Let’s Play Sudoku

 

Have you heard about Sudoku? I guess this may sound like a dumb question. Who has not heard about these logic-based, combinational number-placement puzzles that have taken the world by storm? It does not matter whether it is the digital or paper type, we see people in the subways, cafes, offices, and corridors pulling their hairs and biting their nails off while trying to solve one of these puzzles. Have you ever played one yourself? If not, I would suggest you to try solving one today at Web Sudoku.

I love playing Sudoku. Not only that it helps to oil up my rusty brain once in a while, it also serves as a constant reminder on how we can do better in project requirements gathering. You would probably ask – “Sudoku and requirements gathering, am I missing anything here?” As we shall see later, there are a lot of similarities between Sudoku and requirements gathering. In fact, we may even apply some of the strategies we have learned from solving Sudoku puzzles in gathering project requirements.

Fill in the blanks

A typical Sudoku puzzle consists of 81 square boxes arranged in a 9x9 layout with some of the boxes filled with numbers ranging from 1 to 9. These ‘given’ numbers serve as your initial clues. Your objective is to fill up the rest of the empty boxes with numbers to complete the whole puzzle. Simple, isn’t it? This is exactly what you will be doing when you gather requirements. Usually, you start off with a couple of clues on what are needed for the project. You have gotten these clues from your interviews and conversations with the stakeholders and the operational documents they have shared with you. The remaining part of your job is to find out the missing pieces and link the clues together, or connect the dots if you would prefer to call it, just like the way you fill up the empty boxes in Sudoku.

Rules of the game

All games come with rules. There are rules that you have to follow when you fill up the empty boxes with numbers in Sudoku and you are not supposed to pick any number randomly. Rules or constraints, depending on how you see them, impose limitations on what you can and cannot do in the game. In a similar way, constraints narrow down the options you have and draw boundaries around your requirements. They affect your scope. You have to work with the constraints as no rule can be broken. There are various types of constraints in a typical project environment. Budget, resource, timeline and the common PESTEL macro-environmental factors are usually what you have to deal with. Most people see them as constraints but I regard them as guidelines that help to reduce the amount of possibilities and curb uncertainties. It may sound counterintuitive, or even absurd, that more options and possibilities give rise to higher complexities and uncertainties in a project. In the game of Sudoku, the difficulty level increases with fewer clues given in the opening of the game. You will be exposed to more options initially and have to make a lot more assumptions which may result in higher level of risk and uncertainty. The same applies to requirements gathering as well. Always ensure that your scope is properly defined and try to gather as many clues as possible to form the initial draft of your requirements list and you are set to a safe takeoff.

Strategy 1 – Pick the low-hanging fruit

This is the favorite strategy that many people like to use, especially in the early part of the game. It is crucial to have the initial assumptions, or guesses, right as it will save you a lot of precious time from going down the wrong path. Go for the easy ones first. Not only that a good start will boost your confidence and put you on the right track, it will also narrow down your options while showing you clearer what that end result should be. When you gather requirements in your projects, look for the easy or obvious ones initially. Make validated assumptions for gaps in between the requirements and review with your stakeholders to confirm your understanding.

Strategy 2 – Divide and conquer

Sometimes when a problem is too big to digest or handle, it is always good to break it down to smaller and manageable parts to be addressed separately. Never look at a Sudoku puzzle as if it is a piece of Picasso’s painting and try to solve it. Break it up into rows and columns or localize it into individual 3x3 squares. You will have a better chance solving it this way. You should do the same to your requirements. When a requirement appears to be muddled and murky, break it up like the way you would to obtain a work breakdown structure. Take a microscopic view on each of the sub-requirements and remember to link them back as a whole so that you do not lose sight of the bigger picture.

Strategy 3 – Deduction

Deductive reasoning works from a ‘general’ example (or theory) to a ‘specific’ conclusion and is usually referred to as a “top-down” approach. In Sudoku, the rule states that there can be only one occurrence of each number from 1 to 9 in each of the rows, columns and the 3x3 squares. With this, you can confidently deduce that an empty box should be filled with the only missing number within a row if there is only one empty box left in that row. In other words, you rely on the general rules (our theories) and the given clues (our observations) to arrive at a conclusion on what number to be filled in an empty box. In project requirements gathering, you may also apply the same deductive reasoning via a top-down approach to navigate from a set of high-level requirements and dive deeper to discover more specific details of the requirements or sub-requirements.

Strategy 4 – Induction

Inductive reasoning works the opposite. It starts from a ‘specific’ example (or observation) and works towards a ‘general’ conclusion. This is also called a “bottom-up” approach. Deductive reasoning is the more common and straightforward approach. However, it does not always work especially when the clues (our observations) given are insufficient to help us draw a definitive conclusion. In this case, you have to start with the observations, find a pattern and work backwards to reach your conclusion. It is common in Sudoku that you get stuck in a situation where the number of available clues is insufficient to help you make your next move confidently. This is the time where you have to identify the patterns in the clues, make a few smart guesses or assumptions and test out your hypotheses before filling up another empty box. In fact, solving a Sudoku puzzle successfully usually requires frequent interplays between deductive and inductive reasoning. It is true that you do not always get all the requirements you need in a project as stakeholders are usually not very sure on what they need themselves. You may apply inductive reasoning to study the piecemeal requirements you have obtained, link them together and generalize them into a unified and distinct requirement.

Strategy 5 – Stay cool

I have a bad habit. I lose my patience too easily, especially when I am running out of time. More often than not, I will tend to skip the logical thinking part and go for the hunch. The consequence is I will end up making a lot more mistakes than I usually do and ruining most of the games. It is important to keep yourself calm in all situations and you should be in any game you play. You have your bad days, so does everyone else. You don’t get to choose your Mr. Nice in your team. Your stakeholders might be less cooperative than you thought. They might be unreasonable or even as cantankerous as Gregory House. Fret not! Staying calm and having a clear mind will help you to complete your requirements gathering task more objectively and professionally.