Talking the same language

4 mins read

To ensure IT projects are delivered on time and within budget, companies need to ensure the project team is talking the same language. Dean Palmer reports

When it comes to managing IT projects, it appears that manufacturing may have developed a culture of its own. Successful projects in this sector often rely on the marriage of interests between the business and commercial people and their related issues, and the manufacturing shopfloor with its operational problems. It’s here that conflicts of interest often start to emerge, partly because the two sets of people (three if you count the IT function) aren’t talking the same language when scoping and delivering projects. Dr Angus Hearmon, principal consultant at Atos Origin has worked in the UK manufacturing sector on numerous IT projects: “You need to ensure you get the project scope and deliverables agreed up front. It’s critical because you need to know what the knock-on effects are on other areas of the business. It’s not that complicated really – it’s simply about getting the project team together in a room, in a workshop environment. You don’t need any sophisticated project management software at this stage; it justs gets in the way.” He suggests manufacturers scope projects using a “roadmap” or “story board” for the journey. “If a consultant’s involved, that person needs to have an idea of where the business is heading. Otherwise you end up going where the consultant thinks you want to go. Too many businesses don’t actually have a mission statement, never mind a detailed strategy of where they’re going over the next couple of years,” he adds. “You also need a well-trained project manager with first class communication skills – that’s the most important thing... Project management software can help you if it’s a multi-site IT implementation and you need to get an overall view of project resources across sites. But it’s only an aid.” And what about best practice methodologies? Hearmon: “There’s no such thing as best practice. There’s good practice and bad practice. What’s good for one firm is not necessarily good for another. You’re better off focussing on which worst practices to avoid.” Most major consultancy firms agree on the ingredients for a successful IT project. First, at the sponsor level, the project should have one clear owner, not necessarily full-time, but someone in the business that’s senior and has some real clout. Someone that can force issues to closure and deal with any financial risks. That means also having someone on the team (or steering committee) who’s responsible for realising the benefits from the project. Second, the project team should include someone who has the necessary technical expertise and business know-how. There could be new software involved that requires you to buy-in the skills required for the project, but you also need to have someone on board who fully understands the business processes involved. Third, you’ll need an effective communication process, acheived through teams. You could use software here to promote this, such as engineering design collaboration software used over the web to help engineers jointly agree and authorise design changes. And it’s obvious perhaps but education is also key – that means ensuring everyone involved in the project is aware of the specific tasks they should be doing and why they need to do them. Rapid path to success? Deloitte & Touche’s supply chain director Andy Dyson comments: “There’s never enough time to plan properly with IT projects. But you need to try to produce a hard business case up front. You need to know the specific costs involved, the expected benefits, payback and ROI. “In the last six months, we’ve seen a change in the UK manufacturing sector. It’s now looking for quick-wins, some even use a 90-day rule. They want a rapid path to success, especially the smaller firms.” He claims his company has a very successful IT implementation methodology: “It’s called Express and it’s for mid-market companies. It’s based on the fact that these firms are typically less capable than larger enterprises in taking on large, resource-intensive long-term projects. So we base our methodology on three ‘pathways’: intensive, standard and rapid. These quickly identify which project activities should be considered based on the speed of the implementation the client requires.” Going the ‘rapid’ route means a fast implementation with minimum methodology for low cost, short timeframe projects. The focus is on applications with minimum activity for IT, process and system integrity and training. The other extreme, ‘Intensive’, means a full methodology with significant value-added activity in process re-design, IT, process and system integrity, change leadership, training, education and project management. So it’s horses for courses. $450m in project failures Dr Mark Lycett, project leader at Brunel University has been busy over the last year working on a government-funded three-year research project, Fluid Business (www.site-project.org.uk) which aims to investigate where companies are going wrong when implementing IT systems. “We looked at some analysts’ figures [Gartner and the Giga Group] last year which suggested that project failures were costing businesses more than $450 billion a year world-wide… This was due to project failures, software failure and the subsequent repair costs… And the study also indicated that 25% of firms’ IT budgets were spent on software development and 75% on maintaining the system after implementation,” says Lycett. “We wanted to find out where things were going wrong, whether there were any recognisable faults, and if accepted wisdom was getting in the way. And how we could all do things differently.” Now one year into the research, Lycett explains the results so far: “As far as manufacturing firms are concerned, the software they implement tends to be developed for a particular point in time, as defined by the project. So you can end up with static software that requires lots of maintenance.” And he suggests that many software vendors (and consultants) are guilty of fitting the customer’s business problem to their own software solution rather than the other way round. “As a result, we’re seeing companies adopt a more cautious, phased approach to their IT implementations,” adds Lycett. He suggests four areas where manufacturing firms can improve here: “First, flexibility is key. We have to change our approach to implementing IT systems so that they can be flexible and adapt to the way needs change. Always design with integration in mind... The second point is all about people issues. Ensure you gain buy-in and consult with the end-users of the software by adapting systems to the way things already work. “Third, firms have to change the way they budget for IT to one that is more flexible rather than imposing rigid yearly budgets… And fourth, think big but act small. It’s vital that companies have a bigger picture in place, but often it’s the smallest implementations that succeed – the larger ones are too cumbersome, often becoming obsolete before they’re finished.” And his last point is worth expanding on. Many businesses have rigour and contracts in place to try to curb capital expenditure. But as Giga’s research last year showed that only 25% of a firm’s IT budget on average is spent on software development, why are these firms focussing on this element rather than the software maintenance side which is a larger slice (75%) of the budget? Lycett rightly calls this “Weird logic.”