When a new software product is developed to meet the needs of an organisation, appropriate requirements are gathered and detailed specifications are produced. The project sponsor and stakeholders endorse the project, its deliverables, resource requirements, budget and time schedule and the project manager enthusiastically embarks on the project, diligently following the steps in the projects methodology.
This project is going to be one of the organisation's success stories, right? Wrong!
An important aspect has been overlooked, one which will influence the way in which the project is approached and executed - quality acceptance criteria. Quality acceptance criteria are a set of benchmarks which will determine whether the product or solution is of an acceptable standard for release. These benchmarks must be defined and agreed upon by all stakeholders prior to the commencement of the project and will determine whether or not the project is a -success".
The demand for quality refers not only to value creation, security and user friendliness, but also to extensibility and adaptability. It is important to establish and guarantee the required quality systematically and economically during the whole lifecycle of the project. Taking only the end product into account simply isn't enough. Process quality goals must lie at the very heart of the stages involved in developing or procuring services or products.
Ultimately, just because a project is completed on time, doesn't mean it is a success. A sponsor's expectation is always that the product will work perfectly with good performance, in every environment without bugs however minor or missing functionality and will be ready by the release date. Within time frames dictated by commercial considerations, this is not realistic.
If a part of the user interface is outstanding and a priority one feature is not working, where must the project manager focus their resources?
Functionality, positive working environments and performance are the areas to consider when producing quality acceptance criteria. The establishment of these quality criteria then provide a guide for prioritising elements of the project. For example, aspects of the project which meet a certain criteria would be required for the first release while those which don't meet the criteria could be deferred to a later release. This allows the project team to focus on what is important, particularly if tasks arise that compete for resources.
The application of the product must be considered when defining quality criteria. In a clerical environment it may be reasonable to delay fixing a bug encountered in five per cent of scenarios. However, it would not be reasonable to delay such a bug fix in a mission critical process on a space shuttle.
Stable, user-oriented information systems that effectively support business processes are not a product of coincidence, they are the result of systematic quality management. Development and implementation teams who keep this in mind will undoubtedly deliver a final product which will be of greater value and service to sponsors organisation.
Steve Rogers is the co-founder of ITPM, an Australian professional services company that manages the design and implementation of information technology and telecommunications projects for enterprises. You can contact Steve by e-mail at srogers@itpm.com or visit ITPM on the Web at www.itpm.com .
