The nature of risk

For the purpose of identifying and managing those risks that may cause a project to overrun its time-scale or budget, it is convenient to identify three types of risk:

Identity project infrastructure

Analyse project characteristics

Figure 7.1 Risk analysis is carried ant in Steps 3 and 6.

/^Estimate effort for activity


/ Identity activ*y risks


/ Allocate resources


/ Review publicize plan

For each activity

Figure 7.1 Risk analysis is carried ant in Steps 3 and 6.

Improved quality control should make it easier to predict the time required for program and system testing.

• those caused by the inherent difficulties of estimation;

• those due to assumptions made during the planning process;

• those of unforeseen (or at least unplanned) events occurring.

Estimation errors

Some tasks are harder to estimate than others because of the lack of experience of similar tasks or because of the nature of a task. Producing a set of user manuals is reasonably straightforward and, given that we have carried out similar tasks previously, we should be able to estimate with some degree of accuracy how long it will take and how much it will cost. On the other hand, the time required for program testing and debugging, might be difficult to predict with a similar degree of accuracy - even if we have written similar programs in the past.

Estimation can be improved by analysing historic data for similar activities and See Chapter 5 for similar systems. Keeping records comparing our original estimates w ith the final methods of estimation, outcome will reveal the type of tasks that are difficult to estimate correctly.

Planning assumptions

At every stage during planning, assumptions are made which, if not valid, may put the plan at risk. Our activity network, for example, is likely to be built on the assumption of using a particular design methodology - which may be subsequently changed. We generally assume that, following coding, a module will be tested and then integrated w ith others - we might not plan for module testing show ing up the need for changes in the original design but, in the event, it might happen.

At each stage in the planning process, it is important to list explicitly all of the assumptions that have been made and identify what effects they might have on the plan if they are inappropriate.


Some eventualities might never be foreseen and we can only resign ourselves to the fact that unimaginable things do, sometimes, happen. They are, however, very rare. The majority of unexpected events can, in fact, be identified - the requirements specification might be altered after some of the modules have been coded, the senior programmer might take maternity leave, the required hardware might not be delivered on time. Such events do happen from time to time and, although the likelihood of any one of them happening during a particular project may be relatively low, they must be considered and planned for.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment