Helpful but not a miracle …
Over the last few years there has been much emphasis on project management methodologies such as Prince2. The introduction and roll out of these structured techniques helps set expectations amongst the wider community about what the project manager will do, and the manner in which communication will take place. For instance the project stakeholders will not be surprised to see a project manager having a set of documents including
¨ Business Case,
¨ Project Initiation Document,
¨ Product flow chart
¨ Product descriptions
¨ Highlight reports
¨ Risk Log.
The development of the standard processes is obviously helpful as these, together with standard templates for the documents used, help many project issues to be anticipated and worked around. In order to be credible the methodologies need to cope with the most complex situations (e.g. Building the Olympic venues for London 2012)
The size and scope of some of the methods can give rise to serious issues as the project manager seeks to decide which elements from the methodology can be treated as optional and tries to downscale the approach to smaller projects. (The level of detail or the number of stages of plans is all a matter of judgement, as is the appropriate membership of a supervisory board within a Prince2 approach). Sometimes this reduction can be triggered by external time commercial and time pressures – “…why don’t you stop creating documents and get the team to concentrate on actually producing something…”, but it can also be decided by the personnel available to provide the supervisory roles and structures envisaged.
The role of the project manager and the team in making sure that the documents and controls are of appropriate quality can also sometimes be given insufficient attention.
¨ It is difficult to know when a risk log is complete. This log is sometimes compiled using brainstorming or other collaborative techniques, but the obvious need to have few un-mitigated risks can lead to “game playing”.
¨ Deciding on the work breakdown structure and the product interdependencies can be really challenging.
As project methodologies have become more prevalent, the author has noticed a tendency for the subject knowledge of project managers to be treated by some as less important. The project manager may be more of a generalist who understands the process of project management rather than an individual who has experience of the particular challenges arising from the activities involved ( e.g. software development, building an airport ). There is little substitute for the experience that allows a project manager to judge when a small issue is one that will remain small or could grow into a issue threatening the complete project ( or even programme ). This isn’t to say that software project managers need to know how to programme for example; but if for instance they don’t understand the difference between representative and unrepresentative test harnesses for unit testing then the system integration could be appalling painful.
More recently much attention has been given to “gateway reviews”. In the UK the OGC have published a gateway review process that other organisations may have adopted. It is worth recognising, however, what these reviews do well, and what they omit. The reviews focus on “buy” rather than “build”, and they ask whether the project management controls are working and the project will deliver the benefits to its stakeholder community. The reviews do NOT focus or consider which assumptions may make the project outputs meaningless. This is assumed to be happening as part of the risk management process.
Quite apart from the challenges that arise from the need to define management deliverables there are often serious issues with the estimates and assumptions made as part of specialist deliverables that are to be delivered through the project. These assumptions are of critical significance to the whole project and often need a detailed technical and business review to bring them to light. The technical staff within a project may not be aware their interpretation of the business requirements has embedded unsafe assumptions. Examples of some that the author has uncovered during past project reviews are:
¨ Expecting the client to synchronize identifiers between systems on a regular basis.
¨ Misunderstanding the speed of response required to support call centre staff when designing a complex integration to back office systems.
The author is a senior consultant with strong business acumen who understands both project management and technology. He has over 10 years experience of major IT projects in both private and public sector, and the difficulties of making the project plans represent reality. Get help with your project challenges by visiting http://www.kutchka.co.uk/survey/index.php?sid=10 now.