TORONTO — If they want to capitalize on major software implementations, companies must stop ignoring advice and start following a few simple rules, according to one IT veteran.
“”There are a bunch of reasons why software projects fail. To me, some of the key reasons are poor requirements
of management and poor estimation,”” said Stephen MacLean, CIO and director of IT for Acres International, an engineering consulting firm. MacLean was speaking as part of the IT Leadership 2002 conference held in Toronto this week.
In his presentation, Ensuring Value from IT Development Investments, MacLean cited three large Canadian and U.S. software implementations that failed to deliver. Included in the list was a “”running shoe company”” that spent a reported $400 million on an inventory planning system that failed to produce. (In February 2001, Nike blamed i2 Technologies and problems implementing supply chain software when it declared disappointing quarterly results); a grocery chain (Sobeys), which spent $50 million on an SAP implementation and then pulled the plug. As well, a100-year-old management consulting firm that spent $50 million on an ERP implementation and then tossed it.
“”The message is pretty clear that there is some depressingly familiar advice coming out – one needed to test more, one needed a sponsor, one should have killed the project early,”” he said. “”I’ve worked in a bunch of organizations including software development companies as well as three stints as a CIO and I’ve yet to see an organization do a good job on tracing requirements through the lifecycle of the project to make sure they are actually delivering.””
MacLean pointed to statistics from The Standish Group that indicate 32 per cent of all projects end up over budget and late, while 52 per cent of projects will cost 180 per cent of their original estimates and only nine per cent come in on time and on budget.
So how does one deliver value in an IT project? MacLean says three key ingredients are required: deliver on time, on budget and meet the business needs. From an organizational standpoint, three critical elements must exist.
“”Obviously, you need a high performing team – so getting the right people is critical. Then set priorities – for some reason IT people don’t prioritize very well. Prioritizing and being able to say no and then getting the process right. I think more than anything that’s the area where we are still struggling.””
He said organizations should also provide technologies that can be used by existing personnel within reasonable time constraints.
“”We’re not going to retrain people to be rocket scientists to use an application,”” he said. “”One of the problems we have at Acres with our systems is we continue to go out and buy pretty complex systems. The feedback from the organization is ‘you’re giving me a sledgehammer to deal with a finishing nail.'””
Agility, said MacLean, is about providing quality first and speed second. He recommends “”small and nimble”” projects that cost less and offer fewer features and can be delivered in shorter time periods.
“”Microsoft is a good example – how many people have heard the term bloatware applied to Microsoft software? The number of features the average user will probably use represents 10 to 15 per cent of the features in Office. I’d sure like a version that was stripped down and ran a gazillion times faster with a much smaller footprint with one twentieth the cost.””
In terms of spending, setting a dollar ceiling on software projects is key. MacLean suggests no software project be greater than $100,000 — or at least be broken down into budgetary chunks of the same amount.
Taking an incremental, capped approach may work for some, but shouldn’t be applied across the board says IDC Canada Ltd. software analyst Warren Shiau.
“”It’s hard to generalize. Certainly, if you’re renovating your house it makes sense to tackle the kitchen first, then the bathroom and the roof. But it also depends on the level of expertise on the implementation team,”” he said.
The size of the development team is also a factor: big projects mean more levels of information and more communications channels to go through. There must also be a demonstration and review process with incremental releases.
MacLean added that if an IT department is doing development, it should resemble a software development house and practice the same formal software release methodologies.
Another MacLean rule of thumb: If it doesn’t work, kill it. At some point, if the project isn’t going well, be brave and pull the plug.
As well, ensure business people are committed to the development team, particularly with ERP projects. “”If you’re not getting dedicated business people on a project you’re in for a world of hurt,”” he said.
Lastly, implementation teams must be prepared for the “”J curve”” phenomenon. Performance is probably going to fall off when you first start a project, but once employees really buy into it, or reach the “”Jesus point,”” said MacLean, “”then you start to have improved performance and go back up the curve.””</PComment: [email protected]
