Your ability to map and solve complicated, multi-faceted problems is why they pay you the Big Bucks. But you needn’t lie awake at night chewing on the grisly issues. Here’s a painless way to make the tough choices.
Making business decisions that have consequences to your bottom line isn’t as simple as throwing a dart at ideas tacked up on a board. You have to research and weigh multiple aspects of every choice and explain your actions to your managers or even the COO.
You need to make a good decision quickly, as well as keep a record of the key factors you considered.
To aid you in your quest for clarity, we’ve come up with a decision matrix, a method for documenting those considerations up front. This will help you work through complex decisions and to gain support for your choices. Later, if any factors change significantly, you can re-evaluate your options to determine whether your approach needs to change as well.
And you’ll never have to toss a dart at a board again.
Start with a whiteboard, a spreadsheet, or even a blank piece of paper.
Step 1. Title
Name the decision that needs to be made.
Always start with the question that needs your answer. In this example, we’re going to assume that your CEO is concerned about the scalability of the database for the critical in-house client management system (CMS) and has mandated a change. He has tasked you with either defending the current database or choosing a new one. So the question is, “Which database should we use for our expanding CMS that is scalable?”
Step 2. Rows
In the rows of this matrix, list the choices for your solution.
In this fictional simplified case, you start with four database options: DB2, Sybase, Oracle, and SQL Server. Your company has several other database-driven applications, supported by your developers and DBAs, and as it happens, the current in-house production standard is Sybase, with some legacy DB2 applications, including the client management system, plus a few pilot systems on Oracle. SQL Server, however, has received good notices from colleagues.
You may be tempted to consider the three databases that are currently used at your firm. But you’re planning a multiyear commitment to an enterprise system. You want to study the possible future permutations and lay the groundwork now for difficult decisions that may come in the years ahead.
Studying means research. After soliciting feedback from managers in several divisions—which is a necessary step when making company-wide decisions—you found that several developers in the CMS team are pushing for PostgreSQL.
So you add PostgreSQL to your matrix, which now gives you five databases to consider.
Step 3. Columns
In your columns, list the determination factors you need to evaluate.
Sample factors may include expertise level within your firm, purchase and support costs, and integration requirements into your current systems architecture. Don’t forget scalability—the very reason the CEO has you researching database options.
Remember, you’ll also need to clearly answer such questions as, Will the product cost more to buy up front, or will it cost less yet require ongoing support fees? How much will it cost you in time and developer effort to implement and to maintain afterwards? Oh, and did your CEO have a fight with a company, resulting in the mandate, “We will never use [Product X] at this firm?”
Listing the actual decision factors in separate columns keeps rationality ahead of the three P’s of bad decisions: personalities, passion, and politics.
Step 4. Weight
Determine how important each factor is in making your decision.
Some factors are more important than others. Assign a weight to each factor you must consider. You can assign a number from 1 to 10, or use a percentage (in which case all weights together should total 100%). Whatever scale you use, higher weights are more important. The key point is that a weight of 60% is three times as important to you as one that’s only a weight of 20%.
In this example, the all-important scalability issue gets the heaviest weight; it’s the reason you’re creating this matrix, after all. Vendor support comes next, with cost and in-house expertise coming in behind—they’re still important, just not as important.
Rate the rest of your factors from your columns. It’s okay to apply the same weight to some factors. Just be sure to identify which really matter and which don’t.
Step 5. Rank
Use a scale to rank each option.
Now you’ve weighted all your factors, immediately forget about them (for the moment) and rank your choices based on each factor. For best results, hide the weights so you’re not tempted to “adjust” the result based on the answer you’re expecting to get. (Yes, that sounds goofy, but that doesn’t mean it’s not true.)
Here we use a scale of 1-3, where 1 is poor, 2 is fair, and 3 is best. (You can use a broader scale if you like, but be wary not to overthink the problem.)
The current in-house standard database Sybase already has full support, and your employees know it well, so you give it a rank of 3 for both vendor support and expertise. That’s also true for DB2, but you know expertise will decline in the legacy technology, so you might consider giving it 2 for expertise instead. SQL Server has some supporters, but you’re doubtful about scalability, and you don’t have a support contract with the vendor yet, so you score it only 1.
You score PostgreSQL a 1 as well—it’s open source, and so has no official support out of the box. That said, research reveals that commercial third-party support is available (for a price). So you might rank it a 2.
Carry out this same exercise for all the options you have assembled. Don’t be afraid to consult with your reports and contributors for areas they have expertise in. However, also be mindful that biases can emerge: Your DBAs may have a strong preference not to retrain on a new database, while the developers may favor new shiny technology. That’s why you’re the one doing this exercise…and not them.
Step 6: Grading
Grade your results for this decision.
Now you’re nearly done. Multiply the weights from Step 4 by the ranks in Step 5 in each table cell. Add the decision scores across the rows to get the total score for each option.
Evaluate the option scores. Do you agree that the option with the highest score is clearly the best choice? Do you agree that those with the lowest scores are not right for you? If so, you have a good decision matrix with solid, documented reasons for your choice. If not, look again at your determination factors, weight, and rank. What have you missed?
Adjust it until you get results you agree with and can defend. This is your decision matrix. Its job is to clearly illustrate how you made your decision, and why that decision is right for your firm today.
Step 7: Results
This is the decision that proves your point.
As we can see from the decision matrix [view full size], the best choice for the CMS is…the firm’s overall current database choice. It’s what most other applications are using and so it has expertise, already-amortized costs and an existing support contract. At a total score of 2.6, that makes it the obvious choice.
But that doesn’t mean you haven’t learned something: PostgreSQL turns out to be the next best choice, even though you have no applications using it today. That’s useful information. The power of a decision matrix is that you can rationally justify your decisions. But it also allows you to adjust your decision should requirements change.
Step 8: Risk management
Keep the future in mind in the present.
What if annual maintenance costs change significantly? Is there a dependency on an architectural change at your firm (e.g., server operating system version) that could slip or fail, significantly changing your ease of integration ranking?
These concerns can change your answer. In this example, increasing costs on their own aren’t enough to dethrone Sybase, because the weighting of 15% means a rank change from 3 to 2 only drops its weighted score to 2.5. But now you turn up a vendor who can support PostgreSQL cost-effectively, bumping its cost rank from 1 to 2 but its support rank from 1 to 3. Now it scores 2.6, edging out Sybase by a hair.
Test several realistic risks on your decision scores to see whether they impact your ultimate choice. Then take action to prevent or control events that could realize those risks: For example, you can negotiate and contract your maintenance rates based on factors you control (such as the number of concurrent users or amount of data stored).
Later decisions will be a snap because you’ve already laid out the critical factors for future reference. Now you’re thinking and planning strategically. And this is why the boss asks you for your decisions.
You May Also Like:Team & Project Management | Tagged change management, Decision Making, decision process, effective leadership, influence, project management, team leader