Program Management Tools & Techniques

Program Management is often viewed as project management on steroids. However, when this is the approach of the Program Manager, both the program and the program team usually suffer. Effective program management requires a different skill set.

First let's define what I mean by a program. If you refer to my page on project complexity, you find that the most complex type of project is a program. A program is a large multi-year, multi-deliverable proejct that normally costs millions of dollars and will have hundreds of people working on it at some point in time. The recommendation for managing a program was to break it into a family of inter-related sub-projects that have their own Project Leader. The Program Manager's role is to manage the interfaces and relationships between the sub-projects. When a problem arises on one sub-project, the Program Manager must work with the Project Leader to drive the problem to a satisfactory solution, or sometimes to shift the problem resolution to a different sub-project that is better able to address the issue.

Therefore the Program Manager does not personally manage the day-to-day activities within all of the sub-projects. However, the Program Manager is the primary stakeholder for each of the sub-projects and is involved in the oversight and risk resolution activities within each sub-project. Ideally, the Program Manager is an experienced Project Leader and understands how to plan, execute and control a project. But, the Program Manager must be able to step back and not begin to micro-manage all of the sub-projects. There are a number of tools and techniques that will assist the Program Manager in their role. These include the application of the systems engineering discipline, the use of Interface Control Documentation to manage the scope interfaces between sub-projects, the use of Milestone Alignment charts for schedule integration between projects, the use of a Staffing Management Plan for personnel resource alignment, and Program Management Reviews for program control. As mentioned on the Project Team Leadership page, two vitally important characterisitcs of successful program management are communication skills and risk management. Other tools and techniques that are discussed on other pages and that apply to program management include:

• Requirements Document
• Network Diagram
• Work Breakdown Structure
• Budget Baseline
• Technical Reviews
• Earned Value Analysis

Systems Engineering

The Systems Engineering discipline as applied to programs is as much a philosophy as it is an engineering discipline. In this case Systems Engineering starts with the final business impact of the program and considers all of the needed activities necessary to successfully implement the program. For instance, a new product development program targeting products for a new market may need to develop a product, build a new factory in a differnet country, create a new logistics process, implement a new ERP system, and develop a new sales and service operation. All of these sub-projects must comply with a myriad of standards and regulaotry requireemetns. Each of these sub-projects are very different in terms of the scope of work and the needed technical skills. Yet each of these sub-projects must complete their sub-project goals to an overall program schedule and integrate with the other sub-projects so that the new product can be successfully launched in the new market. The Systems Engineering discipline translates the overall program goals into detailed sub-project requirements.

In addition, the Systems Engineering activities will establish quality attributes and success criteria for the sub-proejct deliverables that will ensure the overall program is able to meet the program quality and success criteria. The definition of requirements and trackig of successful attainment of the requirements is often maintained in a Systems Engineering Management Plan (SEMP). The SEMP will contain the Traceability Matrix (discussed on the Scope Planning page) for each of the sub-projects. Often there is a significant amount engineering analysis needed to establish the performance and lifecycle requirements for aspects of the system that are effected by multiple sub-projects. This analysis can take weeks or months to complete, yet it is a crucial portion of the overall program lifecycle and must be done prior to the initiation of the sub-projects.

Interface Control Documentation

Interface Control Documents (ICDs) are the mechanism used to communicate technical requirements and interfaces between sub-project teams. These must be managed by the Program Manager because there will inevitably develop confusion and conflicts between the sub-project teams concerning technical interfaces. Some of the more common items documented on ICDs are mechanical interfaces, electrical interfaces, acceptable tolerances, datastream definition and protocols, thermal interfaces, electromagnetic interfaces, loads and moments, hazardous materials and hazardous waste, and material compatibility. This is not an exhaustive list, rather it an illustrative list. Some of these may not apply on your program, but there may be other technical requirements that do apply and are not listed.

The development of ICDs is often as much political as it is technical. One of the sub-projects is tasked with creating an intial draft ICD that is then reviewed and commented upon by all of the affected sub-projects. This is where it is necessary for the Program Leader to engage. The initiating sub-project will often bias the ICD in the direction that minimizes risk within their sub-project - for instance they may impose excessively tight tolerances on parts and systems coming from other sub-projects. The Program Manager must consider the risk to each sub-project and the overall risk to the program of the different options for interface definition. Given the strengths and weaknesses of the project plan and the project team within each of the sub-projects, the Program Manager makes the best program decision and then communicates that decision through the ICDs. In my experience it is best to treat the ICD as a revision controlled document and, when working with multiple companies, placing the ICD on the contract as a controlled document.

Milestone Alignment Schedule

The Milestone Alignment Schedule is the Program Manager's schedule integration tool. This schedule takes the major sub-project milestones from each sub-project and carries them onto a program schedule. In addition to the major milestones, I normally include any handoff activities between sub-projects such as a pilot run of the new product in the new factory. I have found this to be a better program schedule for the Program Manager than using multi-project software and integrating all of the sub-projects. On a fairly large program the multi-project software will quickly expand to include literally thousands of activities as each of the sub-project plans are incorporated. sifting through all of these activities to identify and highlight the vital few becomes a time-consuming task for the Program Manager. Instead, when the sub-projects are initiated the Program Manager defines the schedule intergration points that he or she wants to track. Then during the ongoing Program Reviews, the Program Manager tracks those milestons and in the risk identification portion of the review, new integration points are identified and added when appropriate.

The type of schedule can be created in a Gantt chart format where each integration milestone is a line on the Program Gantt or it can created as a pipeline chart where each of the sub-projects is a pipe and the integration milestone linking the pipelines are shown. I have used both approaches and both are acceptable. The example shown is a pipeline chart.

Staffing Management Plan

The staffing management plan is used by the Program Manager to optimize the resource pools that are shared across several sub-projects. The staffing management plan typically shows the resource needs in a set of histograms where each bar represents the needs during a particular time period such a month or quarter. The staffing management plan provides insight to the Program Manager concerning possible people shortages or skill shortages on the program. The Program Manager then can work with Human Resources to fill the gaps with permanent or temporary staffing. Also, the Program Manager can work with the sub-project leaders to change schedule boundaries on the sub-projects that will alleviate staffing concerns without delaying the end date of the program.

Developing the staffing management plan can be difficult. Often the sub-project leaders are unable to provide resource estimates without first conducting detailed planning for the entire project. Yet, if the program is Adaptive in nature, it is impossible to prepare a project plan for the entire sub-project. When that is the case, the Program Manager must coach the sub-project leaders to develop high-level plans and create rough resource estimates to support those plans. It is not necessary to have precise estimates for the staffing management plan since the plan is based upon large pools of resources. It is far more importatnt for the Program Manager to know that they will need five more software development engineers during June and July than it is to know that they will be short by 6.3 engineers on Wednesday June 11.

Program Management Reviews

Program Management Reviews are used by the Program Manager to accomplish three things:
Check on the status of the sub-projects to determine if there are problems within them that are beyond the ability or authority of the sub-project leader to resolve
Ensure coordinated handoffs between sub-projects for joint or shared program deliverables
Identify risks between sub-projects and risks that are likely to migrate from one project to another
These reviews are normally scheduled to occur on a regular calendar schedule - such as the first and third Monday of each month. The reviews are attended by all of the sub-project leaders and key program stakeholders. The Program Manager normally starts the meeting with a quick overview of the status and near-term goals of the program to ensure alignment and then each of the sub-project leaders provides a status report of their sub-project. The sub-project leader reports focus on points of interface with other sub-projects and the reduction or elimiation of risk on their sub-project. These are not "activity reports" but rather are risk reviews. Formal minutes and action items should be maintained for these reviews and filed in the project archives.

Project Team Leadership Tools & Techniques

Most projects are planned and implemented by teams of individuals. Therefore the ability to work effectively in a team is an important characteristic of successful project management. However, this is more than just being pleasant at meetings. The team normally represents diverse functions often with different, possibly conflicting, objectives. The team must be able to integrate the different needs of the functions and simultaneously achieve the goals of the project. Further, this is often done in an environment where no one individual has direct authority over the team members.

