Home Career

A project diagnosis report should be as brief as possible.

It must, however, cover:

• causes for concern with the current status;
• causes for concern with the potential future status;
• the actions required to manage these concerns;
• the exposure to risk as a result of these concerns; and
• evidence that supports these four areas.

This would form a brief project diagnosis report. A longer report would cover all aspects of the current and future status, whether or not they required action or created a risk.

The size of the report will depend upon:

• the kind of diagnosis being performed, and whether it is aimed at discovering problems and suggesting solutions or whether it is a full check of the project, providing approval of those aspects of the project that did not pose problems;
• the size of the project, as a long project is likely to lead to long reports, certainly early during the project life-cycle, because there will be more factors affecting the future of the project than there would be with a short project;
• the complexity of the project, as a project that involves more resources, more tasks, more people or more interaction with stakeholders and with other projects will offer a broader scope for diagnosis;
• the state of the project, as a project in a poor condition is likely to produce a longer diagnosis than a project in a good condition;
• the state of documentation, as a poorly-documented project is likely to produce a longer (though less focused) diagnosis than a well-documented project;
• the degree to which the project diagnostician understands that the diagnosis conclusions will be accepted, as a diagnosis which has to convince its readers of its conclusions will be longer than one which is likely to have its readers' buy-in; and
• the degree to which the diagnosis matches the expectations of its readers, as a report that raises additional issues that were previously unknown to its readers is likely to be longer than one which can remain focused on its readers' expectations.

There is an obvious danger of "scope creep" on a project diagnosis, especially on a project that is in difficulties. A project diagnosis should not become a blank cheque for consultants, and therefore some means must be developed of managing the scope of the project diagnosis.

We shall now examine each of the factors listed above to establish how it can be managed.

Nature of the Diagnosis

If the organization commissions a full report on the project, it will expect that the diagnosis will examine every aspect of the project in detail. Most of these aspects are likely to be reported as satisfactory, while some may be reported as unsatisfactory and deserving of future action.

If the organization commissions a report that is intended only to highlight a small number of problem areas, with suggestions for action to correct them, then that is what it should get.

In some cases, the project diagnosis will be focused solely on the project documentation, rather than on the project execution. (We shall examine this option later.)

These limits on the scope of the diagnosis should be established and agreed in a terms of reference document.

Size of the Project

The diagnostician should already be aware of the size of the project.

Reference to the relative size of the project ("short", "medium" or "long") or to its expected duration should be included in the terms of reference for the diagnosis.

In general, the duration of the project diagnosis will be relative (although not directly relative) to the duration of the project itself. For the three month project, a project diagnosis may take three days; for a six month project, five days; for a one year project; seven days.

For a long project (over six months), it may useful to restrict the terms of reference for the project diagnosis to a three month future, on the classic "rolling wave" principle that the project itself will not be planned in detail for more than three months ahead.

Complexity of the Project

The complexity of the project should also be known to the diagnostician at the outset.

A reference to the complexity of the project ("easy", "medium" or "difficult") should be included in the terms of reference.

It is possible that the project may be more complex than its management and the diagnostician imagine. This can often occur where interactions with stakeholders have become more complex than planned.

The diagnostician should immediately report if the project is more complex than imagined. This complexity may lie within individual activities or even tasks rather than across the project as a whole. Nevertheless, if the complexity of the project is greater than was originally imagined, then management should be made aware of this and a decision taken on whether to extend the diagnosis.

State of the Project

The diagnostician should be told whether the state of the project is expected to be "good", "indifferent" or "poor". This should be included in the terms of reference.

Again, the project diagnostician should report immediately if the state of the project is considerably different from what was expected. Management can then decide whether to continue with the current project diagnosis or whether it should set up a new diagnosis with broader terms of reference.

Of course, if management knew definitely what the state of the project was, it would not need to commission a project diagnosis. There is always uncertainty, before the diagnosis, as to the real state of the project.

State of the Documentation

The project diagnosis is highly dependent upon the state of the documentation.

Documentation must be organized, relevant, accurate, current and complete. Where the project diagnosis depends on these factors, there will be difficulties if some of them are not present.

