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.


  • 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.

PM Foundations – Performing Resource Analysis & Creating the Resource Plan

In a previous blog post, I talked about resource loading your project schedule (estimating the resource needs, and loading resource estimates into your project schedule). Before you call your project schedule “complete”, it is a best practice to perform resource analysis & leveling, and create the resource plan. The resource plan is utilized to confirm the project resource assignments with resource managers, and it is a direct input to creating the labor component of the project budget.

Again the best practices areas associated with resource planning are:

  • How to estimate the resource requirements for schedule activities
  • How to load the resource assignments and work effort estimates into the project schedule
  • How to perform resource usage analysis, and resource leveling techniques
  • How to create the resource plan utilized to finalize resource assignments, and provide a key input to create the project budget

This blog post is focused on the last two – performing resource analysis & creating the resource plan

Resource Analysis & Leveling

The first decision to make when performing resource analysis is what is the proper time period to use for resource usage optimization. In other words, is it at the level of days, weeks or months that you need to make sure you have the right resources assigned to support planned project activities. For projects 3 months or greater, I find that it is most appropriate to perform resource analysis and leveling to the “month level” of precision. Attempting to level resources to a more granular level is not necessary to create a “workable” project schedule.

To start the resource analysis process, access the Resource View in your project management tool, and change the timescale to “months”. This view provides the number of planned hours for a resource for each month. Based upon this information, and the percentage each resource is allocated to the project, you have the information required to identify months in which resources are under or over allocated to project activities. Just because a resource (or a month) is highlighted in RED does not mean you have a resource usage problem. It may just mean that a day or week is over allocated, and that does not necessarily represent a problem that requires adjustments to the schedule.

The following represents the best practices for resolving resource issues:

  • Look at the detail activities within the resource usage view for the period that is over or under loaded in the schedule
  • Challenge the resource hours (or resource % allocations) on specific activities
  • Look for opportunities to assign other resources
  • Look for opportunities to move activities up or back (pay attention to how resources are loaded in preceding and subsequent periods). Use dependencies to move the activities around (you are changing the soft dependency logic to level the resource loading).

Below is an example of the resource usage summary and detail views utilized to analyze and level resources.

Before making adjustments to the project schedule, it is recommended to save a “back-up” version of the project schedule (in case you do not like the results of the adjustments). Make the appropriate changes, and then review the impact on resource usage and key milestone dates. Based upon the impact of the changes, you may need to challenge specific assumptions to improve the milestone dates (e.g., durations, dependencies, resource availability).

Note: I do not recommend using the “Level Resources” function within the project management tool to perform resource leveling. This function attempts to automate the decision making process described above (with the default of moving dates based upon resource availability). Reworking the result of this automated process is generally more work (not to mention more frustrating) than manually reviewing and adjusting the schedule.

The Resource Graph (below) is another tool available within the project management tool that provides an excellent summary of resource utilization for each resource. This view provides a quick preview of the impact of schedule adjustments on resource utilization. It is also a valuable way to demonstrate the impact of alternative schedule solutions (“what if” scenarios) on resource utilization. Snapshots of this view are often utilized within core team or sponsor review sessions to communicate resourcing opportunities or challenges within the project schedule. Make sure you are solving resource issues based upon the “materiality threshold” established in the schedule management plan. Things are going to change throughout the project life cycle, therefore you are trying to get the resources leveled to a reasonable level – your goal is to arrive at a reasonable schedule (not the perfect schedule).

Creating the Resource Plan

Once you are satisfied with the reasonableness of the project schedule (timing of both key milestones and resource utilization), it is time to create a first cut of the resource plan. The resource plan provides a summary of the resource hours required to complete the project. The resource plan is used for the following:

  1. Confirm resource allocations with resource providers
  2. Key input to the labor component of the project budget

