Preventing Project Failure

A few weeks ago I tried to find someone who had used a multi-year Integrated Master Schedule (IMS) on a software project on twitter. I got no love, no response at all form the whole PMOT list. Even at Happy Hour with my fellow PMs the mere mention of the dreaded multi-year IMS brought moans from around the table.

I’m new to a project that is using multi-year IMS for a 5 year long legacy application upgrade project. So, because I’ve always used effort based schedules, I decided to bone up on multi-year IMS knowledge. Instinctively, I didn’t like the idea of a 5 year long schedule and became sort of predisposed against it; not an active vocal opponent but more of a subtle ‘this thing don’t sit right with me’ opponent. Anyway – the IMS is working well enough on the project that there was only so much bithcing and moaning I could do.

So I thought long and hard and have finally realized why the multi-year IMS is not a good thing for software projects, or any project that isn’t a bridge or an aircraft carrier.

But First – What is a IMS? The IMS is at its core an event based schedule. It’s usually used to plan very large projects (like building aircraft carriers) that extend over a number of years. The operative sentence asked by the PM building an IMS is: How do I know when something is done, and what indicators do I have to know how close a task is to being done?

In contrast, most software projects that I’ve been on use effort based schedules. The effort based schedule describes tasks in terms of what someone must do to complete the task. So the operative sentence asked by the PM building an effort based schedule is: What do you have to do and how long will it take you?

Different questions, different answers, different way of looking at things. I’m actually ok with either way of building a schedule and and ok with IMS thinking.

Glen Alleman provides lots of great resources on IMS here if you want to read more about the theory behind it.

But what doesn’t sit right with me is the use of an IMS to lock down assumptions on very long projects.   DoD contractors like to use multi-year IMS because it gives a good snapshot of ‘do-ability’ as in – ‘yes, we really can build an aircraft carrier in 5 years’. And this is because the IMS is usually a required contract deliverable, something that can be held up to prove that a schedule was indeed built (check). And on a lot of gov contracts, that’s what’s being asked for; “show me the schedule, show me the WBS and show me how you are going to reach the goal, with all the subcontractors and all the resources. And then I’ll release more funds to you, contractor.”

Putting everything in one long schedule can do that for you. And when you feel confident, you baseline multi-year IMS and the baseline becomes the foundation upon which variance (CPI, SPI etc.) are measured.

Key Problem So why are so many multi-year IMS based projects way over cost? I wrote about the Northrup Grummen KEI program that was killed last year. And now the GAO is hammering Lockheed about cost overruns on the F-35 fighter.  They write “Total estimated acquisition costs have increased $46 billion and development extended 2 ½ years, compared to the program baseline approved in 2007.”

My take is this: some projects will not work with a multi-year IMS and will always result in cost overruns. This is what gives me the PM heeby jeebies when using multi-year IMS on a software project; you can’t plan that far out because for smaller deliverables, the situation is much more volatile.

Where is IMS from? I believe the multi-year IMS grew as a useful tool out of very large capital construction type projects, and thus its main assumption, that you can develop an accurate plan and cost estimates for long term projects, works only in those controlled projects. In other words, it’s an artifact of a different culture; the capital construction (bridges) and very large deliverable (aircraft carriers) cultures; not the rapidly changing business rhythms of medium sized deliverables (fighters) and software projects.

Let’s look at the assumptions that come out of the two different types of cultures; Very Large Deliverable Culture and Medium to Small Size Deliverable Culture.

Very Large Deliverable Culture The multi-year IMS works will with very large deliverable culture (VLDC) because of VLDC’s relatively longer business rhythms, locked in senior management commitment, stable resources and predictable costs. VLDC culture is characterized by the following:

• Longer Business Rhythms Nobody expects a very large deliverable project to go up overnight. There’s a built in assumption that the project will take years before there is any usable piece. In fact, it may not be usable as a deliverable until all the years are up. And no matter how your stakeholders might want to speed things up, there’s only so much you can really do because once you’ve started you can’t throw away all that you’ve done to that point and change course.
• Stable Commitment Therefore, commitment to the project remains unless something heinous happens like complete economic collapse. New administrations don’t change the commitment, new CEOs of companies don’t change the commitment. And scope does not change the significantly. Everyone is committed to the project because you look great when it’s done. Ta Da!! A New BRIDGE!!
• Less Key Person Dependency Very large deliverable workers have knowledge, but it’s usually based on a skill that can be transported from place to place. When, for example, your plumber leaves to work on another project, he’s not taking with him all the plumbing knowledge on the project; usually another plumber can come and figure out the schematics right away.
• Costs are More Stable and Rise Predictably Costs for very large deliverables are of hard and fast physical resources, the cost of concrete, the cost of bolts, the cost of screws. The cost of these items rise predictably. And not only that; companies that produce very large deliverables usually employ economists who will model out the price of cost shocks and incorporate that into their contract price.

