Courses on quality teach us that the cost of defect correction is much greater than the cost of prevention and that these costs are not always financial. The cost of a software bug which is not caught prior to release extends beyond unplanned rework, release management & communication efforts to reputational impact and even potential legal action.
What does this have to do with project management?
The same rules which apply to customer-facing outputs also apply to the project manager’s deliverables produced to support the delivery of a project’s scope. The project plan, work breakdown structure, schedule, risk register and many other artifacts all represent the hard work of many different roles, but are primarily associated with the project manager and if the quality of any of these is lacking, the project manager’s credibility will be impacted the most.
Now you might disagree with me and say that many of these deliverables have multiple cross-functional reviewers who will inspect them before they are signed off. After all, most functional managers won’t blindly endorse a project schedule without confirming first that the proposed allocations for their staff are accurate and with such reviews the potential for meaningful impact to projects would be reduced.
While this might be true for some artifacts, it is usually not common for all key project management artifacts to receive thorough external reviews, and the “lens” which is used by the reviewers is likely focused on the impact to their own areas or work. On top of that, even if there are no tangible impacts on project success, quality issues will color perceptions of the project manager’s abilities.
So what’s the solution?
If your organization has a PMO, you might be tempted to push this responsibility on to that entity to proof all key project management deliverables prior to their release. Unfortunately, this will just create a bottleneck as it’s rare for PMOs to have surplus skilled staff available to provide such services. A PMO can help, but it would be through as-needed consultation or through random spot checks.
A better solution is to draw on a common development practice and utilize PLS – Peer-Level Support. Having a peer inspect your work before it is released to others helps as they will be looking at it through the eyes of a project manager and are less likely to draw conclusions or judge your effectiveness than someone in a different role.
One of the best aspects of this practice is that it can start quite small with just a couple of PMs and grow incrementally. Over time, if this practice becomes institutionalized, it will reduce the magnitude of nit-picking done during such reviews as PMs realize that “with what judgment ye judge, ye shall be judged”.
PM friends don’t let PM friends release low-quality artifacts!
Easy in theory, difficult in practice 