logo image

Acquisition
Acquisition: Project topics: Project diagnostics: Definitions

Definitions

Defining what we mean by a "project diagnosis" may be difficult, especially if we are used to post-implementation reviews (PIRs) at the end of a project or project audits during a project.

In defining a project diagnosis, it is useful to examine the typical project life-cycle, and, in particular, to look at how PIRs work within it before going on to look at project diagnoses.

Post Implementation Reviews

The following diagram shows the typical four-phase project life-cycle.

Project life-cycle

Figure 101.1: Project life-cycle

The PIR may be performed as part of the fourth phase. Alternatively, it may not be performed at all, for a number of reasons:

  • The project may have run out of time, so that the time allotted to the Closure phase has been used up during the Execution phase. This situation occurs so often in projects that the use of the Closure phase's time and budget as contingency for the Execution phase can almost be regarded as a technique.
  • The project may have been closed down at the end of the Execution phase. This also occurs often. In some instances, the project manager leaves the project at the end of the Execution phase, the people involved in the project become fully occupied with other tasks or other projects, and the project is generally assumed to be complete.
  • The PIR is judged to be premature if conducted immediately after the Execution phase. In many instances of this, the decision to delay the PIR is correct. Where the project deliverables need time to be "bedded in" or for their benefits to begin to emerge, it can often be more useful to delay the PIR until it will be more effective. Unfortunately, the PIR may then not take place at all.

Assuming that there is a PIR and that it is conducted at an appropriate time, what is the PIR intended to achieve?

Principally, a PIR must be a learning process. It should enable the organization to learn from the project that has just been completed and use that knowledge to improve future projects.

This relies upon a number of assumptions:
  • There will be future projects within the organization.
  • These future projects will be recognized as projects and will be managed as projects.
  • There is a mechanism for the managers of the future projects to learn from the PIRs of previous projects.

PIRs are most effective when their results are reviewed by senior management, who then institute immediate steps to prevent the recurrence of problems.

PIRs are least effective when they are filed away after completion.

To summarize the differences between a PIR and a project diagnosis:
  • a post-implementation review allows the organization to improve its future performance; it can do nothing to improve the completed project; while
  • a project diagnosis is intended to make improvements to the current project; it is not intended to do anything for future projects.

This difference is sometimes ignored and a project diagnosis becomes a kind of interim post-implementation review. It is important that a project diagnosis takes a very narrow view, of the current project, and ignores the "big picture".

There are other differences between a PIR and a project diagnosis:
  • A PIR can be relatively relaxed. Interviews can be arranged with participants or stakeholders in advance. Documents can be studied in detail. Illustrated reports and presentations can be developed.
  • A project diagnosis must be quick. People must be available immediately or they will not be seen. Documents have to be read quickly, so that only relevant documents will be examined. Reports are likely to be lists of current issues and of suggestions for dealing with them.
  • A PIR can cover a lot of issues. With the benefit of hindsight, the reviewer can state whether a particular issue was critical to the project, even though it appeared to loom large at the time.
  • A project diagnosis can cover only a few issues and they must all be critical to the project. The diagnostician must be able to differentiate the critical from the routine issues, even though, to the people involved, the non-critical issues may appear more important than the critical ones. (We shall discuss this skill later.)

Project Audits

It is easier to confuse a project diagnosis with a project audit than with a post-implementation review.

Nevertheless, there are distinctive differences, which are highlighted by a definition of a project audit.

Before the definition of a project audit, we need to define another term.

Project documentation consists of:

  • the project charter, describing the organization's expectations and the project's objectives;
  • the baseline project plan, which is the project plan that has been agreed and signed off within the organization (rather than any subsequent adjustment to the plan made for the convenience of the project manager);
  • any contracts between the organization and any vendors or external or internal service providers; and
  • any sign off documents for delivery of outputs from the project.

A project audit:
  • determines the current status of a project, in terms of the project documentation;
  • estimates the future status of the project, in terms of the project documentation; and
  • identifies any risks to the project scope, quality, budget and schedule.
A project audit is very much like a financial audit. It tells you what the situation is, and it tells you what the situation is likely to be, at least in the short term, but it does not tell you what you can do about the situation.

A project diagnosis examines the current situation, extrapolates one or more future situations, ascertains where these are likely to place the project at risk, and then suggests ways in which the risks can be managed.

While a project audit is like a financial audit, a project diagnosis is like a medical diagnosis. The diagnostician examines the current situation, works out what could happen in the future, decides if the situation is harmful, and then prescribes appropriate treatments.

Medical Diagnosis

There are some important similarities between a project diagnosis and a medical diagnosis, and they are worth discussing here.

