Implementing A Technical Review

Background

When projects submit an initial proposal the project partners will probably have an idea as to the approaches which will be taken in order to provide the project deliverables. During the project's life it may be desirable to review the approaches which were initially envisaged and, if necessary to make changes. This document describes possible approaches to periodic reviews.

Reasons For A Review

There are a number of reasons why a technical review may be necessary:

Technological issues:

There may be changes with underlying technologies. For example the software which was initially envisaged being used may be found to be inappropriate or alternative software may be felt to provide advantages.

Staffing issues:

There may be staffing changes. For example key technical staff may leave and are difficult to replace.

Organisational issues:

There may be changes within the organisation which is providing the project.

Changing requirements:

There may be changes in the requirements for the project, following, say, a user needs requirements survey.

Ensure that deliverables comply with standards and best practices:

It may be necessary to ensure that the project has implemented quality assurance processes to ensure that project deliverables comply with appropriate standards and best practices.

A project review may, of course, also address non-technical issues.

Approaches To A Review

Projects may find it useful to allocate some time during the project life span to a technical review of the project.

Review by development team:

The project development team may wish to reflect on the approaches they have taken. They may be encouraged to provide a report to the project manager.

Review by project partners:

The project partners may be involved in the review process.

Review involving third parties:

The project team may wish to invite external bodies to participate in the review.

Comparison with one's peers:

You may chose to compare your deliverables with your peers, such as similar projects. This approach is particular suited for reviewing publicly available deliverables such as Web sites.

When organising a project review you should take care to ensure that the review is handled in a constructive manner.

Outputs From A Review

It is important to note that any improvements or changes which may have been identified during a view need not necessarily be implemented. There may be a temptation to implement best practices when good practices are sufficient, and that implementation of best practices may take longer to implement than envisaged. The outputs from a review may be:

Better understanding:

The review may have an educational role and allow project partners to gain a better understanding of issues.

Enhanced workflow practices:

Rather than implementing technical changes the review may identify the need for improvements to workflow practices.

Documenting lessons:

The review may provide an opportunity to document limitations of the existing approach. The documentation could be produced for use by project partners, or could be made more widely available (e.g. as a QA Focus Case Study).

Deployed in other areas:

The recommendations may be implemented in other areas which the project partners are involved in.

Implemented within project:

The recommendations may be implemented within the project itself. If this is the case it is important that the change is driven by project needs and not purely on technical grounds. The project manager should normally approve significant changes and other stakeholders may need to be informed.

Conclusions

It can be useful to allocate time for a mid-project review to ensure that project work is proceeding satisfactorily. This can also provide an opportunity to reassess the project's technical architecture.