« The Project Game
Sources of Hidden Risks in the Projects »

10 Project Management Terms Customers Love to Hate

December 4, 2011 | Author: PM Hut | Filed under: Project Management Musings

10 Project Management Terms Customers Love to Hate
By Steve Hart

As I was starting to write an article on creating a well-organized WBS, I was reflecting on the fact that the WBS is a term/activity that customer’s 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 there “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.

Steve Hart, PMP is the Practice Manager responsible for project leadership & delivery services for the Cardinal Solutions Group in the RTP area. He has 25 years of project management and technical leadership roles, and has developed an extensive practical knowledge that spans a wide variety of industries, and project delivery approaches. Steve recently transferred to the North Carolina Chapter of PMI from the Dayton Ohio PMI Chapter, where he was active as the editor of the chapter newsletter, and PMP certification instructor. You can read more from Steve Hart on his blog.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Sunday, December 4th, 2011 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories