PROJECT PERFECT
Project Management Software
Specialists in Project Infrastructure

Help improve the site. Take a 3 minute survey and receive a free ebook.

"Your top 5 PM Questions Answered"

Click Here

Sign up for our newsletter. Hear about new Project Management White Papers.

When you subscribe you can download a free eBook

Click Here to Join

Email a friend about this site

Get great free widgets at Widgetbox!

Home - White Paper Index
A Different View of Project Risk	First published July 09
Neville Turbit - Project Perfect	Rating
(Download pdf version)

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: Setting context Risk identification Assessment of risk Evaluation of risk Mitigation of risk to an acceptable level The monitoring of risk Review of the whole process	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: Quantitative feedback from the process Piloting innovative ideas and technologies Measurement of the impact of risk on business objectives 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.

To date, 12 people have rated this article. The average rating is 4.58 - Add your rating. Just select a rating and click the button. No other information required.

Only one rating per person is allowed.

Risk Maturity





1	2	3	4	5

Return to the top