Steps to create the resource plan:

  1. Create a list of the resources, sorted / grouped appropriately (e.g., by type of resource, internal vs. external) within the resource plan worksheet.
  2. Cut and paste in the hours from the resource usage view (in the project management tool) into the spreadsheet.
  3. “Adjust” the project hours to add in indirect project hours (activities that are not helpful to load directly into the project schedule). The hours for each resource in the Resource Plan should be compared to what is going to be “charged” to the project (% the resource is allocated to the project each month).
  4. Review the plan for reasonableness. Reconcile/resolve significant differences between the Resource Plan and the Resource Usage view from your project schedule.

Note: The resource plan represents a worksheet built into the Project Budget Workbook. This approach enables pointing calculations directly to the planned hours in the resource plan to drive cost estimates on the labor budget worksheet. A copy of the Project Budget workbook is available within the Templates page on


Resource Planning Best Practices

In summary, the following are the best practices associated with the resource planning processes:

  • Do not add “noise” into the schedule by attempting to account for all hours expended on the project (activities in the project schedule should be limited to “direct” project activities). The hours reflected in the resource plan can be adjusted (generally increased) to account for indirect project hours. The resource plan should represent the hours that will be “charged” to the project by each resource (vs. the direct project activities planned in the project schedule for each resource).
  • Do not attempt to over-engineer the resource leveling process. The objective of the resource leveling process is to “smooth” the resource usage reflected in the project schedule, reducing the over and under allocation situations. Change is inevitable throughout the project life cycle, therefore your goal is to create a project schedule that can be effectively monitored and managed throughout the execution phase of the project – reasonableness, not perfection.
  • Plan to the appropriate time windows. Understanding the resource usage on a monthly basis is normally good enough to create a “workable” project schedule. In the context of this blog post, the term “workable” means a schedule that supports a timeline and budget that is understandable and defensible.

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).


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


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.

Using SharePoint to Manage Risks & Issues

One of the most straightforward applications of project management best practices using SharePoint relates to managing risks and issues. Maintaining a Risk & Issues Tracking list within your project team site improves the structure and accessibility associated with this important best practice area. This is a huge improvement over the “offline” tracking Excel spreadsheet that is reviewed and updated on a semi-regular basis only by the project manager.

Creating the Risk & Issue Tracking Log in SharePoint

I find that the Issue Tracking type list is a great starting point for creating the Risk & Issue Tracking Log in SharePoint. The following are the standard fields associated with this type of list that I leverage to create the Risk and Issue tracking tool:

  • Id – System assigned unique identifier for the risk or issue.
  • Title – Headline associated with the risk/issue.
  • Description – More details about the risk/issue (background and source of the risk/issue).
  • Category – Tailor this field to capture the risk/issue categories associated with your project. In most cases, this field is used to group the risks/issues by type/source of risk or functional areas.
  • Priority (Magnitude) – Used to capture the magnitude of the impact of the risk or issue on the project. I tailor this field to be a choice between 9 (high impact), 3 (medium impact), and 1 (low impact). Assigning a numeric value enables calculation of the overall risk/issue ranking. The values 9, 3, and 1 provides separation between the higher impact risks/issues and medium & low impact risks/issues.
  • Assigned to (Owner) – The team member that owns management of the risk approach or issue resolution.
  • Due Date (Target date) – Represents the target date for the resolution of an issue. The date assigned for a risk is generally when the potential event is anticipated to occur and needs to be proactively managed.
  • Status – Tailor this field to capture the current status of the risk or issue. Try not to overcomplicate the status – something like Active, Resolved, and Closed is adequate to communicate the status of a risk/issue.
  • Comments – Utilized to explain the current status of the risk or issue.

