To quote the Danish politician Karl Kristian Steincke ”It is difficult to make predictions, especially about the future.” But predicting the future is what project management is all about. When things go wrong, scenarios can help you have a plan in place to recover.
Project management is hard — you’re predicting when milestones will be met, how much money will be spent, what tasks will be performed in which weeks, and so on. But predicting doesn’t have to be hard. If you just stuck to predicting tomorrow’s weather (no seven-day forecasts) and to promising that it would be much like today’s weather you’d be right a lot of the time…not 100% of the time, but ”a lot.” In addition, you could improve your odds by limiting yourself to two or three options in a small number of categories. If you limited yourself to predicting just a few scenarios — Rain/No Rain, Warm/Cool/Cold, and Cloudy/Not Cloudy — then you’d be right one out of twelve times, just by chance.
If this sounds foolish, it shouldn’t: One of the reasons that Agile project management has become successful is because it’s performed this kind of simplification on project management. Instead of predicting costs and delivery date for a project stretching several months (or years) and requiring the coordination of multiple teams to deliver a set of interlocking features, Agile concentrates on projects measured in weeks that concentrate on a single feature. Folks, this is what we call ”smart.”
Still, even with Agile project management, project managers still find themselves facing unexpected surprises. Even in four to six weeks, much can go differently than you expect: new discoveries are made, people get sick or leave, delivered products may turn out to be not what is wanted. The world is full of ”unlikely events” — including being ahead of schedule (it could happen).
The master plan is, of course, the most likely series of events for any sprint or any project. However, each potential unexpected event has a likelihood associated with it. Add up all of those likelihoods and, over a series of sprints, it becomes obvious that you are almost certainly going to be surprised: if not in any particular sprint, then eventually and in many (if not most) sprints. And, of course, there’s nothing to prevent more than one of these surprises happening at a time. Yet, we tend to plan each sprint as if it were to unfold exactly as expected.
Fortunately, while there are an infinite number of potential unlikely events, they tend to fall into a few categories. You might lose any one of your resources but, often, the impact will be the same — you’ll swap in some other resource. While you might not be able to predict which requirement might change, the impact is the same: another resource will be needed or more time will be required to re-do completed work. Some task may take significantly less time than expected, putting you ahead of schedule so you’ll look for the resources that will let you start some other task earlier than expected. Some piece of new technology might not work as expected but, regardless of what fails, you’ll compensate in the same way: abandon some feature or fall back on some proven technology. A vendor or other partner will fail to deliver but you’ll reach out to some other partner, add time to do the work internally, or abandon/defer some feature.
As those examples show, at a high level, many surprises share solutions. Your first step in scenario planning is to only consider those common solutions (what happens if we need some resource or have to drop some feature) and provide a high-level plan for implementing those solutions (here’s where we can get additional resources or here are the low priority features that we can eliminate). When planning for weather, for example, you really just consider how to deal with rain and temperature and make sure you can deal with those (and you don’t worry about a cyclone).
Which leads to your second step: Only develop high-level/low-detail plans for dealing with surprises. Scenario-based plans do not need to be given the same detail as the project’s master plan because the master plan is, after all, the most likely outcome. In all probability, any particular scenario plan will not be executed because that particular surprise won’t occur. Investing a lot of time in planning something that probably won’t happen isn’t the best use of your time. However, over time, one or more of your scenarios probably will occur and having a high-level plan in place will save you time.
Furthermore, as Learning Tree’s Project Management: Skills for Success course points out, not all resources are critical ones…which leads to your third step: only plan for critical resources. Scenario planning for non-critical resources is also probably not the best use of your time. A high-level/low-detail plan for a critical resource that’s common to several solutions may just consist of knowing where you can draw additional resources from and have had a brief conversation with the owner of those resources to determine when and how those resources will be available.
Fourth, use scenario planning to reduce the ”surprise component” of your unlikely events. Ruth Bowen, at Bright Hub Project Management, points out that a useful part of scenario planning is identifying what leading indicators will alert you to when an unlikely event is becoming more likely. When you do see those leading indicators appearing you can consider adding in more detail to what might currently be a very sketchy ’Plan B.’ For example if productivity from one of your critical team members starts dropping, it may be time to confirm that the additional resource you identified is still available.
Scenario planning also does more than just prepare you for surprises. In their post on scenario planning, the site Expert Program Management points that that, among other benefits, ”simply discussing different scenarios with your team, your colleagues, and your stakeholders can shed new light on your project or program, helping you to build a more resilient plan or identify new opportunities you had not previously considered.” If you ever do get ahead of schedule, having a list of ”new opportunities” will let you quickly take advantage of any resources that have been unexpectedly freed up.
Once again, however, maintaining perspective is important. As Bowen points out, you should not be ”treating scenarios like forecasts” — your focus needs to remain on the main plan because it is the most likely outcome. Scenarios aren’t the project, they are a way of simplifying your view of the future that allows you to plan appropriately for unlikely events. It’s like leaving your umbrella in your briefcase: You won’t always need it but you’ll be glad that you made that plan when that unexpected rainstorm blows in.
Looking to take your scenario planning to the next level? Check out Learning Tree’s Strategic Thinking for Operational Managers course for more detail on how to identify the tangible variables that drive scenarios and the relationship between those variables.