“If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family anatidae on our hands”
Why risk analysis in a project?
At the start of the project we will perform a risk assessment.
‘Risk taking in projects is inevitable since projects are enablers of change and change introduces uncertainty, hence risk. Management of risk should be systematic and not based on chance. It is about the proactive identification, assessment and control of risks that might affect the delivery of the project’s objectives’
Types of projects
Projects fall into different types. With the delivery of business solutions there are projects that are performed regularly. Examples of these are upgrades from one version to another, system redesign, implementation of a new module within an existing suite.
So a new project comes along and what do we do? We look for similarities on work that has been performed previously. However ‘Once people have started thinking about a problem one way, the same mental circuits or pathways get activated and strengthened each time they think about it. This facilitates the retrieval of information. These same pathways, however, also become the mental ruts that make it difficult to reorganize the information mentally so as to see it from a different perspective’
For example consider this project:
It is an upgrade of a finance system from one version to another, with no changes to the chart of accounts. The latest version that has been available for a period of time (so this will not be an early adopter project), the changes to the screen layouts and structure are minimal. The reason for the project is that the legacy version is going out of mainstream support.
When we perform our risks assessment prior experience tells us that a number of risks can be mitigated or are not risks at all. For example:
- There are a number of specialist consultants who understand the software functionality. Skills are not based on a limited pool or single person dependency.
- It is installed at many other locations. Therefore it is proven in other live environments.
- It uses what can be considered standard infrastructure (Microsoft Windows Server, Microsoft SQL Server, IIS) and skills in these areas are widely available.
- There are no changes to the chart of account structure. This significantly simplifies the data migration which will use in built functionality to migrate from one version to another.
- The users are experienced in the existing software so will only need training in new features.
- The method of integration has not changed so any interfaces will need repointing not re-writing.
Sounds easy, like painting by numbers. Now a duck has two legs, feathers, quacks, floats on water, and can fly. We see it looks like a duck and behaves like a duck. Projects might look similar. They may have characteristics seen before. Yet they are not ducks. There are nuances to consider, people issues to understand, timelines, holidays to be taken, environment issues, other projects taking precedence, legal considerations, business as usual that is likely to take priority, and so the list goes on.
When we do our risk assessment, it takes mental strength not to fall into the trap of thinking this was easy before, and it will be easy now. Certainly we can draw comfort that the project has some similarities, but we need to ensure we do not forget the areas that may be different, what are the esoteric points to consider?
