PMO Bytes

I saw this quote from Tom Peters, “Don’t shy away from the term ‘love.’ Do you in fact l-o-v-e your project?”

It got me wondering what makes up the four-letter acronym.

Could it be ‘Late, Overspent with Vexing issues and an Exhausted team’?

Do you hate to love your project or you still love it the way it is?

In this LOVE relationship, what role do you play? What are you doing to sustain or even improve it? Aren’t you doing anything at all?

I know that you have a plan, as you always do, but I have never seen you following it.

In fact, you like to be late. Do you know that when you are late, many people get hurt?

Sometimes, we do not see eye to eye. It’s fine. We should learn to agree to disagree.

What is your tolerance before you snap? Is this just about ego?

We know that life is full of unknowns and surprises. Did you make any unnecessary assumptions in this bond?

Remember to talk it out when you have a conflict. Communication is always your best way to avoid confusion.

When something goes wrong, what do you do? Do you blame it on others or have the courage to admit your own mistakes?

Although you are fully accountable for the outcome of this relationship; just don’t take it too hard if things turn out bad. You are not omnipotent.

You once said that this relationship is too risky, yet you jumped in right away. Is it so critical that you must go down this path? Haven’t you learned your lessons?

If you are still hoping for a PRINCE in shimmering armor to save you from your mess, wake up! Do something and stop just PiMPing your project.

“Beep! … Beep! … Beep! …”

The cacophonous sound of the dreaded alarm clock pierced through my tympanic membranes shattering another ‘millionaire dream’ that I was having a moment ago. I wished I could have a gigantic hammer nearby to plunge the final silencing blow to the cussed alarm clock. “Time to wake up”, a voice echoed inside me. Reluctantly, I dragged myself out of the cozy queen-size bed to reach for the ‘Snooze’ button on the clock. I was glad that I have this ingenious snooze function in the new alarm clock that I bought recently (the previous one failed to survive the assault of a flying pillow). “Another five minutes”, I told myself. Then another five minutes after another five minutes and it went on and on…

I was experiencing a strange phenomenon that most people call the ‘Snooze Button Effect’. How could such a nifty invention turn bad? If you google for the keywords ‘Snooze Button Effect’ or ‘Snooze Button Addiction’ you will easily find tons of articles on this topic. One article aptly describes this phenomenon as,

“An occurrence whereby a small press of a button at a given time can supposedly delay an undesirable event from happening for 9 minutes. Contained in these 9 ‘precious’ minutes is an unknown substance that seemingly causes people to be addicted to its delusional effects.”

In general, the snoozing habit is detrimental to sleep health and counterproductive to a fresh start of the day. And yet, many people, including myself, are deadly addicted to it. It is in fact a form of procrastination in disguise that comes with a long list of drawbacks and side effects. I am not going to discuss the side effects here as you may easily find them in most of the articles available in the internet. What I am interested is to explore a similar manifestation of this effect in the field of project management.

Let’s face it. There seems to be an invisible ‘Snooze’ button in every project. Whenever the deadline is near, we are tempted to press the ‘Snooze’ button. “It’s fine to postpone the deadline for a couple of days”, we keep telling ourselves. No harm doing so as we can always crash back the time lost elsewhere isn’t it? Wrong! This is just a willful thinking. Once we start to lay our fingers on the ‘Snooze’ button, there is no turning back. We will just get mired deeper into this perverse addiction. Don’t believe it? Just ask a few project managers around you when was the last time they have altered the deadlines in the Gantt chart.

There are two ways – planned and unplanned – that a project manager may introduce the ‘Snooze’ button in his or her projects. The unplanned way is what I have just described above where the project manager keeps altering the forever fleeting deadlines. This is obviously a lack of control and discipline. There is no incentive for people to stick to the deadlines. To them, deadlines are nothing but a bunch of insignificant dates that are as ephemeral as the morning dew. On the other hand, the planned way is the exact opposite. In this case, various types of buffers are being planted strategically within the project timeline so much so that sometimes it is hard for one to tell when the actual deadline is. This resembles the scenario where a person deliberately set the alarm clock to go off an hour earlier just to keep snoozing on until the actual wake-up time. As we know, adding unnecessary buffers, or more commonly known as paddings, is bad for a project regardless of what reasons we have. Doing this not only unrealistically inflates the project timeline; it also makes it difficult for the project manager to produce any accurate estimation on the project status. So why are project managers still stuck in these padding frenzies? Perhaps, we can understand this a little bit better from the explanation given by Rita Mulcahy in her book “PMP Exam Prep” – “I have no idea how long it will take. I do not even know what I am being asked to do. So, what do I say? I will make my best guess and double it!”

How can we resist the temptation of pressing the ‘Snooze’ button?

Many sleep researchers and therapists around the world have come up with various tips and self-help advices that help people to shake off this baneful habit. Most of these advices try to address the problem by either making it very difficult for people to access the ‘Snooze’ button or, in the extreme case, removing it entirely. For instance, there is this innovative product, Clocky, which is an alarm clock outfitted with wheels that allow it to hide itself in order to force the owner awake in an attempt to find it. Similarly, is it even possible to have the option to postpone deadlines completely removed in projects? If not, are there any ways to make the process much harder to accomplish? For example, will it help if we were to enforce that each amendment of deadline has to be properly documented and approved? Maybe, this is something interesting for the project management gurus out there to think about.

The most important thing is, next time when you are tempted to snooze a project, remember to ask yourself this question – “Is this the only option you have or you’re just addicted?”

 “Simplicity is the ultimate sophistication” Leonardo da Vinci once said.

As we try to simplify things with models, metaphors and acronyms, we unknowingly add on a layer of abstraction to the whole matter. No doubt things look a lot simpler and neater on the surface, but as soon as you peel off the surface layer and take a peek at what is hidden underneath, you will realize that it is still a whole mess down there. I agree that a lot of sophisticated works are required to turn complexity into simplicity. We see these in daily life from mathematics and engineering to business management and marketing phrases. So why are we doing this? Apart from being simple, they are often sexy, catchy and easy to latch on. Some of the better ones, like the Five Forces, Black Swan and PMBOK, have even taken on a memetic life of its own.

In the project management domain, we too have a handful of good examples. For instance, the ‘chickens and pigs’ concept that Ken Schwaber introduced for the daily stand-up is so widely accepted that it is now being borrowed and adapted as analogies in other fields. Why? This is because the concept of pigs>bacon>committed versus chickens>eggs>involved is so comme il faut that the metaphors link up naturally in the mind. It just clicks and sticks.

What about its cousin – the RACI matrix? Well, it does have its own supporters. It is also an acronym-based matrix. The only difference is it has not enjoyed the same popularity as the ‘chickens and pigs’. In fact, quite a lot of people find it confusing. I am quite sure there are many project managers out there who are still not very sure how to fill up the matrix correctly. I have actually met a few.

Wait a second. Isn’t RACI matrix a well-defined matrix? So why is it so confusing and difficult to understand? It seems like people are having a tough time figuring out the differences among the four key responsibility roles, especially between the ‘accountable’ and ‘responsible’ roles. Is it because of the definitions of the roles are not clear enough? Definitely not! What could be the reason(s) then?

If you are observant enough, by now you should have spotted another major difference between the ‘chickens and pigs’ concept and RACI matrix. The ‘chickens’ and the ‘pigs’ are far more lifelike than the dully represented ‘R’, ‘A’, ‘C’ and ‘I’. There is nothing wrong with the definitions. People just find it difficult to relate the theories with practical applications. Yes, RACI needs a story and some metaphors for people to connect it with real life examples. This is exactly what is missing. Without further ado, I hereby present you a comic for RACI – “Gang of Four at Tea Party”. Hope you like it.

I met someone recently who asked me this question, “Do you think it makes sense to use Six Sigma methodology in the processes in finance sector?” What an interesting question that got me thinking over the factors we should consider while evaluating whether Six Sigma is suitable for an industry or an organization. Perhaps we should first take a look at what Six Sigma is and its pros and cons before discussing further.

Six Sigma is a well-known business management strategy that uses a set of quality management methods to improve the quality of process outputs by identifying and removing the causes of defects and minimizing variability in the business processes. Companies adopt Six Sigma to help them improve existing processes and reduce wastages. In spite of its widespread popularity and numerous extensively propagandized success stories and reported savings, Six Sigma does have its own issues. Over the years, Six Sigma has been criticized for its over-obsession with process control and statistical figures. Many people also find it too complex and difficult to implement, not to mention the various costs associated with training and retaining the ‘belts’, and this would have probably turned a few of those who are interested away. In fact, a study conducted by QualPro claims that “among 58 companies that have announced broad use of Six Sigma, the stock performance of 91 percent trailed the S&P 500 index since the launch date of their implementations” (note: the validity of this study has been rigorously challenged in this blog post). Now, putting the validity of QualPro’s claim aside, it seems like we have mixed feelings towards whether Six Sigma is the ultimate go-to methodology to help companies achieve operational excellence. It is like durian – you either love it or hate it.

Apparently there are many factors to consider while determining if a particular organization is appropriate to adopt Six Sigma. Factors like organization culture, operation maturity, management style, environment, and nature of business etc. each has an important role to play. Trying to address all these factors in one fell swoop would be crazy, if not impossible, to achieve. However, setting the expectations right up front and avoid falling into any of the Six Sigma false myths could help you see things in proper perspective and make better judgments, potentially saving you from repeating the same mistake made by former Home Depot CEO Robert Nardelli. Below are six stigmas that you should watch out for if you are considering adopting Six Sigma in your organization.

