Is a big project always high risk? How to assess project risk as part of good governance

If you are an executive charged with overseeing a project’s success, say, as a project sponsor or a steering committee member, it is important to be able to assess the true risk of a project as part of good governance. This task is often undertaken by the project manager, but there is not always a project manager on board at an early stage, nor is it ideal to rely solely on the perspective of the project manager. Understanding the inherent risk of a project helps with governance decisions such as the type of project manager required (seniority, type of experience, personal attributes), appropriate methodology to use (eg, waterfall or agile), reporting processes, timing of milestones, conditions for continued funding, and so on.

"Being able to properly assess the risk of a project is part of good governance."

Many organisations structure their governance regimes and manage risk based on financial attributes - think “delegated financial authority”, manifested in common corporate policies like “only managers above a certain seniority can approve expenses over $X”. This thinking works if the risk associated with that activity is limited to, or in proportion with, the expenditure involved. This brings us back to the initial question in relation to projects: “Is a big project always inherently risky?”

This topic came up recently in a conversation I had with another highly experienced program manager, as I told him that my program is the largest ever tackled by the organisation where we’re working.

His first reaction, like most people’s, was “wow, that’s high risk!”. When I asked him why he thought that large projects were necessarily high risk, he said that large projects have more moving parts, which leads to complexity.

He is right, of course: complex projects are high risk. However, large projects are not always complex, nor is the converse always true. Having spent a good few years developing project risk frameworks at three of Australia’s largest public companies, and having assessed the risks of many projects and startup ventures, I can confidently say that the size of a project (as measured by its budget or the number of staff involved) is only one of at least a dozen factors in determining whether a project is high risk.

But first, let’s get our definition clear. We are talking about project risks defined as threats to a project’s ability to deliver on time, on budget, to the required quality, to the agreed scope, and/or the organisational objectives or benefits agreed to at the start of the project.

"Most project risks are known (or knowable) near the start of the project."

It may surprise some, but most of these risks are known (or knowable) near the start of the project. Think of these as a project’s inherent complexity or vulnerability to failure. A project’s size is precisely one such factor. Other factors that determine a project’s inherent risk include:

1.      Dependencies: the more your project relies on other projects or activities to deliver what you need, the higher the risk. And the more others rely on your delivery to meet their needs, the higher the stakes for your project if it misses its deadline. More dependencies also add to planning and coordination complexities along the way.

2.      Integration: the more technical disciplines or technologies involved, the more work required to make them work together seamlessly, and the harder it is to find bugs.

3.      Collaboration: similar to integration risk, but on the people side of the equation. The number of organisational functions involved in the delivery, and the number of external organisations (such as venture partners and suppliers) involved. All these factors influence the number of stakeholder relationships, schedule dependencies, and decision-makers involved.

4.      Innovation: if the project is using a technology, method or capabilities that are rare, unfamiliar or untried, the higher the risk. Moreover, because of the exploratory nature of these projects, risks are harder to identify or quantify at the outset, and cost and schedule overrun can be multiples of initial estimates.

5.      Change: the more change there is to people’s roles, status, sense of certainty, autonomy, relationships, financial incentives, the higher the risk that the desired change will be resisted and therefore the business objectives or benefits of the project may not be achieved. The risk is higher the more the number and range of people affected by the change.

6.      Deadline: the less flexible the deadline (eg if it is regulatory-driven or publicly committed), or the higher the impact of missing it, the higher the risk.

7.      Duration: all else equal, the further out the deadline (the longer the duration of the project), the higher the risk as the project is more vulnerable to changes. These changes might include staff turnover, sponsors and key stakeholders, customer tastes, and technology.

8.      Budget: the size of the project relative to the organisation, and the amount of flex there is in the budget. For example, a $5M project at a large organisation may be merely a rounding error, but for a small organisation, a $50K overrun may be fatal to the organisation.

9.      Visibility: How visible a project is to key stakeholders – for example, a product that is developed as part of a “skunkworks” project is lower risk than a publicly announced product launch. For a predominantly internal project, a high-profile project often means higher stakes for its supporters, and this may make for a highly charged political atmosphere which (ironically) increases the project’s risk.

10.  Tangibility: the less tangible and measurable the project’s objectives and/or benefits (whether financial or non-financial), and the murkier the causality between the project’s outputs and the desired outcome, the higher the risk that the objectives or benefits won’t be achieved.

11.  Strategic: the more important it is to the organisation’s strategy, and the more difficult to achieve the strategy through means other than this project, the higher the risk. Or if the project commits the organisation strategically in a way that is difficult for an organisation to reverse direction should the project fails, then it would be high risk. There may also be opportunity foregone, eg, being first to market with a new product or system.

"The size of a project is just one of a dozen factors that drive project risk."

This list of the “dirty dozen” determinants of project risk (ie, including size as the 12th factor) may not be exhaustive. But it does show that while a project’s size, all other things equal, is a reasonable proxy for project risk, the reality is that there are a variety of other factors that are just as important. Let’s compare a few real-life examples to see how inherent project risk manifests in practice.

My current program is one in which the technical elements are complex, and there is great variability in the individual units of work to be processed. The scope of work is difficult to pin down and there are constant external forces driving changes to this scope. These attributes all contribute to heightened execution risk, especially the probability and magnitude of budget overrun. On the other hand, although the team is large, there are only a few distinct technical disciplines within the team. There are hardly any dependencies on other projects or business activities. There is minimal technology build nor any other innovations, negligible changes to roles and behaviours (which is mainly contained within the team itself), and no new product development. Although under heavy internal and external scrutiny with tough expectations, there is almost no impact on current day-to-day customers or operations. The program duration is fairly long and there is some significant planned change to the organisation – but the change is broadly known in advance and therefore can be planned, to some extent. So – this program is moderately high risk, but not – if you remember my colleague’s first reaction - primarily because of its size.

Contrast this with another project I’ve run previously: for a non-profit seeking to change the ecosystem by fostering dialogue and collaboration with key stakeholders within and outside the system. This project’s budget was less than a tenth of the program I mentioned earlier and involved a fairly small team. However, success or failure would be highly visible precisely due to its engagement with numerous high profile external stakeholders. The mission was bold, the solution not precisely defined, and the project delivery approach was both unconventional and involved many suppliers and venture partners. Most would agree that this project was much more risky than my current program.

Then there is the project that I came across recently. It is a relatively small project by most standards in this organisation in terms of team size and budget. However, this project is highly visible within the organisation, using technology that is still evolving in the marketplace and new to the organisation. The project is intended to be delivered using an Agile methodology, by a team and within an organisation that is still fairly new to Agile. The project goals, business benefits and delivery timing are somewhat vague to many stakeholders. It depends on quite a few other business areas and their expertise in order to proceed. In short, despite its size (which would have put it in a low-risk category for this organisation), it has a very high likelihood of failure. The only thing I don’t know (given my limited knowledge of this project) is whether the impact of a possible project failure is limited to the project expenditure to date, or whether the impact extends beyond the financial.

Assessing how risky a project is, is an important task for a project sponsor or steering committee member as part of good project governance. In most organisations, project size (typically measured by budget) is used as a proxy for risk. But size is only one of at least a dozen factors that influence the likelihood that a project fails to deliver against its schedule, cost, quality, scope, or organisational objectives. A more comprehensive inherent risk assessment conducted near the start of the project can pinpoint the areas where a project is vulnerable to failure. Armed with this information, a project sponsor or steering committee can make sound decisions on such matters as the choice of a project manager, oversight required, and funding parameters that are commensurate with the level of risk the project represents.

Stephanie Owen is the principal and managing director of Strategy2Life, a management consultancy that helps leaders drive change and bring strategies to life. Based in Sydney, Australia, she is expert in the transformation management disciplines of program and project management, operational models, risk management, and change management. Stephanie has worked in risk management functions in five top ASX listed companies. She is an internationally certified program manager (MSP Advanced Practitioner), and has a growing interest in board governance as a certified company director (GAICD) currently serving on a not-for-profit board.