When a crisis occurs, managing that crisis has consequences for the test team's future work. Working through the...
crisis itself is the first part of managing the crisis. The second part is managing the effects of working through the crisis. We must consider not only the crisis, but the things that we did not do because we were in crisis.
We have several choices when it comes to managing the work that got dropped because of a crisis. One way is to simply work harder and hope we catch up. Another method is to just not do the things that we let slide during the crisis. But there is a third way, a better way. We can identify the opportunity cost of the crisis, and we can manage that cost explicitly. Senior managers will need to consider what those opportunity costs are in order to guide their teams to resolve issues with the least amount of expense.
What’s an opportunity cost?
Put simply, the cost of doing something is not only what you actually spent -- in time or money -- but also the costs associated with the thing you decided not to do. For example, if I buy a sandwich for lunch today, then the cost of the sandwich is $5. The opportunity cost of the sandwich is the soup that I decided not to have for lunch (too bad; I like soup). Opportunity costs are everywhere, measured in time, money or both. The opportunity cost of handling a crisis is all the things we thought we were going to do today (but that got interrupted by the crisis and so didn't happen).
Let's examine a fairly common crisis, a moment where we had to "drop everything" and work on something else. I should note that this actually happened. Names have been changed to protect the innocent.
I was the test manager for Acme Widgets, a small company that made mobile-enabled data collection and synchronization software. In non-marketing terms, we made an application that ran on handheld devices (think Palm Pilots), field workforces would each get a device with forms and the ability to input pictures, and all those devices could be synchronized to a central repository, where managers could collect and collate the data. Most of our customers were inspection companies (think fire inspectors, or cattle inspectors).
The “drop everything” moment
One day, as my group and I were happily testing, the IT manager disappeared into the VP of Engineering's office. Ten minutes later, they both showed up in our shared testing office: "What are you working on?" There was a problem: all of a sudden customers were complaining they couldn't sync their devices. There's no question that we were in crisis mode. There's also no question that it was the right thing to do: getting customers back up and running was the first priority.
That's how the conversation starts; the "drop everything" moment has arrived. The question now is how to minimize the cost of the crisis. How do we recover in the best way possible?
Look at what’s not getting done
We look at the opportunity cost of the testing crisis. The opportunity cost of "dropping everything" is the benefit you would have gotten from the things you meant to do that day. In our example, my group and I hadn't planned to help debug a customer syncing problem (which incidentally was a size problem in the central database, and easily fixed once we figured out what was going on). Instead, we had planned to:
1. Do three phone screens
2. Revise the job description for the tester we were trying to hire
3. Test the new data type that was going into the next release
4. Pair with a developer on some data analysis tools he was writing for us
None of that happened. So the opportunity cost of the crisis was the benefit we would have gotten from all of those things:
- Because we didn't revise the job description or do phone screens, we lost some potential candidates, and possibly a great tester we could have hired.
- Because we didn't test the new data type, we didn't find a bug in it. That bug eventually delayed the release by a day or two.
- Because we didn't pair with the developer, we didn't get the data analysis tool. That project eventually got dropped; we had lost the window of time when someone was available to work on it.
Make adjustments to reduce the cost
So, why do we care about opportunity cost? We're not going to choose to NOT solve the crisis so that we can do the things we have planned.
Opportunity cost lets us make the consequences of our decisions explicit, so that we can figure out how to manage them once the "drop everything" moment is over. By considering opportunity cost, we can make adjustments to reduce that cost, or to reduce overall future effort. In the example above, if we had considered opportunity cost, we could have spared one tester from the crisis to go sit with the developer and get that data analysis tool, which would have reduced testing cost going forward and still allowed us to manage the crisis. In the same example, considering the opportunity cost of not testing the new data type, we could have pushed out the release date, since we knew we were likely to find bugs (and fix them!), and delaying finding means delaying fixing and the eventual release.
Considering opportunity cost does not by itself reduce or change costs. It does make those costs explicit, so that we can consider them and manage them appropriately. We can't avoid all "drop everything" moments. We can deal with them better. Opportunity cost improves transparency and makes effective decisions easier, both within and outside of testing groups.
What ways have you found to manage opportunity costs when dealing with a “drop everything” situation? Let us know by sending an email to firstname.lastname@example.org.