1. The project rush: When the CEO and top management shout “Six Sigma”, everyone down the hierarchical chain gets the pressure immediately. People start to eat, sleep and dream on Six Sigma. All of a sudden, holding on to a couple of Six Sigma projects becomes the new trend. Every topic starts and ends with a project as if you are jobless if you are not on any project. People see this as ‘aligning’ with management strategy. Whether the bunch of Six Sigma projects makes sense or not does not really matter. I have come across a one-year Six Sigma project that claims to save USD 2,000 per annum on toilet paper. Ridiculous, period. We have created a ‘project rush’ phenomenon.
2. Project orphanage: This is actually a by-product from the ‘project rush’ phenomenon above. Just like the post-war baby boom period, we will usually see a sudden surge in the amount of projects driven by the optimism we have in the Six Sigma program. Imagine what will happen if we keep producing babies but no one is going to take care of them after they are born? Yes, most of them will end up in the orphanage. This is exactly what will happen when the entire focus is on projects; people tend to pay less attention to the bigger picture beyond the project lifecycle. The belts hop from one project to another gleefully churning out tons of project deliverables, if not trashes. More than half a dozen of these will end up in the project orphanage. Sounds familiar? Do you have a proper product lifecycle and transition plans to support your project handover?
3. Tunnel vision: Most Six Sigma projects focus on streamlining, cost-cutting and reducing waste. While there is nothing wrong in these approaches, emphasizing too much on them obsessively will result in a tunnel vision effect that restricts the growth of the organization in other dimensions. As QualPro's CEO Charles Holland says, “One of the chief problems of Six Sigma is that it is narrowly designed to fix an existing process, allowing little room for new ideas or an entirely different approach.” Perhaps we should diversify our focus and have more Six Sigma projects in areas like market research and new product development that are usually neglected in organizations that practice Six Sigma.
4. Copy & Paste: I don’t like the phrase ‘free size’ as it means that you are not tailoring the product to your needs. Many people have the assumption that they have to follow everything exactly in the standard Six Sigma methodology out-of-the-box. No, that is not true. Those that have experience in implementing any form of methodology know that the ‘Copy & Paste’ approach will not work as we have to adapt the methodology to suit our needs. We know how rigorous and tedious a standard Six Sigma DMAIC process can be. In some fast-changing industries, the timeframe for a small project could be as short as three to four weeks. If we were to apply the standard Six Sigma process, the project probably would have ended before reaching the ‘Analyze’ step. In an environment where time and resource are scarce, we ought to be realistic.
5. Missing the big Y: In Six Sigma terminology, the big Y refers to the most important business results and measures that are linked to critical customer requirements and expectations. This is what a Six Sigma project seeks to improve. However, it is not uncommon to see the big Y being missed in projects. Sometimes, this is due to the incorrect causal relationships established between the little X’s and the Y’s, but most often than not, it is the big Y itself that is being wrongly identified. In other words, the objective of the project is unclear. This usually happens because the belts do not understand the customer requirements and expectations. Customers just tell us what they want; it is our job to find out what they really need. Setting up a structured and rigorous project review and selection process may help to reduce the number of missing big Y’s.
6. Elixir to all woes: A common mistake that most people make is they bet everything on Six Sigma and expect it to cure all their corporate woes. They have forgotten that Six Sigma is just a tool and as a tool, it depends pretty much on the people using it to make it a success. In other words, it is the execution part that counts. We know that the performance of an organization depends on many factors. The launch of a Six Sigma program alone is insufficient to address all the problems that the corporate is facing. Being carried away by the fads and naïvely believing Six Sigma as an elixir to all corporate woes is probably the catalyst that sparked off the torrent of Six Sigma jokes. To wrap this up, below is an interesting one for your philosophical muse (source: Bright Hub),

A shepherd, herding his flock in a remote pasture stopped as a brand new Mercedes was advancing toward him. The driver, a young man stylishly dressed in an Armani suit got out and asked the shepherd “If I tell you exactly how many goats you have in your flock, will you give me one?” The shepherd looked at the man and said “Sure.” The young man takes out his notebook, connects it to a cell phone, logs into a NASA page on the Internet, calls up a GPS navigation system, scans the area around him, opens up an Excel spreadsheet, spends some time doing complex formulas, and sends an email, to which he receives a fast reply. He next takes out his hi-tech miniature printer to print out a detailed report and says to the shepherd “You have 1,586 sheep." "That’s correct,” the shepherd replied. The young man picked up the biggest animal he could lay his hands on, but before he could drive away, the shepherd said, “If I can tell you exactly what your business is, will you give me back my goat?” “Sure,” replied the young man. “You are a Six Sigma Black Belt,” said the shepherd. “That’s correct,” said the amazed young man. “How did you guess that?” He asked, curiously. The shepherd replied, “You turned up here although nobody called you. You wanted to get paid for an answer I already knew, to a question I never asked, and for all your tech-savvy skills, you don't know crap about my business. Now give me back my sheep!”

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.