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 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.

The team obviously have a vital role to play but the team can feel inhibited from telling their boss that he or she is wrong. Even if the message is delivered it can be discounted, or confused with a lack of discipline. Independents can play a valuable role uncovering these and other challenges that the project may face.

Quite apart from the challenges that arise from the need to define 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 unsafe assumptions 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.

Project reviews
More recently much attention has been given to 'gateway reviews'. In the UK the OGC have published a gateway review process that 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 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 project process. A review that actually looks at the real deliverables can be valuable to make sure that the project will still deliver something.

Conclusion
So whilst project methodology is rightly seen as a means to avoid some of the more obvious pitfalls that have been seen in projects, practioners should be wary of assuming that the adoption of a particular methodology will be a miracle cure for all projects.

Once the views of the team and other stakeholders have been gathered it is worth getting independent review to assess your plan and the assumptions. Periodic refresh as the project unfolds can be worthwhile, depending on the extent of change experienced during the delivery period.

Article Source: http://www.articleblender.com

Vernon Riley is a senior consultant who understands both project and technology. He has 20 years experience of major IT projects, and the difficulties of delivering complex projects. He can be contacted via Kutchka


Here are some more management articles...