Risk - The Complete Tool Set

Project Risk Assessment

Figure 4 shows the different categories of risk in what we call the Risk Wheel plus Personal Risk which should not be forgotten.

Fig. 4 - Different categories of risk

For most business people, there are two different project types. Pure business projects such as implementing a new Equal Employment Opportunity policy and, IT-related projects such as a Customer Relationship Management system. As a result, there are two different Project Risk assessment tools.

IT / Software Project Risk

Software Project Risk assessment is a sub-set of the broader processes of Business Risk management. However in the past, the process of risk assessment in software projects has tended to be intuitive and hidden. This is understandable as risk assessment is generally intuitive. When you are standing on the corner of a busy road intersection, you usually don't pull out your Palm Pilot and load up your Crossing the Road risk assessment tool to formally document that the two-ton Hummer running the red light at 60 mph will really put a dent in your life.

However, as shown in Figure 5, whenever a software guru is asked to estimate how long a project will take, he or she will undertake a most amazing process. In essence, the software person intuitively assesses factors he or she has learnt from bitter experience that will influence the length of the project, assesses the impact of those factors depending on the specific tasks, adjusts the estimates by the relative weights of the factors, assesses the probability of the factors actually occurring, consider how pissed-off they are at present with the state of executive pay and then calculates an adjusted estimate. No wonder computing folks are considered clever!

Fig. 5 - Informal risk assessment

Project Risk management is simply the formalization of a process that has been covert and subjective. As a result, it has been poorly understood, communicated and practiced. (Gratuitous note - many contemporary business and IT project management texts do not even mention risk management.)

When undertaking formal business or software Project Risk management, the risk of a project can be assessed by considering the following risk sub-categories:

• system or product complexity;
• client or target environment; and
• team environment.

System / Product Complexity

It has long been understood that the complexity of the software or product being developed is a key factor in risk, estimation and sizing. For software projects, borrowing from Function Points, Capers Jones and Barry Boehm [op. cit.], the complexity and therefore the risk of a system can generally be evaluated by considering its data complexity i.e. how many inputs, outputs, enquiries, logical internal files and shared files are involved in the system.

Other factors which affect system complexity and therefore risk are:

• function and algorithm complexity;
• complex control, decision exception and/or mathematical operations;
• level of programming language;
• stability of requirements;
• performance requirements;
• high data volume, fast response time, CPU, etc.;
• innovative technology requirements;
• substantial use of tailored or special hardware/software.

By evaluating the intrinsic software complexity, the person or team undertaking risk assessment can predict the risk associated with the product i.e. is it Low, Medium or High risk? It is important that this assessment is undertaken only by considering the software not the team or target environment categories. It is useful to imagine a Museum of Modern Projects; which displayed all systems in Perspex cubes for public appreciation [or horror!]. In this context, you consider your system in comparison with others that you or your organisation has undertaken.

Target / Client Environment

For many projects, the most difficult area of risk is the target area or client group for whom the product is being developed. This is because many of the risks associated with this category are beyond the team's scope of control.

The complexity and risk of the target or client environment is related to the following types of factors:

• the number of different stakeholders, clients, installations (user sites) involved in developing, implementing and using the system;
• the level of client/user knowledge of and participation in the application and the project development process;
• the degree of Project Sponsor buy-in and support;
• the priority and impact of the application within the stakeholder areas; and
• the need for physical restructuring of offices, development of new sites, etc.

Again, as for the other risk categories, when considering the risks associated with the client area, it is important for the project team to consider the client area as independently as possible from the product risks and team risks.

Continuing our Museum metaphor, the next room in the museum contains Perspex cubes containing the various stakeholder groups and Organisations that you and your team members have worked with. It is important here to emphasize that a High Risk Target/Client Environment does not mean that the stakeholder group is hopeless or incompetent. It simply means that "for this project" the stakeholder community does not have the relevant skills, buy-in and so on.

Team Environment

The final category of risk involves the intrinsic risks associated with the project team. As documented by Larry Putnam and Ware Myers (1992) as well as by Boehm and Jones, the most significant factor affecting project productivity, risk and effectiveness is the capability, morale and experience of the team members.

The complexity or risk of the team environment is related to the following types of factors:

• schedules, whether fixed or flexible;
• the experience and likely stability of the project team;
• the development and estimated timeframe of the project;
• use of outside vendors/contractors; and
• the physical team/project environment.

copyright: Thomsett INTERNATIONAL 2010 | contact