4.8. Project review

The project review improves the quality and compliance of newly delivered systems, by measuring them against system governance criteria during development and implementation, and recommending actions to improve quality and compliance.

The project review is used during systems development and implementation projects, and during major system change projects. The conditions under which it is used will have been defined during initiation, and documented in the terms of reference. This could indicate that all projects will be reviewed, or just some.

The review involves three cycles: during project proposal, design, and implementation. The review should be initiated as the project proposal is taking shape. (A review can be initiated later, but will involve more rework because issues will not be identified until later in the project life cycle.)

The process assumes that the final part of the review will take place after the system is implemented. Some organisations may wish to run this review before the system is implemented, as a quality control gate before the system is put live. This should be defined in the terms of reference, or agreed at the start of the review.

Although it benefits from an established system governance regime, the project review can be run before system governance is fully rolled out. It can if necessary be run using standard review materials from Metrici, which will provide a review of the project against general IT best practice.

The project review is carried out by the system governance manager, or their team.

The project review is typically initiated by the project manager, and the findings of the review are passed to the project manager for their attention.

The project review involves three cycles of review: during project proposal, design, and implementation. It will be hard to fully complete the first two, because the details of the system will not have been finalised and there will be no experience of running the live system.

Some judgement is required about completing the review. It is reasonable to miss out some criteria. Where possible, though, it is good to declare what the project is aiming to achieve (for example, it may aim to achieve good documentation even if it has not yet written it). This encourages the project to achieve what they have declared, or risk being downgraded later.

The main purpose of the review is to improve the quality and conformance of the delivered system, not to “catch out” the project. Present the review as a way of helping the project quickly achieve its quality and compliance objectives, not as a tiresome formality. The first two cycle of review, during proposal and design, can be fairly informal. Only the last cycle, when the system is implemented, is taken as the baseline for future monitoring.

The review has three cycles because most projects have definite proposal, design and implementation stages. If necessary, rearrange the reviews to fit around the structure of the project. It is however important to carry out the final review cycle during implementation, as this provides a baseline for future monitoring.