Posts Tagged ‘Negotiating’

Fixed Price Waterfall Projects: Perception vs. Reality

Sunday, July 25th, 2010

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.



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.

John Gorman

Buying Another Policy Administration System: Negotiating Tips

Thursday, April 29th, 2010

Buying Another Policy Administration System:  Negotiating Tips

We recently met with some of the senior technology people at a life insurance company here in the US.  After a long exhaustive analysis, the company was completing the selection process for a new policy administration system.  They had narrowed it down to two leading systems from a short list of 7 or 8. 

While both of the finalist systems had their attributes and selling points, it struck us that the newer of the systems had been around for almost ten years and the older of the two had been around for twice that long.  Surely, they had been re-architected and improved in that time, but for both of these systems “new” is not exactly the right description.

In terms of track record, the insurance company openly acknowledged that neither of the finalists had had much success actually implementing their solution in the past 5 years.  Their estimation was two or three truly successful implementations between the two vendors since 2005.

Anything a company can do to improve the likelihood of success with a policy administration vendor relationship is important.  From a contracting perspective, here is what we recommend:

  • Get source code.  Regardless of the administration package or the vendor-speak about not requiring source code, we strongly recommend that you negotiate rights to code (not source code escrow).   If the vendor claims that they don’t provide source code access, the vendor should be able to represent in the contract that they have not licensed source code (or given the option to buy source code) to any other client.
  • Get reasonable provisions around your rights to use third parties to maintain and configure the system.  The vendor should have to earn your business on an ongoing basis.  Most vendors will have a list of competitors that cannot access the system.  Be sure to limit this to providers of competing SOFTWARE.  You need the flexibility to contract with outside experts who can do some or all of the implementation and maintenance.
  • Do not start the project without a signed license.  However, you should have the ability to opt out (and get a refund of the license) if the services estimate exceeds a certain threshhold.  Also, to facilitate the contracting process, you should agree to a term sheet with the MAJOR deal provisions (like getting source code).
  • Get the “A team” from the vendor and get that commitment with named resources in the contract.

Obviously, a good license contract is only part of the equation, but it’s a start.

John Gorman