Choosing success metrics: are failing IT projects set up to fail?
I met a friend recently for lunch and, quite frankly, he is looking amazing! He joined a gym about a year ago and you can tell! His face is slimmer, he seems to have more energy, looks about ten years younger and, he told me, he has had to buy some new trousers because his old ones were starting to look like “clown pants”.
He should have been buzzing but instead told me how, not only had he not lost weight this month, he’d actually gained a little and so was really cross with himself!
As he raised his hand to ask for the bill I couldn’t help noticing how big his biceps were!!! I couldn’t help thinking that any weight he had put on must be muscle!
This weight gain though wasn’t the only reason why he was beating himself up. That morning, at work he had had a mauling from his Sales Director because he wasn’t hitting his targets. In fact, no-one in his team was anywhere near target and across his industry as a whole, sales were down both quarter on quarter and year on year.
And then, after delivering this gloomy summary of his work life he told me that his accounts had actually brought in more money than the last quarter and his figures were up year on year too. In fact, he’d already beaten his sales for the last 12 months in just nine months of this year.
Wait! What!! He was bucking the industry trend; he was outperforming his colleagues and his competitors, and he had brought in more money than last year already! AND he’d had to sit in a meeting where his boss told him that this made him a failure???
So, what’s this got to do with IT Project Management?
It’s all about choosing the right metrics for success.
Let’s reframe both of these stories.
Needing new trousers because he’d lost inches around his waist, bulging biceps, looking ten years younger, having more energy, a slimmer face … these sound like success to me, but because he was measuring his weight, he felt he was failing. Even using that metric, the data is subjective, muscle weighs more than fat so, given the other evidence, a few pounds gained is a success!
Then at work, he’s overperforming in a down market. He’s achieving greater results than last year, in a shorter time and, taking his quarter on quarter results as a yardstick, he is trending in an upward direction. Again, this all sounds like success in my book. However, because his sales director set arbitrarily high targets, he and his colleagues feel like failures when they should be popping champagne corks.
And WE do it all the time in IT Project Management.
A consultant friend is working with a failing project team right now. He was called in to help turn things around and actually solved their problem in one afternoon!
The team is producing some cutting edge, market-disrupting software. Competitors are following where this team leads, my friend, says that the creative vibe reminds him of what Apple must have been like during the heights of Steve Jobs reign. Imagine that! But the team is failing?
It IS ‘failing’ based on two key measures, delivery date and cost.
OK – they’re quite big failure red flags and they are among the most common causes of IT project fatality so on that first afternoon my friend drilled down.
Yes, the projects were always delivered late but it was because of scope creep. Wait! Another red flag – wow! These guys really are failures!!! No, they’re not! Here’s the thing. As the market changed the team would adapt their project, ensuring that they delivered an end product that was in tune with business need on the delivery date rather than business need when the project was greenlighted – often two different things.
Also, they would listen to end-user and stakeholder feedback along the way and often, when possible, tweak the project to accommodate appropriate requests.
Lastly, they were very keen on delivering bug-free software – their mantra was better to test the software before launch than test the patience of the end-user afterwards. All of this had the effect of delaying projects and, sometimes, it also increased costs.
“To make this project team successful in terms of cost and delivery date,” my friend said to the board on that first afternoon, “from tomorrow we can ban scope creep from projects’ lifecycles altogether.”
“Of course, this means that in future, innovations might have to wait.”
He then listed a bunch of the ‘failures’ that the team had delivered that weren’t in the original project brief and that had delivered revenue, growth and market share, and he catalogued all the market-disrupting ideas that had been accommodated ‘mid-life-cycle’.
He tells the story of how the board seemed to collectively squirm at this thought.
“Or,” he said, “we could recalibrate what we call success, build some contingency funding into project budgets and cut them some slack on time horizons.”
They agreed to do that.
Now, I’m not for one minute saying that time and cost are not important metrics for success. Of course, they are … but this team was succeeding in terms of leading massive business change and growth. The projects they manage are delivering business value time and again. Recall how my friend considers them – “what Apple must have been like during the heights of Steve Jobs reign”. They don’t sound like failures, do they?
The funny thing is, this same project team is still delivering projects within the same time frames and their projects are still costing the same as they did before my friend intervened. The only difference is that they are now considered to be successful. And guess what has happened to morale?
Another thing about failure, that this team and most project teams I work with do, is they learn from ‘failure’. If failure teaches you vital lessons that you take into your next project or team – is it really failure at all? Google’s ‘moonshot factory’ X is set up to expedite failure. You tell Astro Teller at X that his teams are failing he’d probably high five you, hug you and thank you for the compliment.
Sometimes we just set our failure radar wrong. Like when we kick ourselves for gaining weight (that is muscle and makes us look like a beefcake) or when we berate our team for not hitting unachievable, illogical and random sales targets that we set for them.
I suppose what I’m saying is, perhaps we should start to question what we consider success to be. Redefine it in terms that are actually relevant to the climate in which we operate. If time isn’t an issue, then a project hasn’t failed if it’s delivered a week later than it was due on paper. Is it?
When I look at the repeatedly high failure rates for IT Projects, I do wonder whether we are failing because we are setting ourselves up to fail.
I always think a fresh look at your whole portfolio helps assess whether you are applying the right metrics for success and a fresh pair of independent eyes can often see truths that are hidden from you, working in and on your projects day in, day out.
So, take another look at that failing project but with more objective eyes. What’s the end goal that you want to achieve? Is the project really failing when measured against this or is it failing based on criteria that aren’t fit for purpose? Taking a helicopter view and re-evaluating our metrics for success can have a really positive impact across the portfolio – you may identify resources you can buy in from the Project Management as a Service market or you may just decide to give yourself a break, ease the pressure and crack on delivering the business change you set out to achieve.
My metric for success on this article is that it sparks debate, encourages a rethink on what failure actually is and gives us all some breathing space to allow creative thinking and solutions to flow. I’d love to hear from you, especially if that failing project could indeed do with a fresh pair of independent, impartial and objective eyes.