Have you seen the TV show “The Roast Of…”?
Basically, it’s like ‘This is your life’ (if you remember that, back in the day) but instead of celebrities coming on and praising the subject of the show, they turn up and spill the beans on their bad habits and worst moments. The most recent one I saw featured Bruce Willis and Demi Moore was hilarious, roasting her ex-husband.
I wondered what kind of stories would come up if they did an episode entitled “The Roast of a Project Manager” and so, asked a bunch of friends and colleagues in the industry. Their replies made me smile and actually read like a handy list of mistakes to avoid when managing an IT project!
Get in touch and tell me the stories that would make you cringe if you appeared on “The Roast of You” and in the meantime … enjoy …
The Roast of A Project Manager
1 – Big Project / Little Experience
A couple of PMs messaged me back to say that they had once bitten off way more than they could chew – the result – they choked!
Matt emailed to say, “It was my third IT Project, the first two had been runaway successes and I thought I could take on the world! I was wrong! I took on a project that was way too complex for my experience level and it very quickly started to teach me lessons. The greatest lesson that I have kept with me throughout my career is to be humble and if I think that something is beyond me or my team – ask for help! Over time my experience and confidence have grown but I am still mindful of not stretching my team’s resources in a pointless show of bravado! The Project Management as a Service sector is like a magic genie of resources!”
I wonder how many other PMs would expect this to crop up on their “Roast Of …”? Matt’s lesson from those early days of his career is one that we can all take note of. In my experience, project sponsors, stakeholders and CIOs are much more receptive to honesty upfront about a capability gap than they are to the news that your inexperience has caused the project to fail.
2 – Lack of Business Case Clarity
Julia messaged me to recall the IT Project that she once initiated with only a basic understanding of the parent organisation’s needs. “It didn’t end well,” she remembers.
“To be fair I was pretty new at this firm and less confident about confrontation than I am now. The brief was so full of holes it could have been used as a colander! These days I’d push the brief back, ask questions, insist on a proper document that detailed requirements. Back then I just thought, OK, I have some information, I’ll have to fill the gaps for the rest!”
Filling gaps in a project’s business case needs is an easy trap to fall into. The best you can hope for is that you nail it but even in this case how much credit do you think you get? You can’t say, “Hey look at this project I delivered despite the lousy brief.” That never goes down well! Worst case scenario is that you get it wrong and the project fails to deliver on its business needs – suddenly the credit for this is all yours!
No, Julia is right, if the brief doesn’t spell out what the project should deliver for the business keep sending it back until it does!
3 – Inadequate Initiation
Malc wrote to me to say that he shudders at the memory of an IT Project which started without a proper starting plan in place. “I mean,” he writes, “Everyone knew what they were doing. It wasn’t the most complex IT Project ever. We all agreed to crack on.”
“Cracks started to appear when two team members got their wires crossed about their responsibilities. Soon roles got blurred, project milestones weren’t defined and so got missed and finally, the delivery deadline date had to be pushed back due to the rather slapstick way that we were operating.”
A project initiation meeting is vital so that everyone sets off in the same direction at the same time! What’s that old saying? Proper planning prevents poor performance .. so true of IT Projects! I honestly think that it could be the most valuable time that you spend on your IT project, a chance to double check that everyone is sure about their role and what the project is meant to deliver.
4 – Scope on A Rope – A Bungee Rope!
At some time, who hasn’t had scope creep rob them of project glory?
Lydia emailed to tell me about the project that taught her the value of saying ‘no’.
“We started off with a tightly agreed project scope, everyone seemed fully bought in and engaged and REALLY friendly. Then a lot of afterthoughts started to surface, a lot of requests for things that would ‘be kind of nice’ to incorporate and each of them had a sound business justification. There was no procedure for assessing scope change requests and as each was fairly inconsequential in terms of budget and delivery date we waved them through. The problem was that although they were inconsequential in isolation they added up and we blew the budget!”
At this point, it’s amazing how all the people who emailed their ideas for bonus project extras seem to disappear leaving you, as Project Manager, to carry the can.
Lydia says, “Once bitten! Every project I ever worked on since has had a procedure for scope change requests and assess them based on their business case, impact on budget and how they’ll affect delivery.”
It was interesting that most of the replies I got referred to mistakes that happened in the dim and distant past. Experience teaches great lessons and I think that, in IT Project Management, we are constantly learning.
I am!
One of my major passions, the Project Management as a Service sector, is a constant teacher and is expanding to levels where there is a solution for just about every issue that could potentially lead to a project failing. It is certainly worth exploring if you have a challenge. Then, if they do ever make ‘The Roast of a Project Manager’, at least it won’t be about you.
Find out more about Project Management as a Service
PS. Looking for a Project Management Read? How about our newly launched E-Book full of Project Management blogs? Download your FREE copy
