Project Management – Form over substance

I was asked recently about why projects fail, or at least fail to deliver what they were supposed to, and was it because “A failure to plan is a plan for failure”.  That may well be a part of the reason, but by no means all of it.

One thing I have noticed is that the way we do projects today is not the same as when I started out in the 1970s.  Many changes are for the good, but to my mind the effectiveness of project delivery has suffered because project management is now horribly over-engineered.

I suspect that Project Management has succumbed to the modern fetish for valuing form over substance.  Simply put, we focus more on how we carry out the project rather than focussing on the activities producing the product we are being paid to produce.

When I started out in project management, we spent time working out what the problem actually was, how to solve it, who and what we would need and for how long.  We explored different avenues of approach, different ways of meeting a target.  We focussed on the customer’s needs and expectations. We focussed on what was to be delivered.

Nowadays it seems that the focus is more on planning how you are to do it, coupled with a determination to adopt methodologies and standards.   The result is that we spend more time planning the methodology and approach to the project rather than working on the technical requirements of the solution and how we can deliver it.

To compound the folly, we then expend oodles of effort in micro-managing the project execution through layers of programme directors and managers controlling project managers and leaders. 

The body of documentation has greatly increased.  Initially it was a project plan showing activities, times and responsibilities.  Now we have that, but supplemented by risk analyses, process flows, summary timelines, and all sorts of forms showing who did what, with and to whom, and when.  Of course we must have meetings to discuss the documentation.

That gives rise to a much greater number of formally documented meetings, implying a new breed of project administrators who manage the documentation and schedule the meetings, adding to the project overhead, both in time and cost.

A second consequence is that the poor people at the coal face have, in addition to actually doing the work, a welter of forms to complete.  It often seems that management are more concerned that you have not filled out your DB1-A form than addressing an issue which means you will potentially miss a critical deadline.

In summary, you may have a beautifully planned project, wonderfully documented, slavishly following standards, policies and procedures, costing time and money but which has delivered diddley-squat.   The project management landscape is littered with their corpses.

I am reminded of my father, a surgeon, who used to say, “The operation was a great success, but unfortunately the patient died”.

Perhaps it is time we did away with Prince and PMBoK and concentrated on actually delivering the goods.

Next up, I’ll explore how project complexity and the rate of business change work against each other.

Finally, perhaps, I’ll explore how the use of third parties in the project management execution cycle can really put sand in your gearbox.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s