Staking one for the team

Two thirds of all information technology projects fail. That grim statistic comes from The Standish Group International Inc., a West Yarmouth, Mass., consulting firm specializing in project performance. Standish Group defines failure as missing any of three targets — the budget, the deadline or the

defined business requirements — by 20 per cent or more. The researchers add that 15 per cent of all IT projects fail completely, meaning they get cancelled before completion.

Why? The Standish Group has identified five main reasons. Failed projects lack clear business objectives, executive support, user involvement, good scope management — or experienced project management.

IT has struggled with project management almost since the first computer was built. In fact, the five major reasons for project failure are all related to project management. Hank Summy, general manager of the Canadian office of Sapient Corp., a Cambridge, Mass., consulting firm that helps clients plan and manage IT projects, maintains that obtaining executive support is part of a project manager’s job. Making sure the business objectives are clear and managing the scope throughout the project’s lifetime are also vital elements of running a successful project, and involving users — along with other key stakeholders — is essential.

“”Most projects fail not due to technical reasons but mostly due to human reasons,”” says Vijay Verma, a group leader at the Triumf national particle and nuclear physics laboratory in Vancouver and an internationally known consultant and trainer.

Verma says any project’s success starts with a project champion — someone who wants the project to succeed and has the organizational clout to make it happen. These champions are found in an organization’s steering committees and project councils, he says.

One of the first things a project manager must do on any project, Verma says, is negotiate for resources. This can be difficult, he warns, because project managers have a lot of responsibility but not much direct authority, so they must find ways to get what they need to make their projects work. Power and politics, he says, are not much discussed as factors in project management but are very important.


That includes who is on the project team. It’s natural for a project manager to want the most qualified people, says Robert Black, a Toronto-based project management contractor and president of Project Masters Inc., but they are not always available. And sometimes the “”top guns”” aren’t the best people to have on your team. For one thing, they’re more likely to be pulled off your project before it’s finished.

“”I like the underdog sometimes,”” says Black. “”The guy who hasn’t really had a chance to shine on a project — give him a chance.””

Many IT project teams are dispersed or “”virtual,”” and Claire Sookman, principal of Virtual Team Builders in Toronto and a specialist in managing dispersed teams, says the best team members — and the best leaders — for such teams are people who can work independently, but are also team players who can communicate with others.

Another important first step is establishing a clear understanding of the project’s goals.

“”Be very clear about what the project is setting out to do — what it’s going to deliver and what it’s not going to deliver,”” advises Black.

Summy says Sapient’s first step in any project is to bring the project team and key stakeholders together for an intensive workshop called a fusion. The workshop usually lasts a week, preceded by two weeks of preparation, he says. Out of this workshop comes a set of business objectives — and Summy stresses these are defined in terms of business results — a communication plan and a status reporting dashboard that works for the particular organization. Out of the fusion also comes “”a tremendously congealed team of people that are very comfortable working together and have a common purpose,”” Summy says.

Team building starts at the beginning of a project and carries on throughout. When Shell Canada joined with IBM Canada Ltd. in 2001 to build an electronic customer-access system for Shell, the key aspects of the

project were leadership, methodology, communications and team building, according to Roger Milley, IT eBusiness leader at Shell and one of the project leaders.


The joint Shell-IBM team held “”all hands”” meetings, brought in lunch to save team members the trip out to eat, and organized after-hours gatherings such as bowling parties — “”a very cheap team-building event,”” according to Sharon Hartung, an IBM project manager who co-managed the project with Milley.

Shell and IBM also made a rule that everyone in the dispersed project team should have face-to-face contact at least every six weeks for the life of the project. Without this, Hartung said, “”after about five or six weeks we found some of that communication would start to break down.”” Between face-to-face meetings, the team relied heavily on videoconferencing, as well as weekly status calls with key stakeholders.

Summy says an “”incredibly robust communication strategy”” is essential to project success. Sapient relies on electronic dashboards for monitoring project status and regular forums for dialogue about team members’ and stakeholders’ concerns.

For virtual teams, Sookman stresses the importance of creating a “”team operating agreement”” at the outset. This defines ground rules, such as how team members will communicate, how often they will check their e-mail, that meetings are to begin and end on time, and how the team will handle conflicts.

Scope creep — unplanned additions to what the project is expected to deliver — is a classic headache for project managers. Summy says the first step in dealing with scope creep is to define project objectives in clear business terms at the outset.

But some changes are inevitable, and the key to keeping them from derailing the project is to recognize that they are changes and understand their impact.

“”Many projects fail simply because (project managers) don’t even recognize that what they are being asked for is a change,”” Summy says.


Another vital strategy is identifying risks up front and preparing for them, he adds.

For instance, is there a possibility the demands of a new system might lead to a need for more network bandwidth? If so, consider at the beginning what you would do if that happened and what the impact on the overall project would be. Another scenario: if a telecommunications carrier fails to install communications links on schedule, what happens?

By identifying risks and preparing backup plans early, Summy says, project managers can respond quickly when something goes wrong.

On a project of any size, Black says, you should assume things will go wrong. Team members will leave, technical glitches will arise. The project schedule should make allowances for these things. Teams that anticipate things going wrong will be in the best position to deal with the hurdles.

If a project manager can’t avoid a tight deadline that leaves no room for eventualities, Black adds, he or she should at least point out that the schedule will only work if little or nothing goes wrong, and present a list of things that might go wrong.

Then when the nearly inevitable happens, he says, “”You can say, ‘Remember that list I showed you? Guess what? One of them happened.'””

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada

Featured Download

Grant Buckler
Grant Buckler
Freelance journalist specializing in information technology, telecommunications, energy & clean tech. Theatre-lover & trainee hobby farmer.

Related Tech News

Get ITBusiness Delivered

Our experienced team of journalists brings you engaging content targeted to IT professionals and line-of-business executives delivered directly to your inbox.