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.

Advertisements

PM Foundations – The Change Control Process

I recently blogged about managing changes to your project this post discussed the definition of change, sources of change, early warning signs, the change control process, and measuring change. In this post I am going to focus in on the change control process. 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. The change control process 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 processes maintains the appropriate balance between control/discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. In the spirit of not overcomplicating the process, the basic steps associated with the change control process are pretty straightforward (depicted in the graphic below).

Identify Change

Changes may be identified while updating and evaluating schedule progress, performing project budget updates and analysis, assessing on-going project risks, performing quality control activities, and engaging with project stakeholders (e.g., project team, project sponsors) via normal project communication channels.

Here are some examples of how you may identify change in your project:

  • While comparing the work results to the plan (part of monitoring and controlling project work), you realize that testing activities are taking twice as much work effort to complete based on original estimates.
  • A risk is identified that a key resource will be taking a leave of absence during a critical month of the project.
  • You are updating the project budget and identify that consultant rates are consistently tracking 10-12% higher than originally planned.
  • You are managing a project for the introduction of a new product. The company finds out that a competitor is developing a similar new product, and something will need to be done in order to be competitive. This is brought up at a project sponsor update meeting, and requires follow-up actions.
  • During load testing, the team realizes that the technology architecture is unable to handle the necessary volume. This started as a project risk, and is now a project issue.

During the process of identifying the change, the project manager will refer to the guidelines established in the Project Management Plan to determine if this is a change that should be managed utilize through the formal project change control process. Factors such as the following are utilized to determine which changes should be formally documented and managed:

  • The impact of the change represents a permanent change to the project baseline (not a timing related change)
  • The change has a significant impact on the project baseline (above the materiality threshold established for the project)
  • The change represents something that is new or different than what was utilized to establish the baseline plan. Clarifications or more detailed definition of planning components (progressive elaboration) generally are not handled as project changes. This is a point that is often contentious from a customer relationship perspective.

Changes should be documented in detail using a project impact report (PIR) for each individual change. The project impact report should include the following information based on the assessment (at a minimum):

  • Change Header Information
    • Project Name
    • Project Impact Number (reference number assigned for the change)
    • Date (date the project impact report was created)
    • Project Manager
    • Project Sponsor (who is accountable for the project)
  • Description of change and how it impacts the project
    • Checkbox for areas impacted by the change (scope, schedule, cost, quality, risk)
    • Background (includes information like why or how the change was identified, reason for change, benefits of implementing change, and/or risks associated with not implementing change)
    • Impact Descriptions (description of how the change impacts each of the project areas identified as impacted in the checkbox)


All changes should be added to a change control log in order to track the status of the change. The change control log should include the following information (at a minimum):

  • Unique tracking # assigned on the project impact report
  • Title (one line summary description of the change)
  • Date Created (date the change was formalized utilizing the PIR)
  • Cost Impact – in dollars (quantification of the cost impact of the change)
  • Schedule Impact – in days (quantification of the schedule impact of the change)
  • Scope Impact (quantification of the scope impact of the change)
  • Status – indicate where the change is in the change control processes (Assess, Approval, Approved, Implemented, Complete, Rejected)
  • Status Comments – provide more details about the status and history moving through the change control processes

The change control log is the place that any project team member can go to see all of the changes that have been identified and the current status of all of those changes.


Assess Change

Once a change is identified, it needs to be assessed for impacts. The following dimensions of the project could be impacted: scope, schedule, cost, risk and quality.

  • Is the current baseline scope going to be impacted and how? Is the current baseline schedule going to be impacted? Is the current baseline budget going to be impacted? Is the agreed upon quality of deliverables and/ or product going to be impacted? Is the change going to impact the assessment of project risk?
  • The impacts could be positive or negative.
  • As the project manager, you are managing expectations. Establishing a baseline helps manage expectations among stakeholders and commitments to the customer/ end users. If that baseline will be impacted by a change, that needs to be examined.

It is important to quantify the impacts of a change. If the impacts are not clear, it is difficult to make an appropriate decision about whether or not to approve and implement a change to the project.

  • When possible, impacts should be quantified by indicating cost impacts in dollars, schedule impacts in work-days, resource impacts in hours effort, risk impact in terms of the risk assessment (before and after implementation of the change), and quality in terms of impact on open defects / issues.
  • For example, there is a change request to add functionality to a system, and development has already been started. The assessment should identify what activities are required to add that functionality, including the additional hours of work and cost of that labor, and the resulting schedule impacts of doing that work. When considering what activities are required to add the functionality, you have to consider the fact that the system requirements, system design, and test plan will all most likely need to be revised. Also consider any re-work that may have to be done for parts of the system that have already been developed. It may also be possible to quantify the increase in user satisfaction by adding the functionality to the system.

It is important to involve the appropriate project team members in describing and assessing the change so that impacts are accurately assessed and quantified. It is usually members of the core project team that assess changes. Each core project team members should be able to speak to the impacts specific to their area of expertise or their group. The impact of the change is documented on the project impact report:

  • Impact Estimate (quantification of how the change impacts each of the project areas, including the assumptions associated with the impact estimates)
    • Product Scope – Number of features changed / added
    • Project Scope – Number of deliverables changed / added
    • Schedule – Days impact on key milestones, hours impact on resource estimates
    • Cost – Dollar impact by cost category
    • Quality – Change in open defects / incidents
    • Risk – Change in risk severity or probability estimates

Approve Change

The Project Management Plan establishes the change review and approval process (you do not want to be in a position where the process is “invented” in response to the first change).

The following describes the key guidelines associated with review of changes:

  • Generally, projects establish a regular timing for submitting / reviewing changes (e.g., change control board meets every other Wed., and changes must be submitted by EOD Monday)
  • In addition, a process must be established to accommodate review/approval of “rush” changes. These are the changes that have a time constraint for associated with making a decision about the change and/or have an extremely high impact on the project.
  • At a minimum, the project impact report is submitted for review / approval. Some changes will require additional supporting documentation to better describe / explain the change or impact of the change. For higher priority or high impact changes, it is generally best to provide a face to face explanation.

The following describes the key guidelines associated with the approval process:

  • The core team (or select members of the core team) approve all changes. This confirms that the core team agrees with the assessment, and the implementation approach for the change.
  • The project sponsor or project steering committee approves changes that are over a specific impact threshold (e.g., two weeks, 40 hours, $2,500, new feature).
  • The customer’s environment (compliance requirements) generally establishes the process associated with documentation of the approval (email, collaboration tool, verbal, signed copy of the PIR).
  • The timing of the approval process is established to ensure that the impact does not become larger, due to delays in the approval process.

Note: The review / approval process should occur BEFORE the actual change has occurred, and the corrective action has been implemented. This allows the reviewers/approvers to make decisions associated with changes to the project, and the change implementation approach.


Implement Change

The same level of rigor is required to plan changes to the baseline plans, as were required to develop the baseline plan originally. This is an area that many teams fall short – they often behave like change is complete at the time it is approved (contrary to popular opinion, changes do not implement themselves).

In addition, it is important to adjust the planning artifacts to reflect the most current “version” of the plans:

  • Project Management Plan – Project description is updated to reflect adjustments to the product and/or project scope
  • Project Schedule – Deliverables, activities, dependencies, and milestones are updated to reflect the impact of the change on the project schedule. In addition, the schedule baseline is adjusted (using “set baseline” in MS Project) to reflect the impact of the approved change on the project timeline.
  • Project Budget – Planned and forecasted amounts are adjusted to reflect the impact of the approved change on the project budget
  • Risk Log – Risk ratings (probability and/or impact) are adjusted based upon approval and implementation of the change. In addition, the risk log is updated to reflect new risks introduced with implementation of the change.
  • Project files – Change control documents (project impact reports, and change control tracking summary) are maintained in the project files (e.g., team collaboration site)

Communication of the approved changes is an important element of effective change control:

  • All core team members and key stakeholders are aware of the approved change, and the impact of the change on the project baseline
  • Team members are on-board with adjustments to their assignments, based upon the implementation of the approved change

Follow-up

The final step in the change control process is to perform follow-up on the implementation of the change:

  • Verify that the action items identified to implement the change (documented on the project impact report) have been completed.
  • Based upon implementation of the follow-up actions, re-assess the impact of the change and adjust the impact estimates (if required).
  • Update the status of the change (on the change control summary log) to reflect that it has been fully implemented (and closed).


Change Control Best Practices

Be proactive. The cost of implementing change increases later in the project/ product lifecycle. Utilize key metrics to monitor trends and identify potential changes.

The level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

  • Project size (number activities, cost budget, number of resources), complexity (number and types of dependencies), and risk profile (number and distribution across project activities of high priority risks) are evaluated to adapt the change control processes to the project.
  • If changes often have very different impacts (e.g. much higher cost or schedule impacts) when they are implemented, maybe there is not enough rigor involved with the change analysis process.
  • Projects that place more importance on schedules and/ or cost constraints tend to require more control around analysis and approval processes.
  • Another consideration associated with change control processes is the visibility / strategic importance associated with the project

Provide visibility of the change request throughout the change control process to ensure that everyone involved with the project can easily find out the current status of any changes in the process, as well as the reasons for approving or rejecting specific changes.

Ensuring that the change is implemented appropriately is critical because all of the effort that goes into analyzing and making decisions does not matter if the change is not actually implemented fully and correctly.

  • There should be follow-up to confirm the implementation steps have been completed.
  • Actual results should be captured to the planned impact of the change

PM Foundations – Managing Change

In my experience as a project manager, I have found one of the most critical best practice areas during the project execution phase to be the ability to effectively manage change. 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. Nobody wants to be “that” project manager that leads a project that delivers on-time and under budget, but still has an unhappy customer. Below I describe in more detail the following aspects of managing change:

  • What defines a change in the context of your project
  • What are the sources of change
  • What are the early warning signs of change
  • Establishing a process to manage change
  • Measuring the cumulative impact of change

What Defines Change

By the end of the planning phase, the project baseline is established and approved by the project sponsor and project core team. Project scope, schedule, and cost are all part of the project baseline plan. 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).

  • Example of a timing deviation: A deliverable that was completed a week late because the sequence was switched with another deliverable.
  • Example of a permanent deviation: A deliverable that was completed a week late, because it took a week longer than anticipated to be completed (and that week cannot be recovered).

Change is identified and measured based upon the impact on the baseline plan:

  • Scope – Additions/reductions in scope can be either in terms of scope of the product or project – in both cases they change the deliverables articulated in the WBS.
  • Schedule – Planned timing of activities and/or deliverables. In most cases, changes to the schedule are only identified / managed if they impact the project end date or a major milestone.
  • Cost – Addition/reduction to the cost of the project (permanent variance of actual/projected costs vs. planned/budgeted costs)


The following guidelines associated with changes to the project are detailed in the Project Management Plan:

  • There is not one standard definition of a change. Change must be articulated in the context of the specifics of the project. It is important to distinguish between a change and a clarification of expectations.
  • Only changes that have material impacts to the baseline plan will be formalized and managed (the Project Management Plan defines materiality).
  • How the change is determined to be a permanent or timing project impact.

Sources of Change

During project execution, actual events will occur differently than planned, even with the best of plans. It is up to the project manager to proactively identify and manage potential sources of change, and adjust the project plan appropriately. The sources of change generally fall into the following categories:

Customer Needs / Requirements – Adding a product requirement is a common source of change.

  • Adding or changing a product requirement during the middle of development / build / test activities can have even more impacts because of re-work and impacts to other parts of the product.
  • Often the change represents more of a clarification of the original requirement, and not a change in the intent of the requirement. The clarification could still represent more or less work to be completed to satisfy the product requirement.

Technology

  • Implementation of new technology introduces a certain amount of risk / unknowns. During project execution these unknowns may introduce real changes in the work required to complete the implementation (e.g., hardware procurement and set-up, software configuration & customization).
  • An organization’s standard technology platforms may change. If the work required to comply with the new standards is not reflected in the plan, it often represents a change to the project.

