PMO Bytes

Singaporeans had been through an unforgettable week with their hearts going through an emotional roller coaster ride on the events of the Singapore General Election 2011 that ended on 7^th May. While my mind was still trying to recover from the aftershock of the election results, one particular rally speech given by candidate Denise Phua from People's Action Party (PAP) had struck me so hard that I have been pondering on those words that she said since then.

Denise said: “The easiest thing to do in this world - is to criticize somebody else and find something that is wrong in a person, in a situation. The hardest thing to do and a more respectable thing to do - is to take action, to do the job no matter how small or unglamorous it is and to make a difference.” (You may view this part of her speech in this clip from 9 min onwards).

I couldn’t agree more. Indeed, it is easy for us to find faults and criticize. How many people out there really have the might and mettle to stand up and take ownership of the problem? Most of us just keep whining without taking any constructive action. On the other hand, the elites of the PAP-dominated government in Singapore have been badly lambasted for being too arrogant, stubborn and unwilling to listen to the people. Sometimes, when people have stayed too long in the same place, they tend to get too deeply entrenched to the spot and have forgotten to look around for alternatives beyond the immediate boundary. They have become dogmatic and stopped listening to criticism.

I will call the first type of people the Whiners and the second type the Dogmatists. We see these two types of people around in all projects. They disguise themselves as the stakeholders and they hide themselves in the project team, they are everywhere. Some of them watch over you like hawks. You feel scrutinized. The moment you make a mistake, they will pounce on you like a pack of wolves without hesitation. Then there are others that make you feel like an idiot talking to lunatics. They never seem to be able to understand what you say and they just want you to get out of their way. Sad to say, you probably find yourself turning into one of them unintentionally. In my previous blog post, I have talked about how Putt’s Law pokes fun at the satirical gap between managers and techies in the technology domain. I have attempted to extend this law with a twist to include what we have just discussed.

Putt’s Law 2.0: “Project management is largely dominated by two types of assholes: those who do what they do not criticize and those who criticize what they do not do.”

What should we do to overcome this?

The book “The No Asshole Rule” written by Robert Sutton will probably give you some tips on this topic. You may also want to take a quick look at an interesting review of this book by Guy Kawasaki at his blog.

The popular Putt’s Law states,

“Technology is dominated by two types of people:  those who understand what they do not manage and those who manage what they do not understand.”

I came across Putt’s Law many years ago and was intrigued by the candidness and satirical reality pointed out by this law ever since. Even after so many years, I find the veracity of this statement still holds. In fact, it does not only apply to technology; it applies to project management as well. As a project manager, we have to deal with these two types of people in the project team and stakeholder group quite frequently. I am sure you must have met a couple of them in one occasion or another. Ironically, sometimes we are guilty of playing one of the two roles ourselves. This is inevitable. We know well that most project managers fall into the category of “Jack of all trades, master of none”. It is true that we can’t write codes better than our average programmers and we are not as experienced and knowledgeable as our subject matter experts (SME). Yet, we are bestowed upon the sacred role to manage them. The challenge is then for us to find some ways to close the gap between the managers and techies. Below are a few tips to help you achieve this.

Avoid Jargons: Avoid technical jargons in all the documentations and presentation materials. Try to ensure everyone speaks in layman’s terms in all meetings and discussions so that even your granny is able to understand. Watch out for techies who like to flaunt technical jargons around to show off their knowledge. Your duty is to put them under control.

Enforce Clarity: Whenever there is a direction passed down from the top, make sure that the instructions given are clear and specific. Avoid ambiguity at all costs. Sometimes, what appears to be resistance is often a lack of clarity in direction. Confusion arises when people below do not understand why and what people are doing at the top. Take time to explain the objectives clearly to ensure everyone follows both physically and mentally.

Improve Communication: Communication is a crucial part in project management. Identify your audience and determine what to communicate. Select the mode (e.g. email, newsletter, or meeting etc.) of communication that will give you the best results and remember to pick the right frequency. Put all these into a proper communication plan and share it out with everyone. Poor communication often leads to confusion in the team. Rectify it before it burns the bridge between the managers and techies.

Promote Openness: Adopt an open concept in the team to encourage people to ask question whenever they are in doubt or even challenge the status quo if necessary. Very often, people are just too shy to ask question for obvious reason that they are afraid to expose their ignorance. Ego breeds ignorance. Cultivate a positive environment to promote open communication in the team.

Provide Training: Whenever a project needs to involve some technical discussions that are unavoidable, it is always a good practice to provide basic training to prep the team with the knowledge required. This can be done as a separate session prior to the discussion or as a short briefing before the discussion starts. Keep the training simple and understandable without diving too deep into unnecessary technical complexities. Use more diagrams and examples instead of words to illustrate the technical concepts.

Silence filled the air. Total darkness. The curtain was drawn slowly… A beam of light shone onto you and all of a sudden, you became the focus of the night. You waved your baton nonchalantly and the sound of flutes permeated the hall. With a few more clicks of the wrist, the violins followed. You were the Maestro, the conductor of the night.

No, you were also the project manager of a multimillion-dollar project. The musicians in front of you were the members in the project team each with a specific role to play. The musical instruments in their hands were the tools required to accomplish the goals in the project. You shuddered a little initially as you remembered that was the first time you were working with the ensemble, your project team. You have worked with different ensembles – chamber, sinfonietta, symphony etc. in your career hopping from one performance (project) to another. Occasionally, you also need to work with smaller ensembles like duo, trio, quartet, quintet, sextet, septet and octet etc. But in those performances, you played the role of musician instead. You are a veteran. That night was no difference from any other nights. You regained your poise immediately as you know you mustn’t let your audience (stakeholder) down.

Your eyes were fixated on the score – your project plan, too afraid to miss out any important ictus. You have conducted scores of various musical forms – overture, impromptu, intermezzo, concerto, rhapsody, serenade, sonata and symphony etc. The musical form shapes the score just like the way the methodology characterizes your project plan. As you were struggling to keep your ensemble in consonance, you recalled how badly you had stumbled to keep your project team in pace with the project plan. You knew that any slight mistake would be fatal, both for the performance and your project. Your audience were watching, albeit some were sleeping while a couple of others were trying to appreciate what was being played on stage. Yet, you knew they were watching. Your duties as a conductor are to unify performers, set the tempo, execute clear preparations and beats, and to listen critically and shape the sound of the ensemble. As a professional project manager, you need to ensure your team delivers the project in time, within scope and budget, and with quality that meets the expectation of the stakeholders.

Despite there is a host of similarities between conducting musicals and managing projects, their success rates are at extreme ends. What is missing here? Is there anything we can learn from conducting to improve the likelihood of success in managing projects? One obvious difference observed is that a musical performance usually gets a lot more rehearsed before going live. Can we trial run a project plan? If we can, how should we do it?

When I was young, I used to be fascinated by the sound of bouncing ball. The rhythm created by the sheer kinetic-to-sound energy exchange was so untainted and gripping that it sometimes resonated with my heartbeat. Now, inspired by the old classic game Arkanoid and Breakout, I finally have a chance to recreate this spectacular experience by bouncing balls off the walls formed with the word “PMO”. Turn on your volume and enjoy the clip above.

Jumping the shark is a widely used idiom – to describe a moment in the evolution of a television show, characterized by absurdity, when a particular show abandons its core premises and begins a decline in quality that is beyond recovery. A few good examples of these in the history of American television serial drama include the famous Prison Break, Heroes and Lost. In retrospect, these dramas should have stopped after the initial successes instead of dragging on to more seasons where we witnessed sharp dip in viewership. In project management, sometimes we do come across projects that turned bad, with long delays, evading quality and forever changing targets. Such projects will eventually eat up the organization’s coffer. The key question is – “When should we drop a project that turned bad?”. It is like buying and holding on to a share with plummeting share price – it is always a tough decision to make on the ‘right time’ to let it go. I have seen many project managers and steering committees holding too long on failing projects resulting in unrecoverable monetary losses, exhausted team, frustration and undesirable impacts and delays to other projects.

There are various reasons why people like to hold on to failing projects relentlessly. It could be ego – “Failure is not a word in my dictionary”. It could also be due to job security – “This project can’t fail, else I will lose my job”. Sometimes, it could be just tenacity that pushes the envelope – “Be like a postage stamp. Stick to one thing until you get there”, said Josh Billings. Whatever the reason is, we still need to decide whether we should fix or kill the project. Below are a few points to take note when you are considering whether to drop a failing project.

Strategic alignment: Business strategy changes every now and then. When a project is dragged ad infinitum, it is wise to check back if the objectives of the project are still aligned with the business strategies. We need to review the business strategies and reprioritize the problematic project with other projects in the portfolio to decide if it is still worth to continue with the project.

Return on investment (ROI): Even if the project’s objectives are in alignment with the business strategies, we still need to estimate the amount of effort and money that we have already thrown into the project and those that we have to invest further in order to bring it back to life. We need to ensure the overall amount of money, we have spent and yet to spend, is well justified over the benefits that we are going to get in return. Watch out for your ROI in both short and long term plans.

Capability and capacity: Assuming that the problematic project meets the ROI and strategic alignment, we still need to assess whether the resources we have in the current project team or organization have the required knowledge and capability to complete the job. Even if we have the capability, we also need to consider if we have the capacity to do it and whether it will have any drastic impact on other projects in term of resource contention. The bottom line is we need to be realistic and know our limits.

What other points you would consider when deciding to kill or not to kill a failing project?

Sometimes we have to be honest with ourselves and have the courage to admit that the project is beyond the value of fixing, at least not without burning out another pile of cash that exceeds the equivalent business benefits. Do not take it too personal to drop a bad project. There is nothing too wrong to let go if we have done our due diligence of assessment. Most important thing is we have to learn from our mistakes and move on.