Both include an examination to determine what the current situation is. The medical diagnosis may involve a physical examination, a verbal account of the patient's symptoms, and, on occasion, the involvement of a specialist to determine the situation. The project diagnosis involves a hands-on check of the project, interviews, and, where appropriate, opinion from experts. In the case of a project diagnosis, opinion could be sought from human resources specialists, from other project managers who have worked on similar projects, and from product or service specialists.

Both include reference to previous reports to recall previous diagnoses and the treatments suggested then. A routine medical diagnosis will use, where possible, the patient's notes, held by the patient's own practitioner. A routine project diagnosis, carried out by the project's regular diagnostician, will use previous diagnostic reports.

Both involve discovering if the patient has followed any previously suggested treatments and, if so, what the effects were. The medical diagnostician will refer to the patient's notes and listen to the patient's account of the treatment and its effects. The project diagnostician will refer to previous reports and take evidence about the effects of previous recommendations, where these have been adopted.

  • Neither can force the patient to take the revetments suggested. The medical diagnostician can write a prescription for a patient or arrange for a further consultation, but cannot force the patient to have the prescription filled or to attend the consultation.
  • Both rely on the diagnostician's knowledge of the side-effects of treatments and of the effects of a combination of treatments. There is some difference between a medical and a project diagnosis here. The medical diagnosis can rely upon a pharmacopoeia, which will provide information on the general side-effects that can be expected in most patients, some specific side-effects in particular patients, and other side-effects when one treatment is combined with another. The project diagnostician has no such guide, except for the notebook that each project diagnostician keeps. Project diagnosticians build their own pharmacopoeia, with experience.
  • Both rely on a knowledge of the patient's behaviour towards particular treatments. With a medical treatment, some patients will avoid blood tests or injections; others will forget to take medicines after meals; others will not finish a full course of treatment once they notice their symptoms subsiding. These behaviours should be observed and noted by the diagnostician, so that the treatment can be delivered in an effective way.
  • Both depend on the environment in which they occur. This characteristic overrides all of the others. We shall devote the following section to it.

Diagnostic Environment

The environment may operate on the diagnosis in a number of ways.

  • A medical diagnosis performed during an appointment booked in advance with the patient will be very different from a diagnosis performed under emergency conditions. We have already noted that a patient may not like injections. Under a routine diagnosis, the diagnostician may prescribe an alternative method of delivery. Under emergency conditions, the patient may receive injections anyway, for expediency. A patient in pain is unlikely to quibble about the means of delivery of the treatment.
  • A medical diagnosis performed by the patient's own general practitioner will have access to the patient's notes and the notes on previous problems, treatments and results. A medical diagnosis in an emergency room of a hospital may not have such access and may have to rely upon the patient's own knowledge of treatments and reactions. Where necessary, additional tests may have to be completed to determine the patient's susceptibility and reactions to available treatments.
  • A medical diagnosis performed by the patient's own practitioner is likely to focus on the patient, based on the diagnostician's personal knowledge of that patient, in an attempt to fit the patient's condition with the patient's lifestyle and history. A medical diagnosis performed by another diagnostician is likely to focus on the symptoms, in an attempt to fit the patient's condition with a conditions characteristics and symptoms.

This final point requires emphasis.

It is relatively straightforward for an external consultant to conduct a post-implementation review, to highlight what should have happened and what should happen on future projects, or a project audit, to highlight where the current and future situation differs from expectations.

External consultants conducting a project diagnosis will be forced to act like a medical doctor seeing a patient for the first time. They will need to find out if the patient reacts to particular treatments, if the patient is already receiving treatment, and if the patient has any behaviour which could affect prescribed treatments, such as an aversion to injections or heavy alcohol consumption. For most of this, external consultants will have to rely upon the word of the patient. If a patient does not want to admit to a perceived "weakness", then external consultant may not be aware of it from other means.

External consultants will also apply generic methodologies to project diagnoses. They will tend to check for those conditions that generally apply in patients rather than for those conditions that may apply to this patient.

There is an excellent case for having the equivalent of a family practitioner conduct project diagnoses.

One decision that you may have to make, which will depend upon your own organization, is whether to engage an external consultant who is familiar with your organization for each project diagnosis or to employ your own internal project diagnostician.

Project Diagnosis

We can now state a clear and concise definition of a project diagnosis.

A project diagnosis is a report on the current status of a project. It identifies current and likely future problems.

It suggests actions, based on the nature of the project.

A project diagnosis does not:

  • examine the history of the project to determine what went wrong in the past; nor
  • recommend actions for future projects; nor
  • apply generic solutions.


The opinions expressed are solely those of David Blakey.
Copyright © 1996-2024