Many organizations have developed procedures for project team formation and project team behavior. I recommend that you use those if they are available. I have found several techniques to be very helpful when establishing and managing project teams. The first is the Core Team concept. This concept is useful for clarifying the team roles and responsibilities of project team members. The second technique that I will discuss is the use of Matrix Management when establishing teams. With the team established, the role of the Team Leader and Core Team Member will be addressed. Finally several useful techniques for addressing project team dynamics will be discussed including Situational Leadership, Team Development, Conflict Management, and Negotiation Skills. Of course, all of the techniques discussed in Project Management Communication Tools and Techniques have direct applicability to Project Team Leadership.

Core Team

The Core Team is the group of individuals who have day-to-day responsibility for planning and managing the project activities. This is typically a cross-functional group. The Core Team would consist of the Core Team Leader and the Core Team Member from each function that has a significant role in project execution. In my experience, Core Teams can vary in size from three to twelve members. The Core Team Leader for Focused projects often also wears the hat of a functional Core Team Member. For Full-scale and Complex projects with greater complexity, the Core Team Leader position is usually a full-time individual who does not also represent a specific function.

Core Teams are responsible for the detailed planning of a project. This includes the task planning, to include scope, schedule and resource planning for all project activities. Further the Core Team monitors the day-to-day project activities. When minor changes and tradeoffs must be made to the project plan and within the project boundaries, the Core Team has the authority to make those decisions. However, whenever their decision would cause the project to exceed one of it's overall boundaries, such as total budget, project completion date, or compliance to an external requirement, they should refer the final decision to the project sponsors or the PMO. Finally, the Core Team is collectively accountable for project success.

The outer ring of the diagram showing an illustration of a typical Core Team structure is the extended team, or full team members. These individuals are added to a project and removed from it based upon the current project activities. The individuals in this ring move from project to project or may be supporting multiple projects at any given time. These individuals are actively engaged in doing the project activities and the project cannot succeed without them. However, they typically do not play a major role in project planning and control of the project and are not held accountable for overall project success.

Matrix Management

Project teams can be formed within the business organization in several approaches. These include a projectized organization approach, a functional organization approach, or a matrix organizational approach. Many people today advocate for a matrix approach. The matrix has some advantages but it also has some disadvantages. Projects can be successful in any of the approaches, depending upon the nature of the project work and the goals for the project.

The projectized organizational approach creates a dedicated project teams. In this case all project team members are assigned and report to the project leader. They do not support any other projects during the life of the project to which they are assigned. The advantage of this method is that aligns all of the project team members with the project goals and objectives. The disadvantages are that expertise developed on one project is not easily shared across other projects and that there may at times be ineffective use of resources depending upon the schedule of project activities. Some individuals may be sitting idle waiting for predecessor tasks to complete. This approach is appropriate when either the project is truly stand-alone and there is no benefit for integration or best-practice sharing with other projects or when the project is Extreme in nature and the dedicated team is needed to quickly respond to changing circumstances.

The functional organizational approach does not create a formal project team. Rather, the business management determines a project is needed and then each functional department does their portion of the project in an isolated fashion. Either a project sequence is determined and each function does their activity when it is their "turn," or a set of high level requirements are agreed to and each function completes their portion of the project based upon staff skills and availability. The advantages of this approach are that the functional leaders can ensure the project activities are completed by the person most qualified to do the work and it allows functional managers to balance their internal workload across their people. The disadvantages are that there is very little project accountability with regard to overall budget or schedule and if tradeoffs must be made between the functional requirements of two or more functions, the people doing the work have no authority to resolve the issue leading to delays and inadequate project deliverables.

The matrix organizational approach was created to enable the achievement of the advantages of both the projectized and the functional approaches. When this happens, the functional managers enjoys the flexibility to assign the best person to the project activity in order to achieve functional excellence and can make the best use of scarce resources. At the same time the matrix fosters the integration of all the project activities in order to meet the project objectives. However, when the matrix is not implemented well, it results in the realization of the disadvantages of both the projectized and the functional approaches. There are delays and confusion in making decisions and neither the project or functional objectives are met. In my experience, there are two different approaches used for implementing matrix project organizations. One is referred to as a "Weak Matrix" and the other as a "Strong Matrix." Either approach can be effective. The monikers of "Weak" and "Strong" address the relative power of the project leader.

The Weak Matrix structure at first appears to be a functional structure. Each individual assigned to the project reports to their respective functional manager and their is no control by anyone with project leadership responsibilities. However, in this structure, there is a Core Team Member assigned in each of the supporting functions. These individuals are expected to communicate with each other and integrate their respective functional plans and deliverables so as to support the project objectives. One of these Core Team Members is assigned the role of Project Leader. This individual has the responsibility for calling the Core Team together and identifying when there are risks or disagreements that the Core Team is not able to resolve among themselves. At that point, the issue is elevated to senior management for their decision on issue resolution. The Project Leader is essentially an integrator and facilitator in this approach. The only decision-making authority he or she has is with respect to their function. In the example shown, the functions are just for illustration purposes. The Core Team should consist of all functions with significant responsibility with regards to project activities and the Project Leader could be assigned from any of the functions represented on the Core Team.

The Strong Matrix structure is a true hybrid of the projectized and functional approaches. Across the top of the matrix is the functional managers and down the side of the matrix are the Project Leaders. The Core Team Members are typically assigned by the functional managers with the approval of the Project Leader and the Core Team Members report to both their respective functional manager and to the Project Leader. This can lead to difficulty since the Core Team Members have two "bosses." If there is a difference of opinion about a project decision between the Project Leader and the functional manager, the Core Team Member can find themselves caught in the middle. However, when the issue is resolved by the Project Leader and functional manager working together to find the best solution for the business, this structure will speed the identification and resolution of issues. An important point of clarification, in the strong matrix is that the Core Team Members report to both the functional manager and the Project Leader. However, the extended team members report to the functional manager or their function's Core Team Member. They do not report to the Project Leader.

Project Team Leader

The Project Team Leader is the individual with responsibility for ensuring that the project is planned and executed. The Project Leader does not do all the work of project management, that is shared among the Core Team Members. However, the Project Leader does ensure that the work of project management is carried out on the project. The Project Leader is normally the individual who leads the Core Team meetings and is normally the individual who speaks for the project in project review meetings with the PMO or senior management. The Project Leader is also the person responsible for maintaining the project plan and the current project status and any associated project management documentation or databases. Finally, the Project Leader needs to review all major project decisions to ensure they are in the best interests of the project objectives. When the Project Leader believes a decision is inappropriate, he or she must take action to change or elevate the decision.

Over the years I have found that effective Project Leaders have mastered two vital aspects of project management. The first is Risk Management. The Project Leader must ensure that project risks are identified and analyzed, and not suppressed or overlooked. In addition the Project Leader should verify that risk response plans are established and implemented for all significant risks. The second aspect of project management that the Project Leader must do well is Project Communication. The Project Leader must manage the communication between the project team and stakeholders. In addition, the Project Leader must manage the communication between project team members. This can be very difficult when the project team members are not collocated.

The role of Project Leader is hampered by the fact that, unless the project is organized in a projectized approach, many of the project team members will not report to the Project Leader. This means the Project Leader must rely on their personal leadership skills in addition to any positional leadership authority that the title "Project Leader" may grant them. I have found that the Hersey Blanchard Situational Leadership approach to be very effective for Project Leaders.

Core Team Member

The Core Team Member role can often be viewed as a mini-project leader for their respective function. In this capacity, they are responsible for identifying the necessary activities that must be done within their function to support the project activities. Once those activities are identified, the Core Team Member is responsible for the planning and execution of the activities. The Core Team Member may be the person executing the activities, or they may be providing oversight to other individuals in their function who are executing the activities. Those other individuals would be considered extended team members.

A key role for the Core Team Member is to be involved in the day-to-day decisions of project management, They need to be able to adequately represent the interests of their function in Core Team meetings and they need to be able to commit their function to action plans - including schedules and deliverables. To do this well, Core Team Members should be capable of doing risk identification and analysis with respect to their function.

A problem I have seen in several organizations is that Core Team Members are selected based upon, "Who isn't doing anything right now?" rather than on their ability to represent the function on the Core Team. If an individual cannot be trusted to make wise decisions for their functional organization (within reasonable bounds) then they are not Core Team Member material.

Situational Leadership

The Situational Leadership approach developed by Paul Hersey and Ken Blanchard is an effective tool for project leaders to use when determining a leadership interaction style. Situational Leadership Theory can be applied in two different modes. One mode is for personnel development. In this mode the leader will have a long term relationship with the person being led - the follower, and the objective is to bring the follower to a point where they are highly capable and motivated. The other mode is the project mode. In this mode the leader expects to have a short relationship with the follower and the objective is timely and correct completion of project activities. I apply Situational Leadership in the second mode when working as a project leader. A key reason for changing leadership styles is to avoid over-leading or under-leading. Over-leading results in individuals feeling constrained, demeaned, and untrusted. Under-leading results in individuals feeling abandoned, insecure and confused.

The key in Situational Leadership is to determine the readiness level of the followers. Readiness is classified into four categories based upon the followers motivation and ability to do the project activity that is assigned.
Readiness 1: Low Motivation, Low Ability - this person is not skilled at the assigned task and does not want to do the work or work on this project.
Readiness 2: High Motivation, Low Ability - this person is eager to work on the project but is not proficient at the activities assigned.
Readiness 3: Low Motivation, High Ability - this person is capable of doing the project activities but for personal or business reasons does not want to do the activities.
Readiness 4: High Motivation, High Ability - this person is capable and motivated.

The Project Leader should respond to each individual situation be using a combination of task behavior and relationship behavior. Task behavior focuses on providing clear directions and guidance for the specific activities that are to be accomplished. Relationship behavior focuses on building an interpersonal bond between the Project Leader and the team member. For each of the follower Readiness levels, there is a corresponding Leadership Style.
Style 1: Directing - High Task, Low Relationship interactions - Provide clear directions and rigid accountability in order to get the person to expeditiously complete the project activity.
Style 2: Coaching - High Task, High Relationship interactions - Provide encouraging direction to both train the individual and maintain their high level of motivation, don't under-lead.
Style 3: Supporting - Low Task, Low Relationship interactions - Since this person is capable, you must focus on motivation. Relationship interactions will help to identify the underlying causes for lack of motivation and suggest ways to overcome them.
Style 4: Delegating - low Task, Low Relationship interactions - These individuals are budding superstars, so let them shine, don't over-lead.

Project Team Development

The project team development model that I find most useful is Tuckman's "forming, storming, norming, and performing." Although this model has been around for over 40 years, I find that its relevance to project teams is as true now as when it was first articulated. Project teams are often quickly put together and populated with people of different skills, backgrounds, experiences, and bringing different expectations with them. It is often multi-disciplinary, multi-cultural, multi- generational, and many time in multiple locations. This diversity can lead to excellent project definition, planning and execution - but only if the team can develop teamwork.

During the "Forming" stage, team members are being assigned and the team members are just trying to get acquainted. Soon the team progresses to the "Storming" stage as roles and responsibilities are assigned and arguments over activities, standards, and "turf" often are exposed. The project team should begin to resolve these issues and move into the "Norming" stage where they have agreed on activities, standards and levels of responsibility. As the team gains confidence in working with each other, trust develops and the team moves to the "Performing" stage.

One reason this model works so well for understanding team dynamics is that project teams are often unstable. The team membership changes during the life of the project. As activities are completed and new ones started, the roles and relationship between team members may change. As a project progresses through different phases, the standards of performance may change. From a team perspective this means that project teams will travel up and down the sequence of stages frequently. When a project team suddenly finds itself in the midst of conflict they should not view that as a team failure, it is just a cycling of the team dynamics throught the team stages based upon the changing project and business context. It means that once again the team must work through some conflict to establish new norms and again reach for high performing status.

Project Team Conflict Management

A technique that I have found useful for resolving team conflict is the application of the GRPI model of project teams. This technique has gained broad acceptance within the Six Sigma community for its ability to guide the team in a quick and easy approach for developing a project plan that is applicable to small projects. In the GRPI model, project development goes through four stages:
G - Goals: the goals of the project are agreed to by the team.
R - Roles: the roles and responsibilities of each team member are determined.
P - Processes: the actual project processes or activities are defined, estimated, and planned.
I - Interpersonal: as the project unfolds, everyone begins to work together and the interpersonal relationships are established and strengthened.

I use this model for conflict management by working from the bottom up. If conflict arises on the team, I first see if there is any interpersonal issue. If so, we work on resolving that issue. However, I always check the next higher level to see if the problem goes deeper into the project. Moving up a level, I check to see if there is a difference of opinion on what activities we should do or how they should be done. If that is the problem, we resolve that issue and usually the Interpersonal relationships are re-established. If there are Process problems I always look further up to see if there are problems with the assignment of roles and responsibilities. Once those are resolved, the responsible person can then make decisions about the processes and the interpersonal relationships are re-established. If there are problems with the roles, I always check to ensure the team is aligned on the project goals. If there is mis-alignment on goals, that must be resolved before we can even begin to create and execute a viable plan. Often if the issues is goal alignment, the stakeholders must be brought in to align the team members on the project objectives.

Project Team Negotiation

Virtually all projects are under some type of constraint. The constraint may be time, it may be resources, it may be regulatory/compliance, it may be technical limitations. These constraints lead to the necessity to balance conflicting demands on the project. This then leads to the need for effective negotiations between the Core Team Members in order to optimize the project and business performance.

The Thomas-Kilmann Model provides a suggested negotiation strategy for different conflict contexts. Based upon the desire to retain the relationship between team members and need for achieving a solution with a high degree of technically efficacy, different negotiation strategies are suggested. I recommend that the Project Leader be very familiar with this model and prepared to apply it whenever it appears that some goal or attribute of the project will need to be negotiated. Obviously collaborative approaches are often desired, but they may take a long time to reach a satisfactory solution. And sometimes there is no viable collaborative solution. In that case, the Project Leader must help the various team members decide which aspect of the team dynamic is most important at this time and implement the appropriate strategy.

Project Management Closeout Tools & Techniques

Project Closeout is the process or activities associated with finalizing the hand off of the project deliverables to the business team and completing the administrative aspects of closing the project. Most of the project management activities at this time are administrative and are unique to the organization. They involve gaining stakeholder acceptance of the project deliverables, integrating project resources back into the organizations pool of resources, and capturing any lessons learned from the project for use on future projects.

There are four techniques that I have found useful when managing the Project Closeout. This first technique, which I call Closeout Approach, is an organizing principle for guiding the administrative closeout activities. The second technique is a Stakeholder Acceptance meeting. The third technique is the development of a Punch List to drive project closure and prevent scope creep. The final technique is the conduct of a Lessons Learned assessment on the project.

Closeout Approach

The Closeout Approach considers the method that the project deliverables are being hand off to stakeholders and changes the administrative activity accordingly. In all cases, any supplier contracts must be closed with the procurement department. However, the internal closeout process of ohter activities will vary.

Project Inclusion - This form of closeout is the simplest from an administrative standpoint. The project team, who has developed the project deliverables, now become the primary users/ maintainers of the deliverables. The team essentially hands off the project deliverables to itself. In this case, the project management team needs to close any administrative accounts or files that are associated with development and reopen them for operational deployment of the deliverables. The transition is virtually seamless and administrative in nature.

Project Extinction - This form of closeout is also straight forward. The project activities are immediately terminated. Resources are either redeployed in the organization or they are released. This condition may be created because of problems within the project, or it may be because of conditions that are completely outside of the control of the project team. For instance, I worked with a team closing a project in this fashion because an unexpected ruling by a government regulatory body eliminated the need for the project deliverables.

Project Integration - This form of closeout is the most difficult. The project deliverables are completed and the project team believes that they meet the project objective. However, the project team must ensure that the portion of the organization that is to make use of the deliverables is prepared to embrace them and apply them appropriately to achieve the business benefit. At times there is significant resistance to accepting the deliverables. When a project team is facing this type of closeout they need to ensure that appropriate change management activities are being conducted at the same time they are performing the administrative closeout activities. When the change management is likely to be a significant issue for the project, I include a transition phase to the project that has pilot runs, beta tests, or other transition activities to enhance acceptance by stakeholders.

Stakeholder Acceptance Meeting

A Stakeholder Acceptance meeting is exactly what the name implies. The project team meets with project stakeholders to review the deliverables of the project and ensure that the deliverables are acceptable to the stakeholders. I strongly recommend that this meeting be held by Program Managers with all sub-project teams on Complex programs. I have also found this useful when doing projects under contract to ensure that there is a clear endpoint to the project and that the final invoice can be submitted. The format of this meeting often is based upon the Project Charter. The deliverable for each item of the Charter is presented and explained to the stakeholders.

