News

Soon after a popular loyalty-program website was updated, it had to be shut down because the changes inadvertently made members' private information freely accessible. The leak was plugged, but not until after the members became livid.

In another case, one year after launching an enterprise resource planning (ERP) system — and suffering through myriad database crashes — a Canadian grocery retailer pulled the plug and started from scratch with a new vendor.

These kinds of information technology snafus dog companies large and small. At best, projects run late or a tad over budget. At worst, they cause bankruptcy. In between, snafus delay the launch of major initiatives, run millions of dollars over budget, compromise security and privacy, demoralize employees and drive away business.

Because they are complex, IT projects that address ERP, customer relationship management (CRM) and e-commerce are littered with tales of woe. Most organizations understand the benefits of such projects, but they do not fully understand the complexity and costs of implementing them, analysts say. Vendors have been known to play down costs and complexities to close a sale, figuring that problems can be sorted out as they arise, which leads to "scope creep" and budget overruns.

Many medium-sized businesses in Canada have few IT workers and thus contract out application development to third parties. While that might make financial sense, it can lead to problems if the business does not hire a project manager to keep things on track, says Andy Woyzbun, lead analyst with Info-Tech Research Group, based in London, Ont.

Even if the project goes well, "if you don't test you can be in deep trouble," he adds. Testing should mirror real-life conditions to ensure the system will work when running at peak capacity. Planners should build in more time for testing than they think they need; that way, if the project as a whole takes longer than planned, it won't eat into crucial testing time.

Before companies get to the testing stage, however, they should establish objectives and timelines and designate someone to stay on top of the project. Corporate managers too often approve projects and then disappear, Mr. Woyzbun says. "That's a recipe for disaster."

Dino Bozzo, president of Konverge Digital Solutions Corp. in Toronto, agrees. His company builds software applications for medium and large businesses, and he finds "the most successful projects have detailed requirements, with a change-control process."

Change is not a dirty word, he adds. Often when developing applications, vendors discover unforeseen issues or opportunities. The vendor should bring these to management's attention and implement changes that make business sense.

Konverge, for example, built an inventory-control application for the News Group, a magazine distribution company. While doing its work, Konverge discovered methods to determine the ideal number of titles that should be shipped to each store, as well as their quantities and where they should be displayed on racks to maximize sales. The revised project came in over budget, but it also exceeded the projected return on investment.

Sadly, many projects come in late and over budget and come nowhere close to meeting, let alone exceeding, expectations.

Problems often occur when a vendor takes a "design, build and run away" approach, says Sebastien Ruest, vice-president of services research with IDC Canada in Toronto. This is not always the vendor's fault; many businesses, in trying to keep costs under control, do not budget for follow-up and training that could ensure success, he says.

But there is good news: disasters are less prevalent than they were five to 10 years ago when 50 per cent of projects fell off the rails, says Mr. Ruest. There is "more rigour" in project management, he says, and the number of projects that come in on-time, on-budget and meet expectations are up by between 25 per cent and 50 per cent.

Even so, budget creep, unmet expectations and other problems often occur when companies "add applications like spaghetti, instead of layering them like lasagna," Mr. Ruest says. If existing IT application strands are not functioning as intended and the company intertwines a new one, the new application may fail because the programs feeding it are not functioning properly, he explains.

This happens more than people think, although existing applications aren't always to blame, says Ron Lutka, president of Corporate Streamlining Company Inc. and author of the book Black Holes in Organizations.

"Failure is often the result of other process problems," he says, citing the case of one midsized manufacturer that implemented an ERP project without fixing an existing "procedural quagmire." The project came in late and over budget and still did not work properly. Scores of completed work orders remained in the system marked as "in process," and many customers were credited with paying bills even though they had not received invoices.

"Too often, management expects IT to solve process problems that might not even be related to IT. Vendors are responsible for developing new applications, not repairing broken organizations," Mr. Lutka says.

"Organizations need to identify and eradicate black holes, or failures of basic processes, before they layer complex IT systems over flaws."

Failure to do so can lead to the failure of IT projects that, history shows, sometimes fail under the best of conditions. And that can lead to frustrated employees and lost business.

DOING IT RIGHT

To ensure that an IT project goes smoothly, analysts recommend following these steps:

• Determine whether there is a business case for the project. Will it cut costs, enable staff to work more effectively, deliver improved customer service, conduct more targeted marketing or boost sales? If so, at what price? In other words, does the return on investment make sense? If so, proceed.
• Look for vendors with experience in your sector and with experience developing the type of project you need. Conduct due diligence. Check references and the vendor's credit rating.
• Set up a project team that includes managers with decision-making power. Also include end users, the people who will have to use the technology once the project is complete. Meet with the vendor to set your expectations. Explain your business case in detail. Be open to suggestions that make business sense.
• Sign a contract that details expectations, a project budget, completion dates for major project components, and roles and responsibilities. It should also outline the change process and the cost of change.
• Hire a trained, independent project manager at the planning stage so he or she understands the business case and project expectations.
• Keep the project team intact and meet with the project manager and vendor according to a set schedule. Be prepared for ad hoc meetings as required.
• Expect change. Budget time and money for change.
• Test the project before going live. If you revise the project after testing, test the revisions.
• Budget for follow-up tweaks and training. Diligently train workers who will use the system.
• Before starting any project, ensure all processes and systems that feed into it, connect with it or rely on it are functioning as intended.

Special to The Globe and Mail