PMO Bytes

• Even if you have been told, you failed to listen;
• Even if you have listened, you failed to understand;
• Even if you have understood, you failed to take action;
• Even if you have taken action, you failed to do it right;
• Even if you have done it right, you failed to deliver;
• Even if you have delivered, you failed to meet the expectation.

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 –

• Even if you have done everything you could, you failed to get the authority you need to get the job done.

I like the way King George was introduced to Jack Sparrow in the movie Pirates of the Caribbean 4. He was introduced as ‘George Augustus, Duke of Brunswick-Luneburg, Archtreasurer and Prince-elector of the Holy Roman Empire, King of Great Britain and Ireland’. Wow, what a lengthy title and definitely one that is not easy to remember.

While I was counting the number of characters in the title, I recalled a question that a colleague of mine asked some time ago – ‘Is the length of a person’s title related to the importance of the work he is doing?’ In my opinion, the straightforward answer is ‘No’. But if this is indeed the answer, then what could have possibly motivated people to create long and fanciful titles which are hard to remember? The closest explanation probably lies in a three-letter word – ‘ego’.

There is an ego elephant in every one of us.

They vary in size. Some of them are much larger than the others. Most of the time, they are innocuous and stay dormant just like any other elephants. But the truth is, they lurk in the dark, waiting for the right moment, the provocative words or the insidious remarks, to spring into action; and when that happens, nothing can stop them, not even you. They march on, seizing over the control while leaving you paralyzed under their feet. You look so vulnerable in the stampede. And yes, this is nothing new to you. It has happened so many times in the past despite your silent protests. 

You bring them with you wherever you go; to the weekly project interrogation party or your favorite postmortem debate. In most of these internecine dogfights, it seems like the person with the largest ego elephant usually wins. Not that they are strong, but they are just too stubborn to admit that they are wrong. In order to reward them for their hard-fought victories, you feed them with flatteries, something that accelerates their growth. As they grow bigger and stronger, they start to obscure your vision and block your thought, which in turn makes them harder to be controlled. This is a vicious cycle. In no time, they will grow so big that you will have to take them out and hang them on your nose.

How can you manage ego elephants?

1. Chain them up: The first thing you have to do is to cut the damage. Chain them up immediately to stop them from running loose. Do not give them a chance to take over the control. You ought to be able to detect the moment when they are about to spring into action. What you need are cues from micro-expressions, subtle body language and verbal tone to give you the hint to take back the control before all hell breaks loose. If you find yourself with the following symptoms, watch out!
   • Feel insulted when others disagree with you.
   • Keep saying things like “You’re wrong”, “You don’t get it”, and “I’m VERY sure” etc.
   • You disagree for the sake of disagreeing.
   • Keep talking but have stopped listening.
   • Behave irrationally and find all sorts of excuses to win an argument.
   • Hardly compliment but never miss a chance to criticize.
   • Pant heavily with a red face during a conversation.
   • Get impatient easily and believe that people around you are idiots.
2. Stop feeding them: Flattery is the main staple food for ego elephants. It provides the basic nutrients that help the elephants to grow. Cutting yourself off from all sorts of flatteries will help to curb the growth of ego elephants. But before you can even do that, you need to know how to differentiate flatteries from sincere remarks. Below are some good advices, suggested by Niccolò Machiavelli in chapter 23 of his work “The Prince”, which may help you to keep flatteries at bay.
   • Create an environment that encourages people to tell the truth.
   • Constantly seek for advices from the team.
   • Only listen and take the advices seriously from the trusted few.
   • Do not accept all advices blindly. Take only those that are needed.
   • Be skeptical and constantly questioning and probing what others say.
3. Tame them: Being humble is the best approach to tame the ego elephants. It is the ultimate and more sustainable way to put them under control. In fact, according to Jim Collins, humility is an essential trait that great leaders (whom he referred to as level-5 leaders) should have. Do not mistake humility with meekness and cowardice. It actually takes a lot of courage to be humble. As C. S. Lewis once said – “Humility is not thinking less of yourself, but rather thinking of yourself less.” Leaders that have big ego elephants usually put themselves on top of everyone else. However, leadership is never about you; it’s always about the others. Below are a few suggestions on practicing humility extracted from an article in Mind Tools.
   • There are times when swallowing one's pride is particularly difficult and any intentions of humility fly out the window, as we get engaged in a contest of perfection, each side seeking to look good. If you find yourself in such no-win situations, consider developing some strategies to ensure that the circumstances don't lead you to lose your grace. Try this sometimes: just stop talking and allow the other person to be in the limelight. There is something very liberating in this strategy.
   • Here are three magical words that will produce more peace of mind than a week at an expensive retreat: "You are right."
   • Catch yourself if you benignly slip into over preaching or coaching without permission – is zeal to impose your point of view overtaking discretion? Is your correction of others reflective of your own needs?
   • Seek others' input on how you are showing up in your leadership path. Ask: "How am I doing?" It takes humility to ask such a question. And even more humility to consider the answer.
   • Encourage the practice of humility in your company through your own example: every time you share credit for successes with others, you reinforce the ethos for your constituents. Consider mentoring or coaching emerging leaders on this key attribute of leadership.

You do not measure leadership by the number of medals that hang in front of your chest (that’s ego); you measure leadership by the impact you have on the people that follow behind you.

I have a customer who shared with me an ‘unexpected’ and unforgettable experience that he had that almost ruined his career. A few years back, he engaged a vendor to develop a web application that was meant to be used by internal employees. Everything went fine and they had gone through the UAT smoothly. The shocking news came in on the eve of the go-live day that the key engineer working on the project had met with an accident and was unavailable to work on the migration for the application from staging to production server. Eventually, the go-live date had to be pushed back a month to allow the vendor to find a replacement and conduct essential knowledge transfer. My poor customer had to write a long report to explain this ‘unexpected’ hiccup to his management.

I believe most of you have been through similar ‘unexpected’ situations that caught you totally off-guard. You might have anticipated, predicted and planned for whatever you and your team can think of and yet, you would still miss out one or two critical items that pounced back on you when you turned the corner. We deal with two types of risk in projects, the known and the unknown risks. What I have been talking about so far are the unknown ones which usually jump up and haunt us in our most unprepared circumstances.

In his book “The Black Swan”, Nassim Nicholas Taleb characterized a specific type of events that resemble what I have mentioned above. According to Taleb, a Black Swan is a metaphor that represents an extremely high impact, retrospectively predictable, and rare (outlier) event that is beyond the realm of normal expectations. In general, most people expect all swans to be white based on past experience. Therefore, the appearance of black swans is a surprise to many people. However, we tend to concoct explanations for them after the fact, which makes them appear more predictable, and less random, than they actually are. But in reality, black swans are not predictable and they are not necessary all negative. Below are some examples of black swans that have great impact in history –

• World War I 1914
• Wall Street Crash 1929
• World War II 1939
• Oil Crisis 1973
• Black Monday 1987
• 9/11 Terrorist Attack 2001
• Indian Ocean Tsunami 2004
• Stock Market Crash 2008
• Japan Nuclear Crisis 2011

Can you imagine one of those black swans above paying you a visit in your project? You would probably dismiss this thought with a sneer as you are confident that it is highly improbable for the black swans to occur. The problem with us is we put too much emphasis on things we already know and give very little attention to things we don't know. In some cases, we even overestimated ourselves by thinking that we know something that we actually don’t, thereby creating a false sense of reality. This is obviously a key weakness in managing project risks which explains why the black swans always manage to catch us unprepared. Below are some tips that may help you to survive through the black swan events:

1. Be Humble: The first thing is to acknowledge that you are not omniscient. Avoid relying too much on past experience and do not try to predict black swans. Example, never reuse an old risk register for your new projects and assume that all the risks are the same.
2. Stay Skeptical: Do not take facts at face value. Remember that absence of proof is not proof of absence. Be curious and stay skeptical by challenging the norms. Example, form a risk council in the project team to play devil’s advocate to scrutinize and challenge all decisions made in the project.
3. Improve Immunity: Identify areas of vulnerability earlier and reinforce them. Prepare yourself and your team earlier for both positive and negative black swans so that when they come, you are ready to handle them. Example, never just monitor the risks in your risk register. Work on and mitigate the risks with the aim of getting them out of the risk register eventually.
4. Remain Transparent: Do not sweep your dirty laundry under the rug. The more and the longer you try to hide, the messier it will be when it is exposed eventually. Exposing it earlier will help to minimize the impact and buy you more time to deal with it. Example, publish your risk register and welcome others to comment (or even criticize) it openly.
5. Expand Options: Avoid dependency on single source of supply by providing more flexibility and agility in your projects. Example, always work with multiple vendors to avoid being held hostage by a single dominant vendor.

In short, the key to tame the black swans is not to try to predict them, but to build robustness into your projects and prepare your team to expect the unexpected. As Taleb has nicely explained – “It's like saying a bridge is fragile. I can't predict which truck is going to break it, so I have to look at it more in a structural form and reinforce its weak points.”

Warning: The following content may sound crude and rude and contains offensive words that are not for the faint of heart. Do accept my apology if you feel offended.

In the early days of my career, I once heard an elder colleague of mine jokingly lamenting about his bleak future of being a developer. This was what he said,

“Developers are like whores. The older you get the less market value you have. In order to get out of this lowest rung in the industry, you need to study the pimp book (PMBOK) by hard and get yourself certified as a pimp (PMP) so that you can, in turn, manage the whores.”

Laugh as you may, but this was the common mindset that the majority of developers had back in the early 2000s. It might not be the same in other parts of the world, but at least in the place where I belong, this was the case. I am not sure what could be the real reason, but the post Y2K impact, dot-com bubble burst and strong outsourcing and offshoring of IT jobs to India during that period could have contributed and propelled the manifestation of such sentiment in developers in those days.

Whatever reason it might be, it was disheartening and discouraging for a young and aspiring developer like me at the moment when my career was just taking off. It got me wondering – Is project management the inevitable path and springboard for developers to move up the career ladder? If not, what are the alternate paths available for developers? Actually, there are quite a number of alternate roles like chief architect, IT manager, business solution manager and consultant etc. that developers may work towards. In fact, the options are plenty. The important point is not so much on what are available out there, but what you have in you that make a difference. Aristotle once said – “We are what we repeatedly do. Excellence, then, is not an act, but a habit”. As an individual, we have to keep challenging ourselves on what we can contribute and what impact we can make, which in turn justifies our value to the organization. In fact, in his top-selling book “The World Is Flat” (published around the same period), Thomas Friedman actually encouraged fellow American workers to keep upgrading their skills and focus on creating value through leadership and creativity in order to stay competitive and adapt to the challenges in the new economy. Always remember, there are many paths to fame but the choice is yours.

What have you been doing to help yourself rise up to the ‘whore of fame’?

We fill up forms every now and then. We have forms for new project requests, account creation, change requests, leave applications, and even forms for purchasing toilet paper. Have you ever wondered how much time you have spent in your life filling up forms? A research shows that form-filling costs UK business £104 billion a year with average UK worker spending 37 days in year 2010 carrying out administrative tasks. Ridiculous! Wake up, bureaucrats.

I was invited to a meeting to discuss a new change request process. Half way through the meeting, a colleague of mine raised a comment that the existing change request form is too complicated and takes a lot of time to fill in. When being asked if all those fields in the form are indeed necessary, the host of the meeting replied – “Yes, they are mandatory”. Why do we need so many mandatory fields in a form? After a few more rounds of investigative questioning, we found out that Microsoft Excel was the culprit. It happened that someone at the top wanted a report on the volume and status of change requests to be generated out on a monthly basis. Unfortunately, the data need to be categorized before the sleek charts and pivot tables can be plotted in MS Excel. Here we go. This was the reason why those mandatory fields were added – to provide categorization for the data. What a ‘fantastic’ reason? When grilled further on whether those mandatory fields were ever fully utilized to provide meaningful information, the host simply replied that he was not sure as those fields were added by other people many years back. Great! We felt like the children following the pied piper.

Why are we wasting the bulk of our time on things that we hardly use? Should someone regularly review and weed out those unnecessary necessities from the old stale ‘best practices’? I have seen the same phenomenon occurring time and again in projects especially in requirements gathering. How many of you have come across stakeholders who keep demanding for tons of requirements that hardly add any value to the project? Are these unnecessary ‘nice to have’ requirements eroding your budgets and delaying your projects? Are you using any tools like Kano Model or Quality Function Deployment (QFD) to help you categorize and prioritize your project requirements? Do you have a change review board in your project team? If not, what do you do to ensure that the requirements raised by the stakeholders are properly evaluated and validated before investing more time and money on them?

Gathering requirements is not easy, but the task of weeding out the unnecessary necessities is even more challenging.