Common Mistakes of Project Managers

A single mistake from the person in charge of a project can not only cause delays but at times might even result in the complete failure of a project. This is not only incredibly demotivating but can also create issues around reputation management not to mention a potential marketing nightmare for the organisation or the team ultimately responsible for the delivery of the project.

While no two projects are exactly the same, the issues that can affect — and potentially jeopardize — them are often quite similar. And even good project managers can make mistakes when wrangling a big, complex project — or when being bombarded with change requests. Understanding the most common project management mistakes helps focus our efforts and helps us to avoid the same mistakes on our projects.

The following are some of the most common mistakes made by project managers:

• Not clearly understanding how or ensuring that the project is aligned with organizational objectives.
• Not properly managing stakeholder expectations throughout the project.
• Not gaining agreement and buy-in on project goals and success criteria from key stakeholders.
• Not developing a realistic schedule that includes all work efforts, task dependencies, bottom-up estimates, and leveled assigned resources.
• Not getting buy-in and acceptance on the project schedule.
• Not clearly deciding and communicating who is responsible for what.
• Not utilizing change control procedures to manage the scope of the project.
• Not communicating consistently and effectively with all key stakeholders.
• Not executing the project plan.
• Not tackling key risks early in the project.
• Not proactively identifying risks and developing contingency plans (responses) for those risks.
• Not obtaining the right resources with the right skills at the right time.
• Not aggressively pursuing issue resolution.
• Inadequately defining and managing requirements.
• Insufficiently managing and leading project team.

You are a project manager who has to juggle multiple projects simultaneously without messing up any one of them. Despite that, the projects you oversee end up taking longer to complete and cost you much more than the original budget. This gives you sleepless nights and even when you sleep, you get nightmares. Does all this ring a bell? If yes, you need to think about the reasons why projects fail. When you analyze it, you will realize that you are making some  classical project management mistakes repeatedly that are hampering your project progress.

Qualities of Successful Project Managers

Given the many roles played by a project manager, the broad range of skills needed, and the inherent challenges in successfully delivering a project, we need to find ways to accelerate the learning process. Two key ways to accelerate our learning are understanding the qualities of successful project managers and understanding the common mistakes made by project managers. In this post we'll focus on the qualities of successful project managers.

Successful project managers do not share personality types, appearances, or sizes, but they do share three important features:

1. They excel in at least two of the five key skill categories (Project Management Fundamentals, Business Management Skills, Technical Knowledge, Communication Skills, Leadership Skills) and are either “good enough” in the other categories or staff their teams to compensate for their deficiencies.

2. They avoid the “common” mistakes described in the next section.

3. They bring a mindset and approach to project management that is best characterized by one or more of the following qualities:

• Takes ownership—Takes responsibility and accountability for the project; leads by example; brings energy and drive to the project; without this attitude, all the skills and techniques in the world will only get you so far.

• Savvy—Understands people and the dynamics of the organization; navigates tricky politics; has the ability to quickly read and diffuse emotionally charged situations; thinks fast on the feet; builds
relationships; leverages personal power for benefit of the project.

• Intensity with a smile—Balances an assertive, resilient, tenacious, results-oriented focus with a style that makes people want to help; consistently follows up on everything and their resolutions without
“annoying” everyone.

• Eye of the storm—Demonstrates ability to be the calm eye of the project hurricane; high tolerance for ambiguity; takes the heat from key stakeholders (CxOs, business managers, and project team);
exhibits a calm, confident aura when others are showing signs of issue or project stress.

• Strong customer-service orientation—Demonstrates ability to see each stakeholder’s perspective; able to provide voice of all key stakeholders (especially the sponsor) to the project team; has strong
facilitation and collaboration skills; and has excellent active listening skills.

• People-focused—Takes a team-oriented approach; understands that methodology, process, and tools are important, but without quality people it’s very difficult to complete a project successfully.

• Always keeps “eye on the ball”—Stays focused on the project goals and objectives. There are many ways to accomplish a given objective, which is especially important to remember when things don’t go as planned.

• “Controlled passion”—Balances passion for completing the project objectives with a healthy detached perspective, which enables him to make better decisions, to continue to see all points of view, to better anticipate risks, and to better respond to project issues.

