Why projects fail

Catherine Pickering, EMC

---

There are two sides to any business, something we could equate to a ship. A seafaring vessel needs a lot to keep it afloat, from regular maintenance to skilled staff and stern officers. But that ship will not go anywhere without a destination - and with no destination, it has no real purpose.

Enter the project. Devised in the middle of the previous century, projects became a way to elevate certain goals and priorities above the minutia of staying above the water. It's a destination: a call to action that aligns the resources and skills of the vessel towards a common goal. In business parlance, that goal would be towards driving revenue, reducing costs, or some other manoeuvre that keeps a company in the game, preferably winning.

But for all their critical importance, projects fail more often than succeed, a truth that holds fast particularly in the enterprise technology space. And the bigger they are, the harder they fall. According to a 2010 McKinsey report on the topic, large technology projects on average overran their budgets by 66 percent and schedules by 33 percent. Yet, they still managed to fall considerably short of the objectives. So why do projects fail?

The most common mistake is lack of proper scoping and that all the parties involved understand what is meant by the scoping," says Dr Catherine Pickering, senior solutions principal at EMC South Africa. "You're not just working with IT, but checking with business as well."

It's a classic case of left hand/right hand. Communication lies at the root of most project failures, particularly in environments where the technology and business visions aren't aligned. That alignment is usually a matter of a company's culture, but the real glue is always planning, notes George Ambler, VP executive partner at Gartner South Africa. He defines it as 'putting the wood behind the arrow' and says proper planning starts with the business objectives: "Planning requires both IT and business skills, but you need to firstly understand the business case for the project. See what part of the business will benefit and find an executive there to sponsor the project. Identify the skills and subject matter experts in the business, and formally allocate their time to a project. Allocate the appropriate resources. It's about getting the buy-in, people and resources before going ahead. If you don't get that, don't start the project."

Poor planning is what distinguishes the failures from the successes, says Marius Visser, executive for Business Solutions at Metacom: "You can distinguish the companies with a strong business analysis and architecture team. That difference is always apparent."

But, he adds, it's not just about planning. Appreciating what roles everyone will play is key, yet too often departments such as IT are lumped into pure facilitation positions: "The business must understand that the role of IT is not just an execution arm. It must be pulled into the strategy of the company."

Like our ship, a project needs a captain and a champion, a person of power who can make the tough decisions and fight for what the project needs: the executive sponsor. Although the tendency is to lump the CIO in this position, that executive should be drawn from the part of the business that will benefit from the project. As such, it's important that technology projects be framed as business projects, says Ambler: "Executives see value when you execute on their most strategic priorities. The job isn't done when the technology is installed, but when the project delivers the desired business outcomes."

But an absentee sponsor is also often why projects fail to deliver and securing a sponsor is a tricky task in itself. Why is this such a daunting role to fill?

You're not just working with IT, but checking with business as well.

Catherine Pickering, EMC South Africa

"The business executive tends to want to step away from the sponsor role, because it's onerous and you take a lot of risks in the decisions, often involving technology they're not comfortable with," says Visser.

The CIO acts as the bridge here, creating technological context for the sponsoring executive. Pickering says the commitment and responsiveness of the executive hinges on communication and collaboration with the CIO: "The CIO is a key player, the go-between for the business executive and the project developers. This ensures that technology is understood. But in my experience, typically technology is not the main cause of project failure. Often it's a lack of communication, not having the correct skills on board and a lack of project management."

Yet even the best-laid schemes can go awry, as Scottish poet Robert Burns wrote. Truthfully, there is no recipe for ICT project success - other than experience. While companies often fall short on the planning stages, another flaw is not knowing when to stop.

"Most organisations tend to carry on with the project, even when the sponsor goes missing," says Ambler. "When you do that, the technology is installed, but the goal is not obtained and the business blames IT for the failure. Best practice organisations avoid this by withdrawing their staff when the sponsor goes missing."

Companies also habitually skip on the evaluation afterwards, yet this is perhaps the only place where they can truly grow their culture towards more successful future projects. But often it's cost and time pressures that make them skip this vital step.

Says Visser: "The teams are typically under unbelievable pressure and often executives don't understand what is required. So the projects end up being late. By the time the team is done, they are months behind on the next project."

Still, answering the questions of how successful a project was or what caused it to fail is the differentiator between future success and failure. Ambler maintains it should be done several times: "After a project has been executed, have a benefits harvesting meeting. It should happen multiple times after a project lifecycle. So six months, a year and again two years if necessary. The same committee that approved the project should get together again, look at the business case and see if they achieved the objectives. If not, find out why: is it because the technology was a bad choice? Was training lacking? Is the staff not using the system because it's too complex? Having that meeting is for the sole purpose of learning, not pointing fingers or assigning blame. What you want is to learn and agree on actions to take."

Not only do evaluations build the correct culture, but they create the opportunity to still reach those goals. For example, what if a failure can be remedied by adding some extra staff training? But a fear of failure and blame can stand in the way of this.

"The planning and validation phases tend to get neglected. Looking at outcomes is also often skirted," says Pickering. "It's a bit of a head-in-the-sand approach."

This article was first published in Brainstorm magazine. Click here to read the complete article at the Brainstorm website.