10

Controlling a Project

Now that we have our project plan, we are ready to implement it. From a project management perspective, implementing a project plan involves two general categories of activities: project execution and project control. These activities are performed in parallel to complete the work of the project, report project progress, and keep the project on track. For the purposes of this book, we will address the process-focused activities in Part III of the book, “Project Control,” and the people-focused aspects in Part IV, “Project Execution.”

Although there are entire books and courses that address just single aspects of project control and project execution, we focus on the “need-to-know” fundamentals that will greatly reduce your learning curve and accelerate your effectiveness as a project manager.

This chapter serves as an excellent bridge between the “Project Planning” part we just completed and the “Project Control” part we are just beginning. In this chapter, we clarify what “controlling a project” really means, emphasize the key principles of a project control system, highlight the impact that project planning has on this effort, review powerful techniques that should always be considered, and discuss how to avoid the common challenges faced by most project managers. Finally, to summarize the key fundamentals of controlling a project, we study the lessons that can be learned from project recovery missions. This will lead to an understanding that will enable you to develop an appropriate project control system that best meets the needs of your next project.

What Is Project Control?

What do you think of when you hear “project control”? Micromanager? Confrontation? Inflexible? Military-style leadership? Theory X management? Fortunately, none of these terms accurately describe project control. Project control consists of the information systems and the management procedures that enable you to answer questions such as

  • Are we on track?

  • Are we on budget?

  • Are we on schedule?

  • Are we delivering what we said we would?

  • Are we meeting quality and performance standards?

  • Are we meeting stakeholder expectations?

  • What have we accomplished?

  • Will the project objectives be met?

  • What deviations/variances exist?

  • What corrective actions are we taking?

  • What caused these variances?

  • What risks are we monitoring?

  • What issues do we need to resolve?

  • What lessons have we learned?

Officially, the Project Management Institute (PMI) defines the Monitoring and Controlling Process Group as those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes.

Although accurate, this definition does not clearly communicate all the aspects of project control that we need to understand, and it does not emphasize the most important aspect—prevention.

PDA: The Principles of Project Control

An easy way to remember what project control is all about is to think PDA. PDA stands for Prevention, Detection, and Action. Let’s take a closer look at these fundamental principles of project control:

  • Prevention—As with your own health, the secret to wellness is strengthening your immune system and minimizing contact with harmful agents. In other words, don’t get sick in the first place. The same principle applies to effective project control. The best way to keep your project on track is to prevent (or at least minimize) variances from occurring. How do you do this? This takes your entire array of project management skills, but a few key activities include investing in planning, communicating effectively, monitoring risk factors continuously, resolving issues aggressively, and delegating work clearly.

  • Detection—For this aspect of project control, think radar system or early warning system. Project control should provide early detection of variances. The sooner we can act on a variance, the more likely we are to get the success factor back on track. The key for early detection is to have the tracking systems and work processes in place that allow for the timely measurement of project results. Common examples of detection methods are performance reporting, review meetings, and development methodologies that emphasize early and frequent product generation. Two important concepts to note here are that to have a variance, you must be comparing actual results to a baseline of some type, and a variance can apply to any of the critical success factors, including stakeholder expectations and quality, not just schedule, cost, and scope.

  • Action—Although the prevention aspect has a strong action orientation too, this principle goes hand-in-hand with early detection. For project control to be effective, the detection of a variance must be able to trigger an appropriate and timely response. The three most common action types are corrective actions, change control procedures, and lessons learned. Often, as part of the planning for project control, specific variance thresholds are established that dictate what variances and corrective actions can be managed by the project team and what things need the immediate attention of senior-level management.

Components of Project Control

To better clarify what is involved with project control, let’s review some of the key project management processes that are involved. To reiterate, project control involves more than just these processes. Your leadership, communication, interpersonal, analytical, and team management skills are equally, if not more, important to this endeavor. However, without these fundamental management processes in place, as depicted in Figure 10.1, you will have a much more challenging time.

  • Performance reporting—The process for measuring and communicating project status to the targeted stakeholders. Information generally is focused on the performance of critical success factors against baseline targets, key issues, corrective actions, and forecasted metrics.

    The project management processes involved with project control.

    FIGURE 10.1

    The project management processes involved with project control.

  • Change control management—The process for reviewing, approving, and coordinating any request to alter the project scope, schedule, or budget. We address this in greater detail in Chapter 11, “Managing Project Changes.”

  • Configuration management—The process for controlling changes, updates, and versions of project deliverables. We discuss this in greater detail in Chapter 11 and in Chapter 12, “Managing Project Deliverables.”

  • Issue management—The process for identifying, tracking, and resolving issues that could affect the project’s critical success factors. We address this in greater detail in Chapter 13, “Managing Project Issues.”

  • Risk management—The process for identifying, monitoring, and responding to project risks. We address this in greater detail in Chapter 14, “Managing Project Risks.”

  • Quality management—The process for ensuring that work processes and project deliverables meet quality expectations. We address this in greater detail in Chapter 15, “Managing Project Quality.”

  • Procurement management—The controlling processes specifically used to manage any suppliers and vendors involved in the project.

  • Requirements management—The process to ensure all requirements are identified correctly, documented, and tracked throughout the project. This is an excellent scope and change control technique that is mentioned again later in this chapter.

Management Fundamentals for Project Control

As a project manager, there are a few management fundamentals to consider when establishing your project control system:

  • Focus on priorities—Understand what is important to the project and to the organization. Understand that whatever receives your focus will become important. Make sure there is alignment between the two.

  • Scale to project—The level of rigor and detail in your project control system should be consistent with the level of risk in the project. It should also be consistent with the project budget. In other words, projects with either low risk or small budgets should not be burdened with a project control system that is designed for larger, mission-critical projects.

  • Think “process”—You do not want to spend all your time and energy putting out fires, trying to get basic status information, and feeling like you are not in control of your project. You want to establish a natural system of control for the project; you want to plan it in advance. This applies to the project as a whole and to each individual team member’s contribution.

  • Expect changes—Project control does not mean prevent changes at all costs. Conversely, project changes should be expected, planned, and well-managed.

  • Invest in thorough planning—The more energy spent in planning, the easier it is to control a project. If the project is defined properly, work is planned from the bottom up, risks have been identified, stakeholders are in agreement on project objectives, and the project control system has been accounted for, then keeping the project on track should take much less effort.

  • Consider organizational culture—Depending on the level of project management maturity in your organization, you might need to consider a gradual implementation of project controlling procedures to achieve greater acceptance and effectiveness. Again, just make sure you focus on top priorities.

  • Set expectations—Remember to think “project control” in your project communications. Ensure that each team member understands what is expected from the project and from their individual role. In addition, make sure that the project team sees the discipline and priority that you place on all project control procedures.

  • Be consistent—An important element to both effective project control and effective project communications is consistency. Project performance needs to be measured and reported on a consistent, regular basis. This approach is key for both early detection of variances and for establishing a culture of accountability to project assignments.

  • Pay attention early—Just to follow up on the last point: make sure to pay close attention to your project early on. According to a study of more than 800 projects for the Department of Defense since 1977, the outcome of a project was no better than its performance taken at the 15% completion point. Thus, if a project was behind schedule and/or over budget at the 15% completion point, it did not recover from this variance. The general consensus is that this happens for two key reasons: lax project controls in the early stages and poor estimating. If the estimates were off for the immediate work efforts, they are unlikely to be more accurate further down the timeline. We discuss how to handle a variance in the “Variance Responses” section later in this chapter.

  • Track assumptions and constraints—Often, the key assumptions and constraints for a project are identified during project planning then subsequently forgotten: ”out of sight, out of mind.” Also, many projects do not have a system in place to capture new or changing assumptions and constraints as the project moves forward. One suggestion is to track these alongside issues, risks, and key action items.

Powerful Techniques for Project Control

