As Project Managers on an IT project, we are the gatekeepers of the scope, budget, and schedule. From the project’s beginning to its end, our responsibility is to nip potential issues in the bud. After all, an ounce of protection is worth a pound of cure.
We do not delude ourselves into thinking that no small bumps in the road will ever appear throughout the project. What is the reason for this?
There are no projects without risk
In the IT world, we can honestly say that this is true. In fact, what is this risk? According to the definition, it is ‘(…) an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives1’. Let’s try to break this definition down into prime factors.
‘It is an uncertain event (…) that, if it occurs’ — this means that we are managing potential events, which are events that do not actually exist but could occur (but ideally should not arise at all). It is the anticipation of uncertain, non-existent situations in various project areas — ones that could more or less affect the success of an IT project.
Someone might ask — why spend time and money anticipating and preventing risks instead of focusing on what will bring real value? Maybe nothing will happen? Maybe it is better to concentrate on positive outcomes and not explore something that may not actually even take place? It is important to understand that a ‘it will work out somehow’ attitude, especially in an IT project, is a huge risk itself. It is like going for a bike ride with uninflated wheels and hoping to get to your destination.
How to prepare well for this ride called a project? It may sound trivial, but simply taking a thorough and meticulous approach to planning an entire design endeavour can prove crucial to its success.
Risk management is an integral part of project management
There are several particularly important matters regarding project management. First of all, the project’s goal needs to be defined, along with the criteria and indicators that will later measure its success. Next is the project plan, which is the development of all the relevant steps that the team needs to take to achieve the project objective. The project plan should include:
- the budget, which defines and limits the possible activities,
- the scope, which defines the project size, and its end products,
- a plan for managing the team and project communication,
- a schedule that indicates the beginning and end of the project work,
- milestones, which mark the checkpoints during the project (completion of a group of tasks or start of the next phase of the project),
- final deliverables, i.e. the final objectives to be delivered by the project,
- risks, i.e. everything that can go wrong in a project.
The risk management essence is to try to identify risks at the project’s outset and to assess and plan for their occurrence. In project management, we need to be able to anticipate uncertain, non-existent, simply unpredictable situations. During the project duration, the main task of risk management is to minimise its negative impact on the project objectives achievement by responding to constantly changing project conditions.
Preventing risks is time-consuming and involves additional costs, so it is often marginalised in projects. Not every client wants to delve into the area of problems that may not even happen. This is a complication that can lead to situations in which the client is unaware of how many and what problems exist in the project and, consequently, to downplay their relevance. In contrast, it is important to realise that identifying risks is project management’s one of the most important parts.
Identifying and monitoring project risks
Moving on to the specifics — what are the tools that enable risk management? There is a number of options that can be adapted to the needs of a particular project.
One of the main tools we use and implement in our projects is the Risk Register, which collects and stores information on potential issues in one place and is accessible to all project stakeholders. In such a register, we identify, analyse and resolve risks before they become potential triggers.
To create such a register, one should start by consulting with the working team. The project manager, along with the team, identifies potential risks in various areas early on in the project. It is also a good idea to conduct such an analysis with the client in order to understand not only their expectations, but also their concerns about the project. Throughout the duration of the project, the Risk Register should be constantly updated and monitored by the Project Manager, being in close collaboration with the project stakeholders. It is also worth mentioning that risks can also be positive – in an IT project we call them ‘opportunities’. These types of risks can benefit both the project and its stakeholders – in which case we aim to maximise the opportunities.
In the register, we create a risk map by juxtaposing an assessment of the risk likelihood (e.g. very high, high, medium, low, very low) with an assessment of the specific risk impact on the project (e.g. very high, high, medium, low, very low).
There are three areas on the map:
- risk acceptance (green),
- risks managed by the Project Manager (yellow),
- risk escalation to the Steering Committee (red).
We also determine the risk response category (e.g., acceptance, avoidance, developing a contingency plan, mitigation, transfer) and opportunity response (e.g., sharing, exploitation, rejection).
For example: we identify a risk called delay in signing a contract, which is to start work. Let us assume that the paperwork for signing the contract on the part of the stakeholders affects the timing of the work’s commencement and therefore shifts the further project schedule. We conclude that this risk has a high likelihood and medium impact on the project, classifying it as a risk that requires management. We can respond to this type of risk — in arrangement with the client — with, for example, a transfer, which involves the transfer of responsibility for a particular area to other units. While this does not eliminate the risk, it requires the other party to address the risk and manage its potential consequences.
There are, of course, numerous examples, as there are as many projects as there are cases. However, risk mapping, regardless of the nature and assumptions of the project, is a very good tool for prioritising risks and determining methods to mitigate them.
Types of risks in an IT project
Now that we know how to manage risks, knowing the areas of project risks might be useful. Where is the actual beginning? After all, there are various factors that can affect the project’s course.
Risks can usually be grouped into the following categories:
- risks affecting the project schedule/budget, e.g. risks to the project scope (so-called scope creep, as a result of inadequately defined project objectives in the initial phase), underestimation of costs at the beginning of the project, underestimated scope, prolonged work on tasks,
- technical risks, e.g. system integration problems, application errors, equipment failures,
- data security/cyber-security risks
- human resource risks, e.g. staff turnover, holidays, illness,
- project communication risks,
- human error.
It would be worth discussing each of the risks listed, but let’s take one of the most common project risks — project scope risk/requirements change. What impact can it have?
In the initial phase of cooperation with the client, we try to define the parameters of the project and to specify its scope as accurately as possible.
Very often, there is a desire to add new functionality, optimise a process or change an element. Thanks to our flexible approach, we are prepared for frequent changes; however, it is important to be aware that introducing changes during the course of a project might be risky. Such actions (e.g. the need to rewrite elements that have already been done) can have a negative impact on costs and the fixed budget and schedule, extending the time allocated to development.
Hence, in an agile project where changes are frequent, it is risk management and prediction of possible reactions that are key. For instance, if the need to change a particular functionality arises, which may extend the project delivery date, the appropriate response — agreed with the client — may be, for example, to reduce the delivery time in another area of the project, to drop another functionality, or to postpone its execution to a post-implementation stage. This allows us to stay within the agreed budget and deadline.
Collaboration and communication above all
Throughout the entire process, the Project Manager plays a pivotal role. Not only do they look after the overall wellbeing of the project and keep an eye on its scope, but they are also a key figure when it comes to communication with the client — from the start to the very end of the project. It is the Project Manager who is responsible for the constant exchange of information so that any discrepancies are avoided and the project’s objective — as set at the outset — is achieved.
The Project Manager should not only communicate successes, but also be clear about risks — it is key to make the client aware of how many and which problems to expect in the project. Active collaboration with stakeholders in identifying risks and monitoring them on an ongoing basis is therefore extremely important.
In one of the projects we carried out for our energy client, we identified more than 60 risks throughout the project duration (over two years). Initially, we identified ‘classic’ risks, such as lack of availability of decision-makers or problems with integrations. Risk management proved to be a key element in this project, which not only minimised risks, but also introduced good practices that we later implemented in other projects as well. Importantly, the client was also involved in the joint development of the register. Collaboration in this respect proved to be extremely important, also in the context of there being a divergence in the perception of risks, as something may be a risk for the contractor and not necessarily for the client. Such a register allowed risks to be classified appropriately and to determine what should be addressed first.
Risk Register creates good practices
In the aforementioned project, there were a number of risks that we managed effectively. For example, in terms of the risk of decision-makers being unavailable when they were temporarily absent, a table identifying their replacements was developed. Specifically for this project, risks were also identified in terms of client-side editors learning the new CMS system and bringing content into the production environment themselves. We developed a plan that involved conducting partial training sessions for editors as early as the commissioning stage on the test environment. We also prepared sample pages created by our editors. These pages were produced on the test environment, so that when the client’s editors were working on the production environment, they had the opportunity to see how the various modules were implemented.
The sample pages proved to be a very accurate approach and eventually became good practice that we have used on other projects. Another good practice resulting from risk management, is the continuous process of learning from the experiences of past projects — through these we are able to avoid similar risks in the future and constantly work on improving our risk management strategy.
Summary
Effective risk management can influence the project’s course and its ultimate success. Working together in this area offers great benefits and value to the client — above all transparency and clearly defined actions to impact the final project quality. Risk management is about building a relationship based on efficient management and trust between all stakeholders.
Want to mitigate risks and ensure the success of your IT projects? Contact us via the form below and let our experts help you navigate uncertainties and achieve your project goals with confidence.
Contact Us
- A guide to the project management body of knowledge (PMBOK® guide) – Fifth Edition, 2013, Project Management Institute, Newton Square ↩︎
