Evaluating risks starts by defining and understanding a project’s objectives. If there aren’t any objectives, there are no risks, and if the objectives are very fuzzy, so are the risks. In addition, when we prioritize risk, our priorities will be "more correct" if we have a way to objectively evaluate the potential impact of the risk on project objectives.
My point is, effective risk management starts with defining objectives.
Some would argue, that it depends on the project. Certainly that is correct if we try to include all different types of projects. For example, from remodeling a bathroom (one of my side projects right now), to solving world hunger.
However, we won’t cast that wide of a net in this blog series. For defining project objectives in this post we’ll limit our scope to the types of projects we engage in at companies that develop and/or produce products for a profit.
So, do project objectives in companies that develop products for profit depend on the type of project?
Some would still argue they do. On some level, they are right, but at the highest level(s) there are important commonalities.
What do I mean by levels?
I’ll illustrate with some simple Objectives Trees (i.e., Requirements Trees) using a new product development project as the example.
The green box depicts what many people think of when they think of project objectives. It’s easy and natural to equate meeting objectives to meeting requirements. This green box is largely different across different projects and project types. For example, requirements are very different in a new product development project, vs. a cost reduction, a CAPA, a process improvement, and other types of projects we engage in.
But, really, the objectives of the project don’t stop at meeting the requirements. There are higher-level objectives. Whether the project is to develop a new product, solve a production issue, improve employee retention, or something else - at the highest level, a project’s objective is usually to increase profit.*
So, to get a clear assessment of a project risks, should we just say a risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on company profits?
That’s pretty fuzzy and open-ended, isn’t it?
Doesn’t everything have an effect on company profits? If so, when we are prioritizing project risks, can we easily assess each one based on the impact to company profits?
Well, believe it or not, we can, but we can’t go straight there. We have to first understand the relationships between meeting project requirements and company profits. This requires us to fill in a few more levels.
The darker blue boxes represent the interim objectives of most projects.** They connect meeting project requirements to the ultimate objective, increasing profits. They are the project objectives put into concrete economic terms — and they are the same as the Economic Variables we introduced in our posts on making economic decisions.
These economic objectives and variables are largely common across different types of projects. As a result, they can put projects of all types, and their risks, into clear context and help project teams understand, discuss, identify, prioritize, and mitigate project risks most effectively.
The red arrows indicate the negative impact the objectives can have on each other. For example, the more requirements we meet, the longer the duration of the project is likely to be. The shorter the duration of our project, the higher our project expenses and unit costs usually are. Though good lean project management, including good risk management, can make these traditionally negative impacts positive. Shorter projects can also be less expensive, and come out with lower unit costs, if you manage risks well.
The connections differ across different project types, but generally remain the same within the same project type. For example, here is a tree of a typical Unit Cost Reduction project, where the requirements are to reduce the production cost of an already released product.
<>Projects have one or more of the three primary objectives, and while, in some cases, it might seem the others are not related, if we aren’t careful, the other objectives will suffer.
In this example, the primary objective of the project is to decrease unit costs as indicated by the black arrow. Another, if often only implied objective, is to not allow sales volumes or prices to suffer from cost cutting.
The secondary economic objective, shorter project duration, is common to all projects. The faster we complete the project, the more we achieve the primary economic objective. E.g., the sooner we get the costs down, the more we decrease total unit costs for the company. The sooner we release a new product, the greater the sales volumes and/or prices will be.
The schedule objective isn’t really ‘secondary’ because it usually has a very strong impact on achieving the primary economic objective. It can also have a large negative impact to the other primary objectives, if we aren’t careful. For example, if we rush to cut unit costs without spending enough time to test our changes, we stand to lose sales from releasing a lower quality product.**
With some well thought out economic modeling, we can understand, quantitatively, the relationships between the schedule objective and the primary objectives. E.g., we can know that a one month delay will likely reduce total sales by about 5%.
We can also often quantify the impact that ‘more and better defined requirements’ have on the primary objective.
The impacts that the schedule and the requirements have on the other objectives (the red lines) are often not so easy to quantify on a whole-project basis, but can be assessed on a case-by-case basis, again, with an economic model.
With an understanding of the economic objectives of our projects, and how they impact each other and company profits, we are equipped to manage these tradeoffs and the associated project risks the most effectively. However, it’s not absolutely necessary we understand these specifics to get started and be effective in risk management. To get started, we simply need to recognize, even intuitively, that if we aren’t careful, we’ll have a bad project which won’t meet the objectives, whatever we recognize them to be.
In the next post we will review examples of project risks, and then we’ll get into the process we recommend for identifying and managing risks most effectively.
From here forward, we’ll turn our focus even more narrowly to just product development projects. Even though the principles and methods are largely common to other types of projects, and only the examples are really different.
Ready to get started? Download our free risk exposure template.
Risk Management and Project Objectives
Risk Identification and Capture
Risk Mitigation Strategy (part 1)
Objects Impacted and Modular Architecture
Calculating Risk Exposure and Free Risk Exposure Spreadsheet
Risk Mitigation strategy (part 2)
* Some companies may focus on revenues instead of profits as their top goals. Still, keeping costs down is important in these companies to. In addition, many of us don’t come to work thinking it’s all so the company can make a larger profit. Even company missions state other objectives, for example, ‘Helping Surgeons Treat their Patients Better’, which is the corporate mission at Arthrex. However, it’s difficult to correlate day-to-day decisions straight to ‘treating patients better’, and if we don’t make a profit, we can’t be very effective at those other missions for very long. In between a top level of ‘helping surgeons treat patients better’ and the lower levels of each project, somewhere in the middle, lie the objectives of keeping costs down and revenues up. The economic objectives are common to all, and we can use this profit-at-the-top model to very effectively understand and manage all projects’ objectives and risks.
** High quality is a very important part of this tree, and project objectives in general. I’ve left it out for now for the sake of simplicity. It has interconnections to all of the primary economic objectives, and makes the tree harder to read.