Little River Software
>
Project Management
| Project Planning | Testing | |
Risk Analysis
There is no substitute for experience.
If the project is very small e.g. "Please write me one function" the risks are fairly clear from the outset, but as the number of people involved increases, the potential for problems grows even faster. The bigger the project, the more important Project Risk management becomes. Below is an example of the risk analysis we like to do for each project. It does not replace an experienced project manager but it goes a long way to identifying and managing the risks in a project.
How to use this page.
Look at the examples of risks below. Not all of these will be appropriate to your project. Most projects will be able to add one or two risks not listed here. The Implications, Chance, Impact and Prevention items will also differ for each project, but are filled in here to give a better idea of how the risk analysis works. We start with the grid below (all except the last 2 columns):
- The "Risks": We look for things that could constitute a risk in the project.
- The "Implications": We ask ourselves what would happen if this Risk materialised.
- The "Chance": We ask ourselves what is the chance that this Risk will occur.
- The "Impact": How serious is the Risk if it does occur.
- The "Prevention": How can we prevent the Risk from ever occurring.
Once the project is underway we create a new column each time we re-evaluate the project risks.
- We hope to see lower chances of a Risk occurring each time we do a review.
- You could sort these risks, or cross reference them (look for dependencies), or allocate the management of specific risks to different people.
- The bigger the project, the more effort will be required for proper Risk Management.
- Sadly this is a somewhat negative way of looking at a project. If someone finds a more positive way, please let us know, we like to learn new things.
| Risk | Implication Of Risk | Chance Of Risk Occurring | Risk Impact Level | Preventative Action | Status at Project Launch (07-Jul-2018) |
Status at (20-Jul-2018) |
|
| 1 | Poor User Buy in | Implementation Slow or unsuccessful | Low | High | User Involvement, Training, Communication | Very Low Risk | Very Low Risk |
| 2 | No Deliverables | Project Success cannot be measured | Medium | Low | Management agreement to Scope and Project Plan | Risk now applicable to Management reports only. | Deliverables well understood, Risk now V-Low. |
| 3 | Poorly defined objectives or scope | Measurement of project success is difficult, and the potential exists for conflict between the implementers and the end users. | Medium | Low | Clearly agree business objectives before implementation begins. | Risk now applicable to ongoing training only - who takes responsibility. | Training is the only problem Area, Client wants eternal free training. |
| 4 | Business processes and requirements not understood or defined. | Implementation team will make assumptions that may later not be acceptable to the business. | High | High | Project team assists users to define and understand their business objectives | Risk Low | Risk Low |
| 5 | Changing Timeframes or requirements | Insufficient time for tasks, tasks not completed, deadlines missed | High | Medium | Keep to plan. Clearly define the objectives to control this risk | Low | Medium - Dialup Customers still a problem, and threatening deadlines |
| 6 | Internal Staffing Insufficient | Project completes on time, but system suffers in the long term | High | High | Source Internal staff early in project | High | Medium |
| 7 | User Roles are changing | Following the merger, the users are unsure of their responsibilities, amplified by a simultaneous change in IT systems, a cause of poor buy in and poor user involvement. | High | High | Treat changing roles separately from Implementation, Do NOT make assumptions about prior experience at 'doing the job' | Changing Roles Still in Flux | Changing Roles Still in Flux - Raised Issue at Board Meeting |
| 8 | Poor Communication | Users and Management not informed about their responsibilities, a cause of poor buy in and poor user involvement. | Medium | High | Establish a full list of all users and interested parties, and communicate often with all of them. | Manageable Risk. | Manageable Risk. |
| 9 | Deadlines missed | Management dissatisfied with slow delivery, possibility for project to lose direction. | Medium | Low | Manage the Risks | Manageable Risk. | Manageable Risk. |
| 10 | Slow User Uptake | Implementation Slow or unsuccessful, Deadlines missed | Medium | Medium | Early Communication with Users, giving clear understanding of their responsibilities. User Training | Risk increasing due to Dial-Up problems | Risk increasing due to Dial-Up problems |
| 11 | Infrastructure not ready | Deadline Missed | Medium | Medium | Prepare Infrastructure early. | Risk has occurred, due to late delivery of Network components | Risk has occurred, but we are catching up. |
| 12 | Implementation Slow | Deadline Missed | Medium | Medium | Keep to Plan | low risk, except for Dial Up issue | low risk, except for Dial Up issue |
| 13 | Over detailed Analysis | Project never covers all the issues because of too much focus on some issues | Low | Low | Keep Analysis general at first and become more focused as full picture emerges. | low risk | low risk |
| 14 | Poor definition of priorities | An relatively minor task is completed at the expense of a critical one | Low | Low | Keep to proper (predefined) priorities and monitor project plan. | no risk | no risk |
| 15 | Test run too short | Problems after going live, Project meets deadline, but starts off with a rough first month. | Low | Low | Keep to Plan, and have a test run for every department, every user group and every site | Test Run scheduled. | Test Run scheduled. |
| 16 | Inter-Departmental disagreements | No clear understanding of what each department must do and therefore a poor definition of Requirements. Also results in a slow resolution of issues. | Unknown | Medium | User Involvement, Careful Project Management and drive the decision making from the top | Reducing, The staff reallocations have been published. | Reducing, The staff re-training is almost complete. |
| 17 | Responsibility Avoidance | The proper individuals or departments avoid taking responsibility for their work. Or the Customer Company as a whole attempts to shift the responsibility for managing their business onto the solution provider. | High | High | Internal Management must accept responsibility for the business, and drive the responsibility through the company. | Medium | High - Dept-X provides data to Dept-Y but will not acknowledge that errors in Dept-Y reports flow from Dept-X Data Capture Errors. Issue passed to Upper Management. |
The point of a risk analysis is to identify risks early on and then to manange them as the project proceeds. New risks may arise and need to get dealt with, but just as important, new risks need to get added to your list for the next project.
| Project Planning | Testing | |