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:

Introduction

The Kashagan Oil Field has been discovered in 2000 in the Northern part of the Caspian Sea (see Figure 1). It was quickly confirmed that it was the world's largest discovery in the last 30 years, combined with the Tengiz Field located nearby, with a projected output close to that of the Ghawar field in Saudi Arabia. The recoverable oil reserves of the Kashagan Filed were estimated to be at 19-20 billion barrels.

Figure 1

The consortium consisting of several global energy players along with the government of Kazakhstan was formed in order to develop the reserves. The number of players and the make-up of the conglomerate changed several times over project lifecycle (we will come back to this fact at a later time), but as of 2012 the group consisted of the following players:

• Eni (Italy) - 16.81% stake
• KazMunayGas  (Kazakhstan) - 16.81% stake
• Royal Dutch Shell (UK/Netherlands) - 16.81% stake
• Total S.A. (France) - 16.81% stake
• ExxonMobil (USA) - 16.81% stake
• China National Petroleum Corporation (China) - 8.4%
• Inpex (Japan) - 7.56% stake

The Project

The project started in 2001 with an expected completion date of 2005. The allocated budget for this venture was US$10 billion. The oilfield was expected to become operational around 2005 and produce anywhere between 90,000 and 370,000 barrels (at peak production) a day. Needless to say, this project was viewed in Kazakhstan as one of the most important initiatives for the young country and was expected to generate considerable income for the government.

However the project fell 8 years behind the schedule and ended up costing a bit more than the original forecast. Depending on who one chooses to believe, the cost of the venture as of 2015 was either US$50 billion (official number provided by the government of Kazakhstan), US$115 billion (CNN Money's estimate) , or close to US$150 billion (number being mentioned in some publications).

Why Your IT Project May Be Riskier Than You Think

I have recently stumbled across a very interesting article titled "Why Your IT Project May Be Riskier Than You Think" published by Bent Flyvbjerg and Alexander Budzier.

I am a big fan of professor Flyvbjerg and his work and as a result needless to say I read this article with great interest. The article describes the phenomenon called the "black swan projects" or as he puts it "high-impact events that are rare and unpredictable but in retrospect seem not so improbable". In other words, these are the endeavours that are vastly over budget and sometimes so bad, that they kill the companies that conceived them. Some of the examples are:

• Levi Strauss' migration to the SAP system (original budget - $5 million, actual cost - $192 million)
• Hong Kong’s airport's IT system upgrade (losses of $600 million)
• Hershey’s a new order-taking and fulfillment system (losses of $100 million causing an 18.6% drop in quarterly earnings)
• Kmart's IT modernization project (original budget - $1.4 billion, actual cost - $2 billion; led to company's bankruptcy)

Professor Flyvbjerg further states:

"The average overrun was 27%—but that figure  masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average, as management consultants and academic studies have previously suggested. It’s that an unusually large proportion of them incur massive overages - that is, there are a disproportionate number of black swans."

The article proposes the following steps to be taken in order to address this challenge:

There are many different approaches to project prioritization, but the most popular ones are the financial method and the scoring model. In this posting let us examine the financial methodology. In a nutshell it implies choosing some kind of a financial criterion – be it a net present value, internal rate of return or some other formula – and calculating a value for each project. Once the ROI for each project has been calculated, the projects are ranked according to their ROIs in the descending order.

Let us look at an example of how it may happen. We have a company that wants to implement 10 projects and has 200 man-months in their resource pool (roughly speaking 20 people working together for one year including vacation time, and allowances for sick days, etc.)

The list of projects together with their expected ROIs is presented in Table 1:

Table 1

Next, the company needs to estimated the efforts required for each project and rank the projects according to their ROIs (see Table 2):

Table 2

It is clear from Table 2 that the company in question can do projects H, E, A, F, C, I and G assuming their projections regarding the projects’ ROIs and efforts required were correct. Adding Project B to the mix will force the company to exceed their effort threshold.

While the purely financial models are very good at instilling the sense of discipline and accountability they all suffer from a couple of inherent problems. One can argue that every financial formula out there can be presented in the following form:

Financial value = f(Revenues/Costs)

In other words any financial value is positively correlated with the expected cash inflows from the project and negatively correlated with the cost of the project.

One of the prevailing superstitions in project management is the "fixed pie" assumption. In other words, both sides assume that the project results, speaking mathematically, are binary - either the team delivers the project on time or it doesn't; either the project is on budget or over, etc. Fortunately, negotiations are typically not like NBA Finals when team A meets team B in a seven-game series where the winner gets the Larry O'Brien Championship Trophy and the loser goes home empty-handed.

In my experience, situations on most projects are similar to the fable involving two kids quarrelling over the ownership of an orange. Finally, their father enters the room and, operating under the fixed pie assumption, cuts the orange in two equal halves distributing the fruit between the brother and the sister. Interestingly enough, the brother eats the orange and throws away the peel. The sister uses the peel from her half as an ingredient in pastry while disposing of the fruit.

