A project without risks captured makes us very nervous. It’s unusual for an organisation to have ‘over’ identified risks to a project, with the norm being that visibility of potential factors that could derail the project is less than it really should be. Risks shouldn’t be the impetus behind being overly cautious and hesitant to make big changes. Quite the opposite in fact; risk identification and mitigation actually unlocks projects to make more daring and
bigger changes, with a level of confidence that the business knows the process for getting through potential issues.

But how and when should risk identification occur for a project? There’s many important moments in a project’s lifespan, so when should this process start? And how might businesses uncover more project risks? In this guide we cover some of these big questions and more.

A risk assessment done early catches more issues

The risk assessment of a project and the business that surrounds it should be done as early as possible. As soon as a project passes the business case stage and moves into planning, there are already risks present that should be captured. When the risk assessment is conducted as part of determining the project’s feasibility, the planning itself can work around potential roadblocks.

Remember a risk can present as a stakeholder that won’t sign something off, a functionality that may or may not be able to be delivered or a shift in the market that could make the project’s outcomes less fit for purpose – there’s no one single type of risk but multiple – compliance, legal, financial, reputational to name just a few. The earlier this assessment can be done (at strategy and delivery levels), the more prepared everyone is to face and handle these.

Why detailed business and risk analysis can reduce the chance of a disaster

Understanding the business as it stands today and the changes the project will affect within it helps to build a picture of risks by modelling out situations in which those changes cause an issue. While not the most optimistic of business processes, risk analysis at detail gives those involved the chance to write out ‘what if’ scenarios. The business and the project both need to be closely assessed for risks as issues can arise out of either once the project’s underway.

Business risks for a project might be things like:

  • Teams are not equipped to accommodate the changes of the project (e.g. a new system)
  • Budget for other projects may take precedence and therefore stall this project.

Risks that are more associated with the project deliver itself can include things like:

  • The system or stack of platforms don’t provide adequate security protection of data.
  • The capability of the resource available doesn’t meet the needs of the project.
  • Available technologies don’t adequately provide the functionality that the project requires.

Every project is different, but there will be typical risks associated with a people-based project vs. a technology-based project.

When the business proceeds without risks identified, the agility to change course if these risks come true is simply not there. Businesses may steer directly into a problem with no forewarning or game plan to get out of it. It’s in these scenarios where the project suffers from threat of failure – such as there not being enough budget to take remedial action to get things back on track.

Conversely, a business with project risks well identified and discussed brings not only the preparation to deal with these better, but will have indicators of these risks well before they arise. Identifying risks properly guides decision making during the entire process of delivery.

Stakeholder interviews before the project gets started to find where the gaps might be

Talking to your stakeholders removes many blindspots that a steering committee or leadership team may otherwise have. DIfferent business units and their people can review a project’s scope and business case from their unique perspective, and apply operational knowledge to their insights on what impact the project may have. Take for example a legal counsel within the business – their viewpoint on a user-facing digital platform may highlight risks around the ethical and legal collection of information. Not only can your stakeholders identify the gaps in your risk analysis across their own areas, but they can be part of the continuity planning by collaborating with you on plans to work through these.

Stakeholders involved in your risk assessment do something else; create buy-in to the project itself. These conversations will not simply be around the risks of the project, but offer a good platform to discuss the project’s benefits and objectives. When a stakeholder feels more involved, earlier, they’re often more responsive to a project and may prioritise their input to that work.

Project steering committee brainstorm

The steering committee comes together to lead and manage the project’s direction throughout its life. Getting this group together at the very beginning to conduct a brainstorm around risks is a valuable process. Like many good business problems, sharing of perspectives helps to drive the best outcomes. In this type of meeting collaboration would lead to a more considered and comprehensive identification of risks and a better mitigation strategy for each.

The output of this brainstorm can be captured on a risk register along with other analysis and discussions pre and during the delivery phase.

IQANZ_blog_Feb2_3

Project team resource risks

So what are some risks that you may encounter? Risks exist in many different places, but there are some common categories that most organisations need to think about.

The first is that of the project team itself. The project team is responsible for the delivery of the work and consists of project management and different technical and specialist roles depending on the objective. A project based upon establishing or improving technology may include developers, tech leads, front end designers and any other capabilities determined as being required for delivery.

A project team’s risks are commonly associated with the people in the team. Are they efficient in executing the work to a project timeline? Is the quality of the work to the standard needed for satisfactory delivery? Are there enough of the right kinds of people with the needed skill sets? And what risks are there of staff leaving? For longer-term projects there’s often more risk of turnover and the interruptions this may cause to delivery. Despite many projects’ resources including contractors, there is still an onboarding and up to speed process that new team members require – this undoubtedly creates delays in the completion of work.

Businesses may choose a number of ways to mitigate this risk, such as ensuring team members are well looked after, paid properly, have sensible expectations set of them and protected against distracting things like stakeholder scope creep.

External vendor risks

Vendors are those working on the project who aren’t necessarily a core part of the project team or business itself but have an important role to play in delivery. For a property-based project this could be an office relocation company, a commercial real estate company, fit out providers or office services. For a technology-based project, this may be the business that offers a platform that will plug into the project’s solution to meet the objectives.

