When you’re on a diet, you can have the best intentions in the world. But if you end up at an all-you-can eat buffet, those good intentions can quickly disappear.
IT projects, it turns out, are not that different. To prevent scope creep, you need to know what’s on the menu and what’s not – and stick to it. Scope creep – the addition of new features to an already approved features list – can happen to any IT project, large or small. But most projects that suffer from scope creep tend to have one thing in common: poorly defined business objectives.
Scope creep is almost entirely predictable before a project begins, says Barry Levine, a principal at consultancy RSM Richter Consulting Group. “Management has to have clearly articulated objectives so they understand what they will and will not get out of a software solution. That has to be nailed down before a single implementation, and probably even before the software selection phase.”
Scope creep can also occur when a project’s objectives are defined at too high a level, says Tracey MacArthur, director, project management and community care information management, shared information management services at the University Health Network. “For example, if we indicated we wanted to implement a system to decrease the time it takes to refer a patient from one organization to another — that’s a little too general,” she says.
Levine, who’s not naming names, cites the example of one of his clients who ended up calling RSM in to help a badly derailed project get back on track. The client, who had started out with a budget of $1 million and a timeframe for delivery of 12 months, realized the entire project had imploded – but not until the switch was flipped and the project went live.
The go live date was six months past its original deadline – but that wasn’t the worst part.
“Once they flipped the switch and went live, all those things became painfully obvious. Things like inventory out of balance and functionality that didn’t work properly,” Levine says. “They were trying to run a business with thousands of transactions a day and they realized within two weeks the system was out of control. It took a year to bring it back.” It also took another $1.5 million, not including the consulting fees.
Good creep/bad creep
But not being on time or on budget doesn’t necessarily mean a project has failed, observes Karim Mamdani, senior project manager at Canadian Pacific Railway. Mamdani, who manages large ERP and infrastructure projects in the range of $1 to $5 million, says scope creep is not always a bad thing.
When CP, for example, outsourced all its infrastructure to a vendor, the organization had to move it all from CPR’s data centres, including a small one in Calgary and a larger centre in Toronto, to the vendor’s data centre. CPR wanted the project to be completed in three months. But after reviewing issues such as risks, timelines and resources, it decided to conduct a small pilot project with its Calgary data centre first, moving all its equipment over a one-month period.
At that point, says Mamdani, they realized the equipment was old and needed spare parts. Sometimes servers shut down, never to come back online because they had not been rebooted in years, he says.
“We realized our expectations were unrealistic,” he says. “So we came back to the steering committee and management and said this is not going to work, we need more money and more time. They revisited the business case and managed to release the funds.”
The project, although considerably over budget and time upon completion, was hardly a failure, says. “It still was successful because we delivered what we were supposed to.”
The Dos and Don’t’s of scope creep
Do:
• Consider hiring an objective third party with project management experience to keep a project on track and act as a go-between from your organization to the vendor if you don’t have the expertise in-house. “If you don’t know how to build a house you wouldn’t start without a good general contractor,” says RMS Richter principal Barry Levine.
• Follow a process. “Projects that follow a process have a much better rate of success,” says Tracey MacArthur director, project management and community care information management, shared information management services at the University Health Network in Toronto. IT teams that try to go around the rules, fight the process or skip steps find it just doesn’t pay in the end, she says.
• Have a well-functioning change management process. That means prioritizing changes, says Karim Mamdani, senior project manager at Canadian Pacific. “Change orders and requests are important and prioritizing those changes is important also. If you have changes and they’re documented properly and you have the right people approving those changes, then small things cannot get in the way,” he says. “Typically what happens in projects is the end user will walk up to someone and say, ‘Hey, can you put these in?’ and if you get a number of those it becomes bigger and bigger. If you manage change properly with documentation, whoever wants to put a certain feature in would have to go through the change management process and then after that it would get prioritized. If you don’t, you end up delivering a lot of frivolous pieces and you don’t get to the core of what you need to do.”
• Consider the reality that businesses and technologies can change a lot over projects spanning a couple of years,such as major ERP implementations. “It’s a little unrealistic” to ask vendors to stick to their original quotes, says Mamdani.
Don’t:
• Make the mistake of thinking your business is so unique it always needs a custom implementation of off-the-shelf software. “The projects I see that tend to go over budget are those where a fair amount of custom development is involved,” says Levine. “If you’re taking a commercial ERP package, and implementing it largely vanilla — not canging a lot of it and you’re adapting a lot of your business processes to fit the software — then the likelihood of cost overrun is a lot lower than the opposite scenario, which is where you tailor the software to fit your business. You’ve probably heard a thousand times, ‘Our business is unique.’ Most businesses aren’t that unique, but people think they’re special and they think it’s necessary to change the software to the way they do things. That’s what gets companies into trouble.”
• Leave anything undocumented. “Make sure there are minutes on any conversation that took place and any phone calls,” advises Dave Maloney, project manager at Paradigm Shift Technology Group Inc., based in Richmond Hill , Ont. Maloney is currently managing the deployment of software packages for measuring achievement to about 60 per cent of the school boards in Ontario. “It’s kind of project management 101, but in our environment it’s even more important to have that documented because everyone wants to know what was said and who is going to do what.” • Frame the project according to technology. “Frame it according to the ultimate business objective,” says MacArthur. “You can get caught up in the technology components.”
• Shy away from the idea of spending a little to potentially save a lot. “Let’s say you have a $1 million project and you spend $50,000 up front,” says Mamdani. “It’s easier to walk away from $50,000 than halfway through it and say, ‘now we have to dump more money into this because it isn’t really what we want.’”
COMMENTText