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.
And so it goes on and on…
The above is a series of common breaking points that may lead to unfortunate project failures. You started to ask yourself if you could possibly prevent them from happening. It is not easy, you admitted. Yet, you are still expected to sail past them in all the projects you handle. This is because when a project fails, it is always the project manager’s fault. To many people, this statement holds true regardless of whatever creative reasons you can come up with to explain for yourself.
Blame it on the project manager if the project fails.
You have seen how a project manager was blamed for a project disaster when the actual problem lies with an incompetent vendor. You have also witnessed how a project manager was parachuted as a scapegoat to salvage a doomed project. There is a protesting voice inside you crying “It’s unfair!” But as a project manager, your job is to listen, understand and execute effectively to ensure you deliver the project that meets the stakeholders’ expectation. No wonder your mum has been warning you that project management is the most stressful job in the world. Damn it, you regretted not taking her advice.
Now back to the key question – “Should a project manager be fully accountable for the success or failure of a project?”
I can spot a few raised hands. In my opinion, the answer is ‘Yes’ but it depends. You can’t simply make someone accountable for something that he or she does not have the authority to work on. Forget about the question on fairness for a moment, the lack of authority will mean that the project manager has to grope across the political minefield barefooted. You don’t need an economist to tell you the survival rate for this. In general, it is easy for us to push all the responsibilities and accountabilities to the project manager. But without the right authority, there is very little thing the project manager can do. He will not have any decision-making power, not given any budget, and probably don’t even have any control over his own team. It is like sending a general into a battle without an army backing him up. Therefore, it is imperative for project managers to be given the necessary authority to run their shows. Unfortunately, most organizations failed to realize and understand this.
If I were to add on one more breaking point to the series above, it will be –
I came across this interesting dialogue few years back.
Sometimes, asking question in a wrong or unclear way may confuse the listener and in some cases, create unnecessary misunderstanding. Asking question is an essential skill required in the requirement gathering task in most projects. It is a soft skill that looks simple on the face of it (who doesn’t know how to ask question?) but extremely difficult to master. One useful guideline that may help to improve effectiveness in the communication is to focus on the 5 Ws (What, Why, Who, When and Where) in your question. First, you need to consider what to ask in your question and how to phrase it and decide whether the question should be open-ended or specific and direct to the point. You need to keep asking yourself why you need to ask the question and whether it is appropriate and adequate. Then you must also make sure you are asking the question to the right person, at the right time and right location. The approach you use and the words you choose in your question are also critical in order not to leave any room for ambiguity. If there are any special terminologies or idiosyncrasies that are expected to be used in the conversation, they have to be clearly defined and communicated up front to everyone to prevent unnecessary confusion.
For example, I once came across a print on a mug that says – ‘Failure is not an option’. Speaking the lingua franca in software development industry, most software developers will interpret the phrase ‘not an option’ as ‘mandatory’ since anything that is not optional to them must be mandatory (you will know what I mean if you have ever tried filling up an online form where all fields with a star ‘*’ are mandatory and the rest are optional). In other words, a simple and positive statement like ‘Failure is not an option’ may turn out the opposite way as ‘Failure is a mandatory’ if it is not interpreted correctly. If you think this is funny, it only gets worse when the whole event of requirement gathering is to be conducted in a multicultural and multilingual environment where the differences in culture and language pose to be a challenge in communication. Still not convinced? Take a look at some of the funniest Chinese-to-English translations at Engrish.com.
“The ability to ask the right question is more than half the battle of finding the answer”, once said Thomas J. Watson. How true this statement is. Yet to be able to ask the right question, it takes more than just addressing the 5 Ws mentioned earlier. At the very least, your question should be SMART – Specific, Meaningful, Appropriate, Relevant and Timely. On top of all these, you still need to close the loop. You need to make sure that the person fully understands your question before he or she attempts to answer it. One way to achieve this is to ask the person to explain your question back to you. Listen carefully to what the person says and clarify any dubious points immediately. Keep in mind that all of us come from different backgrounds and something that looks common sense to you may not be very obvious to others. The important point is to keep your question SMART to avoid ambiguity.
Occasionally, people may like to ask questions which no one is able to answer and they feel great about it. Some of those who are more egotistic actually feel intellectually superior and excited when no one is able to understand their questions. Honestly, asking a question that is difficult to answer is no big deal. The real challenge is how to raise a question that is simple enough that everyone, from the CEO sitting in the corner room to the pantry lady, is able to understand and hopefully, provide some good answers. Anyway, at the end of the day, what is the point of asking a question that you can’t find an answer? Keep asking SMART questions, and not questions that make you look smart.
To ask a hard question is simple. However, to ask a simple question is hard.
In this PMO Byte, I have created a simple crossword puzzle for those who would like to test out how well they know about the terminologies in project management. I will post the answers in the Comments section later. You may want to give it a shot before looking at the answers.
PM Crossword Puzzle Feb 2011
2. Tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems.
4. A diagram that shows what factors can be contributing to an issue or problem.
8. Mathematical measurement that provides a way to forecast future performance based on what's happened thus far in the project.
9. Used to translate customer requirements to engineering specifications.
12. A collection of projects whose objectives are not related to each other.
13. A schedule network analysis technique.
15. A task or series of tasks performed over a defined period of time.
16. A piece of work requiring effort, resources and having a concrete outcome.
17. Any factor that potentially can jeopardize the successful completion of a project.
18. A tender document that defines the procurement requirements of a project.
19. Deliverables-oriented, graphical, hierarchical representation of the work required to fulfill the project scope statement.
20. A procedure for analysis of potential failure modes by the severity and likelihood of the failures.
21. This happens when the requirements and work on a project expand in an unmanaged manner.
23. Sum of knowledge within the profession of project management that is standardized by PMI.
25. A type of bar chart that illustrates a project schedule.
26. A statement of the scope, objectives, participants, roles and responsibilities in a project.
27. Graphical representation of a process, showing sequential activities, branches, and decision points within the process.
1. The time a task can be delayed without delaying the project.
3. Member of senior management who supports the project and ensures adequate funding and resources are made available.
5. An iterative, incremental methodology for project management often seen in agile software development.
6. A review that is done at the end of the project, during the project closure.
7. Description of product functions or deliverables that collectively will satisfy the overall business goal.
10. A contractually required work product, produced and delivered to a required state.
11. A key event during the life of a project.
12. A model to analyze and represent the tasks involved in completing a given project.
13. The practice of identifying, documenting, approving and carrying out changes within a project.
14. First meeting with the project team and the client of the project.
22. Matrix for clarifying roles and responsibilities in projects.
23. A histogram chart showing the values in descending order.
24. An estimate of funds and/or resources planned to cover a program or project.