10 Common Lies in Project Management—When Projects With a Green Light Status Fail

Olivier Cothenet - September 8, 2016

There was a doctor in a famous TV show whose motto was "everybody lies." He kept this in mind when he was analyzing complex and mysterious cases. It always helped him to find the problem’s root cause and finally save his patient’s life.

Imagine you’ve taken the responsibility of an ongoing project. In the last status report provided, all key performance indicators are in green. You’re confident in the project’s health and you are also confident in your ability to end the project and reach the objectives—a controlled situation.

Wait a minute. As an experienced project manager, you know that everything generally goes wrong. Why so green? Will everything remain green until the end or slip quickly into a red, uncontrolled situation?

"Everybody lies." Here are ten common lies that you can find in project management or reporting. Being aware of these little truth deformations or misunderstandings will help you to get a real idea of the project status and act as quickly as required.

1. The budget is enough to complete the mission.

What has been said:	What has been really done:
“Project budget has been validated by top management.”	The budget presented was a top management-friendly budget; prepared and arranged to make them validate the business case and give their sign-off. Only macro-estimations have been done by external consultants who have no idea about the complexity of the internal organization.

The choice to launch a project or not has to be aligned with the company's strategy, but it is sometimes driven by politic considerations like selfish career interest because the project has a high visibility in the company. In this case, the budget is built in such a way that it will match what the management wants to hear: a fantastic reward for peanuts, the most incredible value for money operation. But this budget won't match the needs to correctly drive the project, to select the right vendors, and to build the expected end product.

Budget review should be one of your top priorities. Check who made the estimation, the methods used, if tasks and project objectives have been clearly understood, and if a real provision for contingency has been added.

If the budget construction is too blurred or if you feel that the budget is not enough, gather your stakeholders, explain the situation, and ask them to revise the budget or to change the scope of the project.

2. The Project Management Office (PMO) knows what it is doing.

What has been said:	What has been really done:
“The PMO is driven by the right persons.”	The PMO, an administrative project task, has been delegated to junior or inexperienced staff or inappropriate staff.

The PMO is often considered to be a purely administrative office that gathers and orders information and documentation, organizes meetings, or sends friendly reminders. In a nutshell, low-value tasks that can be delegated to anyone in the company that is able to fill an Excel file. These people will do their best based on what has been explained (or not) to them, but in the end, key meetings will be organized with the wrong actors, project time follow-up won't be accurate, project key documents won't be up to date, and project rules and best practices won't be shared.

As a result, the project team will take more time to normalize and perform.

The PMO is the heart of the project. Ensure that it has been given to people with the appropriate mindset, level of competence, rigor, and with the right knowledge of the project. If you feel that it has been delegated inappropriately, change the team or take the time to manage them closely and to train them in project management.

3. Keep calm, it's an agile approach.

What has been said:	What has been really done:
“Everything is under control; we will deliver the product on time thanks to an agile approach.”	No written specification, no meeting minutes, no follow-up of key decisions, and continuous procrastination on blocking points.

Being cool as a project manager is quite hard: You have to be focused on timeline, budget, and quality, fight everyday contingency, and be the best leader for your team. But you can try to be cool and astonish your team if you use trendy approaches like the agile one. Even if, in the end, you don't really know what it is.

Agile is not a magic word that will make your project run faster than any other one. It's a real approach with precise rules and roles. It is generally used in projects where the end product is not perfectly described or known at the beginning. It isn't a way to skip formal project follow-up and administrative management.

The risk with an uncontrolled agile approach is to deliver less features than initially scheduled because if, at the end of an iteration, the job is not completed or if tests failed, the product scope is reduced for the next iteration to try to deliverer something functional. Yes, at the end, budget and time will be respected—but forget the product.

Check to see if a real and driven agile approach is used with key actors, with each one in a precise role, and if key project documentation like the product backlog is maintained.

4. Business requirements have been validated.

What has been said:

What has been really done:

“Here is the sign-off from the top management.”	The top management received two documents: a 200-page functional description with 356 footnotes and 255 references a big-picture document where everything is simple Yes, they gave their sign-off, but what did they really validate?
“Here is the sign-off from the project users group.”	The right actors were not around the table. They weren't directly concerned by the project and their main concern was to get out of the meeting room as soon as possible—whatever the speaker said or whatever was decided was because it was lunchtime.

Many projects fail because nobody in the project team and none of the stakeholders knows what is expected or how the beautiful story in the paperboard can be materialized in real life. As a result, an objective void of sense is given to the project team that will process tasks and tasks and burn all the fuel, without going anywhere.

Identify who really understands the goal of the project, what is expected, and how things can be achieved. Then make them analyze the business requirements closely. If something is not clear or a contradiction is raised, convoke your stakeholders and make them rephrase what they were expecting. It will never be a waste of time, you will find:

• that the interpretation of the needs was incorrect
• that the needs have already changed
• that there are needs that you were not aware of

Business requirements are the purpose of the project; it’s a living item that evolves everyday. You can’t be satisfied with a sign-off. You need a common understanding and a shared vision of all stakeholders.

5. Schedule is on time.

What has been said:	What has been really done:
“Project tasks are completed in the timeframe allocated.”	We began to work on the change management gamification process because it’s more fun and easier than developing the core system.

In large projects, maintaining the schedule is nearly a full-time job. Project managers often underestimate the time needed to keep the schedule up to date and the complexity to balance tasks duration, tasks ordering, and the availability of key people.

As a result, the schedule generally follows three steps:

• Shared externally, nearly up to date, with a clear critical path (beginning of the project)
• Shared internally, only comprehensible by someone that is in the project, with a blurred critical path (a few steps later)
• Back in the head of the project manager, with a critical labyrinth (when the project is ongoing)

The schedule can always be on time, but if only low-complexity or low-priority tasks are completed (to show that the project team is doing something), the schedule will one day collapse.

It isn’t necessary to have a project plan with a lot of details; the more tasks, the heavier the administrative burden. Ask for a global schedule where the critical path and key dependences are identified and highlighted. If not already realized, request the prioritization of tasks (must have, should have, could have, won’t have), and then check the precise state of critical items. You’ll have a clear picture of the project schedule and be able to assess if the schedule is on time—or not.

6. You are not alone (project team will do what they have been asked to do).

What has been said:	What has been done, one week after:
“We are very pleased to work with you. What can we do to help you?”	Nothing.

You have a project team composed of great experts—the company’s rising stars. Even if you have deployed all your leading skills and built a trusting relationship with them, nothing goes on. Why?

Because with the very common matrix organization, when names are required to work on a project, managers reluctantly give them.

In the worst, but frequent cases:

• You have no authority link on your team
• Your team hasn’t got any personal objective on your project
• Your team doesn’t want to work on your project; they were only free when the request for staff was made

So you have been granted a dream team on paper, but it's a ghost team in reality. They will work on your project if they have some availability and if they succeed to motivate themselves. You are essentially alone with your project.

Be sure that each member of your project team has the time to work with you, the will to be implicated in the project, and the experience to deliver what has been asked. If not:

• Sell your project to your team; they will learn a lot of things working with you
• When required, train your team
• Ensure with their direct managers that your project has been written into their objectives

7. Documentation is complete and reflects the project state.

What has been said:	What has been really done:
“All project documentation is here. Everything is not up to date, but a big refresh will be made at the end of the project. Right now, we have other priorities.”	The project documentation folder is empty or full of void project document templates where only the name has been changed to give the impression that something is there.

It's a common idea and an agile principle to make the documentation at the end of the project or to skip it. This is because you will lose a lot of time building documents and updating them each time stakeholders change their minds or because, at the end of the project when everything is critical and the only goal is to deliver on time, you have to make a choice.

Project documentation is a waste of time when it’s appointed to the wrong person. A lot of people hate writing and it isn’t in their DNA to be teaching. A good document can't be done by just anybody in the project team. It is mandatory to find the balance between the wall of details and the big picture and to find the good approach.

Documentation is the best way to keep project knowledge and to share it. It will always be a time-saver when you will build a project presentation for stakeholders, onboard a new project team member, or need a reminder of how choices were made in a long-term project.

As a project manager, check regularly as to how project documentation is completed and by whom. Take the time to open a sample of project documents and to read them carefully from beginning to the end. You'll be surprised. If you have good writers on your team, take that chance to ask them to do more or to promote them to documentation leader.

8. The vendor is the best one.

What has been said:	What has been really done:
“We chose this vendor because it’s the leading company in the market place.”	We didn’t made a request for proposal because it was useless; it's the company of my brother-in-law, we can trust them. In addition, our major concurrent uses them.

