Posted in blog city on November 16th 2004 

Martin Fowler has recently blogged about projects of fixed scope in nature and concluded that it is not possible to execute a project successfully in this mode. 

As per the blog,
“The biggest problem with the fixed scope contract is it immediately pits the client and contractor on opposite sides where they are fighting each other about whether something is a change and who should pay for the change.”

The entry also states that

“We took a look at those requirements and estimated it would take us about half a million dollars to build it. Like most people tackling a fixed scope project, we added a buffer - in this case quite a large buffer doubling it to a full million.”

“For each one we estimated the scope of the change and figured out how much it would cost, but didn’t charge the client for the change. Slowly but steadily the changes ate up the buffer. After about six months or so the changes had used up the buffer completely. We’d been quite open with Nebbiolo during this whole time, so they weren’t surprised when we told them that we couldn’t afford to eat the cost of the changes any more. During that time we’d collaborated closely with Nebbiolo and they’d grown to trust us. We had no problem finding more money, indeed it took another half million to cover the requirements changes that were needed before we delivered.”

While I am happy that ThoughtWorks had absolutely no trouble in getting 50% more of what has been estimated — I really wonder if there is a client like Nebbiolo who is willing to accept 50% buffer in the initial estimates (mind you — ThoughtWorks is very open with Nebbiolo and I am sure client is very much aware that there was a 50% buffer) and pay another 50% on top of that again, why does any one care if it is agile methodology or if it is a fixed scope contract?

Just wondering what would ThoughtWorks do if the client refused to pay any more, despite best efforts to make the client understand the FixedScopeMirage. Will it not lead to confrontation? What actually required here is a set of assumptions and risks clearly documented while fixing the scope and estimates. Based on these it becomes relatively easy to convince the client when there are requirement changes that mandate revision of the estimates. Note that this has nothing to do with following agile practices or not. This is the thumb rule of estimations. If you do not know what you are estimating for, why do the estimation?

Mr. Fowler seems to have forgotten that the main reason client insisted on a fixed price deal was because with the earlier vendor the requirements itself were not frozen. That is the down side of time & material projects, where the vendor keeps charging the client by extending the project forever. Fixed price projects are benefical both for vendors as well as the client. And yes scope must be fixed with proper assumptions and identified risks. 

Another way to do the project is to go the hybrid way, which usually works best — gather requirements using time & material contract and once the requirements are signed off, have a fixed scope/price contract to complete the rest of development.

Filed under: General, Technology