The following metadata is added to this list to improve the tracking of risks and issues based upon the best practices associated with Risk and Issue Management:

  • Risk or Issue – A selection of Risk or Issue. This field provides the capability to maintain risks and issues in the same list. If a Risk turns into an Issue, you just need to update this field (vs. re-enter it into another list).
  • Project Impact – A multiple line text field that is set-up to explain the impact of the risk or issue on the project (schedule, scope, budget, quality). This description helps explain the magnitude ranking assigned to the risk/issue.
  • Probability – Used to estimate the probability of the risk occurring. Similar to the magnitude field, I set-up this field to be a choice between 9 (high probability), 3 (medium probability), and 1 (low probability). A value of 9 is assigned for issues (the event has already occurred). Assigning a numeric value enables calculation of the overall risk/issue ranking. The values 9, 3, and 1 provides separation between the most risks/issues and medium/low risks.
  • Risk ranking – The risk ranking is set-up as a calculated field to establish the overall risk/issue ranking based upon a combination of the magnitude and probability of the risk (magnitude x probability). An “81” risk/issue represents a high impact and high probability item that triggers more focus and attention from the team.
  • Risk approach – The planned risk management approach. This field is set-up with an option of Mitigate, Avoid, or Accept.

Below is an example of the “All Items” view of the Risk and Issue Tracking Log list in SharePoint.


Creating Views

Once the list is set-up and populated with data, multiple views can be created to communicate more effectively with different audiences. If you are talking to your core team, you will pull up the Active Risks or Issues, and filter on different categories. If you are preparing your status report or communicating with your project sponsor, you will use the High Impact Risks or Issues views. Individuals on the team will l focus on the risks or issues that they own, using the My Issues view. Below is an example of different views created for the Risk and Issues Tracking Log.





Exporting to Excel

I am not an advocate of pulling the issues “offline” into Excel for communication purposes. It is best to provide your stakeholders access to the view that gives them the relevant information based upon their needs. However, on larger projects with significant amounts of data, it is helpful to be able to export the list into Excel to perform additional analysis (e.g. creating charts that depict risk/issue related trends). Below is an example of the risk and issue tracking log exported into Excel.



Diligence around resolving issues and reducing the probability or impact of potential risks is a key PM best practice, particularly during the execution phase of the project. Use of SharePoint to manage risks and issues enables a more structured and accessible process, creating a project environment that encourages and facilitates timely identification and resolution or mitigation of risks and issues. In addition, it provides a strong tool to deliver targeted communication to key stakeholders. Teams that most effectively manage risks and issues are the teams that avoid major surprises and set-backs throughout the project life cycle.

PM Foundations–The Core Team

At the heart of most successful projects you will find an effective core team that is fully responsible for the day-to-day leadership of the project. This is not to be confused with the strategic level guidance that represents the key function of the project steering committee. The project manager is responsible for ensuring that the core team is effectively selected, on-boarded, and fully engaged throughout the project life cycle.

What is the purpose of the core team?

The practical answer is that the core team is responsible for monitoring the progress of each of the key deliverables and making decisions about course corrections should the project begin tracking behind schedule, over budget or if major scope changes occur.

What are the important elements of a good core team?

A good core team is comprised of the key stakeholders who are empowered to represent a segment of the overall project domain (the segment is generally defined based upon an organization or competency/function they represent). Representing this segment means that the core team member is responsible for providing knowledge from their area of expertise, and making/influencing decisions that impact this area of expertise. Several key factors influence the process of identifying the core team:

  • Diversity: Diversity is a key element of the core team, because it is critical that different perspectives about the project and the project deliverables are fairly represented on the core project leadership team. These perspectives should be represented from day one of the core team — many project managers are tempted to exclude groups from the core team until they are needed to perform specific project activities.
  • Inclusiveness vs. effectiveness: The core team is not the entire project team working on different project activities. Sizing the core team appropriately is critical to the successful management of the project. As the project manager you need to strike a balance between including the right people in the day-to-day management of the project, and creating a team that is too big to effectively make decisions. Based upon my experience the appropriate core team size is somewhere between 6-10 people.
  • Assessing the Organization: The type of organization you are working in significantly influences the manner in which the core team is formed (depicted in the chart below). In a functional organizational, it is generally the functional leads that represent their area/department on the core team. In a matrix and project organization, the core team is generally formed based upon the role of the people assigned to the project. The type of organization also impacts the project manager’s role and authority on the project (from limited in a functional organization, to full control in a project organization).


