Submitted by Jamal Moustafaev on Tue, 12/22/2015 - 08:52

Introduction

Recently the Canadian media reported that the government of British Columbia has launched a "thoughtful reset" (whatever the heck that means) of its Information Technology projects due to major delays, cost overruns and failure to deliver the scope promised.

According to the Vancouver Sun newspaper:

Of eight high-profile IT projects recently undertaken by government — with a total price tag of $2.5 billion — several have faced serious difficulties and collectively they’ve overshot their budgets by a combined $350 million and counting.
The two large-scale health projects that have faltered are a national infectious disease system that has cost B.C. 420 per cent of the budgeted amount, and a massive computer transformation project in Vancouver Coastal Health that’s beset by firings and delays while still in the design phase.
Panorama, the error-prone infectious disease outbreak software, was budgeted at $27 million in B.C., but cost $113 million. To add insult to injury it was riddled with more than 11,000 defects and errors.

As a result of that, the Deputy Health Minister Stephen Brown, Health Minister Terry Lake, Liberal MLA Ralph Sultan, and an NDP critic Adrian Dix (please, please tag them in this post if you are connected with them!) had asked a whole bunch of very interesting and thoughtful questions (see below) that I intend to answer in my today's article:

Questions and "Oh, So Inconvenient" Answers

Question# 1:

How to get realistic about budgets, timelines and expectations? How do you make sure the aspirations at the beginning are grounded enough you’ve got some assurance you are going to deliver?

Answer #1:

Here are some of the usual suspects you may want to look at:

How did you come up with the original (incorrect) estimates in the first place?
1. Did someone very high in the food chain just say, "Hey we want to implement system X and we only have $Y and Z months? Off you go!"?
2. Did you conduct technical feasibility study (i.e. preliminary assessment of requirements, budget and time)?
3. If you indeed conducted those preliminary studies, was there any pressure applied to the project team along the lines of "depress your forecasts in order to make this venture attractive in the eyes of our management. Once we get them a little bit pregnant, there is now way back for them"?

NOTE: If I was a gambling man I would be betting heavily on a combination of 1a and 1c; i.e. someone at the top indicated that the budget must not exceed a specific amount and despite all the information coming from the project team the senior management adopted the very noble, but unfortunately especially ineffective "Yes We Can!" approach.

Conclusion #1:

Implement a transparent process whereby every large project is allocated sufficient amount of resources and time in order to conduct the technical feasibility analysis. Technical feasibility analysis means preliminary requirements elicitation and analysis as well as the resulting estimates for budget, time and resource needs.

Question #2:

Why can the ministry build a complex hospital within 10 per cent of its original budget but lose control of the purse strings on a computer project?

Answer #2:

Because this an IT world, stupid! Let me explain my point of view. Several years ago I had a chance to conduct a spontaneous experiment in Dubai. I was teaching my Project and Portfolio Management Masterclass . The room was full of professionals predominantly from the construction, engineering and telecom industries and at some point of time we got talking about estimation on IT projects. I proposed to ask them two questions just to demonstrate how different human mind works on perceiving the sizes of IT and non-IT endeavours.

Q1: Look out of the window. Do you see that large building outside? How much do you think it cost to build Burj Khalifa (currently the tallest building in the world)?

A1: Oh! At least several billion dollars! (Actual cost $1.5 billion)

Q2: Have you ever used Amazon or eBay? What is in your opinion the total cost of development of their platforms?

A2: Couldn't be more than U$100,000 or 200,000 (actual cost are in the neighborhood of tens of billions of dollars)

Q3: (after disclosing the real costs of the projects) Why did you successfully estimated the cost of Burj Khalifa and totally missed with your estimates for the IT projects?

A3: Well, man, look at the size of this monstrosity! It had to be somewhere around a couple of billion ... As to the websites ... You logon, browse the catalog, add something to the basket and pay for it. How complicated can that be?!

This conversation was provided in order to illustrate why I very frequently refer to the chronic underestimation of the scope of the IT projects as "iceberg phenomenon". The problem is that an average person fails to see the complexity of any software development initiative because he/she only sees the very top layer - the interface of the product, while all the infinite lines of code required to make sure the interface works properly remain hidden to them.

Conclusion #2:

Do not assume that because an IT project looks straightforward, just because it appears to be simple. To get more information on the topic, please read my article "Project Failures: Black Swans and the Crack Spread Phenomenon".

Question #3:

Why can't we just hire very expensive and prominent vendors and just rely on them?

Answer #3:

Because we - at least the last time I checked - lived in a capitalist world where every company is trying to maximize its profits. Yes, there are various codes of ethics and all, but let me paint you the following picture:

Vendor: This project appears to be very large and complicated. You should probably allocate more money and time for the discovery stage (i.e. requirements elicitation and analysis).

Customer: I don't have that kind of money! Aren't you supposed to be the experts in this field. All we want is a cutting-edge, seamless and flexible eHealth system!

Now, let me ask you this (very, very easy question): Which option do you think the vendor will pick?

Option 1: This is unacceptable. I am telling you that we can't accurately assess the size and the budget of this endeavor until we spend more time on requirements. I guess, I will be gathering my belongings and leaving your office, thus foregoing millions of dollars in potential revenues.

Option 2: Oh, to hell with that guy! Let us just agree to whatever they want (or just simply keep quiet) and get the money remaining on the contract. Once the funds are exhausted, we will tell him that we need more money and time. What is the worst that can happen? They will ether fire us (highly unlikely) or allocate more resources to the project (very likely). Either one of these scenarios is better than Option 1 above.

Just to prove my point, is it very surprising now that IBM chose to "jettison key features, remove financial penalties and transfer the risk onto the provinces", once they realized that they wouldn't be able to deliver what they promised?

Conclusion #3:

You always have to remember that at the end of the day every vendor is trying to maximize its profits. If you don't do due diligence, they will most likely take advantage of your carelessness.

Question #4:

How to try to stop the cycle of grandiose modernization projects that crash and burn? How will the proposed new technology improve health care and how will that work?

Answer #4:

Great, simply great question! Let me ask you this:

Did you try to determine the value of the above-mentioned projects before you initiated them? Let me explain what I mean. Here are some excerpts from the article:

[This project will] dramatically transform old paper processes into a new system of digitized patient charts, lab tests, imaging scans, prescription drug tracking, surgical bookings, infectious outbreak management and other health care procedures

After the SARS outbreak in 2003 killed 44 people, Ottawa ordered the provinces to create a “seamless” public health software — and that work started in B.C. with Panorama

$842-million Clinical Systems and Transformation Project, which will give doctors and nurses faster access to electronic health records and bring many hospitals and health care centres under one set of electronic standards

So here are my questions:

What do you mean by "dramatically transform"? How much money did you expect to save once the new system is implemented? What is the value of this project to the provincial medicare?
What the hell is a "seamless" public software? Has anyone defined that? Again, why would this seamless software (assuming even we know for sure what that word means) help the provincial doctors and nurses? Is there a return-on-investment calculation available?
What id you mean by "faster access"? Faster by how much? Assuming we know exactly what "faster" means, what is the value of this project to our medical system? Is it the ROI? NPV?

All of these questions fall into the domain of project portfolio management. Project portfolio management is the management of the organization’s projects so as to maximize the contribution of projects to the overall welfare and success of the enterprise subject to internal and external constraints by maximizing the project value, balancing the portfolio and aligning it with overall company strategy.

Conclusion #4:

Consider embracing project portfolio management in order to rank, score and prioritize your project proposals and "kill" the ones that wouldn't add major value to your organization.

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca