Interesting perspective this week from my friend and fellow IT Project Leader Malc.
Malc emailed to tell me that he had recently reframed his team’s thinking on post-project delivery analysis. What he has done is pretty interesting and he says it is adding demonstrable value to the process.
“We always used to look back at what worked well during a project’s lifecycle but not in nearly as much depth as what didn’t work so well. In fact, we’d be more negative than that, especially if a project had failed to meet a budget or a delivery date we’d really drill down on what went wrong! If I put a ratio on this, I’d say it was weighted 5:1 in favour of looking back at what and how we messed up. We told ourselves that it was vital for learning, that we’d emerge stronger and I guess we did, a little. Actually though, we were mostly really bringing ourselves down.”
I wonder how familiar this sounds to you? Perhaps, it’s human nature to focus on the negative, perhaps we are hard-wired to believe that our greatest lessons are in the mistakes we make.
There may even be an evolutionary reason, one of the authors of a study ‘Bad Is Stronger Than Good’, Professor Roy Baumeister wrote that those who are “more attuned to bad things would have been more likely to survive threats and, consequently, would have increased the probability of passing along their genes.” The article goes on, “Survival requires urgent attention to possible bad outcomes but less urgent with regard to good ones.”
I think that you can learn a lot from dissecting the debris of where things didn’t quite go to plan after an IT Project. Malc and his team have not abandoned this practice altogether, but they have shifted the fulcrum so that greater prominence is given to what went right and discovering the reasons for that.
Malc continues, “A year ago me and my team emerged from a post-mortem session feeling really sorry for ourselves. A project hadn’t hit the bulls-eye, mainly because we’d not been strict enough managing scope creep requests and then, having agreed to changes, we had not been clear enough managing stakeholder expectations about their consequences. All of this conspired to quickly burn through a generous contingency budget, made the project late and one of the changes kind of watered down one of the original key business objectives of the project. Despite the fact that all the problems could be attributed to the stakeholder requests, all the scope changes were within our management and we had to take the blame rather than pass the buck. It was a bitter pill to swallow and we all went home feeling thoroughly cheesed off. It was a Friday night, not a great way to start a weekend!”
It’s true isn’t. Whenever I’ve put my heart and soul into a project and it hasn’t delivered in line with my hopes and expectations I find it hard to be cheerful. I find my mind drifting back to what I could have done differently. I wonder about how I might act or think differently; if I’m not careful it can take over. Who hasn’t woken in a cold sweat in the middle of the night when something hasn’t gone to plan!?
It was feeling like this that got Malc thinking.
“There were five key business objectives on that IT Project. Four of them delivered in line with the brief and they would have been delivered on time and within budget, but all five objectives were interdependent. The fifth objective was the one delayed by scope creep requests, it was here where the budget overrun had happened, it was this that delayed overall delivery of the project. Suddenly, I started to see the project in a different light. Four-fifths of the business objectives had been met and independently they would have been on time, within cost forecasts.”
The project had set out to streamline the IT operation across stock control and procurement, production, transport, customer services and finance, the plan being to create a transparent system whereby any team member could instantly get a real-time view of any part of the business operation, ie, The transport manager could check stock levels, sales administrators could check customer accounts paid in full before processing new orders, finance could check delivery notes for discrepancies before chasing late invoice payments. It was only really the accounts team that had “thrown a few spanners in the works” and ironically because of the odd tweak here and there it this part of the project that was not syncing with the dashboard Malc and his team had created.
“In isolation, four-fifths of the project delivered successfully! That’s an 80% success story!” Malc started to tell himself.
Actually, in delivering these ‘successful’ parts of the project the team had done some great work.
1 – They had accessed resources from the Project Management as a Service market that had created efficiencies that had actually mitigated some of the delay caused by the scope creep from the finance department. Thinking about this some more Malc believes that the project would have been perhaps another week or two late had it not been for these innovations. In naval gazing over what went wrong, this had been completely missed. These were repeatable outsourcing strategies that could be used again in the future.
2 – There had been some really exciting collaboration with stakeholders outside the IT department to make sure that at each milestone the project was on track to meet needs. All departments had previously been operating as silos but now, not only were they liaising with the IT guys, they were communicating better with each other and they could check in an instant on parts of the business operation that previously would have meant waiting for an email or telephone reply.
3 – Malc noted that a couple of junior members of his project team had shown some real initiative and suggested improvements to the firm’s stock control and procurement systems which to cut a long story short, meant that the company would carry less stock by automating purchasing to reflect orders received. Malc realised that other parts of the process could be automated to create similar efficiencies for the business.
As the night went on Malc’s mood changed from one of melancholic despair to feeling re-inspired. He called each of member of his team to share his thoughts, the result being that everyone came back in to work on Monday in a better frame of mind than they’d left for the weekend.
“From that day we vowed to concentrate more on what went right and seek to repeat it rather than beat ourselves up about what we did wrong.”
Malc and his team are not rewriting history to cast themselves in a better light, what they are doing is separating negative perceptions like “the project failed” from what actually happened, i.e. most of what the team did here worked really well and should be repeated.
Travis Bradberry, an emotional intelligence and writer, wrote an article for Forbes in which he recommends separating fact from fiction when considering negative events or thoughts, indeed he suggests actually writing down what you’re thinking.
“When you find yourself believing the negative and pessimistic things your inner voice says, it’s time to stop and write them down. Literally, stop what you’re doing and write down what you’re thinking. Once you’ve taken a moment to slow down the negative momentum of your thoughts, you will be more rational and clear-headed in evaluating their veracity. Evaluate these statements to see if they’re factual,” says Bradberry.
This is what Malc did. His team felt their over budget and late project, that had fallen short of a key objective meant it was a failure but when he committed his thoughts to paper that evening he started to see positive after positive staring back at him from the notepad.
He also realised that he had to be more assertive when considering scope change requests.
There are many studies that show that a positive outlook is better for your health. Who knows, maybe Malc is right, maybe the lessons for repeatable success lie more in what we got right than what we got wrong.
Whatever the truth, looking for the occasional silver lining certainly feels better than looking for the clouds all the time.