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"?