Planned vs. Actual Execution – The most common source of change is simply that work is completed in a different manner than originally estimated and planned. The following are more specific examples of this source of change.

  • Inaccurate estimates – Activities take more or less time than was estimated. This is more likely to occur if this type of work had not been done previously by the company or by the resources providing estimates.
  • Change in resources – The skill set associated with the resource completing the work is different that the skill set the estimates were based upon. Changes in resources in the middle of the project introduce factors like ramp-up time, the skill level of the new resource, availability of the new resource, the billing rate of the new resource.
  • Change in deliverables / activities – The addition of or removal of deliverables from the WBS can impact timelines, costs, and quality (e.g. adding training materials). Also, there could just be a process / methodology change that requires new tasks or a change to a task even though there is not a new deliverable. For example, if quality standards change, that could increase the time it takes to perform some tasks.
  • Sequence of work completed (project dependencies) – New or different project dependencies are identified during the project execution that could permanent delays in subsequent activities / milestones.

External Influences – Factors outside the control of the project team often drive changes to the project. Examples of this include:

  • Changes in regulatory or other compliance requirements
  • Changes in other systems / environments that impact the current project
  • Changes in dependent projects
  • Changes in the business environment or economy (e.g., introducing new funding constraints)
  • Reorganizations that drive changes in team members or key stakeholders (this would never happen, right?)

Early Warning Signs

In addition to understanding the potential sources of change for your project, it is also important to understand and monitor key project metrics that help identify potential (or real changes) early on (early warning signs). It is fairly intuitive that the further the project is in the project life cycle the more costly and impactful the change is to the project.


Some early warning signs of change 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

Change Control Process

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.

The following represent the key processes involved in managing changes to the project:

  1. Identify Change: Either the project manager identifies, or is made aware of a change. Based upon guidelines established in the Project Management Plan (permanent vs. timing, and materiality), the project manager determines whether or not the change should be formalized and assessed.
  2. Assess the Impact: Once the change is identified and it is determined the team needs to assess the impact of the change on the project, the assessment is documented, using a change control tool (i.e., a project impact report).
  3. Review and Approval: Once information about the impacts of the change have been documented, the change should be reviewed by a Change Control Board and either approved or rejected.
  4. Implementation and Verification: Planning and execution of the actions required to implement the change. Implementation includes adjustment to planning artifacts to accurately reflect the new scope, schedule, and budget based upon approved change. Implementation of the change effectively establishes a new baseline for the project.
  5. Follow-up Verification: Perform a follow-up review to confirm that the appropriate actions were completed to implement the change (corrective actions), and that the change had the anticipated impact on the project (time, cost, scope, quality, risk).

Remember that change is inevitable and oftentimes necessary. However, it is important to control change so that changes are properly assessed and only approved changes are implemented within the project.

Assessing the Cumulative Impact of Change

It is important to understand the cumulative impact of changes on a project with regards to the scope, schedule, and cost/ budget. Throughout the life of a project, there will be changes. 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).

The project manager is ultimately responsible for project execution against the baseline plans. The project manager should be able to explain the evolution of that plan from the original baseline to the current baseline, including all approved changes that have been implemented. 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. Effective use of the change control log (see my blog post on Using SharePoint to Manage Change Requests) provides a tool to track and reconcile changes to the baseline schedule and budget.

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”. I am a not a big fan of the term “scope creep” because it represents an excuse vs. an explanation. Good projects managers can pretty precisely describe the difference between the original baseline and the actual results – strive to be a good project manager.

Characteristics of Effective Change Control

Be proactive. The cost of implementing change increases later in the project lifecycle. Utilize project metrics to monitor trends and identify potential changes.

The level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

  • Project size, complexity, and risk profile are evaluated to adapt the change control processes to the project.
  • If changes have different impacts when they are implemented (higher actual cost or schedule impact), maybe there is not enough rigor involved with the change analysis process.
  • Projects that place more importance on schedules and/or cost constraints tend to require more control around analysis and approval processes.
  • Another consideration associated with change control processes is the visibility / strategic importance associated with the project.

Provide visibility of the change request throughout the change control process. This ensures that everyone involved with the project can easily find out the current status of any changes in the process, as well as the reasons for approving or rejecting specific changes.

Focus on the making sure the change gets appropriately implemented. Project teams often spend all of their time and energy on analysis and approval, and forget to adjust project deliverables to reflect the change.

  • Follow-up to confirm the implementation steps have been completed.
  • Compare the actual impact on the cost and schedule to the estimated project impact.

Using SharePoint to Manage Project Changes & Impacts

One of my favorite questions when interviewing potential project management candidates is, “How do you manage change to your baseline plans.” First of all, many candidates fall into the trap of thinking baseline plans is the same thing as the schedule. Others think that change relates to customers adding features and functions to the product. The easiest way to describe change from a project perspective, is change represents anything that is a permanent (vs. timing) deviation from the original plans that define what is going to be delivered (scope), when it will be delivered (schedule), and how much it will cost (budget).

Using collaboration tools, such as SharePoint, to manage change does not replace the diligence required to identify and manage project impacts effectively, but it does streamline the processes associated with documenting, reviewing and approving the change requests. In addition, SharePoint enhances the ability to effectively communicate project changes throughout the project life cycle.

Creating the Change Request Log

I find it easiest to use a Custom list to create the Change Request Log in SharePoint. The following are the fields I add to this list to improve the identification and tracking of change requests based upon the best practices associated with Project Change Management:

  • Id – System assigned unique identifier assigned for the change.
  • Title – Headline associated with the change request (make sure it is descriptive enough to identify the item from the summary view of the change requests).
  • Status – Drop down selection: Not Started, Documented, Reviewed, Approved, or Implemented.
  • Cost Impact – Numeric field for the estimated impact the change request will have on the project budget.
  • Schedule Impact – Numeric field for the estimated impact the change request will have on the project schedule.
  • Scope Impact – Text field utilized to describe the impact the change request will have on the scope of the project.
  • Comments – Text field utilized to describe the current status of the change request.
  • Attachments – The change request should be supported with more details explaining the request and estimated impacts. A completed project impact document is attached to the change request item.

Below is an example of the Change Request form in SharePoint, and the Project Impact Report template.

cr-input form

cr-project impact report

Managing the Approval Process Using Workflow

Creating workflow for this SharePoint list helps automate the approval and tracking process. At the time the item is added to the SharePoint list, an email is sent to the approver (see below for an example of the email).

cr-email

From this email, the approver can Approve, Request a Change, Reassign, or Reject the change request (see an example of the approval pop-up that is displayed within Outlook).

cr-approval popup

Once the approver performs the approval process, the status of the workflow is updated within the SharePoint list (see the Change Request Workflow column of the All Items view below).

cr-all items

I find it is best to keep the workflow straightforward, with no more than 2-3 approval levels. The benefits associated with approval automation can be lost in time spent on manual intervention if the workflow is too complicated.

Cumulative Impact of Change

It is important to understand the cumulative impact of changes on a project with regards to the scope, schedule, and cost/ budget. Throughout the life of a project, there will be changes. The project core team, project sponsor, and steering committee members should be aware of the cumulative impact of changes (comparing current project performance to the original expectations established in the baseline plan).

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 baseline, including all approved changes that have been implemented. Project managers often will 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. Effective use of the Change Request Log provides a tool to track and reconcile changes to the baseline plan (and provide as a regular project performance metric).

I create another view within the Change Request list to communicate the cumulative impact of change on the project. This new view filters for only approved or implemented requests, provides a total count of approved/implemented requests, and sums the total schedule and cost impacts. Below is an example of the approved requests view of the change requests.

cr-approved view

Summary

SharePoint provides a great vehicle to capture and track change requests in a timely and accurate manner. In addition, adding workflow to the SharePoint list automates the change review and approval processes. The information captured within this list allows the project manager to communicate effectively around the team’s ability to manage change and accurately describe the cumulative impact of this change on the project.