Four common rookie project manager mistakes and how to avoid them

Abstract

Rookie project managers often fall victim to costly mistakes and errors that can derail a project and significantly impact one's project management career. Fortunately, these mistakes are indeed avoidable. This paper explores four of these all too common mistakes and provides practical tips and best practices that can be used by project managers of varying experience level.

Introduction

While project managers can often become consumed with day-to-day administrative details and status updating, they can sometimes lose sight of key steps that are a critical part of the foundation of any successful project. Four specific pitfalls that too often derail the rookie project manager include the following:

Mistake #1—Not Dealing With the Slacker on the Team

Mistake #2—Skipping the Initiating Phase

Mistake #3—Skipping Risk Analysis

Mistake #4—Not Being Brutally Honest With the Project Sponsor

Any of these mistakes can cause time/cost overruns, morale difficulties, poor project selection, team dysfunction, estimating errors, stakeholder dissatisfaction, or other project problems.

The Four Mistakes

Mistake #1—Not Dealing With the Slacker on the Team

Many project teams fall victim to the proverbial Pareto Principle where 20 percent of the team is actually doing 80 percent of the work. It is an all too often phenomenon, and one with potentially disastrous consequences not just for productivity and task output but possibly more importantly for the overall morale of the team. Indeed, most team members are well aware if there are one or two team members who are simply not pulling their weight. This not only frustrates other team members but also destroys overall team morale. Left unaddressed, a perfectly well functioning team over time can become quite dysfunctional as more and more team members begin to “slack off.”

If the consequences of ignoring this behavior are so significant, why is it so often ignored by rookie project managers? Those newer to their positions are often less comfortable confronting team members who may have more seniority than they have. Indeed, “confronting the slacker” can be quite intimidating. Oftentimes, there is fear about whether the slacker will retaliate, push back on the project manager, or in some way cause problems within the team. These concerns are quite valid; however, the behavior must be addressed if the project manager is to engender a healthy team environment.

The key to addressing this behavior most effectively is to build a “culture of accountability” within the team from the outset of the team experience. This approach shifts the role of the project manager from “parent-child” where team members accept tasks on behalf of the project manager and are therefore accountable to the project manager to one of “team facilitator” where the accountability rests not with the project manager but with the team as a whole. Using this new paradigm, the project manager acts as more of a facilitator on behalf of the team by enforcing ground rules and holding all team members accountable (to the team). This type of “team accountability” can be illustrated by the handling of action items during team meetings. When a team member accepts ownership of an action item (or task), the team should clarify early on that owners (not the project manager) are responsible for providing status updates to the team. Should the project manager detect potential slippage in completion dates or any other inability to perform the task as promised, these issues should be raised as part of the standard “action item review” conducted at the beginning of every status meeting. This is not intended to embarrass anyone but instead to build a culture of accountability within the team. This practice should be introduced from the very first meeting (before any slacking behavior begins) to ensure that no one feels they are being singled out or treated differently. Project managers who do not ignore slacking team members but instead insist that they be held accountable just like everyone else on the team engender valuable respect from his or her team.

Mistake # 2—Skipping the Initiating Phase

Too often project managers are placed under so much pressure to deliver results quickly that they feel that they are late before they have even begun! As a result, less experienced project managers often make the mistake of skipping over some of the earlier steps of the project management process and turn their attention too soon to the planning (or even execution) phase. This can be such a dangerous step. Don't do it! The first phase of project management, the initiating phase is absolutely critical, and the dangers of skipping it can be significant.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Project Management Institute [PMI], 2008) speaks to the importance of the Initiating Process Phase. “Within the initiating processes, the initial scope is defined and initial financial resources are committed. Internal and external stakeholders who will interact and influence the overall outcome of the project are identified. When the project charter is approved, the project becomes officially authorized” (p. 44).

In some cases, the initiating work may begin before the project manager is officially selected; however, even in these cases, the project manager should “backtrack,” so to speak, with the project sponsor or other key stakeholders to ensure that the proper vetting has been conducted and key questions have been answered. When this is not done, very often project managers spend significant time during project execution suffering the consequences of having a lack of clarity around these issues, which should be documented in the project charter.

Key questions to include during the initiating phase include these:

  • Why are we doing this project?
  • What problem/issue are we trying to fix/address?
  • Is this project the best way to address this problem or issue?
  • Is this project the best use of resources at this time?
  • What are the risks associated with this project?
  • Do the benefits outweigh the risks?
  • Do we have adequate support to conduct the project?
  • How will success be defined for this project?
  • What are the triple constraint expectations/priorities?

Indeed, without clear direction on such fundamental issues, the project manager is moving forward with a weak support structure at best. Oftentimes, when these issues are not discussed and clarified during the initiating phase, the questions/issues resurface at some later point in the project life cycle, when the issues are much more costly and difficult to address.

With experience, project managers discover that it's imperative to spend some time answering these key initiating questions very early in the process and ensure that the appropriate support structure is in place and the project is indeed beneficial to the organization. In a worst-case scenario, proper initiating phase vetting may have eliminated the project completely—missing that analysis is a fatal error indeed.

Mistake # 3—Skipping Risk Analysis

Too often project managers view risk analysis as another planning step that they do not have time for. As a result, they oftentimes make the fatal mistake of skipping it completely. What they fail to realize is that time spent doing risk analysis typically pays back significantly throughout the life of the project. Indeed, it can be tempting for project managers to focus their efforts on developing a “bullet proof” project plan, but the reality is that there is no such thing! Virtually every project will deviate from plans in some way because of unexpected changes, and project managers should be ready for that. Risk analysis is a wonderful tool to help do just that.

The PMBOK® Guide clearly asserts the importance of conducting risk analysis during the planning phase. “Qualitative risk analysis is the process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact. Quantitative risk analysis is the process of numerically analyzing the effect of identified risks on their overall project objectives” (PMI, 2008, p. 54).

Once the risk events have been prioritized based on probability and impact, the project team should develop a list of mitigation strategies and backup plans for the most severe risk events. A mitigation strategy is intended to prevent a risk event from occurring. In contrast, a backup plan would be implemented after a risk event has occurred.

Indeed, skipping risk analysis is like sticking your head in the sand. The unfortunate truth is that virtually all projects carry some risk. The astute project manager recognizes this and consequently conducts risk analysis not only to prepare the team for possible risks but also to take steps to proactively mitigate those risk events (and actually increase project success). This risk analysis not only serves as a tool for the team to utilize through project planning and implementation, but it also serves as a tool that the project manager can use to assist in expectation setting with the project sponsor or other key stakeholders. Indeed, risk analysis data (quantitative and/or qualitative) should be shared with the project sponsor with the intent of securing support for additional resources, resetting success criteria, or securing support for planned mitigation strategies or back up plans.

Mistake # 4 – Not Being Brutally Honest with the Project Sponsor

Project sponsors play such an important role in the success or failure of a project. The PMBOK® Guide defines the role of the project sponsor as follows: “A sponsor is the person or group that provides the financial resources, in cash or in kind, for the project” (PMI, 2008, p. 25). The PMBOK® Guide further specifies the responsibilities of the project sponsor: “The project sponsor works with the project management team, typically assisting with matters such as project funding, clarifying scope, monitoring progress, and influencing others in order to benefit the project” (PMI, 2008, p. 215).

One of the project manager's key responsibilities is to keep the project sponsor adequately apprised of the project's progress and any potential problems. Because the project sponsor represents power, many project managers (particularly those with less experience and organizational seniority) fall into the trap of painting a rosier picture than actually exists. Ironically, this actually hurts the project in a variety of ways:

  • Sets higher expectations than may be realistic for project results;
  • Puts the project manager in the difficult position of having to later explain why the sponsor and other stakeholders weren't warned of problems earlier;
  • Erodes sponsor's confidence in the project manager's estimating skills (for future projects); and
  • Sends the message that the project manager is easily intimidated and unwilling to speak truth to power.

Admittedly, project sponsors are not always ideal. However, most will readily admit that they would much prefer and respect a project manager who tells them the truth (even if it challenges some their views and assumptions) than being blindsided and horribly disappointed with poor results. Indeed, even if there's bad news to share, they would rather get the bad news as soon as possible positioning them to take corrective action sooner rather than later (quite likely saving time and money).

Obviously, being brutally honest with a project sponsor can be challenging. Consider the following best practices when faced with this dilemma.

  • Ask the sponsors at project inception whether they want brutal honesty about project progress. (They will say “yes,” and this gives you a bit of “permission” to be candid with them.)
  • Ask the project sponsor s to define success criteria as part of project initiation. Also, ask them to prioritize elements of the project charter.
  • Alert the sponsor to potential problems as soon as possible.
  • If you do not have much history with the sponsor, consult someone who does for advice about how best to approach them.
  • Gather facts and data to support your assessment.
  • If possible, develop best case/worst case scenario data.
  • Be prepared to share your recommendation(s) and provide alternatives if appropriate.
  • Emphasize the fact that you are sharing this information to hopefully position them to take corrective action as early as possible.
  • Acknowledge that you can only share the information and make recommendations, but the project sponsor is often ultimately responsible for final major decisions regarding the project. Do not place undue pressure on yourself unnecessarily.

Conclusion

Being a new project manager certainly is not easy. In addition to the mechanics of managing a project, the new project manager must quickly learn to avoid these all too common traps that can unfortunately doom a project almost before it begins. It is critical that new project managers lead from a position of strength and not let intimidation cause them to make critical mistakes. Confronting difficult team members can be just as challenging as being brutally honest with a project sponsor. If ignored, either situation can poison the project. Likewise, project managers must reject the temptation to skip preventative steps like project initiation and risk analysis. Both may seem like luxuries during the early stages of the project but will soon prove to be absolute necessities indeed.

References

Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK Guide) (4th ed.). Newtown Square, PA: Project Management Institute, Inc.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2012 Dana Brownlee
Published as part of Proceedings PMI Global Congress 2012 – EMEA, Marseille, France

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.