Playbook_Logo.png
Free Trial
Watch Demo

Eric Graves

Aerospace and mechanical engineer turned NPD systems engineer, Eric spends his time engineering better product develop systems, using PLAYBOOK as his tool of choice!

Search Result

Posts containing:

Project Risk Management for Hardware Development: Examples of project risks (Part 3)

Eric Graves- 04/7/16 06:21 PM

This is Part 3 of the PLAYBOOK series on project risk management for hardware product development. In Part 3 we look at another key piece of project risk – the uncertain events and conditions that are the cause of a risk. In so doing, we’ll look at a few common examples of project risks, their potential impact on project timelines, the scope of "events and conditions’" we include in project risk management and finally, we use an analogy to show why effective risk management is important.

As a reminder, in Part 1, we looked at the definition of risk management and discussed how the trick to effective risk management is to learn – both carefully and quickly – in the right balance.

The PMBOK definition of a Project Risk is “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.”

In Part 2, we looked at the key piece of project risk management – the project’s objectives and how effective risk management must start with defining project objectives. We concluded that project objectives are best established in economic terms such as sales volumes, sales price, cost of goods sold, and project expenses. As well as the all-important launch schedule, which directly impacts the other objectives.

So what do we mean by “uncertain events and conditions” which may impact these economic objectives? Let’s look at one common example.

Technical design challenges and associated risks

The most common and easily recognizable example of project risk are technical design risks. E.g., We are not confident that a particular requirement is achievable because of constraints in the technologies available.

Let’s use a mobile phone as an example. There are many challenging requirements for a mobile phone. For example, it needs to be small but and powerful, with lots of features like a high-resolution screen, a powerful camera, GPS, etc. But we aren’t sure if the components available can do everything without generating too much heat. In addition, fitting everything into a hand-sized package isn’t exactly falling-off-a-log easy, or the battery isn’t likely to last very long with all the gadgets running on it.

Project Risks vs. Issues: Should we manage them differently?

Most of us probably expect that there are significant technical challenges in designing a marketable mobile phone. In fact — especially for those in the business — at least some of the challenges (conditions) seem pretty obvious and certain.

So do conditions we are certain about still qualify as risks if a risk is an “uncertain condition or event” which may impact our project objectives?

Some contend that when a risk becomes a certainty, then it becomes classified as an ‘issue’ instead of a risk. I don’t think risks and issues are really that different and trying to distinguish one from another is more hassle than value-added. Where is the line between risk and issue? At 99% certainty? 95%? 99.9%? There is no such thing as 100% certainty.

Even when we are 100% sure we have an issue, maybe 1 out of 100 of those issues resolve themselves and so we never really had a problem in the first place. Even 100% sure is only 99% sure. There is no distinct line between risk and issue, and so I don’t try to draw a line. We can evaluate and manage them all very well using the same set of practices and principles, so what is the point?

Other types of project risk

Now that we have defined a broad scope of what qualifies as a project risk, let’s review a few more common examples.

  • Supply Chain: For example, we may have a problem easily procuring high-quality materials and parts for our prototype and/or production units.
  • Manufacturability risks: Can we produce prototype components and assemblies quickly and reliably enough to meet the schedule and project expense objectives? Can we produce production units even more reliably?
  • Unit cost: Can we produce our product at or below the budgeted cost of goods? Is our customer’s Total Cost of Ownership going to fit within their budget?
  • Product fit/Market: Will our potential customers like what we are producing and pay us enough for it?
  • Resource Risks: Will we get enough resources to meet the schedule target? What if a key person leaves the company or gets hit by the proverbial beer truck?
  • Program-management: Major scope-change during the project.
  • Interpersonal: For example, if there is a lack of effective communication between members of the development team, or between the team and management.
  • Regulatory: What are the regulations we’ll need to meet, and how will we gain our regulatory approvals with a minimum delay of our launch?

 

These are just a few common hot-spots in the sea of things that could negatively impact our ability to achieve our project objectives. The list of potential or near-certain risks and issues is certainly long, and, if we include even the very low risks, it could easily overwhelm us with too many problems to solve.

What about unknown risks?

Even with the best planning and intentions, it’s impossible to think of everything. Try as we might to avoid it, there will always be at least a few unknown-unknowns that we won’t see early enough to keep them from impacting the project objectives.

So, what is the point then? If we can’t mitigate everything, why even try?

In the many times I have asked this question to a group of product developers, I have yet to have someone say we shouldn’t try to manage risk. Universally, everyone agrees we should try to deliberately mitigate at least the biggest risks. Why? Because we all recognize the positive payback for our effort. With a little time and/or money spent earlier, we can save a lot of time and/or money later.

But is agreement that we should deliberately mitigate risks enough make it happen?

Unfortunately, it isn’t. Projects lacking in proactive risk management are almost as universal as the agreement that we should manage risk.

Why do projects lack risk management?

So why do projects lack risk management? I think it has a lot to do with a lack of agreement about how much risk management is too much. There is disagreement about how much time and money should be invested in risk management up front and during the project.

So how much time and resources should we invest?

To help establish some agreement about the importance of risk management and the level of effort required, we developed an analogy as depicted below. These images show our project on a horizontal time-axis like we see in a project timeline or Gantt chart.

 Project_Risk1.png

 

We are currently on ‘today’ (the green bar in the top picture) and we need to run to the completion of the project, which is represented by the ‘finish line’ at the end of all of our tasks. We run a constant rate of one day per day.

While we run at a constant rate toward it, the finish line isn’t really in a fixed location. By our actions, or in-actions, the finish line can move on its own in either direction, left or right, and we can purposely move it in either direction. Our challenge is to keep it from going too far to the right or even pull it to the left some

Project Risks are represented by the mine along the path. When a risk goes unmitigated, it often blows up which has the impact of moving our finish line further away.

 

Project_Risk2.png

 

Say, for example, the bomb in this image represents the risk that a mom-n-pop shop supplier won’t be able to meet our needs for ramping-up production. It won’t extend our schedule yet, but there is a good chance it will in the future. If it does, it will move the launch date out a few weeks while we find and qualify a new supplier.

What companies often imagine is that the mine will be a dud - the risk will not materialize, and the project will move along the path to the finish line like it was never even there. Of course hope is not an effective risk mitigation, so these companies suffer the inevitable consequences of their blown-up schedules.

Really, the risk appeared on the path as soon as we chose to use a component that would be difficult to procure elsewhere. That choice moved where we should expect our finish line to be. Our next decision – conscious or not - is whether to recognize the new finish line location and try to do something to diffuse the bomb, or hope it’s a dud.

Extending this analogy to something more representative of a real project, where there are multiple risks and multiple parallel paths we must traverse to get to the finish line, the image looks something like this:

Screen_Shot_2016-04-07_at_10.43.08_AM.png

 

The pink and red lines in the middle represent the critical path (critical chain) of the project. The dark-red lines are the risks materializing on the critical chain. The orange lines are risks materializing on the other parallel paths.

Some of the mines will be duds. The other active mines, if we don’t diffuse them them, will extend part of the path a little or a lot. These combine to establish a range of possible finish dates, with a probable completion date somewhere in the middle, and further out than we may have hoped for.

However, we can diffuse many of those bombs if we put in a little extra time and money to do so. This mitigation cost is depicted by the green lines in the picture below. By putting in some short green lines, we can remove a lot of the long orange lines.

Project_Risk4.png

While we can’t mitigate all of the risks (remove all of the orange lines), by removing a lot of them, we avoid many of the project-extensions. The result is an overall (probably) shorter project path, with more certainty about when we’ll reach the finish line.

Project_Risk5.png

 

The analogy shows that the minimum possible completion date is later in the lower scenario, where we commit some time to risk mitigation. But the probable completion date is earlier (and often it is much earlier).

With as many risks as there are in a project, the law of averages will rule, and the probable finish date is a far more accurate estimate of when it’s really going to be finished.

Conclusion

In conclusion, the result of good risk management is shorter projects with more certain completion dates, as long as we don’t go overboard and put in green lines (mitigations) which don’t effectively remove a longer orange line downstream. Stay tuned for Part 4 where we discuss the return on investment of project risk management!

 

Are you ready to explore a new approach to risk management? Download your free template today.

 

Download my free risk management template