When the introduction of a new customer relationship management system began to falter at Vancouver’s Ngrain Corporation last summer, there was no one better qualified than general manager Gabe Batstone to step into the fray. That was the problem. The IT project’s original leader had departed before
completion, leaving the new system hanging and Batstone struggling to balance his regular duties with the demands of the complex project. The only solution, he quickly realized, was to bring things to a grinding halt.
“”We immediately stopped our work on the project and let it ride for two weeks. Then we had a meeting to recall what our original objectives were,”” says Batstone, whose company provides interactive 3-D software to the aerospace and defence industries. The project had become unfocused and overly ambitious, so the team recommitted to their original goals and the project was back on track within weeks. The new system came online at the company in January.
“”We had taken on more than we could manage and the project had grown way too big,”” he says now. “”I needed monthly reports from the new system, not a host of clickable features that I would hardly ever use.””
The most critical lesson he learned from the project’s failure was the importance of an effective team with a strong leader. “”Pretty much every IT project goes awry to some degree. But the key questions are, ‘Do I have the right people to bring it back online?’ and ‘If something goes wrong, who can I yell at?’ If you don’t know these answers from the start, then you’ll have a problem,”” says Batstone, who recently co-founded the Vancouver Product Managers Association to encourage local companies to network, share resources and uncover best practices in launching IT-related business endeavours.
But learning from other companies’ best practices can be difficult when your projects are in fields where no one has been before. VIA Rail, Canada’s national passenger train operator, faced a number of challenges when it tried to implement a series of IT plans in the 1990s. Among the operator’s most challenging aims was a system to enable travel agents to book VIA tickets directly, says Mohamed Bhanji, the crown corporation’s Montreal-based director of marketing technologies.
Initially, a system of proprietary hardware was supplied to 200 travel agents, enabling them to become dedicated ticket sellers. But the system required staff training and was cumbersome to use, so it failed to deliver on VIA’s objectives for rapid growth. The team went back to the drawing board to find a new way to fulfil its aims.
“”We asked ourselves why we couldn’t simply become part of the existing system that travel agents use to book airline tickets. We approached IATA (the International Air Transport Association) and asked them what we could do to enter their system. It took 18 months and we had to make major internal changes, but we became the first railway company to become part of their system,”” says Bhanji. “”The project only worked once we adapted our own systems to the industry standard.””
It’s a lesson VIA took on board for all its future IT projects, including becoming an early adopter of Internet booking procedures in 1994. “”We learned that when you take on projects just for the sake of new technology, you are more likely to fail,”” says Bhanji. “”Always keeping our customers in mind and making ourselves increasingly convenient for them is what keeps our IT projects focused.””
It’s a sentiment that Marc Perrella, vice-president of IT and communications at Toronto-based analyst and consulting group IDC Canada, can appreciate. He recalls an anonymous project where the company involved had no sense of focus from Day 1.
“”The project was not correctly defined, the manager was inexperienced and there was no appreciation of the complexity of the task ahead,”” says Perrella. Making little progress on their ill-defined goals, the team soon became demoralized and project paralysis set in. After three months, they called in outside help from Perrella and his group of advisors.
“”The management had basically brow-beaten them into thinking they were useless, so we stopped the project and pulled everything back to do a risk assessment. The audit uncovered what was working and what wasn’t, so instead of starting everything from scratch we were able to re-set the foundation,”” says Perrella.
Perrella believes there are many reasons an IT project can come unstuck. These include disagreement over objectives, lack of management, insufficient resources and scope creep — a change to the nature of a project halfway through.
For Ron Babin, a Toronto-based associate partner at Accenture who has been called in to pick up the pieces on many IT ventures, there are several ways to define project failure. But whatever the definition, he believes the underlying cause of many failures is the lack of a business raison d’etre. “”When technology is seen simply as a panacea and a project has been launched for purely technological rather than sound business reasons, that is a tactical failure,”” he says. “”All IT projects should be business first, technology second.””
It’s this essential business dimension that’s often missed when companies analyze the failure of their IT projects, says Hank Summy, president of Toronto-based system integrator Sapient Canada. “”People think about project failure in terms of lost software or hardware costs, but they don’t think about the loss to the company of not solving the problem that the project was set up to address. Also, what’s the opportunity cost of keeping workers on a failed project when they could have been working on other successful projects?”” asks Summy. The formula he uses to keep projects on track involves a series of iterations every three to five weeks, ensuring achievable stages on which each succeeding stage can be built. This formula has the advantage of ensuring a rigorous audit-and-proceed approach that keeps complex ventures on track. “”Only about a third of IT projects in the marketplace are completed on time and on budget, so it’s important to keep a very close eye on every stage,”” he says.
According to Larry Simon, one of the organizers of the Canadian Information Productivity Awards (CIPA) — an annual competition that judges the best in Canadian IT projects — successful endeavours are those that can prove themselves business-wise, have cross-functional use to the company and stay on track with good internal measurement systems. While companies have generally learned from the era of failed multi-year mega-projects that were common in the 1980s and 1990s, Simon believes many of the same old mistakes are still being made. “”There’s still a tendency to allow projects that ought to be killed to keep going because nobody wants to make the call to cancel it,”” he says.
Simon believes that far too many projects begin without outside advice or the establishment of a business and IT steering committee. “”IT projects should be treated just the same as any other project. The business and IT elements should be joined at the hip.””
