Risks in Project Delivery

A project delivery risk is an uncertain event that might occur and will have an effect on achieving the project objectives.

Risk = probability of occurrence * magnitude of impact

We measure risk using a combination of probability of a perceived threat or opportunity occurring and the magnitude of its impact on objectives. There are many types of risk that impact project delivery, resulting in elevated cost, duration, quality and many other factors (reputation, performance, usability, effectiveness of the solution).

Fundamentally there is a level of risk that cannot be avoided. In these cases, the only option is to move the risk to minimise the impact.

To manage your project delivery risk you can read and benefit from this point of view, or use a Responsiv Consulting Outcome based contract to place most of the delivery risks onto Responsiv!

Here are 10 ways to manage project delivery risk and some guidance on how to manage them.

1. Lack of Communication

A project team often contains a diverse group of people from the design phase to production. The success of a project is highly dependent on efficient communication between the team members.

A successful project requires great communicators and there are various different ways to facilitate that. For example, a project stand-up where all the team members come together for a time-boxed meeting of perhaps 10–15 mins.

During this time the team members will address the following questions:

  • What did you do yesterday?
  • What is your plan for the day and are there any blockers that are impacting the project goal?

2. Record Risk

It is important to monitor and record all the risks and issues associated with a project. To achieve this, you will be able to make use of risk registers.

A risk register is a tool that can be used to identify all the potential risks or issues, and help to manage them. You will be able use either a spreadsheet or any project delivery /management software to monitor this. Once you have identified the risk or issue, record that within the software or excel.

3. Prioritise Risk

When a risk has been recorded in the risk register it should be prioritised by determining the level of potential impact. Spend time to analyse the risk and likely (not worst possible) impact.

By categorising risks as being Low, Medium, or High impact according to how the risk will be managed. The project can then agree a policy for each category.

  • Low-Impact risk may not have a significant impact on the project, but it will need to be monitored and managed.
  • Medium-Impact risk may have a substantial impact on the project budget but “it’s only money” and is inside the ability of the company to manage.
  • High-Impact risk may have a substantial impact on the project timescales and efficacy, including reputational damage.

The following questions can be asked while categorising them into high vs low degree risk.

  • What is the risk impact on the project and/or product?
  • Are the stakeholders aware of the risk?
  • How important is the risk to the customer?
  • Will there be any direct impact on the relationship with the customer?

4. Establish the Likely Impact

Assessing the likely impact will allow you to take adequate steps to resolve the risk and will allow you to incorporate the impacts on budget, deadlines and in the project overall.

For each risk, provide an assessment of impact on a scale between 1 and 5 where 1 is low and 5 is high based on:

  • The probability of the risk materialising
  • The impact of the risk occurring
  • Impact of the risk on the project delivery

5. Risk Owner

Once the team have identified a risk, the project manager will need to assign a person who is responsible for that risk.

The “risk owner” is responsible for minimising the risk to the project. They are responsible to assessing the risk and reporting to the project manager on a regular basis or when the risk profile has materially changed.

6. Regular Risk Reviews

Risks are continually added to the risk register throughout the project life cycle.

The register should be reviewed on a regular basis to help the team evaluate project exposure across all risks. For example, review the register on a monthly basis and establish any action that need to be taken.

7. Defensive Documentation

From project start-up to closure there is various documentation required to plan and control, as well as to record the project progression.

The documentation will help to track the project process, decisions made, and contractual agreements. Documents created during the planning phase e.g., requirement and design specifications must be approved by the authorised member within the organisation.

  • It is good practice to obtain written authorisation to proceed from the project sponsor (customer) prior to the implementation phase.
  • Any contractual document sent to the customer must be signed off by the authorised project members.
  • Any document that is developed as a part of the project must be maintained in the project folder.

Documentation is a fundamental way to manage the risk of mismatched expectations, solving the wrong problems, unexpected delays, and customer refusal to accept the project outputs.

8. Resource Risk

Resource risk occurs when there is lack of resources to deliver the project. To mitigate this the project manager must ensure that the resource plan is scheduled for all of the resources who are involved in the project.

Resource plans involve creating a time frame on when the resources are needed and analysing the critical path and its implications. This plan should be communicated to the resource manager on a regular basis to establish whether there are other projects in the pipeline that will require your project resources.

  • Waiting for resources is a common budget and delivery schedule risk.
  • Using unskilled “gifted amateurs” can add time, cost, and quality risk
  • Insufficient capacity of resources will prolong the project, and drive additional costs for other team members and materials

9. Scope Risk

Scope creep is when we add additional features or functions to the product or when we keep adding new requirements to the project without addressing the impact on time, cost and resources.

Always ensure that contract, Project plan, and Activity are aligned

Contract Scope==Project Plan Scope==Resource Allocation and activity

To mitigate this, project scope and requirements must be recorded at the beginning of the project and must be approved with the stakeholders before starting to design or implementation.

10. Time Risk

Projects have deadlines and the project team will progress towards that date under the direction of a project manager.

One of the methods that project managers can use to manage the time is setting time estimates.

For each of the tasks that needs to be performed, allocate a time in which the task must be completed. By assigning a fixed time for each task, the team members will try to complete the activities within fixed timebox meaning that you are more likely to meet your project deadlines.

  • Estimates that are too lax risk project members to dawdle, running over budget, over time, or losing momentum and morale.
  • Estimates that are too aggressive risk project members being overwhelmed, unmatched expectations with other stakeholders, and a culture of extending deadlines.
  • Research suggests that companies that set and hit deadlines can demonstrate a positive impact to their overall ability to add value to shareholders.

Conclusion and Next Steps

Project delivery is a complex and often undervalued skill. Not everyone has the ability to exert sufficient but not smothering control, while appreciating the challenges of delivery, and balancing the needs of external stakeholders.

Projects that deliver connectivity and automation are generally more project management heavy because of the number of system owners and other stakeholders that are involved, as well as the impact (changes) needed to enterprise infrastructure.

We have a track record to support our confidence that we can help you to deliver your IT projects. Responsiv will stand behind this claim with fixed price, outcome-based contracts – which are very effective ways for you to manage your risk.

    Last Name*

    First Name

    E Mail*


    Lead Status*

    *By pressing submit you agree to receiving communication from Responsiv. You may unsubscribe from communications at any time.

    Ivanin Ivanov

    Ivanin Ivanov

    Ivanin is a Technical Consultant at Responsiv. He specialises in System Integration with IBM Integration Bus, IBM ACE, and IBM MQ, and is skilled in systems analysis, design and integration, API development, web development, and database design and development.
    Ivanin’s other interests include cybernetics, cloud technology, containerisation & orchestration and the DevOps culture. He continuously strives to expands his knowledge and keep up with the strides of modern technology.