A Different View of Project Risk
Overview
There are lots of articles and white papers on risk management on the web. This white paper on risk takes a different perspective. It looks at risk in three dimensions.
- Corporate Risk Maturity
- Project Riskiness
- Project Risks.
It will make your view of risk management more complete, by providing a context to assess the organisation’s attitude to risk.
Corporate Risk Maturity
A while back, I was looking at an organisation and how they managed risk. They considered themselves good at risk management as they were involved in an industry that had lots of risky activities. When I asked them why they were good at risk management, they said “We haven’t had a death in about four years.”
Their view of risk was it revolved around occupational health and safety. Some other questions to their senior executives were quite revealing.
On corporate risk:
Q. Do you do a risk assessment as part of your corporate planning?
A. We did a few years back.
Q. What happened after the assessment?
A. Good question. Not really sure. Must go back and have a look at it.
On management risk:
Q. Do you have a policy about staff travel to avoid risk?
A. Not really. In fact our 20 senior executives recently flew to a conference on the one aircraft.
On acquisitions:
Q. Do you do a risk assessment on the companies you purchase?
A. Why. We know a good deal about them before we buy them.
On projects:
Q. Do you do a risk assessment for all projects?
A. The IT people seem to, but it is really up to the Project Manager. I suppose if it is a complex project they might.
And so it went. It was not that they were being lax. They didn’t really see the benefit of carrying out risk assessment. It was a case of lack of risk maturity.
Risk Maturity Model
To illustrate the situation to management, I did some extrapolation from CMM – the Capability Maturity Model. I added a Risk Maturity model as below.
|
|
Description |
Processes |
People |
Scope |
| 1. Initial | The decision support process for managing risk is characterised as ad hoc, and occasionally even chaotic. | Few processes are defined and success depends on the individual’s abilities and experience. | Remove an individual and the processes may change dramatically commiserate with the next individual’s level of ability & experience | Typically only dangerous or potentially dangerous areas are addressed for risk. The focus is to ensure the company meets legislative requirements. |
| 2. Repeatable | Basic management processes are established to document the management of the organisation. | The necessary process discipline is in place to repeat earlier successes on similar tasks, based on the previous experience of the organisation.
A risk framework is put in place. |
Ad hoc training provided but no mandatory or monitored attendance. Risk mitigation is identified but not necessarily implemented. | Similar scope to Initial. The focus is on safety although there is the beginning of a cultural change from ‘must do’ to ‘should do’ |
| 3. Defined | The process for standardising, documenting, integrating risk management into the normal decision-making processes of the organisation. Requires standardised business process models to be in place. | All decisions use the approved detailed version of the organisation’s standard risk management process for decision-making. Process not necessarily fully audited. | Mandatory training required across all areas of the company.
Process owners drive risk management of their processes. |
Focus on OH&S area. Some work at the project and environmental level, but not necessarily fully implemented at the business level. Exception at the business level may be financial compliance activities (e.g. SOX) |
| 4. Managed | There are detailed risk measures applied to all management decisions. A formal process of managing risk and the quality of the risk management planning, includes:
|
All business processes and the output products or services are quantitatively understood and controlled. There are penalties for non compliance. Audit is a regular, ongoing activity. | Cultural change where everyone focuses on risk as a significant part of their job. Risk management is seen by employees and customers as giving the organisation a competitive advantage. | All areas of the organisation participate in Enterprise Risk Management (ERM). This includes OH&S, Environmental, Business, Technology, Financial, Legal, Strategic Planning and Audit.
IT systems actively support risk management. |
| 5. Optimising | Continuous process improvement is enabled by:
Organisation seen as a leader in risk management. |
All decisions within the company – operational and business – do not proceed without a risk review. Risks are examined for implications outside their immediate area.
Risk measurement is a KPI for all business units. |
Matrix approach to risk. All employees required to look both within and outside their area to improve risk management. Business structure and systems designed to support risk management e.g. risk committees, departmental compliance audit roles. | There are no boundaries for risk. The organisation treats every activity as one where risk is an integral part, and must be managed.
Business Continuity and Disaster Recovery Planning is in place and regularly tested. Process and technology change is subject to risk management. |
Corporate Risk Context
The first layer of risk is the Corporate Maturity. If you are working in a project, you need to ask yourself what the level of risk maturity the company has achieved. A lower level will indicate that risk is not taken seriously. A cavalier attitude to projects is likely to exist, and the organisation will likely ignore a strongly disciplined approach to project risk management. You have a hard selling job on your hands.
Project Riskiness
When you first look at a project, it might be a straight forward project with little chance of failure, or a highly risky project with a high potential for failure. This is the second layer. You can develop a model to rate the project regardless of the type. The following assessment is for an IT project but most of it could apply to any project.
This assessment which we developed for a client some years ago, determines if the project is small, medium, high or very high in terms of risk.
|
|
PROJECT TYPE ASSESSMENT FORM |
|
||
|
|
|
|
|
|
| PROJECT NAME |
|
|
|
|
|
|
|
|
|
|
| Product/System Risk |
|
|
|
|
|
|
|
Total |
0 |
|
| Overall |
1 |
Simple | ||
| System/Service/Product |
2 |
Some complexity but understood | ||
|
|
3 |
Some complexity and not understood | ||
|
|
4 |
Highly complex but understood | ||
|
|
5 |
Highly complex and not understood |
0 |
|
| Logical Data (inc Files) |
1 |
Simple data with few variables and low complexity | ||
|
|
2 |
Numerous variables, with simple relationships | ||
|
|
3 |
Multiple files, fields and data relationships | ||
|
|
4 |
Complex file structures and data interactions | ||
|
|
5 |
Very complex file structures and data interactions |
0 |
|
| I/O and inquiries or |
1 |
Not critical to the business | ||
| organisational impact |
2 |
Important but not necessary for day to day operation | ||
|
|
3 |
Would cause pain if the system was not there | ||
|
|
4 |
Important for day to day operation | ||
|
|
5 |
Mission critical system |
0 |
|
| Interfaces to other |
1 |
Stand alone system | ||
| systems/services/products |
2 |
Few systems under the teams control | ||
|
|
3 |
Few systems under others control | ||
|
|
4 |
Complex systems under the teams control | ||
|
|
5 |
Complex systems under others control |
0 |
|
| Functions and processes |
1 |
Simple algorithms and simple calculations | ||
|
|
2 |
Majority of simple algorithms and calculations | ||
|
|
3 |
Algorithms and calculations of average complexity | ||
|
|
4 |
Some difficult algorithms and complex calculations | ||
|
|
5 |
Many difficult algorithms and complex calculations |
0 |
|
| New business |
1 |
No change to business procedures | ||
| procedures/alterations |
2 |
Minor changes | ||
|
|
3 |
Some changes to particular areas | ||
|
|
4 |
Major changes | ||
|
|
5 |
Completely new procedures |
0 |
|
| Stability of requirements |
1 |
Stable | ||
|
|
2 |
Firm but exposed to change | ||
|
|
3 |
Firm but likely to change | ||
|
|
4 |
Not documented but relatively straight forward | ||
|
|
5 |
Unknown |
0 |
|
| Performance requirements |
1 |
No special performance requirements stated by user | ||
| (including quality) |
2 |
Performance requirements were stated but no special actions required | ||
|
|
3 |
Response time or throughput is critical during peak hours | ||
|
|
4 |
Response time or throughput is critical during all business hours | ||
|
|
5 |
Stated user requirements require performance analysis tasks during design phase |
0 |
|
| Technology requirements |
1 |
No new technology. Skills available | ||
|
|
2 |
Significant skills available internally to manage technology | ||
|
|
3 |
Significant skills in the market to manage technology | ||
|
|
4 |
Some skills in the market to manage technology | ||
|
|
5 |
Limited skills in the market to manage technology |
0 |
|
| Level of technical innovation |
1 |
None | ||
|
|
2 |
Simple. Been done before internally | ||
|
|
3 |
Average. Been done internally/externally before | ||
|
|
4 |
Extensive. Has been done somewhere before. | ||
|
|
5 |
Very innovative. Not been done before. |
0 |
|
|
|
|
|
|
|
| Team Risk |
|
|
|
|
|
|
|
|
|
|
| Intrinsic team skills (general |
1 |
All expert with previous project experience | ||
| skills) |
2 |
Some expert with previous project experience | ||
|
|
3 |
All knowledgeable with some previous experience | ||
|
|
4 |
Some knowledgeable with some previous experience | ||
|
|
5 |
Novice with no previous experinece |
0 |
|
| Relevant skill level with |
1 |
All expert with previous application/product experience | ||
| application/product |
2 |
Some expert with previous application/product experience | ||
|
|
3 |
All knowledgeable with some application/product experience | ||
|
|
4 |
Some knowledgeable with some application/product experience | ||
|
|
5 |
Novice with no application/product experience |
0 |
|
| Project manager experience |
1 |
PM with successful recent experience in similar project in SW | ||
|
|
2 |
PM with successful recent experience in similar project externally | ||
|
|
3 |
PM with successful recent experience | ||
|
|
4 |
PM with theoretical PM knowledge but little experience | ||
|
|
5 |
Inexperienced PM with little PM knowledge |
0 |
|
| Project staffing level |
1 |
1 | ||
|
|
2 |
2 to 3 | ||
|
|
3 |
4 to 6 | ||
|
|
4 |
7 to 10 | ||
|
|
5 |
Over 10 |
0 |
|
| Use of contractors/part-time |
1 |
Less than 25% external | ||
| members |
2 |
25% to 50% external | ||
|
|
3 |
50% to 75% external | ||
|
|
4 |
75% to 90% external | ||
|
|
5 |
More than 90% external |
0 |
|
| Project development length |
1 |
Less than 3 months | ||
|
|
2 |
3 to 6 months | ||
|
|
3 |
6 to 9 months | ||
|
|
4 |
9 to 12 months | ||
|
|
5 |
Over 12 months |
0 |
|
| Schedules/deadlines |
1 |
Flexible but established with the team on a phase by phase basis | ||
|
|
2 |
Flexible but established with the team for the project | ||
|
|
3 |
Firm but missed dates may impact the client operations | ||
|
|
4 |
Fixed within the organisation | ||
|
|
5 |
Fixed. Outside organisational control |
0 |
|
| Priority of project for team |
1 |
Only priority for the team | ||
|
|
2 |
High priority for most of the team | ||
|
|
3 |
Medium priority for most of the team | ||
|
|
4 |
Low priority for most of the team | ||
|
|
5 |
Not a priority for most of the team |
0 |
|
| Team experience with hardware/software or |
1 |
All expert with previous hardware/software/technology experience | ||
| technology |
2 |
Some expert with previous hardware/software/technology experience | ||
|
|
3 |
All knowledgeable with some hardware/software/technology experience | ||
|
|
4 |
Some knowledgeable with some hardware/software/technology experience | ||
|
|
5 |
Novice with no hardware/software/technology experinece |
0 |
|
| Project team physical/support |
1 |
Team co-located with all facilities required | ||
| environment |
2 |
Team co-located with some of the facilities required | ||
|
|
3 |
Same building with all facilities required | ||
|
|
4 |
Same building with some facilities required | ||
|
|
5 |
Different locations |
0 |
|
|
|
|
|
|
|
| Environmental/Target Risk |
|
|
|
|
|
|
|
|
|
|
| Level of client/user support |
1 |
Enthusiastic | ||
|
|
2 |
Supportive | ||
|
|
3 |
Neutral | ||
|
|
4 |
Low | ||
|
|
5 |
Negative/Resistance |
0 |
|
| Client experience with |
1 |
All expert with previous product/system experience | ||
| product/system |
2 |
Some expert with previous product/system experience | ||
|
|
3 |
All knowledgeable with some product/system experience | ||
|
|
4 |
Some knowledgeable with some product/system experience | ||
|
|
5 |
Novice with no product/system experinece |
0 |
|
| Client Project Sponsor support |
1 |
Enthusiastic | ||
|
|
2 |
Supportive | ||
|
|
3 |
Neutral | ||
|
|
4 |
Low | ||
|
|
5 |
Negative/Resistance |
0 |
|
| Impact on client operations |
1 |
Minor impact | ||
| (New technology, policy, etc.) |
2 |
Some impact | ||
|
|
3 |
Significant Impact | ||
|
|
4 |
Critical to operations | ||
|
|
5 |
Showstopper |
0 |
|
| Client/business expert |
1 |
Full time experts available (several experts) | ||
| participation |
2 |
Full time expert available (one expert) | ||
|
|
3 |
Part time expert(s) available | ||
|
|
4 |
Ad-hoc participation | ||
|
|
5 |
None |
0 |
|
| Key stakeholders |
1 |
1 | ||
| (Critical and essential) |
2 |
2 to 3 | ||
|
|
3 |
4 to 6 | ||
|
|
4 |
7 to 10 | ||
|
|
5 |
Over 10 |
0 |
|
|
|
|
|
|
|
|
Minimum score |
26 |
26 questions x 1 |
|
|
|
Maximum score |
130 |
26 questions x 5 |
|
|
|
|
|
|
|
|
|
Small |
|
if score < 51 |
|
|
|
Medium |
|
if score > 50 |
|
|
|
Large |
|
if score > 80 |
|
|
|
Very large |
|
if score >110 |
|
|
|
|
|
|
|
|
Riskiness Context
If a project is high or very high in terms of riskiness, there are going to be lots more risks to manage. A Project Manager will need to devote much more of his or her time to avoiding pitfalls. In an immature organisation, this is a recipe for disaster. The organisation does not want to know about risk, and will not be as supportive as a more mature organisation. The Project Manager will be under pressure to just get on with the job, and not waste time mitigating risks. The end is almost inevitable. A risk will come to fruition and who will be blamed?
Project Risk
As I said, there are lots of articles on how to do a project risk assessment. The point of this article is to understand the environment in which you are working. Often the crunch comes between pragmatism and professionalism.
I don’t have a magic solution. I have compromised my professionalism in the past, and I have walked away from projects in the past. It is up to each person, in each situation to make that call.
Conclusion
The point of this article is to make people realise that project risks happen in a context. You as a Project Manager have very little control over the environment. You need to understand the environment and make a decision as to whether you want to operate within that environment. If nothing else, I hope this white paper on risk has raised some questions that you may not have asked yourself in the past.
Copyright Project Perfect