Procuring the Core Team Members

The factors described above represent key considerations when performing the following steps to select the core team:

  1. Determine which roles should be included on the core team. I find the most effective method is to look for the roles on the RACI chart with the most significant R’s (Responsible).
  2. Decide what project team members can fulfill these roles, If the team has not been formed, the question becomes what people in the organization can fulfill these roles.
  3. Determine if the composition of the core team needs to be adjusted based upon disconnects between the roles on the core team and the names assigned to the team.

The following chart provides an example of assembling a core team, based upon ownership of the key project deliverables. Ownership does not necessarily represent the person that will complete or manage the deliverable, but rather the person that will be responsible for the deliverable. Responsible means that this is the role that will ensure that the quality, scope, timing and cost of the deliverable are satisfied based upon the expectations established in the baseline project plan. Key deliverables which do not have an explicit owner established on the core team generally represents a RED flag (project risk), because the project manager will likely be required to manage these deliverables outside of the project leadership team as a “one off” process.


You will find that multiple people may be required to fulfill specific roles, if one person cannot adequately represent the full scope of the deliverable on the core team. In addition, specific roles may be filled by consultants or third party partners.

Getting stakeholders, functional managers and other resource managers to agree to loan you the right resources for your core team can be a challenge. Having a solid project management plan with high level milestones and roles/responsibilities, Project Sponsor support for the initiative, and clear definition of the deliverables (in the form of a WBS) to reference during the discussion with the resource managers makes this process much easier. When assembling the core team it is important to interact with the potential core team members to understand how well they understand the project – and how they feel about the business case (benefits, scope, target dates). It is a bonus to obtain resources that are passionate about some aspect of the initiative (benefits to their organization, learning opportunities for them, team dynamics).

On-boarding the core team

Prior to the overall project kick-off, the core team is assembled for a planning meeting (or series of planning meetings, depending on the complexity of the project). The planning meeting helps level set the core team on project planning efforts that have been completed to date (prior to them joining the team), and launching the efforts to complete the remaining planning activities/deliverables. The Project Manager facilitates the discussion on project planning deliverables completed to-date (project charter, milestones/target dates, scope statement, RACI, and the Project Management Plan). Making sure everyone is clear about what their role on the project is one of the essential topics at this point in forming the core team.

The Core Team planning meeting is best structured in the following manner:

Goals and objectives

  • Communicate information about the project using project artifacts created to-date
  • Establish a common understanding of roles and responsibilities
  • Begin the process of completing the remaining planning deliverables

Activities / Discussion Topics

  • Icebreakers and introductions (particularly important for new projects, with a diverse cross-functional team)
  • Review of project deliverables (best to provide access to these deliverables in advance of the meeting, so this time is spent productively covering questions and open issues)
  • Establish core team priorities and begin working on the remaining planning deliverables

Core Team Best Practices

The following summarizes the best practices associated with selecting, procuring, and on-boarding your core project team:

Purposefully select the core team

  • The team’s diversity in terms of backgrounds, perspectives and talents significantly improves project outcomes.
  • Right-size the team to accomplish the task at hand – manage the day-to-day project operations. Make sure the team can adequately “own” the project deliverables, but is not too large to effectively manage team dynamics.
  • The core team should be formed in a manner that is consistent with the organization that is driving the project.

Work with the right people to procure the right team members

  • Clearly communicate with resource managers (about the project and resource needs).
  • Use the project sponsor appropriately to gain support of the initiative.
  • Obtain buy-in of the potential core team members (to understand their commitment to the initiative, and comfort with their role).

Make the effort to adequately on-board and ramp-up the core team

  • Spend time “forming” the team.
  • Clearly communicate the plans completed to-date. You want the core team to “own” the plans, even if they were not involved in making all of the decisions or creating all of the planning deliverables.
  • Focus on getting immediate traction on the work ahead. Quickly align the core team with the project priorities, and ownership of next steps.

PM Foundations – Project Closure

Here a few thoughts about a best practice area that is often minimized or entirely overlooked – project closure. At the end of a project, many project managers are hurriedly preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization.

Project closure starts with effectively shutting down project activities, validating all product deliverables are complete & key product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within operational functions). The PMBOK refers to this process as contract closure.

The second best practice area is gathering customer input about the project, and facilitating lessons learned. There are a lot of good resources available for gathering customer feedback for project work, and the easiest way to evaluate the quality of this data is to ask two questions of yourself and the project team:

  • Is this information actionable?
  • How likely will the organization do something with this information?

Although I place a high value on customer input and recommended next steps, the true sign of a well run project is demonstrated in the final project performance report (also referred to as the Post Project Assessment):

  • How well can you reconcile actual delivery dates to original baseline dates?
  • How well are budget variances explained through approved corrective actions?
  • Are project quality metrics well articulated?

The critical success factors of a solid project performance close-out are creating a strong and well understood project baseline, and diligently managing to the baseline throughout the project life cycle. Assuming these processes are performed properly, the final project performance report represents a summarization vs. data compilation & analysis effort.

PM Foundations–Establishing Project Rhythm

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. This rhythm involves three important elements of effective project execution:

  • Teamwork – People on the project are working together to accomplish a common goal.
  • Cadence – Work is getting done on-time, and in the sequence that it should.
  • Communication – People are informed and engaged at the right time about relevant topics.

If the foundation for these three elements of project execution is created during this transition period, when the unexpected occurs on a project, the project team will be equipped to respond appropriately and continue moving the project in the right direction.

Why is project rhythm so important?

The project team works more efficiently and effectively with a common understanding of the goals and the plan to “get there”.

  • Team members are more likely to be well-informed, and actively participate in decision making when strong communication and collaboration processes and tools are established.
  • Team dynamics & satisfaction are improved on a team that understands what progress looks like.
  • Bottom line: Good project rhythm improves project delivery outcomes.

How is project rhythm established?

1. Ensure the team understands the baseline plan

  • Communicate the plan in a manner that everyone hears the key messages (scope, schedule, constraints, assumptions, risks /issues).
  • Find ways to reinforce the messages (team meetings, one on one interactions, collaboration tools).
  • Ensure that the plan “lives”, and is an on-going point of reference for the team.


