Tightrope Risk Analysis

IRM Training - White Paper
Tightrope Risk Analysis

A tool for identifying, analysing & managing risk in a project.
Derrick Brown, Director

Jan Kusiak, General Manager
IRM Training Pty Ltd ABN 56 007 219 589
Suite 209, 620 St Kilda Rd, Melbourne, Vic. 3004, Australia
03 9533 2300
derrickbrown@irm.com.au
jan.kusiak@irm.com.au
Contents
1. INTRODUCTION 2
2. THE PROJECT CHARACTERISTICS CHECK 3
2.1 OVERVIEW 3
2.2 PROJECT CHARACTERISTICS QUESTIONNAIRE 4
2.3 USER ENVIRONMENT 4
2.4 SYSTEM COMPLEXITY 7
2.5 TEAM ENVIRONMENT 10
2.6 SCORE SUMMARY 12
2.7 ANALYSIS 12
3. RISK-REDUCTION 13
3.1 USER ENVIRONMENT 13

3.2 SYSTEM COMPLEXITY 14
3.3 TEAM ENVIRONMENT 14
4. PROJECT PROCESS CHECK 15
4.1 OVERVIEW 15
4.2 IDENTIFY THE KEY PROCESSES AND KEY DELIVERABLES 15
4.3 IDENTIFY THE POTENTIAL CAUSES OF FAILURE 15
4.4 CALCULATE THE RISK PROBABILITY 16
4.5 CALCULATE THE RISK SERIOUSNESS 16
4.6 CALCULATE THE RISK VULNERABILITY 16
4.7 RATE THE RISKS 16
4.8 PLAN ACTIONS TO MINIMISE THE RISK OCCURRENCE 16
4.9 REVIEW THE RISKS 17
4.10 MONITOR THE RISKS 17
5. FEEDBACK 18
© 2002-2007 IRM Training Pty Ltd www.irm.com.au 1

1. Introduction
Managing a project is like walking a tightrope - it is easy to fall off and hurt yourself. However, we
can improve the tightrope and perhaps convert it into a bridge, hence reducing the risk of a
calamity.
The project manager has total responsibility for the success - or failure - of a project. In the initial
burst of enthusiasm - and the likely refusal of management to contemplate failure - it is easy to
overlook the risks. It is the project manager’s responsibility to remain pragmatic, to check out the
viability of the project, and to report any doubts about the wisdom of proceeding to the highest
management level.
We can take two views of project risk:-

• We can analyse the project scope and complexity, the environment and the planned resources -
the project characteristics
• We can analyse the project plans and look at the risks in the project processes
Both views are equally relevant. Each demands a different approach. The two approaches are
described here. You should use them both at key points in your project; the initiation stage, at each
milestone or sign-off point, and whenever the system or the project environment changes.
The results provide indicators as to the overall project risk, and to the possible actions that we can
take to reduce the risk. The project manager should always confer with the project sponsor and
ensure that the risks and implications are understood. Ultimately the project manager is responsible
and so he/she should not proceed with a project where they consider the risks to be unacceptable.

2. The project characteristics check
Overview
The questionnaire provides a formalised way to assess the project characteristics risk. The results
will not be absolute and should not replace the conclusions arrived at by experienced management.
The questions provide a framework to assist management by revealing factors that might otherwise
go unnoticed.
The questionnaire is divided into three sections: The user environment, the system being built, and
the team doing the development. Each project is unique; it consists of a set of people within a
particular organisation with its own culture, its own problems, its own constraints. The questions
may need to be interpreted to suit these conditions. For example, it is possible that more than one
team will be involved in the development. An adjustment to the appropriate question and scores
may be required.
This risk assessment of the characteristics is best carried out by a mixed group - users, management
and team members. The assessment is largely subjective, but a group of people can arrive at
sensible conclusions. The weightings can be modified by choosing intermediate points on the scales
if this seems reasonable. Complete the questionnaire - or as much of it as possible - without
spending too long on any of the questions. Compute the scores. Compare the results with the
scores shown at section 2.3, then use the analysis at section 2.4 to identify the high scoring areas.
Plan actions to reduce the score, following the advice at section 2.5.

Project characteristics questionnaire
Project.............................................................................
User Environment
H M L
1. How committed are the senior user management? 8 6 2
Extremely enthusiastic - L
Supportive - M
Neutral- H
Patchy - add 2 to the score
2. Are the Users knowledgeable about software 4 2 0

development procedures and the standards in use?
Knowledgeable - L
Moderately knowledgeable - M
Little or no knowledge - H
3. Are Users aware of, and prepared to follow the 4 0

Change Control procedures?
Yes- L
No- H
4. What is the priority for the project within the User 8 4 2

area(s)?
High - L
Low- M
Varies according to User - H
5. How critical will the system be to the day to day operations 9 6 2

of the User(s)?
Minor impact - L
Significant impact- M
Major impact - H
6. Are there other outside agencies involved in any agreements, 20 6 0

or with some sort of stake in the project?
None - L
Yes, one - M
Yes, more than one - H

H M L
7. How many separate User areas are involved in 20 12 4
agreements and decision-making?
One - L
Two - M
More than two - H
8. Are any unions involved? 20 10 0
No- L
Yes, one - M
Yes, more than one - H
9. How many different user sites are involved? 6 4 0
One - L
Two or three - M
More than three - H
10. How severe will the disruption and procedural 4 2 0

changes be to the Users?
Minor- L
Significant - M
Major- H
11. Will the User organisation have to change structurally? 16 8 0
Minor- L
Significant - M
Major- H
12. What percentage of existing functions are to be replaced? 6 4 2
Less than 25% - L

26-50%- M
51-100%- H
13. How different is this system from others in use in the 8 4 2

organisation?
Something similar exists - L

Parts exist - M
Nothing like it exists - H

H M L
14. What flexibility is there with the project deadline(s)? 16 6 1
Flexible, they are to be established with the team - L

Firm, already established within organisation and if missed
will impact on operations - M
Fixed by outside agency or other mandate outside
organisation's control - H
15. Is the Project Brief fixed, or is the User prepared to 40 10 0

discuss it as work progresses?
No Project Brief - H
Exists and prepared to discuss - L
Exists but not prepared to discuss - M
16. How much participation are the users committed to? 16 12 4

Expert User(s) committed to significant amount of work - L
Significant responsibilities accepted - M
Responsibilities very limited - H
17. How knowledgeable are the Users in the proposed 10 8 2

application area?
Understand area, and have experience of a previous
implementation- L
Some experience - M
Very limited or no experience - H
18. How knowledgeable are the Users with respect to DP? 12 6 3

Very knowledgeable - L
Some exposure - M
None - H
19. What are the communications like between the 9 6 3

User area(s) and the DP department?
Good- L
Fair- M
Poor- H
20. Is there any new user-controlled technology or 9 0

techniques required?
No- L Yes- H

System Complexity
H M L
1. What state is the system proposal document in? 16 6 2
Complete and acceptable - L

Acceptable but incomplete - M
Incomplete, unavailable or unacceptable - H
2. What is the expected operational life of the system? 12 4 1
One-off operation - L
Short life - M
On-going function - H
3. How critical is the system performance going to be? 16 0
Not critical - L
Critical due to throughput or volume or memory response time - H
4. What is the condition of the documentation for the 12 6 3

existing computer system?
Complete, but may need some work- L

Acceptable, but incomplete - M
None or little available - H
5. What percentage of existing functions are to be replaced? 12 8 4
Less than 25% - L

26-50%- M
More than 50% - H
6. Is there a similar system in existence? 12 6 4
Yes, reasonably similar- L

Some functions exist - M
Nothing like it- H
7. Is the software to be dependent upon hardware? 16 6 0
Hardware independent- L
Partially dependent - M
Wholly dependent - H

H M L
8. Is new hardware required of a type not already used 4 0
within the organisation?
No- L Yes- H
9. Is additional hardware of any sort required for the project? 4 0

No- L Yes- H
10. Approximately how many unique screens will be required? 9 6 3
Less than 10 - L
Between 10 and 30 - M
More than 30 - H
11. Approximately how many unique input/output 9 6 3

transactions are there?
Less than 10 - L
More than 100 - H
12. How big is the initial file conversion job going to be? 8 4 2
Very little or no data to convert - L

One or two files - M
Several large files - H
13. How complex is the data editing task? 12 9 3
Simple - L
Complex - M
Highly complex - H
14. How many unique data items are there in the system? 6 4 2
Less than 100 - L

More than 500 - H
15. Are there any security issues with the data? 10 6 0
None or few of significance - L

One or two significant issues - M
More than two of significance – H

H M L
16. How complex is the algorithmic processing going to be? 16 9 3
Simple - L
Complex- M
Highly complex - H
17. Are there system interfaces? 10 4 0
No, it is a stand-alone system - L

Yes, moderate complexity - M
Yes, complex - H
Add 6 to the score if the interfacing systems are not within the
project team's control.
18. The software will consist of: 6 4 2
An outside package that meets all requirements - L
Some pre-coded parts written within the organisation - M

All or mainly written within the team - H
Add 4 if the software is to come from two sources
19. What experience is there of any software package 16 8 0

incorporated?
It is being used elsewhere in the organisation - L

It has been used on a bureau basis - M
There is personal experience of it - M
No experience of it- H
20. How many programming languages are to be used? 8 0
One - L
More than one - H
21. What level of language will be used? 20 4 2
High level (e.g. Java or VB in web based apps) - L

Medium level (e.g. COBOL in legacy system environments) - M
Low level (e.g. assembler in manufacturing or equipment control systems) - H

Team Environment
H M L
1. What is the priority of the Project within the IT 8 4 2
supplier?
High - L
Medium- M
Low- H
2. How committed is the IT management? 8 6 2
Enthusiastic- L
Supportive- M
Neutral or worse - H
3. What is the total development effort in person-months? 16 8 4
Less than 3 person-months - L

Between 3 and 20 person-months - M
More than 20 person-months - H
4. What is the estimated elapsed project development time? 20 8 4
Less than 3 months - L

Between 3 and 9 months - M
More than 9 months - H
5. How experienced is the project manager? 20 8 4
Experienced with a similar project of this type and size - L

Some experience of managing projects - M
Inexperienced- H
6. How are the team's skills and manpower to be made up? 9 6 3
Full-time team members - L

Part-time or outside specialists - M
Part-time and outside specialists - H
7. What proportion of the team will be from an outside 16 8 0

organisation?
None - L
Less than 25% - M
More than 25% - H

H M L
8. Have the team members worked successfully together before? 12 6 3
All or most - L
Some - M
None - H
9. How knowledgeable is the team in the application area? 12 6 2

Been involved - L
Some have involvement - M
Limited or no involvement - H
10. Is the software environment new to the team? 16 12 0

(Data base, data communications, languages, etc)
None of it - L
Some of it - M
Most of it - H
11. Has a new operating system to be installed: 12 0

No- L
Yes- H
12. Is there any hardware new to the team? 12 6 0
None - L
Peripherals or terminals - M
CPU or comms or combinations - H
13. Is the development team on one site? 12 6 0
One site - L
Two sites - M
More than two sites - H
14. Is there an agreed change control process in use, known 12 6 0

by the team?
No agreed process - H
A process, but not used or known by the team - M
Process used by the team - L
15. Is there an agreed project development process in use? 12 6 0

No agreed process - H
Partial process - M
Good process - L

Score Summary
User Envir System Team Totals

High 245 234 197 676
medium 116 100 96 312
Low 27 34 24 85
Total your scores and enter the result below.
My project: ………….. …………. ………….. ……………
The table shows the maximum scores in each category. Enter the appropriate categories for your
project below. For example, if your project scored 135 in the ‘User Environment’ section, this is a
‘high risk’ category, as the score is above the maximum ‘medium’ score.
My project risks:
…………… ………… ………….. ……………
Notice that your project can be a high risk in one section, but say, a medium risk overall.
Analysis
• If your project scores up to 90 in total, then it is a low risk project. Examine any scores in a
category where the total is above the ‘low’ range shown to see if you can take any risk-reducing
actions.
• If your project scores up to 315 then you have a medium-risk project. Pay attention to the high-
scoring categories.
• A project scoring above 315 is a high-risk project. Pay particular attention to the high-scoring
categories. Actions must be taken to reduce the risk.
• Projects scoring 450 or more are most vulnerable and must be examined most carefully.
• A project scoring above 550 really needs to be re-defined, restructured or even abandoned. This
sort of project has so many risky areas that you really stand very little chance of making it a
success.
• The Risk Analysis should be re-assessed at milestones, when the risks may have changed.

3. Risk-reduction
Your project may score badly in just one category, or in more than one.
User environment
A score of 120 or more means that there are almost certainly actions that can be taken to reduce the
risk. Some of the risk-reducing actions will include:
• User education & training - This may include managing senior management perceptions of
flexibility, managing target dates, change control. It could include education and training in
these topics or in the User Acceptance Testing process, or in specifying User Requirements.
Consider using formal structured techniques for specifying the user needs, rather than English.
• Communications - establishing improved formal and informal communications with senior

managers and stakeholders. Ensure that a Steering Committee is set up with an agreed process
and regular meetings. Other formal groups may be required. If there are many stakeholders,
and/or they are diverse or geographically scattered, then more time and resources will have to be
spent in coordinating responses and obtaining agreements.
• Formalising procedures - Formal agreements and sign-off of key documents, e.g. Project Brief,
Business requirements, formalised change control procedures
.
• Planning - Set up of the steering group or user management structure, paying special attention to
progress reporting. Establish an overall plan for the project, including implementation strategy,
acceptance testing and training strategies. Develop a detailed plan for the first phase only. Use
dependence networks and establish the critical path. Develop plans assuming ‘early starts’.
Establish the optimum resources required, then go and find them. Do not plan on the resources
already allocated.
• Publicity - This may need extra careful planning and execution. Ensure that project progress is
publicised at every opportunity. Invite ideas and feed-back. Give the project an imaginative
name. Put notices on notice boards, in the organisation’s newsletter. Raise the community’s
awareness!

System Complexity
A score of 100 or more here indicates that the scope may be too large, considering the many factors
that are contributing towards the score.
• Scope and boundaries - Re-examine these to see if they are too ambitious. Exclude peripheral
areas. Reduce the user scope, that is, it may be possible to develop a solution for a smaller set of
users. Reduce the functionality. It may be possible to reduce the risk substantially by re-
planning the development on an incremental basis. Focus on asking ‘How little could the project
deliver that would be of benefit, and how soon could we do it?’ Redefine the project to deliver
these basics. Then define a second project to deliver another level of benefits, and a third
project…The projects could run concurrently, each one starting a little later than its predecessor.
The projects could be considered as stages within the same project, but considering them as
different projects makes the whole thing easier to manage and communicate. The projects might
be named xxx version one, xxx version two etc.
• Implementation strategy - Examine this to see if a more conservative approach is possible;

there is often a safer option e.g. pilot, phased, phased pilot etc.
(A pilot implementation is where we implement the system in a small and manageable part of the
business, then extend the implementation gradually. A phased implementation is where we
implement part of the system, then implement further parts. A phased pilot is a combination of
these two.)
• Design strategy - Re-evaluate this. Could a safer strategy be employed, with fewer new tools,
techniques, software? If the project is being used as an organisation or department test-bed for
new processes, tools or documentation methods, consider rejecting these ideas. (This project is
already dangerous enough without having additional burdens placed on the team.)
Team Environment
A score of around 100 is dangerous.
• Project priority - If the project has a low priority and/or has a low commitment from the client
and/or the service provider management, then the cost/benefits should be re-examined. A low
priority project will have its resources ‘stolen’ easily, and will not obtain agreement easily at
milestones. Perhaps the project need not be done, or the benefits need to be emphasised. If it is
worth doing then some communications may be required - publicity, ‘selling’ and persuasion.
• Team structure - If the team structure is a high risk one, then special efforts should be planned
at the beginning of the project in team bonding work. The project manager will need to be good
with inter-personal skills and motivation. If consultants or contract staff are involved, then
attention should be placed on the recruitment process, to ensure that the best people are found,
and retained for the project duration. Training may be required for new software, tools and
techniques, and allowances made in the plan for the learning curve for the skills to sharpen as the

