Preventing Project Failure

Yesterday, DoD’s Missile Defense Agency killed the KEI Program. The Kinetic Energy Interceptor is a weapon system that detects the kinetic energy of an enemy’s rocket blast, focuses in on that and shoots the rocket down during its launch. To Northrop Grumman (NG) and its subs, this action represents a 6.3 billion dollar loss. KEI was a big program and perhaps that’s why it was a fairly easy target when the Secretary of Defense started looking for ways to cut costs in the DoD.

But I think that cost cutting was not the only reason the KEI Program was killed. Actually Gates pretty well summed it up when he said, “..the system had limited capability, would have been difficult to fire from ships because of fits large size, cost too much and would have to have been launched from close to the target.”

Wow..So , if I’m the PM on this project, I would be pretty torn up by the Secretary of Defense (SecDev) talking about my project like this. Especially after it’s been in the works for years. Knowing what I know about DoD culture, and especially the ability of buzz to travel in the Pentagon, this says to me that the buzz about the system had to be some time in the making for the SecDev to go up there and fry the program.

I know when someone talks dirt about one of my programs, I certainly have a different opinion of it than they do. So I took a look at some of Northrop Grumman’s (NG) info on their KEI Program website to see what they thought. Incidentally, to say this is a big loss for them is an understatement. Its one of the 9 programs listed on their missile defense page. A major program in a mega company. Anyway, yes, they think a bit differently. Their advebs say that the KEI is has “Deployment Flexibility”, is easy to deploy in a crisis, and has a “small temporary footprint”.

Compare the buzz:

NG: deployment flexibility

Dod: needed to be too close to the target to work

NG: small temporary footprint

DoD: built too big

NG: easy to deploy

Dod: difficult to fire from ships

What happened to get these groups so far apart? I don’t know a soul at NG so anything I write here is pure educated speculation, but because the program was so big there’s a lot of info on it, so I started piecing it together. My initial gut reaction was simply that risks weren’t properly mitigated. I believe that projects fail due to three causes. They can implode internally because of no process or process that people don’t follow. Or they can have firm process but miss the intent of that process and that’s usually reflected in a spectacular failure that comes from the external customer. I think that NG missed the intent of project risk management in this case.    The intent of risk management is to think about and mitigate for ways the project could fail.  I trust that a company the size of NG has really good risk management in place.  But its very possible to have a limited view of risks; to focus on project risks from a resource perspective;  ie ‘the risk my pm may quit’ and not from the strategic perspective; ie ‘the cost of implementing changing requirements may outweigh the benefits of continuing the project.’

Project Risk Management

My thought here is that two risks really came into play; the risk of additional unknown new requirements and the risk of shifting political winds. It could very well be possible that NG was simply responding to the needs of its customer when the scope was allowed to change. If this is the case, then risk mitigation should have come into play. I imagine a seasoned PM would have raised the red flags with a conversation that would have gone like this:

PM to NG head honchos: “Head Honcho, I’m worried about this change in scope. I know that we followed our project integration management procedures to the T and that we’ve adjusted resources to meet the new requirements, but lets think about this a second.”

NG Head Honcho: “Hey..yeah…let’s think about 6.3 billion dollars.”

PM: “Sir, that’s my concern. We need to understand where the change came from and who is driving the change. My worry is about what kind of stakeholder support exists for the new set of requirements.”

NG Head Honcho: Hey..yeah…let’s think about 6.3 billion dollars.”

PM: “It took years to develop the initial set of requirements and I know through my experience with this customer that its buy-in across the services is key to successfully project implementations with large systems. Given that initial scope had buy-in, but we are unsure of the buy-in for the new scope, shouldn’t we make sure that we mitigate the risk of some unknown outside stakeholder killing our project by doing the rounds again with the new requirements?”

To which I imagine the NG Head Honcho said something like: Hey..yeah…let’s think about 6.3 billion dollars.”

In other words, the risk on a requirements change is that someone, somewhere didn’t know about it, or agree to it. The larger the project, the more likely this is. And indeed the online literature does show that after the scope change, and about 2 years into the project, the Navy started grumbling. An article in navyleague.org KEI Now Seen as Multipurpose Missile Defense Weapon specifically addresses the scope change and brings up hard issues about problems in KEI size and deployment.

I got burned on one of my projects for this same reason. I kept hearing that a key senior executive sponsor would have to agree to requirement changes, but I didn’t push hard enough to get in front of that sponsor. So sure enough, when it came time to release the new version of software, this key stakeholder put on the brakes and my schedule went all wacky. My lesson learned was to include language in every scope document that ensures that all stakeholders be informed, and to work with my clients to mitigate the risk of the unknown, hidden stakeholder with the power to kill the project.

For PMs working on DoD projects, this possibility is even more real. The Pentagon has its own culture, with at least three layers of strategic objectives that span horizontally and vertically throughout the building and across a complicated web of interactions between rotating officers, senior leadership, contractors and civilian employees. Assignment Pentagon explains this culture and is a must read for any PM working on IT projects with DoD.

More evidence of this phenomena: There’s a great article about the LAMP-H program that got killed for very similar reasons originally published in the December 2006 PMI journal.

Ok, my final thought here is that perhaps NG did everything right –maybe it did mitigate risks and socialize the new scope with all stakeholders. They may have failed in this: not mitigating for a great shift in the political winds. The financial firms who do projects in foreign countries are exprert at this. Probably because they’ve lost a ton due to rapidly changing political scenarios. Indeed, I found this great presentation from Barclay’s that speaks their risk mitigation practices in large infrastructure projects. In the US, we have a firmly established rule of law and timely and stable elections (ahem– in comparison with the rest of the world). At least we are stable enough that the NG PMs could forsee a political election occurring in the middle of the project. Just like in financial firms, they could have run a risk simulation, a stress test with the assumption that the country would move from the center right to the left, which is currently happening.

Tools to Apply

So what can we PMs learn from this story?

1. In military projects mitigate for these risks

a. Unknown stakeholders with the power to kill the project

b. Lack of socialization of new requirements

c. Shifting political winds

Until my co-worker mentioned that DoD had killed the KEI program, I had never heard of the KEI program. I present this very blog post itself as evidence of the danger of headline risk. Therefore, I close by bringing us back to the hidden cost of project failure, which I blogged about last week. It’s sad, its depressing, it costs money and ultimately, it can be avoided.

• • Comments [6]
  • Tags [case study, Controlling Scope]
  • Categories [Controlling Scope, Real Life]