How many times did you hear the sentence above when you were wondering what was done to select a vendor that never delivers what is expected?

Selection of vendors is often skipped because it's time-consuming and because company procedures are often too complicated or unknown.

Thus, vendors are selected based on their reputation or word of mouth or with the “me too” effect. The faster they are implicated on the project, the better it is.

And when the project begins, the real problems begin. The vendor hasn’t any knowledge of what you are doing or has sent you junior staff (at the price of an expert, of course) that are just here to learn at the same time as you or to google questions for you.

Review the list of vendors selected for your project. Check how they have been chosen, what they are known for, their references, and their ability to deliver what you need. If they are not the right ones, try to end the contract as soon as possible or negotiate with them to share the “learning effect.”

9. People are aware of the project.

What has been said:	What has been done, one week after:
“Communications have been sent to everybody through all media available (a push email and a news item on the digital workplace).”	The push email has been sent at 6:00 p.m. right before many people are leaving for a holiday and a little link was published at the bottom of the digital workplace. It was hidden ten seconds later by a promotional advertising from the company restaurant.

Communication is a question of repetition and timing. Check that key messages have been sent in various ways and have been repeated. Check when they have been sent to be sure that the appropriate audience was online and receptive when the key messages were broadcasted. Negotiate with the internal communication service to have your time slot secured.

Do not hesitate to use a tracking system to check and see who opened the communications or who visited the project website. You’ll be surprised to see that the communication reactivity rate (users clicking on a link in the communication or forwarding the communication) is about five percent.

During your coffee break, ask people what they have understood to see if they have the right messages in mind. If not, repeat the communication when possible and try new media.

Project adoption is not only sending email. It is a question of being sure that key messages are understood and being sure that the end users share your vision of the project.

10. Lessons have been learned.

What has been said:	What has been really done:
“Based on the lessons we learned, we know what will lead this project to success.”	We will do the project our way; it will work. The previous project manager is no longer with the company, it's useless to see what has been done.

This is the third time in ten years that your company tried to make the same project, and this is the third time the project failed. Why? Because lessons are very difficult to learn.

When a project fails, everything needs to be cleaned quickly to try to forget it and to avoid shame. The company won't invest in understanding why or how they arrived in such drama. The former project team is generally thanked and replaced by less experienced staff or external consultants because the budget has been cut—enough money has been wasted.

As a result, the same mistakes are repeated, the same wrong ideas are adopted, and the project fails again.

If project lessons are not formalized and stored in the company, investigate:

• Try to contact former project managers, even if they are no longer in the company
• Try to find projects in the same situation as your projects; have a discussion with the key actors of these projects and the final users to get their feedback on what has and has not worked

Try it Yourself
Here is an example of a quick quiz that you can use to see if your project report is really green:

	Themes	Key questions	Possible answers	Mark
1	Budget	1.1 Who made the budget?	External consultants	2
			Project sponsor	1
			Internal expert team	3
		1.2 Which method was used?	Parametric estimating	3
			Comparison with a similar project in the company	2
			Project manager intuition	1
2	PMO	2.1 The PMO is?	A certified project manager	3
			A junior team followed by the project manager	2
			Your nephew just hired as a trainee	1
3	Agile approach	3.1 Which agile approach is used?	Scrum	3
			PMI for agile project	3
			Project phases have been called iterations. That’s agile, isn’t it?	1
		3.2 Is the project backlog defined and linked to project iterations?	Yes, in our project management tool	3
			Yes, in our Excel file for project follow-up.	3
			It was on the paper board, but oops, the cleaner just removed it.	0
4	Business requirements	4.1 How have business requirements been formalized?	It was also on the paper board that was cleaned. But don't worry, we have them in mind.	0
			Here is the second tome of the requirements, hope you liked the first one; page 445 (chapter 76) was really exciting to write.	1
			Here are the specifications and the slides “project for dummies” that summarize key principles.	3
		4.2 Who validated them?	The experts group (3 people)	3
			The focus team (about 17 persons)	1
			The business leader	2
