Trying to estimate the risks that a project faces helps minimize those risks. It' s highly important to go through a risk assessment period in your initial round of project document formulation and then revisit your initial risk assessment periodically as the project progresses. By doing so, you' l l detect potential trouble spots before they occur, both at project formulation time and during the project.
Risk assessment is a big topic, and there are several questions on the IT Project+ test that ask you about risk. But the single test objective 2.10, with its associated subobjectives, talks about risk effectively enough that you can cover the test' s questions. We' l l take some time here and cover the areas that you' l l be tested on that you need to be concerned about. Keep in mind that one could write an entire book on risk assessment and management—much more than I have space for here—so it ' s worth your while to become familiar with risk assessment as you go forward in your project management career.
Risks can take on a variety of forms. For example, one risk that an IT project might encounter would be changing versions of software used for some facet of the project. The upgrade could require lots of new training, might not provide the capabilities that the project' s deliverables require, or in some other way could interrupt the project process. Or, as another example, a risk might be that you have only one database administrator (DBA) for the entire company and if, God forbid, that person became unavailable, any database development activity on the project would come to a screeching halt.
Consider the impact of having only a single server run the application that your users will be utilizing. The risk associated with this is obvious—if the server fails, users cannot utilize the deliverables the project provided. In your risk assessment, you have near-term and long-term risks in addition to various categories such as people, software, hardware, resource, or time risks.
We start by considering that everything we do in the realm of project management is documented, including our risk assessment documentation. As discussed in A Guide to the Project Management Body of Knowledge and by PACE, most risk assessment comes during the planning phase of the project. There are three essential ingredients to this part of your analysis:
■ Risk identification, where you become aware of a potential risk to the project.
(This is sometimes called simply risk assessment in A Guide to the Project Management Body of Knowledge.)
■ Risk quantification, where you determine the risk, in terms of monetary, resource, or time constraints, and then apply an actual quantity to the risk: "If the project encounters this risk, the cost to the project will be x dollars."
■ Risk response development, where you develop the method by which you' l l respond to the risk if it rears its ugly head. (This step is referred to as risk response planning by A Guide to the Project Management Body of Knowledge.)
In the controlling phase, you' l l utilize risk response control, where you actually put into place the response to the risk that you developed back in the planning phase. This is when you' re forced to pull out the risk response instruction sheet and put down a risk that has materialized.
In less formal terms than those of A Guide to the Project Management Body of Knowledge, the essential ingredients to the risk assessment process that you should cover are, at a very minimum, identifying, prioritizing, then developing your response.
Was this article helpful?