Home Career

There are some skills that a diagnostician requires.

Criticality and urgency

The diagnostician must be able to see the difference between issues that are critical and those that are urgent.

Often, the project participants will be able to see only the urgent issues: the ones that require action now. They may ignore the critical issues: the ones that will affect whether the project is successful.

In projects that have tight schedules, there is likely to be a greater focus on the urgent rather than the critical issues. This will not have an adverse impact on the project if all the critical issues are urgent. Where there are critical issues that do not have urgency, these may be lost.

On a project, at any given point, a chart of the criticality and urgency of each issue can be made.

Figure 107.1: Criticality and urgency

As this is a software development project, the software will remain critical to the project's success. At this point, the software is regarded as urgent, as it usually is throughout a software development project. This is unlikely to change throughout the project.

The documentation is as critical to the success of the project as the software that it supports, but it has a very low urgency. This can often be because the development of documentation is left to the end of the project. Another contributory factor is that software development teams may not enjoy writing documentation as much as they enjoy developing software.

The training is slightly less critical to the success of the project than the documentation and the software, although it still has a high level of criticality. It has a higher urgency than the documentation, however. This may be because the project team knows that training will have to be delivered before the project is closed and that the training must be satisfactory; the delivery and training will a "test" of the project team. The documentation, on the other hand, can be written very much at the will of the project team. It is unlikely to be read or reviewed by the project owner. It will not be a test of the project team, and can therefore be, to a great extent, ignored.

For some reason, the development of online help is not critical to the project. It is not viewed as urgent. The upgrade of the servers for the new software is not critical to the success of the project. The project's major deliverables are the software, training and documentation. Upgrading servers is an activity that can be undertaken after the project, as far as the project owner is concerned. There may even be a separate project to determine the specifications for the new servers. The server upgrade has somehow managed to become urgent; it is something that the project team needs to do, even though the project does not need it.

This is a perfectly reasonable scenario. It is not unusual to set up a project so that users can have a broader range of facilities or a better presentation, even though they know that their response times may degrade. The main priority of the organization is to provide the new facilities and get them "bedded in", especially if processes have to be changed or extended as a result. Making the software run faster may be delayed until practical experience has revealed the demands that will actually be made upon the servers.

The project team may want more powerful servers so that they can develop the software faster. The argument will be that the servers will be useful when the software is used, so acquiring them now will be a double advantage: the application will have the power it needs to run well, and the software will be developed faster.

Sunk and future costs

We have already looked at four catastrophic scenarios, and it will be useful to review them here, to understand how a project diagnostician should view sunk and future costs.

1. If a project will never be completed, management is likely to recognize that the sunk costs (the costs already incurred) may have to be written off and the project terminated.
2. If a project may not be completed by certain critical dates, it may again be easily recognized by management that the project should be wound up and the sunk costs written off.
3. If the projected cost of the project exceeds its potential value, this may be a more difficult situation for management to grasp. All of the costs to date may have to be sunk, and only the total costs of completing the project taken into consideration. The diagnostician may often have to persuade management to look at the project costs in this way.
4. Again, where the deliverables are so poor as to be useless, the diagnostician may have to persuade management not to "throw good money after bad" in attempting to improve the deliverables without proper regard to the costs of doing so.

Here are two examples:

• A project will cost $1,000,000 in total, with $100,000 already spent. The diagnosis determines that the value of the project will be below the original expectation, at only $800,000. Management may be prepared to accept the $100,000 as a sunk cost, rather than continuing with an additional expenditure of $900,000 to lose $200,000.
• The project will still cost $1,000,000, but now $300,000 has already been already spent. Now, when the diagnosis reveals the value of the project as $800,000, management may be tempted to spend the additional $700,000 to complete the project.

In fact, the following should apply.

1. The project should be one where an investment is being made to create an asset. This will not apply to projects for risk avoidance or for the development of future platforms which are not expected to produce any return in the short term.
2. The "cost to completion" is the amount that will have to be spent in future to complete the project. Costs already incurred will not be considered.
3. The "project value" is the value of the asset that will be created by the project.
4. For any project diagnosis, at any stage of the project, the project should be examined closely if the cost to completion exceeds the project value.

Thus, in the first example above, the cost to completion is $900,000 and the project value is $800,000; the project should be considered for termination.

In the second example, the cost to completion is $700,000 and the project value is $800,000; on this basis, the project should continue.

The diagnostician may have to ensure that this view, of cost to completion versus project value, is sustained by management and that decisions are made accordingly.

The rules apply in all cases, whether it is an increase in the projected future expenditure on the project or a fall in the projected asset value from the project.