This is written from a consultant’s perspective (and over 30 years’ experience). It is intended only to raise some specific issues that lead to project failure, rather then to be a general guide to project management. And it relates specifically to transport planning and modelling projects.
The first problem is that highly trained technical staff who have relied on their training and skills to achieve a high flying career tend to continue to assume that these same skills will carry them though the trials of project management. Consequently, apart from paying lip service to administrative forms and reports, they assume that project management simply involves the application of their technical skills at a more strategic level. This is a huge mistake.
Project management is a multidisciplinary activity. The PM (project manager) must be able to:
Technical skills are clearly not enough!
There are many reasons why projects fail, and the following discusses some of them in my experience, but there is also a useful review in M M O’Connor and L H Reinsborough, Quality projects in the 1990s: a review of past projects and future trends, International Journal of Project Management Vol 10 No 2 May 1992.
Most consultancy projects are won through some sort of proposal process. A poor, superficial, overly brief or technically flawed proposal will lead to project failure unless the PM redesigns the project and secures the agreement of the client. This is a controversial area internally within the consultancy and also with the client, but it is a foolish PM who proceeds on an ill-founded plan.
It is common in consultancy to find that the ideal team is for one reason or another unavailable at the outset of the project. A team without the appropriate balance of skills will not succeed in achieving the project to plan. While this may mean difficult internal discussions, the PM must ensure that he has the right resources needed for the job.
Clients vary in their attitudes and approach. While many are a joy to work with, the relationship with others can create project problems. Often this is because they lack understanding of the technicalities of the project. If there are expected to be client difficulties, or these become apparent during the project, it is the PM’s responsibility to devise a plan to cope with them or head them off.
Communications with the client are a critical factor. He/she needs to understand the progress of the project and the issues that arise and to learn confidence in the team. Poor communications can lead to the client and project team having different perspectives on what needs to be done and serious downstream conflicts.
Invariably, unexpected technical problems arise during a project. Some hopefully have been anticipated in a risk analysis at the outset and contingency plans have been made. Usually, such problems are reflected in an expected budget over-run.
Perhaps the single most important point that I can make is that the usual PM and company reactions are wrong - that is, to seek to solve the technical problem while at the same time recovering the budget over-run. This is impossible, and has the inevitable result that, as the project continues, the budget, timetable and the quality of the deliverables will all be increasingly severely undermined. This is because technical and quality problems arise from the technical short-cuts which are required to solve problems while reducing resources, but more importantly because, now unduly influenced by a heavily constrained project budget, the PM starts to make sub-optimal decisions which increase project risks exponentially.
There is no question that, in this situation, the project should be re-planned to sort out the technical problems and to complete the remaining tasks as intended, allowing appropriate resource contingencies for the remaining work. Although this will apparently imply accepting a larger project budget over-run, the final outcome will still be better because the downstream risks will be minimised.
There are three common difficulties:
These are matters which can only be addressed by PM training, internal project reviews and/or changes in the corporate culture.
You can download this very simple project timetable and budget tracking system. For more complex projects it is hard to go past the 3-sheet system advocated in Anderson, Grude, Haug and Turner, Goal Directed Project Management, Kagan Page and Coopers & Lybrand.
I have mentioned the setting up of the project team, but resource problems can undermine a project during implementation if resources are not managed well. For example:
PMs must be alert to the need for changes of scope and to negotiate these formally with the client.