Taking on a new IT project is likely to trigger varying responses from IT and business executives. Highly unlikely reactions, however, are a slight shrug of the shoulders, or a settling back with a self-satisfied smile that says: "No problem, it's in the bag."
IT projects large and small present organisations with myriad challenges. Apart from the biggest issues ? time, money and value ? any number of unforeseen hurdles await those complacent enough to simply shrug or sit back.
A 2012 report by McKinsey is but one source of advice on what organisations should be doing to deliver large-scale IT projects on time, on budget, and delivering value. The recommendations are nothing new: manage the strategy and stakeholders, master the technology and content, build effective teams, and apply proven project management practices.
The research contained in this report, however, is bone-chilling. McKinsey reported that half of all large IT projects ? defined as projects with initial price tags above US$15 million ? run 45% over budget, 7% over time, while delivering 56% less value than anticipated.
While projects of this magnitude are probably undertaken by a handful of local enterprises, they're not uncommon in certain sectors of the economy.
So, how does South Africa's project management expertise and performance stack up?
According to a report published at the end of last year by industry body Project Management South Africa, the country fares fairly well. In fact, the IT sector outperforms the services, mining and manufacturing industries. Not by a huge margin across all measures, but well enough not to cause panic.
According to the research, 59% of IT projects were considered successful. This compares well with the average across all industries of 55%. The 'challenged' (29%) and 'failed' (12%) IT projects are also lower than the study's overall rate of 31% and 14% respectively.
Not a pretty picture
Despite the comparative performance appearing favourable, there's hardly cause for celebration.
KPMG's Management Consulting director Walter Palk says although he has witnessed a greater degree of governance and accountability around failed IT projects, he's still concerned about a seeming inability to learn from past mistakes.
"I think we've lost the art of knowing when to cancel a project, even when it's in pre-feasibility phase," he says. "I see a lot of projects that are rebadged, repackaged, and renamed. By and large, the same objective is trying to be achieved under a different banner. Organisations don't seem to be learning some of the lessons."
Not surprisingly, he echoes the McKinsey recommendation to adopt and execute "rock-solid project management skills", as failing to do so is often the cause of project failure.
Stefan Schoeman, management consultant at Bizmod Consulting, points to another common failing: a disconnect between the IT and business teams.
Again, this is not news to anyone involved on either side of the table, as many a boardroom battle has been fought over control, or blame, for IT projects that are expected to help the business be more effective.
Schoeman suggests that mistrust stems from IT not clearly understanding what the business needs, and business executives not clearly understanding the technological limitations. Factor in the ever-present changes and problem-solving that takes place, and you have a recipe for disaster.
"Generally what happens is, because of the speed at which things change dynamically around an IT project, business comes in at the tail end of those changes," he says. This sidelining then causes the business executives to lose interest once they no longer feel part of the process.
The blame game
Schoeman adds that the blame game is not a one-way street, with business executives often guilty of moving on to other matters once the project team has been briefed.
One solution is to second someone from the business to the project team, while also adopting an agile or lean approach to the development life cycle.
Generally what happens is, because of the speed at which things change dynamically around an IT project, business comes in at the tail end of those changes.
Stefan Schoeman, management consultant, Bizmod Consulting
Schoeman says this has the advantage of rolling out features incrementally, with the business representative on hand to make calls on the roll-out or problem-solving. "If something happens that can't be bridged in this team, that person should have the discretion to say, 'Stop, I need to take this back to the business'."
KPMG's Palk suggests this conversation and approach is directly linked to an organisation's ability to assess its project management maturity.
"That's not about doing a risk assessment, it's about honestly asking, 'What is our track record of delivery?'" he says. "When things have gone wrong in the past on other projects, ask why. It's about being honest about those issues and then building it into the project approach."
Undertaking such an 'early warning' process is not a 10-minute discussion, he says; more likely an intensive workshop to get the people involved to make a true assessment of potential pitfalls or failings internally.
"I always say to my clients, 'Have you looked in the rear-view mirror? Why do things go wrong in this organisation? What causes friction and what causes pain? Let's be honest about that.'"
These may not always be comfortable questions to ask. But rather that than facing the far more hostile questions an IT executive and his team will have to face if the project does fail.