As I wrote my last post about the psychology of decision making, I started thinking about some tips that I could share about decision making. As I formulated some of the tips, I realized that Scott Berkun’s checklist captures the essentials quite well.
It occurred to me that Penelope Trunk blog posts would be a great resource, too. Penelope has written tons of posts about making good decisions on managing your career and life. She captures some of the tougher aspects of making choices and how we can better manage our emotions and fears as we arrive at a decision that fits us (important decisions require self-knowledge).
Here are my tips that are focused on software projects:
1. Understand the context
About 3 years ago, I was leading a software project. My Client mentioned a need to import an Excel spreadsheet into a database for a custom web application we were building. My initial reaction was to use SQL Server Integration Services (SSIS) and import the Excel spreadsheet. I had some experience with SSIS and this was the first solution that popped in my head. I realized that the SSIS option could take additional effort. I worked with the Client to understand the problem and clarify the context. I found that this would be a one-time import of the Excel spreadsheet. The Client did not expect to import Excel spreadsheets with similar data in the future. This led me to write a simple Excel macro to generate the necessary SQL statements and perform the import. The entire solution took about 2-3 hours to develop. I have found that taking the step back to understand the context can lead to better decisions and solutions.
2. Clarify your goals or values
It is much easier to prioritize and make decisions when you have clarity on what you want to achieve. In a data warehousing/business intelligence project I was involved in, the goal was to execute our daily loads for a particular data mart in 2 hours or less. The goal drove the design and development process from designing the individual jobs and the approaches we took to develop the staging tables and the necessary code.
An important aspect about clarifying goals is to draw out “lullaby” language as Jerry Weinberg calls it. In business intelligence projects, data quality can be a critical goal. However, data quality can mean different things to different stakeholders. It helps to clarify what stakeholders truly want and if there are opposing goals that may prevent the implementation of a successful solution.
3. Rule of 3
I learned this valuable rule after attending the Problem Solving Leadership workshop led by Jerry Weinberg, Johanna Rothman, and Esther Derby. The rule calls us to evaluate three options while making a decision. The rule helps improve the quality of decision making as it prevents us from picking the first solution that comes to mind and running with it (which can be really tempting as a software engineer!).
A recent example comes to mind. I was leading an application integration project and we had to process flat files as part of this effort. Some of the processing involved co-relating multiple flat files and applying certain business rules. I came up with two options: writing the logic entirely in C# or creating SQL Server Integration Services (SSIS) packages. However, both options, didn’t seem very appealing. The C# option could have resulted in higher development effort. The SSIS option would have introduced another technology in the mix with more maintenance overhead. After talking with other experts at work, we came up with a third option – using SQL Server stored procedures. This was a much better fit for our particular scenario.
I am always amazed at the wide applicability of the Rule of 3. It’s a valuable tool .
4. Write it down
This is probably one of my favorite methods. Writing down what you want to achieve can help clarify the decision for you. If I find that I am unable to write down what needs to be done, that’s a yellow flat that I really don’t know much about the problem. Hence, a decision to choose an option will be tough. It may be better to figure out what needs to be accomplished before spending time and energy on choosing an option.
5. Decision Fatigue
I learned the concept of decision fatigue from Penelope Trunk. There is a huge cognitive load on the brain as you keep making decisions throughout the day. As we near the end of the day, the quality of our decisions suffer as a result. Hence, it is better to devise routines that keep the decision fatigue into account. Critical design meetings at the end of the day are probably a bad idea!
The New York times article has some interesting nuggets around decision fatigue:
The more choices you make throughout the day, the harder each one becomes for your brain, and eventually it looks for shortcuts, usually in either of two very different ways. One shortcut is to become reckless: to act impulsively instead of expending the energy to first think through the consequences. (Sure, tweet that photo! What could go wrong?) The other shortcut is the ultimate energy saver: do nothing. Instead of agonizing over decisions, avoid any choice. Ducking a decision often creates bigger problems in the long run, but for the moment, it eases the mental strain.