IT project management: start clueless and work from there?
by David Cotgreave / 12/4/2017 3:07:39 PM
Do you ever listen to the radio comedy show "I'm Sorry I Haven't A Clue"? Billed as the ‘anti-dote to panel games’, it is actually a panel game, it’s been going now for over forty years AND it's very funny.
In IT Project Management, not having a clue might not be quite so amusing. Can you imagine being asked to consult on an IT Project and your opening statement being, "I'm sorry, I haven't a clue." It might not create the best first impression...
So I was quite surprised to hear an IT Project Manager say these exact words last week during a conference call that I was asked to eavesdrop in on.
The IT Project in question is failing ... and I mean textbook failing. It’s late, over budget, scope gone AWOL, no ownership, it's a case study in the making. The stakeholders, who were represented on this call were asking, "What has gone wrong?" I nearly choked on my tea to hear the reply, "I haven't a clue."
However, before you pin the blame on this 'clueless' PM, you should know that, actually, he has been drafted in to save the project. On reflection, despite my initial surprise, not having a clue might be a great place to start, not just for the saviour of this struggling IT project but with any mission that you embark on with your Project Management team.
As I listened in, this Project Manager was certainly not clueless, in fact, it quickly became clear that the project was now in safe hands.
So, how is clueless a great place to start?
In that one opening statement, this Project Manager demonstrated that he had no preconceptions about why this project was failing, he wasn't going to prejudge based on opinions or experiences from previous projects, or prescribe solutions before diagnosing the problem. First, he was going to listen and observe. Listening to him was like a breath of fresh air. To be clear, this Project Manager wasn't ignoring his years of Project Management experience, but he DOES refuse to let it sway his judgement in ways that are not helpful.
Early on, the stakeholders pushed him to make a call based on his vast experience, to hazard a guess, but he wasn't willing to make any judgement until he'd completed a thoughtful investigation.
I honestly think that this is why a lot of IT Projects fail.
Often, Project teams and stakeholders identify that there is a problem, for the sake of illustration, let's say it's scope creep. However, instead of starting with the question, "How do we solve the scope creep on this particular project" they think, "OK last time we had a problem with scope creep how did we solve it?" Then, having remembered what they did - they do it again ... ignoring the fact that it's a whole different project and that it could be a whole different set of stimuli that caused the creep!
In fact, one of the most recent project fails I was asked to carry out a post-mortem on had done exactly this. They had identified missed project milestones but started with a pre-conceived idea of why the project was failing (based on previous experiences). Then they looked for evidence to back this up, which they found in abundance. They went to work based on these 'results' BUT they were false positives, the project was failing due to entirely different reasons.
History, it turns out, is sometimes a really bad teacher!
I remember learning about Bayes’ law that predicts the probability of an event, based on prior knowledge of conditions that may be related to that event. Obviously, this is a watered down definition, distilled to its very essence for the sake of brevity, but Bayes’ Theorem turns this prediction process into an equation, correcting for false positives and gives you the real chance of an event occurring. It's a lovely piece of mathematics and I've often wondered how to turn it into a Project Management methodology.
Not having a clue could be as close as I've ever come to achieving this.
The Project Manager parachuted in to save this project wasn't interested in prematurely hypothesizing about potential causes. He corrected for false positives that may have skewed a diagnosis before declaring his position.
I caught up with him later, over email, and he explained that the late delivery, budget overruns, scope creep, lack of ownership, etc were all symptoms, any one of which could have been singled out as the project's problem. There would have been lots of evidence to back up such a hypothesis in each case. He'd been given all of this information before the briefing (I had listened in on it) so it would have been easy to turn up and claim that the problem was budget overspend, scope creep or any of the others symptoms.
On this particular project, all those symptoms were down to good old-fashioned issues with resource prioritisation across the portfolio and they are already well on the way to being resolved. That could have been missed though if the PM had decided to tackle the individual issues because he recognised them from a previous project.
This is what he wrote to me, "Much better to start out believing that you haven't a clue, observe dispassionately and from an objective position, theorise based on actual evidence from this case and this case alone. Understand that most of the answers don't come from what you know or think you know. New and case-specific facts are more powerful than preconceived notions based on your version of history."
Actually, how often, after a Project fails, is this your first question ... "What did we do wrong?"
I have two big issues with this question.
- i) It suggests that had you not done this one thing wrong, i.e., had you done everything right ... the project would have been a success. This is arrogant in the extreme, such control would elevate you to the level of the gods - by the way, if you were to achieve such power please don't waste your time on IT Projects - turn your attention to important matters like world peace, global equality or my football team's league position.
- ii) It relies heavily on your version and interpretation of history. Guess what - if you were heading up an IT Project that failed, your memory of what went wrong may not be the most reliable. I've been there myself, us humans are very good at coming up with reasons that back up our recollection of events.
However, if you started to unpick your failure without prejudice (not having a clue) you would soon start to pick up very clear and useful clues and project post mortems could really teach vital lessons.
This can be difficult, it can be hard to stand back and see the patterns that are emerging across your portfolio, sometimes you really do need a totally fresh pair of eyes to carry out an independent analysis of your project management office and performance.
That call gave me a fascinating glimpse of a different mindset, a fresh way of approaching challenges. I have resolved to approach (at least some) IT Project problems next year as if I didn't have a clue (and I'll say it before someone else does - I only hope you can tell the difference).
I do wonder how much more innovative we all would be if, just sometimes, we were able to park our preconceptions and prejudices at the door and approach our IT Projects as if we were brand new.