Step 6 – Re-planning Project planning

4.4 Risk management 81 risks at the project’s outset and the control of those risks as the project unfolds. As you undertake the stages of project management you will also be incorporating the activities of the risk management process. In this section we introduce a risk management process that you can use to manage and control risks within your own project. The four main stages of this risk management process are:

1. Identify risks

2. Assess impact of risks

3. Alleviate critical risks

4. Control risks.

4.4.2 Identify risks

As you are putting together your project plan, you should also be identifying any sources of risk to your project. These risks can be individual events event-driven risks – acute that might have an impact on your project for example, your supervisor leaving, your hard disk crashing, etc. or they may be longer term risks that evolve over time evolving risks – chronic before eventually coming to a head for example, underestimating the time it will take you to develop part of your system, deteriorating relationship with your client, etc.. Whether the risks to your project are event-driven or evolving, they can be further classified as either technical or non-technical risks. Technical risks refer to any risks that are associated with the hardware or software you might be using. For example, will there be problems interfacing the components of the software and hardware system you are developing? How well do you know the programming language and platform you are going to work with? Is your project dependent on the development of an algorithm that may be difficult, if not impossible, to develop? Is the specification for the system clear? Are the requirements likely to change? Is the project beyond your technical ability? What are the chances of your hard disk crashing and you losing all your data? Non-technical risks are all other risks associated with your project. These can include such things as losing your client, your user or your supervisor; illness; over-running your time estimates; discovering work during your literature search that already covers in depth what you intended to do; etc. As well as identifying potential risks to your project it is also useful to identify risk triggers sometimes called risk symptoms at this stage too. Risk triggers are events or things that happen during the course of your project not necessarily ‘bad’ things that might give an indication that something is wrong or that one of the risks you have identified is increasingly likely to occur. They are useful in that they give you warning, ahead of time, that something will happen and you can be better prepared to deal with it when it does. For example, missing preliminary milestones in your project is a good indication that your project is going to over-run; struggling with a straight-forward implementation of a component in a new programming language will probably mean you will encounter severe implementation difficulties later on; having difficulty in arranging a meeting with your client early on may be a good indicator that she may be difficult to contact and meet later when you are desperate for feedback towards the end of your project.