The situations between customers and project teams are often similar to the fable described previously: the underlying interests, constraints and risk tolerances of both parties are rarely identical. The proverbial pie usually looks quite different to each party. Hence, a good project manager can increase the size of the pie by looking for things that are of low cost to him and his team and high value to the customers (and vice versa).

Consider the following interaction between an experienced construction project manager and a customer:

Customer: “I would like to add another clause to our contract. If the work on the new mall is not finished by the deadline in the contract, I want your company to pay a penalty of $5,000,000”

PM: “Hmm, we have already signed the contract without the late penalty clause; I am not sure how our management would react to that …”

Customer: “I am sorry, but I have been instructed by my boss not to proceed ahead without this modification to the contract”

PM: “And may I ask you why you guys feel the need to add this clause?”

As a part of my project and portfolio management consulting practice I frequently get involved in advising various companies on how to run their real-life projects. In my previous article "How Not to Handle Project Negotiations" I shared a discussion that took place between three project stakeholders and invited the readers to find the mistakes that happened in that conversation. Today I am providing my proverbial two cents on the situation at hand ...

Sheila: You know about the problems we had with the release 4.0 of this product. You guys were late by 3 months, went almost 50% over budget and delivered way less features that we expected. Besides even the stuff you did deliver had serious quality issues.

Aha! So the previous similar project has been a failure on all three fronts: late, over budget and delivered less scope than expected. I wonder if optimistic estimation had anything to do with that?

Dan: Yes, and because of all these problems we lost two of our customers and several others warned us not to contact them until we have e-Merchant 5.0 ready with all the necessary features …

And these failures are beginning to have a strategic impact on the company's well-being ...

John: Yes, I understand your concerns and that is why we decided to invest a bit more time in scope definition in order to be able to better estimate project size, risks and duration.

Sounds like a very smart move to me. After all it is impossible to come up with any meaningful estimates until one knows the scope of work.

Dan: How much time are you planning to spend on requirements gathering?

John: We estimated that we would need about four weeks to elicit and document all the requirements and another week to for the team to conduct document inspections and generate estimates.

Again, sounds very reasonable.

As a part of my project and portfolio management consulting practice I frequently get involved in advising various companies on how to run their real-life projects. Several years ago I was requested by a CEO of one organization to sit in a meeting where several stakeholders were supposed to discuss various aspects of the new "do-or-die" project. The ensuing conversation was so hilarious, that I excused myself from the room as soon as I could and recorded the entire exchange before it escaped my mind.

So, my challenge to you: how many estimation/negotiation handling mistakes were you able to spot in the following conversation?

John the project manager at the ABC Software Inc. a producer of e-Commerce software was preparing for a meeting with Dan, a VP of Sales and one of the original founders of the company and Sheila, a Senior Product Director. They were supposed to discuss the next major release of the company’s e-Merchant product.

Sheila: You know about the problems we had with the release 4.0 of this product. You guys were late by 3 months, went almost 50% over budget and delivered way less features that we expected. Besides even the stuff you did deliver had serious quality issues.

Dan: Yes, and because of all these problems we lost two of our customers and several others warned us not to contact them until we have e-Merchant 5.0 ready with all the necessary features …

John: Yes, I understand your concerns and that is why we decided to invest a bit more time in scope definition in order to be able to better estimate project size, risks and duration.

Dan: How much time are you planning to spend on requirements gathering?

Several posts ago I published an article titled "Top 6 Ways Your Vendor Can Screw You On Your Next Project". Today I wanted to follow up on this topic with a list of strategies geared to help a company deal with the tricks and ploys of irresponsible vendors. All of these methodologies have proven themselves in my project management consulting practice, especially on the troubled project recovery assignments.

Strategy #1: Pay More Attention to Your RFP

Spend more time and effort writing your Request For Proposal. The more complicated the project is, the more precise and detailed should your request for proposal be. In which of the cases below do you think the contractor would have less "wiggle room"?

Throughout my consulting and training engagement I frequently came across outrageous statements made by various company executives about both project management and project portfolio management. Today I want to provide you with a collections of all these pearls of wisdom and provide my (at times not very politically correct) answers to them.  

So, without further ado, here we go with top seven dumb statements from executives:

Dumb Thing #1: "I am not sure why we are failing with our projects! After all we have MS Project installed on every desktop in the office"

Having MS Project or any other project management software installed on your computers won't do jacksh*t for you if you don't have proper skills, methodologies and processes implemented at your company. It is like picking up a random person off the street, giving him a Stradivari violin and expecting him to perform at Niccolo Paganini's level of without any training or guidance. Or how about buying a random guy a pair of most expensive soccer boots and the and the most advanced ball and expecting the person to instantaneously become the next Lionel Messi ?

Dumb Thing #2: We have a lot of receptionists sitting around doing nothing. Why don't we put them through a 2-day project management course and we can assign our (multimillion) projects to them? By the way, any chance you can cut the length of your workshop to one day?

No, I can't! And you need to realize that a project manager capable of running a multimillion dollar project is an accomplished professional with years of training, education and progressive experience. Putting a receptionist through a 2-day PM course may open her eyes to discover the exciting world of project management, but will most definitely not prepare her to run complex multimillion dollar projects.