Fixed Price Waterfall Projects: Perception vs. Reality

Many years ago, my old company (which was a small software and services company that did large projects) got tired of the unpredictability of cowboy programming and we embraced a waterfall systems development methodology with the fervor of the newly converted.

We would capture detailed business requirements that would let us determine the “whole cost” of the project and create a bullet-proof implementation plan. We could even commit to a fixed price for the known scope – really it was a fixed price for implementing our interpretation of the business requirements. When we wrote the functional specs, we would learn even more and get some additional requirements, which would result in change control items. Thanks to our waterfall methodology and rigorous project management, we could explain why the project was getting bigger. As we started to code and learn even more about the requirements – the scope and cost would grow some more and the date would start to shift.

Months later, we would complete our testing and deliver to the client – and the business users would say “this isn’t what we want”. And we would say “but it meets the spec”. This would lead to weeks of contentious conversations and analysis and justification. Ultimately, we’d all agree to a compromise no one was happy with.

This was done in good faith and with good work efforts all around. However, the reality was that the fixed price would be for a defined amount of scope (call it “X”), but the project would grow legitimately because of new scope or new interpretation of the documented scope. Before you knew it, X became 2X, which made for some painful projects and some contentious client relationships.

When I started working for a larger, more established company, I learned that there might be a better way. I learned it was better to estimate all of the likely costs up front. So, we spent more time on requirements and got even better estimates, more bullet-proof project plans and detailed scope definition. Unfortunately, the costs still went up during design and build – but at least we had much more data to explain why the project was a lot bigger!

Especially in the world of big insurance systems, I believe there is a large gap between perception and reality when it comes to fixed price waterfall projects. At the risk of stating the obvious, I have listed below some of the areas where I see the gaps. There may be good business reasons or constraints that steer you toward the fixed price waterfall approach, I would just recommend that you go into it with your eyes wide open.

Perception

Reality

A waterfall project with a fixed price contract lets me know what my cost is going to be

Fixed price contracts let you know what the cost is going to be for the vendor’s interpretation of documented scope. Typically, large multi-year projects will cost multiples of the initial estimates due to change control items.

Defining the scope up front is worthwhile because I can make sure that everything I need will be in the system.

You spend way too much time defining scope and creating “bound scope” and not nearly enough time prioritizing scope. Too much unnecessary scope is documented and many important requirements are missed and become change control items later.

You can document enough to bind the scope

Until the client sees the functioning system, there is no way to remove “interpretation risk”. There is just not enough time or budget, typically, to review and discuss every requirement and spec to ensure there is no misunderstanding.

A tight change control process will ensure that management will understand and buy into scope increases

Management will not have the bandwidth to focus on change control items. It won’t be one big item, but a series of smaller, detailed items that drive the cost up. Ultimately, the scope will grow significantly and management will not feel good about the rationale.

Fixed price contracts favor the client

Fixed price contracts favor the vendor if the vendor is sophisticated enough to manage change control process properly.

Fixed price contracts make for a smoother relationship because everything is documented

A good vendor project manager will know the contract “inside and out” and will be ensuring that both parties uphold their part of the bargain. There will be a lot of contentious discussions about what is in and what is out of the fixed scope. Terms like “nickel and dimed” will be used regularly.

Responding to “…we would complete our testing and deliver to the client – and the business users would say “this isn’t what we And we would say “but it meets the spec”. want”. – it seems to me there is an important role, that hasn’t been explicitly stated. That is, ‘checking in’ frequently with the business users – to understand their perception as well as identify business pressures that have an impact on the gaps. It’s an important feedback loop – that can help you build greater understanding on both the business side and development team, AND in parallel – build buy in and engagement for what comes down the pipe from the development side.