It has been stated (and is supported by research done by PMI) that the consistent application of project management methods can result in an increased likelihood of project success. However, this needs to be balanced with the following advice from the Guide to the PMBOK (Fourth Edition): “For any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process.”
How do we go about rationalizing these two apparently competing guidelines?
It starts with recognizing that we should follow consistent project management principles, but the application of specific methods should be driven by the needs of each project.
Work decomposition, activity definition, and sequencing are necessary activities, but do they need to be done the same way on all projects?
On a project that has its requirements very well understood by the customer and project team, one could develop a work breakdown structure (WBS) to an “inch pebble” level and then migrate the lowest level activities to a detailed project schedule. On the other hand, when faced with a more conceptual end state, trying to decompose scope beyond one or two levels in a WBS is wasted effort. On such projects, high-level planning and use of agile methods will likely result in a better outcome.
There are multiple risks with applying a one size fits all approach to the use of project management tools:
- Too much effort is spent on the “how” instead of the “what” or the “why”
- Project administration costs are not commensurate to overall project costs
- Team members and key stakeholders grow frustrated and develop (or reinforce) perceptions that project management is low value bureaucracy
I witnessed a good example of this when attending a product demo for an integrated application development platform. Although this solution provided tools and templates in support of agile methods, handling of code reviews was clearly not one of these. Code reviews are an established method of eliminating defects early in the development process, but the degree of automation reflected within the tool suite to automate code review workflow would be onerous for nearly all organizations.
Having a detailed project management methodology is not bad, and in highly regulated industries or domains where strict compliance is required, it is essential. However, for most of us, such a methodology should always serve as a reference and should never replace the need for a project manager to use good judgment.