Medium to Small Size Deliverable Culture The multi-year IMS will not work well with Medium to Small Size Deliverable Culture (MSSDC) because of shorter business rhythms, rapidly changing business priorities which results in less stability in senior management commitment. In addition, in MSSDC, costs are more unpredictable and knowledge worker transience is damaging.

• Shorter Business Rhythms MSSDC projects usually arise out of some pain point in business; some need to stay ahead of the curve in a field of cut throat competitors, or in the case of government, to increase productivity to meet the needs of vocal opponents, like frustrated taxpayers. But the idea here is that usually a problem exists that has to be solved and until it’s solved, people are suffering. So there’s pressure to get it done, and fast. Further, knowledge workers come at a higher price point, so there is pressure for them to produce, to insure that with all the money that’s being paid out, they are delivering. All this creates the expectation of multiple deliverables, produced early, and produced often.
• Key Person Dependency on Transient Resources Most knowledge workers become more valuable over time because of what they know. And the more they know, the more they are in demand by other projects. And the more they know, the worse your project is when they leave. And they move around a lot. Especially software engineers. Generally, workers don’t stay for the long haul, and when they leave, they take their knowledge. Unless you are very well documented, replacement is very costly, learning curves are longer and time is almost always wasted in transition.
• Costs are More Unpredictable This is all about Company A buying out Company B buying out company C. So when you built your project on assumptions about using a certain software package and then the following year, said software prices go up 50% due to mergers and acquisitions, you are quite stuck. It’s not like the price of 2X4s that will rise smoothly according to economic indexes. Hardware costs will usually go down due to Moore’s law, but the world of software and licenses is a dicey world indeed.
• Unstable Commitment With the quicker business rhythms come quicker changes of leadership. One woman’s burden could be another woman’s bliss. The CEO of yesteryear thought that a new sales system was in order, but the new CEO believes that sales is no longer the lifeblood of the company and changes course to support research; and all of R&D’s software priorities. And since software projects deal with smaller, quicker deliverables and functionality, senior management may feel that it’s easy to simply produce more widgets and change scope as well, even if they stay committed to the project. It’s not easy to build another bridge, it is easy to add just one more fighter to the F-35 scope.

So here’s the thing; the use of a multi-year IMS is based on Very Large Deliverable assumptions that don’t work for Medium to Small Size Deliverable projects. A multi-year IMS assumes:

• Stable Senior Level Commitment
• Stable Scope
• Stable Human Resources
• Predictable Costs

In fact, I don’t think any of those assumptions hold true in anything other than very large deliverable projects. And when that multi-year IMS is baselined in a medium to small size deliverable culture, it’s almost a guarantee that life will change so significantly that costs will go up in unpredictable and volatile ways.

Should you use a multi-year IMS? Can you answer yes to these statements?

1. My senior management will maintain commitment to this project for the length of the project (Stable Senior Level Commitment)
2. The chance of the scope changing is <10% for the length of the project (Stable Scope)
3. 70-80% of my human resources have no key person dependency. (Stable Human Resources)
4. Physical resource costs (software licenses, hardware) will grow predictably for the next five years. (Predictable Costs)

Recommendations If you have a multi-year project, it’s good to use the multi-year IMS to get to the notion of ‘do-ablity’, as in ‘yes, its possible to do this project in 5 years’. But follow this guideline to baseline a schedule that won’t leave you with cost overrun:

Baseline Iteratively Baseline only that part of the schedule where you’re 90% + sure of costs, resources, scope and duration stability. Set milestones for when you will revisit the next baseline and build that into your project plan. So for example, if you are only reasonably sure of the first year, baseline only the first year. Then continue to work towards a date when you will baseline the next year.

Lockheed hit significant unknown unknowns a few years into the F-35 project. The GAO writes that “continuing manufacturing inefficiencies, parts problems, and engineering technical changes indicate that design and production processes may lack the maturity needed to efficiently produce aircraft at planned rates.”

It’s the planned rate part that is getting Lockheed into trouble now. My guess, and it’s just a guess, is that they baselined a multi-year IMS; they used a tool meant for slower rhythms in a faster environment and instability in that environment was not accounted for in their original baseline.

Final Thought I think it would help for notions about scheduling at the very high levels of government to change. Use the multi-year IMS as a planning tool, but not as scheduling dogma. And maybe end the use of a baselined multi-year IMS as a contractual deliverable. Perhaps baselining in increments is a better idea, and contracts can be written to embrace Progressive Elaboration. I’m encouraged to see DoD updating IT acquisition to adopt some of these ideas.

• • Comments [4]
  • Categories [Methodology]