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:

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:

Sign #1: Project and resource managers often fight over resources.

Example: The head of the Finance department asked IT services to install a new accounts payables system. When approached by the project manager, requesting to assign two financial analysts to formulate the requirements of the system, the Director replies with unequivocal, "Are you nuts? There are too busy!"

Sign#2: Priorities of projects frequently change, with resources reassigned from one project to another.

Example: At the beginning of the year the CEO of your company announces that project A is the most important endeavor and will have the highest priority when it comes to resources - both financial and human. Sometime in March you suddenly discover the project manager of project A aimlessly wondering the hallways of your office. When you inquire about the status of her project, she lethargically replies, "Oh, the strategic priorities have shifted ... All resources have been reassigned to project B! And by the way, my deadline and scope remain unchanged."

Sign#3: Senior managers have authority to unilaterally approve and release projects.

Example: Your recent project got initiated simply because the CEO of your company walked into the conference room and uttered something to the effect of, "Wouldn't it be really cool if we could do this!" No feasibility study, no conversation with your technical or marketing experts. Nothing.

Sign#4: Projects are started as soon as approved by senior managers, irrespective of the resource availability.

Example: Project C has been approved by the executive committee and the project manager has been assigned to run the new initiative. Unfortunately, right at the Initiation stage, he hears the following from the PMO Manager, "I hope this project does not require too many resources. We simply don't have any ... People are too busy working on other tasks. Just be creative and deliver this!"

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