So far, we have covered the value and importance of planning your control system. In this section, we’ll take a look at some powerful project control techniques that you’ll want to consider during your planning efforts and then implement during the execution of your project.

  • Small work packages—This was a point of emphasis during our discussion on building a work breakdown structure (WBS). Recall that there are two primary reasons for advocating small work packages: more accurate estimates and better control. From a control perspective, if your work packages are scheduled to complete within one (or at the most, two) reporting period, it is much easier to detect a delayed or troubled task. With earlier notice, you are more likely to resolve the variance and protect the project’s critical success factors.

  • Early and frequent work packages—In addition to small work packages, which help identify progress variances early, you should look for opportunities and approaches that emphasize prototyping (at a minimum) or early and frequent generation of the actual product result that is reviewed with the key stakeholders. This is the key aspect of agile-type methodologies. This helps identify any variances with requirements and stakeholder expectations as early as possible. And with earlier notice, you are more likely to resolve the variance and protect the project’s critical success factors.

  • Baselines—A fundamental control principle is to manage to baselines. First, establish a baseline. This is generally applied to the critical success factors of schedule and budget, but you can apply it equally as well to product-oriented aspects of the project, especially requirements. Second, measure and report performance against the baseline. Third, maintain the baseline unless there is a formal agreement to reset the baseline. We discuss this in greater detail in Chapter 11.

  • Status meetings—The simplest, and most widely known, technique is the status meeting. Consistent and regular status meetings help to keep everyone honest, accountable, and on their toes—especially if work assignments are small and have clear completion criteria. In addition, status meetings are powerful tools for improving project communications and managing expectations.

  • Completion criteria—This starts during project definition with defining the acceptance criteria for the project, and it continues for each deliverable and work assignment. Answer this question in advance for each deliverable and work assignment: “How will we know when it is done?” Understanding the completion criteria upfront increases productivity and avoids many of the issues associated with status reporting on work tasks, especially the infamous “I’m 90% done” syndrome.

  • Reviews—Reviews are a key technique for ensuring quality and managing expectations on project deliverables, and they can take many forms. The principle here is to plan for the review-feedback-correction cycle on most, if not all, of your key deliverables. Common examples of reviews are process reviews, design reviews, audits, walkthroughs, and testing. In addition, reviews can be combined with predefined milestones and checkpoints.

  • Milestones and checkpoints—A key feature of most proven project methodologies is the use of predefined milestones and checkpoints. These markers are important points to stop, report progress, review key issues, confirm that everyone is still on board, and verify that the project should proceed with its mission. Besides being a powerful expectations management tool, these predefined points allow project sponsors and senior management to evaluate their project investments along the way and, if warranted, redirect valuable resources from a troubled project to more promising pursuits.

  • Track requirements—A simple, yet often neglected, technique to help control both scope and expectations is the use of a requirements traceability matrix. The traceability matrix provides a documented link between the original set of approved requirements, any interim deliverable, and the final work product. This technique helps maintain the visibility of each original requirement and provides a natural barrier for introducing any “new” feature along the way (or at least provides a natural trigger to your change control system). In addition, the traceability matrix can link the specific test scenarios that are needed to verify that each requirement is met.

  • Formal sign-offs—Formal sign-offs are a key aspect of change control management, especially for projects that are client-vendor oriented. The formal record of review and acceptance of a given deliverable helps to keep expectations aligned and minimize potential disputes. Most importantly, the use of a formal sign-off acts as an extra incentive to make sure the appropriate stakeholders are actively engaged in the work of the project.

  • Independent QA auditor—The use of an independent quality assurance auditor is another specific example of the “review” technique mentioned earlier, and it’s often a component of project QA plans. In addition, the quality audit can be focused on product deliverables, work processes, or project management activities. The power of this technique is in establishing the quality criteria in advance and in making the project accountable to an outside entity.

  • V method—The V method is a term used for a common validation and verification approach that ensures that there is a validation and verification step for every deliverable and interim deliverable created. The left side of the V notes each targeted deliverable, and the right side of the V lists the verification method to be used for each deliverable directly across. The diagram in Figure 10.2 helps illustrate this method.

    An illustration shows a V method approach for a software development project.

    FIGURE 10.2

    V method approach for a software development project.

  • Escalation thresholds—Escalation thresholds sound much more ominous than they actually are. The purpose of escalation thresholds is to determine in advance what issues and variances the project team can handle and what issues or variances demand attention by senior management. Often, these thresholds are defined as percent variances around the critical success factors. For example, if the cost variance is greater than 10% or schedule variance is greater than 15%, engage senior management immediately for corrective action steps. The key value of this technique is that it helps to define tolerance levels, set expectations, and clarify when senior management should get involved in corrective action procedures.

Performance Reporting

As we have touched on several times already, another key aspect of project control is measuring and reporting project performance. We could easily spend an entire chapter (or two) reviewing the various options, factors, and challenges involved with this process. However, if you keep the following principles in mind, you can adapt your performance reporting process to best meet the needs of your project environment:

  • Answer the big three questions—As a rule, key stakeholders want to know the answers to the following three questions when reviewing project performance:

    1. Where do we stand (with regard to the critical success factors)?

    2. What variances exist, what caused them, and what are we doing about them?

    3. Has the forecast changed?

  • Measure from current baseline—If you are going to report project performance with a variance focus, you must establish and maintain your performance baselines. Any change to the performance baselines is controlled via your change control procedures.

  • Think “visual”—Another key concept in reporting is to think visually. Most people are visual and spatial learners and will grasp the important project performance metrics more quickly if they are presented in a visual format. The use of bar charts, graphical schedule summaries, and stoplight indicators (red, yellow, and green) for key metrics are good examples of this technique.

  • Think “summary page”—Along this same theme, you generally want to provide your key status information in no more than one to two pages. If it is appropriate to have details that will take more than one or two pages, it is recommended that you provide a one-page summary upfront.

  • Highlight accomplishments—A part of the status report’s function is to serve as a public relations tool for the project, so make sure key accomplishments are highlighted prominently.

  • Show forecasts—In addition to reporting how the project has performed to date, remember to show the forecasted schedule and cost metrics. Often, this information is shown as Estimate At Completion (EAC) and Estimate To Complete (ETC) figures. Specifically, highlight any changes to these figures from the last reporting period.

  • Highlight key issues, risks, and change requests—This is a natural category when assessing project performance. Make sure any key issues, risks, and change requests are included on status reports. I discuss these in greater detail in subsequent chapters.

  • Avoid surprises—An important point about consistent, performance-based status reporting is that stakeholders are aware of and knowledgeable about overall project status and are not caught off guard with project developments. To this extent, depending on the audience for any status report, you might want to communicate with specific stakeholders in advance of any official report distribution. Always remember that you should not surprise anyone—especially your sponsors and accountable senior management stakeholders.

  • Adapt to meet stakeholder needs—This is an example of the customer service orientation and servant leadership qualities of effective project managers. Be prepared to offer examples of performance reports that have worked well for you in the past, but most importantly, go into any project looking to understand the information needs for this given environment. Show enthusiasm and willingness to adapt to the customer’s standards or to develop custom formats to best meet the stakeholders’ needs.

  • Deliver with appropriate frequency—Consistent with a management fundamental mentioned earlier, the frequency of performance reporting must be appropriate for the project. The process of gathering information and reporting performance needs to be quick enough and occur often enough to be useful and relevant.

Variance Responses

As previously mentioned, the first goal of our project control system is to prevent any variance. However, we also realize variances and changes will occur—this is the nature of the project beast. Thus, the remaining goals of project control are centered on early detection and appropriate response. Let’s review the general response options that are available to us as project managers when a variance occurs:

  • Take corrective actions—The preferred option, whenever possible, is to understand the root cause of the variance and then implement action steps to correct the variance. When performance measurement is frequent, it is more likely that action can be taken that will make a difference. Examples of corrective actions include adding resources, changing the process, coaching individual performance, compressing the schedule (fast-tracking or crashing), or reducing scope (this would be documented as a change request, too).

  • Ignore it—In cases where the variance is small (and falls within an acceptable threshold range), you might choose to take no action to resolve the deviation. Even in these cases, it would be advisable to log the variance as a risk factor.

  • Cancel the project—There might be times when the appropriate response is to cancel the project altogether. This response is more likely on projects where one or more key assumptions have not held or when one or more of the critical success factors has a very low tolerance for any deviations.

  • Reset baselines—While taking corrective action is the preferred option for performance variances, there are times when the variance cannot be eliminated. This is common on knowledge-based projects and common on projects where the estimating assumptions have not held. In these cases, a decision to reset the performance baselines is made and approved. From that point on, performance is measured from this revised baseline. This is part of the change control procedures we discuss more in Chapter 11.

Leveraging Earned Value Management Concepts

Earned Value Management (EVM) (otherwise known as variance analysis) is the best project control technique for early detection of performance variances. The technique was developed nearly 40 years ago for the United States government to better manage contract payments to vendors. Ever since, EVM has grown in popularity and acceptance across many industries and now is regarded as the preferred project control technique by PMI. However, it has not been accepted as standard practice in all industries, and it is usually a technique found in organizations or industries that are relatively mature in their management processes. Thus, we could spend an entire chapter on a technique that might not be part of your organizational culture yet. In addition, if you work in one of these process-mature environments, you are less likely to be reading this book, and you will likely have many additional resources to address the details of earned value.

Still, there is tremendous value in a quick review of EVM. An awareness of the fundamental concepts will help you in your project controlling and performance reporting endeavors.

  • Assess cost performance and schedule performance together—The main value of EVM is that it enables you to measure and track both schedule and cost performance. Evaluating project performance on just one of these indicators does not always give you the true picture and does not allow you to detect variances as early.

  • Each work package has a planned value—The planned value of any work package is the budgeted cost of the work scheduled to complete the work package. The important point here: Estimate the cost of each work package in your schedule. Also, this means that the project as a whole has a baseline schedule and budget.

  • At any point, the project has an “earned” value—The earned value of a project is the budgeted cost of the work actually completed. In other words, how many work packages (or partial work packages) have been completed at this time? The value is expressed in budgeted cost terms, not actual costs. This enables you to perform cost analysis by comparing budgeted versus actual costs for the work completed. The important point to consider: Be aware of the costs you expected to incur for the work that has been completed.

Before we introduce an example EVM graph, let’s review the other key terms and concepts that comprise EVM. Table 10.1 summarizes these key elements.

TABLE 10.1 Earned Value Management Elements

Element

Definition

Notes

Planned Value (PV)

Budgeted cost of work scheduled.

Performance baseline.

Earned Value (EV)

Budgeted cost of work performed.

For the work performed, what was the budgeted cost?

Actual Costs (AC)

Actual costs of work performed.

For the work performed, what were the actual costs?

Cost Variance (CV)

Earned Value – Actual Costs

CV = EV – AC

A negative number means you are over budget.

Schedule Variance (SV)

Earned Value – Planned Value

SV = EV – PV

A negative number means you are behind schedule.

Cost Performance Index (CPI)

Earned Value / Actual Costs

CPI = EV / AC

Numerical representation of project cost performance.

CPI < 1 means your project is costing you more than you planned. CPI > 1 means you are taking less money to do the project.

Schedule Performance Index (SPI)

Earned Value / Planned Value

SPI = EV / PV

Numerical representation of project schedule performance.

SPI < 1 means your project is behind schedule. SPI > 1 means you are ahead of schedule.

Budget at Completion (BAC)

Total baseline project.

The original project budget.

Estimate at Completion (EAC)

Budget at Completion / Cost Performance Index

EAC = BAC / CPI

Based on current cost performance, what will be your total cost?

Estimate to Complete (ETC)

Estimate at Completion – Actual Costs

ETC = EAC – AC

Subtract AC from EAC to get estimated remaining costs.

EVM takes the planned value (PV), or what you planned to do at an estimated cost, and compares it against the estimated cost of the work performed (EV) and against the actual cost of work performed (AC), or what actually got done. These metrics provide a wealth of information about whether the project tasks are taking longer than they should (schedule variance, or SV), or whether they are actually requiring more work effort to complete (cost variance, or CV). In addition, the estimate-at-completion metric (EAC) helps you forecast final project performance and determine whether any corrective action needs to take place.

To illustrate how EVM could be used for performance reporting, see Figure 10.3.

A graph is given.

FIGURE 10.3

Depicts EVM metrics for the fourth time period on a sample project.

In this example, the report provides EVM data for the fourth reporting period. At this time, the Planned Value = $75K, the Actual Costs = $100K, and the Earned Value = $60K. On this project, we can tell the following by analyzing this report:

  • There has been a cost variance from the start. It could be the actual resource costs have been higher.

  • Also, for the first three weeks, the project was ahead of schedule. More work was completed than planned. This was a likely factor for the actual costs being higher too.

  • During the past reporting period, something has occurred that delayed progress. The project is now behind schedule (and the cost variance has increased significantly).

Many of the project management software tools, such as Microsoft Project, include these EVM calculations. To be useful, the schedule must include all assigned resources, individual resource costs, and current progress measurements.

