I think you've struck upon one of the KEY factors of project success right there that no one mentions.

Trying "experimental" things first, proving them, then moving on to the more routine parts of the system.

One of the other really good code books I read, I think it may have been Code Complete, said that developers really must try the "experimental" parts of a system first. The high risk stuff.

The reason, from a business perspective is obvious. If some key "new" component of a system, or business process, or approach DOESN'T work, then there really is no need to continue funding the project.

Yet, of the large project failures I've been involved with, exactly the OPPOSITE has happened. The project manager and developers do the things they are most comfortable with, spend the majority of the money in the project, then discover that the key "NEW" thing doesn't work. Ooops, sorry we took your money. We were billable by the hour, so we can't refund it to you.

This dichotomy occurs because most consulting outfits are operated off of "billable hours", and so they want to bill as much as possible before the "unknown" parts of the project are tested. It's a key reason, I think, that many people are avoiding the likes of EDS/IBM GS/etc. for consulting. ( It may even be one source of reasoning for outsourcing overseas. The thinking goes, "If we can't trust the largest, most established companies in America, then who can we trust? We might as well try someone else, less expensive." )

Bob Lewis, the former columnist for InfoWorld in the management arena keeps preaching 3-6 month engagements. His philosophy is that you give them the risky stuff first, see how they handle it, then decide whether they're honest enough to make a permanent part of your team.

I really like his thinking.

Glen Austin