Project Punch List

The Punch List is a technique borrowed from construction projects. When conducting Stakeholder Meetings, gaps are often identified between what the stakeholders wanted from the deliverables and what is being supplied by the project team. The Punch List is used to manage the closure of those gaps. As a deliverables is presented - whether in a Stakeholder Meeting, pilot run, or Beta test - any gaps or deviations are listed and placed upon the Punch List. The project team then identifes the cost and schedule impact of completing the Punch List items and they come to an agreement with the stakeholders concerning which items they must complete and the end point of those new tasks. Both the stakeholders and the project team manage the effort to the Punch List. Stakeholders cannot continue to add items and the Project Team must complete all the items on the list. This technique will quickly drive the project to closure.

Lessons Learned

The Lessons Learned process is usually tailored to the organization. If the organization has a PMO the Lessons Learned process is nomrally a formal part of project closeout. When there is no PMO, often any Lessons Learned activities are done informally if at all. When I conduct Lessons Learned sessions, I follow a four step process.

Evaluate the Business Case - The first question I ask is whether the project created the business benefit that was used to justify approving the project. This question is less about how well the project team did and is much more focused on senior management and the project selection and approval process. The lessons learned at this point improve the ability of the organization to select projects and to establish realistic project charters.

Evaluate the Project Plan - This question addresses how well the project manager and project management team planned the project. It concerns topics like: a) identification of required activities, b) cost and schedule estimates, c) risk factors, and d) team integration and communication.

Evaluate the Project Management Methodology - This question addresses whether the organization's procedures and systems were beneficial for the project or not. It includes asking questions like: a) Are procedures current and relevant? b) Are checklists and templates current and relevant? c) Are the mandated reviews and control points appropriate? and d) Is the PMIS useful?

Evaluate Team and Personal Performance - The team then considers how well they executed the plan and followed the methodology. This is normally a self-assessment by the team and can be aided with techniques such as 360 reviews. With respect to formal personal performance appraisals, I recommend that this be done for the core team members on all large projects. The method for conducting the performance appraisal must be accomplished in accordance with local Human Resource practices.

Project Management Monitoring and Controlling Tools & Techniques

Monitoring and Controlling a project is the process or activities whereby the project manager tracks, reviews and revises the project activities in order to ensure the project creates the deliverables in accordance with the project objectives. Because of the unique and temporary nature of projects, they require active control. Unlike a process where the same set of activities have been performed repeatedly so that habits and expectations are stable, a project is inherently unstable. The activities are unique to the project or the sequence of activities and resources are only temporarily assigned and associated with the project and are redeployed when the project completes. Habits and patterns are not established before everything changes.

The primary results of the Monitoring and Controlling processes are the project performance reports and implementing project changes. The focus for project management is the analysis of project performance to determine whether a change is needed in the plan for the remaining project activities to achieve the project goals. In my experience, almost every project will require a change to the plan at some point in time. Traditional projects are the most stable projects because the requirements and the activities are clear and well understood. Adaptive and Extreme projects are the least stable. They require very close control and will require numerous changes - if for no other reason the project manager will need to refine the activities of later phases based upon the results of early activities.

Tools and techniques that are used by project managers to conduct the Monitoring and Controlling of a project fall into one of four general categories. The first is the collection of project performance information. Techniques supporting this category are Pulse Meetings, Variance Reports, and Program Reviews. The second category is the analysis of the project performance to determine whether a project change is needed. Techniques that are used in this category are Technical Reviews, Project Forecasting and Problem Solving. The third category is reporting on project performance. Techniques that support this activity include the use of a Project Management Information System, Management Reviews, and Dashboards. The final category is the management of project change. The technique I commonly use in this category is the maintenance of a Change Management Log. There are two areas of project management tools and techniques that closely support the Monitoring and Controlling process but are also used more broadly throughout the project lifecycle. These are important enough to justify their own page.

Project Communication Tools and Techniques

Earned Value Analysis

Pulse Meetings

Pulse meetings are short team status meetings where the project management team is able to gather project performance information about the activities that are underway. These meetings should occur frequently and can either be face-to-face or virtual. Normally they are only a few minutes in duration. During the meeting, the beginning and completion of project activities is reported. In addition, the status of any activities that are underway is communicated to the rest of the project management team. Issues on any of the ongoing activities are identified, however, the issue resolution occurs at a separate meeting with the appropriate individuals present. The issue resolution meeting may immediately follow the Pulse meeting, but it is clearly a separate meeting and those project team members who are not needed for issue resolution do not need to attend. The frequency of the Pulse meeting is determined based upon the status of the project. When in an Extreme mode, the Pulse meeting may be happening several times a day. Projects that are running smoothly may only need to have a Pulse meeting once a week.

Variance Reports

Variance reports are formal reports generated by the PMIS, by the Earned Value Management System, one of the other business management systems - such as the quality control system, or by a project supplier. Variance reports compare what has actually happened on a project against what was expected to have happened on the project. A variance report typically indicates both the absolute value of the difference and a percentage representation of the difference.

The actual performance achieved on a project activity (such as cost or duration) seldom precisely matches the estimated performance set at the time of project planning. The page on Estimating explains why project estimates are seldom precisely accurate. However, since the estimates often aren't accurate, it is imperative for the project management team to identify the variances in order to know what is actually happening on the project. The variances can uncover both positive and negative project risk.

Project variance reports often are expressed with two references. The first reference is what was supposed to have happened since the last reporting cycle. This is often called the "Current Period" variance. It is an indication of how well the project resources were able to conduct project activities in accordance with the project plan in the recent past. The second reference is what was supposed to have been done on the project since it started. This is often called the "Cumulative" variance. It is an indication of how well the project resources have been able to conduct project activities throughout the project lifecycle. The cumulative variance will have embedded in it any previous variances - either positive or negative. The current period variance provides a clear representation of what is happening right now on the project. The cumulative variance eliminates the effects of any short term conditions, either good or bad, that effected the project during the most recent reporting period. Both variances provide useful information.

Program Reviews

Program Reviews are meetings with the project team members and sub-project leaders that review the current status of the program as compared to the original program plan. These are most often used on Full-scale and Complex projects. Unlike the Pulse Meetings which focus on day-to-day activities, the Program Reviews focus on the big picture and emphasize the integration between activities and between sub-projects encompassed within the program. The question being asked is whether the program activities and the sub-projects are likely to interfere with each other. In addition, when I have a supplier who is a major contributor on the program and is performing customized work on this program, I will conduct Program Reviews with the supplier for their portion of the program. Program Reviews are sometimes combined with Management Reviews. I do not recommend this approach. The danger with this approach is that key stakeholders and managers may intimidate some project team members from providing a frank and honest appraisal of the status of program work.

Technical Reviews

Technical Reviews are formal meetings conducted with subject matter experts who are not members of the proejct team. These are in-depth reviews focused upon a technical aspect of the project. Examples would be Desgin Reviews, Code Reviews, Security Reviews, or Production Readiness Reviews. The reviewers should perform an in-depth analysis of the project deliverables and activities to determine whether the project work has been accomplished completely and correctly. These reviews will normally generate a list of actions that must be completed. These actions may require additional testing or analysis. In some cases it may even require redesigns of systems, software, processes or products. The results of these reveiws are normally reported to senior management at the next Management Review. In many cases, the technical review must be completed before a project can proceed to a toll-gate meeting. When the Technical Review is linked to a toll-gate meeting, the action items do not need to be completed prior to the toll-gate. However, any open action item is listed on the risk register and the plan for resolving that action item is included in the project plan for the next phase.

Project Forecasting

Project Forecasting consists of taking the project status information and extrapolating the current project performance to the end of the project. Forecasts can be made with respect to project duration, overall project cost, performance/quality level of project deliverables, or any combination of these. A key element in forecasting is to review the risk events that occurred and the remaining risk triggers. A deeper discussion of this is found on the Project Risk Management page. A caution when doing forecasting, ensure you have adequate information to realistically forecast performance. My personal rule of thumb is that I wait until an activity, phase, or deliverable is at least 25% complete before I try to forecast. Prior to that point I stick with the original estimate, modified by any appropriate risk mitigation activities that have occurred.

