Controlling the Project Outcome

Table of contents:

Overview

We'll spend a good deal of this chapter discussing project changes, how to manage change, and how to assess the impacts of change. The change control process kicks in during the Controlling phase of a project. Remember that change can also occur during the Planning and Executing phases, as mentioned in previous chapters. For clarity's sake, we'll cover all the change processes here.

Change can have positive or negative effects on your project, and it's important that you understand how to handle the change, what it means to the progress of the project, and how to communicate the change to the project team while maintaining their enthusiasm and focus on the project goals.

This chapter will also look at performance-monitoring techniques to determine whether the project is on track with the plan. We'll wrap up with a section on the warning signs of a project in trouble.

In this chapter, you will learn:

Why change happens
Establishing change control procedures
Assessing the impacts of change
Monitoring project performance
Signs of project trouble

Change Happens

There's an old saying that says nothing is certain but change. This certainly applies to your projects. I've never had the experience of working on a project that went from Initiation to Closing according to the original project plan with making any changes. You need to be flexible when dealing with change, communicate the change properly, and know when to say no.

The Controlling life-cycle process is about managing change. As you progress through this process, team members, stakeholders, and customers will request changes. You'll measure and inspect project performance, which may also turn up the need for change or require some action to get the project back on track. Let's take a closer look at how changes come about on projects. If you understand how or why changes come about, it will help you to come up with good change control procedures to manage the process, which we'll cover in the next section.

How Changes Come About

Changes occur for many reasons. Some changes are requested by stakeholders and team members, and others come about as a result of measurements and inspections performed during the course of the project. Here are some of the ways changes may occur on the project. This isn't an exhaustive list, but it should get you thinking about the ways changes occur so that you can then figure out how to deal with them when they do.

Stakeholder and customer requests Stakeholders and customers may request changes to the requirements of the project, they may ask for the project schedule to be shortened, they may add new deliverables, or they may have other requests that impact the project. Stakeholders and customers never seem to be short of ideas for project change.

Project team member requests As the project progresses, team members may recommend changes as they discover more efficient ways of doing the tasks. They may recommend ways to change the process to shorten the schedule or ways to combine tasks for better efficiency.

Key members leaving the project Team members who leave the project can cause changes to the project. Their expertise may be such that their departure will hold up the progress of the project until another expert can be hired or found. This requires a change to the project schedule.

Budget cuts Budget cuts mean the scope, schedule, resource allocation, or quality aspects of the project have to change.

Organizational changes Reorganizations and realignments of business units can bring about changes to the project. These types of change usually delay the project schedule. New senior management personnel can also change the direction of the project. This one's even a potential project killer.

Measurement and inspection Errors discovered during inspection processes in the Controlling cycle will necessitate changes to correct the process and will impact the project. Variances in measurements, processes, or controls will likely force changes as well.

Indirect changes Changes may occur to the project indirectly as a result of implementing contingency plans or risk response plans. Also be on the lookout for changes that team members make without telling you. They may be doing a favor for a stakeholder or end user and decide to make a change without telling anyone else. While you don't want to discourage good working relationships between the team and stakeholders, you do want to make sure that everyone knows and follows the established change control process. Undocumented changes can add up and eventually will impact the schedule or the budget.

Responding to Change

Many people do not like change. We all have different tolerances for change, and some adapt better than others. As a general rule, folks like the status quo. Keep this in mind when working with your project team regarding changes. Change, whether its impacts are positive or negative, can have a demoralizing effect on the team. The last thing you want to have happen at this stage of the project is to kill the team's motivation.

Let your team members know that there is a process in place to document and approve changes and that only valid changes will be approved, because they want to be assured that you're not going to jump every time someone suggests a change and derail their hard work. Be certain to document the justification for the change and share that with the team. Team members should clearly understand the need for the change and how it's going to be implemented and incorporated into the project. But if changes keep coming their way without any communication from you, they may throw up their hands and say, "What are we doing this for?" If they begin to feel that their efforts are in vain, they'll lose their motivation and will no longer maintain their commitment to the goals of the project. Remember those bad attitudes that we talked about? Here's where they'll really catch on and spread if you're not careful to communicate well with the team and support them.

Note

Honesty is the best policy when explaining changes to the team. Don't make the changes out to be worse than they really are, but don't keep bad news from the team either. They'll find out some other way, and then you'll have to deal with a loss of credibility as well as with the impact of the changes.

Explain the changes to the team in full detail and don't cover up unpleasant news. Help them understand the impact on the project and let them know you're in this with them to make it work. Include the team in the brainstorming sessions to work through alternatives to deal with the changes. Let them know that you support the changes and that you support their ideas as well. Then rally their support for the changes.

As the project manager, you'll want to keep change to a minimum whenever possible. We'll talk about how to assess the impacts of change later in this chapter. First, let's look at the mechanics of the change control process and how change requests are generated.

Establishing Change Management Control Procedures

Change control is an important process in the project life cycle. And change requests should come about in a formal manner. If you haven't done a good job establishing a change control process and communicating that process to the stakeholders and team members, you'll likely end up with e-mail going directly to project team members asking for changes or stakeholders grabbing you in the hallway and asking for something "they must have" to consider the project successful.

Tip

Here's your first rule regarding change: Always require change requests in writing.

No one has a perfect memory. Undocumented changes can cause big conflicts. If you don't remember the change the way it was described, or the stakeholders thought they said what they meant but that's not what the project team implements, you'll have even more setbacks and changes to deal with than the original requested change. Undocumented changes could end up affecting the project schedule or the product quality or costing the organization money or loss of business, so always get change requests in writing.

Note

Change control procedures are normally documented during the Planning process and implemented during the Executing and Controlling processes. For the sake of clarity, I've included the change management process and change management plan in this chapter. I think it will be easier for you to see the logical progression of the change process if it's described all in one place.

Forming a Change Management Plan

A change management plan helps you accomplish three things. First, it helps you understand what causes change to come about; we talked about that in the opening section. Second, a change management plan helps you understand when or why a change is needed, and third, it helps you manage the change by establishing procedures for change.

change management plan

The plan that describes how change requests are submitted, reviewed, and approved or denied.

Good change management plans should describe such processes as submitting change requests, managing change requests, deciding who will review the change requests, and determining how they're approved. It's a good idea to provide users with forms for submitting change requests, because this will ensure that you capture all the information you need to make a decision regarding the change. (I'll give you an example change request template later in this chapter.)

Your organization may already have a change management process in place. If so, use the existing policies and modify them—with permission, of course—if you need a process that is specific to your project.

The following list shows most of the elements you should include in your change management plan. You could modify these for use as headings in the change management plan and then fill in the information according to your project needs or organizational policies.

Where to obtain change request forms
How change requests are submitted
The person or team responsible for accepting change request forms for review

Also include a section that describes how the change control processes work. This should outline the following processes:

How changes are approved
How the preliminary review works
How recommendations for approval or denial are made
How the change control board process works, their authority level, and their meeting dates
Sign-off by the project manager and/or change control board

The change management plan should describe the level of authority needed to approve a change, as noted in the former list. Some change requests can be approved by the project manager, depending on the nature of the change. Others need to go before a review committee, often called a change control board, that reviews and approves all changes outside the project manager's authority.

change control board

A group of individuals including the project manager and key stakeholders responsible for reviewing, approving, and denying change requests.

Note

Here is rule number two regarding change: All change requests must follow the change management process. They should be submitted according to the change management plan, approved or denied by the appropriate level of authority, and signed off. Changes that are not submitted according to the rules of the process are automatically denied.

It's important that stakeholders and team members follow the established change management process. Undocumented changes are also known as scope creep. As we've previously discussed, scope creep can get out of hand quickly, escalate the costs of the project, lengthen the project schedule, or distort the quality of the product. All of these things add up to an unsuccessful project. Projects that are unsuccessful because the project manager failed to implement processes and project plans foretell an unsuccessful project management career, so do everything you can to make sure these processes are followed.

The change management plan should be distributed to all key stakeholders, project team members, customers, vendors, and anyone else outlined in your communications plan who gets project information. File a copy of this plan in your project notebook as well.

Establishing a Change Control Board

The change control board is made up of key stakeholders, the project manager, key project team members, and functional managers and customer representatives when appropriate. The purpose of the change control board is to review change requests and approve or deny them. The board's authority should be outlined in the project management plan, as mentioned earlier.

The change control board should meet at regularly established times. Their meeting schedule will depend on the project; once a week may be necessary for some projects, while once a month is enough for others. Establish the meeting schedule at the end of the Planning phase, and start holding your meetings shortly after the Executing phase begins.

Make certain there are procedures in place for emergency changes. If the change control board meets only once a month, for example, and the project manager has an issue that must be dealt with on the spot, procedures should be outlined in the change management plan that give the project manager the authority to make the change. After making the emergency change, the project manager should still submit the change request to the board as a formality to show that the change has occurred, to log the change, and to include documentation of the change with the project information.

There are several ways to administer the change process and deliver change requests to the change control board. Your procedures may require that all changes go through a preliminary review by the project manager so that a high-level impact analysis can be recorded right on the change request form. After the high-level impact analysis is completed, the change control board reviews the change request and makes their decision. Alternatively, large projects may have a full-time change manager who reviews all change requests and is responsible for the first level of approval before the change request goes to the change control board. Requests denied by the change manager go no farther. Or the change control board may review all change requests first. Those they think have potential to improve the product or project processes are given to the project manager to perform an impact analysis. The project manager turns in the impact analysis at the next change control board meeting, where a final decision is made. Yet another method is for the project team to review all change requests and only those recommended for approval will go to the change control board. Again, the change management plan should outline your procedure, including when and how impact analysis should be performed. (We'll get to impact analysis later in this chapter.)

Tracking Changes

Change control procedures should include a tracking system to track the date the change was requested, the status of the change, and the approval status. This could be a simple change log or spreadsheet like the one shown in Table 11.1. This example shows a sample portion of a change control log for a software development project.

Table 11.1: Change Control Log
*Project name:*
*Project number:*
*Project Manager's name:*
ID	Change Request Description	Submit Date	Status	Approve Date	Implement Date
1	Add new edit module to accounting program	1/20	Researching schedule and resource impacts	Pending
2	Change the content of the audit report in the accounting program	1/30	Approved	2/03	2/10

Use this log at your change control board meetings to keep track of change requests and their status. The meetings shouldn't take long because your only purpose is to discuss changes. If you're working on large projects, the meetings may get more involved. But if they're getting too lengthy, consider having them more often. The control board meeting agenda looks something like this:

Review outstanding change requests.
Discuss impacts and benefits of the changes.
Approve or deny the changes.
Review progress of changes previously approved.

All change requests should be signed by a member of the change control board. This gives you the authority to implement the change or to file the denied change request in the project notebook.

After the change meeting, you'll communicate the change to the project team and modify the project plans to include the change. Changes to the scope, the project schedule, quality, or the budget will require updates to these project plans. Don't forget to submit the modified project plans to the key stake-holders and project sponsor for signatures when the changes are significant in nature.

Assessing the Impacts of Change

Once a change has been requested, at some point in the process someone is going to ask you what the impact of the change is on the project. You'll be required to assess the impact of the change and report on the impacts it will have on the various project plans. Changes will almost always affect at least one of the following, if not several of the following: scope, project schedule, budget, or quality.

Note

Here's the third rule of change: Budget changes almost always require changes to the project schedule, scope, quality, or a combination of the three. Schedule changes almost always require changes to the budget, scope, quality, or a combination of the three. Scope changes always require changes to the project schedule and may require changes to the budget, quality plan, or any combination of the three.

Keep in mind that just because a change is requested doesn't mean it has to be implemented. That's one of the reasons you go through the effort to create a scope statement. Perhaps your stakeholders are asking for a change that is out of scope for the project and is recorded as an out-of-scope requirement in the scope statement document. You can remind them, by showing them a signed copy of the scope statement if needed, that their request is documented as out of scope for this project.

Remember that time equals money, so even if the change doesn't impact the budget directly but it impacts the time required to complete the tasks, it still indirectly impacts the cost of the project. If all your project team members are on staff and the tasks take longer than originally planned, their salaries are charged to the work of the project longer than originally planned, so indirectly, the cost of the project has risen. And, the end product doesn't reach the customer, or the marketplace, until the delayed completion date, which means that the ability of the company to collect revenue on the product of the project is delayed.

Calling in Reinforcements

Your first step in examining how changes will impact the project is to get the project planning documents together. You begin by reviewing the change requested against the associated planning documents. The impact of some changes will be obvious. Start by noting those changes and ask yourself how they may impact other parts of the project that are not so obvious.

Use some of the techniques we discussed in previous chapters, such as brainstorming, to come up with ideas, impacts, and all the project areas that may be affected. Involve stakeholders and project team members to help you uncover all the possible impacts of change and any risks associated with the change.

Usually you'll find that change requests fall into one of three areas: scope change, schedule change, or budget change. We'll look at these categories of change to see how changes in these areas may impact the project, how to assess their impact, and how to make adjustments to accommodate the changes.

Three questions should be examined for each of the changes we'll discuss:

Why is the change needed?
What will be the impact on the project or product of the project if the change is not implemented?
Are there alternatives to the change?

Start examining how the change affects the project by asking these three questions. The third question should be examined by the project team to determine whether there are ways to accommodate the results of the change while reducing the impact or coming up with other ways to get the same results.

Adjusting for Scope and Schedule Changes

Scope changes are probably the most frequent type of change requested on a project. In this section we'll look at how scope changes are requested, what questions to ask to help you assess their impact, and how they affect the schedule. Remember that scope changes always require schedule changes, so we'll cover both of those types of changes here.

Scope changes include any changes to the deliverables or requirements of the project. In Chapter 4, "Defining the Project Goals," we discussed how any modification to the agreed-upon WBS is considered a scope change. You'll recall that the WBS details the project deliverables, summary tasks, and tasks. Therefore, changes to any of these items constitute a change in scope.

First, let's look at how scope changes are requested and what types of information you need to assess their impact. Figure 11.1 shows a sample change request template. Your project team or stakeholders can use this template to request any type of change, including scope changes. We've already discussed most of the elements on this form. Each heading has a brief explanation beneath it describing the kinds of information the requestor and project manager should provide.

click to expand

Modify this template for use on your projects. And don't forget to file these in your project notebook. I recommend putting these in an appendix or starting a separate notebook for change requests. If you're keeping this information online, create a directory just for change requests and the change request-tracking log. Be sure to note the tracking number from the change request log on the top of this form.

Modifying the Scope and Schedule

When the scope change is approved, you'll need to adjust the project schedule to accommodate the change. Remember that changes to scope always require changes to the project schedule. In order to do this, you'll need to assess how the changes affect the project and what adjustments you need to make to accommodate the changes. Things you can do to help make adjustments for scope and schedule changes include the following:

Ask functional managers for suggestions and assistance with changes.
Examine resource allocation and ask for more resources, human and equipment, to meet the new requirements and dates.
Determine whether working overtime is an option for existing team members to meet new requirements and dates.
Examine vendor options. Are there services you can purchase or parts you can buy that the team was originally going to produce, or can you outsource some of the deliverables to the vendor to complete?
Reduce the project scope to accommodate schedule changes, including modifying goals and deliverables.
Move some deliverables to phase two of the project to accommodate schedule changes.

Once the changes have been approved, the project manager should adjust the project schedule to account for the changes. Communicate those changes—including new tasks, new due dates, modified tasks or dates, and so on—to the project team members. Discuss scope and schedule changes as part of your regular team meetings.

Adjusting the Project Schedule

Sometimes you'll be asked to shorten the project schedule even after it's been approved and the Executing phase has begun. Reasons for this new urgency may include a new marketing opportunity, the sponsor's fear of a budget cut before the project can be completed, or a scope change that may require shortening the schedule.

There are two techniques for shortening, or compressing, the schedule. The first is called fast tracking. As an example, let's say that the team writing the technical users guide for a software programming project starts writing the manual at the same time the testing team is testing the modules. Originally, the writers were not going to start until the testing phase was complete, but by starting the two activities at the same time, the schedule is shortened.

fast tracking

A schedule compression technique that starts two tasks at the same time that were originally scheduled to start sequentially.

The second technique for shortening the schedule is called crashing. Crashing is a technique that weighs cost and schedule trade-offs. For example, you may consider adding resources to the critical-path tasks to crash the schedule. Adding resources will shorten the amount of time needed to complete these tasks. (Remember that adding resources to the noncritical-path tasks won't help because noncritical-path tasks don't impact the schedule.) Another technique of crashing is limiting or reducing the project requirements. This will also sometimes shorten the project schedule if the tasks related to these requirements are on the critical path.

crashing

A schedule compression technique that examines ways to reduce the duration of critical-path tasks.

Tip

The primary goal behind schedule crashing is to gain the greatest schedule compression with the least cost.

Crashing isn't always an option because the results may negatively impact the project. Always check the critical path after using this technique because the critical path may change. You may have some tasks drop off the critical path while others that were not critical are now considered critical. Fast tracking doesn't always work either. There is often a reason for tasks starting one after another, especially for quality control or completeness of the product.

Managing and Revising Costs

Changes to the budget come about for several reasons, including incorrect estimating techniques, schedule overruns, and inadequate WBS development. These items are within your control as the project manager and they underscore the importance of proper project Planning techniques.

Budget changes that come about due to circumstances you can't control include the schedule and scope changes we discussed in the previous section, fixed budgets that are set from the beginning of the project, and corrective actions taken to get the project back in line with the project plan. All of these conditions may lead to budget revisions.

The first step in adjusting the budget is to determine the revised cost estimates. Review the original estimates and confirm your assumptions regarding those estimates. Realize that the product or service you planned to purchase may have changed, been upgraded, or been modified somehow, which affects the original estimate and the cost of the product today. If you're bringing in new resources or materials that weren't previously included in the budget plan, you need to acquire estimates for those items and include them in the updated budget.

Next you must update the budget with the new costs. Include narrative information that describes why the updates or additions are necessary, and note the change request tracking number associated with the budget update. Get approval of the updated budget from the project sponsor, and distribute copies of the new budget to the appropriate folks.

Measuring and Controlling Project Processes

The Controlling life-cycle process involves monitoring the project outcomes to make certain that they're in keeping with the project plans and that the project continues according to the plan throughout the life of the project. This includes managing and controlling change (as we've already discussed), measuring and inspecting the project performance for adherence to the project plans, taking action to get the project back on track when variances occur, and evaluating the effectiveness of corrective actions.

Successful projects are those that fulfill the requirements of the project to the stakeholders' satisfaction while keeping the project on time and on budget. In order to maintain the schedule and the budget, you'll have to monitor the performance of the project. We've already discussed managing change; now we'll look at how you'll measure outcomes and control performance.

As you might imagine, there are several ways to monitor the performance of the project. Communication between you and the project team is certainly one of your biggest defenses against unforeseen problems or problems running out of control. There are other tools and techniques you can use as well to monitor project outcomes, and we'll look those at in this section.

Obviously, the project plan will serve as your measurement baseline for all project performance. We've spent a great deal of time discussing the project plan and its importance, and it comes into play again in this life-cycle phase as our baseline for project performance. During the Controlling phase, you'll regularly monitor the project's outcomes against the plan to make certain everything progresses according to plan. The four things you'll monitor closely for performance during this phase are the project schedule, budget, scope, and quality.

Performance Reporting Tools

Several techniques are available that you can use to monitor project outcomes. We'll take a brief look at each of these techniques below. It's beyond the scope of this book to go into the details of these techniques because many of them involve complex math calculations, graphs, and methods that are at the advanced level of project management. If you're interested in further study, there are several books on the market that deal with these techniques.

Note

Monitoring project outcomes and taking measurements occurs during the Controlling phase. However, you should establish what to measure, how to measure, and what project outcomes to monitor during the Planning phase of the project. If you have waited until the Controlling phase to determine what to measure, you may be too late; you could end up measuring on-the-fly and producing results with little value or meaning. Or you may have already missed opportunities to correct poor project performance because some of the work is already completed.

Status review meetings Project status meetings allow you to collect information from the project team members regarding progress. We discussed status review meetings in Chapter 10, "Executing the Project." Don't forget to visit informally with your team members as well to maintain up-to-date information on project performance.

Variance analysis This technique compares the expected project plan results with the actual results to determine whether variances exist. You'll use this technique primarily to determine schedule variances, budget variances, and quality variances. Variance analysis can be used for risks, scope, and performance specification measurements as well.

Trend analysis Trend analysis involves analyzing project results periodically to determine whether the project performance is improving or getting worse. Mathematical formulas are used in this technique to forecast project outcomes based on historical information.

Earned value analysis Earned value analysis is the technique used most often to determine project performance. Earned value is unique because it calculates cost, schedule, and scope measurements together to determine various indexes, performance measures, and variances. Several formulas and measurements are used in this technique to determine forecasted costs of the project at completion, the actual costs of the project to date versus what was budgeted, schedule variances, performance indexes, and so on. There are entire books available on this technique alone.

Inspection Inspection is most often used in quality control. This involves physically looking at the results and measuring them or testing them to determine whether the results meet the requirements or quality standards outlined in the plan.

Control charts Control charts are used to measure and plot the results of processes over time. You can measure and display variances, track measurements, compare variables, and so on. There are several forms of control charts including variance control charts, flowcharts, Pareto diagrams, scatter diagrams, and numerous industry-specific controls.

The goal of gathering data and measuring the results is to control the project outcomes so that they conform to the requirements and so that the project process conforms to the project plan. When you've taken some of these measurements and determined that variances do exist, you'll need to take corrective action to put the project back on track.

Corrective actions involve a variety of options and depend on the project and the problem you've encountered. For example, say you've performed some variance analysis on your project schedule. Prior to conducting the analysis, you determined that the control limit for schedule variances for this project is 10 days. If schedule variances are less than 10 days, no action is needed. If you discover that the variances are greater than 10 days, you'll have to take action to get the project performance back in line with the plan so that the variances are minimized or eliminated. You could add resources to the project, move some deliverables to phase two, eliminate some of the requirements and the tasks associated with them, and so on to get the schedule back on track. Remember that updates to the project Planning documents will be required when corrective actions are taken.

corrective actions

Actions taken to align project performance with the project plan.

Note

After you've taken corrective action, it's important to measure the results to make certain that the action was effective and that you're getting the outcome you planned.

The project Planning, Executing, and Controlling phases are revisited several times throughout the project. Updates to the plan require the execution of the new plans. Controls and corrective actions require changes to the plan that require new tasks to be carried out and measured against the plan. Corrective actions may not always require new project plan updates, but they will require a trip back through the Executing phase as the corrective actions are put into place.

Not all projects require formal measurement techniques. However, the most important Controlling technique you can use is to regularly gather information regarding the project status, meet with team members formally and informally, and remain aware of all the activity on your project. This all goes back to communication. Taking an active role in knowing where the project is compared to the project schedule and other project plans is your best defense against project problems taking you by surprise.

Risk Monitoring

Another important part of the Controlling process is monitoring the project for the occurrence of potential risk events. (We identified risks and developed risk response plans in Chapter 7, "Assessing Risk.") Schedule periodic reviews to check the risks identified in the risk plan and reexamine their impacts. Monitor the risks and their status to determine whether the impacts you identified in the risk response plan are still realistic. It could be that some of the risk events now have reduced impacts while others have increased impacts.

Tip

Be on the alert throughout the Controlling process for risk events. Actively review all the identified risks, and remind your project team members to keep you informed of any risk triggers.

New risks might come to light as a result of measuring and monitoring project performance. When this occurs, document the risks in the risk plan and create response plans for them. Remember to update the existing risk response plan with the newly created responses.

Is the Project in Trouble?

Not only is change a guarantee on your next project, so also are problems. Problems aren't always bad and they don't always mean an end to life as you know it. But if you aren't careful, problems can quickly get out of control and wreak havoc on your project. The monitoring process we discussed, in which you put on your eagle eyes and watch for every sign that something may be amiss, is one way to determine whether problems are about to get out of control. Monitoring and controlling project changes will also keep problems at a manageable level.

Unfortunately, there are times when schedules or budgets or key personnel do run amuck and the damage to the project is not repairable. This section should alert you to some of the warning signs that the project is headed the wrong way down a one-way street. If you recognize these signs early enough and deal with them correctly, you may avert a head-on collision with an unsuccessful project.

Just Say No

Before we look at some of those early warning signs, let's talk about flat-lined projects. Sometimes it's time to pack up the project management tool bag and go home. You and the team have put a lot of time and effort into the project, but it is so far out of control that there's no coming back. When that's the case, the best call to make is to end the project.

Most of the things that will cause the project to get to this point are the same as the warning signs we'll look at next. If you've done a good job creating the project plan, communicating with stakeholders and the project team, and monitoring and controlling the performance of the project, you have nothing to be ashamed of. Sometimes projects end on their own accord; they outlive their usefulness and the organization drops interest in the project. Other times projects are killed by overzealous stakeholders attempting to make a career-boosting move that will propel them into the Big Boss seat.

Let's take a look at some of the other warning signs of project problems that could become project killers.

Early Warning Signs

Lest I sound redundant, you've seen many of these signs before. I just want one last chance to tell you how important it is to keep your eyes peeled for these signs. It's not unusual for seasoned project managers to have a failed project or two under their belt—but projects that fail as a result of the project manager's error, lack of preparation, or oversight are not going to win you that promotion to the project management director's position anytime soon. Here we go.

Poor planning techniques are starting to influence the scope, schedule, quality, or budget of the project. How many more ways can this one be said? The better your project planning skills and the better your documentation, the easier it will be to manage your project and the higher the chances of completing a successful project. Poor project planning techniques are a sure indicator of an unsuccessful project.

You and your team start telling key stakeholders what they want to hear instead of the true project status and issues. Never tell the sponsor and the key stakeholders only what they want to hear. This is a sure sign the project is headed for disaster. They might not want to know about the problems and want only the good stuff reported to them, but it's your job to tell them anyway. If you don't inform them of problems and issues, they'll make you the scapegoat when it all crashes in, and I think you know what happens after that.

People don't know what's going on, they don't understand their jobs or deliverables, and rumors are spreading. Communicate well and communicate the right information to the right people. Be an active listener, watch for nonverbal cues, and let the sponsor and key stakeholders know about important project information almost as soon as you learn it yourself. Many times they can help you resolve problems in ways you wouldn't have thought about. And don't forget the honesty factor. Tell them the truth, even if it hurts. They can't help you resolve problems they aren't fully informed about.

The project started late but is still expected to finish on time. This can cause problems later in the project. Delayed starts aren't uncommon because key personnel may not be ready for the new assignments, the budget may not receive approval prior to the planned start date, and so on. If no schedule changes are permitted, use some of the techniques we discussed earlier such as crashing and reducing scope to help meet the project schedule.

Budget cuts are impacting the project dramatically. This can be a sure project killer. This might be one of those situations where it's time to pack up and call it quits. But don't come to that conclusion too quickly. Assess the impact on the scope and schedule and see if there are ways to work within the new limits. If not, just say no. Let the sponsor and stakeholders know that it's not possible to complete the project with the existing requirements with the budget cuts they've proposed.

The team is starting to lag behind due to poor duration estimates or lack of skill. Or, they're motivated and committed but don't possess the skills needed to do the work of the project. Consider hiring subject-matter experts to help with the lack of skills problem, and encourage these experts to mentor your team members. If poor duration estimates are the problem, consider having the estimates examined by a third party or a knowledgeable expert from another department before using the estimates to complete the project schedule. If you're already in the midst of a project with this problem, consider changing the project priorities, asking for more resources, or requiring overtime to catch up with the schedule. This is another problem area where you may reach a point of no return. If it becomes evident that the team has taken on more than they're capable of, you'll need to be honest and inform the sponsor that the existing team isn't going to be able to complete the project.

Your team members start regularly stating, "I'm almost finished." This is an award-winning line in the Information Technology industry. There is no good way to measure how far along a programming task has progressed, so you have to rely on the lead programmers to judge (by their experience) how close they think they or their team members are to completing the task. The problem comes when you've heard this statement for the past six weeks from the same team member. The only way out of this one is to communicate and stress the importance of honest reporting.

You have too many changes. Too many changes can cause the project to end up very different from what it started out as. Manage changes and stick to the agreed-upon scope of the project, as discussed in the previous section.

You and your team realize that the project should never have been started in the first place. The objectives are beyond the ability of the project team to perform, the time expectations are unrealistic, or the budget is unrealistic. When you know this up front, inform the sponsor and decline to manage the project if they aren't willing to work with you to correct the problems. If you don't realize this until later, you'll have to document your findings and recommend to the sponsor shutting down the project.

Stay informed of problems and meet them head on when they occur. Remember to keep the sponsor and key stakeholders informed because they will often be able to help you resolve problems or obtain resources that are outside your authority.

Terms to Know

change control board
change management plan
corrective actions
crashing
fast tracking

Review Questions

1.	Name three ways that change comes about on projects. ____________________________________________________________
2.	Why should change requests be submitted in writing? ____________________________________________________________
3.	What is the purpose of a change management plan, and when in the project life cycle should it be created? ____________________________________________________________
4.	What types of information should be included in the change management plan? ____________________________________________________________
5.	What is the purpose of a change control board? ____________________________________________________________
6.	Scope changes always require changes to what other Planning document? ____________________________________________________________
7.	Name two options you can examine when faced with scope or schedule changes. ____________________________________________________________
8.	Name the two schedule compression techniques. ____________________________________________________________
9.	What is fast tracking? ____________________________________________________________
10.	What is the most important Controlling technique you can use when monitoring the performance of the project? ____________________________________________________________

Answers

1.	Change comes about on projects for many reasons: stakeholder requests, customer requests, team member recommendations, business changes, the result of risks, and so on.
2.	Change requests should be written to avoid miscommunication and confusion and so that they can be tracked, reviewed, and analyzed for their impact on the project.
3.	A change management plan helps you understand what causes change to come about and when and why the change is needed, and it establishes the procedures for change. It should be created in the Planning stage of the project life cycle.
4.	The change management plan should describe where to obtain forms for change requests, how to submit change requests, how the changes are approved, and the authority level of the project manager and change control board.
5.	The change control board is responsible for reviewing, approving, or denying change requests.
6.	Scope changes always require changes to the project schedule and include any changes to the agreed-upon WBS.
7.	When faced with scope or schedule changes, you can consider bringing in more resources, modifying the scope of the tasks, or reducing the scope of the project by moving deliverables to another phase of the project.
8.	Schedule compression can be accomplished with fast tracking or crashing the schedule.
9.	Fast tracking means starting two tasks at the same time that were originally scheduled to start sequentially.
10.	The most important technique you can use to monitor the progress of the project in the Controlling phase is to stay up-to-date on project status by holding regular team meetings and maintaining open communication with project team members by meeting with them informally.