PM Foundations – Updating Schedule Progress

It always amazes me that after project managers put so much time and effort into creating a baseline project schedule, they do not always put the same level of energy and discipline into maintaining it during the execution phase of the project. It is extremely important during this phase of the project that the schedule reflects where you are at currently, as well as how the remaining work is planned to be completed.

During the transition from planning to execution the project manager establishes the progress update processes. These processes are both formal (e.g., submitting updates through a tool) and informal (e.g., soliciting input in one-on-one meetings). A productive project manager will ensure that these update processes are linked to other project related activities, such as time reporting, team meetings, and status reporting.

Progress Update Processes

The progress update processes and tools should fit into the way the team works. Try to avoid implementing processes that are disruptive or redundant. You do not want these processes to end up getting in the way of actual work being completed. In addition, these processes should be timely and consistent. The updates should be completed the same time/date during the reporting period (day/week). Team members should KNOW when information is due and when the schedule updates have been completed.

Based upon the organization and work environment, the project manager either establishes formal or informal processes and tools to collect progress updates. These processes and tools can range from weekly conversations with team members, to utilization of a tool for each team member to submit updates.

The key to this process is that it is linked to other project update activities (timeliness of information is dependent update establishing efficient processes):

  • Time reporting – Usually time reporting is at a higher level than required to update schedule activities, but at a minimum this process can be leveraged to trigger schedule update discussions.
  • Team meetings – Information shared at team meetings should be direct inputs for schedule updates (particularly on smaller projects).
  • Status reporting – It is up to the project manager to ensure that the status report is completed after schedule updates have been completed.

Performing Schedule Analysis

After completing progress updates to the schedule, it is a best practice to review the schedule data in a manner that proactively identifies potential issues. This review is utilized to identify areas where additional information and/or adjustments are required.