Vendors bring with them many benefits, such as taking off the load and overhead of staff that may only be required for very specific parts of the project. They also offer specialist expertise that your organisation can ultimately save money and deliver a better result by engaging with.

There are risks too, such as the delivery of work not meeting the objectives or brief. Vendors may also run over budget or over time. Mitigating vendor risks relies upon a stringent procurement and terms of engagement process and ongoing strong relationship management. The business needs to have its scope and requirements crystal clear for a vendor before they begin. Even in an Agile delivery project where requirements are built along the way, knowing what the overall end capability needs to do before starting is important. Once the work has been accurately reflected, there’s a better chance of the deliverable being fit for purpose. Organisations should also take the RFP process seriously, with evidence for similar projects the vendor has supplied for being made available.

Market changes or evolving user needs

Part of the reason we suggest organisations try breaking their projects up into smaller chunks is because a lot can change in a few years. A big project takes longer to deliver its outcomes, surfacing a risk that these outcomes may be out of date by the time they’re implemented. This issue can result in wasted budget vs. an approach where smaller but quicker results are generated. Taking one small step in the right direction beats a big jump in the wrong one.

The market changes – no project team can anticipate this. But setting the business up to win through a more segmented approach to projects can protect against the expensive mistakes.

Technology and security risks

As more operations move to digital for the convenience of users, a host of functional and security risks get introduced.

The sheer number of variables at play with an enterprise-level or public organisation’s technology project can be daunting. Risk assessment in these situations requires a level of detail that may warrant help from specialist expertise. It’s common for large digital transformations to go through a year or more of requirements, assessment and planning before moves are made. For high stakes changes, sometimes this is simply necessary.

Environmental risks

Increasingly important in both public and private sectors is the environmental impacts of a project or business initiative. We are seeing more organisations aiming for carbon neutrality, B Corp status, or at the very least to stay out of headlines for any moves that could be perceived as poor for the environment.

How your organisation identifies these risks depends on the personnel at your disposal internally, within your assurance partners or specialist environmental consulting partners. Also involved will be your PR, comms and marketing departments should there be any potential for customer or media aversion to your activity from an environmental standpoint.

Stakeholder sign off stand offs

This risk exists for pretty much every project in New Zealand today. Stakeholders are the gatekeepers of a project being accepted and progressed to the next stage. If a stakeholder who is accountable for that milestone and its outcomes is not confident, they will delay the process.

Mitigating stakeholder sign off delay risk comes through clear scope, early involvement and relationship building, as well as ongoing communication and of course the quality of the delivery by the project team.

‘Key person’ risks

Having one person in the project team or a stakeholder who holds the knowledge to allow the project’s success is a massive risk to a project. Losing a team member no matter how long-standing they may be in the business is always a possibility. Project teams should work to capture key person information and share it across multiple people and documentation to protect against this.

Project teams should also avoid total sole ownership of deliverables, with back up staff who are at the very least informed about the piece of work in place. The key person risk is another reason why good governance, reporting and documentation is such an effective safety net.

Engage independent QA expertise to find risks in your business’ blindspots

Risk is a tricky part of getting a project primed and ready for success. And it doesn’t just stop being an issue once you’ve started; adding new risks to your register during the project is important. Having independent QA expertise to help guide you through the process of identifying risks (and help to identify risks themselves) is well-worth it for organisations when there’s significant time or money at stake.

A misconception many make about quality assurance is that it’s reserved for the big enterprise or public sector departments only. In reality, many medium-sized New Zealand businesses are conducting projects that present many risks that could be helped with a quality assurance partner on board.

Where to next?

Read our other project resources:

IQANZ_blog_Feb2_2

Setting project milestones

Staying on track isn’t just a matter of delivering on time, but controlling costs too. We offer some useful tips when setting project milestones.
Learn More >>

IQANZ_blog_Jan2_3

How to avoid project failure

Project failure is something every organisation wants to avoid. We touch on some of the approaches to preventing things going wrong.
Learn More >>

IQANZ_blog_Jan2_1

Identifying project risks

Risks exist in all organisations. It’s how we prepare, adapt and navigate these risks that makes projects successful. Read our guide on spotting and dealing with risks to a project.
Learn More >>

IQANZ_blog_Feb2_1

Understanding project governance

All the structure and processes around how a project is delivered can mean the difference between a successful project or not. Learn what governance is and how it can help.
Learn More >>

IQANZ_blog_Jan2_2

What causes scope creep

Scope creep affects every project manager or project team member at some point in their career. In this guide, we explore what some of the causes are.
Learn More >>

IQANZ_blog_Jan1_4

Managing project stakeholders

In this guide, we offer some tips for managing stakeholders to keep relationships positive and projects on track.

Learn More >>

Latest Project Assurance Articles

Get In Touch

IQANZ Limited
Level 2, PSA House
11 Aurora Terrace
PO Box 11-757 Wellington,
New Zealand

04 473 4340
info@iqanz.com