10 Project Management Terms Customers Love to Hate

As I was starting to write a blog on creating a well-organized WBS, I was reflecting on the fact that the WBS is a term/activity that customers often do not understand or appreciate. That got me thinking about all of the project management terms and processes that customers do not like or appreciate. The other day a client said to me, “You talk like a project manager”. Given that I am a project manager, I took this as a compliment (although it may or may not have been intended that way). However, in the role of a project manager you are responsible for leading teams and building relationships, and certain project management terms and processes can disrupt team dynamics and ultimately impact the team’s performance. All of the terms I discuss in this blog are part of doing our job as a project manager, and the customer’s negative perception associated with these terms is usually a function of how they are applied during the project delivery processes.

Top 10 Project Management Terms Customers Hate

  1. Work Breakdown Structure (WBS) – The scope of the project is the most difficult component of the project baseline to define and describe. The Work Breakdown Structure (WBS) represents a best practice area to effectively confirm/validate the scope of the project. The WBS is a deliverable-oriented hierarchy that defines the work of the project and only the work of the project. The WBS breaks the work down into components (work packages) that can be scheduled, estimated and monitored & controlled. Due to a lack of experience and understanding of the WBS, customers do not always place value in the process of breaking down and organizing the project deliverables. They often view participation in facilitated WBS sessions as tedious and painful.
  2. Target Date – The customer’s irritation with the use of the term target date is generally their perceived lack of commitment to a date (project completion, or interim milestone). In most cases this can be overcome by explaining that the team’s commitment will be achieved as soon as the date is supported by an approved project plan (scope, schedule, resources, and budget). It is definitely a good practice to clarify when a date represents a target date vs. a committed date supported by the project plan. Upon completion of the project plan, I will highlight gaps between target dates and planned dates, and provide alternatives to “close the gaps” as part of finalizing/approving the plan.
  3. Progressive Elaboration – Progressive elaboration is a term and process that some project managers are not familiar with, let alone customers. Progressive elaboration is tied to the concept of “rolling wave planning”, where short-term milestones are planned in more detail than future milestones. As the project progresses, the work associated with future milestones is “elaborated” and planned in more detail. This practice works well with iterative project delivery approaches, but makes customers uncomfortable because “up front” the timeline, budget and scope are not fully developed. In these cases it is important to establish high level scope, schedule and budget expectations that the project team manages within. This is an extremely effective practice, and customers gain confidence in it when team utilize it well to streamline project delivery processes and reduce the overall time to market.
  4. Assumption – Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started. Customers get the most annoyed when assumptions are utilized as a CYA. I hate it when I run across assumptions like: “We have enough resources to complete the project.” –or- “The client will be available to approve the deliverables.”
  5. Constraint – Constraints are factors that limit options such as resources, budget, schedule, or scope. Constraints help teams clarify the “boundaries” that they must work within. At times teams utilize constraints inappropriately to define the project boundaries, and unnecessarily constrain the project delivery approach. Customers can view constraints as “excuses” for why it is not possible to meet customer expectations.
  6. Scope Creep – Honestly, this is not a term that I am too fond of myself. The project manager is ultimately responsible for project execution against the baseline. The project manager should be able to explain the evolution of that plan from the original baseline to the current plan, including all approved changes that have been implemented. Some project managers fall back on the excuse that the project is over budget or late because there were constant changes, but often cannot quickly explain the changes that account for the primary deviations from the original plan. Projects with too high a percentage of unexplained variances, is usually an indication of a project with inadequate attention to change control processes. In these cases, too many changes are “flying under the radar” and hence the use of the term “scope creep”.
  7. Baseline – Upon completion of the planning process, the team establishes project delivery expectations (scope, schedule, and budget) that are called the baseline plan. They execute against the baseline plan throughout the project life cycle. The baseline is utilized to measure the team’s ability to deliver against these expectations. In addition, the baseline is updated throughout the project life cycle based upon approved changes requests. Customers’ difficulty with the baseline is that it is not always clear when the baseline has been established (the transition from project planning to execution is not well defined or communicated). In addition, teams do not always do a good job maintaining the baseline plan, and information comparing current plans to baseline plans is not helpful or relevant.
  8. Change Request – The overall goal of change control is to prevent changes from overwhelming a project or taking the project unnecessarily off track. The goal of change control is NOT to prevent all change. Change control enables proactive identification and management of change, in a manner that keeps the project moving in the right direction, towards successful completion/delivery. Effective change control maintains the appropriate balance between control/discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. Customers respond negatively to change control when this balance is not consistently maintained (too many changes vs. too inflexible to respond to change).
  9. Risk – All projects have some level of uncertainty and unknowns, and therefore an element of risk. The risk management process represents a best practice area focused on predicting, planning for, and managing events that might occur during the project (positive or negative) that would have an impact on project plans. Customers are apprehensive about risk management because it tests their “intellectual honesty” in terms of what “could happen” during the project. In addition, mitigation action plans are not always viewed as having a “real” effect on the reducing probability or potential impact of the risk.
  10. Contingency – Contingencies and reserves are utilized to recognize and mitigate risk inherent in the project schedule and budget. In many cases the plans do not clear tie the contingency or reserve to the risk it is mitigating. In addition, teams do not always do a good job of recognizing what events or actions have driven consumption of all or a portion of the contingency or reserve. For these reasons customers will equate use of contingency and reserves to “sandbagging” or “padding” within the plans.

What should I do?

The obvious conclusion that some people would draw from this blog is that these are terms and processes that you should avoid with your team and customers. That is not the take-away that I would recommend. These are industry terms that demonstrate your knowledge and establish credibility in your role as a project management professional. Of course, this assumes these terms are applied in the right situation and context, and supported by the right actions and approach. However, these terms should be applied throughout the project life cycle with an awareness of the audience (from the perspective of both the understanding and perception of your customers). When appropriate, clarifications should be provided to explain the concept behind the term (particularly the first few times you use the terms). You should also be aware of overuse of specific terms that are particularly annoying to your customers or team members (usually due to the customer’s past experiences on projects). These suggestions will help, but the real power associated with effectively leveraging standard project management practices is demonstrating in a tangible manner how these concepts and processes drive positive project outcomes. When customers see success based upon a solid project management approach, they truly appreciate the value of your industry knowledge and expertise.

About Steve Hart
Practice Manager responsible for project leadership & delivery services for the Cardinal Solutions Group in the RTP area. I am a PMP with 25 years of project management and technical leadership roles, have developed an extensive practical knowledge that spans a wide variety of industries, and project delivery approaches. As a practicing PMP, I am a member of the North Carolina PMI chapter. I am an avid sports fan, particularly the Miami RedHawks, Cleveland Indians, Cleveland Browns, and most recently the NC State Wolfpack.

3 Responses to 10 Project Management Terms Customers Love to Hate

  1. Pingback: 10 Project Management Terms Customers Love to Hate « PMChat

  2. Paul Slater says:

    Hi Steve,

    Another great post.

    The one I’d add to your list is Critical Path. Project Management people know what it means and when we talk about it with clients they think they know what it means. Their interpretation is often a sequential list of all the important (in their eyes) things that they believe have to happen in a project. Trying to explain how a WBS is developed and float to them gets far too messy yet in my experience they persist in using the phrase to show others that they know all about Project Management. A nightmare!


    • Steve Hart says:

      I totally agree about the Critical Path. The other thing team members do not get is that the critical path will change throughout the project. That is why I usually use the crtical path as a tool for the PM, and not for general consumption by the team. It is much easier to translate the crtical path activities into “high priority” tasks for the team.

      Thanks for your contributions!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: