Section 10.4. Managing Project Change

10.4. Managing Project Change

Managing change is one of the major jobs for the IT PM and IT team during the work phase of the project. When change occurs, the first step is to look for the root cause of that change. Is it the project definition? The plan? The WBS? External factors? If you don't look for the root cause of the change, you will miss opportunities to improve your project management skills. Change means that something is not going according to the plan, but we all know that plans are rarely perfect. Assessing what is causing the change will help you not only address this issue, but may also help you foresee additional issues that might stem from the same root cause. During the course of the project, the scope, schedule, budget, quality, or requirements can change. The impact these changes have on other tasks and on the project as a whole can range from negligible to extensive. "Manage change or it will manage you" is very true in project management. In this section, we'll look at these and discuss how to deal with change so it doesn't derail your project.

10.4.1. Change Due to Variance

Earlier, we said that if there was any variance, we needed to look at the cause of the variance and then decide what to do. We really have four primary choices in terms of dealing with variance and they are:

• Ignore the variance You can choose to ignore the variance, and in some cases this is the best option. When would you choose to ignore the variance? If a task is not on the critical path, minor variances to its schedule may not be all that important to the outcome of the project. If a task's variance on cost is easily explained and you have the reserves to handle it, you may choose to do nothing. Minor price variations of supplies are an expected source of variance and can usually be ignored. Let's be optimistic for a moment. Perhaps something comes in ahead of schedule or costs less than anticipated; you might choose to ignore the variance, though you might want to investigate so you can learn how to repeat that kind of success. Don't be fooled, however. When a task comes in far ahead of schedule or far under the estimated cost, it could be a sign of trouble, as mentioned earlier.

• Take appropriate action to address the source or effect of the variance Most of the time when you identify schedule or cost variance, you'll need to take steps to address the variance. These steps could include shuffling resources around, modifying the project schedule, reducing project scope, cutting costs on another task, etc.. The appropriate action should be evaluated in terms of any additional risk it may bring to the project and what impact it will have on other tasks and the project as a whole.

• Revise the plan to reflect the variation Sometimes the variation is such that it requires a revision to the project plan. An example of that might be that a component you were going to use in the project suddenly jumps in price by 500% due to a manufacturing plant going off-line (due to strike, natural disaster, etc.). You may need to go back and revise the plan to deal with this variance in cost. You might choose to select a different component or build the component in-house. These all require changes to the project plan and each change should be carefully thought out before being implemented because changes to the project plan (at this point) come with greater risk. There's a saying that "Problems are often born of solutions"sometimes we fix one thing and break four others. This is especially true in software development, but holds true in all types of IT projects.

• Cancel the project One of the options that people hate to consider at this point is canceling the project. However, sometimes it's better to cut your losses and move on. If a variation to the project schedule will delay the project to the point that it's no longer useful, it should be cancelled. An example of this might be a project to develop an interim software solution until the network servers are all upgraded. Once the upgrade is complete, the interim solution will be scrapped and a permanent solution will be installed. If the network upgrade is supposed to take 24 months and the interim solution is delayed and isn't going to be available until month 18, it might not be worth finishing the project. Another example is when a project gets in trouble financially due to cost overruns that make it impossible or inadvisable to complete the project. While sound planning can help you avoid some of these scenarios, it can't prevent them completely and sometimes the most prudent course of action is to cancel the project.

Now, let's turn our attention to areas that might have variance, why they might have variance and what you can do to manage variance to get your project back on track.

10.4.2. Changes to Schedule

Managing change to the project as a whole is part of change management and it should follow your established guidelines for change management developed in your definition and organization stages. By monitoring the project schedule, reviewing performance and status reports, and managing change requests, the IT project manager can control the project schedule to the greatest extent possible. However, the project schedule is one of the parameters that almost always shift as work progresses. The question is, how do you manage these changes without going crazy or putting your project at risk?

The schedule is the number one thing that tends to change in the implementation phase of the project because we can't know with absolute certainty how long tasks will actually take. Ideally, using subject matter experts and historical data, your estimates are very close to actual. Still, there are unexpected things that always pop up that make changes to the schedule almost a foregone conclusion. Resources become unavailable even if they were previously assigned to the project, resources get overbooked, people leave the company, delays in preceding tasks require resources to be shuffled aroundthe list is almost endless.

Managing schedule changes means staying on top of current task progress and looking ahead a step or two in the project to make sure resources are lined up. Your risk management planning should have addressed the major risks to your schedule and that planning should have looked closely at all risks to the tasks on the critical path. You should have a "Plan B" identified for tasks on the critical path and you should understand the impact of delays or changes to the schedule of these tasks. If change is required, assess the impact on other tasks and to the critical path before implementing schedule changes. Sometimes a solution creates more problems than it solves, so don't jump too quickly. Look first for optimal solutions and then look at the reality of your situation. By looking first for the "best case scenario" you might spot an opportunity or two that you would otherwise have missed. Granted, some schedule changes are simply pushed on youa task is delayed and it's not clear it will be late until the very last minute. These types of changes are difficult to manage but you should strive to respond rather than react. Responding is a rational action based on new information; reaction is typically an irrational or poorly planned action based on new information. Your first step, after assessing the situation, is to see if there are tasks that can be rearranged in order to accommodate the schedule changes. Sometimes these exist and the schedule can easily be modified without changing the project parameters (scope, time, cost, quality).

There are two commonly used methods you can use to get your schedule back on track if things really take a turn for the worse: crashing and fast tracking. Crashing occurs when you add more resources to the project to ensure it completes on time. Clearly this has an impact on your budget because additional resources cost additional money. Hopefully your reserve amounts will cover all or most of this additional cost should crashing become necessary. The danger of crashing is that adding more bodies does not always translate into more work being completed. A good analogy is that a race horse doesn't go any faster with two jockeys than it does with one (and in some cases, it goes slower). In software development, there is a point at which more bodies will mean less work accomplished, so caution should be used when deciding to crash a project schedule. Make sure that more bodies really will help. An example of when this might work well is when you have to install 50 servers in five locations. In that case, more bodies may well get the job done faster.

Fast tracking occurs when tasks that normally would be done sequentially are done in parallel (at the same time). This allows tasks to be done either at the same time or with some overlap. An example of fast tracking might be that servers will be installed as soon as they pass final QA testing rather than once all the servers for a particular location are ready to go. The danger to fast tracking is that you risk rushing things and this increases risk, especially to quality. Rework is often the result.

Applying Your Knowledge

You would typically crash or fast track your schedule if schedule (time) was your least flexible project parameter. There are risks with both methods and neither assures you that your project will still complete on time. If schedule is not your least flexible project parameter, you may do well to simply push your completion date out rather than incur the risks these two methods bring to a project.

10.4.3. Changes to Budget

The budget is managed first by creating realistic estimates for the cost of the project (not necessarily the estimates your boss wants to hear). Once the initial budget and reserve amount are decided upon, a baseline should be established. Monitoring the cost of each task and the total, cumulative cost of the project regularly is the key to keeping project costs under control. You can use percent complete, variance, or some of the techniques we'll discuss in Chapter 11 to analyze where you are with your project budget. If the project budget starts getting off track, you'll need to start rearranging things to stay on track. Remember, though, that you should keep your flexibility grid in mind as you decide what to do. If budget is your least flexible item, you may have to push your schedule out so you incur fewer costs in a given period of time or so you incur fewer costs overall. You may also have to go back to the planning stage to determine how you can accomplish the remaining work for less. Budget issues stem from four types of problems: flawed estimates, accounting anomalies, permanent variances, and minor variances.

Flawed estimates require a new estimate to be created. This is known in the formal project management world as generating a new Estimate to Complete (ETC) because you know that the original estimate was simply wrong. This new estimate should specify the additional amount needed to complete the project as well as the actual cost to date. If known, it may be helpful to note why the estimate was flawed as well as any lessons learned so you and the team can avoid these errors in the future.

Anomalies are like hiccoughsthey come out of nowhere, they take you by surprise, and there's not much you can do about it. These types of situations are one-time events that significantly impact your budget, so you will have to account for them after the fact, though you can't plan for them before they occur. Your reserve amount might cover the cost of an anomaly, but you might choose to make this a discrete line item so your reserve amount can be used for the normal budget variances that will occur. Here's an example of one such scenario. You've ordered fifty new servers and as they arrive (five at a time) your team begins to unpack, configure, test, and install them. It's not until you have 35 servers installed that they start failing and you discover there was a manufacturing problem and all the servers are all defective. The vendor is willing to replace them immediately, but you've already spent a large portion of your budget (and schedule) unpacking, configuring, testing, and installing these servers. In order to complete the project on time, you contract with an external IT company to come in and assist with these tasks on the replacement servers. This unplanned event blows your budget out of the water. It's not an estimating error but an anomaly that is unlikely to occur again in the future (if it does, fire that vendor). All you can do is deal with the anomaly. These types of variances can be small or large, and what differentiates anomalies from other types of variances is whether they could not have been reasonably foreseen and are not likely to occur again. Large anomalies can cause projects to be cancelled at this stage, but small anomalies can usually be incorporated into the project.

Permanent variances are variances that are expected to be typical for the remainder of the project. An example of a permanent variance is that the materials you needed have gone up in price by 20% but that price increase is locked in for another 12 months, so while you are protected against any further increases the remainder of your project will show a -20% variance (remember, a negative variance means your plan is better than your actual) on this line item. Another example of a permanent variance is if the people assigned to the task are not as skilled or competent as expected. They make take more time to complete tasks (more paid hours), you may have to provide additional training, or you may have to bring in outside contractors to assist. This causes permanent variances moving forward unless other actions can be taken. Permanent variances may or may not be addressed by the reserve amount. In some cases, the permanent variance should be added to the cost of the project and the reserve left intact to account for other minor variances that may occur. How it is handled is a matter for you, your project sponsor, and your Accounting department to decide upon.

Minor variances also occur in projects, which is why you created a reserve amount in your budget for each phase of the project (or each major deliverable). These are to be expected and you may choose to set a threshold for "minor" so that you and the team are clear what minor means in terms of a budget variance. Certainly you don't want to get pulled from a meeting if the cost of a task will exceed budget by 5%. By the same token, 5% variances can add up quickly. Define acceptable variances and closely monitor your reserves.

Cheat Sheet…
Bring in the Reserves

Remember when you created your schedule and budget based on your WBS and your best estimates for time and cost? You created reserves for each based on a number of factors. When evaluating change to the project, make sure you remember your reserve amounts. Most minor variances can be dealt with from the reserves. Major or unanticipated variances often have to be handled differently. Typically these major variances must be added to the overall project schedule and/or budget rather than being handled through reserves. This will help you keep the project on course by leaving you with reserves to provide flexibility to address the day-to-day variances that occur. You may have to "spend" your entire reserve amount if the variance is huge, but that means that every other task (both time and cost) will have to hit dead on for the project to complete as expected. The odds of that are about the same as winning the state lottery, so be wary of using up your reserves for large, unexpected variances (your project sponsor may require you use your reserves respond to a large variance, but that won't change the fact that minor variances will still occur).

10.4.4. Changes to Scope

Changes to scope can be managed or unmanaged. Unmanaged changes to scope are often referred to as scope creep. Scope creep occurs when the amount of work expands after the project plan has been agreed upon and approved. One of the ways this occurs is through team members interacting with users or stakeholders and informally agreeing to changes outside of project meetings. Another way this occurs is when executives or your project sponsor insert work into the project after the plan is set. Your first line of defense is to make it clear to your team that the only changes to the work of the project that are made are those discussed and agreed upon in project team meetings. Your scope of work is modified when a proposed change is approved and incorporated into the project plan. For instance, if you have a permanent budget variance, you (you, the team, project sponsor, stakeholders) may decide to reduce the scope of the project so that the final budget is closer to the planned budget. This would indicate that budget is least flexible and scope is somewhat (or most) flexible. Another time you may choose to reduce scope to meet schedule requirements or hard deadlines. You may choose to increase the scope in order to accommodate market or user changes or to incorporate a leading edge technology that just became available. However, increasing scope also means something else has to change. Remember the relationship between scope, time, cost, and quality. When your scope increases, you'll have to increase your schedule, increase your budget, or reduce your quality to accommodate this change. In some cases, you may be able to add scope without impacting schedule or budget, but those instances are few and far between.

Requested changes almost always impact scope in one way or another, so the logical starting point is your Work Breakdown Structure. Remember that your scope is essentially defined by the tasks in the WBS, so managing your scope means managing the tasks of the project. Change might be in the amount of work requested, changes to the attributes of the deliverables, or changes to the methods used to create the deliverables. Each of these changes should be evaluated to determine the change to the WBS so that you will know where tasks need to be added, removed, or modified to accommodate the change. Then you should evaluate whether the requested change is logical, desirable, feasible, and affordable. You also need to understand how this increased scope will impact the remainder of your project, especially as it relates to schedule, budget, resource allocation, and tasks on your critical path. Once you understand the nature and impact of the requested change, you can make a determination as to whether or not (or how) to implement the change.

Reviewing status and progress reports can also lead to change requests. It's possible that as work progresses, it becomes clear that the project will not be able to deliver on one or more objectives as it currently stands. This might become clear through reporting and analysis of progress reports. It's also possible that through progress reporting you discover the project is on better footing that you planned and you can accommodate that last-minute, "must have" feature that users have been clamoring for.

Cheat Sheet…
Scope Creep 101

One of the most common problems that happens in projects is scope creep. Scope creep is sneaky and it often happens when you least suspect. When managing a project, it's important to continually keep an eye on scope. Every time you consider making a change, you should ask what effect the change will have on scope. There are a lot of changes that can happen in a project that have a relatively low impact, but changes that impact your scope ripple through your project and become magnified. To avoid the ripple effect of scope creep, make sure you continually ask if changes will impact scope and then decide whether that's acceptable or not. Be sure to understand how and where that ripple effect will occur.

10.4.5. Managing Change Requests

Change requests typically involve changes to scope, but they can conceivably involve changes to schedule, budget, or quality. Changes to functional or technical requirements usually fall in the category of scope change. Change can come from verbal or written requests, from inside or outside the organization, or from legal or regulatory requirements. Regardless of the nature of the change request, one of the most important tasks of an IT project manager during this phase is to manage change requests. If your team is constantly shooting at a moving target, it's unlikely the goals of the project will be met. Change control is the way you prevent the moving target syndrome. Though we discussed change management earlier in the book, it's worth repeating at this juncture.

First, your change management process should be clear about how change can be requested, how change is evaluated, and how change is made to the project. Most change requests fall into one of four categories: errors or omissions, risk response, value-added, or external events.

Errors and omissions are perhaps the most common source of change requests in a project. Through the project management process, you've attempted to reduce or eliminate the need for rework due to errors or omissions, but they sometimes still occur. The error or omission might be due to a forgotten or overlooked task in the WBS (one that should be in the WBS and is not), an overlooked or forgotten feature of the project deliverables (functional specification error), or an error in the technical specifications discovered during the work phase. Changes that address gaps or shortfalls in the project must be assessed based on their impact to project scope, schedule, budget, quality, requirements, and risks.

Change also occurs when you have to respond to project risk (risk response), whether planned or unplanned. If you have to implement "Plan B" for a particular work package or project phase, that forces change on the project. Having to develop "Plan C" on the fly due to unforeseen circumstances also forces change on the project. The degree to which change occurs as a result of implementing contingency plans should be part of the risk management and assessment phase. If it wasn't assessed at that time, make sure you and the team take a look at the impact of Plan B to your project's scope, schedule, budget, requirements, and quality before implementing it. Even if you assessed your risks associated with Plan B, it's always a good idea to re-evaluate them based on the current project status and data since many things change between planned and actual as work progresses.

Value-added change requests are just thatthey are changes that will add value to the project such as a change that will reduce the overall cost of the project or a change that will shorten the project schedule by two weeks or a change that will add functionality, usability, or other desirable features to the project. Value-added change is typically a positive thing, but it should be scrutinized just as any other change should be.

External events can drive change requests as well. If you're developing a software product that deals with finance, you may have to change your specifications in response to changing local, state, or federal laws. These are external events that should have been assessed during the risk assessment phase ("What external factors might impact your project?"), but these kinds of changes cannot always be known in advance.

Requesting change to the project should be a formal process. You can download a change request template from the Syngress website if you don't already have a solid change request process in place. The elements of a change control system include:

• Document requested change and reason for request.

• Evaluate impact of requested change on scope, schedule, budget, requirements, quality, and WBS.

• Determine whether or not to implement change.

• Determine approval levels needed (if any).

• Determine if any special communication is needed with respect to the requested/approved change.

• Integrate the change into the project plan.

• Update any related external plans impacted by the change (training, operational transfer, etc.).

• Document lessons learned, if applicable.

10.4.6. Taking Corrective Action

Any corrective action you take is, by definition, a change to the project. It's important to understand this so you don't inadvertently introduce new problems into the project. If you recall from our discussion about quality in Chapter 7, change becomes riskier and more expensive the further out in time you go (that is, the further into the project work you get). Each change carries its own unique set of risks and it's your job as IT project manager to weigh the risks and the benefits of the change. Once you've evaluated the reward relationship, you can make an informed decision as to the proper course of action. Some changes may be mandated (by the project sponsor, stakeholders, or legal requirements) and you have only two choices: make the required change or terminate the project. In some cases, you may choose to terminate the project because to incorporate the required change would cause the project to fail. In other cases, you have to determine the impact of the required change and modify your project plan (including scope, schedule, budget, requirements, quality metrics, WBS, and task details) to reflect that change. Corrective action could (and often does) introduce new problems, so don't take corrective action without fully assessing the impact on the project.

The IT Factor…
Responding to Change

When the folks at NASA and the Jet Propulsion Laboratory were preparing the Mars mission, they had a hard deadline because there were only certain times the rocket could be launched when the planets were properly aligned for the mission. During the course of the project, the team creating the landing system discovered they'd underestimated the actual weight of the Mars vehicle (designed by a different team) and had to go back to the drawing board to redesign a landing system that could accommodate the weight of the vehicles. They didn't have a choice about making this change nor did they have a choice about the schedule. In their case, the schedule was the least flexible item, and quality was a close second because it wouldn't do to meet the deadline and have the Mars vehicle crash and burn as it landed on the surface of Mars. Their team raced against the clock to get the project completed. Another team responsible for the software systems had the launch and landing software tested and ready to go, but were unable to complete the surface navigation software in time. However, they knew that they had a small window of opportunity to complete this task without putting the mission at risk because the navigation software had two flexible features the rest of the mission did not: it was not required to be completed at launch (no finish-to-start dependency with launch) and it could be modified on the fly by beaming the new software code up to the vehicles once they were en route to Mars or even on the surface of Mars.

This is a great example of how projects progress. Errors, omissions, and changes will occur, even when it is rocket science. The key is how well you assess your options and how innovative you can be in responding to change.