• IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog
  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources

IT Revolution

Helping technology leaders achieve their goals through publishing, events & research.

  • IT REVOLUTION
  • Newsletter
  • About
  • Contact
  • My Resources
  • Books
  • Resources
  • Courses
  • Podcast
  • Videos
  • Conference
  • Blog

The 3 Real Risks Every Project Manager Should Focus On

September 3, 2020 by Mark Schwartz Leave a Comment

Adapted from War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age by Mark Schwartz.

It turns out that people are pretty terrible at assessing probabilities and risk. In my last book, A Seat at the Table, I cited several examples to make this point—examples that I love because even knowing the right answer I still can’t convince myself it is right.

The first example had to do with the TV game show Let’s Make a Deal, in which the contestant is asked to choose one of three doors. Behind one, the contestant is told, is a car the contestant will win if he or she guesses correctly. Once the contestant guesses, the host opens one of the other doors to show that there’s no car behind it. He then points out that two closed doors remain—the one the contestant chose and the third one—and asks if the contestant wants to switch doors. Since there are now only two doors, each seems to have a 50% chance of hiding the car, so it doesn’t matter, right? But the correct strategy is always for the contestant to switch doors—doing so doubles his or her chances of winning. Our intuition hesitates to accept that, even when it’s carefully explained.

Another example that I cited looks at probability in the world of disease. Let’s say you’re tested for a rare disease that occurs in one out of every one thousand people. The doctor informs you that the test is 99% accurate: that is, if you have the disease, the test will be positive 99% of the time, and if you don’t have it, the test will be negative 99% of the time. Unfortunately, the test comes back positive. How worried should you be? Not very, it turns out. With these parameters, the chance that you actually have the disease turns out to be only about 9%.

We have a strong tendency to identify risk in all the wrong places and miscalculate the likelihood of outcomes. Traditional project management, for example, leads us to believe that projects have cost, schedule, and scope risks. A project manager following Project Management Body of Knowledge (PMBOK®) best practices will keep a risk register and make plans for mitigating those risks.

But these delivery risks are not the right risks to be concerned about. The real risks are (1) the risk of not accomplishing our business objectives, and (2) the risk of not accomplishing them in the quickest, most cost-effective way. To those I’ll add (3) the risk of unintentionally exceeding the budget. Cost, schedule, and scope are at best only proxies for these real concerns.

(1) The Risk of Not Accomplishing our Business Objectives

If your goal is to increase the number of cases each employee can process in a day, say from seventy to one hundred, and you’re willing to spend a million livres to achieve that objective, then the risk is that you’ll spend your million livres and not achieve the objective.

If you take that objective and translate it into a set of requirements for technologists to implement, then you’ve added another risk—the risk that the requirements you’ve chosen won’t actually accomplish the objective. Yet that’s exactly how the traditional model proceeds; it does little to mitigate this risk, since you don’t find out whether your requirements have succeeded until the project is over and you’ve spent all your money.

You can reduce the risk by taking the Lean startup approach and treating the so-called requirement as a hypothesis: “I believe that if we implement these features, then the result will be to increase cases from seventy per day to one hundred.” Then you’ll test the hypothesis, often with only a fraction of the total spend of the project. Based on the results of your test you can either modify the requirement or abandon it altogether. That is risk mitigation.

You can further mitigate this risk by using DevOps to quickly release one capability at a time to users. You can then see the objectives being accomplished as development proceeds; in the prior example, you can see the number of cases continually increase from seventy. With every released feature, you’re decreasing the risk of not accomplishing your objective. What better risk mitigation could you ask for?

(2) The Risk of Not Accomplishing Them in the Quickest, Most Cost-Effective Way

With the old waterfall approach, it was almost certain that you were not accomplishing objectives in the quickest, most cost-effective way. The waterfall, remember, actually increased risk by encouraging feature bloat. It required costly upfront time to prepare the requirements and to plan the project before delivering any value. And it increased costs because testing came at the end, when it was the most time-consuming to fix problems.

Fortunately, your toolkit now includes a better way to manage this risk as well. With an Agile approach you can begin delivering value right away, evolving the plan as you proceed. You reduce cycle times and eliminate waste by looking at the entire value stream, both inside and outside of IT. All of these reduce the risk that you won’t accomplish your objective in the quickest, most cost-effective way.

(3) The Risk of Inadvertently Exceeding Budget

In the waterfall approach, we treated scope as fixed (“required”) and continued a project until either the scope had been completed or the project had been terminated as a failure. Because the project had to continue until the scope was complete, there was a high risk of exceeding budget. That was precisely what happened on many projects.

When you use the Agile approach, you get results constantly through-
out the process, prioritized by their effect on the desired outcome. As a result, if the budget runs out you can simply stop the project—it has already delivered most of its value. Or you could decide to increase the budget and produce more impacts. You have the choice.

Most Recent Articles

  • The DevOps Enterprise Journal: Spring 2022
  • Learning Effectively From Incidents: The Messy Details
  • Putting the Ops in DevOps – An Infrastructure Story

Filed Under: A Seat at the Table, Books, DevOps Community, War and Peace and IT Tagged With: a seat at the table, devops, mark schwartz, project management, risk, risk management, software delivery, war and peace and it

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

newsletter sign up

Topics

Tags

agile agile conversations better value sooner safer happier business business agility business leadership case study continuous delivery devops DevOps Advice Series devops case study devops enterprise forum DevOps Enterprise Summit devops handbook digital transformation dominica degrandis douglas squirrel enterprise Gene Kim incident management information technology IT jeffrey fredrick jez humble John Willis Jonathan Smart leadership lean making work visible manuel pais mark schwartz matthew skelton nicole forsgren operations Project to Product project to product tranformation seven domains of transformtion software software delivery Sooner Safer Happier teams team topologies the idealcast The Phoenix Project WaysofWorkingSeries

Recent Posts

  • The DevOps Enterprise Journal: Spring 2022
  • Learning Effectively From Incidents: The Messy Details
  • Putting the Ops in DevOps – An Infrastructure Story
  • Visualizing Team Dependencies with a Team API
  • What to Expect at DevOps Enterprise Summit Virtual – Europe 2022

Privacy Policy

Featured Book

Featured Book Image

Events

  • DevOps Enterprise Summit Virtual - Europe
    Virtual · 10 - 12 May 2022
  • DevOps Enterprise Summit US Flagship Event
    Las Vegas · October 18 - 20, 2022
  • DevOps Enterprise Summit Virtual - US
    Virtual · December 6 - 8, 2022
  • Facebook
  • LinkedIn
  • Twitter
  • YouTube
Copyright © 2022 IT Revolution. All rights reserved.
Site by Objectiv.