PM-Foundations – Managing the Creep

I have discussed on several occasions that “scope creep” is not a term that I am particularly fond of. The PMBOK® refers to project scope creep as uncontrolled changes. I have heard project managers say on more than one occasion, “My project is suffering from scope creep”. In my mind that statement translates into, “I have been unable to control change on my project”. One of the key responsibilities of the project manager is to identify and control change – in other words “managing the creep” on your project.

Team members often talk about the amount of change on the project. Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager effectively manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The other aspect of good change management is that the project manager effectively communicates the source and impact of project changes. The worst form of change on a project is the type that is not controlled and cannot be explained – it is the CREEP.

5 Tips to Managing Creep

1. Creep relates to all aspects of the project baseline – When most people talk about creep it is in the context of scope. In the context of scope, creep is the small features added throughout the project life cycle that in sum total can have a significant impact on cost, time and quality. Creep also relates to other the aspects of the project baseline – time and cost. In the context of time, creep is the deadlines missed by a day or two, or the activities that take a few hours longer than expected. In the context of cost, creep is the consulting rate that is a few dollars / hour higher than budgeted, the consultant that is required a few weeks longer than planned, or the software license costs that are a bit higher than anticipated. Any one of these examples could have an impact on overall project performance (what is delivered, when it is delivered, and how much it costs), and if it is not controlled and managed, it represents creep. If you are only focused on scope creep, you are only managing part of the overall CREEP in your project.

2. Establish rigor around creep in the planning process – The stronger the baseline plans, the easier it is to identify and manage creep throughout the remainder of the project life cycle. Is the scope well defined and organized in the form of work packages in the WBS? Are the work packages at the level that can be tracked throughout the project life cycle? Is the schedule constructed in a manner that reflects how the work will actually be completed? Are cost assumptions well documented within the project budget? In addition, the project management approach detailed within the Project Management Plan establishes processes and tools that will be utilized to directly or indirectly manage creep. Examples include:

  • Project metrics – How will project performance be measured?
  • Materiality – What represents significant variances that will trigger corrective actions? These variance targets can be expressed as days, hours, dollars, or a percent.
  • Change Control – What process will be utilized to manage change as it is identified?
  • Roles and Responsibility – Who has responsibility and accountability for deliverables or groups of deliverables?

3. Use project metrics to monitor and identify creep – It is important to monitor and understand key project metrics in a manner that helps identify potential (or real) changes as early as possible. These metrics help identify early warning signs for changes that may be “flying under the radar” – uncontrolled change = CREEP.

Some early warning signs include the following:

Schedule slippage

  • Tasks not started on-time
  • Tasks not completed on-time
  • Tasks with less progress than planned (particularly on larger effort or longer duration tasks)

Variance Trends (Cost / Schedule / Risk / Scope / Quality)

  • Consistent cost variance trends (overall or on specific cost types / categories)
  • Consistent schedule variance trends (overall or on specific project phases / milestones)
  • Actual work effort (or duration to complete) to complete tasks is consistently higher (or takes longer) than planned
  • New tasks or deliverables are identified throughout the project life cycle (pointing to gaps in the planning process)
  • Overall project risk (overall assessment of number, severity, and probability of risks)
  • Defects are identified at a higher than planned rate, or the closure rate is slower than planned

Open Risks and Issues

  • An increase in the number of risks and issues, particularly if they are focused in a specific project area, is a good indication of a potential change / adjustment required.
  • Issues that are not closed sometimes point to a project change that is required to close the issue.

4. Turn creep into change – A change represents a permanent deviation from this baseline plan. The term ‘permanent’ is important. It is possible that there is a deviation from the baseline plan that will be self-correcting and is really only a deviation due to timing (when something has occurred vs. when it was planned to occur). When a deviation is deemed to be permanent, it is identified as a potential change and is managed through change control process. Managing a potential change through the change control process moves it from an “uncontrolled change” to a “controlled change” – reducing the level of creep in your project. If several permanent deviations are below the materiality threshold, but in aggregate above the threshold, consider grouping them into a single change to move through the change control process. Again, it is important to strike a good balance between the discipline to control change and the flexibility to respond to changes in customer needs and expectations. The level of rigor and control around formalizing and approving changes should be “sized” appropriately to both the organization and the project. Some considerations include:

  • Project size, complexity, and risk profile are evaluated to adapt the change control processes to the project.
  • Projects that have significant schedule and/or cost constraints tend to require increased focus on change control processes.
  • Projects with higher visibility and strategic importance to the organization tend to have more structured change control processes.

5. Understand and communicate the cumulative impact of change – The project core team, project sponsor, and steering committee members should be aware of the cumulative impact of changes (comparing actual project performance to the original expectations established in the baseline plan). Project managers often will fall back on the excuse that the project is over budget or late because there were project changes, but they cannot quickly explain the changes that account for the primary deviations from the original plan. Reconciling the actual project performance (schedule & cost) to the original baseline plan helps understand the “unexplained” variances. An unexplained variance is the difference between the total schedule or cost variance and the approved project changes / impacts. A project with too high a percentage of unexplained variances is usually an indication of a project with inadequate attention to change control processes. These projects have too many changes that are “flying under the radar” – too much CREEP. Good projects managers can pretty precisely describe the difference between the original baseline and the actual results – strive to be a good project manager.