When forecasting project duration, the key is to understand the schedule performance and schedule risk of the activities on the critical path. Those activities will be the ones that drive the project completion date. On a resource constrained project, or a project with unpredictable resource availability, this can be very difficult because the lack of resources causes the critical path to vary. I have not found a good robust tool for forecasting schedule in this condition. It generally comes down to expert judgment and gut feel. When it is vital for the project to complete by a certain date, I often will convert my schedule tracking to a countdown mode where everything is measured in terms of how many days before project completion. Also, I will Pulse the project more frequently in order to quickly assess when I believe we are falling behind. If that sounds like micro-management it is because that is micro-management.

When forecasting total project cost, I prefer to use the forecasting methods that are embedded in the Earned Value Management system. Unfortunately, many organizations do not have the financial systems in place that enable earned value management. When that is the case, I am forced to rely on trend forecasting - which is sometimes called "straight-line" forecasting. Trend forecasting takes the current project spending and extrapolates that rate of spending until the end of the project. This provides a rough forecast, but it does not take into account the effect that different activities may require resources that spend at different levels. The resources that perform the remaining activities may be higher or lower cost than the preceding resources. Also, it does not take into account that the project may be ahead or behind schedule. If the project is ahead of schedule, the spending done to achieve that condition inflates the extrapolated value of the project final cost. If the project is behind schedule, the lack of spending creates an extrapolated value of total project cost that is too low.

When forecasting the performance or quality of project deliverables, I rely heavily on prototypes and preliminary analysis. When the project does not have these, the risk that the project will not achieve the desired performance or quality established at the time of project planning is higher. If performance is the most important attribute of the project deliverables, then the risk of missing the forecast project duration or cost is much higher. The principle involved is the "Rule of Ten's." According to this principle, the cost to correct a technical issue goes up by a factor of 10 as the project moves from one phase to the next. Therefore it is imperative that performance issues be identified as early as possible.

Problem Solving 

Problem Solving is a very broad topic. There are dozens of approaches to problem solving. My rule of thumb with respect to this technique is that if you have a process that works for you, use it! I recommend you have an agreement with your project core team members or key project stakeholder concerning the problem solving process that will be used. Will it be team-based or individually driven? Will you use a process that relies on data from past projects or only on data from this project? Once a root cause is determined, how will recovery actions be identified and approved? As I said, there are many problem solving methods and their answer for these questions and others is different. From my standpoint, the most important point is that you have a process to address issues, rather than jumping to conclusions or worse yet, ignoring the problem until it is a crisis.

If you don't already have a problem solving process, may I suggest this one that I refer to as CIV2:

1. Clarify: Clarify the problem. In which part of the project did it occur? Who was involved? When did it happen?

2. Investigate: Investigate the details about what happened. Gather data from both the project activity and the surrounding environment. Determine the root cause(s) of the problem.

3. EValuate: Evaluate the options to address the problem. Consider the impact on the project objectives that each potential solution would likely have. What new risks are associated with each potential solution.

4. Choose: Choose among the viable solution/recovery paths. If necessary, coordinate the decision with key stakeholders. This must be done whenever the solution will impact a boundary condition of the project.

5. Implement: Implement the selected solution/recovery path. Modify the project plan with respect to any changes in scope, resources, or scheduled dates of any activities. Update the risk register.

6. Validate: Validate that the solution/recovery path is achieving the desired results.

Project Management Information System

The Project Management Information System (PMIS) was discussed in detail on the Executing Tools and Techniques page. The PMIS is the set of communicating methods used by the project team to share plans and results of project activities. The PMIS can either be a physical system or an electronic system. Either way, the PMIS is used as the clearing house of information on the project including; project plans, project status, project risks, project changes, project meetings, and any other information that project management team believes is relevant to the project team.

Management Reviews

Project Management Reviews are formal documented meetings with the project team and key stakeholders that review the current status of the project as compared to the original project plan. Unlike the Pulse Meetings and Program Reviews which are data gathering meetings that focus on understanding the current status of the project, the Management Reviews are with key stakeholders with the emphasis being on whether the project performance is adequate for the project to deliver on the overall project objectives. Often if the project has encountered issues, such as resource constraints or scope creep, the stakeholders conducting the review are able to provide assistance to the project team to overcome these issues.

The format for these reviews is usually set by the stakeholders and addresses the topics that are most important to them. The review may be a formal stand-up meeting, it may be an informal discussion setting, a written report, or an update to an electronic dashboard. Regardless of the method used, these are formal status reporting meetings and need to be treated as such. The project manager should keep an Action Item list or Stakeholder Issue log for any questions that arise in these reviews. Also minutes from these meetings should be maintained as part of the project records.

Project Dashboards

Dashboards have proliferated as more organizations start to manage projects within the context of a portfolio of projects. A dashboard is a great method for capturing a snapshot of a project and presenting that to stakeholders. Dashboards contain a small subset of project status information that is used as indicators of whether the entire project is on track. The dashboard information is used to make decisions concerning changes to projects or to the project portfoliio.

Within a project team, Dashboards were used by project managers to focus the project team on the few key items that would drive project performance. Therefore the current critical path activity is tracked for schedule status, the current activity with the most uncertainty in resource requirements is tracked for cost status, and the most challenging activities are tracked for project performance/quality. This is an excellent use of dashboards, especially when working with a virtual project team.

As more organizations decided to manage their projects as a portfolio of projects, they have recognized the need to have a means of measuring the projects in the portfolio both against each other and with respect to their objectives. The dashboard offers that mechanism as each of the projects report on key metrics that are used by the senior management or Project Management Office to check the status of the projects. Often the dashboard measures the status through the "Red light - Green light" method. This type of scoring uses colors to indicate project status on the key measures. A "Green light" indicates that everything on the project is going according to plan. A "Yellow light" indicates that there are some problems, but the project team is working the situation and should be able to contain the problem. A "Red light" indicates that the problem is so severe, the project team cannot resolve the problem and achieve the project objectives without help from the stakeholders. The senior management team and PMO use the Dashboard to make resource allocation decisions and to call special Project Management Reviews.

Change Management Log

This tool is very straight-forward. The need for it increases as the project complexity increases. I can't imagine running a Complex project without one, but I have never used one on a Simple project. The necessity on a Complex project is because these projects are managed as a set of Focused and Full-scale sub-projects. The boundaries between these sub-projects will inevitably need to change as projects progress. Sometimes the changes are due to shifting milestones. Sometimes the changes are the result of activity deliverables that are passed between the projects. In any case, the changes in one sub-project cascades into changes in another sub-project. The Change Management Log tracks the implementation of the change across the sub-projects. It can also track the implementation of the change within a project, especially if the project activities are conducted in multiple locations or if there are multiple phases underway at one time. Using the Change Management Log is similar to using an action item list. Each item is tracked to ensure it has been completed.

Earned Value Analysis

The fundamnetal characteristics of all business financial transactions are the amount of the transaction and the date of the transaction. These two components are equally important in financial planning and tracking systems. Traditional financial planning and tracking systems are not compatible with the project environment.

Traditional financial planning and tracking tools do not fit the project context. For instance, the traditional financial planning tools are tied to annual budgeting cycles not project schedules. Also, traditional financial planning tools assume the business will be in the mode of continuous operation so if activity slows in one area, the resources will be shifted to another and the expenditures will stay constant. This levels out the resource requirements and eliminates spikes and valleys in resource needs. However, projects often don't operate in that fashion. Projects activities are planned with start and stop dates and resources are assigned and removed from the project plan throughout the project life-cycle. Therefore some of the major assumptions on which financial planning tools are based are invalid in the project planning environment.

Further, traditional financial accounting systems make some assumptions when tracking costs that are not valid in the project control environment. For instance, the tracking cycle used in financial systems is based upon calendar events such as end of month, end of quarter, or end of year because these are major reporting points to taxing authorities and investors. However, the significant project reporting points are the project milestones; which seldom precisely align with finanical calendar dates. An additional assumption in the financial systems is that the business is on-schedule - again because of the financial planning calendar it is impossible for the business to get behind schedule. There is no such thing as stretching December out to have 37 or 38 days. The financial control system assumes the project is always on schedule, so any over-spending or under-spending during a time period is a true over-run or under-run on the project. However, a project is seldom precisely on schedule, and over-spending in one month may be the result of activities being delayed or accelerated and do not necessarily indicate the final project spending will be over-run.

The Earned Value Analysis (EVA) technique takes into consideration the project context for the planned and actual expenditures and integrates the project scope, schedule, and resource characteristics into a comprehensive set of measurements. This page will outline the use of Earned Value Analysis by addressing Financial Databases for EVA, Earned Value Definitions, Establishing Earned Value Budgets, Determining Earned Value, Variance Analysis, and Forecasting.

The Earned Value technique allows for the temporary and intermittent nature of project work by scheduling the expenditures based upon the project plan, including the spikes and valleys in resources requirements. Further, Earned Value tracks how much money has been spent on the project in relation to how much project work has been accomplished. This takes into consideration all that has happened on the project such as schedule delays or acceleration. The variances that have occurred can then be separated into those due to timing, either ahead or behind schedule; and those due to mis-estimating the work; true under-runs or over-runs. Finally, the indices and variances generated by the Earned Value technique will aid the project management team in forecasting the financial conditions at project completion.

Financial Databases for EVA

The EVA techniques manipulate information gleaned from three essentially independent sources of financial data. Each of these are a cost baseline for the project. Each looks at the project from a different perspective.

The planned project expenditures (Planned Value) from project start until the present time. This is established at the time the project was initially planned and represents the original intent of the project team. It is developed by summing up all of the project task estimates and time-phasing them based upon the project schedule.

The actual project expenditures (Actual Cost) as of the present time. This is collected by the business financial cost accounting systems. These are all the costs associated with the work that has been completed on the project up through the present instant in time.

The actual project progress (Earned Value) which is the originally planned expenditures for the work that has been accomplished up to this time. This is determined by the tasks that are completed or the progress made on the tasks that are underway. The key to this measurement is that the values for each task are based upon the originally estimated values for the task. Each task is assigned a "value" that is embodied in the original task estimate. When the task is completed, the estimated value represents the value earned by completing the work on the project task - regardless of how much that work actually cost.

Earned Value Definitions

EVA is known for its acronyms. This table shows the acronym, using both the old naming convention and the new naming convention. Each of the acronyms is defined in more detail below.

Planned Value (PV) is developed by first determining all of the work, or tasks, that must be accomplished for a successful project result. The work within each of the tasks, whether done internally or outsourced, is estimated. That estimate is converted into a monetary value which represents the dollar portion of "planned value" of the task, essentially saying that the task has that worth to the business. This value is then scheduled to occur based upon when the task is scheduled to occur within the project plan. Once the amount and timing is established, the PV for the task or activity is set. It can only be changed by implementing a project change.

Actual Cost (AC) is the number that finance often is most concerned about because this represents the actual cash that the business has had to expend on the project. The AC is determined based upon the accounting system's method for cost accumulation. Where possible, it is most helpful to collect the costs based upon a project charge number or account number that is associated with the costs. This number may change every day based upon whether project work was conducted upon that day.

The Earned Value (EV) comes from an assessment by the project management team as to the amount of progress they have made on each task in the project. Often this is difficult to measure precisely and is based upon a judgment call by appropriate individuals within the project. Tasks that are completed have earned the entire value for that task. Tasks that have not been started have not earned any value for that task. Tasks that are partially complete may have earned some value for the work that has been done. The total amount of value available for a task to earn is the value assigned to that task at the time of project planning--in other words, the Planned Value for that task. It is easy to determine EV for tasks that have been completed (EV is the task PV) and for tasks that have not started (EV is zero). The difficulty comes when estimating the EV for a task that is underway. Suffice it to say, most organizations have set some specific ground rules in this area to ensure the EV is not under-stated or over-stated. Methods for determining EV are discussed below.

The remaining acronyms will be explained in more detail as variances and forecasting are discussed later on this page.

Establishing Earned Value Budgets

EVA is based upon task or activity planning data and therefore requires that a relatively rigorous planning approach is used, often using the bottom-up estimating rather than top-down. The project PV at any point in time is determined by summing the task-level budgets for the time period in question. Accuracy in the task level budgets is required both in the amount of effort estimated for the task but also in the timing of when those efforts will be expended. The key here is that we want to estimate the project task timing in the same way that the financial system will record the AC for the task. In most businesses, the personnel costs are collected and analyzed either weekly or biweekly because of the need to run payroll. Therefore I recommend that the in-house labor in a task should be spread evenly during the task duration, which is called "level-loading," while tasks that have external expenses often are recorded in a lump sum based upon when the supplier submits an invoice. For instance, an invoice received from a testing service would come in as a charge on one day although the testing may have occurred over a period of several months. In those cases it is often better to "event-load" based upon the expected timing of the receipt of the invoice. It is even possible to use a combination of timing approaches when estimating the PV for a task.

Selecting the appropriate timing is important so as not to create confusion later when we determine variances. A variance due to planning the timing of a task expense differently than the time when the expenses actually occurs, even though the amount is accurate, still generates the need for a variance report. Creating a task-level budget that accurately reflects the timing of expenses will reduce the need for a variance report for timing reasons. Variance reports will focus on true under-runs or over-runs.

Determining the Earned Value

Determining the EV for a partially completed task is at the heart of EVA. Therefore it is important that the EV be as accurate as possible. However, EV is a judgment call while a task is underway. If the project management team under-states or over-states the EV, they can change whether a project is perceived to be running well or in significant trouble. Over time some approaches have been developed for estimating EV. These provide guidance to the project management team and can improve the accuracy of the EV.

The best approach is to have detailed tasks planning with a percentage of PV assigned to each item or interim milestone within the task. Then as soon as that item is complete, that amount of EV has been earned. However, this does require very detailed task planning and often that planning has not been done, either to save time or because there are no obvious interim steps within the task.

Another technique is the "0-100" technique. In this approach, no EV credit is allowed for a task until the task is completed. This is a good approach for short, discrete tasks, such as "Place Purchase Order."

The "50-50" technique is also commonly used. In this approach half of the EV is credited to a task once the task is started and the other half is credited once the task is complete. This is usually done when the task is relatively long and will span multiple reporting periods. This emphasizes the start of tasks and encourages tasks leaders to begin work as soon as possible on a task.

My personal favorite of the quick estimates is the "30-70" technique. In this approach 30% of the EV is credited to a task at the time of the task start and the remaining 70% is credited when the task ends. This is a good approach to use when a task has an uncertain estimate, such as software debugging. There is the recognition that work is underway, but the emphasis is on completing the task.

Earned Value Variance Analysis

EVA provides excellent insight into project variances. Through EVA a project manager can understand how schedule variances are impacting cost variances and vice versa. Without EVA, the project manager is at a disadvantage when trying to explain to finance why the expenditures were other than expected.

Once we have the PV, AC, and EV for a project, we can begin to calculate project variances and determine the current status of the project. The first variance I will discuss is Cost Variance (CV). This is the amount of under-run or over-run the project has experienced. As with all of the measurements, I can address the Current CV, which is the variance this month, or the Cumulative CV which is the variance since the project started.

CV = EV - AC

In EVA, a negative CV is an over-run and a positive CV is an under-run.

With the Earned Value technique, the CV is calculated by subtracting the AC from the EV. This is essentially asking, "How close am I to what I thought it would cost do the work I have accomplished as compared to what it actually cost to do the work that is accomplished." Because both EV and AC are only considering the work that is actually accomplished, the errors due to schedule variance are removed. The first set of figures shows how a project that is on schedule, but is either in an under-run or over-run condition, would be reflected in both a Gantt chart and with EVA data. The task is a two week task that started one week ago. The task is on schedule, meaning it is 50% complete and therefore the EV is the PV. In the top case, the task is on budget so AC = EV and the CV is zero. In the second case, the AC is $6,500 but the EV is only $5,000 so the CV is -$1,500 and the project is over-run. The third case shows that the AC is $3,500 and the EV is $5,000 so the CV is +$1,500 under-run.

Next we will consider Schedule Variance (SV). This is the amount ahead of schedule or behind schedule the project is currently experiencing. An interesting point about SV is that it is measuring schedule but the units are dollars. SV measures the VALUE of the work that is ahead or behind schedule, not the number of days or weeks. As with all of our measurements, we can address the Current SV, which is the variance this month, or the Cumulative SV which is the variance since project start.

SV = EV - PV

In the Earned Value technique, a negative SV is a behind-schedule condition and a positive SV is an ahead-of-schedule condition.

