The myth of Project Management

I first discovered the term “consensual hallucination” when reading William Gibson’s seminal cyberpunk novel “Neuromancer”. He used the term to describe his concept of cyberspace – a place that didn’t actually exist but it was a representation of a massive computer network that people could conceptualise well enough to deal with. For ease of understanding, everyone treated an abstract concept as a physical reality – they consented to believe in the hallucination because it was easier to understand that way.

Life is full of consensual hallucinations. If you live in a democracy, you tend to believe you have a say in what happens even though the whole political system is completely under the control of vested interests. Voting is a sideshow but we tend to indulge in the consensual hallucination that it means something because life is easier to bear that way. In fact, pretty much any political or religious belief system is a consensual hallucination.

Which is not to say that they are all by definition untrue – simply that they are abstract systems that people tends to treat as concrete reality despite the complete lack of empirical evidence to support this consensual hallucination.

When you work in IT, you deal with the consensual hallucination of Project Management. There is an almost universal belief that it is possible to predict ahead of time how long a project will take, how much it will cost and what will happen along the way. In the broadest sense, this is possible. If you have enough experience you can come up with ballpark figures; last time we did something similar it took this long and cost this much.
But some people believe Project Management should tell you these things down to the day and the dollar. A project plan should tell you every task that needs to be completed. A project plan should be flawless and leave nothing to chance. And a project plan should be completed before ANY work is done on the project.

Despite the fact this is clearly insanity, it is a terrifyingly common mindset in management ranks. Project planning and goals are obviously important at some level (otherwise how the hell would you know what you are doing?) but how did we move from “let’s have a clearly defined set of project goals and a strategy for how we’ll get there,” to “this is 100% accurate, carved in stone and will never change”?

I think there are a number of reasons the myth of Project Management has been elevated to the level of holy scripture:

• A whole industry of consultants who base their existence on the lie that they can provide definitive solutions to Project Management
• Several rainforests worth of books purporting to offer the definitive methodology for flawless Project Management
• Nobody likes to look stupid. If you’re a professional and someone puts you on the spot to answer “how long will this take?” you like to have an answer
• When you do work that is measurable in retrospect (“we wrote this many lines of code and it took this long”) it’s easy to fall into the trap of thinking you should be able to project forward accurately (“it should be this many lines of code which should take us this long to do.”)
• Very few businesses are keen to hand over an open chequebook – when you buy stationery, you know what you’re getting and how much it will cost. Why is it so hard to get the same thing with software?

So how do we escape the consensual hallucination that there is a way to do Project Management that is absolutely foolproof and provides definitive answers?  Well, the first step is to kill all the consultants.  Okay, maybe that’s a bit harsh.  Let’s limit ourselves to killing the consultants who act as though they have some mystical powers that enable them to succeed where all other have failed.  Maybe even that’s going a little bit too far.  Surely there’s a solution that doesn’t involve the risk of incurring jail time?

There is no silver bullet (although there’s quite a good essay entitled “No Silver Bullet“) that will solve this issue but there are things that can be done to improve the situation.  How about we all sit down to a big three-course serving of reality together?  If you’re on the development side, one of the best things you can do is to have the courage to say “I don’t know,” when you don’t, in fact, know the answer to a question.  Sure, the geek mystique might take a bit of a hit when you admit you’re not infallible but it’s worth it in the long term.  If you’re on the business side it means LISTENING when your IT people tell you that a definitive answer isn’t possible.  The obsession some people have with getting an answer, any answer, even when they know the answer is totally inaccurate is nothing short of stupidity.  Just don’t do it.

It’s perfectly reasonable (and I would even suggest that it’s necessary) to come up with some sort of estimate in a project plan.  So long as everyone agrees that’s what it is: an estimate.  And, more importantly, the estimate will need to be revisited at key milestones to see if anything has been uncovered that will affect previous estimates.  For this to work, everyone has to be open and everyone has to listen and be responsive.  Or we can keep flailing about saying it has to be this way because the sacred Project Plan says it’s this way.

To illustrate the ups and downs of Project Management, in another post I’ll be documenting the project I’m finishing up on right now.  I’ll be using my current project as an example because it’s one of the best managed projects I’ve ever worked on (I’m not the Project Manager so don’t worry – I’m not big-noting myself).  It’s a good illustration because it’s quite a big project and most of the Project Management was done really well but there were still some problems.  And at the end of the day, it’s the way everyone involved handles the unexpected that drives whether a project will succeed or fail.