There have been several discussions on the forums and in a Blog or two about how formal project management processes have failed us in the past. We have a saying where I work...
Don't do stupid things on purpose
Here a few of red herrings I've come across lately:
- Project's measure performance by counting the hours consumed and money spent (cost and schedule performance) - don't do this. This is called "level of effort," and the only thing it measures is the non-recoverable sunk cost of the project.
- The units of measure of progress is defined in the Earned Value process. This does not mean the full ANSI 748B but it has to be some way of attaching value to the deliverables.
- Define the value of the deliverable. Measure the cost of delivering this value. Measure the presence of the deliverables in terms of 0% or 100%. Either it's there or it isn't.
- Keep track of how much its costs to deliver a "unit of value" and use that as a forecast for the future.
- If you are performing a 0.9 (90%) get back to 1.0 (100%) is not enough. You're underwater (below the line). You need to get above water for awhile - 1.1 (110%) in order to catch up.
- This catch up process can not be done by spending more money. It can only be dome by being more efficient. Less rework, faster deliverables for the same cost.
- Working harder does not help. OK, a little but you can't sustain it for long.
- Detailed estimates add value - don't do this in the way PMBOK suggests. Also don't believe completely David Anderson when he says estimates are Muda. The truth is in the middle.
- Actually the truth is in the situational middle. Here in aerospace we use a rolling wave planning process. A detailed plan is built up to the Integrated Baseline Review (IBR). This is the point in the project where everyone sits down and agrees what the project will deliver, how much it will cost, and when it will be done.
- This is done "after" the project is started not before. There is a "proposed" cost and schedule of course, but at IBR the cost and schedule are baselined so no one is confused later about what was agreed to.
- Risk management is a part of project management - don't believe this for a moment. Project Management IS Risk Management. Project Management is a verb. All the administrative activities (the keeping score activities) of project management defined in all the project management guides ignore this to their peril, starting with PMBOK.
- The Integrated Master Plan / Integrated Master Schedule (IMP/IMS) DID 81650 requires a "schedule risk assessment."
- Many project management guides fail to distinguish between Technical Risk and Programmatic Risk. They are different. They drive each other but in non-reciprocity ways.
- In the same way there is non-reciprocity between risk and opportunity. They are two sides of the same coin but they are not interchangeable - just like the two sides of a real coin are not interchangeable (obverse and reverse). Except the Euro coins which have confused all collectors are to which side is named what.
Enough for now, there is more, but this will get you off the path to trouble and get you asking some important questions.
- When someone makes a statement about how bad a process is - ask first "is this process being misused or misapplied, or simply misunderstood. The red herring of "cost accounting" is one of those. The "accounting of value" is a better term, but in order to deliver value, costs have to be applied to one side of the equation.
- When someone makes the claim "there is nothing new under the sun," ask them about Capabilities Based Planning, Event Based Scheduling, Maturity assessment instead of progress to plan, Earned Schedule (not Earned Value, Earned Schedule).
- When great thinkers are invoked as the justification for doing something - like say PERT - ask if they have read the original documents on the subject, spoken with any historian of the subject, or have the original or near original manuals from the original or near-original training classes. No? Maybe they're speculating.