The project diagnosis can, of course, be commissioned to examine the state of the project documentation. In this case, it is probably better to set up one diagnosis to examine the documentation and determine its ability to meet the tests of organization, relevance, accuracy, currency and completion. A second diagnosis can then be planned to examine the state of the project itself, based on the results of the first.

Where a project diagnosis is undertaken with an assumption that the documentation meets these criteria, then this should be stated in the terms of reference and any deviation reported immediately.

Some documentation should be present for every project:

• the project charter;
• a project plan; and
• project status reports.

This is the minimum that a project diagnostician would expect to encounter.

For internally-run project diagnoses, it is useful for the organization to have adopted a project management methodology. This will enable the internal diagnostician to rapidly identify documentation items and their contents.

Acceptance of the Conclusions

Project diagnosticians may become involved with this issue at two points.

First, they may encounter it before the diagnosis begins. Given the other factors involved, such as the nature of the diagnosis, the size and complexity of the project, and the state of the project documentation, the organization's management may already have a view of what it will see in the diagnosis report and, therefore, what problems and corrective action will be needed. Project diagnosticians should determine what these are, as they will often define the boundaries of what the organization's management will be prepared to accept.

Second, during diagnoses, project diagnosticians may encounter situations that are beyond the boundaries that the organization's management will be likely to accept. In an extreme example, a project diagnostician may conclude that a project is in such a poor state that it needs to be stopped (or "frozen") and either re-planned or re-initiated. This may be difficult for the organization's management to accept if it had imagined that the project was actually proceeding well.

The project diagnostician may be able to prepare a plan for the diagnosis based on the first of these. If the second should occur during the diagnosis, the diagnostician may have no alternative to requesting an extension of the scope of the diagnosis to include a detailed justification for the new actions required to correct the unexpected situation.

An additional complication is that the project may be in a catastrophic situation. The catastrophic situations that a project may be in are as follows.

1. The project may never be completed. Progress and commitment may be such that the project will continue to survive while failing to achieve its objectives. This catastrophe can be averted either by re-planning the project or by terminating it.
2. The project may not be completed by certain critical dates. This can occur when a product has to be ready by a certain deadline; if it misses that deadline, then it will not be launched at all. Examples of deadlines can range from having products available in shops in time for Christmas to having reports in production in time for the end of the financial year. This catastrophe may be averted by increasing the resources or their availability. This remedy may cause the following problem.
3. The projected cost of the project exceeds its potential value. This can often occur in a project where the costs of the project have been increased incrementally without any reference back to the value of the project deliverables. In this instance, it is usually best to terminate the project. An attempt to reduce the project costs can often result in the following catastrophe.
4. The deliverables are so poor as to be useless. This can occur as a result of one or both of the two previous problems. It may be that certain critical dates can only be reached or project costs controlled by reducing the quality of the deliverables.

There are two other circumstances in which a project can be approaching catastrophe. These concern whether the deliverables from the project will be costly and difficult to maintain or use in future. The scope of the diagnosis may include these two factors. The project diagnostician should certain ascertain whether the organization's management wishes to include them as part of the diagnosis.

Expectations of the Audience

The expectations of the audience depend, to a large extent, on the nature of the diagnostician.

• If the diagnostician is an external consultant, then the organization may expect a report that includes all the background to the consultant being engaged for the diagnosis. An internal diagnostician is likely to write less by way of background.
• An external consultant may describe his methodology, whereas an internal diagnostician may simply state that she is following the established internal methodology for project diagnoses.
• An external consultant may be expected to report against "best practice", whereas an internal diagnostician may report against the organization's project management methodology. The external consultant may therefore have to describe "best practice"; the internal diagnostician can simply refer to internal publications.
• An external consultant, especially if being engaged for the first time, may state, at length, circumstances that are already well-known within the organization. An internal diagnostician may be able to preface a statement with "As we already know …" or "As we have observed on other projects …".
• This last point may manifest itself in another way. An external consultant, engaged for the first time, will have no frame of reference for the individual project under consideration, amongst the full programme of projects within the organization. The internal diagnostician may have established, after a number of project diagnoses, a common frame of reference. This may even form a separate document, dealing with common issues and problems endemic to projects within the organization.