Planning for quality is planning for success

Once the project requirements are understood, quality planning ensures that they will be met. This requires a suite of measures to:

• Confirm the proposed solution will meet the requirements
• Ensure that the solution suppliers both can and will meet the standards of workmanship needed on time
• Confirm that work done meets acceptance requirements at the earliest opportunity reasonable
• Check that non-functional requirements are being met, not just functional requirements

There is a cost associated with quality control, both time and money, and there is almost always a ‘penny wise, pound foolish’ pressure to cut those costs, but they are usually dwarfed by the cost of poor quality – rework, delays and legal bickering. Progress issues can threaten completion; the Channel Tunnel project ground to a halt due to conflict between parties over who should pay the rising costs, and this was only resolved by firing the executives involved on both sides. My last blog post mentioned the quality issue with London’s Millennium Bridge where user experience wasn’t thought through, i.e. it wasn’t planned. The quality planning process should start, like all good planning, with the final outcome – how will the project be accepted and the final stage payments authorised? It can then work back to the start.

This ‘backward planning’ at the earliest stage of the project ensures that quality is assessed for entry into service, demanding the involvement of end users, maintainers and operational managers. Too many projects get close to the end before considering final acceptance testing, by which time it’s too late to address factors overlooked earlier. Building in quality control points throughout the project gives reassurance that work done is delivering value.

My first exposure to poor quality planning was on a software development project within my programme where percentage complete progress reports indicated it was on track. Only when I demanded to see demonstrations of the resulting code working was it revealed that none of it had been tested; nothing was working. Here I had no excuse – I was simply inexperienced in unprofessional behaviours.

However, fingers burned, since then I have always required early testing. Migrating a marketing team from their small server to the corporate data warehouse was progressing to plan when I was offered the test plan to review. I was astonished that it omitted performance testing and demanded that interactive performance be added – it would be a disaster to move from a small server to a supercomputer and have things slow down. Performance testing showed that it would be slower in some cases but rewriting fixed that before final acceptance testing by a delighted customer.

It seems obvious that testing as early as possible allows faults to be fixed with the minimum of cost and delay, yet this is not common practice. Effective and efficient quality control is everyone’s responsibility, so that means everyone involved must understand what makes their part of the solution acceptable or unacceptable, so all products need acceptance criteria. For standard items, this comes from their manufacturing specifications, but for all bespoke items, this creates a heavy thinking and documenting burden early in the project and throughout the design process. This demands discipline from the project team, planners and designers, and more importantly the support of the sponsor and other senior stakeholders for ‘thinking time’.

Stakeholder pressure ‘to make progress’ is a major factor in skimped quality planning. In an IT programme for a global manufacturer, a huge change to reduce IT costs was planned to the way email was used. No consideration was given to changing the behaviours of the 93,000 users globally, including the CEO and company executive committee. The same programme was also critically dependent on wide area network file transfer speed, which at that time was completely unacceptable for half the globe. I pointed out that these factors would guarantee the programme would fail but gaining acceptance of that took time and effort before the relevant groups were engaged.

Putting thought into what makes all the project’s products acceptable, and how that acceptance will be carried out, really flushes out flaws in the requirements and the solution design before it’s too late, preventing disasters later.

Quality planning doesn’t have to be very time consuming or expensive, but it does take discipline, best reinforced by process, to be effective. Our everyday language is full of advice to back this up: ‘look before you leap’, ‘more haste, less speed’, ‘a stitch in time saves nine’, ‘measure twice, cut once’ and so on. And remember, he who laughs last laughs longest.

You may also be interested:

• Who deliver quality in a project?
• What is quality management?
• Successful quality management requires expert risk management