I will generally utilize the MS Project feature AUTO-FILTER feature to highlight potential project related issues. The approach helps focus in on specific problem areas:

  • Tasks that are NOT completed
  • Tasks that should have been started or finished already (past due), OR tasks that are scheduled to start or finish in the upcoming 1-2 weeks
  • Task assignments for specific resources (identification of resources that may be over or under allocated in the current time period

As the project manager you should be asking yourself the following questions when reviewing schedule related information:

Why are tasks past due? Most likely you will have run across the answer to this question when gathering progress updates from team members. If not, this is a good opportunity to follow-up with team members on the status of specific tasks. The answer generally falls into one of the following categories:

  • The task is taking longer than expected
  • Other tasks took higher priority
  • I could not start the task because I need another task to be completed first

Are actions required? Based upon review of past due tasks, as well as other tasks scheduled for the upcoming 1-2 weeks, you may identify problem areas that require immediate action. This is particularly true if delays (or anticipated delays) in the tasks will impact an upcoming milestone (or the project end date). Based upon discussions with the team, you may decide that one of the following actions must be taken:

  • Change resource assignments
  • Add a risk and initiate mitigation action planning
  • Change task dependencies to reflect new task sequencing
  • Add a task to reflect new work

Are schedule adjustments required? Some follow-up actions drive additional updates to the schedule. The bottom-line is that if the schedule no longer reflects how work will be performed, you should likely make additional updates to the schedule.

Making the Right Adjustments

Based upon completion of on-going schedule analysis, including follow-up research and discussion with team members, you will often identify adjustments that need to be made to one of the planning artifacts (schedule, issue / risk log, project management plan). The following represent considerations when making common adjustments to the schedule:

Resource assignments: Resource assignments may be proactive resource changes to avoid future problems, or reactive changes to respond to slippage in the project schedule. If material in nature, the resource changes should be made in the schedule. After the changes are completed, the project manager should review the resource usage to ensure that the changes solved the resource utilization issues as anticipated.

Duration / work estimates: When material differences in work effort or duration are identified (plan vs. actual progress), you should consider reflecting the difference in the schedule (particularly when there is significant work or time remaining to complete the task).

Tasks & dependencies: As work gets underway, additional tasks or task dependencies are identified that are required to complete the deliverable. These generally represent clarification of the work to be performed (vs. change in the deliverable to be completed). Again, if these changes are material in nature, and have not already been completed, you should consider reflecting these changes in the schedule.

Risks & issues: Review of the schedule based upon completing progress updates will often result in identification of additional risks or issues. This is the appropriate time to capture these risks/issues, and plan the appropriate actions to close or mitigate the risk/issue.

Project impacts: There is often a question around initiating project impacts based upon schedule changes identified. This topic is discussed further in my blog post on Managing Change, but the following represent the guidelines as to whether or not a project impact should be initiated:

  • Does this change have a material impact on the scope, schedule (end date), or cost of the project?
  • Is this a permanent change (or just a timing issue that will be resolved at some future point in the project)?

Updating Schedule Progress Best Practices

In summary, the following represent the primary best practices relating to updating schedule progress:

  • Establish a timely process (and supporting tools) to update schedule progress. The team should be well aware of how and when schedule updates will be captured, and when the schedule updates will be accurately reflected in the project schedule (to ensure team members are looking at the most current information).
  • Ensure that the processes for updating schedule progress are efficient for the project manager, as well as the rest of the team. Where appropriate, leverage existing communication vehicles or tools to capture this information (e.g., team meetings, timesheets, and personal status reports).
  • The process of updating schedule progress should regularly trigger the project manager to review the schedule to identify current or potential problems, and initiate the appropriate corrective actions.
Advertisements

Using SharePoint to Measure the Impact of Change (KPI)

As I discussed in my blog post on Managing 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 manager should be able to explain the evolution of the plan from the original baseline to the current baseline, including all approved changes that have been implemented.

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. In addition, use of the Project Status list enables use of SharePoint 2010 Key Performance Indicators to measure and communicate the project team’s ability to manage change at any point in time throughout the project life cycle. In order for the project sponsor and steering committee to make good decisions when approving change requests, they should understand the impact of the changes they have already approved. In addition, project change is one of the key metrics utilized to assess project performance in the project closure process (and identify and implement project improvement opportunities for future product releases / projects).

Creating the Approved Change Request view in the SharePoint list

The first step to establishing the project change metrics in SharePoint is to ensure that you have the appropriate view set-up to support the computation of the metric. The cumulative impact of change on the project represents the total impact of the approved change requests (approved and implemented status) on the project schedule and budget. To support this metric, I create a view in the change request list that is filtered to include only approved and implemented change requests (sample of this list view below).

The screen shot below from the Change Request list view settings illustrates the filters utilized to limit the list to only approved and implemented change requests.

In addition, totals are added to the list view to the Approved Change Request list view to display the sum of the schedule impact (days) and budget impact (dollars). I also added a count of the change requests so you can get a quick feel for the number of change requests that are driving the total change impact. The screen shot below from the Change Request list view settings illustrates setting up the totals that are displayed at the top of the list view.

Creating the Schedule Impact Metric

To create the Schedule Impact metric, select NEW indicator from the Project Status list. Within the indicator set-up, you are prompted for a name of the metric, a brief description of the metric, and comments (I use comments to describe the specifics of the source/calculation). In addition, you are prompted to select the list, and list view (described above) where the change request data is maintained. The screen shot below illustrates the first part of the indicator set-up process.


Then you are prompted to define the schedule impact metric:

  • The metric is calculated using the “Sum” of the “Sched Impact” field in the Approved Change Requests list view.
  • The “lower” the metric value is better.
  • The metric is GREEN when the total schedule impact is X days or lower (in this example I used 10 days)
  • The metric is YELLOW when the total schedule impact is Y days and greater that X days (in this example I used between 11 and 20 days)
  • The metric is RED when the total schedule impact is greater than 20 days.

The screen shot bellow illustrates the definition of the schedule impact metric.


Based upon the information set-up for the Change Request Schedule Impact metric, the screen below illustrates the details displayed for this metric. The biggest challenge is setting up consistent criteria from project to project that effectively defines GREEN/YELLOW/RED for the cumulative schedule impact.

Creating the Cost Impact Metric

The same process is utilized (as described for the Schedule Impact metric) to create the NEW indicator, describe the Cost Impact metric, and select the list/view where the change request data is maintained.

Then you are prompted to define the metric:

  • The metric is calculated using the “Sum” of the “Cost Impact” field in the Approved Change Requests list view.
  • The “lower” the metric value is better.
  • The metric is GREEN when the total cost impact is X dollars ($) or lower (in this example I used $10,000)
  • The metric is YELLOW when the total cost impact is Y dollars and greater that X dollars (in this example I used between $10,000-$25,000)
  • The metric is RED when the total cost impact is greater than $25,000.

The screen shot bellow illustrates the definition of the Cost Impact metric.


Based upon the information set-up for the Change Request Cost Impact metric, the screen below illustrates the details displayed for this metric. Generally the definition of GREEN/YELLOW/RED for this metric is documented within the Cost Management Approach of the Project Management Plan.

PM Foundations – Project Assumptions

You have probably heard the saying, “Be careful when you assume something. It will end up making an Ass of U and ME.” From a project management perspective, assumptions are your friend. Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started.

 

Examples of Assumptions

  • Benefits associated with the project – When building a business case, you often need to make assumptions about what impact (hopefully positive) the project will have after it is completed. You can gather information (e.g., time studies) to refine the assumptions, but there will still be unknowns until the new processes and systems are in place and fully operational.
  • The way things will work within the product – You do not know exactly how something is going to work until you start to define and build it. This means that during the planning process you probably need to make some assumptions about what “it” is. These assumptions will impact the planned effort and duration of the project.
  • Things you can leverage to develop the product – Often times you are not starting from scratch. There are assets from previous efforts that can be reused, but you may not know exactly to what extent. Another good example of when to create an assumption.
  • Resources you will use to build the product – The number and types of resources will definitely have an impact on the timing and quality of your efforts. At the time you are planning the project you may or may not have all the exact resources in place – this includes the partners that you may hire to help with the effort. The assumptions in this area also include things like: Do I need to include time and costs for training? Do I have the facilities and computers available to support these resources?
  • Dependencies and lead times – What needs to be completed to start working on specific activities? If you wait for all the answers to these questions, you will never complete the project schedule.
  • Cost of developing the product – You may not have all of the exact cost estimates, but you need a project budget. Again, you can gather information (e.g., costs from similar projects) to refine the assumptions, but you may still have some unknowns associated with the cost / pricing for specific components of the effort. Insert an assumption.

When do you make assumptions?

  • Developing the business case – As I mentioned in the examples, during project initiation, when you are developing the justification for the project, there will be a ton of unknowns and assumptions help construct the initial business case for the project.
  • Developing the project plan – Throughout the planning process (defining the product and project scope, creating the project schedule, and developing the project budget) there will be things you will not know until you get to that point in the project.
  • Managing change – As project changes occur you may not know the exact impact of the change on the project or product. This is a good example of why assumptions must be managed throughout the project life cycle.
  • Managing risks – Just by the very nature of a risk, assessing the probability or impact of a risk may require some assumptions (e.g., if this risk occurs it will delay the project by 2 weeks). Try and get your mind wrapped around that one – unknowns related to the unknowns.

Best practices associated with assumptions

  • Do not use assumptions to CYA – be specific, and you must believe them to be true – I hate it when I run across assumptions like: We have enough resources to complete the project. –or- The client will be available to approve the deliverables. These assumptions are either added because of a CYA mentality or because they are believed to be untrue. Assumptions need to be specific and manageable, and most importantly you need to believe they are true at the time you identify them – if not, they are just “noise” in your project plans
  • Make sure they are documented – When you identify an assumption, document it, either in the project management plan or in a separate list of assumptions that are maintained and managed. Some assumptions seem innocent enough, but I have had plenty of times when we have had to revisit the rationale behind the plan because we did not document the assumptions well enough.
  • Assumptions need to be managed throughout the project life cycle – On an on-going basis you need to review and test your assumptions, particularly the ones that are critical to your plan (scope, timing, or cost). Assumptions can be deleted from the list as work is completed and they are OBE (overcome by events).
  • Focus on the key assumptions – Over time you tend to accumulate a lot of assumptions. Make sure that you have established a mechanism to focus on the critical assumptions (based upon the timing of the project activities, and the nature of the assumption).
  • Assumption management is tied to the risk management process – As discussed above, managing assumptions is directly tied to managing risks because they both relate to unknowns. It is a best practice to perform a quick review of key assumptions at the same time you are updating the risks. Think of it in the same way as changing the batteries in your smoke detector when you change your clocks for daylight savings time.

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

Top 6 Project Management Best Practices

What about Project Management Best Practices

I do a lot of blogging about project management best practices. I firmly believe that it is the effective implementation and consistent application of PM best practices that differentiates successful projects from challenged projects. Best practices represent the practical application of the concepts, processes, and tools defined in the PMBOK® and other sources of knowledge. Project management is a very mature competency, and there is no shortage of resources to understand and define best practices, but the key lies in identifying the “critical few” that are key to project delivery success in your project environment. Below is the graphic that depicts the “critical few” included in Cardinal’s PM Foundations program.

Practical application of these best practices drives a consistent project management approach, and tangible business results:

  • Quicker ramp-up of project managers
  • Easier integration of projects in a multi-project environment
  • More productive project managers (not inventing processes and tools on the fly)
  • Equips project managers with tools to “fill the gaps” in the client environment
  • Better overall team performance – delivering on customer expectations (including measurement of performance)

These are the tangible business results that separate good project managers apart from “the pack”.

My Top 6 Best Practices

If I could only have 6 best practices to put in my toolkit as I ventured into a new project assignment (or mentor a new project manager), these are the ones I would select.

1. Project Organization: Forming the project team sounds pretty basic, but it is amazing how many project teams launch the project without performing stakeholder analysis, and defining the project organization. Important elements of the project organization include project sponsors, the core team, and understanding other key stakeholders. The use of a RACI is a flexible and effective tool within this best practice area.

2. WBS: The WBS defines the scope of the project and breaks the work down into components that can be schedule and estimated, and easily monitored and controlled. Simply put, a WBS is a deliverable oriented hierarchy that defines the work of the project, and only the work of the project. The use of facilitated WBS sessions represents a key technique within this best practice area.

3. Resource Loaded Project Schedule: The project schedule utilizes the WBS to define the activities, sequence, durations, and resources required to complete the project work. What does a good project schedule look like? Here are a few questions to help test your schedule:

  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?

4. Managing Project Change: Change is an inevitable element 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. The following are the key aspects of this best practice area:

  • Definition of a change in the context of your project
  • Understanding the sources and early warning signs of change
  • Establishing a process to manage change
  • Measuring the cumulative impact of change

5. Measuring Performance: This best practice area involves keeping your eye on the appropriate project performance measures to proactively identify potential problems, and engage the team to identify and implement corrective actions. Measuring project performance includes schedule, budget, and supplier performance. Use of earned value to measure schedule and budget performance represents a tool within this best practice area.

6. Closing the Project: A best practice area that is often minimized or entirely over looked is project closure. At the end of a project, many project managers are busy 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 and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project performance report (also referred to as the post-project assessment. Creating the project performance report includes gathering input from key stakeholders, and identifying improvement actions to be implemented for future projects.

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.

image

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.

image

image 

image

 

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.

image

Summary

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 – Estimating and Loading Resources

One of the common pitfalls I often run across when reviewing project schedules is inadequate attention or diligence around the area of resource planning. Improper planning in this best practice area often leads to project schedules and budgets that may not be reasonable or manageable. The following summarizes the high level best practice areas associated with resource planning:

  • 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

    For purposes of this post, I will focus on the first two — estimating resources and loading the resource assignments into the project schedule.

Resource Estimating:

There are two techniques for resource estimating – bottom up & resource allocation. Both techniques are valid, and each are more effective than the other in specific situations.

Bottom up Estimating:

The following steps describe the mechanics of this technique:

  1. Work with the team to estimate the work effort (hours) for each resource assigned to the activity.
  2. Enter the hours for each resource assigned to the activity within the Project Management tool.
  3. The Project Management tool computes the allocation % for the activities (based upon the hours and duration assigned to the activity).

When is this technique most effective:

  • The activity is complex, and the team needs to spend time to understand the details associated with the activity.
  • Experience with other projects is based more on actual hours of work effort.
  • Precision of the work effort is very important, and is worth the time to create a more accurate schedule.

Here is an example of how this technique works:

clip_image002

Resource Allocation:

The following steps describe the mechanics of this technique:

  1. Group activities based upon allocation of resources (may be one to one, but more likely will have activities with the same allocation over some period of time).
  2. Assign allocation % for each resource assigned to the activity in the Project Management tool.
  3. The Project Management tool computes the number of hours of work effort for the activities (based upon the allocation % and duration estimated for the activity).

When this technique is most effective:

  • Details of the activity are not known, and therefore it is the duration estimate that is driving the resource estimates
  • Experience with other projects is based more on “how long it takes” vs. “how many hours of work”
  • Precision of the work effort estimates is not as important as developing a reasonable schedule

Here is an example of how this technique works:

clip_image004

As depicted in this example, both techniques arrived at approximately the same resource needs (this certainly will not always be the case). However, the approach to arrive at the resource needs was very different and highly dependent on the situation and information available. For each set of activities within the schedule, it is important to decide on the appropriate approach to estimate and assign resources, and then gather the information required to determine resource requirements. In many cases the project manager will use a combination of the two approaches (#1 for more complex work effort driven activities, and #2 for more duration based activities).

Resource Loading:

Once the resource estimating process is complete, the mechanics of loading resources into the schedule is very straight forward. From the resource tab on the individual task, or from the resource column in the Gantt view (assuming you are using MS Project as your PM tool), the resources are added in the following manner (depending upon the approach selected):

1) Approach #1: Select the resource, enter the hours in the work column, and the % allocation will be computed.

2) Approach #2: Select the resource(s), enter the % in the units column, and the work hours will be computed.

Another key element associated with the resource loading process is the task type set-up for the activity. Use of different task types impacts the way the units (%), work and duration are re-calculated when any of these elements are changed. I always recommend use of fixed duration with an effort driven option as the default set-up. It allows work and units to fluctuate as you modify the timeline (duration). The table below describes the different behaviors within the project schedule, based upon the task type:

clip_image006

When loading resources, a good check that you have the activities broken down to the appropriate level is whether or not you have direct accountability of resource assignments. If you have a lot of tasks with 2-3 people with a 10% allocation, you may not have the activities broken down to the appropriate level.

You want to avoid falling into the trap of loading activities into the schedule that are “indirect” in nature that are merely loaded to reflect usage of individual’s time on the project. Try to keep the schedule focused on “direct” project activities. There are other ways to reflect commitment to the project without putting “noise” in your schedule.

Resource Estimating & Loading Best Practices

In summary, the following are the best practices associated with the resource estimating & loading processes:

  • Use the resource estimating and loading approach that best fits the type of activities that are being planned
  • clip_image008

  • 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” activities).
  • Set-up the schedule activities in a manner that drives the appropriate behavior when loading resources into the project schedule. I recommend fixed duration as the task type.

Note: I will be posting a blog in the near future on performing resource usage analysis and creating your resource plan.

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

clip_image001

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.

clip_image002

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.

image

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

image

    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?

    Summary

    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.