Project system reviews

By Andrew Clifford

An effective system review reduces risk and cost in your project, and helps you make the best use of scarce technical staff.

When you run an IT project, you need to carry out three types of review.

• You need to review the project progress, timescales, and budgets.
• You need to review the project deliverables.
• You need to review the IT system itself.

The system review is often confused with the deliverables review. But the starting points are different.

The deliverables review starts with the business requirements, and checks that these have been taken forward effectively in the design.

The system review starts with an idea of what a good IT system looks like. It works back to check that your system will meet these more general IT requirements. It makes sure you deliver a system that will be a good citizen of you IT estate, not a delinquent.

A system review needs to consider all characteristics of the system, whether or not they are part of your design. This includes: responsibilities, data integrity, performance, availability, security, recovery, test availability, documentation, reporting facilities, fit to technical standards, technical viability, and many more.

It helps to have a standard template for your system reviews. The template should clearly explain what a good or bad system looks like. If you have to reinvent the review for each project, it will only contain the things you have already thought about. It will not challenge your proposals effectively.

A good review template lets you carry out an effective review without having to assemble a panel of experts. The template should show you where you need specialist assistance, helping you make the best use of scarce resources.

The review needs to be more than a simple checklist. It needs to ask searching questions. For example, to review system availability you need to consider for what hours the system will be available, if and when it will be unavailable for routine maintenance, and what the business impact of non-availability would be. This is different from a design review, which might, for example, focus on the use of resilient hardware.

Run a system review three times in your project.

• In the early stages of design, to identify gaps in the overall solution.
• At the end of detailed design, as part of you quality assurance process.
• After implementation, to provide a baseline to ensure that ongoing support maintains and improves the quality of the system.

If you are replacing or extending an system, review the existing system before you start the new design. This helps build the case for change. It makes sure that you repeat the successes of the existing system, but avoid the pitfalls.

System reviews give benefits in the project and in the deployed system. They help you identify omissions early in the project, and to fix them before the project needs costly rework. They help you make the most of scarce technical staff. They help you deliver a higher quality system, which reduces long-term risks and support costs. They help you avoid the built in obsolescence that forces an early end to many IT systems.

Subscription