Quite some time ago I published an article titled “The Dangers of Being a Good Project Manager” where I discussed some of the shortcomings of being an efficient project manager, namely that some people tend to think of a well-managed project to be easy and a poorly run endeavor to be complicated.

A friend and a project management colleague of mine recently shared this hilarious and yet deeply disturbing story of his home renovation project with me.

Bob (let us call him that) and his wife buy a new house that is in need of significant upgrades. Here are the parameters of the project:

• Scope:
  • Install New hardwood floors (includes the removal of old carpet)
  • New stairs Including removal of the old ones)
  • Repaint kitchen cabinets including installation of new door handles
  • Repaint 3 rooms
• Budget
  • $10,000
• Timeline
  • The most interesting constraint on this project – only 5 days. The problem was that the current owner could only move out on the 25^th of the month, while Bob and his family had to vacate their rental on the 31^st.

Considering the extremely tight deadline, Bob – as a true project manager - realizes that the key to success on this project is planning. So, three months before the date he starts to visit hardware store, talk to specialists and bring home numerous samples of paint, varnish, hardwood etc. The following conversation occurs on more than one occasion at Bob’s household:

Bob: Hey, Nicole, take a look at these eight samples of the hardwood flooring. Which one do you think will accentuate our furniture?

Nicole: Oh, for the love of God, Bob! The move is three months away! Three months! Why do we have to spend our Friday evening looking at those samples? We will figure it out a week or so before the move.

While project management has been almost fully embraced by the private sector in most of the developed (and certain parts of the developing) world, the government sector still remains a curious wonderland where large projects get initiated and "executed" without any professional involvement of project managers. And yes, I am omitting words like "planned", "monitored" and "controlled" on purpose!

I remember one interesting conversation that took place with an employee of a large government agency, whose management continued to claim that "project management was a waste of time" and that "in any case, we outsource the entire project to a construction company, so why should we bother?"

Me: So tell me, how do you run projects here?

E: Well, at some point of time someone up there (points to the ceiling) decides to build a new port facility ...

Me: And then?

E: The Steering Committee obtains the money based on some very arbitrary estimate and announces to all our departments that the project will be starting on January 1. The Real Estate department is the first on the scene since they have to acquire the land for the future development. They take care of that and pass the files to the Legal department ...

Me: And what happens then?

E: The head of the Legal department is very surprised to see these documents, but the representative of the Real Estate team exclaims, "Remember we had a discussion about this project a couple of months ago? Well, here you go! My job here is done". The head of the Legal team suddenly remembers the now-vague conversation that took place at the Steering Committee meeting, curses and assigns the case to one of his overworked lawyers.

Me: OK, but that is not the end of the story ...

E: Oh no, you ain't heard nothing yet! Begrudgingly the Legal team prepares all of the documents required and one day surprises the next victim - the Planning department. Keep in mind that by that time the historical Steering Committee meeting is three or four months behind us. So, the Planning department has already lost any recollection about that project.

Me: And how do they react to this?

Several months ago I published an article titled "Why Do Clients Prefer to Live in Denial?" that described a particular project situation yours truly found himself in certain number of years ago. Today I just wanted to revisit this case study from a slightly different perspective: rather than concentrating on what went wrong in that particular scenario, I would like to focus on the possible remedial action that could have been taken. At the end of the article I am going to provide you with several potential answers to my question and ask you to propose the best possible course of action.

So, without further ado here is the situation:

• You are a CEO of a smaller company A that signed a major deal with larger retail company B to supply them with a new trading platform
• The technical sales team assessed the situation at company B and came up with an approximate estimate of US1.5 million for the entire project
• The management of company B dismissed the estimate produced by the sales team and forced company A to accept a US$750,000 target
• Since your organization (company A) has been experiencing certain financial issues at the time, you yielded to that demand, but added an article to the contract stating that:
  • Since the budget is smaller than expected, company B will assign a team of their employees to work full time on the deployment of the system together with a team of specialists from your organization
  • Once the money (i.e. the $750K) runs out, company B will accept all the responsibilities remaining for fine-tuning the platform

Several months later once the project manager received a complete and accurate requirements document, he was able to produce a schedule and the resource requirements estimate. The final, detailed estimate turned out to be:

I frequently find myself in the situations where I have to explain the complexity of software development in particular and of technology projects in general to the people that are in way, shape or form related to the IT field. The dialogue below is, in my humble opinion, the best and the most entertaining explanation I have encountered so far:

The marketing guy: (snidely) So, what is so complex about IT projects?

The programmer: Well, imagine that you are writing a script for the movie "Jurassic Park 8" ...

MG: And?

P: You have to describe the following scene: "A very angry T-rex is running across a field on a rainy day ..." So, you start your script with the words "It is raining" ...

MG: (even more snidely) And what is so challenging about that?

P: Suddenly you get a message from your computer telling you that your T-rex is dead!

MG: Why would he die?

P: Well, you start investigating and discover the following: A scientist who was studying pterodactyls close by, lost his balance on a slippery rock (it was raining, remember?), his rifle fell on the ground and discharged a shot. It turns out that the bullet ricocheted off the nearby tree and hit the T-rex right in the head.

M: Oh! And what are we supposed to do?

P: We can load the scientist's rifle with blanks, but that could endanger his life ... We could get him a new pair of shoes, but that would be too costly ...

M: So, what did you decide to do?

P: We decided to remove the tree to eliminate the ricochet factor

M: And??

P: Unfortunately we got the message that T-rex's main enemy, the Indominus‍ Rex died in the next scene!

M: But why would he die?

P: Apparently he tried to lean on the non-existing tree!

And what tricks do you use to explain the unseen complexity of IT projects?

I want to share with you today a very interesting conversation that took  place more than 10 years ago when I was working for an international bank. At the time I was sitting side-by-side with another more junior project manager (let us call him Bob for the purposes of this story). Bob was a great guy and a very knowledgeable professional. Having said that he also was a product of a "command-style" management system and could easily yield to the requests like,

"There is really no point in wasting time on requirements document. I have sent you an e-mail outlining the high-level features of the projects. The technical guys should figure out the rest!"

Needless to say, he was in trouble. A lot. Missed deadlines, rework, angry stakeholders ... As a result he rarely was capable of handling more than two projects at once and could at all times be seen around the office with a very pained expression on his face.

One day when Bob was away, probably being yelled at in yet another one of the status update meetings, my boss - the director of our department - approached our cubicle.

D: Jamal, I wanted to talk to you about certain issues.

Me: OK, what is on your mind?

D: I can't say I am happy with your performance. You show up to work at 9 and leave at 5 ... This is not how our organization works ... Just look at Bob. He is here at 7 am every morning and rarely leaves the office before 8 pm. I have seen him coming to work on Saturdays, Sundays and even stat holidays! Why can't you be more like him?

Me: John, how many projects am I currently managing?

D: (counting on his fingers) Seven. Why do you ask?

Me: And how many of them are on-time and on-budget?

D: All of them! But that is not the point ...

Me: (interrupting) How many projects is Bob handling?

D: Two ...

Me: (snidely) And how many of them are in good shape?

D: (finally realizing where I am going) None! but that is not the point! You see, your projects are easy and his are difficult!

Me: (violently banging my head against the cubicle wall) John, you really think that his readiness to go into the testing phase WITHOUT finalized requirements specifications has nothing to do with the "difficulty" of his projects?

In addition to the organizational benefits There are several “hidden” advantages of investing their personal time in project post-mortems for project managers too. But before we try to discuss these benefits let’s try to picture the typical year of an average project manager.

Typical project manager handles five to ten or, maybe even more projects in any given year. One can argue that by the end of the year – a time of performance reviews - you have probably forgotten all the specifics of the projects you have done in the first two quarters. This unfortunately, can lead to nasty surprises during the review with your manager. Here is a very interesting dialogue that happened between one of my corporate students who was a big believer in writing and saving all of his “Lessons Learned” documents and his manager during an annual performance review:

Manager: “I have given you a below average rating because two of the projects you were assigned to were late and over budget.”

PM: “Actually I had a chance to review ‘Lessons Learned’ from these projects and it looks like Project ABC budget has been revised due to 10 change requests submitted closer to the end of the Execution stage. These changes have inflated the project budget from $200,000 to $275,000.”

Manager: “And what about Project XYZ? It was late as far as I can remember…”

PM: “Yes it was. But I have had three developers taken off my team and assigned to higher-priority projects. Again, deadlines were revised and approved by management and stakeholders.”

Thus, “Lessons Learned” is a great tool that can be used to protect project managers from arbitrary judgments of their bosses.

In addition the document can be utilized in all potential future negotiations on similar projects. For example, if the estimate of say, $100,000 for the budget and six months for duration was once imposed on the project team and the actual cost of the project was $150,000 and duration was close to 12 months, the project manager can use this historic data as a serious argument in negotiations with customers and management. Her line of reasoning may sound something like that:

A couple of years ago I was commissioned by a product company to run a crucial project of theirs, the delivery of the next version of their flagship product. The project has been hindered by problems from the very inception: too much scope to deliver ("customers demand ALL of these features!), not enough time ("we absolutely MUST deliver this by the start of the Christmas season!") and lack of resources ("you need HOW many people?!").

I started this endeavor by sitting together with the product managers and a couple of senior architects in order to prioritize the features and to determine the proverbial "low hanging fruits" that were of utmost importance but could be delivered relatively easy. At the end of the day we were able to cut or postpone some of the "nice to have" but cumbersome scope items. However we still only had a 50% chance of hitting the required deadline. So, I gathered my documents and walked into the office of the CEO ...

Me: Listen, our chances of finishing project on-time are still pretty slim. We are hovering somewhere around 30% probability of hitting the deadline. We need to look for some additional degrees of freedom ...

CEO: And what are you proposing?

Me: Well, we went through the list of potential options to obtain additional degrees of freedom: adding more people, replacing inexperienced experts with the experienced ones, cutting some additional scope, etc., but received an unequivocal "no" to each one of our requests ...

CEO: Well, I guess you guys will just have to roll up your sleeves and work harder!

Me: Actually, there is another option that can give us some wiggle room. You know how we conduct company-wide meetings every Tuesday? (Note: The company had a long-standing tradition of running "all hands on deck" meetings on a weekly base. The gatherings lasted for 2-2.5 hours each time and largely consisted of  employees passing on teddy bears as prizes and thanking each other for being especially helpful last week. The management was convinced that such gatherings improved communications and employee morale, thus treating these events as sacred cows.)

CEO: Yes ...

Me: Would you mind exempting my team from these meetings? We think it can free up ...

Introduction

In my consulting and training practice whenever I get to talk to project managers, both experienced and new, the question of whether it pays off to be honest when interacting with your clients always comes up. I usually say that it is much easier to weather the storm at the beginning of the project than to suffer the death of the thousand cuts through the entire duration of the venture.

However, one time an experienced project manager approached me after the session and, with a "wink wink, nudge nudge" look on his face, said the following:

"Oh, c'mon, man like you never lied to your customer in order to get the project off the ground! You know perfectly well, once they get a little bit pregnant, there is no way back for them!"

Once I got over the painful image of "getting my customers slightly pregnant", I remembered the following dialogue I had with my former boss, the director of the IT department at a global bank.

The Story

Director: Hey, I am going to assign you to this new regulatory project. Keep in mind, this is a high-profile endeavour; our main client is the Senior VP of our company. By the way, you should not, he is a very difficult individual. As a matter of fact his nickname in our department is "El Diablo"!

PM: Yes, I have heard about this project. I have spoken to some of our technical people and they have estimated the project to take about nine months ...

Director: Yup, that is another problem. I have personally promised that we would deliver the product in three months

PM: “What?! Three months? But now that he finds out the truth he will be mad!”

Director: “Don’t worry about that. I have a plan. We will proceed by breaking the news to him gradually!”

Foreword

Throughout my career I have always tried to build a relationship based on trust with my clients. I always made sure that the time and budget estimates were based on cold reality rather than some enigmatic expectations of the customer. I did this not only because of PMI Code of Ethics and Professional Conduct  but also because in my humble opinion, it is much easier to weather the storm at the very beginning of the venture, than to agree to everything your customer wants at inception and turn your life into a living hell for the rest of the project.

As a result whenever a client came to me asking for something like this (see if you can recognize some of your clients!):

"I want a customized Ferrari delivered to me tomorrow for $500"

I always replied:

"Sorry, but with that kind of timeline and budget, the best I can do is a bicycle and here is why ..."

Usually if what followed after "why" was fairly reasonable and convincing, about 90% of the stakeholders agreed with me and we proceeded to work on the project at hand in a friendly and collaborative manner.

Having said that, today I want to share with you story that falls into the other 10% ...

Introduction

Imagine the following situation: