Management means - exactly that

New technology can deliver substantial financial benefits and even completely transform businesses: the pages of MCS are full of real-life examples that prove the point. But IT projects are notorious for failure, or at least budgetary and time overruns, and that's especially challenging in manufacturing. Why? Because a new IT project usually represents a venture into the unknown: not just new systems, but changed processes, procedures, roles and responsibilities – even different relationships with departments, customers, suppliers and business partners. But it's also the case that it has the potential to grow like Topsy. Software vendors offer a very broad range of program options and modules that can extend into virtually every part of a manufacturer's operation, given half a chance – and there's always an argument for that. Furthermore, the world doesn't stand still and wait for a system to be commissioned. Things change so fast that there's little virtue in attempting to stick rigidly to agreed implementation phases for processes and systems based on today's 'best practice' in supply chain management, for example. Things will long since have moved on before the system's fully operational. But these challenges aren't insurmountable. By following some simple rules, it's not so difficult to increase vastly the chances of a project being judged a success. Perhaps the most important rule to remember is that the more effort invested right at the start of a project, the more likely it is that the expected business benefits are not only delivered but even exceeded. Project scoping As Paul Baron, professional services director at software consultancy Inca, says: "Scoping is the difference between a successful project and just another project. Get the scoping right and you might have a successful outcome, but if you don't, your chances of success are zero." Scoping may be the most important part of a project, but unfortunately, it's also usually the most difficult. In particular, there will be pressure at every corner to add to whatever scope you agree. This is something that Anthony Smithson, financial controller of ice cream manufacturer Richmond Foods, was very mindful of when the company came to implement Cognos Enterprise Planner (EP) business intelligence with Inca. "We'd had experience on a previous project of people asking 'Can we add this?', 'Can we add that?'. So we knew we didn't want to go down that road again," says Smithson. Definition first Richmond has grown fast, largely by acquisition, and transformed from a small Yorkshire firm run by a farmer to a multi-million pound business supplying 55% of the UK's supermarket own-label ice cream. Planning on spreadsheets was no longer quite the ticket, and hence the move to Cognos EP – but that's a very versatile tool, and it's not hard to see the scope to extend its role. Smithson's approach: "We had a very strict definition of where we wanted to go and, because we had a very strong team, with the commercial director being the project sponsor, we were able to say that the scope only went as far as the budgeting process. We weren't going to budge on that." It's not always as easy or clear-cut as that, as Paul Massey, consulting services director at IFS UK points out: "In many cases, all the companies know is that they have an old system that needs replacing and an IT manager who wants to spend some money!" With what amounts to a virtually blank sheet, it can be difficult to know where to start, and even more difficult to know where to draw the line. Teresa Jones, senior researcher with analyst Butler Group, suggests: "If you stand back from things and ask 'What can we help people to do better?'; 'What can we free them up to do more of?', it can be a great help. You might start with asking where the problems are at the moment. What are the processes not performing well?" It helps, too, to think not just of those processes that are failing to deliver, but those that represent what the software vendors love to call 'points of pain'. Processes may be delivering the goods, but only by involving a disproportionate amount of time and trouble, consuming too many resources and disrupting other activities. Those can be priorities meriting change. A number of techniques are available to help with project scoping, and Jones recommends Mind Mapping – the visual way of presenting and linking ideas and processes – as a good starting point. "It can help to start off in a less structured way, and then you can add the structure later." However, not everyone finds techniques like that easy or appropriate, especially those used to thinking in confined or linear ways: initial quick training may be an answer. One thing's for sure: for a project scope to be viable, it's critical to secure everyone's agreement. Jones insists the scope should be written down, and that "you should get everyone to sign to it." It would be nice, too, to be able to carve that scope in stone, but, as stated, that's unrealistic. Thereafter, it's something of a balancing act: the project shouldn't bend to every whim, but some flexibility is essential to accommodate a changing world. As Baron observes: "The amount of times you start a project and people want to do something awfully interesting half way through! All projects must have a means of making a change." Project deliverables Meanwhile, a project scope that merely says what's going to happen, without saying why, is useless. "The scope must indicate what you're going to get out of it – not just the deliverable, but what is the value of that to the business," insists Jones. It can be difficult to estimate, but Massey also agrees it's essential. "There must be some payback on the investment. If you can't measure and define that, how are you going to know whether you've got it? There must be a clear definition of what you're going to achieve." What he recommends is defining some KPIs (key performance indicators) that will flow from the top-level project goals. Everyone has to accept that it's not always easy to translate a project's goals into hard figures, and Jones makes the point that it's also always valid to have soft benefits in there too. "But," she says, "you still have to write them down and aim for them." It's also important not to be too ambitious in defining the scope: the project will take too long. "If you have a six-to-nine month project, the business will change in that time, so will the solution, and so will the scope. Basically, you'll never get there," says Massey. "It's also difficult to keep a project team together for a long period of time – another reason why speed is important." Best advice is to aim at keeping each project to a maximum of three months. Of course larger projects are unavoidable, but they can still be broken down into three-month phases, perhaps with the first being to scope a larger project, the deliverable and to generate a shortlist of software vendors and consultants. Incidentally, it's worth noting that, perversely, once KPIs and benefits have been defined for a project, the business processes impacted become clearer, and thus also the departments and people implicated. Either way, more detailed planning is now necessary. "If you don't spend time looking at process models, you'll waste so much time further on," warns Massey. "There is a big payback on spending those few days so you know exactly where the project boundaries are." Project planning IT can help here too: a business process modelling tool can help identify processes to be targeted and ways in which they should change. From that, a number of steps will logically follow, including knowing which people to involve. "The next challenge is getting the resources freed up," observes Massey wryly – a challenge that dogs most projects from scope definition onwards. "You may have to fight to get the people you want, rather than the people who are available – but if you don't, you'll pay for it," he warns. It's crucial that those who are going to manage the altered processes are the ones driving the project: it's absolutely not a job for external consultants. The recommended method is to backfill the day-jobs: if necessary, taking on temporary staff, particularly if some roles are going to go away anyway as a result of the technology. Thus armed with a scope definition, process map and resources, you're ready to devise the detailed project plan: and, as observed, that must aim high and fast. You have to get success as early as possible: the more momentum you can get from quick wins and early payback, the more the project team and wider company will relish further success and add their commitment. Unfortunately, by their very nature, detailed project plans talk in terms of tasks, whereas the company wants deliverables. "The big job of the project manager is then to marry up tasks and deliverables," says Baron. And he reminds us: "Nearly always, any problems in a project arise because the deliverables weren't defined." Nevertheless, there will be tasks to be done, and they will take time. It's important to give people as accurate an idea as possible of how much time they'll need to put in, and to give them milestones so everyone involved can see they're on track. Tools such as Microsoft Project and Excel have a place in helping to organise and review the tasks, people and resources. And there are others. Inca's process for implementing Cognos EP at Richmond took the interesting approach of using the software itself – it is enterprise planning software, after all – to manage the implementation. "We use it in a very graphical way," comments Baron. "Most projects have things like critical paths, Gant charts, flow diagrams and lists of deliverables. All of those can be put into Cognos EP. The graphical display means I can usually tell within one or two minutes the status of a project." Over when it's over? From there on, completing the project is 'just' a question of the assigned people working through their tasks, with appropriate project management and co-ordination on the way. But a project isn't over even when it's over: although every step on the way is important, the post-implementation review is also one of the most important. "The first thing in a post-implementation review is to remind people of what the deliverables were," says Baron. Then you ask: 'Did we achieve what we set out to achieve, and what can we do better next time?' It's not a time for finger-pointing and blame. The review is your opportunity to learn and improve: it's the time to ask what can be done better in the existing project and for the next, in a positive and constructive fashion. It's also an opportunity to consider what other changes and developments might be sparked off by the project's achievements.