Risky business

According to Standish Group, only 34% of IT projects are successfully implemented, with the rest either over running, going over budget or being abandoned.

  • E-Mail
By  Neil Denslow Published  June 1, 2003

I|~||~||~|The goal of any project manager is to bring in the project on time and on budget. However, despite their long hours of fervid activity, this is rarely achieved. According to Standish Group, only 34% of IT projects are successfully implemented, with the rest either over running, going over budget or being abandoned.

While 34% seems low, it actually represents considerable progress — only16% of projects were successfully completed in 1994. Project management is therefore improving, but too many projects are still failing at great cost. The Standish Group estimates that in 2002 the lost dollar value for US projects alone was US$38 billion with another US$17 billion in cost overruns — a total project waste of US$55 billion against US$255 billion in project spending.

The main reason for the failure of projects is not technology though, but people. “No matter how the technology improves, humans remain a variable that you cannot control. That’s the reason why many of these projects slip from their targeted budget and timeframe,” says Abdullah Al Khadi, project director, HyperLink.

People problems are most often apparent in projects that are solely generated by the IT department, as they often fail to consider the real needs of the business or the end users who will work with the system. The numerous failed customer relationship management (CRM) implementations show this, as many were driven by IT departments that wanted a CRM system solely because it was fashionable.

“[As such,] when they got the piece of software live, what they had was a piece of software. They didn’t have a functioning CRM system. The end users don’t know what it was, didn’t want it and didn’t know how to use it,” says Jim Massey, director of professional services, GBM.

Successful projects, by contrast, are ones where all sides of the organisation are involved. This is key, as only the business side will be able to undertake the business process re-engineering needed in order to make full use of a system. “When you are implementing something like SAP or Oracle, in many situations you will see that the operating procedures of the company need to be changed. But this is something that the management often fails to take note of,” says Mihir Chatterjee, senior manager, information risk management, KPMG Bahrain.

The reason that management makes this mistake is because the treat the implementation as strictly an IT affair that has nothing to do with them. This though all but guarantees failure. “The moment management treats a project as an ‘IT project’ they dig the grave for the project itself,” says Chatterjee.

Aside from re-engineering business processes, the business side also needs to be involved in a project to train the staff who will use the new system, as this the only way the company will be able to get the full benefit out of it. Project management therefore needs to encompass the management of people and change, as opposed to just a series of tasks.

“People throughout the field of IT projects have come to realise that a successful project depends on the management of the people and the culture within the organisations, and not just managing the tasks as deliverables and the assignment of resources to tasks,” says Al Khadi.

“The aspect of psychology and managing the cultural changes within organisations is really affecting the success rate of IT projects,” he adds.

||**||II|~||~||~|Managing change across the organisation is clearly a wide-ranging remit, and this can only be achieved if a high level business sponsor supports the project. The sponsor will be the one that drives the project along, making sure that the project manager has both the resources and money needed to make it happen. “It’s key to the success of a project that you have a sponsor with the authority to move things,” says Massey.

However, projects are often undermined because there is no clear sponsor. Instead the management initiates the project, and then leaves it to the project manager or outside consultants to make it happen. “In many situations, we don’t find a specific project sponsor who understands his responsibilities or takes ownership of the project,” complains Chatterjee.

To ensure that this sponsorship is formalised within a project, companies need to form steering committees that will provide leadership for the project and monitor it. “It’s of foremost importance for big IT projects that there is a steering committee consisting of IT and users at a senior levels,” says Chatterjee.

“[However,] we often find that those steering committees are never formed. Or if they are formed, that they hardly ever meet, and even if they meet, they rarely take ownership of the project,” he continues.

When a steering committee is successfully established, its first task must be to agree on the scope of the project. This can be done in a project definition workshop, where the roles of the three main parties in the project — the customers, the suppliers and the end users — should also be agreed on. “Having a project definition workshop upfront is the very first thing you do, to define that [the scope] and then to define the responsibility of each of the three groups,” Massey explains.

Of the three groups, it is often the end users that get forgotten. However, without their participation the company is likely to be lumbered with a system that doesn’t the business’s true needs. “Sometimes, it’s obvious that there has been insufficient end user involvement,” says Mohammad el Shanti, business development manager, HP Services.

Once the scope of the project has been agreed to, and responsibilities have been assigned, the project manager also needs to consider what will happen when things go wrong. This is almost bound to happen, as even on a small project there will be any number of different tasks that need to be completed. “You need a risk management plan for any project you are doing,” says Lorcan Malone, business development manager, Gulf States, EDS. “You want to identify your risks and keep those up to date throughout your plan,” he adds.

||**||III|~||~||~|In assessing risk, the project manager needs to consider both the likelihood of the risk occurring, and the impact it will have on the project. For instance, one possible risk would be equipment arriving late. The risk of this happening depends on the nature of the equipment and the supplier. If, for instance, it is some PCs from a local supplier, then the probability of them arriving late is quite low, and it may not matter greatly even if they do turn up late.

However, if it is specialist equipment with a three or four month lead time, then there is a much higher chance of delay. In which case the project manager needs to assess what impact this will have on the project. If it is also high, then a contingency plan needs to drawn up. “You really want to manage the high probability/high impact risk and have a mitigation plan for each in place,” advises Malone.

Late deliveries, though, is just one example of risk. Other dangers include key people resigning, budget cut backs, changes to the project and a host of other possibilities. However, these risks, and the need to prepare for them, are often forgotten about because of the day-to-day demands on the project manager. “The entire focus is on managing the project, [and] there is hardly any focus on managing the risks that keep on arising throughout the project,” says Chatterjee.

As such, risk management is increasingly being taken away from the responsibility of the project manager, and given to a third party. This can be either an outside consultancy or to a project management office (PMO) within the organisation.

This structure is becoming apparent both worldwide and within the region, as it has helps to ease friction between the clients and the implementers. “This third party acts on behalf of the client to facilitate and coordinate activities especially in project management,” explains Al Khalid.

However, even with a third party involved, the business side still needs to play a part in the project. “The PMO cannot replace the business knowledge of the users or teach them how to use the system, but it does provide a better implementation environment for the project to succeed,” says Al Khalid.

The chances of success can also be enhanced by taking a more realistic view of what is possible in one project. Numerous IT projects fail because their sheer size prevents adequate planning and risk management. “If it’s a project that goes out for years and has got many things to do, people just can’t get their minds around it,” comments Massey.

As such, there is a growing trend towards making projects smaller. Either by breaking larger projects into smaller inter-related projects or just by limiting what needs to be achieved from the start. Jim Johnson, chairman of the Standish Group, says there have been “major improvements in reducing projects’ scope and then being able to manage them better.”

“The trend now is definitely to break it all down into chunks of distinct projects, and build from there. It’s definitely improving, and I think it is improving in the Middle East and globally,” agrees Malone.

The advantage of breaking projects up like this is that they instantly become more manageable. The project manager can more easily identify all the tasks that need to be done — as well as the risks — and then plan accordingly. Limiting the scope of the project therefore greatly boosts the chances of success, while also keeping cost and time scale under control.

“You want to minimise the scope,” advises Johnson. “One of the most successful techniques is to keep minimising, questioning why things are being done and taking things out,” he explains.

This is the best way of avoiding “scope creep,” whereby the goals of the project continually expand making the project impossible to finish. However, the project plan does needs to be flexible as change in the goals of the project are all but unavoidable.

“No project that I’ve ever seen hasn’t changed,” says Johnson. “You need to set up for change, and you need to understand why you change things. What is not often in place is rationalisation for change and what affect the change will have the project,” he adds.

The project may need to change for a multitude of reason. For instance, the business may have changed rendering part of the project unnecessary, or the budget may need to cut because of cutbacks. However, while these necessitate change, the business needs to be aware of the trade off between, the scope of the project, the time scale and the cost. “You can change any of those, but you affect the other things,” says Massey

“You can make the time scale shorter, but you will have to compromise on the scope of the project and probably have to spend more money and put more people on it. Or you can do the project cheaper, but it will probably take longer and have less function…. It’s balance, and when you make change you have to understand what you are trading off,” he explains.

The possibility of needing to make changes is therefore yet another risks that needs to be identified. “Everything comes back to risk management,” says Malone. “[However,] if you identify your risks properly, and you are manage those risks, then you are well on your way to be successful,” he adds.||**||

Add a Comment

Your display name This field is mandatory

Your e-mail address This field is mandatory (Your e-mail address won't be published)

Security code