IT projects continue to run over time and over budget, resulting in systems that do not match business or end-user requirements, ot stall before they are finished. In contrast, traditional engineering projects show lower rate of failures. In fact, traditional engineering projects have been  around for centuries and are better understood. IT projects have their own inherent weaknesses (such as invisibility, complexity, dynamic nature, difficulty regarding estimation, intangibility, regular upgrades, inability to add people on a delayed project and training requirements) as well as strengths (flexibility, mobility, replication, scalability, reusability of components and possibility of using prototypes) that requires careful attention. The only possible fault one can call common to all failures in inadequate, to a greater or lesser extent, management of those projects manager responsible. In mitigation, the design and implementation of IT systems is horrendously complicated, involving highly complex matrix of technologies and business interdependencies which are shifting at different relates across several management planes. But that is still no excuse for such failures. The reasons IT projects fails, to whatever extent, remain the same as always: the inability to specify user requirements, manage the number of requested changes, or limit the scope of change as the project progresses. There are many other issues behind failed projects, including in-house politics, deadline-centric cultures and new legislation emerging during the project.
Good project management, however, is about taking account of change up-front, and building in risk management and contingency planning buffers. It is about setting realistic duration and cost estimates, and not being afraid to tell the chief executive that his pet project cannot be finished in the six months he expects, even if being so honest puts your job at risk. Since none of this is rocket science, it begs the questions as to why to protect continue to fail. 'It's because there's too often a lack of an agreed requirement specification', says Dennis Gower, a founding member of the Association of Project Managers. 'At least 50% of the time of the contract should be to find out precisely what users and departments require, it's that important.
Anne Bentley, a business consultant with project management software house Artemis agrees: 'The actual specification of what's wanted by the department is often not concise or clear, which means costs won't be clear, estimated timescales will be out, and soon the whole thing goes wrong'. In addition, says John, commercial directive at software implementation specialist Druid: 'A lot of the failure is down to the fact that users aren't fully aware of the change that the company has embarked upon on their behalf. Pressure on any project manager to change the scope is fierce, and while there may be formal change management processes in place, he can still get swamped.'
If that all sounds obvious, it is because the people explaining the issues are all project management professionals. Many of those managing end-to-end IT projects, however, are not. Not only that, but the companies to work for have no sense of project management on a corporate basis, spanning all business operations. This state of affairs is changing. With the onset of recession at the start of the decade, corporate
minds were focused on monetary constraints and efficiency improvements in existing systems. The number of new projects lessened, and those that were given the go-ahead were, often for the first time, highly scrutinized from a non-IT perspective.
Focus was sharpened on professional project management skills, regardless of whether they came from outside the organization through consultant, or through in-house training and development programs. During the past three years, institutes and groups, such as the Association of Project Managers, have emerged. 'The use of project management hasn't been god in the past', admit James Baker, responsible for setting up the BCS's project management group. 'But in the past five years there's been a dramatic upturn in training, qualifications and attention to project control, and its role in organization as a whole.'
Unfortunately, this trend has taken 30 years to arrive, with relatively recent disasters such as those at the Stock Exchange, the London Ambulance Service and British Gas still fresh in the mind. On of the key reasons for this, believes Baker, has been the hugh divide between user and IT shops, the latter delivering what they though the user required, and user naively expecting systems the IT department could not deliver. 'With IT system now very much a business issue', add Baker, 'these gaps may be flowing, but there remain crucial issues regarding managing projects. There's an argument that technology always has a solution to technology problems, but you can’t necessarily find solutions to people problems, the management of which accounts for perhaps 80% of successfully managed projects.'
If the right people are involved, the chances of success increase exponentially. But what constitutes an ideal project manager is debatable. To some, it is a combination of having a listening ear with the ability to rule with a rod of steel, and having the requisite project management skills. For others, such as long-time project manager Ervin Munir, new projects director with AMS, there is much emphasis on imperturbability. 'In some firms, personal success is based on meeting dates, and if slippages are perceived, it leads to situations where the project manager is unwilling to tell the truth.' Munir related an instance in his career, which has featured Currys, Dixon and Burger King, when he was given six months to complete a project which his own analysis showed would take a year. 'I had to decide whether to keep quiet or tell the truth', he recalls. 'In the end I stuck to my guns, and the users were pleased with the final results. And that's what all project managers should be able to do.'
For Neil McEvoy, a director at consultancy Hyperion, a key attribute is the ability to manage expectations and balance resources and skills against those expectations. 'When things for wrong because business requirements changes, that's when the real skill of project managers come in'. With more project management courses and certifications, the prospects of improved skilled professionals seem certain. 'Certification', says McEvoy, 'can arm people with a basic toolkit. But most problems are about managing relationships, so all the training in the world will of little use if the project manager has no instinctive feel for people.'
And there is more, add John: 'Project managers need to be methodical, but also intuitive and able to understand real issues. It's an art and a skill. At least with a growing body of professional project managers to call on, the prospects for doing so successfully are enhanced.
End of case study

What are the qualities sought from project managers according to McEvoy, John, and Baker?