PMO Bytes

If I tell you that 4 = 3, you probably think that I am crazy. Don't believe? Let me try to prove it to you.

Still don't believe it? Something is missing here? Yes, you are right. If you examine closely, there is a fallacy in the equations above. We started off by assuming a + b = c. This makes the term (a + b – c) equals to 0. As such, we are not supposed to divide both sides of the equation in the last step by this term as this will result in infinity. The lesson learned here is everything happens for a reason. It is up to us to find out the real cause it. So next time when you hear people saying "I don't know how it happened" or "There is no reason for this to happen" in your project, challenge them. Do not accept 'no reason' as reason. Be curious, stay doubtful!

It is very common for us to come across similar situations in our projects where things were not working the way we wanted them to be and yet we couldn’t figure out what could be the root causes. Some people will resign to fate believing that they were just ‘unlucky’ while others will try to ‘shift’ the problem to someone else and find a scapegoat in order to get out of it fast. What would you do when you are stuck in an entanglement in your project which you are not able to find a way out? Instead of putting on your running shoes immediately and attempt to escape from it, do you have the courage to open the Pandora’s Box and try to find the ‘hope’ inside? If you are gung-ho enough to tread on the land where few have dared to walk, here are a few tips that you may adopt. I would call this the CAR process – Cause Analysis, Action Plan, and Review Progress.

1. Cause Analysis or Root Cause Analysis (RCA): This is a set of methods that will help you to identify the root causes of a problem and should be the first crucial step to be performed. The most commonly used techniques include Fishbone Diagram, Failure Mode & Effect Analysis, Cause & Effect Matrix, 5 Whys, and Fault Tree Analysis etc. Each technique varies slightly from the others, and depending on the nature of the problem you are facing, you may need to select a suitable technique that best fits your situation.
2. Action Plan: Once the root causes have been identified, the next step is to define follow-up actions to be taken, assign owner and set deadline for each of the action items. In fact, this is the step that most stakeholders are interested in. Finding the root causes of a problem, no doubt, is crucial. But what the stakeholders would really like to know are how and when to get them fixed. Defining action items, sometimes, may not be a straightforward task. You may even need to organize a few brainstorming sessions and focus group discussions in order to come up with a viable action plan.
3. Review Progress: Do not be too happy when you have the action plan ready as your job is not over yet. Obviously, you still need to review and monitor the progress of all the action items in the action plan. The action plan defined in the previous step is definitely not foolproof and therefore, requires continuous review to ensure the objectives of each action item are achieved. In some cases, you may even need to modify the action items in order to adapt to any environmental changes. This is important and you may need to keep doing it until all the action items in the action plan are completed successfully.

By following this CAR process, I hope you will have a safe and smooth drive through your journey of problem solving.

Whenever someone asks me what PMBOK is, I always find myself spending a long time and having difficulty to explain to the person the concept of PMBOK in a short and digestible way. I have been thinking – "Is there a way that I can describe or paint a nicer picture of PMBOK?" This has inspired me to a little experiment. With some trial and error, the outcome of the experiment is a surprisingly cool portrait that not only illustrates PMBOK visually but also describes it in words that reflect the key concepts of what it is. The words in the portrait were taken from the article 'Project Management Body of Knowledge (PMBOK) Guide' that gives an overview of PMBOK and the size of each word maps directly to the number of times it appears in the article relatively. Hence, it is not surprising to see some common and important words like "PROJECT", "MANAGEMENT" and "PROCESS" etc. appearing larger than the rest of the words. In a way, this looks like a digital DNA of PMBOK, isn't it? I hereby proudly present you – A Portrait of PMBOK!

Click here to download the high resolution copy of the PMBOK portrait.

What is Simplicity? We have heard about the 'KISS' design principle (an overly abused cliché). For those who have not, the KISS principle states that simplicity should be a key goal in design, and that unnecessary complexity should be avoided. Edward De Bono published a book with the same title ('Simplicity') emphasizing the importance of keeping things simpler in this increasingly complex world. The great Albert Einstein once said – "Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction". However, he also warned that "Everything should be made as simple as possible, but not simpler". No doubt, being simple is important, but the key question is how simple we can go without trading off important details? I will leave this question for you to work on (read about Occam's razor if you are interested).

Simplicity is a common design requirement that appears in most projects and many project managers are spending huge amount of effort, time and money trying to meet this requirement. But are all these effort, time and money spent justifiable for the gain achieved with a ‘simple design’? Are we overdoing it? What should be the baseline? I have seen people splurging thousands of dollars just to simplify a process in a system that is only used by one user (the administrator) once or twice a year. My advice to all project managers is – do not get trapped and follow the ‘KISS’ design principle blindly. Do your due diligence evaluation and ROI assessment on whether a design should be further simplified and know when and where to stop.

Before we wrap this up, let's take a look at the picture above. It summarizes all that I have talked about in one simple picture. Are you able to get it?

Turn on your volume and watch the clip below in full screen (wait for the download to finish before you start to watch). Make sure you follow the instructions given in the clip for best result.

If you have paid attention to the clip above, you probably will be surprised by how the effect has taken place. This is one of those experiments conducted by Daniel J. Simons to study a psychological phenomenon that he called 'Change Blindness'. According to the findings in his research, most people are unlikely to notice the changes in the environment if the changes are small and gradual or the person is focused on doing something else. The research was initially used to study how people could have missed crucial environmental changes resulting in car accidents (click here to watch the clip on Change Blindness).

How can we apply this in project management? It is very common for us to manage change and the expectation of change in projects. Changes that we usually encounter include process change, system change, people change and sometimes, even lifestyle change. One of the many aspects in change management is to manage the expectation and mitigate the impact of change on the people. The direct approach that is widely adopted usually involves investing more time and money for better training and communication. Unfortunately, this approach only helps to ease out the transition part of the change; it doesn't make the change oblivious (or transparent) to the people. Ideally, people that are subjected to the change shouldn't even notice that there is a change in the first place. Over communicating the change will have an adverse effect of propagandizing the change to the people (this should be done more prudently). Alternatively, we may borrow some ideas from Daniel's research that shows how change could be introduced without people significantly noticing it. First, we may consider introducing change in smaller steps, one at a time gradually so that people will not be aware of, and therefore not significantly affected by, the change happening around them. Another more unusual approach is to keep people busy working on something else while the change is taking place. This shifting of focus technique gives people a false perception that the change is indirect and therefore, has minimal impact on them. For example, in an office relocation project, instead of directly telling people to prepare for the shift, you may organize a competition for them to compete to be the first to finish the relocation preparation. By shifting the focus from a mundane preparation task to an exciting competition, you have actually implemented the change in a fun and innovative way. Does change management need to be daunting and tiring after all?

The prisoner's dilemma is a fundamental conundrum in game theory that demonstrates why two people might not cooperate even if it is in both their best interests to do so. In its 'classical' form, the prisoner's dilemma is presented as follows:

Two suspects are arrested by the police. The police have insufficient evidence for a conviction, and, having separated the prisoners, visit each of them to offer the same deal. If one testifies for the prosecution against the other (defects) and the other remains silent (cooperates), the defector goes free and the silent accomplice receives the full 10-year sentence. If both remain silent, both prisoners are sentenced to only six months in jail for a minor charge. If each betrays the other, each receives a five-year sentence. Each prisoner must choose to betray the other or to remain silent. Each one is assured that the other would not know about the betrayal before the end of the investigation. How should the prisoners act? (Source: Wikipedia).

This classic problem happens in project management as well. Imagine a project team gathered around to brainstorm on the requirements of a high profile project. Since this project has huge impact on many people and is highly visible, everyone wants to have a bigger stake on it. Each team member then has an option of either takes the lead and drives the discussion, or focuses on contributing individual requirements and ideas. There are three possible outcomes based on this.

If you were one of the team members, what would you do? According to the prisoner's dilemma assumption, most people will opt for taking the lead which results in sub-optimal outcomes (either 1 or 2 above). In fact, this is often the case in real life situations. However, if everyone can cooperate well in a collaborative manner, the outcome will be most optimal that benefits everyone. Unfortunately, this requires a tremendous level of trust within the team before it can happen. In other words, each member must trust that the others will act unselfishly focusing on getting the job done before he or she will do the same. In order to achieve this, the project manager needs to pay high attention on issues like team dynamics and conflict of interest among the team members. This is a difficult, but not impossible, task that really tests out the skills of the most veteran project manager.