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:

Since I posted my previous article “A Story of One Interview: What Would You Do?” that went viral on LinkedIn, I have received more than one hundred comments from professionals from all corners of the globe. After reading them I realized that the problem of “should the project manager be a technical expert in his/her domain?” still remains deeply misunderstood by some people. As a result I just wanted to share yet another discussion that I had at one of the project management conferences with a CIO of a North American university followed by a simple survey that would require you to select an appropriate project management candidate.

CIO: … When looking for a PM I definitely value technical knowledge more than project management experience. For example, if I have an SAP project in my portfolio, I will favour someone with SAP experience, preferably in the educational sector.

Me: (after the presentation has ended) You mentioned your preference for technical expertise over the project management one when looking for a PM.

CIO: Yes I did.

Me: I really don't want to argue here about the fact that a project manager should not be a technical expert in her domain and that you should have subject matter experts taking care of that problem. I just have a couple of questions ...

CIO: (tensely) OK.

Me: Well, let us consider the SAP example. SAP is an enterprise resource planning system, correct?

CIO: Yes ...

Me: So, it is very likely that the project would impact areas like, oh I don't know, finance, accounting, human resources, student records and even possibly engineering. By employing your logic we can deduce that the PM should also be an expert in those areas as well, right?

CIO: (smiling) Absolutely! But unfortunately such person does not exist ...

Me: OK, next question then, if you don't mind. Let us say that you hired this "great SAP expert with no project management experience" person. Let us even assume that she successfully delivers the project in question (which I personally doubt). A couple of months go by and you are presented with a new flagship initiative; say, the development of a brand-new university website.

An interesting (to say the least) conversation took place between yours truly and a vice president of software development several years ago during a job interview. Today I just wanted to share this experience with you and ask for your suggestion on how to deal with it:

VP: So, you have been working as a project manager for close to ten years now, right?

Me: Yes that is correct. The only thing I wanted to add is that I have also been working as a business/requirements analyst over that period of time.

VP: But I don't see any technical (developer) experience on your resume.

Me: Actually I have finance/management science educational background.

VP: So, you never worked as programmer?

Me: Not really.

VP: And how the heck do you expect to manage technical people?

Me: (confused) I am sorry, I am not sure what you mean ...

VP: Well, say you join our team and get assigned to work on a project. You are estimating the duration of the tasks and your programmer tells you that the activity would take 5 days. Whereas in reality it would take only 2 days. How would you know that he is lying if you don't have any developer background? What can you possibly do in this situation?

Me: (turning to the HR Manager who was also present in the boardroom) I would probably suggest that you fire your human resources manager ...

VP: (very surprised) What??

Me: (smiling) Well, you just said that most - if not all - of your programmers are liars. Shouldn't the personnel department try to do a better job when hiring people?

While this response was probably a bit harsh, I was just wondering what would you do in a situation similar to the one described above?

A) Roll up your proverbial sleeves and try to convince the VP that project managers do not have to possess technical skills in order to successfully run projects.

B) Agree with him, leave the office, cry a bit and forever abandon your project management career in software development and IT.

C) Ignore his comments, wait for the interview to finish and go look for a company with a less toxic  environment.

In the table below I have complied my own "cheat sheet" for the most typical estimation mistakes committed by project managers (see Table 1).

Table 1

Do you think I was able to capture the most important ones or can you add other estimation mistakes to this list? Please leave your comments below.

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

• Please follow me on Twitter: 
• Like our page on Facebook: 
• Connect with me on LinkedIn: 
• Subscribe to my RSS feed: 

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.

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:

You have assembled either your entire project team or at least all of the technical team leads from different areas. The job of these people is to assess the combined impact of the new change request on key dimensions of your current project: scope, time, budget, duration and quality. What are questions that should be asked in order to accomplish this task (see Figure 1)?

Figure 1

Question: What important cost and effort ingredient was omitted from the table above?

Answer: The “cost of assessing” the Change Request, irrelevant to whether it was or was not approved!

Conclusion: Educate your project stakeholders that they are delaying your project and potentially increasing the costs EVERY time they submit a change request irrelevant of whether it was approved or rejected! Assessing the requested change is an expensive and time-consuming task.

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

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:

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 ...