Top 10 Project Risks and How to Mitigate Them

Share this article...

Anyone who works on projects will know that they aren’t all plain sailing. Projects are defined to bring about change in an organisation. Very frequently they are process and technology-centric but they all have one element in common, human interaction. With this combination of elements to consider, there are usually some risks that bubble up along the delivery path that require mitigation.

The Prince2 definition of risk is, “an uncertain set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity and the magnitude of its impact on objectives”.

Tracking Risks

Project managers will track identified risks in a RAID Log (Risk, Assumptions, Issues and Dependencies) throughout the project with a view to getting each one resolved or accepted. Each one needs to be mitigated somehow. These risks could be resource issues or budgetary constraints or awaiting an SOW (Statement of work) sign off. These are day to day items that need to be raised and quickly resolved to keep a project on track.

There are some risks during a project that may be considered too contentious or political to be put on a public shared list, but it’s these risks that can really affect the success of project delivery. It’s these risks that fit into my Top 10 that I have as a countdown for you here:  

10. When the sale doesn’t cover the true value of the solution

“The too good to be true sales pitch”

It’s when the sales team promotes the proposed solution as standard functionality but really requires lots of custom development, making it more complex and time-consuming. Or when the salesperson sells at way under the estimated cost to offer an over competitive quote to win the deal, or when the team over-promises and under-delivers.

  • Be part of the pre-sales team so you can guide parties towards the optimum solution
  • Carefully read the Statement of Work (SOW) to ensure all requirements are accounted for and the delivery timeline is reasonable
  • Stay on point with budget, resources and timeline throughout the project
  • Use change requests with the customer to ensure that all outcomes can be delivered within an accepted timeframe, quality and without breaking the delivery team

9. When the customer’s budget doesn’t match their expectations

“Champagne tastes, beer budget”

The reality of implementing projects successfully and then maintaining a healthy system can be rather misjudged by customers. Some may budget for the license purchase and initial implementation but then forget about ongoing enhancement costs. Others may feel they can configure the system themselves, while some client’s expectations on what they would like the system to do for them, sometimes will not match their budget. 

  • As a customer, your system should be seen as a long-term investment
  • Create a centre of excellence within the business to define a product team, development team and key stakeholders who will continue to shape the solution as business processes change
  • Build the solution in iterations, starting with simple outcomes and adding complexity as budget allows and as the business engages with the system

8. When the delivery team isn’t a high performing one

“Toxic team members”

Unfortunately, we have probably all met someone whose behaviour can threaten the success of a project. Most of the time their behaviour isn’t malicious but there can be a range of reasons why it occurs, such as, the Architect with little experience who designs a solution that is not scalable. Or the Developer over engineers a solution to show off their skills, or a team member who fails to communicate their progress at stand-ups and the person who doesn’t let others speak or give their opinion.

  • If you identify toxic behaviour then act immediately as it can disrupt a project flow
  • Investigate the cause of the unwanted behaviour to mitigate the issue quickly
  • Allow the individual who created the disruption time for them to address their behaviour and be part of a high performing team
  • If the behaviour isn’t changed to meet the overall needs of the project then remove the toxicity from the delivery team

7. When project success relies on collaboration in all areas

“Collaborate or die”

A project is only successful based on its inputs and how they glue together. If there are mismatches then problems can occur, such as, when a member of the team fails to show up for meetings or update tickets or deliver their work outputs according to their own timescales. It could be in relation to the customer who doesn’t get the right people in the room or provide project information, and it could be in relation to technology when apps or integrations cannot connect or are built with conflicting code.

  • Support the team member as they might be feeling overwhelmed by the project
  • Ask the client to get the right stakeholders in place and to share information
  • Carefully review and test technology before making expensive commitments that won’t work

6. When there is a lack of data strategy

“Dirty data”

Data is one of the most misjudged elements of a project and enough emphasis isn’t given for a thorough review of what is captured during a customer journey and why, let alone the quality of the input. Sometimes, when timelines get squeezed, it is tempting to push legacy data into the new target model, allowing for existing poor data management behaviours to be replicated in the new system. This can result in adoption issues by end-users and unhappy customers having to negotiate incorrect data captured, or the business falling foul of any data protection laws.

  • Spend time to define the new data strategy and process, and what data is required at each stage of the customer journey in the new system
  • Review all legacy data to assess what moves into new world and which should be archived
  • Clean data for quality purposes before uploading into the new system
  • Define business process and system rules to preserve future data quality

5. When there is no proper roadmap for future enhancements and projects

“Roadmap to nowhere”

When stakeholders believe they only have one shot at an implementation they can often ask for the world to be delivered in the first phase. Requirements become the size of an encyclopaedia and often trying to replicate their existing world. Meanwhile, any other team wanting functionality will have to wait an age for their turn. The danger lies with an imbalance of time spent on one set of stakeholders, not appreciating the features of the new system and the potential of never getting beyond the discovery phase of their project.

  • Create a roadmap of top-line proposed activities, share it with key stakeholders and keep it up to date
  • Log any dependencies, such as integrations or resource expertise, which may affect the success of a project
  • Regularly review the roadmap to check if the projects are still relevant and prioritised accordingly to the business needs

4. When change management isn’t addressed

“Not ready for change”

If you consider the customer examples of those who wanted the replicate their existing processes or wanted to lift and shift their legacy data into the new system then these are perfect traits of poor change management behaviour. The stakeholders involved in the project weren’t open to doing things differently. This could be due to lack of time to assess the need or not being empowered to experiment. Sometimes a project can fail when the proposed change isn’t bold enough, when the end result, irrespective of how many iterations it takes to get there, won’t achieve the ultimate goal. 

  • Explain the ‘why’ of the project and the reasons for the need of business change
  • Communicate the process so that stakeholders are aware of the project goal, its milestones and how it may affect them
  • Illicit feedback from stakeholders at every stage to keep the project on track or to mitigate any issues arising

3. When stakeholders aren’t considered

“People on the bus”

Stakeholders are people who may drive the change but also could be affected by what is implemented. Often, projects won’t get the right combination of stakeholders involved in delivery, such as management making design decisions on the process to find they are too removed from the day to day. Or when team members see their workload double as they are pulled onto a project without support for their day job. Or other stakeholders worried about the impact of the project result on their livelihoods.

  • Get the right people involved in the project and empower them to make informed decisions. Don’t assume the management layer will know the nuances of their team’s work processes
  • Support stakeholders by backfilling their day jobs so they can dedicate their time to the project and able to meet deadlines
  • Communicate to stakeholders on the project progress using different formats as appropriate to their needs; meetings, emails, town halls, videos, etc, to illicit feedback

2. When the customer doesn’t come first

“The VIP”

Sometimes an implementation will consider the process for the internal end-users to capture insights from their customer, but they do not go deep enough to think about what really needs to be tracked at each stage of the customer journey, for the customer’s benefit. Some departments are too keen to capture any, and all forms of data possible, getting tangled into the sensitivity and relevance of the data kept. Some businesses are focused on chasing the next target and win and act too short-term, with the potential of wrecking relationships, brand loyalty and future long-term investment.

  • Simplify the offering to the customer and focus on quality outputs from your product
  • Get your customer journey to ‘yes’ quickly and reduce unnecessary process
  • Consider the data you capture during the phases of the customer journey and if it’s needed
  • Build the relationship with your customer and think long term potential

1. When leadership is not aligned

“Trouble at the top”

Taking the top spot is leadership. They are the biggest risk to a project. If your leadership team is not aligned to the project goal, then you can have executives flexing their muscles to play against one another for their own department interests or personal career progression. It’s basic play for control and power. 

Then there is the leader who is into ‘command and control’ when they believe that the project must progress in a certain way for it to succeed. Or they have bought into a certain technology that might not be the best solution in the long run. They may not have considered the scalability or future needs of the business. It’s their pride and ego at stake that could be damaged by admitting they got things wrong and so they stick firmly with the decision made, costing the project time and money on wasted resources. 

  • Stick to the facts when highlighting issues and remove any emotion or blame to protect egos so that mitigating decisions can be swiftly made
  • Find allies, especially those higher ranking or more knowledgeable, who share your opinion on the issues raised to build gravitas on the situation and who can escalate when needed
  • Protect yourself if you are not feeling supported, not progressing or unable to challenge. Keep evidence and escalate if you can. If not, walk away. No project is worth your wellbeing.

Summary

You’ll notice that these risks are heavily people orientated and there is no real surprise here. Projects affect people in many different ways. As you step onto a project carefully assess the human interactions that you will be facing. Could any of them become potential risks to the successful delivery? Identify them as early as possible and use the tips in this top 10 for their mitigation.

Add Comment