Candle in stump holder. (c) J. Samuel Burner (CCA-2.0) http://www.flickr.com/people/lobsterstew/

The Rise and Fall of Strategic Planning… and project planning, too

Forrest ChristianProject Management, Reviews - Books, Strategy 1 Comment

Rise and Fall of Strategic Planning by Henry Mintzberg, which Jon has mentioned several times on this site. Mintzberg makes some scathing remarks about the Strategic Planning industry. A lot of it seems to come down that the planners are (A) taking the power away from managers and (B) it doesn’t work in practice. I’m wondering if a similar argument can’t be made about software project management.

I’ve mentioned before the dismal record of software projects: according to the surveys review IT Cortex, more than half of the projects in any of the reviews of software project implementations have been “successful”. Big Insurance Group (BIG) certainly had that problem, even though the IT group considered itself to have an 80% ontime rate, their internal clients considered almost every project that I had heard about to be either under-requirements, over-budget or behind schedule.

I believe that this dismal record stems from the same problems that Mintzberg identifies with strategic planning for the enterprise. IT project planning is often done by special groups who are not held accountable for the validity of their plans. “The programmers goofed it up!” “These project managers weren’t smart enough to handle the workload!” “We’ve got the wrong people!”

If your plan was smart, you would have compensated for the stupid people in the lower ranks.

It seems to me that the entire project management field suffers from severe problems. I got this when reading something else of Mintzberg’s on organisational structure. He talked about how the structure for reporting or behaviour can be routinized into professions. He used the example of a surgeon and anesthesiologist during a multi-hour open heart surgery in the 1970s: there was almost no spoken communication between the two. All that needed to be done had been routinized into their professions, which now dictated the roles’ behaviours. I suppose that communication might occur during an emergency situation within the surgery, but even that probably occurs according to strict cultural (within hospital) norms.

Software does not have these routinized roles. Heck, we can’t even agree on what the profession really is, mostly because we try to encompass the surgeons, the surgical nurses, the anesthesiologists, the post-op crew — everyone associated with the surgery. Which is insane, but there you have it. But because we do this, we cannot have any sure plans. Too many things are unknown because we have yet to routinize most of the roles. Or even identify them.

Plans go awry even in very routinized industries on large projects. The construction industry rarely meets a deadline, much less a budget, on a multi-billion dollar project. We can all talk about how this is due to the requirement for “best circumstances” estimates — which DeMarco and Lister describe well in Waltzing with Bears: Managing Risk on Software Projects — but that’s still blaming someone else. If the system worked at all, then it would compensate for the need for best circumstance estimates in some way. Most software managers are as surprised by not hitting their estimates as their bosses are.

Agile methods, including eXtreme Programming (XP), have been developed to compensate for this by not producing any end date whatsoever. The recent debate in IEEE Computer shows that the jury is still out but that it is a solution to a deep problem.

Image Credit: image (c) J. Samuel Burner (CC BY 2.0)

Comments 1

  1. Post
    Author

Leave a Reply

Your email address will not be published. Required fields are marked *