When considering the value of work that is ahead or behind schedule, the value of any under-runs or over-runs needs to be excluded. The Earned Value technique compensates for this. With the Earned Value technique, the SV is calculated by subtracting the PV from the EV. This is essentially saying, "The value of the work that I have completed minus the value of the work that I had planned to have completed by this time." Because both EV and PV are only considering the work using the originally estimated value of the work, the errors due to cost variance are removed and variances are due only to timing.

The next set of figures shows how a project that is behind schedule, and is either in an under-run or over-run condition, would be reflected in both a Gantt chart and with EVA data. The task is a two week task that started one week ago. The task is behind schedule, it should be 50% complete but it is only 30% complete and therefore SV is -$2,000 in all three cases shown. In the top case, the task is on budget since the AC of $3,000 matches the EV for the work that is done. In the second case, the AC is $4,500 but the EV is only $3,000 so the CV is -$1,500 and the project is over-run. Notice, that the project is not over spent at this point. Without the EVA analysis, the project team could be fooled into thinking they are in an under-run condition. In actuality they are over-run and behind schedule. The third case shows that the AC is just $1,500 and the EV is $3,000 so the CV is +$1,500.

A project may have spent the exact amount of money up to a point in time that had been budgeted for that time period. However, if only half of the work had been accomplished, the EV would be one half of the PV. This would indicate a significant behind schedule condition and a significant over-run, even though the money that had been spent was exactly what had been in the plan for spending up to that point. The problem is that now there is no money budgeted to do the work that was scheduled to have been done but has not been completed.

The final set of figures shows how a project that is ahead of schedule, and is either in an under-run or over-run condition, would be reflected in both a Gantt chart and with EVA data. The task is a two week task that started one week ago. The task is ahead of schedule, it should be 50% complete but it is already 70% complete and therefore SV is +$2,000 in all three cases shown. In the top case, the task is on budget since the AC of $7,000 matches the EV for the work that is done. In the second case, the AC is $8,500 but the EV is only $7,000 so the CV is -$1,500 and the project is over-run. The third case shows that the AC is just $5,500 and the EV is $7,000 so the CV is +$1,500. In this case, without the EVA analysis the project team could be fooled into thinking they are over-run since they had spent more than the $5,000 that was budgeted to be spent at this time. In actuality they are under-run since they have completed 70% of the task and not just the 50% in the plan.

The SV and CV variances are sometimes provided in percentage form rather than in actual value.

Forecasting Using Earned Value

The variance calculations for SV and CV give us specific values of under-run/over-run. We can also calculate indices that give us trends and that can assist in the estimating of final project cost. The two indices generated in the Earned Value technique are the Schedule Performance Index (SPI) and the Cost Performance Index (CPI).

SPI = EV / PV

The SPI is the ratio of Earned Value over Planned Value. When the EV is greater than the PV, we are doing more work than scheduled and the project is accelerating. The SPI will be greater than 1 in that case. When EV is less than PV, we are doing less work than scheduled and the project is being delayed. The SPI will be less than 1.

CPI = EV / AC

The CPI is the ratio of Earned Value over Actual Cost. When the EV is greater than the AC, we are completing the work for less than the estimate and the project is under-running. In that case the CPI is greater than 1. When the EV is less than the AC, then the cost to complete the work was greater than the initial estimate, or value, of the work. In this case we are over-running and the CPI is less than 1.

A question frequently asked of project management is, "How much will this project really cost to complete it?" At the beginning of the project an estimate is made. This estimate is normally set as the project budget and is referred to as the Budget at Completion (BAC). This is also the final PV for the project when the project plan is created. But the BAC contains many assumptions and is seldom realized precisely. Therefore, the question is a legitimate one. As the project progresses and we learn more, the assumptions are proved true or discredited.

Project management is then called upon to make a new estimate of the final cost to accomplish the project. This estimate takes into consideration the current business conditions and the relevant project experience to date. It is referred to as the Estimate at Completion (EAC). The EAC is the answer to the original question. It includes all of the money spent so far on the project and an estimate of what must still be spent to complete the project work.

EAC = AC + ETC

The Earned Value technique uses the variances and indices to calculate an EAC. This is done by taking the results of what has been spent already on the project, the AC, and adding to that an estimate of the cost to do the remaining open work on the project. This estimate for the remaining work is referred to as the Estimate to Completion (ETC).

It is obvious that in order to have an accurate estimate for the final project cost, the EAC, we need to calculate the ETC. There are several methods. These four are the most widely accepted.

Method 1. In this case I consider that whatever cost variance that has occurred on completed tasks is an isolated event. I do not think it is a trend and therefore the original estimate for the cost to complete the remaining work is unchanged. In this case the ETC is the value of all the work on the project that has not been done yet. It is determined by taking the total value of the work on the project (BAC) less the work that has been completed (EV).

ETC1 = BAC - EV

Method 2. In this case we consider that whatever cost variance that has occurred is a good indicator of what we can expect in the future, so we will extrapolate the trend through to the end of the project. This is done by determining the remaining work on the project (see Method 1) and dividing that by the CPI; which indicates the trend of under-run or over-run.

ETC2 = (BAC - EV) / CPI

Method 3. In this case we assume that there is a need to complete the project on time. Therefore, if the project is behind schedule, an effort will be made to accelerate the remaining tasks. This acceleration will cost money so the remaining work is also divided by the SPI; which indicates the trend of schedule variance that must be overcome to complete on time. Normally when this method is used, the estimate for the remaining work is based upon the Method 2 approach of considering any over-run or under-run trend.

ETC3 = (BAC - EV) / (CPI * SPI)

Method 4. At times we become convinced that the original estimate is so far off, or that the variances are neither isolated or clear trends, that we create a new estimate for the remaining work. This is often done when schedule acceleration techniques such as crashing or fast-tracking are used.

ETC4 = New estimate for the remaining work

The project management team uses whichever method they believe is the most accurate way to estimate the cost of the remaining work. Ultimately this is a judgment call based upon their understanding of the project.

Project Management Executing Tools & Techniques

Project Execution is the process or activities associated with completing the project activities defined in the project plan in order to meet the project objective defined during project initiation. This is the portion of the project where most of the project effort is expended. The focus for project management is the application of resources to project activities and the collection of information concerning the results of the project work.

The primary results of the Executing processes are the project deliverables and project performance information. In addition, when issues are uncovered while performing project activities, requests for changes to the project plan should be generated.

Once the project plan is in place, the most important aspect of successful Project Execution from a project management perspective is to ensure that appropriate resources are applied to each project activity so as to correctly complete the activity on time and on budget. The project manager must use the internal and external resources available to the project to ensure this happens. The management of internal resources is such as important topic that it is discussed on its own page:

Project Team Leadership Tools and Techniques

The application of external resources will be discussed below in the section on Conduct Procurements. Even with the application of the correct resources, sometimes the results of the project activities will be other than what was expected. Therefore the other aspect of Project Execution to discuss is the use of a Project Management Information System. This system will collect the data that is eventually used by the Project Control processes.

Conduct Procurements

Conducting project procurement consists of contracting with suppliers and vendors to perform the project activities that have been designated to be outsourced. The Project Planning page discussed how to determine the level of project management oversight required for a given project procurement. Now that the relationship has been determined, a supplier who is capable of performing the activity must be placed on contract. This entails typical procurement activities such as source selection and negotiations. The activities associated with administering the contract will be addressed in the Project Monitoring and Controlling page.

Project Management Information System

The Project Management Information System (PMIS) is the set of communicating methods used by the project team to share plans and results of project activities. Years ago we recommended that the team establish a central location where information could be posted for all on the team and the stakeholders to see the status. We called those project "War Rooms" - but in today's politically correct world we call them Project Management Information Systems. Another change from what we did years ago is that the typical PMIS today is an electronic system. It is an e-room, a website, a common folder on the shared drive, or a common file with different levels of access for review and update. In my experience, a PMIS today will be in one of the following forms. Which one you choose should be based upon the team dynamics and the organizational culture.

Project management software file available in a shared location.

This approach is generally used with Full-scale and Complex projects. In those cases the project complexity is so high that project management software is used because of its superior capability to track inter-relationships between project activities and project resources. This is the best PMIS approach for highly complex projects. The disadvantage with this approach is that all of the stakeholders and team members must be trained and competent at using all of the features of the project management software. Some of the software programs are complex and awkward to use. They can require a significant amount of time creating a project plan and then maintaining the project status. They require special training to know how to read information and to update information. If the stakeholders and team members are not frequently using the software, they have difficulty reading and maintaining project information.

