Large IT projects have a notoriously high failure rate, and more often than not the reasons for failure can be traced back to a few simple concepts that were not properly executed. As consulting firms are often key players in large IT projects and have experience with them in a wide variety of environments, we asked several of them to identify common points of failure. To add to our perspective, we also talked to a few CIOs.
GREAT EXPECTATIONS
Getting large IT projects off on the right foot has a lot to do with how they’re perceived. “A great many projects have been doomed to failure from day one because the expectations around them were so out of line,” says Larry Simon, Vice-President and Chief Technology Officer at consulting firm CAP Gemini Ernst & Young in Toronto.
Adds Alden Cuddihey, Associate Partner at Andersen Consulting in Toronto, “Make sure that the system or the technology is not positioned as a panacea.”
The project should start with a clear idea of what must be done and why. “The most important ingredient is a clear vision of how the technology will work in the business and what the business drivers are behind the project,” says Chris French, Partner and SAP Practice Leader at Deloitte Consulting in Toronto. While consultants can help develop a business case, he adds, it really must come from within the client organization.
It takes good communication to set expectations properly. Everyone should have a voice, from users through the corporate IT group to consultants and senior management. Anyone who must supply resources and anyone who will have to deal with change should take part.
Failing to explain a project to end users can be the kiss of death, according to Eric Wilson, Chief Information Officer at Philip Services Inc. in Hamilton, Ont. He recalls one project at a previous employer where users didn’t get enough information about the system and how it affected their jobs. They kept doing things the old way, sometimes defeating the purpose of features in the system. For instance, new orders were refused if they could not be met in a timely way, but salespeople took the orders manually and complained the system was failing. “Ultimately it’s the user base that’s going to make the thing successful,” he says.
Senior management must support the project as well. Successful projects “are the ones where the senior team gets involved and puts their best people on the project, as opposed to the ‘build it and they will come’ approach,” says Wilson.
KNOW WHERE YOU’RE GOING
When he taught project management courses, CAP Gemini’s Simon would ask everyone in the class to remember a failed project. With project phases marked on the wall, everyone would place a card on the phase where their project could have been saved. “Almost 90 per cent of the cards end up in the project initiation phase,” he recalls.
Observes Stephen Goodman, Managing Director of the SAP practice at KPMG in Toronto, “Most of the time projects don’t go off the rails. They were never on the rails in the first place.”
One cause of such trouble is uncertainty. Unless you are doing a research and development project, unknowns should be few, argues Jacques Archambault, Senior Director of Risk and Quality Management for consultancy LGS Group Inc. in Montreal. Goals should be clear, and the technology involved should be well understood. “You have to set the conditions for success up front,” he adds. “Many times when it goes wrong, it was written from the start that it would go wrong.”
Yet Eva Maglis, Vice-President Consulting Services (Operations) at CGI Group Inc. in Montreal, warns against trying to pin down every detail before hiring a consultant. “It isn’t possible to have a large system with fully defined requirements,” she says. “There isn’t a customer on the planet who can do that.” The consultant should work with the customer in defining requirements, says Maglis, and project planning should allow for the fact that needs will change. One way around the problem is multiple releases, allowing for new requirements to be incorporated in subsequent phases.
PROJECT CHARTER & METHODOLOGY
A key element in avoiding the “unknowns” in a project is the development of a “project charter,” also sometimes called a “project statement.” This document should outline what the project will accomplish, how it will be done, who will be responsible for what, who will decide whether work is satisfactory, how change will be managed, and assorted other issues.
Jim Kerr, Division Director for Communications and Information Systems at the Health Sciences Centre in Winnipeg, says most projects that fail do so because they lack a plan. “People don’t really know what they’re building,” he says. “They find out as they go along.” He sees the project charter as “one of the main front-end pieces.” Everyone must sign it, “and that’s the bible.”
Deloitte’s Chris French stresses that the goals in the charter must be clearly understandable and attainable. And it is usually smart to put in the project charter not just what is part of the project, but what is not. If there could be any question whether something is included, specify either that it is or that it is not.
In addition to the project charter, an indispensable aid to careful planning is a well-defined methodology. “Having a strong, proven methodology is probably the most critical factor we see in a large project’s success,” says Terry Davis, Vice-President of IS and Dealer Development at Home Hardware. “Our software development group here operates according to a very strict methodology, and that methodology ensures that there are no missing steps.”
What the methodology is matters less than the fact that there is one. “It’s not important that the company has the best process,” says CGI’s Maglis. “What’s important is that there is a process and people know it.”
WHO WILL BE THE CHAMPION?
KPMG’s Stephen Goodman maintains every project needs a champion, whose role is to sell the project to his or her peers, to push for financing and staff to make it work, and to keep commitment to the project going. Often the champion heads the user department served by the new system. The champion may be part of senior management, Goodman says, but is not usually the chief executive. One thing is sure: the project champion always comes from within the organization. “You can’t hire a project champion,” he says. “They’ve got to be there already.”
And the champion must have a real stake in the project,” adds Jim Kerr, of Winnipeg’s Health Sciences Centre. “It’s not somebody you can spare, somebody who’s kind of good at it. It’s the major stakeholder.” In one current project at the HSC, the project champion is the hospital’s Chief Operating Officer.
Home Hardware’s Terry Davis tells of a case where an IT person made the pitch to senior management for project funding, and after he had left the room the head of the user department commented: “I hope IT doesn’t come back asking for more money.” Davis was shocked, he says, because it was really that executive’s project. Now Home Hardware’s IT group never pitches projects to management – someone from the user department must do so.
ROLE OF THE PROJECT MANAGER
The project manager – often supplied by a consulting firm – is crucial. Consultants usually have extensive experience in managing IT projects. Philip Services’ Eric Wilson says many of the best project managers come from outside. However, the client still needs a project or program manager to oversee the consultant relationship.
Davis warns against dividing responsibility without a single person ultimately in charge. “It’s very easy to try and carve up a large project into different pieces and it’s tempting when you do that to let the different leaders of the different parts operate somewhat independently.” That doesn’t work, he says. “You have to have a strong overall project manager.”
At the same time, one person cannot know everything about a large project. So while the project manager needs an overall view, the team must be set up to support distributed knowledge feeding back to a central spot. “If you try and do it so that a few people know everything, forget it,” says CGI’s Maglis.
One of the great enemies of bringing projects in on time and on budget is scope creep – the tendency of the project to gradually take in more development group here operates than intended. A clear project charter goes a long way toward containing scope creep, but it may still happen. Some creep is inevitable – needs may change before the project is complete, or it may simply become obvious that something is needed that hadn’t been thought of.
“There’s nothing implicitly wrong with scope creep,” says KPMG’s Goodman, “as long as people understand the impact it’s going to have on the project.” But scope creep has to be kept under control, which is why one important trait in a project manager is the ability to say no.
THE CLIENT/CONSULTANT TEAM
The project manager, no matter how competent, still needs a good project team, including consultants and the client’s own staff. One sign of a really good client-consultant relationship is that it’s hard to tell who works for the consultant and who works for the client. “The most successful relationships are when clients and consultants work together in partnership, as one team of people,” says French at Deloitte.
Getting the right people assigned to the team is not only critical to success but also a potential minefield. An important project needs the best people in the affected departments, and success often depends on taking people away from their regular jobs for the duration. “A lot of times the project suffers because people are going back and forth between the project and their regular jobs,” says French.
“It’s very difficult for departments to free up their brightest and best,” says KPMG’s Goodman. “Unfortunately that’s exactly the person you need.” Often the best solution is to put the top people to work on the project and backfill their regular jobs with others. Sometimes this works out better than might be imagined, he adds, because people who move to the project gain experience and return to more senior roles, and their temporary replacements become permanent.
Another key HR concern on large IT projects is keeping everyone committed, in spite of the long hours such projects demand. One strategy is to employ incentives. Goodman tells of one recent case where KPMG and at least two other consulting firms were involved in an SAP implementation. All staff and contractors working on the project were promised bonuses if it came off successfully. A key, he says, was that either everybody would get the bonus or nobody would, so there was no point in trying to pass the blame or engage in turf wars. The result? The project was “very successful”.
KEEP COMMUNICATING
Throughout the life of the project, users and IT people should be in constant consultation. This doesn’t mean IT simply telling users what is happening – it means everyone having input.
Periodic reviews, involving users and service providers, give us a picture of what is really happening, according to LGS’s Archambault. He adds that the goal is not to spot what has already gone wrong, but to identify things what might go wrong and stop them from doing so. That might mean resolving a problem before it becomes critical, or in some cases finding additional resources to cope with an issue that turns out to be more complex than expected, or even choosing to reduce the project’s scope. The key is recognizing the problem soon enough. “The incapacity to recognize that there’s a problem is often more costly than the problem itself,” says Archambault.
These regular reviews can go a long way toward keeping a project on time and on budget, says Home Hardware’s Davis. If the project team must report monthly to an oversight committee of senior management, there is “a strong incentive for them to keep an eye on the clock.” The reporting should be to as high a level as possible, he adds. It’s too easy for IT people to explain away delays to the CIO with phrases such as “you know what it’s like”.
Talking to consultants and CIOs about the elements of IT-project success, the same things come up over and over. Senior management commitment, involving users, realistic expectations, regular reviews, good project management – and perhaps most of all, communication. As one of our consultant commentators put it, “You can never communicate enough. And no project ever does.”
The Role of Consultants on Large IT Projects
IS staff at Home Hardware in St. Jacob’s, Ont., thought they were doing well on a major IT project, but consultants from Oracle Corp. pointed out some things that weren’t up to scratch. VP of IS, Terry Davis, retained Oracle Consulting for quality audits because, he says, “sometimes we’re a little too close to a project, and sometimes we don’t measure the quality as stringently. It’s human nature to go a little easy on yourself.”
Besides making those tough calls, consultants also bring a fresh perspective to IT projects. “They can be the ones that push our people hard and challenge why we do things in the way we used to,” says Eric Wilson, CIO at Philip Services Inc. in Hamilton, Ont.
“Consultants play a very important role in helping clients think about new ideas, bringing experiences from other organizations to the table, so that the project doesn’t just end up being a further automation of the old way of doing things,” agrees Chris French, Partner and SAP practice leader at Deloitte Consulting in Toronto.
What kind of a consultant should you hire? Says Larry Simon, Vice-President and Chief Technology Officer at CAP Gemini Ernst & Young in Toronto, “The client has to have a clear understanding of whether they’re looking for specific technical skills, point skills to fill certain gaps, or more general skills and advice to solve the bigger problem.” The main strength of technical consultants is their detailed knowledge of certain areas of technology; their role in a project is usually helping implement particular software. The role of the management consultant is more at the strategic level.
What can a consultant offer? “Experience,” says Alden Cuddihey, Associate Partner at Andersen Consulting in Toronto. “Having done it before.” Few businesses do the same project, or even highly similar projects, over and over. Consultants do, so they can bring to a project their experience from similar ones in the past. Consultants can also provide technical skills that most companies would take years to develop on their own.
But nobody knows your business as well as you do, so neither client nor consultant should assume the consultant knows best. “I will never be as good at the customer’s business as the customer,” says Eva Maglis, Vice-President Consulting Services at CGI Group Inc. in Montreal.
An existing relationship is often a factor in choosing consultants. Davis says Home Hardware tends to use firms that it already has a relationship with. For instance, he felt that on a project involving Oracle software, Oracle Consulting would have an extra incentive to make sure everything went well. In another case he chose KPMG for an information security audit because it is also Home Hardware’s corporate auditor.
That makes sense to Maglis, who says respect and trust are key elements in a good client-consultant relationship. But, she adds, you almost have to go through the cycle once to build it.
Jim Kerr, Division Director for Communications and Information Systems at the Health Sciences Centre in Winnipeg, looks for experience in the people who will actually work on the project. “Some people have just been hired into a consulting firm, never done anything before, but charge me the big bucks,” he complains. “No thank you.”
Which leads us to the last point. Make sure you get what you think you’re paying for. Some consulting firms will trot out their project stars when the deal is being hatched, only to have them disappear when the real work is about to begin. Getting around this one may be tough, but you certainly have more leverage up front during negotiations than you do when the project is under way. That’s the time to get some assurances.
Grant Buckler is a freelance writer specializing in information technology and IT management. He is based in Kingston, Ont.
