Before I go any further, let me re-state (and supplement) a few truths I hold dear.
- Most defects are introduced in the early phases of a project and get a good deal more costly to fix as time passes
- Most capital is committed relatively early in the project life-cycle
- Commercial contracts offer plenty of opportunity to write in haste arrangements that there will subsequently be plenty of time to leisurely repent
With this all said, how does the project manager take these self-evident truisms and instate a control that will serve to guard against mishaps?
I've talked about a several elements that together can serve as a foundation for project delivery. There are a number of things that can cause instability, amongst which are the following.
- Poor scope definition
- Inadequate product descriptions
- Lack of stakeholder engagement
- Poor change management
I've covered quite a bit of detail in relation to the first three but very little on the the topic of change. Incidentally, this isn't a complete list, but it's certainly some headlines.
The invidious thing about change is that it comes in many guises and there won't always be a governance product or person that can be called upon to respond appropriately.
With this said, you need a catch-all, something that informs all decisions, something that is quantifiable, and readily comprehensible to all stakeholders.
Say after me - "EVERY DEVELOPMENT STEP HAS A CORRESPONDING TEST ACTIVITY".
Put it in the brief, put it in the PID, the project charter, give it a slide in the project kick-off meeting, write it on the wall, include it in SOPs for the project team and champion it at every opportunity.
And when, as inevitably will be the case, someone deviates from this virtuous path and you've finished picking up the pieces, conduct a root cause analysis which will almost certainly find the absence of an appropriate test activity the principal culprit.
,,,and then of course, you can add it to the lessons learned log.