7 Caution ↑
No. 50 — Do Not Place Excessive Faith in Project and Program Management
Project management – and its big brother, program management – certainly have their place in software development. None can gainsay the value of counting things, and comparing actual progress to plans, and reporting status, and delivering progress reports – these are all essential activities on any large project.
However, many of the important things happening on a project cannot be directly measured through any project management technique I’ve ever seen. Are big decisions getting swept under the rug? Are junior programmers being left on their own to cut code that will need to be rewritten later? Is the team working on the easy things, and leaving all the hard things for later? Are analysts generating reams of requirements documents that are full of boilerplate text, and say little or nothing of any significance? Are key customers too busy, and not paying enough attention during document reviews and product demos? Are some customers in violent disagreement with each other, and secretly hoping the project will fail? These are the sorts of things that typically torpedo projects – not the fact that the project is 2% off on its earned value measures.
This is not to say that good project managers can’t detect these sorts of issues – but it is to say that increased application of project management discipline is not likely to bring these issues to light, let alone correct them.
It doesn’t help that, in many organizations, project managers must report a version of reality that satisfies leadership’s unrealistic expectations about a project and how it will perform.
Think of project management as something like a color-blind monitor trying to manage the creation of a new oil painting, and you will be on the right track to making effective use of project management on your software development efforts.
Words from Others on this Topic
There is probably no job on earth for which an ability to believe six impossible things before breakfast is more of a requirement than software project management. We are routinely expected to work ourselves into a state of believing in a deadline, a budget, or a performance factor that time subsequently may prove to be impossible.
– Tom DeMarco and Timothy Lister, Waltzing with Bears: Managing Risk on Software Projects, 2003
One frequent analogy casts the manager in the role of an airplane pilot guided by organizational measures that are like cockpit instruments.
Mechanistic and organic analogies are flawed because they are too simplistic. Kaplan and Norton’s cockpit analogy would be more accurate if it included a multitude of tiny gremlins controlling wing flaps, fuel flow, and so on of a plane being buffeted by winds and generally struggling against nature, but with the gremlins always controlling information flow back to the cockpit instruments, for fear that the pilot might find gremlin replacements. It would not be surprising if airplanes guided this way occasionally flew into mountainsides when they seemed to be progressing smoothly toward their destinations.
– Robert D. Austin, Measuring and Managing Performance in Organizations, 1996
Next: Let the Buyer Beware