Common Project Control Challenges

Although we’ve touched on several challenges facing project managers when attempting to control their projects, let’s run down the top reasons for difficulty in the project control arena:

  • Time and cost accounting logistics—The logistical and organizational culture issues relating to time reporting and project costs tracking can prove detrimental to timely and accurate performance reporting. During planning, you want to understand and clarify how project time and cost information is reported and how quickly you can get this data. You might need to establish project-specific time reporting or approval procedures to ensure the integrity of your control system.

  • Project manager reluctance, multitasked—The project manager might be reluctant to request WBS-level time reporting by project team members, especially if this is not part of the organizational culture. In addition, the project manager might be overallocated and might not be able to invest enough time to performing the project controlling duties. This is most common when the project manager has assigned other project roles to themself or when the project manager is assigned to multiple projects.

  • No change control—The most common reason for project control difficulty is the lack of change control procedures. This is most problematic when the project scope has increased without the proper reconciliation with the project schedule and budget.

  • No completion criteria—When clear completion criteria for work assignments are not established, you are more likely to have rework cycles, more difficulty in accurately reporting progress or status, and more likely to experience the 90% done phenomenon.

  • No baselines—This should be obvious by now, but if a schedule and budget baseline are not established and controlled, then you will not be able to accurately measure for performance variances. Without this ability, you are less likely to detect problems early—when they are small and more manageable.

  • No requirements traceability—This is definitely an issue for controlling scope and stakeholder expectations. The lack of a formal tracking procedure between original requirements and final products increases the odds of missed work and scope creep.

  • Not consistent—When control procedures are not consistently implemented, it is difficult to detect performance variances early, and it is more difficult to get project team members to follow the defined control procedures.

  • Measuring progress accurately—Accurately measuring progress is a natural challenge on work assignments with intangible final products, especially on any project where status is estimated. However, this challenge is further complicated when work definition is vague, completion criteria are not established, or work efforts are not reported on a daily basis.

  • Impact of hidden work—This hits at the heart of work definition and change control. Any effort spent on unidentified work, unplanned rework cycles, or out-of-scope work adversely affects the accuracy and effectiveness of project control procedures.

  • Virtual/distributed teams—When project team members are not physically located together, it can be more difficult to get information, detect potential issues, measure work progress, and ensure understanding of work expectations. We talk more about this in Chapter 20, “Managing Differences.”

Lessons from Project Recoveries

To really understand what is important for controlling a project, let’s review what occurs during a typical project recovery. For clarification, a project recovery is an attempt to turn around a troubled project. If there is ever a case where project control is absolutely critical, it is when you are trying to heal a sick project.

The first thing that senior management will do to recover a project is to make sure there is an effective project manager in charge. This might mean anything from validating the current project manager, bringing in someone new, pulling someone up from the project team, or providing a mentor to the current project leadership. After the project leadership is solidified, most recovery missions involve the following activities:

  • Review planning principles—The planning principles are revisited. A focus is placed on establishing priorities and objectives, clarifying acceptance criteria, gaining consensus, and reviewing roles and responsibilities.

  • Reset baseline—As a final step in the replanning step, key milestones are set and new baselines are set for cost and schedule performance.

  • Frequent status checks—To facilitate better communications, prevent additional obstacles, reinforce the visibility of the recovery mission, and emphasize individual accountability, team status meetings are conducted daily. In some situations, these checkpoints are even more frequent. It depends on the nature of the project.

  • Aggressive issue resolution—One purpose of the frequent status checks is to gain visibility of any new or potential issue. The resolution of any new issue is aggressively pursued. These become top priorities for project leadership.

  • Ensure clarity—Another technique normally employed in successful project recoveries is an extra effort to ensure clear understanding of all communications, expectations, and work assignments. When focus and efficiency are of paramount importance, the criticality of clear communications and mutual understanding is obvious.

  • Increase visibility and accountability—This has been referenced indirectly already, but it is worth emphasizing again. A major reason that project recoveries often work is because people know they are more accountable for their efforts due to the increased visibility with senior management. For both the individual and the organization, the recovery mission helps to prioritize efforts and align resource allocations.

The map in Figure 10.4 summarizes the main points reviewed in this chapter.

An overview of controlling a project.

FIGURE 10.4

Overview of controlling a project.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset