Why is it so hard?

Steve Romero comments on the "Same Old Problem," regarding all the reasons projects fail into the ditch.

I've modified the statements a bit, but they're still true.

• We don't have enough resources to get the work done
• In our organization, there is no real planning process and when there is no one follows it
• We don't prioritize our projects or the features in them. every project is a #1 priority along with the "must have" features
• Our priorities are constantly changing with no explanation, impact analysis
• Everyone is by passing the approved processes and then wonders why things go wrong
• Funding tends to be very political, unstable, and not connected to the produced value
• We can't kill a project or a feature in a project. If we do kill a project or the features, it always seems to show up again. We never have any objective measurements to overcome the politics in decision-making. 

So why are things statements true in some domains and not others? 

The Minimum Buy In Cost for Managing a Project

In the aerospace and defense business the guide of the amount of Level of Effort work runs around 10% to 12% depending on the customer. This funding goes for administrative functions: Program Management, Contracts, Program Planning and Controls.

So where is the allocation of resources for "managing" the project? The commitment to managing the project? The skills and experience in managing projects?

The CMMI-DEV 1.2 framework asks:

• Goals
• Commitment
• Ability
• Measurement
• Verification

When I hear of projects that have "gone in the ditch," like those from Steve's post, I ask "do those project teams actually know how to manage a software project or a collection of software projects?

Sounds like the answer is no. So Steve has it right when he says 

It is heartbreaking to know so many folks continue to deal with these circumstances. I am very much looking forward to the day when these problems are a thing-of-the-past.

This is a Self-Inflicted Wound

From a recent NASA Cost Symposium paper "The Joint Confidence Level Paradox: A Historical Denial," the simplest explanation of the failure to apply sound principles to the management of projects has two conclusions:

1. We are not really seeking probable cost and schedule accuracy (and the management of scope and requirements that comes with that), but are primarily concerned with keeping programs viable and fundable as long as possible.
2. The variables are too complex, unquantifiable, and incalculable.

One more piece of background for failing to invest in the necessary planning and controls comes from Dan Galorath,  "Controlling Software Costs: Development is (Only) Job One"