2. Establish the appropriate communication vehicles

  • Establish regular project team meetings (communication & engagement “across” the project team).
  • Conduct timely project sponsor updates (communication & engagement “up” to the project sponsors).
  • Distribute meaningful project status reports (see my last blog for a more detailed discussion of this best practice area).
  • Implement tools and processes for project team collaboration (a central location for the team to reference and collaborate for project work).


    3. Capture & report project progress in a timely manner

          • Establish progress update processes that meet the needs of the team (dependent on the size and complexity of the project team).
        • Ensure that the progress update process is linked to (or integrated with) other project related processes (time reporting, team meetings, status reporting).
        • Upon completion of each project progress update, review/analyze the project data with the team to determine:

                  – Why are tasks behind plan?

                  – Are corrective actions required?

                  – Are adjustments to the plan appropriate?


    Performed well, the project manager facilitates creating the project rhythm during the project planning to execution transition without the team even noticing. As the transition is complete, and project work is underway, the project rhythm enables the team to quickly gain momentum, reduce overall project risk, and move down the path to successfully deliver on the goals of the project.

    PM Foundations–Project Status Reporting

    For those familiar with the movie classic that pokes fun at the workplace, Office Space, you probably remember the scene where that boss repeatedly nags his subordinate about the importance of a cover page on the TPS reports. This exchange between the boss and subordinate highlights that status reporting is a management mandated activity that does very little in terms of getting actual work done.

    Unfortunately, many project teams maintain this same attitude when it comes to project status reporting. This project management purist views project status reporting as an integral component of effective project communications and reporting (no surprise there). In fact, I would go so far as to say it represents one of a handful of best practice areas that ensures success throughout the execution phase of the project life cycle.

    Nobody reads it, why do it?

    1. Facilitates communications – This is the obvious reason – The project status report establishes a consistent and timely vehicle for fact based reporting about the project that can be consumed in a meaningful manner by all stakeholders (core team members, project sponsors, and other interested parties).

    2. Establishes a rhythm for project performance analysis – It ensures that on a regular basis the project manager performs analysis on what has been accomplished, how is the team performing, and what corrective actions need to be implemented (to resolve problems, or mitigate risk).

    3. Maintains focus on the project team – It highlights where the team needs to focus to correct problems or maintain the progress required to meet or exceed customer expectations.

    Best Practices

    From my experience, the best practices associated with effective project status reporting are in the following areas:

    • Format: How is the information presented to communicate the desired message(s) to the different groups of stakeholders
    • Project Metrics: What are the metrics regularly generated and reported to accurately communicate the current and forecasted status of the project
    • Timing: What is the appropriate frequency of reporting status information (timely enough to be proactive, without becoming burdensome to the project manager and/or team)
    • Re-enforce the message: What additional vehicles must be in place to make certain that the important message(s) are understood, and the required corrective actions are initiated

    Format: As a consultant, I usually walk into a situation where a project status report format already exists. Rather than irritating the customer by suggesting that the current status report is not adequate, I normally look for subtle ways to enhance the information presented. The goal is to ensure that the status report draws attention to the key information that is required to inform or initiate action. Some of the important elements of the status report include:

    • Project header information – Re-enforcement of the overall project scope/goals, and key stakeholders
    • Overall status – Often expressed as a color (Green/Yellow/Red) with some comments about why the overall status is what it is
    • Accomplishments – Highlights progress in the current reporting period (make sure that the key messages are not lost in too much detail)
    • Risks & Issues – Escalates the “top 3” risks & issues, including the corrective or mitigation actions
    • Upcoming milestones – Focuses on the important milestones, including planned vs. forecasted completion

      My general guideline is that a status report should not exceed two pages – if it does, stakeholders are likely to miss some, if not all, of the key messages.

    Metrics: Project metrics are the primary ingredient of the status report that creates fact based information on a regular basis. These metrics must be generated directly from the project management artifacts that are utilized to manage the project on a day-to-day basis (project schedule, project budget, risk register, change control logs). Because these metrics are created from existing project management tools, there should not be significant effort associated with updating them.

    Based upon my experience, the key project metrics presented on the status report fall into one of the following categories:

    • Time – Comparison of the planned vs. actual or forecasted completion dates
    • Effort & Cost – Comparison of the planned vs. actual or forecasted effort / cost to progress to this point in the project (this is where earned value is a useful tool)
    • Scope – Comparison of planned vs. actual scope of deliverables completed to-date (summary of scope changes)
    • Risk – Assessment of the level of risks identified or realized (compared to the initial risk assessment)

    Timing: The most important element related to the timing of the project status report is establishing and maintaining strict adherence to a consistent reporting interval (e.g., every other week) and delivery schedule (e.g., by end of day on Monday). This ensures that the stakeholders know when to expect (or look for) the status report. From my experience, implementation of either weekly or bi-weekly status reporting most effectively meets the needs of both the project manager, and key stakeholders, without creating too much project overhead. Specific sections of the status report may be provided on a less frequent basis (e.g., budget information may be updated on a monthly vs. bi-weekly basis).

    Re-enforcement of the message: Project managers often fall into the trap of assuming that distribution of the status report is enough to ensure that the key messages are well understood, and the appropriate next steps are completed. The distribution of the project status report needs to be directly connected to other regular team communication events (core team meetings, project sponsor / steering committee meetings) to confirm understanding of the current and forecasted status, escalate issues / risks, and initiate corrective actions.

    Delivering the Right Information to the Right People


    In summary, the project status report should not be created with the view that it satisfies a requirement mandated by management, but rather a best practice that creates significant value for you, as the project manager, the core project team, and other stakeholders. Effective use of the project status report is one of the clear indicators that the project is “under control” during the execution phase of the project. On top of that, there will be no need for this conversation: “Hi, Peter. What’s happening? We need to talk about your TPS reports.”

    PM Foundations – Creating a Meaningful Project Budget

    As a person who had both project and cost center budgeting responsibilities for many years, I must admit this was an effort that I did not necessarily enjoy and usually procrastinated (much like those of us that procrastinate filing our taxes). Ironically, now that I am on the other side of the fence as a consultant, I work very hard to establish the credibility and trust of my client that is required to be assigned responsibility for the project budget.

    Best practices associated with the project budget are focused on efficiently leveraging the planning assets created to that 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. Therefore, the best practices shared in this column represent areas that should be considered during the project budgeting process, not a step by step instruction on creating and maintaining a project budget.

    The following represent the best practice topics discussed in this column:

    • Efficiently creating the labor budget for your project
    • Other cost considerations
    • Project budget vs. funding

    The Labor Budget:

    Within the world of IT projects, labor generally represents the largest and most complex component of the overall project budget. The important concept associated with the labor budget is to ensure that other planning artifacts are utilized to efficiently create the labor budget. This approach significantly streamlines the development of the labor budget, and most importantly it ensures that the project budget is defensible when compared to the project schedule and resource / staffing plan.


    The resource usage view of the project schedule is utilized to create the staffing plan. The staffing plan depicts the full-time equivalent resources (or resource hours) per planning period. The resource quantities are imported into the labor budget and translated into dollars per planning period. The following represent the key elements of the labor budget:

    • Grouping of resources – Understanding of costs by type of resource helps articulate the key cost drivers within the labor budget.
    • Breakdown between internal and external costs – Clients generally place more emphasis on external costs, because these costs are incremental to their business (these costs would not be incurred if the project was not completed).
    • Timing of costs – It is important to summarize the costs by time period, because timing of project costs will be required for financial budgeting and reporting purposes.

    Other Project Budgeting Considerations:

    The following represent the other areas to consider when completing the development of the project budget. These areas are discussed with your client to understand the appropriate approach, based upon the client’s environment and organizational assets (e.g. financial reporting policies, procedures and tools).

    • Non-labor costs – Non-labor costs generally relate to planned purchases required to support the project. There are capabilities to capture these costs within the project schedule, but it usually adds limited value to reflect them in the project schedule. It is a best to plan and track these costs directly within the Project Budget Tracking tool.
    • Capitalized costs – Companies capitalize certain costs associated with developing or purchasing software designated for internal use. It is important to understand your clients business rules associated with capitalization, and ensure that the project budget supports both planning and tracking capital versus expense project costs.
    • Operational Costs – Although it is not part of the project budget, it is important to provide visibility of the impact of the project on the cost of the on-going operations. The costs included in the project budget can be utilized to derive many of the cost impacts on the on-going operations, such as: depreciation, customer support, infrastructure maintenance and software maintenance.

    Project Budget versus Project Funding:

    The project manager normally has limited responsibility for project funding decisions, however he/she must reconcile the funding model to the project budget. It is important to understand that when the project budget is approved by the project sponsor, the project cannot be launched until it is fully funded. Fully funded refers to the fact that the project is accounted for in both department cost center budgets (expense) and the capital plans (capital). Another critical aspect of the funding model is not only comparing the total project budget to the total amount funded, but also understanding the timing of the project funding vs. the budget. Under funded situations at any point in time require action prior to executing on the project as planned (e.g., may require delays in launching specific project activities / phases).


    The following provides an illustration of the components of the project budget, from the lowest level activity estimates in the project schedule up to the project funding model for the project.



    In conclusion, the project budget can be considered a strong component of the overall project plan when following have been fulfilled during the planning process:

    • The project budget is fully supported by other project artifacts
    • The project budget process connects to the client’s financial policies, procedures and tools
    • The project budget can be reconciled to the approved cost center budgets and capital plans