How Do You Decide?
Requirements are fundamentally a tool for simplifying future decisions. They pose either hard (“must have”) or soft (“might have”) limits on future decisions that you or someone else has to make. Anytime you want to build (or buy) just about anything, you are facing a ton of decisions. Without some level of “requirements”, you have absolutely no basis for making the “right” decision.
Making Subconcious Decisions
If the decision is repetitive and trivial, you probably have an established or habitual reaction. In this case, you probably are not even aware of the “requirements” that drive your decision, because they are so ingrained. For instance, if you are wandering through the aisles of a store shopping for groceries, many of your decisions will be based on habit. You (or your family) prefer Pepsi over Coke, so Pepsi it is. You prefer chicken to beef, easy choice. Snickers beats Milky Way by far, decision made. It’s not that you have no requirements; it’s just that they are subconscious.
Dealing with Conflicting Choices
What happens, however, when another factor, e.g. your available funds, enter the picture? If you are strapped for cash and Coke is on sale for less than half of what Pepsi costs, what decision do you make now? Do you stretch your money by going with the less-preferred Coke or splurge on the more expensive Pepsi to indulge your taste buds despite the price difference? Decisions only become difficult when you have conflicting requirements. On the one hand, you want the Pepsi because that is your favorite, but if you ignore the price difference, you may may not have enough to buy the leaner ground beef which might be more important.
A Better Basis for Making Decisions
As long as you are dealing with this level of comparatively trivial decisions, you most likely choose based on your personal compass, your personality. Desiderius Erasmus is credited with the philosophy, “When I get a little money I buy books; and if any is left I buy food and clothes.” Assuming you don’t want to run around naked and starving in today’s world, you probably need a better basis for making decisions – in particular when the decisions deal with Information Technology solutions for your organization.
Which Decision Making Strategy Should You Chose?
As the choices you are facing become more complex, the key question becomes, “How can you decide which choice is best for your situation”? You may not be aware of it, but there are amazing recommendations for you available on the WWW (Wild and Wicked Web). These recommendations are simply more decisions, albeit at a higher level, namely which decision-making strategy should you choose when you are faced with a tough decision.
Your strategy probably should be based not on habit or gut feel, but on at least a cursory assessment of the situation, potential consequences, and the risks associated with making the wrong choice. I will present an example of each strategy and how each applies to the development of Requirements for IT solutions.
Lean Business Analysis for Lean Requirements – Simply Put!
The following was extrapolated and liberally adapted to the requirements discovery process from
35,000 Decisions: The Great Choices of Strategic Leaders.
Decision-making Strategies for Better or Worse
Go with Your Gut
- have the requisite experience making decisions of similar magnitude,
- have a credible success record in the outcomes of those decisions, and
- the consequences of being wrong are trivial, both in the short and the long term,
then go with your gut.
If you are defining requirements for an IT solution based on your gut, you need a very strong digestive tract. If the decision is truly trivial, you are probably safe and keeping it simple is a great first step toward keeping it simple (one of the pillars of Lean). The risk you face is if the decision turns out to have non-trivial consequences of which you are not aware. Appropriate use of the Cynefin technique for evaluating the complexity of a situation can significantly minimize the probability of a disastrous outcome.
Go with the Flow
Defining an IT solution based on popular opinion will by default lead you to trying to adapt software designed by someone else to fit your situation – great idea when it fits, sucks when it doesn’t. If you use an out-of-the-box solution, you will either change your process to take advantage of that solution or change the solution to make it fit your organization. Because this strategy costs minimal up-front investment (and we assume that the majority is well-informed), it is often the easy way out. Remember, however, if you use an out-of-the-box solution, you will either change your process to take advantage of that solution or change the solution to make it fit your organization Either way, you still need requirements.
Go with Someone Else
The adage “Trust but verify” seems appropriate here. Given the complexity of modern IT solutions, delegating the authority for defining the requirements is often the only option executives have. Done correctly, you create a cohesive team whom you trust and who deliver fantastic requirements. Done poorly, you might have escalated the probability of project failure by an order of magnitude.
Go with the No
Not defining the requirements for an IT solution is the best way of letting developers run your business. We tried that in pretty much every decade from the ‘60’s thru the ‘00’s and it never has worked. Business experts need to make business decisions and IT experts need to make technical decisions. Only when you get the combination right will it be truly successful.
Go with the Weight
- Positive outcomes
- Relative “weight” of that outcome
- Negative outcomes
- Relative “weight of that outcome
Once you have assigned values to each potential outcome, add all the positive weights and subtract the negative weights. If you compare the calculated value of each potential decision, the one with the highest weight wins. Of course, this strategy depends on an honest and unbiased assignment of the relative weights, meaning it is subject to subconscious (and conscious) manipulation that can skew the results toward a desired outcome. In that case, it becomes a very time-consuming and draining approach for justifying your “gut instinct” (see 1, above).
Incidentally, the pros and cons you capture here are a very viable way of clarifying what you really want. These are “Requirements” that form the basis for testing the situation that is created by your decision when the dust settles. If the good and bad consequences you identified are not recognizable when your decision has been implemented, your decision might still be correct but the implementation of it was flawed. Life has now gotten a lot more complicated, but that is what makes it interesting, right?
Go with the Requirements
That, in turn, implies that you have sufficient time available. You can get the time by successfully applying the less time-intensive strategies listed above to less important decisions. Only then will you have the time needed to reflect on potential positive and negative consequences and define the desired outcome of each decision. At this stage, you are truly defining the Requirements for what you decide constitutes a successful resolution. The strategy most likely to succeed for any major IT project is making every decision at the appropriate level of detail as quickly and efficiently as possible.
In any given time-frame, you may apply each of these strategies and every combination of them in your day-to-day life. On an IT project, you will need every strategy listed to make the right decision at the appropriate level of detail at the right time. That is a lean definition of Lean Business Analysis which delivers Lean Requirements.
Where life in today’s world gets interesting is when we try to adopt lean thinking to the decision-making process – but that is a topic for later posts. I will be ranting and raving about what constitutes “lean” business analysis” and “lean requirements” in several upcoming posts. If you want an in-depth answer now, take a look at my training course Lean Business Analysis for Lean Requirements.