PM-Foundations – 10 Steps to Create a Strong Baseline Plan

When interviewing project management candidates, my favorite interview question is: “When you are assigned to a new client/project, what is the process you utilize to establish the baseline project plan?” Some candidates lose points immediately because they describe a process where the baseline plan is equal to the project schedule. Many candidates start out pretty strong talking about identifying stakeholders and defining business needs, and then get lost on a rambling dialog through the entire project life cycle.

I like this question so much because as a project manager you are introduced to new situations all the time (new clients and new projects), and it is extremely important to hit the ground running leading project teams through the planning process. Adapting a consistent planning approach from client to client, and project to project, significantly improves outcomes of the project planning process (both time to market and quality of the plans). Strong baseline plans represent the foundation for a successful project delivery process.

10 Steps to Create a Strong Baseline Plan

  1. Ramping-up – The first step is to learn everything you can about the new project. In most cases, you are not starting the project with a “blank piece of paper”. Take the time to read through existing project artifacts, and meet with interested parties. The focus of this step is absorbing everything you can about the new project, and understanding where you are starting from in the project initiation process. The key to this process is active listening and observing — it is amazing how much you can learn when you are not doing the talking.
  2. Understanding the Stakeholders & Forming the Team – The next area of focus is starting to identify the project stakeholders. Throughout this process you are trying to understand the people that have a strong interest in –or- impact on the project. This is the point in time when you begin to form a high performing core team and a helpful steering committee (you can read more in my blog on the core team).
  3. Developing the Business Case – As the project manager, you can be the strong partner that facilitates improvement and finalization of the business case (aka, the project charter). With your fresh and unbiased perspective on the project, you can add significant value by ensuring that the key components of the business case (e.g., objectives, benefits, assumptions, high level requirements) are explicit, understood, and achievable.
  4. Creating the WBS – The Work Breakdown Structure defines the scope of the project by breaking the work down into components that can be scheduled and estimated and easily monitored and controlled. A well-constructed WBS represents the most effective way to define and validate the scope of the project (what deliverables will be produced). The project manager’s role in this step is to facilitate the organization and decomposition of the work required to successfully deliver the project, in the form of the WBS.
  5. The Project Timeline – The focus of decomposition in the context of activity definition is identification of the specific actions / activities that will be required to create the deliverables that were defined within the WBS. The Project Manager also works with the team to establish the relationships between project activities. The key to creating a logical flow (organization) of work within the project schedule is the definition of these relationships/dependencies (you can read more in my blog about managing project dependencies). The final component of this step is the process of determining how long it will take (in days) to complete an activity, or a series of activities (duration estimation). At this point in time, the project schedule starts to reflect a timeline with project milestones. This timeline is utilized to validate the reasonableness of previously established target dates (or establish target dates if they do not already exist). It is important to keep in perspective that at this point in the process you are trying to arrive at a first cut of the project timeline, and not create the final project baseline (in the spirit of an iterative process) – you are looking for reasonableness, not perfection.
  6. Resourcing the Plan – The Project Manager builds on the project timeline by estimating resource requirements for each of the schedule activities, and loading specific resource assignments and work efforts into the project schedule. At this point in time the project manager will also perform resource usage analysis and leveling techniques, and create the project staffing plan (you can read more in my blog about performing resource analysis and creating the staffing plan).
  7. Finalizing the Project Schedule – After resources are loaded into the schedule, the project schedule is for the most part fully formed. At this point, it is best to perform a final review of the project schedule (individually as the project manager, and also with the core team). The goal of this review is to determine: 1) Can the team deliver with this schedule? Are there opportunities to improve the schedule? 2) Is the schedule well understood? Are all aspects of the schedule fully documented?
  8. Finalizing the Project Budget – The step of finalizing the project budget is focused on efficiently leveraging the planning assets created to this point in the process, and performing the appropriate level of analysis to develop a project budget that will be understood and approved by the client, and just as importantly can be managed throughout the project life cycle. This step includes creating the labor budget, understanding other cost components and reconciling the project budget with project funding (you can read more in my blog about creating the project budget).
  9. Finalizing the Baseline Plan – The step of presenting the baseline to the Steering Committee is one of the most exciting times in the project planning lifecycle. If you have tied up loose ends with key stakeholders, sponsors and core team members, you are well prepared to bring the project baseline (scope, timing, and budget) to the project executives for approval. This meeting/briefing represents a key gate for moving forward with the project.
  10. Transitioning to Project Execution – As a project manager, you often rely as heavily on your “soft skills” as a project leader, as you do on your core knowledge as a project manager. This is particularly true during the transition from project planning to execution. It is the time period when you are on-boarding the entire project team, and moving from “planning the work” to “doing the work”. As you make this transition, you must establish a good rhythm on the project team (you can read more in my blog about establishing project rhythm).

Where do I go from here?

These steps are not a detailed prescription or specific recipe for project success, but they do represent a proven approach to move a team effectively and efficiently through the project planning process – from the time you are assigned as the project manager, to the time you begin the execution phase of the project. If you are able to describe this approach during the on-boarding discussion with your new project sponsor, you are likely to begin to establish credibility as an experienced and competent project manager. In addition, if we do happen to cross paths in an interview situation, you now have the input required to get you through the initial screening process.

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.

%d bloggers like this: