If the decision is trivial, you should presumably make it based on your gut feel, choosing the option that makes you feel best. This is the “Blink” (aka “impulse-driven”) strategy that many practice and recommend because it requires the least amount of physical and emotional effort. If you:

• 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.

In case your gut doesn’t give you a preference, the next most popular option is to go with popular opinion. This is the “ask the audience” option in “Who Wants to be a Millionaire”. You will be criticized by fewer people for making the popular choice — unless it turns out to be the wrong decision. If your decision makes a bad situation worse, run for the hills (figuratively speaking, I hope…).

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.

If you feel incapable of making a choice, maybe there is someone you trust to make the decision for you. If that is the case, make sure that he, she, or they share your ethics and morals because you must accept that you are still responsible for the consequences (good and bad) of that decision. Abdicating the decision does not absolve you of the responsibility for the outcome.

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.

You might think that not making the decision at all would reduce or eliminate your responsibility, but if you are the designated decider, that just ain’t true. Avoiding the decision or procrastinating until the decision is out of your hands is coward’s way of “letting fate decide”. If you could have avoided undesirable outcomes by owning the decision but you didn’t, you are just as responsible for the consequences as if you had made the wrong decision.

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.

If you have the luxury of time and have a mathematical bent, you can consider both the pros and cons of each potential decision and let math be your master. You can create a simple spreadsheet for each potential decision you are considering. Each spreadsheet consists of 4 columns:

• 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?

Interestingly enough, this is actually the most challenging strategy. However, you really need to invest the appropriate amount of time and energy to make the right decision when the outcomes have potentially significant impact on you and yours or the environment in which you exist.

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.