To overcome these problems, companies are beginning to hire Project specialists who are experts with the project management software. These individuals will creaet and maintain the project plan in the project management software. They then create reports in standard formats that are provided to both team members and stakeholders.

Spreadsheet file(s) available in a shared location.

This approach is generally used with Simple and Focused projects. In those cases the project complexity is simple enough that the project activities can be planned and updated using several columns of a spreadsheet. This is often referred to as a WBS Dictionary, which is discussed in more detail on the Scope Planning page. The spreadsheet is typically easy for project team members and stakeholders to access and understand. The spreadsheet is able to manage a great deal of data and information. The disadvantage when using a spreadsheet for the PMIS is that it is difficult to track complex interactions between activities.

Meeting room or meeting space with a whiteboard, walls, and Post-it notes.

This method harkens back to the days when we used "War Rooms." This technique is often used with Extreme projects because of their rapid change and redirection. With the advent of modern technology the room may now be a virtual room instead of a physical room. When it is a physical room, the team meets regularly in the room to plan and track project activities. When an activity is completed, the information about the execution is posted on the whiteboard, a Post-it note, or some other document that is posted on the wall. When the room is a virtual room, the team meets in the virtual world and each participant posts their information using the tools of the virtual room technology. The advantage with this technique is the ability to quickly react to changing project conditions. The disadvantage is that everyone must have access to the physical or virtual room and if it is a virtual room there is the need for training in the use of the technology.

Project Management Communication Tools & Techniques

Communication is an essential part of project management. I have never met a successful project manager with many projects under their belt that was not a good communicator. This is due to the inherent nature of project work as compared to process work. Projects are unique one-of-a-kind set of activities. If we did exactly the same thing in every project, the same way, with the same people, and in the same sequence, then project manager communication skills would not be as important. An individual could be trained for a job, placed in it and the expectations would be clear. But project work is always different. That is why we need good communication. Those working on the project need to understand what is required on this project, when it is required, how it should be done, and what other activities it must integrate with. Without good communication, projects fall into chaos.

The methods and frequency of communicating will vary from project to project. One of the most important considerations is the project complexity. Simple projects require a minimum of communication, since it is usually a one person team and only one stakeholder involved. Focused projects require more communication planning and execution, but they typically are still relatively straight-forward since there are only a few people on the team. The project manager can often handle the communication through informal channels such as one-on-one meetings or calls to all of the team members and stakeholders. When the complexity grows to the size of Full-scale projects, the communication focus needs to shift. Now the project manager must spend dedicated time keeping everyone on the project aware of status, issues, and changes. Also, there are usually many stakeholders and stakeholder meetings on Full-scale projects. Once the complexity grows to the size of a Complex Program, the program manager is spending virtually all of his or her time doing communication and risk management. In fact, you could argue that communication IS risk management. These programs are typically managed as a portfolio of integrated sub-projects. The program manager is continuously communicating between the sub-projects to ensure they stay integrated and to guard against a problem in one sub-project cascading into all of the others.

Tools and techniques that are used by project managers to aid in communicating start with the Communications Plan. To develop a communication plan, a project manager will often do a Communication Technology Assessment. Of course, a Team List should be developed. Naturally, I recommend that when conducting a meeting - use good presentation skills, when composing a message - use good writing skills, when having a face-to-face encounter - use good interpersonal skills. However, these are not unique to projects so I am trusting you can get help on these from your Human Resources or Training department and you don't need me for that. I will stay focused on the parts of communication that are unique to project work.

The PMBOK includes Stakeholder Management activities in its communication chapter. I have placed the stakeholder management activities in Project Initiation and Project Controlling pages. Although those activities entail communicating, they are so integral to Initiating and Controlling that I felt it was better to address them in those sections.

Before I start to discuss the communicating tools, there are two topics I would like to address. The first is the understanding of a "Sender - Receiver" model. Whenever information is being communicated, it is translated from the sender's mind into a message and then from the message back into the receiver's mind. There are opportunities for misunderstanding in both translations, and for noise and errors to be introduced during the transmission of the message. That is why I believe every project leader meeds to focus on communication. Since project work is often new or unique, the chance for misunderstanding is even greater. There is no established pattern or expectation. I strongly encourage the habit of "Repeat it back." for all project communication to minimize misunderstanding.

The second is the recognition that listening is a three step process. If a team member does not seem to be listening, it is important to understand which step of the listening process is the issue. The three steps of listening are: 1) hearing, 2 understanding, and 3) judging. The Hearing step is just that. The actual receipt of the message. Team members who "aren't on the call" will not get the message. For vitual team members you may need to create special channels of communication to ensure they actually hear the message. The Understanding portion of the listening process is the team member translating the message into desired actions or changes to the project. Team members who do not understand the acronyms or whose native language is different than the normal language of project communication may hear the message that is being sent but not understand what it means. To determine if this is the problem, the project leader will need to have a directed conversation with the team member and ask them what they think the message is telling them to do. The third listening step is Judging. In this step the team member hears and understands the message and then decides whether or not they believe it applies to them and their project work. When this is the breakdown in listening the project leader will need to spend time with the project team member to determine either why the message does not apply in this special case or to explain to the team member why the message does apply to them.

Project Communication Plan

Every project manager uses a Project Communication Plan. Many project managers do not consciously develop one, instead they embrace one that has been imposed upon them from a previous project, they follow a procedure instituted by the PMO, or they conduct their communication in an ad hoc fashion. That is an approach for developing a plan - not a very good one - but an approach. I recommend that a conscious decision is made as to what communications need to occur for a successful project. I typically consider four categories of communication. All four types are not needed on every project, but they are typically found and should be planned for.

The first category I consider is management meetings. This category is often an extension of the Communication Strategy for stakeholders that I discuss in the Project Initiation page. For this category, consider which managers need or want information, the frequency they need or want it, and the content detail. Major communication sessions with stakeholders, such as technical reviews that I discuss in the Project Control page are often reflected on the project schedule as milestones and should be included in this portion of the Communication Plan. The management meetings should be planned and proper preparatin conducted. Some of these are face-to-face meetings and some are conducted using an electronic medium. A poor management meeting jeopardizes support for the project and reflects badly on the work of the project team.

The second category of meeting is the project team meetings. Depending upon the size of the project and the team, these can be short ad hoc conversations, conference call updates, email chats, formal pulse meetings, or a variety of other communication approaches. Regardless, these are where the project manager is able to track the day to day work of the project and resolve issues while they are still small.

The third category I like to consider is management reports. Many organizations require project managers to provide periodic reports for the management team. Often these are reviewed by managers who are not direct stakeholders in the project. These reports need to be able to stand alone in describing the project and its status. A project manager cannot assume the reader is familiar with the goals or risks in the project. That is why it is important to use the standard template or format the organization suggests/requires. The standard template guides those who are not familiar with the project to the areas of the project report that they are concerned with.

The final category that I consider is project records. These are the method that the project team uses to communicate to the future. Whether the future is teh business team members who use the project deliverables to implement business stategy, the next generation project, archives for litigation, or records for lessons learned, the records need to be complete enough so that whoever is reading them after the project has completed will be able to understand what has happened.

Communication Technology Assessment

The type of communication technology used by the project manager will vary based upon the organizational constraints of the project team and stakeholders. Factors that influence the technology include whether the team is co located, the confidentiality of any information that needs to be shared, communication facilities available to the team members, and the organization's culture for how meetings and disucssions are normally conducted. Some technologies lend themselves to large group interactions and others are more appropriate for one-on-one discussions. The table below provides an assessment of the advantages and disadvantages of different communication technologies for use in a project environment.

Project Team List

The Project Team List is a list or database with all project team members and their contact information. This includes the core project team members and extended team members. I typically will also include key stakeholders on this list. The list is provided to team members to aid communication. I want project team members to know who to call when they have a question or an issue arises. The list can be maintianed in as a spreadsheet, a word document, a file for your email server, a contact list in your project eroom, or any other mechanism that is a normal resource contact management system in your organization. One caution about the list, I provide business contact information, but not personal information. In this era of identity theft and the increase of "creepy people" I try to protect the team member's privacy as much as possible.