Subscribe

Why projects fail

Despite their incredible value for business, why do IT projects tend to crumble or fall short of their objectives?

James Francis
By James Francis, Ghost Writer, Copywriter, Media Hack & Illustrator
Johannesburg, 15 Sept 2015
Catherine Pickering, EMC
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?

It's in the planning

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."

Relationships

There are no IT projects

As IT has moved from a support role and towards facilitating key business goals, IT departments themselves must adapt.
The most common problem, says Gartner's George Ambler, is that IT teams confuse routine maintenance with resultsorientated projects.
"There's no such thing as an IT project. Maintenance is important and necessary, but it's not business value. Often when IT teams talk to executives, we talk about all the maintenance we're doing. But the executives really don't want to discuss maintenance - that's why they pay your salary. They focus on driving revenue, reducing risks and improving cost structure. You don't pay the head of sales to maintain the sales force, but to drive revenue."
EMC's Dr Catherine Pickering agrees: "There is always that feeling that keeping the lights on is the most important thing.
Although important, if a company doesn't grow through strategic projects, then is there even going to be a company to maintain the product?"

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.

Don't just hand it over

Be careful to not hand over too much to an outside solutions partner, says Metacom's Marius Visser: "You cannot abdicate the role of the CIO and understanding technology in the business context to a third-party installer. Very often it becomes a safety net - I get the best systems integrator and therefore I have no ownership of the failure and accountability of this project."
This risk-aversion does quite the opposite: the IT teams don't take ownership of the technology and looking after business needs. It also ends up wasting a lot of the IT budget and places planning for future projects at risk. Basically, if a company wants to pass the pressure for its projects to outside sources, it's making room for future failure.

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."

School of hard knocks

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."

The to-do checklist

Want your project to succeed? You'll need to do the following:
* Make it a business project to help understand its value.
* Plan well with all stakeholders, and allocate resources and skills.
* Assign a sponsor executive whose department will benefi t from the project.
* Keep communication open between stakeholders and empower them with relevant knowledge to make tough decisions.
* Don't be afraid to pull the plug.
* Don't become overly reliant on outsourcing. The core team should be in-house.
* Revisit the project several times to gauge its success. Don't be afraid to investigate failure.

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.

Share