I’ve often used the cliche that improving PPM or PM capabilities is a journey not a destination, but this advice can introduce its own challenges. Given the myriad of people, process or tool changes that a PPM/PM process leader could make to improve project value realization, predictability or reporting benefits, an unfortunate tendency is to frequently tinker with established procedures.
Don’t get me wrong – I’m not a fan of methodologies that never evolve since a good “fit” between a methodology and the culture/maturity of the organization is vital to its continued use.
Frequent changes might be driven by a process leader’s desire to continue to demonstrate incremental value from practices or tools so as to justify the value of the approach. For example, if a sponsor has invested significant financial and political resources into the funding of a costly PPM toolkit, they may wish to see as many of the features within it used as soon as possible and the temptation might be too great to not dribble features out in a constant flow.
Whatever the justification, the outcome is often the same – staff are not able to develop the “muscle memory” that comes with consistent execution of the procedures, and this results in poor quality outcomes and metrics as well as increased defensiveness and resistance to change. A small percentage of your staff might thrive on chaos, but for the remainder, these frequent changes result in the same tension experienced during a game of Whac-a-mole!
So how do you find the sweet spot between stagnation and too frequent change? The answer is through release management. Just as a commercial software company releases updates on a scheduled, predictable basis, you should establish a practice for changing your PPM/PM methodology at regular scheduled intervals.
The benefits of this approach include:
1. Each release should include the same thorough communication, planning & training that (should have) accompanied your initial methodology launch.
2. Staff get advanced warning of the changes and have the opportunity to provide feedback into the development phase.
3. The effort to gather and report on metrics to understand if the release really improved capability or not is focused instead of being spread out over a long period of time.
4. Staff have sufficient elapsed time to achieve process equilibrium.
5. The expected benefits of the changes can be compared with the full costs (hard & soft) to justify the release – it’s a lot harder to do that if the changes are made in a “stealth” mode.
6. The focus of a release is defined based on business needs and the magnitude of perceived gaps. For example, one release could focus purely on improving organization skills whereas another might be heavier weighted towards technology changes.
The frequency of these releases will depend on the change appetite of your staff as well as the expected time line for achieving PPM & PM business objectives, but I’d caution against anything greater than a quarterly basis.
Improving PPM and PM practices should be like scaling a mountain – short climbs separated by regular plateaus.