Page 69 - Straight Talk On Project Management IV

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