• Healthy paranoia—Balances a confident, positive outlook with a realism that assumes nothing, constantly questions, and verifies everything.

• “Context” understanding—Understands the context of the project, the priority that your project has among the organization’s portfolio of projects and how it aligns with the overall goals of the organization.

• Looking for trouble—Constantly looking and listening for potential risks, issues, or obstacles; confronts doubt head-on; deals with disgruntled users right away; understands that most of these situations are opportunities and can be resolved upfront before they become full-scale crisis points.

In the next post we'll focus on the common mistakes made by project managers.

Project Change Control Challenges

In this post we'll look at the challenges faced by many project managers. Here’s a list of things to either avoid or be on the lookout for:

The obvious—Be sure to set up a change control system as part of your approved project plan—and then use it.

Can’t say “no”—Use your change control system and don’t automatically agree to accept a scope change request without running it through the process. This is a common issue with project managers who have a fear of confrontation. Use your system as an objective third party to minimize direct confrontations.

Can’t say “yes”—Some project managers take the other extreme. They are so paranoid about “scope creep” that they do not listen to consider legitimate scope changes, often overlooking changes that are needed to meet the project objective. Again, keep the focus on the “big picture” (the project objectives) and exercise your change control system.

Over-reliance on formal sign-offs—Formal sign-offs are important and valuable. However, they should represent genuine agreement and understanding. Verify that you have real understanding and buy-in before proceeding.

Not the “gold” you want—Be on the lookout for gold-plating. This is the term given to extras or features added to the work product by the project team but not requested by the customer. This is a common reason why schedule delays occur and why unnecessary risks occur on projects. Also, the same issue can manifest itself in a work process. A technician might want their work to be perfect rather than just meet the specifications for the project. This is another reason why a team approach to estimating and planning can be so valuable.

Is it really a change?—Sometimes stakeholders do not agree on what really is an official change. Especially in contractual arrangements, the issue isn’t always “is it a change?” but rather “do I have to pay for it?”—a slightly different matter. Most of the disagreements occur because of ambiguity or inconsistencies in the specifications. Just do the other things we mentioned, and you should have a solid foundation to deal with this, if it ever happens.

The “impact” of the impact—In most cases, the individuals who need to assess the impact of a proposed change, especially scope changes, are members of the existing project team—who have current work assignments. Be aware of the impact that this “unplanned” effort could have on the project and guide the CCB accordingly.

Inadequate impact analysis— Just make sure the analysis performed on the impact is complete. At the minimum, verify the following on any change request assessment:
• Has the total work effort been accounted for? All supporting processes? All impacted deliverables?
• Have the implications of the request been completely considered?
• Have all impacted stakeholders been considered?

Beware of the little guys—On most projects, there will always be one or more of those small, minor scope changes. Sometimes they are clear changes; other times, they fall into a gray area. In an effort to build relationships and please the customer, many project managers do not document these if they feel the change requires minimal effort to implement. Be very careful here. Before you know it, you can easily have a series of these little changes that, when added up, can affect your project.

In addition, you must manage the expectations you are setting if you overuse this technique. As a rule, I would encourage you to at least document every change—no matter how small. For small  ones, you might choose to group them into a single change request.

Powerful Techniques for Minimizing Project Changes

The following techniques are powerful change prevention actions we can take:

Clear project definition—The more effort spent upfront to get agreement on clear project objectives and success criteria from the appropriate stakeholders, the less likely we are to get change requests during the project.

Solid requirements definition—Discussed in previous posts when we looked at the common reasons for scope changes.

Trace requirements—There is nothing like linking any work specification to its original source to control project scope. By tracing and showing the relationship from the original business objectives down to the detail design specification, you can identify (and possibly eliminate) any scope expansion when it is first proposed. If the proposed feature does not link directly to a higher level specification, it is a potential scope change.

Formal acceptance sign-offs—Formal sign-offs are a key aspect of change control management, especially for client-vendor oriented projects. The formal record of review and acceptance of a given deliverable helps to keep expectations aligned and minimize potential disputes.

Engaged stakeholders—Although formal sign-offs do act as strong “stick” incentive to get stakeholders involved, there is nothing like having professional, knowledgeable, and engaged stakeholders who are committed to doing their best as the best weapon against unplanned scope
expansion. A team of people who want to work together and get the job done can accomplish the work at hand with a “less formal” level of project management.

Use the right project approach—This technique is more about risk management, but change control and risk management are very intertwined. As mentioned before, if you know there is likely to be a high degree of change, structure your project in a manner that allows for deliberate, planned scope expansion (prototyping, iterations, cycles, and so on). For all projects, the following approaches help reduce the number of project changes:

• Emphasis on project definition and planning
• Shorter timeframes (1 year or less is preferred)
• Pilot tests
• Phased implementations
• Go/no-go decisions at phase-ends

Use WBS to illustrate impact—This technique might not prevent change requests from being submitted, but it can help you classify something as a change (and not part of the intended scope), and it can help you communicate the effect of the proposed change. By reviewing your detailed WBS, you can show that the work for the proposed feature was never accounted for, and you can show what other work items will be affected by adding the proposed change.

Defer to post-implementation—Another technique that will not prevent change requests, and that might not be applicable to all project situations; however, if it does, it can reduce impact on the project success factors. If the change request is legitimate, but is not absolutely critical to the initial
release (there is not a workaround, it does not adversely affect the customer experience), you can guide the CCB to defer the request to a future project or a post-implementation phase.

Track assumptions and constraints—This is definitely part of your risk response plan, too, but part of your “watch dog” mindset is to keep a close eye on the project assumptions and constraints. If these change, your project will definitely be impacted.

Although we want to be prepared for project changes when they occur, we want to spend most of our energy preventing the need for changes in the first place. Hence using the above discussed techniques must be carefully used to minimize project changes.

Elements of a Project Change Control System

The specifics of project change control systems can vary depending on industry, organization, and project importance, but there are essential principles, guidelines, and components that every change control system should possess.

Principles

Effective project change control systems follow these key principles:

1. Any proposed scope change is documented, evaluated, and approved before it is implemented. 
2. The appropriate stakeholders are involved in the evaluation and approval process.
3. Any change request is thoroughly assessed for impact to other project critical success factors, especially project schedule and budget.
4. The appropriate management level approves any change request before it is implemented.
5. All project changes are documented and communicated to all stakeholders.
6. Any stakeholder is permitted to submit a project change request.
7. The rules are firm, the roles and responsibilities are clearly defined, and
   the workflow process meets the needs of all stakeholders.

Guidelines

In addition to the principles we reviewed, these guidelines should be considered for an effective project change control system:

Re-baseline—The project plan should be updated to reflect the acceptance of any change to the critical success factors. A new performance baseline should be established.

Multiple paths—The change control system should consider multiple process paths based on estimated impact of the change request and the thresholds negotiated with senior management. This allows the appropriate stakeholders and management levels to be involved when needed and at the right time.

Focus on “buy-in”—Especially on proposed scope changes, make sure the right stakeholders are involved, understand the need and impact of the proposed change, and agree to the action plans before proceeding.

Aligned with contract—If your project involves contractual arrangements, make sure the project’s change control process is aligned with the change control process used to manage the contract with the vendor(s).

Components

There are no requirements from a technology perspective when it comes to project change control systems. They can leverage manual processes or utilize enterprise software packages. The following components are present, understood, and utilized:

1. Change request form—This form is used to capture the pertinent details of the proposed change and the key information resulting from the impact assessment.

2. Unique identification number—When a change request is submitted for evaluation, a unique identification number should be assigned to facilitate better communications and tracking.

3. Change request tracking log—The tracking log communicates summary information on all project change requests. Minimal information includes identification, impact summary, and current status. Spreadsheets and databases are common tools for tracking logs.

4. Change control board (CCB)—The minimum set of project stakeholders who need to review and approve any change request impacting the project’s critical success factors.


At the heart of managing project changes well is a project change control system. The specifics of project change control systems can vary depending on industry, organization, and project importance. Ultimately, the determination of any change request is a consensus-based, cost-benefit decision made by the stakeholders accountable for the project.