Archive for July, 2010

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

8 Reasons Why Large Policy Administration Systems Are a Thing of the Past

Friday, July 9th, 2010

Today, it’s clear that insurers will stop placing big bets on large systems. They’re moving to a model where small components and web services combine with their legacy components in an incremental manner. Here are some of the reasons why:

  1. All systems want to be the “center of the universe”. In a future world of SOA and architectures of small re-usable components across an enterprise, components need to be built from the ground up to be standalone and ready for integration.  Most vendors of “systems” or “platforms” say they are built for integration (and some of them even are). Of course, you need to make that system the “hub”.
  2. “Throwing the baby out with the bathwater” – much of what insurers already have in place works just fine and can be leveraged in some way without significant expense.
  3. The full software package has a number of awesome features that are just not applicable to your business.  It has been estimated that more than 50% of the overall functionality a system has to offer is not even needed or used in the average implementation.   The customer is paying for this functionality one way or another (with higher than needed fees to vendor and higher maintenance costs due to “code bloat”).
  4. There is no comparable “one-to-one” match to your existing legacy platform you want to replace.  So, a significant mapping, customization, “configuration” and integration job is required.
  5. Redundant functionality in the admin system to other areas.  Typical redundancy consists of client, product, policy, agents, and even generic functionality like content management, users, security, work queues, correspondence and much more.
  6. It’s all legacy anyway.  The “newest” US life Policy Administration system with any substantial customer base is about 10 years old.  With technology generations coming and going faster than ever, this is already out-dated.  Compound that with the fact that it will take you 3-4 years to convert your legacy onto this “new” system that is now almost 15 years old when you are finished…time to start looking again for a new system.   Now, let’s look at some of the other “good” systems on the market…they have all been re-branded by slapping on new technologies onto their old core code.  In those cases, you’ll be looking at a 20-25 year old system by the time you’re done.
  7. Instead of incremental improvements sooner, systems are designed to be implemented as “big bang” by converting full blocks of business or put up new products.  They do not allow you to implement one major business function at a time.
  8. Most of the top vendors out there have been acquired by a large company who has significantly increased costs, are primarily looking for the “big deals”, have stopped innovating, and diluted the domain expertise and talent.

If you want to learn about the next generation of Life Insurance enterprise components, see

Tom Famularo