Inspired by Chris Croft‘s course about common mistakes in project management, this article revisits five of them. In hindsight, some I did inadvertently, and some I will probably do; therefore, sharing these imperfections can make the difference between a good project to an excellent one.

As project managers, you may find these mistakes familiar; catching them on time makes your life easier. So, without further ado, please welcome the top five lapses:

Stories, not Facts

Management is a facts-based process. “You can’t manage what you can’t measure” (Peter Drucker). We tend to fall in love with a story that has a compelling narrative; this is much simpler than gathering information and delving into details; nevertheless, it is irresponsible to make conclusions based on stories, whereas tangible measurements and findings should be the base for decisions making.

People’s beliefs may be convincing, but deeds are undeniable. Therefore, registering events, documenting activities, and justified assessments are the building blocks for objectively understanding the progress of a project and determine the next steps.

Moreover, fortifying your decisions based on factual evidence increases your reliability as a project manager. You can always look back and trace the reasons for the decisions you made, as opposed to hunch-based decisions.

In short: the project plan should reflect the project’s activities based on concrete occurrences and solid information.

Withholding Information, not Sharing

Management is far from being a one-man show; it involves working teams, stakeholders, sub-contractors, and end-customers. Every party holds some information that is only accessible to them.

Let’s focus on the project’s internal teams. The sharing of the project plan, tasks and dependencies, risks, or reasons for rescheduling is essential for several reasons:

• Better planning: the team members have the expertise, and thus their advice are valuable. Furthermore, your team have knowledge you’re blind to; this knowledge improves planning and monitoring.
• Cohesive team: sharing information increases the sense of belonging and the engagement level of individuals; it rises the commitment and harnesses the team to achieve a common goal.
• Certainty: people feel safer in a collaborative environment; they will cooperate more and be more creative.

The tendency to hold information can originate from many reasons; some think it is the faster way to move forward. For others, creating obscure situations to keep control or slip away from criticism can justify this tendency. Nonetheless, whatever the reason is, this approach is not effective and can be harmful to the project in the long-run.

In short: sharing information may take its toll in the short run, but that’s necessary to establish the foundations for the project to thrive.

Monitor Tasks, not a Gantt Chart

That’s a common pitfall. Listing tasks, owners, and target dates is the foundation to master activities and efforts, but that’s not enough to manage a project, there is more than that.

Things will get complicated when hindrances pop up, or unexpected events occur. Being able to identify critical tasks, highlight bottlenecks or slack, unravel dependencies and constraints are essential to control the project properly.

You can use spreadsheets for the job or other Gantt chart solutions to manage the project, but it’s crucial to choose the right tool to be able to foresee impending problems and ramifications of delayed tasks; otherwise, you will lack a significant part in controlling activities.

In short: use the Gantt chart to understand what is concealed beyond the tasks fully; that is needed to keep the project on track and tackle problems.

Delivering Bad News too Late

Although we want to believe that problems will fade away naturally, in most cases, it doesn’t happen. Thus, the better option is to reveal problems beforehand, than keeping bad news till the end, when there is nothing left to do.

It takes much courage to face a customer or a stakeholder and report that something went wrong; therefore, it seems easier to ignore the situation, like the ostrich syndrome that buries its head in the ground.

However, disregarding a problem is negligence, which can grow into a disaster. Handling issues while they are young is more controllable, and thus things can be maneuvered and solved to the satisfaction of all parties.

Be prepared before conveying your message. Always come with practical proposals of what can be done to alleviate the pain of the news you are about to deliver. I remember the tension before telling my customer that the project will be delayed, but after the initial shock and anger, came the productive part of how to find a joint solution that will serve the best interests of the project under the circumstances.

In short: although delivering bad news may be deemed as intimidating, the other side may thank you for exposing problems when there is still a way to remediate the situation.

Retrospective? Who has time for it?

After the celebrations, when the project is over, everyone rushes to their next assignments. Contemplating on the things that worked well or the required improvements may seem like a waste of time. It is so easy to disregard the retrospective process for some reasons:

• Lack of time and low prioritizing; the benefits of conducting the retrospective do not outweigh the other tasks.
• Hard to remember what really happened and what were the causes and effects of happenings.
• Documenting events and names are forever; no one wants their oversights to be carved in stone.

In spite of these reasons, in my view, this is the paramount act in the project’s lifecycle. Firstly because closure is a meaningful step; halting for a moment to review the journey and recognize the achievement is an opportunity to say “thank you”, before moving on. Secondly, inspecting the occurrences is necessary for learning and improving, on both the organization’s and the individuals’ level; digesting the findings ensures the lessons learned are not forgotten.

Retrospectives are not only reserved to the end of the project. In Agile development, the retrospective ceremony has its own place as one of the pillars, but in traditional project management, it’s easy to neglect it. 

To improve this, retrospectives should be part of the project planning by setting check-points in the project’s plan itself. These are opportunities to re-examine the project’s trajectory in the middle before it is too late.

In short: having an honest and professional review of the activities and behaviours to preserve or to strengthen is imperative to avoid repeating the same errors. Make it an integrated habit in any project you manage.

Wrapping-up

These mistakes will happen. There will be circumstances that force us to stray from the correct path; that’s the nature of projects. Yet, we can mitigate the consequences by keeping in mind these pitfalls and be aware beforehand.

Keep on getting better.

– Lior