5	Schedule	5.1 How have tasks been prioritized?	The MoSCoW principle (must have, should have, could have, won’t have) has been used.	3
			As they were stored: first in, first out	0
			Everything is in the backlog, if it is not realized at this iteration, it's negotiated with the client.	1
		5.2 What is the critical path of the project?	For the moment, we try to launch as many things as possible.	1
			Features A, B, D, E, and H	3
			We don’t yet know the final state of the product, so we don’t know the critical path.	1
6	Project team	6.1 How has your project team been constituted?	The project sponsor said, “Here is your team,” and you know that he has made good choices.	1
			You were implicated in the selection of the profiles and the definition of their objectives.	3
			You're still looking for people that have the competencies to lead the project.	1
7	Documentation	7.1 Is there a shared documents repository for the project?	I'll send you key documents by email.	1
			Here is the address of the online site where we share the documentation.	3
			Don’t worry, documentation will be made at the end of the project.	0
		7.2 What are the last modification dates of the documents and how many times have they been updated?	About two weeks after the beginning of the project—that means six months ago.	1
			Yesterday—for instance, project decisions matrix or backlog are updated nearly daily.	3
			Don’t worry, documentation will be made at the end of the project.	0
8	Vendors	8.1 How was the request for proposal (RFP) made?	There’s an undisputed leader in the market and we chose it—no need to lead a RFP.	1
			I really know this vendor well and the guys behind it. That’s why we chose them.	2
			We made a market study, a bid was sent to a selection of vendors, short-listed vendors have been invited to an oral, and were evaluated by the project group.	3
		8.2 Does your vendor have references similar to your project?	No, but there are great experts in this company	2
			Yes, with a company in the same industry area	3
			No, and they sent us junior staff	1
9	Communication	9.1 Which media have been used?	Email, the best way to touch people	2
			All that can be found (email, poster, intranet, internal newspaper)	3
			Word of mouth, we made a buzz!	1
		9.2 When have communications been sent?	Friday at 6:00 p.m., we've just finished them	1
			Two days before New Year’s Eve, we've just finished them	1
			At 11:00 a.m. on Tuesday	3
10	Lessons learned	10.1 Is there a post mortem of a similar project?	No, and former project team is no longer here	0
			No, but I've a meeting scheduled with the manager that was in charge of the project. He’s no longer in the company, but I found him on LinkedIn.	3
			We have access to the quality audit of the project.	3

Review which answers you chose and add up the marks. Check where you are:

More than 40 points	Congratulations, your project is in very good health! Some stuff can be improved, but nobody’s perfect.
Between 25 and 39 points	Be careful, even if things seem to be going forward, the breaking point can be near.
Less than 25 points	OK… You really need to check everything from the beginning. Relax, take a deep breath. You can do it.

Conclusion
There is no easy answer as to why people lie. Personal interest? The will to show that everything is OK—anywhere, anytime, and no matter what happens? Omissions?

In a project status report, green lights aren’t a necessary condition to guarantee a final success. Projects with a high risk of failure and projects close to the breaking point can easily be hidden under an over-optimistic or uncontrolled view of what has really been done.

A good road security approach used commonly in driving can also be helpful to use in managing projects whenever you are in danger. Keep calm and cool for your passengers, but always keep in mind that the worst is coming. This should be the way you drive your projects. Dangers are hidden in the information given to you: The devil is in the details, always ask for more. Give yourself the time to perform a few checks on what has been provided to you and be ready to act quickly when needed. It's a project quality approach that can bring you back to the truth—and to success.

Remember that at the end of each project failure, a head needs to be cut—better if it is not yours.

In a Nutshell
Even if indicators are green and management is at the top of the art, your project can be at risk. Why? Because the truth can be hidden under common little lies:

• The budget is enough, but it is just a budget acceptable by management and not the real one
• PMO is in place, but consists of unexperienced staff
• Agile approach is promoted just to hide a lack in project management
• Requirements are validated, but haven’t been read or understood
• Schedule is on time, but tasks aren’t ordered or prioritized
• Project team is in place, but has no objective on your project
• Documentation is done, but is just void document templates
• Vendor selected is just a good old friend
• Communications have been sent when nobody was receptive
• Lessons have been learned, but haven’t been consulted

These basic checks on what has been said and done can bring back the truth and save your project.

About the Author
Olivier Cothenet is a project director specialized in new technology of information and communication. He has over ten years of project management experience in nonprofit organizations, and in small, medium, and large companies in both local and international contexts.

---

Comments (36)