White Paper – Quality Management
Quality management strategy The delivery of a project’s objective, and the achievement of the benefits, involves many quality management activities. Many proprietary project methods, which conflate project management with product development, place the responsibility for quality within the technical domain area, and project performance suffers because of this. Other methods that clearly distinguish between the project lifecycle the product development lifecycle do not. PRINCE2 and Managing Successful Programmes, for example, specifically identify the Senior Responsible Owner (SRO), who is either the project sponsor or a senior business manager, as being accountable for all aspects of project quality. Confusion between project and product assurance led to the inclusion within the international standard for project management: ISO/DIS 21500 of a definition for quality assurance in projects. It consists of three elements: Plan quality - determine the quality requirements and standards that are applicable to the project, and to the deliverables of the project. Show how the requirements and standards will be met given the project objectives.
Quality assurance, thus clearly encompasses the management conduct of the project, the delivery of the products, as well as the products. What then is best practice in providing the appropriate level of assurance for the project and the products? To provide the level of confidence that a project is performing as required there needs to a structure or project assurance framework established for projects run in the organisation, and at the individual project level, a quality plan.
Project assurance
Assure quality - ensure that the project and product planning includes all processes, tools, procedures, techniques and resources necessary to meet project quality requirements.
The framework for project assurance is typically owned by the project management office (PMO) or a project centre of excellence. The framework is a layered set of policies, processes, procedures, tools and templates, which are themselves separated into: governance, project execution and product development. The pi3 ‘M-model’ illustrates this layering. First it shows the layering of control: portfolio, then project; then project execution.
Control quality - determine whether the project objectives, quality requirements and standards are being met; and identify causes of and ways to eliminate unsatisfactory performance.
The second, more elaborate, presentation of the M-model shows how the three lifecycles of project, product and change, governance and assurance levels interact.
Page 1 of 5
www.projman.co.za
© Projman cc trading as PiCubed
White Paper – Quality Management
Figure 1: Portfolio and project control Top management
Portfolio governance
Strategy definition
Portfolio planning
Portfolio controlling
Project governance
PMOs, SGs
Idea evaluation
External project termination
Project controlling
Project preparation
Project management Detailed planning
Project managers
Internal project termination
Project execution
Personnel and financial management
Figure 2: Project and change governance across the lifecycle
Organisational change Portfolio Strategy alignment
Portfolio planning
Portfolio controlling
Project Opportunity
Initiation
Planning
Execution
Close out
Look back
Feasibility*
Product Business benef its plans
Design
Test
Transf er to operations
Build
Governance Business justification
Change Make it wanted
Page 2 of 5
Delivery strategy
Readiness of the business
Make it happen
www.projman.co.za
Operations review & benefits realisation
Make it stick
Š Projman cc trading as PiCubed
White Paper – Quality Management
The model highlights why project assurance is so vital - it is the essential integrator that connects the outputs (the products delivered by the project) the management of cost – represented by the project processes - and the management of value – represented by the three stage change process. The fundamental governance decision areas are represented as the four stage gates (the paired triangles): (1) Business justification (2) Delivery strategy (3) Readiness of the business (4) Benefits realisation The key governance documents used at each stage gate are listed in the table below:
Stage gate
1) Business justification
2) Delivery strategy 3) Readiness of the business
4) Benefits realisation
Documents
Opportunity motivation Financial summary Project motivation Benefits plan Business case Authority to proceed – to plan Project definition report Change definition report Authority to proceed – to execute Status reports Transfer to operation (TTO) Change readiness Authority to proceed – to close Look back report (benefits realisation)
Tools
Project complexity categorisation Lifecycle selection criteria Stage gate 1 checklist
Stage gate 2 checklist Stage gate 3 checklist
Stage gate 4 checklist
These documents contain the essential information necessary to allow management decision making and authorisation to proceed to occur. Other documents (e.g. the quality plan, the project schedule, SACCRID* logs, etc), targeted at management and control of the project, will be generated by the project manager and other members of the team. Governance documents serve the purpose of succinctly summarising the case for proceeding with the project.
Project reviews The ‘weapons’ used in project assurance are ‘reviews’. These are not casual affairs, but structured comparative analyses made against defined standard items. It is this that makes them powerful weapons, and it is essential they are deployed appropriately – and properly. Descriptive reviews, without reference to the comparator and without a view of the expected performance ratings, are low value and the reports generated can often be written before the review is conducted. Each of the reviews listed in the table below is reviewed against a document and without that the review provides little insight or value as a governance decision-support technique.
Page 3 of 5
www.projman.co.za
© Projman cc trading as PiCubed
White Paper – Quality Management
Review type
Purpose and check document
Audit
Similar to an asset audit – a checklist approach to identify compliance with standard components and processes – check is against selected method referenced in the quality plan Project status review To confirm that the ‘to go’ status is the same as that stated in the progress reports – check is against the project plan and schedule Health check To identify any management actions necessary to re- align the project with its mission (objective, scope, benefits) – check is against the SACCRID* logs and the business case Post project review To determine how well the processes of the project performed and whether there are any lessons learned to be taken back into the process documentation – check is against the project definition report Post implementation review To determine how well the transfer to operations occurred and whether the outputs are in proper use. – check is against the change definition report Benefits realisation review To determine the value and level of benefit being achieved – check is against the benefits realisation plan *SACCRID logs describe the stakeholders, assumptions, constraints, changes, risks, issues and dependencies managed by a project.
The quality plan Project assurance is a part, though an important part, of the quality management system (QMS) for a project. The other part is the quality of the outputs produced by the project. To encompass both elements it is common practice to incorporate a quality plan as a project management execution document. This specifies how the QMS is to be implemented and deployed in the project. Whereas project assurance is typically owned by the PMO, quality assurance is likely to have an ‘owner’ for each of the distinctly different product lifecycles used in the project. Quality assurance & control processes are typically owned by the technical area responsible for the development of the product. In the case of IT products, the IT group; engineering products, the engineering group; training products, the HR group; etc. In developing the quality plan for a particular project the project manager may therefore need to draw upon several sources. One of the common pitfalls for project managers with strong technical backgrounds is the tendency to apply quality assurance and control techniques that are specific to their own technical area. They either attempt to apply the same techniques to all types of products, or fail to apply any structured quality assurance and control techniques to those products that are less familiar to them. In the table below, the typical contents of a quality assurance plan are listed, indicating where the organisation should have standards for the project manager to draw upon in developing the project specific quality plan. However, a word of warning, when reviewing quality plans, many commentators have remarked on a worrying tendency for quality plans to be mainly ‘boiler plate’ text and have, and to be seen to have, very low value. The quality plan should capture deviations from standard processes, and state the reasons why the risks associated with varying from a standard are lower in this case than keeping to the standard processes and procedures.
Page 4 of 5
www.projman.co.za
© Projman cc trading as PiCubed
White Paper – Quality Management
Contents of Quality Assurance Plan Section
Content commentary
Source
Project assurance (project processes)
Governance approach to be used for this project with specific responsibilities identified. Reporting approach to be used with specific responsibilities identified. Project reviews which will be conducted – when and by whom.
Project assurance (project outcomes)
Key success criteria for the project (as documented in business and benefits / change management plans). Post-project review, post-implementation review, benefits review process to be adopted with specific responsibilities defined.
Governance – standard roles & responsibilities Life-cycle model Portfolio level reporting Project level reporting Tolerances & action responsibilities Project status review process Audit process Health check process Post project reviews Post implementation reviews Benefits realisation reviews
Product assurance
Standards applicable to the development of products in the project. Assurance approach to be used identified for each of the major product deliverables with across reference to responsibilities Standard technical product acceptance criteria which are applicable to the products to be produced. Specific product acceptance criteria (quality expectations and acceptance criteria defining what must be done for the final product to be acceptable to the business and the users) – reference to the user requirements and acceptance criteria defined in the user requirements documentation. Approach to be used for confirming product quality with cross reference to responsibilities. Change management procedures – reference to organisation standards, plus indication of any deviation from these standards for this specific project. Specific responsibilities for change management cross referenced. Describes the configurations of products and how versions will be controlled and baselined during the life of the project.
Quality responsibilities
Product control
Change management procedures Configuration management plan
Page 5 of 5
Summary of quality assurance & control responsibilities.
www.projman.co.za
Governance – standard roles & responsibilities
Domain specific product life cycle descriptions (e.g. SDLC) Domain specific product quality criteria Domain specific verification and validation procedures
Change management process Configuration management process
© Projman cc trading as PiCubed