project progresses. Staff may also require some familiarisation in the business application. Where
team members are not located together, or even on the same site, the team
• communications will be fraught with difficulties. Technology helps, but nothing is as effective
as face-to-face discussions. If this situation cannot be avoided, then make plans to ease
communications. Consider appointing someone at each site to co-ordinate local and inter-site
communications. Formalise acknowledgment of formal communications, make plans for inter-
site visits, ensure the budget reflects these extra costs.
• Project size - A large project can be broken into smaller chunks, as above. A large team is more
difficult to manage than a small one. A project with a long duration has a high risk of suffering
from many changes in requirements, and from changes in the client management, the team, and
service-provider management. Any personnel change has an effect on productivity and client
management changes will almost certainly change the project requirements.
4. Project process check
Overview
We perform this risk check with a nine-step process, starting with the project plans. If we are at the
project initiation stage then the plans will be high-level. As the project progresses we shall have
more detailed plans and therefore this process check becomes more useful.
Examine the key processes and the key deliverables. Ask the question ‘What can go wrong here?’
We shall then ascertain the probability of the risk and its seriousness. We then calculate the total
risk vulnerability and produce a ‘league table’. We establish the highest priority risks and then
decide upon the actions to be taken and plan them.
Identify the key processes and key deliverables
Examine the project plans. Identify the major tasks on the plan and the key deliverables. Include
the tasks and deliverables being produced by all the resources, not just those under your direct
control.
Identify the potential causes of failure
Brainstorm with a small group of involved staff. Look at past projects and list what went wrong
with them. History is a good indicator of the future. What will we do to prevent similar problems
from re-occurring? Now look at this project- what can go wrong? Examine the list of tasks and
deliverables. List the effects of a failure on the project and establish the underlying causes. Use the
Cause-Effect analysis technique where there are linked effects and confused causes. Establish a list
of potential causes of failure. Do not attempt to put them into any sequence.

Calculate the risk probability
Looking at each risk in turn, we now establish the probability of that risk occurring. Nominate a
value between 0.1 (low risk) and 0.9 (high risk). ‘1’ is a certainty. Do not spend too long on each
one, just establish a consensus view.
Calculate the risk seriousness
Looking at each risk in turn, we now establish the seriousness of the effect of that risk. Nominate a
value between 0.1 (not very serious) and 0.9 (very serious). ‘1’ is a show-stopper. Again do not
spend too long on each one, just establish a consensus view.
Calculate the risk vulnerability
The risk vulnerability for any one risk is the product of the two values, risk probability and risk
seriousness. For example, if the probability is 0.3 and the seriousness is 0.7, (that is the probability
of this risk occurring is quite low, but it would be fairly serious), then the vulnerability is 0.21.
Rate the risks
Now put the risks in a league table, with the highest values at the top. Given that we probably
cannot plan for all risks, it makes sense to look at the most vulnerable ones. The top 33% or so are
the ones to look at.
Plan actions to minimise the risk occurrence
We do this in two stages; we want to plan to reduce the chance of the risk and to reduce its effect
should it occur anyway. We ask two questions of the top risks:
• What can we do to minimise the chance of the risk occurring?
• What can we do to minimise its effect?
Decide upon the appropriate actions, for example, to check certain results, or to ensure that
particular criteria are set for some deliverable. It is easier to build in quality to the deliverables
when measurable criteria are set at the beginning. Add these actions to your project plans. Very
often the tasks involved are quite small in terms of effort, but significant in terms of results. Risks
are reduced by following an established process or a project methodology. If your organisation has
an agreed project process or methodology, follow it. Your project will gain immeasurably. Do not
be tempted or persuaded to ‘cut corners’ - the risks involved are too great.

Review the risks
Review the risks and the planned actions with your clients. Obtain their feedback. Welcome any
suggested changes, that is partly why you are doing the review. (Another reason is to inform them
as to the risks involved so that they have a better understanding of the process that you are
following and of the need for quality.)
Monitor the risks
At key points you need to check that the risks have not changed in nature. Some will have passed,
some will have disappeared, some will have increased in vulnerability, new ones will have
emerged. Modify your plans accordingly.
The identification, analysis and management of risk is a core topic of IRM’s 3 day training workshop
“Project Management Techniques”. Using Tightrope and practical examples, participants learn the skills
and techniques needed to successfully manage risk in a project environment.
For workshop details and schedules visit: www.irm.com.au

5. Feedback
We welcome your feedback on ‘Tightrope’. If you would complete the questionnaire here we will
take your comments into account in our next release. We guarantee anonymity and we will not
make any results public in any way that can identify you or your organisation. All fields are
optional.
Name: Organisation:
Phone: E-mail:
How was ‘Tightrope’ useful to you?
What did the results disclose to you?
What action was/will be taken as a result of the analysis?
Which was more beneficial, the ‘characteristics’ or the ‘process’ check?
How did your project score on the characteristics check?
User Environment System Team Total
How big is the project? (Complete whatever you can)
Function points:
Duration:
Resource time (People-days or people-weeks):
Type of project (software development, maintenance, implementation, assessment, review, roll-out)
Any further comments?
Thanks for your time. Please return to: Tightrope Response

IRM Training Pty Ltd
Suite 209, 620 St Kilda Rd
Melbourne, Vic 3004
Or e-mail: training@irm.com.au

Tightrope Risk Analysis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tightrope Risk Analysis

Enviado por

Direitos autorais:

Formatos disponíveis

IRM Training - White Paper

Tightrope Risk Analysis

Tightrope Risk Analysis

Derrick Brown, Director

2. THE PROJECT CHARACTERISTICS CHECK 3

3.1 USER ENVIRONMENT 13

4. PROJECT PROCESS CHECK 15

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 1

We can take two views of project risk:-

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 2

2. The project characteristics check

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 3

Project characteristics questionnaire

2. Are the Users knowledgeable about software 4 2 0

3. Are Users aware of, and prepared to follow the 4 0

4. What is the priority for the project within the User 8 4 2

5. How critical will the system be to the day to day operations 9 6 2

6. Are there other outside agencies involved in any agreements, 20 6 0

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 4

8. Are any unions involved? 20 10 0

9. How many different user sites are involved? 6 4 0

10. How severe will the disruption and procedural 4 2 0

11. Will the User organisation have to change structurally? 16 8 0

12. What percentage of existing functions are to be replaced? 6 4 2

Less than 25% - L

13. How different is this system from others in use in the 8 4 2

Something similar exists - L

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 5

Flexible, they are to be established with the team - L

15. Is the Project Brief fixed, or is the User prepared to 40 10 0

16. How much participation are the users committed to? 16 12 4

17. How knowledgeable are the Users in the proposed 10 8 2

18. How knowledgeable are the Users with respect to DP? 12 6 3

19. What are the communications like between the 9 6 3

20. Is there any new user-controlled technology or 9 0

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 6

Complete and acceptable - L

2. What is the expected operational life of the system? 12 4 1

3. How critical is the system performance going to be? 16 0

4. What is the condition of the documentation for the 12 6 3

Complete, but may need some work- L

5. What percentage of existing functions are to be replaced? 12 8 4

Less than 25% - L

6. Is there a similar system in existence? 12 6 4

Yes, reasonably similar- L

7. Is the software to be dependent upon hardware? 16 6 0

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 7

9. Is additional hardware of any sort required for the project? 4 0

10. Approximately how many unique screens will be required? 9 6 3

11. Approximately how many unique input/output 9 6 3

Very little or no data to convert - L

13. How complex is the data editing task? 12 9 3

Less than 100 - L

None or few of significance - L

© 2002-2007 IRM Training Pty Ltd www.irm.com.au 8

17. Are there system interfaces? 10 4 0

No, it is a stand-alone system - L

18. The software will consist of: 6 4 2

An outside package that meets all requirements - L

Some pre-coded parts written within the organisation - M

Add 4 if the software is to come from two sources

19. What experience is there of any software package 16 8 0

It is being used elsewhere in the organisation - L

20. How many programming languages are to be used? 8 0