ProjectControl

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

3.1: Identify the specific tasks that should be accomplished on a weekly basis in the course of tracking an up and running project.
3.2: Given a scenario with a set of project performance indicators, demonstrate the ability to recognize when performance problems are occurring on the project and determine if/when corrective action/recovery needs to occur.
3.3: Given a scenario with updates/changes made to the project plan, demonstrate the need to check for various project impacts.
3.4: Given a scenario involving a project with a schedule delay, choose an appropriate course of action.
3.5: Given an approved project and a status report scenario containing a significant variance from plan (e.g., excessive overtime, purchased items more expensive than anticipated), identify and determine solutions and accommodations for such a variance.
3.9: Identify issues to consider when trying to obtain approval of a changed project plan that is still within expected budget, but has a schedule that extends outside of the original baseline end date.
3.10: Define and explain estimate to complete (ETC), estimate at completion (EAC), and budget at completion (BAC).
3.11: Demonstrate the ability to track the financial performance of a project, given the financial management baseline and data on the actual performance of the project.
3.12: Given an approved project plan and a specific scope deviation (e.g., design, schedule, or cost change), demonstrate your ability to identify, prepare, determine, and quantify key elements of change control.
3.13: Identify and justify the conditions for initiating a change control process.
3.14: Given scenarios involving requests for changes from sponsors, team members , or third parties, recognize and explain how to prevent scope creep.
3.15: Recognize and explain the importance of communicating significant proposed changes in project scope, and their impacts, to management, and getting management review and formal approval.
3.16: Identify and explain strategies and requirements for maintaining qualified deliverables, given a large project with many team members at multiple locations (e.g., communication standards, work standards).
3.17: Recognize and explain the importance of testing in situations where tasks are being performed by both project team members and third parties.
3.18: Identify and explain strategies and requirements for assuring quality during the turnover phase (e.g., user docs, user training, help-desk training, or support structure).
3.19: Identify and explain strategies and requirements for assuring quality of deliverables and meeting sufficiency standards during each phase.
3.20: Recognize the need and explain the importance of controlling changes on the configuration of the project deliverable .
3.25: Given an initial high-level scope, budget, and resource allocation, demonstrate understanding of the need to investigate the aspects of the project that could be modified to improve outcomes (i.e., find out what is negotiable, prepare to negotiate).
3.32: Given a project team meeting scenario, demonstrate the knowledge to review an issue log with team members and secure closure of issues.
3.33: Demonstrate the ability to prioritize issues by severity and impact on quality.
3.34: Demonstrate understanding of how to determine if/ when planned risks have materialized and how to implement planned risk mitigation and removal strategies.
3.35: Demonstrate the ability to prioritize risks by severity and impact on quality.
3.36: Demonstrate the ability to remove/mitigate a project risk.
3.37: Demonstrate an understanding of how to report to the project sponsor that a project is in jeopardy and how to report corrective action strategies that are under way.
3.38: Demonstrate understanding of how to determine when a project should be prematurely terminated .
4.3: Recognize the need for acceptance testing (user acceptance testing, factory acceptance testing, site acceptance testing) of the project deliverable.

In the course of executing your project plan, you continually monitor results. Deviations from the project plan can be warnings that changes may be required to your original project plan. Requests are received during the course of the project to add new requirements or to expand the scope of the project work. You need to implement change control processes to deal with these requests.

Integrated change control looks at the overall impact of change and manages updates across all elements of the project plan. Scope change control includes recognizing that a scope change has occurred, taking appropriate action relative to a scope change, and managing a process to review and approve or reject requests for scope changes. Schedule control entails knowing that a change to the schedule has occurred, taking the appropriate action to deal with the schedule change, and updating the schedule based on changes in other areas of the project plan. Cost control involves being aware that the project costs have changed from the estimate, understanding when cost changes require response, and updating the budget

Quality control monitors the project deliverables against the project requirements to ensure that the project is delivering according to plan.

Performance reporting provides information to the project stakeholders comparing the work results produced by the project with the information contained in the comprehensive project plan. Variance analysis, trend analysis, and earned value are used to assess project performance.

Risk control implements the risk prevention strategies or contingency plans developed in your risk response plan, monitors the results of preventative actions, and assesses new risks to the project.

Changes to the project plan may result in stakeholder action requiring trade-offs between scope, cost, time, and quality. We ll discuss these processes and techniques in this chapter.

Integrated Change Control

At this point you probably are thinking that with all the time and effort that went into planning, you should not have to worry about any changes. Everything is documented in the plan and the stakeholders signed off, so it should just be a matter of execution. That would be nice, but in the real world things change: a new business strategy, a competitive threat, or a new technology that was not available when you did project planning.

All aspects of the project plan are subject to change as the project progresses; the key to avoiding chaos is to manage any change in an organized fashion with an integrated change control system that looks at the impact of any change across all aspects of the project plan. A lot of time is spent in the planning phase developing estimates and plans for managing the project. Unfortunately, some project managers tend to forget all of that and just shoot from the hip if things go astray. You need to keep referring back to your planning documents and the management processes you put in place to update the plan.

Depending on how your change control process is set up, there may be a change control committee including the sponsor, the client, and other executives that reviews all changes, or the changes may be worked though the project team. Typically, larger and more complex projects have more formal change control. Regardless of who is involved in reviewing and approving changes to the project plan, changes that go outside established limits need to be presented to the stakeholder team. We will discuss stakeholder action later in this chapter.

Lets take a look at what is involved in controlling changes to scope, schedule, cost, and other elements of the plan.

Scope Change Control

As part of Scope Planning in Chapter 3, we discussed the need to define and document a scope management plan. As your project work progresses, you will implement this plan to control the scope of your project. Scope change control is the management and documentation of any changes to the project scope.

The following are some of the events that can trigger the need for the scope change process:

A review of a major deliverable determines that there have been additions to what was defined in the project plan.
Project team members indicate that they have made changes to a requirement.
There is a formal request to add to the project deliverables.
There is a design change.

In an ideal world, no change would be made to the project scope without going through a formal scope change approval process. In the real world, developers have conversations with end users or someone comes up with a different way of doing things and suddenly your scope has changed. If you discover that you are a victim of scope creep and a change has already occurred, you should still run the change through the scope change process to analyze the impacts to the other parts of the project plan and to secure formal approval for the change.

Lets review the key steps of the scope change process:

Use a standard scope change request form with a description of the change, the reason for the change, and the originator of the request.
Analyze the impact of the scope change request on the budget, schedule, and quality of the project.
Use an approval process to accept or reject requests .
Communicate results of scope change requests to all stakeholders.
Incorporate approved changes into the project plan.

Scope changes may require corrective action and/or changes to the baseline.

Corrective Action If your project has become the victim of scope creep, you may or may not want to continue down the path that has created the scope change. You may need to determine what action is required to get the project back on track. It may take time to undo what has been done. In addition, you will want to investigate how the scope creep occurred and take steps to prevent future scope creep, such as educating team members on the scope change process.

Baseline Adjustments Any scope change, either planned or unplanned , will require updates to at least a portion of your baseline planning documents. At a minimum, you will update the scope statement. You may also make changes to the schedule baseline and the cost baseline, depending on the magnitude of the change.

Scope change control results may have a significant impact on schedule control, as you will see in the next section.

Schedule Control

As you review progress reports from project team members and the updates to the project schedule, your goal is to confirm that activities are on track or that any changes have been analyzed for impact to the critical path. Changes to the project scope will also require analysis regarding impact to the schedule. Schedule control is the process of managing and documenting any changes to the project schedule.

Project management software is an extremely useful tool for schedule control. Software packages can provide an individual task view of planned start and finish dates compared to actual dates, as well as forecast the impact of any changes from the baseline schedule to linked tasks, the critical path, and the project end date. You can also do what-if scenarios, to show the impact on a particular phase or even the project end date if task duration is changed or new tasks are added due to an approved scope change.

The key to making the best use of team member progress reports and the various reports and views using project management software is to focus on the critical path tasks. Remember that the critical path tasks are on the longest path of your network diagram and drive the end date of the project, so any delay to one of these tasks may lengthen the total project time.

Schedule control results include schedule updates, corrective action, and lessons learned.

Schedule Updates A schedule update is any change made to the project schedule as part of the ongoing work involved with managing the project. Schedules are typically updated weekly based on the team member progress reports to provide a current view of schedule progress and a comparison of status of the completed project work to the schedule baseline. Schedules are also updated to reflect new activities.

You may hear two terms in relation to schedule update. A revision is an update to the approved start or end date of the schedule baseline. Revisions are typically a result of approved scope changes. If a schedule change is substantial and impacts dates for multiple milestones or major deliverables, rebaselining may be required to provide a new means of measuring performance. Rebaselining should not be done lightly, as it distorts the accuracy of your original plan.

Corrective Action A number of factors come into play when considering whether corrective action is required as part of schedule control. Activity duration estimates are not expected to be perfect, so dont think you need to do something every time the actual time required to complete a task does not match the estimates. If an activity has a delayed start or is taking longer than expected, but has float time such that there is no impact to successor tasks, you dont need to take any action at this point. Your emphasis on corrective action should focus on critical path tasks.

Performance indicators can tell you that things are going wrong. Lets take a situation where critical path tasks are taking longer than planned and a major milestone may potentially be missed and/or the project end date is in jeopardy. The performance of critical path tasks impacts your ability to complete the project on time, so you need to look at what can be done to get the project back on schedule. Your first course of action should be to determine why the critical task is behind schedule and work with the person(s) assigned to the task to get it back on track. If you have a part-time resource, you should investigate bringing that person on full-time until the task is complete.

If nothing can be done about the activity creating the potential delay, your analysis will need to encompass the rest of the project work. You may implement fast tracking by having some tasks worked in parallel or crashing by bringing on additional resources to complete the remaining work in less time. If you choose to implement either of these techniques, be sure to document the risks associated with this course of action.

Lessons Learned Major changes to the project schedule should be analyzed to determine what caused the deviation from the plan so that steps can be taken to prevent the situation from happening again. These lessons may apply either to the remaining work on your project or to future projects. If all of the tasks assigned to a particular resource or group require more time than planned, you may want to have the people involved revise estimates for any future tasks or have the remaining estimates reviewed by a third party with experience completing similar tasks.

Changes to your scope or schedule may involve extra costs that need to be managed.

Cost Control

Another key project result is the tracking of project spending. Formal reports from the finance systems, project team member time reporting, and requests for purchase approval all provide a picture of how the project spending is tracking with the budget. The budget impacts from scope changes also need to be analyzed. The cost control process includes being aware of the project spending to date, determining that a change to the cost baseline has occurred, and taking appropriate action to deal with the change.

Project management software is also useful in tracking project spending, if cost figures have been loaded. You can run reports that show spending to date and projected spending. You can also look at the impact of adding new tasks using what-if scenarios.

Any major change to the project plan that will impact cost should include securing additional funding as part of the approval process. Adding requirements to the project and starting work on new tasks prior to securing funding is a sure way to overrun your budget.

Cost control results include revised cost estimates, corrective action, and lessons learned.

Revised Cost Estimates As actual costs are incurred and tracked, you are able to project how the actual costs for a particular project phase or even the entire project will differ from the original estimates. As with any deviation from the project plan, you should review the revised cost estimate to determine any impacts to other aspects of the project plan. An increase in overtime hours, for example, may be an early warning that a task is taking longer than planned. Frequently, revised cost estimates are the result of changes originating in other parts of the project plan, such as a scope change or schedule change.

Just as with schedule updates, there can be revisions to the cost baseline, typically in response to a scope change, or there can be rebaselining if the cost variances are so extreme as to make a change necessary in order to track performance.

Corrective Action General cost overruns that are not tied to a change in another part of the project plan such as a scope change or a schedule delay may not require any further action if they are below some predefined level. Many organizations consider projects on track if the actual spending is plus or minus a predefined percentage of the overall project budget. If you have a 10 percent leeway on a project budgeted at $1,000,000, an extra $50,000 spent will be acceptable; an extra $200,000 would require the approval for additional funding.

If the problem rests with the accuracy of the initial cost estimates and there are no additional funds available, you may need to discuss trade-offs with your stakeholders, such as reducing the scope or lowering the quality. We discuss trade-offs in more detail later in this chapter.

Lessons Learned Major deviations from the cost baseline need to be analyzed to determine what caused the difference so that steps can be taken to prevent the situation from happening again. These lessons may apply to either the remaining work on your project or to future projects. If a number of work effort estimates from the same resource or group are not being met, you may want to have revised work effort estimates for any remaining tasks.

Now lets look at controlling change for some other aspects of the project plan.

Other Plan Changes

Scope, schedule, and budget are the items that are most frequently mentioned targets of change control, but these are not the only components of the project plan that may change. Lets take a brief look at four other elements: resource changes, requirements changes, infrastructure changes, and configuration changes.

Resource Changes Whenever a project team member is added or leaves , it is important to document the reason for the change, the name of the replacement (if any), the person requesting the change, and any impact the change will have on the project.

Requirements Changes This can be a tricky area to manage. As detail is added to a requirement or it is updated to clarify expectations, you need be taking a look at these changes to make sure they do not involve a scope change. Any new requirement should always go through the change control process.

Infrastructure Changes Infrastructure is the elements of a project that will remain permanently after the project is completed. As an example, a team member may have planned for a Sun server running UNIX for your database, but as the project moves forward, the network team requests that you change this operating environment to Windows 2003 Enterprise Server. Infrastructure components that may change include:

Computing systems
Software development environments
Server operating system platforms
Networking infrastructures
Delivery methodologies

Infrastructure changes can have a major impact on your overall project plan, particularly if your project includes equipment orders that were based on different infrastructure assumptions.

Configuration Changes Frequently, the design team will make a decision about a software or hardware configuration only to find out as the software is installed that another configuration would work better for the requirements or that the suggested configuration wont work with another system in an integrated system environment. One of the more frequent examples of a configuration change is when the database design team determines that a given set of indexes is required for the database being designed. But then, as the programmers begin to write code that runs against the database, they may decide that another type of index would be useful and effective as well. So a configuration change is required to add the new proposed index.

Configuration changes can be very simple or quite complexit just depends on the nature of the configuration and what is expected of the software or hardware. However, generally speaking most configuration changes dont require a lot of time and can be accomplished within a couple of hours, so theyre really not project showstoppers. Keep in mind that some configuration changes will require a reboot of the equipment and thus may not be able to be put into effect until after hours.

As your project moves forward and major deliverables are produced, you will start implementing your quality management plan.

Quality Control

Although quality is one of the common constraints all projects share, it is an area that does not always receive the same amount of focus as the scope, budget, or schedule. However, lack of quality management can have severe negative impact on the project. Quality control is the process of reviewing project results to confirm compliance with defined standards and making appropriate changes to remove causes of unacceptable quality. The quality management plan discussed in Chapter 6 is the foundation for the specific activities carried out during quality control. The quality activities, the procedures used to complete the quality activities, and the resources required are documented in the quality management plan.

Quality control is done throughout the project. As we have mentioned in earlier chapters, milestones are often included in a project schedule to mark the completion of a project phase or major deliverable . Quality tools and techniques are used to determine compliance with a minimum sufficiency standard, and quality activities are often a key part of the formal process of approving the completion of a phase.

We will focus on the use of testing to monitor the project work results, as well as mention some other tools and techniques that are used in quality control. The results of your quality control activities may result in rework , process changes, or acceptance of any defects that are found.

Inspection (Testing)

Inspection is a broad category that includes examining, measuring, or testing work results. The most common use of inspection on IT projects is testing.

Testing is something you should always try to devote extra time to. Testing is a boring job ” someone has to run the code over and over again, testing different things in different modules, taking notes about its performance. But it s got to be done. You should have at your disposal testers who are ready and willing to thoroughly run your new code through its paces.

Testing is done throughout the project, and several kinds of testing are common on IT projects:

Module Testing A programmer completes a module of code and needs to test it. Some modules don t lend themselves to module testing, because they re designed to interface with other modules. Still, the programmer can check that variables load correctly, that the code goes to the places it s supposed to go to depending on the input, and that memory gets cleaned up and the program exits correctly. Often developers can run code through a checker that steps the code line by line to see how it behaves and how it loads memory variables . The process can be at once very interesting and yet extremely frustrating, because the developer has something going wrong but can t figure out where ”all of the code appears to be doing what he or she wants it to do.

At this stage of the game, dynamic link libraries (DLLs) and other informational files are also tested for complete and accurate content.

Unit Testing Once several modules that go together have been satisfactorily tested, the developer can test them all at once in unit testing. They might test an entire printing system or a set of algorithms that calculates something. They re testing the functionality of pieces that have been put together to form a cohesive group .

System Testing Next, the developers test the entire system as a whole. They make sure the system flows as expected, that the user doesn t encounter unexpected loops or gotchas (such as deer in the headlights frozen screens), that the system is fast and functional, and that it delivers what the customer is expecting. System testing should take a long time, because they thoroughly test each component and the whole.

User Acceptance Testing (UAT) This is the time when they actually bring in a small set of users to begin testing the deliverable. By the time developers get to UAT, they should ve worked out all bugs , speed or logic issues, and flow problems. The system should be at its best, most pristine state. This is the system they currently expect the user to utilize in production ”until the UAT testers find the problems others missed.

Factory Acceptance Testing (FAT) Sometimes a system is so large it s better if testing by the users is done on site at the place where the initial development was done. Think of the development of a new radar system for weather forecasting in which there is new gear being developed plus new software. All of this is done at the vendor s site in preparation for delivery to the new location once the customer has accepted the new system. FAT is part and parcel of big government contractors such as Raytheon and other companies that specialize in big development work.

Site Acceptance Testing Site acceptance testing involves customer testing at the customer premises. Consider the radar system example above. A radar specialty contractor has developed the new radar system and all of its elements. The customer has come out to the factory for FAT and finds the system acceptable. Now the company delivers the new system to the customer and they go through another round of testing to make sure that all things are operational and that the system operates as expected.

Testing is always an important step in confirming the quality of an IT project, and in a couple of scenarios you may need to conduct even more testing.

Geographically Dispersed Team Project teams are often dispersed across multiple locations. A major software deliverable may be the result of code compiled from modules written by several programming teams. Even though you have established communications and work standards for the teams , the lack of daily face-to-face contact can increase the risk of misinterpretations, which could lead to differences in the modules that may impact the compiled package. In this situation, you may want to have more detailed testing on the individual modules to catch problems early on.

Vendor Deliverables Another scenario where testing takes on significant importance is when a vendor produces deliverables. The specifics of how and when you can test during the development process should be included in the contract. Integration testing of the vendor deliverable with the rest of the system is commonly a requirement for final acceptance of the vendor work. Acceptance of a vendor deliverable equates to vendor payment, so these tests need to cover all requirements associated with the work the vendor was contracted to produce.

Although testing is the most frequently used for quality control in IT projects, it is not the only method available.

Other Quality Control Tools and Techniques

Anyone who has been on an IT project is probably familiar to some degree with the amount of testing that is conducted over the course of a project. Other tools and techniques can be used in combination with testing to address quality defects.

Pareto Diagram A Pareto diagram is used to rank the importance of a problem based on its frequency of occurrence over time. This diagram is based on the Pareto principle, which is more commonly referred to as the 80/20 rule. The Pareto principle is named after Vilfredo Pareto, an Italian sociologist and economist , who observed that 80 percent of the wealth in Italy was held by 20 percent of the population. This principle has been applied to many disciplines since Pareto first discovered it. Applying the principle to quality control, it says that the majority of the project defects are caused by a small set of problems. A Pareto diagram helps to isolate what the major problems are, so that you can take action that will have the greatest impact. A bar graph is used to display problems in decreasing order of occurrence so that priorities for improvement can be established.

The purpose of a Pareto diagram is twofold:

It displays the relative importance of the defects.
It directs the improvement efforts to those areas that will have the biggest impact.

Let s take a look at how this works. A Pareto diagram typically starts with a table that lists information regarding the frequency of the defects or failures uncovered during testing. Table 9.1 shows the following frequency of failure for items A “E: the number of occurrences, the percent of defects that this item represents, and a cumulative percent.

Table 9.1: Frequency of Failures
Item	Defect Frequency	Percent of Defects	Cumulative Percent
A	800	.33	.33
B	700	.29	.62
C	400	.17	.79
D	300	.13	.92
E	200	.08	1.0

With this data in hand, you can create a Pareto diagram, as shown in Figure 9.1 The bars are ordered from left to right based on the frequency. The bars depict the defect numbers , and the cumulative percentages are plotted using the circles. By looking at the data in Figure 9.1, you can see that the most significant problems you want to focus on are A and B. Fixing these two items will resolve over half of the defects.

click to expand
Figure 9.1: Pareto diagram

Control Charts A control chart is a picture of the variance of several samples of the same process over time. It is most commonly used in manufacturing. A control chart is based on a mean, an upper control limit, and a lower control limit. The upper control limit is the point beyond which preventing additional defects becomes cost prohibitive. The lower level is the limit at which the client or end user will reject the product because of the defects. The goal is to stay in the middle area (the mean), where the best product for the lowest cost is obtained. An example of a control chart is shown in Figure 9.2.

click to expand
Figure 9.2: Control chart

Statistical Sampling If you have numerous work results that require inspection or testing, you may decide to use statistical sampling, which gathers a subset of all the applicable work results and randomly selects a small number for testing or examination. Statistical sampling can be very cost effective, especially in projects where multiple versions of the same product are produced.

Flowcharting Flowcharting was discussed in the quality planning section of Chapter 6 as a means to create the process that produces the product. Flowcharting can also be an effective tool during quality control to help determine the how the problem occurred.

Trend Analysis Trend analysis is a mathematical technique that can be used to predict future defects based on historical results. We will discuss trend analysis in more detail later in this chapter.

The results you obtain from testing or other quality control tools and techniques are used to determine whether any action should be taken to correct poor quality.

Quality Control Actions

As you implement your quality control activities, you need to make decisions on the appropriate course of action based on the results received. Any action taken to resolve quality problems has trade-offs, so you will need to involve other stakeholders in the decision process. The most common actions taken as a result of quality activities are rework, process adjustments, and acceptance.

Rework

Rework is any action that is taken as a result of quality activities to correct a defect. A module test may result in the rewrite of a section of code from the module tested.

Rework sounds like the ideal solution to any quality problem that is found. If you discover a problem, you should fix it ”right? In an ideal world with no time and budget constraints that would be true, but rework often impacts both the project schedule and the budget. The time to complete the deliverable will be longer than estimated to account for the time it takes to fix the problem, and the people doing the rework will be billing additional hours to your project.

Note	There may be exceptions to the increase in billable hours, if you are working with a vendor and have quality standards written into the contract. However, you should always consider the possible financial impacts.

A decision on rework is often tied to the severity of the defect and its impact on the ability of the end user to use the product. Your client, sponsor, and other impacted stakeholders need to be involved in rework decisions.

Process Adjustments

Changing a process can ripple throughout the rest of the project. Unless it is very clear that a process change is contained to a small work group or a few team members with no downstream effects, it is best to use the change control process to analyze the impacts of a process change and obtain formal approval before making any changes.

Acceptance

Acceptance is the decision to accept any defects that are found as a result of the quality testing. Acceptance is a common action based on analysis of the severity and frequency of the defects uncovered during testing. For example, some commercially available software products are released for sale to the public with known defects to be fixed with an upgrade later. Meeting the publicized release date for the product is more important than fixing defects; in other words, the schedule takes priority over quality. The overall impact of accepting a defect should be analyzed and communicated to project stakeholders. You need to get stakeholder sign-off to accept defects.

Another important aspect of quality control is the documentation quality.

Documentation Quality

IT projects often produce documentation, both technical and nontechnical. Your quality control activities include ensuring the quality of all project- related documentation and other material turned over to groups who use or manage your deliverable. This includes user documentation, user training, help-desk training, and documentation for other support groups.

User Documentation

Any documentation ”whether online or paper copy ”that the user requires in order to use the system should be proofread for spelling, grammar, and content. All instructions regarding the use of the system should be tested to confirm accuracy. Paper copies should be prepared and bound for distribution to the users. Help-screen documentation should be complete and thorough. There is nothing more annoying than hitting F1 for help only to find No help is available for this topic or extremely minimal information.

User Training

User training may be instructor led, a self-paced workbook, or online. Regardless of the delivery medium, the curricula should be checked for content and completeness. A pilot class may be held to confirm that the training is thorough and understandable and that any online practice features of a training database work correctly. The trainers who will provide or support the training should be educated on the new system and ready to go, and any training documentation should be printed and bound, ready for class. Training materials such as demonstrations and visuals should be ready. The scheduling of training classes should be part of the project schedule to ensure that users will be ready for the deployment.

Help-Desk Training

IT project managers are often good about considering end-user training and getting classes ready for users, but they may overlook the person in the trenches, the help-desk technician, who will wind up getting calls from users about how the new system works. Take into consideration where the help desk is going to fit in terms of supporting the new system, and prepare help-desk technicians in advance with the training they will need to support users. Help-desk training should include all of the aspects of end-user training as well as the more detailed aspects of resolving problems and troubleshooting. All of the proofreading and testing discussed in reference to user training quality also applies to help-desk training. Especially during the early phases of new system release, users are going to have questions about how the system works and may turn to the help desk for answers. The help desk needs to be ready to go at deployment time.

IT Quality Control

Quality control in the IT world begins by following a twofold path :

Sticking to well-known, widely established standards for the work that you do
Setting up your initial environment in such a way that you are guaranteed success

Neither of these items are easy to quickly establish ”they take buy in at all levels and a dedication to the process. Let s talk about each one separately so you can get a feel for what s involved.

Standards

When IT shops sit down as a group and hammer out standards, the result is almost always a more consistent way of doing business. Consider, for example, the following applications development standards:

All new applications will be developed so that they run from a browser utilizing XML.
All applications will utilize server-side Web services such as J2EE, not localized services.
All applications will use Simple Object Access Protocol (SOAP) as the transport method from the application to the client.

These standards certainly aren t inclusive and may not be the standards that a given IT shop would set, but you can see that they are fundamental, simple to understand, and use commonly held protocols as the binding glue. By setting these standards, you have a firm way of controlling new applications enterprise-wide. If someone s entertaining the notion of bringing in a COTS software product, you can insist that the vendor(s) being considered are required to adhere to the standards.

In setting up a PMO that s going to handle IT projects, it s wise to get all the IT stakeholders in a room and see if you can generate a list of common standards that all groups will adhere to. These standards can include:

Server burn documents ”that is, how servers will be built
Workstation installation standards ”that is, the OS and office automation suite versions, patches and service packs , browser settings, control panel settings, profiles, etc.
Application development standards
Network operation standards, including acceptable network protocols

Standards Organizations

Standards organizations develop standards for almost everything you can imagine (from software protocols to street signs to wine glasses ). One organization is called the International Organization for Standardization (ISO ”see www.iso.org). Specifically, ISO 9000 can be (and is) utilized by corporations for the management of their quality control. While ISO 9000 is a large thing, perhaps you can glean standards information by visiting the site and determining how ISO derives the standards and what standards are available.

Another is the Distributed Management Task Force (DMTF ”see www.dmtf.org). This organization acts to bring about ways to manage systems by a standardized interface. Microsoft introduced this standard into its Windows product through the Web-Based Enterprise Management (WBEM) standard, which utilizes a management interface and database on each Windows 2x computer and higher. WBEM is utilized by Microsoft Systems Management Server (SMS) for the purpose of gathering inventory information from PCs and uploading the data to a central database for the purpose of maintaining a centralized system inventory.

Another is the Institute of Electronic and Electric Engineers (IEEE ”see www.ieee.org), an organization instrumental in producing widely adapted networking protocols. The wireless networking protocol suite 802.11 is an IEEE standard that has evolved out of hours of work by committee experts.

Another useful and interesting standards organization centers its philosophy on the best way to manage operations environment (servers, network infrastructure, mainframe, etc.) This organization, the Information Technology Infrastructure Library (ITIL ”see www.ogc.gov.uk/index.asp?id=2261) has standards that will assist you in formulating great operational methodologies. ITIL is the entity responsible for saying that one must understand a business process flow before applying technology.

Another standards body is the American National Standards Institute (ANSI ” see www.ansi.org). Interestingly, the PMI s A Guide to the PMBOK is an ANSI standard.

As you can see from these organizations, thought and effort has been put into developing standards whereby computing systems can play in the sandbox with one another. So, at the very least, it s to your benefit to understand those standards and to insist that they re used throughout the organization as best practices.

Setting Up Your Environmental Processes

There are many good ways to get started in organizing a PMO that continuously puts out highquality projects. Perhaps the first place to start is to assess your organization to see just how healthy it actually is in terms of its ability to actually generate good-quality projects. A Capability Maturity Model (CMM) analysis might be in order. CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) ”see www.sei.cmu.edu/cmmi/adoption/cmmi-start.html for more information on the various CMM implementations to date.

The idea behind any CMM is that five operational levels describe any given organization s project development efforts: Initial, Repeatable, Defined, Managed, and Optimizing.

Initial Processes are ad hoc and occasionally even chaotic . Does this describe your organization? It sure does some of the ones we ve worked for! When a project is required, it just sort of gets thrown together. There s not really any commonsense pragmatism put toward the effort. This level is the lowest level of CMM. Organizations at this stage are CMM 1.

Repeatable At this level of CMM, an organization has established basic project management processes that serve to define the costs, schedules, and projected outcomes of any given project. At CMM 2, an organization is not considered to be project-mature, but has definitely taken strides toward cleaning up its processes.

Defined At CMM 3, processes have been defined, published, standardized, and put into operation by some sort of project overseer entity ”typically a PMO. All projects utilize standard documentation, project requests , approvals , and so forth to implement the deliverables. Organizations at CMM 3 are starting to get their stuff together, but they ve got a way to go before they re fully functional.

Managed CMM 4 organizations qualitatively control the output of their projects. Any project is subject to strict quantitative scrutiny (in large organizations and projects this happens through Six Sigma techniques) to assess the quality of the outputs. Controls are tight, operations are well understood , and projects are cranked out in a uniform way with consistent quality. Understand that the operative word with CMM 4 is quantitative . At this level, we re applying quantitative measures and analysis to assure that our quality output is high.

Optimizing Like Abraham Maslow s top rung (self-actualizing) of his famous hierarchy of needs, an organization at CMM 5 is not only generating projects of consistent high quality and that are expertly monitored and managed, they re also constantly looking for ways to improve processes.

Note

You may not work for a manufacturing entity or other concern that has a vested interest in quantitatively managing quality, but if you re good with math, especially statistics, you may find a large measure of success in your employment efforts by getting a Six Sigma belt. Six Sigma ( www.isixsigma.com) is a program that teaches people how to monitor quality outputs through statistical analysis. The program uses the various colors of martial arts belts to denote how far you ve gone in the program. There are Six Sigma green, brown, and black belts ”the top, of course, being a black belt. Companies like General Electric (GE), Boeing, and others use Six Sigma types to assist in the management of their quality output.

The key to any IT undertaking lies in the ability of the IT organization to smartly implement project management methodologies and to undertake projects with consistency of action. By first understanding where your organization is at relative to its ability and aligning your efforts with good-quality, well-known standards, you have a very high chance of success.

Tip	Remember that it is key that we always understand a business unit s process or flows before we apply technology. If you re careful to keep that order straight, all else should fall into place.

Risk Monitoring and Control

Part of project planning was the identification of potential risks to the project and the development of a risk response plan. Risk monitoring and control is the process of implementing the risk response plan. This process includes not only tracking the risks identified during planning, but evaluating the effectiveness of the actions you identified. Have the steps you identified to prevent the risk or mitigate the impact been implemented? Is the result what was expected? For those risks you could not control, you must track the status of the risk to determine whether to implement the contingency plan that was developed to deal with the risk.

Risk monitoring and control also includes identifying any new risks throughout the life of the project. Regardless of the level of detail in your original risk identification, as the project progresses conditions change, the business changes, and other components of the project plan change, all of which can produce new risks that must be dealt with.

Closely linked to risk control is the control of project issues. You must monitor and update the progress of current issues, evaluate the progress of resolution, and identify new issues.

Let s start with the risk response plan results.

Monitoring Risk Response Results

During risk planning, you identified risks to the project and prioritized those risks based on the probability of occurrence and the impact to the project if the risk occurred. The risk response plan includes a planned response for each of your high priority risks ”action that will either avoid the risk or lessen its impact or a contingency plan to deal with the results of the risk.

Preventative Action Risks that can be avoided or mitigated should have specific actions associated with preventing the risk, often involving the addition of new tasks to the schedule.

In these cases, you should be tracking the implementation of the planned action and evaluating the impact of the action(s) on removing or mitigating the risk. If the action is not mitigating the risk, you will need to review the risk response and either choose to accept the risk or develop a new response.

When you review an action that is not having the desired result, you need to determine if other factors involved have changed the nature of the risk. If what you really have is a different risk, it may require a completely different approach.

Real World Scenario ”Keeping Your Eye on the Trigger

One of us was on a project a few years ago that involved extensive user training in multiple locations as part of the deployment of a new user interface. The training had to take place before the new application was deployed at each location, which drove the development of a very complex dependency between the training and deployment schedules.

Just when we thought we had this schedule planned out to perfection , we were advised that the end users were represented by a labor union in the midst of negotiating a new contract. Talks were not going well, and a labor strike could start in the middle of our deployment. No one associated with the project could do anything to impact the outcome of the labor negotiations, so we had to develop a contingency plan.

We discussed several options, one being to tighten up the deployment schedule to complete all locations prior to the end of the current contract. That plan would have required additional resources to both train the end users and deploy the system, which we did not have. We opted to keep the existing training plan and develop an alternate plan for those offices that would not be trained before the strike date. The contingency plan called for the training to start 2 weeks after the end of the strike and to keep the same sequence and time between training as existed in the current schedule. All deployments scheduled prior to the strike date would continue as planned. No training or deployments would be canceled until after a strike was declared.

The client approved this plan, a team member was assigned to monitor the progress of negotiations, and we established two triggers. The first was a vote by the union members to authorize a strike. When this occurred, a conference call was established with the managers of all offices impacted by the contingency plan. We reviewed the plan and made sure everyone understood the formula for calculating the new training date. It was agreed that a project team member would contact each office manager to confirm the training dates if we had to implement the contingency plan.

Our second trigger was the official start of the strike, which came at 12:01 A.M. on a Sunday morning. When the strike was declared, a message was sent to all training and deployment managers to cancel travel plans for that coming week.

Although the work stoppage delayed the overall deployment schedule by 6 weeks, the contingency was implemented smoothly and the remaining offices were deployed in an orderly fashion with no disruption to customer service.

The key to a successfully implementing a contingency plan is identifying your triggers and good communication.

Contingency Action The other type of action that you identified in your risk response plan was a contingency action to deal with a risk you could not avoid or mitigate. This requires a different approach to risk monitoring. A contingency plan is implemented only if a risk actually occurs, so you need to be monitoring for a risk trigger , which is an event that tells you that the risk is imminent.

As the project moves forward, you need to be alert to any signals that either the risk or the trigger is changing. The key to a successful contingency plan is knowledge that the risk is forthcoming.

Identifying New Risks

The risk response plan evolves throughout the project life cycle. Some risks identified during planning may not materialize, and new risks may arise that were not previously included in the response plan. As the project work completes, you need to be aware of any new unplanned risks.

Warning

Any change to the project scope has a potential to add risk to the project, because it changes or adds to the major deliverables of a project. Because the new activities associated with the scope change frequently lengthen the project schedule, they may be on the critical path as well. A scope change should always include a risk analysis and review of the risk response plan.

New risks may also impact the risk priority listing. A new risk may have a greater probability and a more severe impact than previously identified risks. Changes to the project plan may also change the relative ranking of existing risks. For example, as actual work progress is reported , the schedule critical path may change, impacting the urgency of dealing with risks that were previously a low priority.

As you modify a response to an existing risk or identify a new risk, the action proposed to deal with the risk may itself result in a change to the project plan. The response may involve a change to the project scope, a change to the schedule, or money. In this case, your risk response should go through the appropriate change control procedures, like any other change.

Your issues log is another important document that requires ongoing monitoring and updates.

Monitoring Issue Resolution

Monitoring the progress of issues resolution is very similar to monitoring risk; you need to make sure appropriate action is taken to close the issue. An issues log that is not carefully managed can turn into an unwieldy monster, with new issues added weekly, and nothing getting resolved.

As you review your issues log in a project team meeting, you want to be sure the person who has been assigned to resolve the issue is working toward closure. Sometimes project issues will remain open for weeks or even months, especially if you consider we are still working on this one an acceptable progress report. The status you request should always include both a plan for resolution and a target date to resolve the issue. If no progress is made, perhaps the responsible party needs assistance or does not really understand the issue. It may require escalation to the sponsor to overcome roadblocks .

Although the goal is to assign all issues and resolve them as quickly as possible, in some instances you need to prioritize issues and have them worked in sequence. You can use some of the tools from risk planning to complete this prioritization. If multiple issues require the same team member or group , review the impact of each issue on the outcome of the project and establish a priority list.

A Project in Jeopardy

What starts out as a risk or issue to be resolved by project team member action can sometimes escalate into a situation that can jeopardize project completion. If the actions you have taken are not having the desired impact or if you are identifying new risks that you cannot control, it is time to get with the project sponsor to determine the appropriate course of action.

Escalation to the project sponsor is a delicate balancing act. You do not want to get the reputation that you panic every time something goes off course or that you cannot handle tough decisions. On the other hand, if you have done everything you can, do not delay involving the sponsor on the faint hope that things will change. If you do not raise a red flag until the project is in serious trouble, it may be too late for the sponsor to do anything.

When you come to the project sponsor, be prepared to communicate clearly the issue or risk, the actions you have taken so far, and the impact to the project if nothing changes. Your briefing with the sponsor should be at a high level; he or she does not need to know every step taken along the way.

You should request specific action from the sponsor. You will not come off well if you go into your sponsor wringing your hands and saying you don t know what to do. If you are having issues with another department that requires a decision at the executive level, let the sponsor know who is involved and what you need done to get the project on track.

Sometimes nothing can be done to change the situation. Perhaps a new regulation has invalidated key project assumptions or new corporate leadership has implemented a strategy that nullifies the justification for your project. If this is the case, your request to the sponsor may be a recommendation that the project be canceled.

Project control results need to be reported to the stakeholders, and in some cases stakeholder decisions must be made regarding the future of the project.

Performance Reporting

Control activities uncover important information about your project that you need to communicate to stakeholders. Performance reporting provides progress and forecast information on the project scope, schedule, cost, and quality. Risks or issues that that are jeopardizing the success of the project also need to be reported to the stakeholders.

Performance results should be distributed based on your communications plan for each stakeholder group . Performance reporting includes information on what has been accomplished to date and is typically stated in terms of what has been completed and what remains to be done.

A number of analytical tools can assist you in obtaining meaningful data to communicate project progress.

In addition to communicating project results and forecasts, performance reports often require action on the part of the stakeholder team.

Performance Reporting Tools and Techniques

A meaningful performance report needs to contain more specific information than simply stating whether the project is on schedule, over budget, or out of scope. Deviations have a wide range of impacts on the overall success of the project. As part of your performance report, you need to include an analysis of the problems to quantify the impact to the project.

Techniques that can be used to clarify the impacts of deviations from the plan include variance analysis, trend analysis, estimate at completion, and earned value.

Variance Analysis

Variance analysis is the comparison of planned project results with actual project results. Variance analysis is most frequently used on the project schedule and project budget.

Most project management software tools include a tracking feature that allows you to display the baseline schedule compared to the actual schedule. You can see which tasks took longer than predicted , as well as any impacts to project milestones. You can create views that show results down to the task level, or you can do a summary view that shows the overall results for a particular phase. This tracking feature also recalculates project end data based on any delays.

Project budget reports can be compared to the cost baseline to show how much has been spent compared to what was budgeted for the same period of time. These reports can also include a comparison of the hours expended on tasks by individual resources to the work effort estimate that was part of the cost baseline.

Percentages can be used to quantify variance. You may have seen performance reports stating that a major deliverable is 75 percent complete or a statement indicating that the project schedule is 50 percent complete and 35 percent of the budget has been spent.

Warning

Exercise caution when using percent complete or percent of total budget. These numbers may be misinterpreted if they are used out of context. The budget needs to be looked at in terms of the work completed and the work remaining. Being on schedule and over budget is not a good thing, but being behind schedule and over budget should send up a big red flag.

Trend Analysis

Past performance may give you a clearer picture of what to expect from future performance. Trend analysis is based on mathematical calculations used to show whether performance is improving or declining over time.

These historical trends are used to forecast future project performance. Various formulas are used to calculate trends and predict future results. It is outside the scope of this book to go into this subject in detail.

Estimate at Completion

As your project progresses and you obtain your official budget reports, you will be asked to predict the total cost of the budget. An estimate at completion (EAC) is a forecast of the total cost of the project based on both current project performance and the remaining work. To understand how EAC works, you need to know a couple of other terms:

Actual cost (AC) is the total amount spent on the project to date or through the end of a particular phase.
Budget at completion (BAC) is the total amount of the project budget.
Estimate to complete (ETC) is the cost estimate for the remaining project work.

EAC = AC + ETC A comparison of your EAC figure to your BAC figure provides you with a current estimate of any deviation from the original budget.

Note

There are two other methods for calculating EAC. One uses actual spending to date plus remaining budget. The other method uses actual spending to date plus the remaining budget modified by a performance factor. It is beyond the scope of this book to go into detail on these methods . Further information can be found in A Guide to the PMBOK .

Earned Value

In your future, more advanced PM studies, you ll encounter some financial management variables that you may want to pay attention to ” especially if your project is one that s massive and requires that you pay special attention to all the financial details.

Note	Although Objective 3.10 only lists the three terms associated with estimate at completion, the intent of this section is to provide a broader explanation of financial management variables.

There are several variables, each of which could be easily calculated through spreadsheet or project management software calculations. We need to take some time to build some of the numbers that you ll use to calculate these variables, so we ll start with some basic definitions, then move into how they combine with each other in real use.

A Guide to the PMBOK has changed some of the earned value management terms. Both sets of terms are still in use, which can cause confusion if you do not realize that two terms are interchangeable. Table 9.2 lists both the current term and the term it replaces .

Table 9.2: Earned Value Terms
Current Term	Also Known As
Actual Cost (AC)	Actual Cost of Work Performed (ACWP)
Earned Value (EV)	Budgeted Cost of Work Performed (BCWP)
Planned Value (PV)	Budgeted Cost of Work Scheduled (BCWS)

When you perform analysis on your project using the following formulas and variables, you re performing earned value analysis . When you perform assessment on a project s earned value , you re measuring how much of the budget you predict that you should have spent so far, given the amount of work already done on the task. You re calculating the budgeted cost of work performed (BCWP). (The terms earned value and BCWP can be used synonymously.) It s important to also understand that your pristine project starting point ”nobody working on any tasks yet, no money spent ”represents the baseline of the project. It s important to fully describe your project s beginning prior to calculating any financial management variables. Project management software allows you to save your work with a baseline before you start entering hours or materials costs.

Earned Value Basics

Start with a status date ”simply, the date when you re going to take a measurement of how much has been spent on a specific task.

Next, you must understand several different ways of looking at a task s cost. The first way is the planned value (PV), also referred to as budgeted cost of work scheduled (BCWS). Generally, you apportion out a task s total cost evenly over the number of days that the task is scheduled to take. If a task is predicted to take 5 days and cost $100, for example, each day represents $20 of a task. You arrive at the BCWS by comparing the amount that s budgeted to be spent on a task between its start date and the status date (not necessarily the same as the end date). For example, if you have a 5-day task that s going to cost $250, then you can break the per-day cost out to $50 a day. If you set your status date to Thursday, for example, you ve used 4 days of the 5 and your BCWS is $200. Figure 9.3 illustrates this concept.

click to expand
Figure 9.3: Budgeted cost of work scheduled (BCWS) or planned value at status date

Another component of earned value is the actual cost of work performed (ACWP). This is the actual cost incurred for each day that you worked on a project within a given period. In our example in Figure 9.3, the project has a budgeted cost per day of $50, for a total of $250 for the task. But what if you spent only $45 on Monday, $30 on Tuesday, $45 on Wednesday, and $35 on Thursday? Then your ACWP for the 4 days would be $155, even though your BCWS is still $200. Figure 9.4 shows this relationship.

click to expand
Figure 9.4: Actual cost of work performed or actual cost

Finally, you have another straightforward calculation you can make: budgeted cost of work performed (BCWP, as mentioned earlier). This figure represents the comparison of the percentage of work performed to the expected, budgeted amount. If by Wednesday you ve met 75 percent of the task s budgeted work (even though you ve got until Friday), then the work you ve done was budgeted to cost $187.50 even though you ve only really spent $120. You re comparing the amount you ve actually spent to the amount you d expect to have spent based on the percentage of work completed thus far. Figure 9.5 demonstrates this calculation.

click to expand
Figure 9.5: Budgeted cost of work performed or earned value

Now that we know the differences in these earned value components , we can go forward and calculate some basic financial management variables. The BCWS, ACWP, and BCWP figures you have go into the remaining calculations.

The BAC and EAC acronyms that were described earlier in this chapter will also play into an index described later.

All these calculations deal with comparing the current status to the budget in some way. One group simply subtracts, producing a variance that is the difference between actual and budgeted; the second group, the indexes , divide to show you the ratios relative to those measurements. All these numbers might be useful to calculate, although in smaller IT projects not all of them will be necessary.

Variances

Variances show the difference between that which was budgeted and the actual costs expended. A positive variance shows that you ve saved money or time and might be able to reapportion the savings elsewhere in the project. A negative variance states that you re either over budget or behind schedule for a given task ”requiring that you take action.

Cost Variance The cost variance (CV) simply represents the difference between a task s estimated (budgeted) cost and its actual cost. The formula is CV = BCWP “ ACWP.

Schedule Variance The schedule variance (SV) simply represents the difference between a task s progress as compared to its estimated progress and is represented in terms of cost. The formula is SV = BCWP “ BCWS.

Indexes (Ratios)

Indexes are designed to show a ratio between one project budgetary component and another. The most common of these numbers are extremely useful, because they are simple to gauge: either greater than 1 or less than 1. If a ratio s value is greater than 1, the task is either ahead of schedule or under budget. A ratio less than 1 indicates that your task is behind schedule or over budget.

Note that ratios can also be expressed as percentages, which may be an easier way to think of the numbers. For example, if one of these indexes calculates to 0.971, you can multiply by 100 to state that index as 97.1 percent.

When you commit these formulas to memory and understand what they re representing, you can use earned value analysis to get a much better handle on where you re at with a given project. You can answer questions such as Is there enough money in the budget so that I can finish the project? or Do I have enough time left to finish the project on time? Again, you would use these calculations with very complex projects and probably wouldn t need them with simpler ones.

COST PERFORMANCE INDEX

The cost performance index (CPI) shows the ratio between a task s budgeted and actual costs. The formula is CPI = BCWP/ACWP.

A CPI of less than 1.0 means you re over budget; a value over 1.0 means you re spending less than you expected.

SCHEDULE PERFORMANCE INDEX

The schedule performance index (SPI) is a ratio of the work performed on a task versus the work scheduled. The formula is SPI = BCWP/BCWS.

An SPI of less than 1.0 means you re behind schedule; a value over 1.0 means you re taking less time than you expected.

TO-COMPLETE PERFORMANCE INDEX

The to-complete performance index (TCPI) is a ratio of remaining work compared to remaining budget and is represented as a percentage. It can be viewed as an efficiency formula where the higher the percentage, the more efficiency you re currently getting out of the task. A TCPI that is more than 20 percent higher or lower than the CPI means that the current EAC is not representative of past performance. Here is the TCPI formula:

TCPI = work remaining / funds remaining

where: work remaining = BAC “ BCWP

funds remaining = BAC “ ACWP

For example, given the following project numbers, here s how you d calculate the TCPI:

BAC = 250,000

BCWP = 175,000

ACWP = 180,000

CPI = (175,000 / 180,000)

= 0.972 (or, as a percentage, 97.2%)

TCPI = (250,000 “ 175,000) / (250,000 “ 180,000)

= 75,000 / 70,000

= 1.071 (or, rendered as a percentage: 107.1%)

To compare TCPI to CPI, divide one into the other. If the result is between 1.2 and 0.8, then you re within the +/- 20% guideline:

TCPI / CPI = efficiency compared to past performance

1.071 / 0.972 = 1.102

In this case, a comparison of 1.1 means we re essentially on track in our project relative to past performance (provided, of course, that past performance was in line with our expectations).

The results of all this analysis may require decisions by the stakeholders on how (or if) the project will move forward.

Driving Stakeholder Action

During the project control phase many hard decisions regarding the future of the project are made. The project manager is responsible for communicating not only the nature of deviations from the project plan, but also the impact of these deviations and recommendations for moving forward. Trade-offs may be required in order to complete the project. In some cases, the project may no longer be viable and the stakeholders may be asked to officially cancel the project.

Communicating Performance Deviations

As you analyze progress throughout the life cycle of your project, it is important to keep stakeholders advised of any variance that could impact the outcome of the project. You may choose to supplement your project status report with charts or tables to clarify and summarize the results of your analysis. Several useful charts and reports can be produced using your project management software. For example, a tracking chart can be produced in Microsoft Project that displays the status of major deliverables or milestones compared to the schedule baseline. If you have loaded cost data into the software, other reports compare what was spent to what was budgeted.

Tip

The key to success is to keep things as simple as possible. The point of using graphs or charts is to clarify how the project is performing compared to the plan. Avoid using acronyms or other analytical terms the stakeholders may not be familiar with. Translate your results into language everyone can understand.

Managing Trade-Offs

Early on in this book we mentioned that all projects share common constraints: scope, time, cost, and quality. If any one of these changes during the course of a project, it impacts at least one of the other three. Change of some form is inevitable in all projects; so don t think that you can keep all the variables stagnant.

As project manager, you need to communicate the trade-offs to the stakeholders if there is a change to one of the constraints. You should have an idea regarding the importance of the constraints from your planning meetings with the client, so that you can present the trade-offs based on the constraint the client does not want to change. Let s look at how changes in one area of the plan impact the others.

Scope Trade-Offs

A scope change request is often one of the easiest to deal with from a communications perspective, because your change control process includes an analysis of the impact of the proposed scope before the change is approved.

If your client wants a new feature added to the address validation project, you need to communicate the increased cost and/or increased time it will take to add that feature. Additional resources or team members with different skill sets may be required. Clients may often push back and want you to just do it all within the same time period with the money currently budgeted. The client needs to understand that the only way to accomplish that is to give up quality by eliminating or shortening test cycles.

When dealing with scope changes, look for alternate solutions that may be acceptable to the client. If a new feature cannot be added to the existing project without a schedule change, perhaps it can be looked at as a future enhancement. There may be other ways to obtain the result the client needs, so always ask questions to clarify what is behind the scope change request.

Schedule Trade-Offs

The importance of a schedule delay can run from an inconvenience to a disaster, so it is critical that you know and understand the relative importance of this constraint for your project. Let s look at a situation where your 10-month project is staying within budget and has not been subject to scope changes, but you need to obtain approval from your stakeholders to extend the project end date 3 weeks. On the surface this request seems reasonable; we all know that the estimates made during project planning are educated guesses. In many situations, the logical course of action may be to recommend delaying the end date rather than to add risk to the project by implementing crashing or fast tracking. However, if the project was designed to meet a regulatory action with a mandated implementation date, you would certainly lose credibility making a recommendation that would cause your organization to be in noncompliance and subject to fines or other legal action. You should always consider the priority of the target end date and the impacts of missing this date before you recommend a schedule delay.

If your actual results indicate that you are behind schedule in several areas, it is likely that the work effort was underestimated or the requirements did not communicate the true complexity of the project. Regardless of the reason, if you are behind schedule and see no viable means of catching up with the current resources, you need to present your stakeholder with options. Assuming the project delivery date is the highest priority, you need to assess how the date can be met. If your issue is resources, explain to the stakeholders the resources required and the estimated cost. If more resources will not impact the end date or if no funds can be secured, you should be prepared to discuss removing functionality from the project.

A Phased Delay

Telling your stakeholders that there will be a delay in the project delivery is no fun, but sometimes you just can t avoid it. It may even be a big delay. But don t make it worse by downplaying the length of the delay and crossing your fingers.

One of our early project experiences involved a new system application that was being developed for customer care representatives from two recently merged companies. Although the requirements and all of the major deliverables referenced one system, each company had separate backend systems to interface with the new customer care system. So in reality, the development team had twice the application interface work than had been planned.

Everyone on the team knew there was no way that the project would deliver as scheduled, and the development team completed a revised estimate that would delay the project by 6 months. Both the development manager and the project manager were afraid to go to the sponsor and the client with this news, so they communicated a 2-week delay and hoped for a miracle . The 2 weeks didn t change anything, so they communicated another 2-week delay. At this point the sponsor started asking a lot of questions, and the project manager had to admit that the best estimates of the additional work required indicated a 6-month delay. The sponsor was furious that she had not been told the truth from the beginning, and the credibility of the project manager was nonexistent. In fact, a new project manager was named shortly after this incident.

No one likes bad news, but you will be much better off if you take one big hit and present all the facts. Too many project managers try to sugarcoat project problems and convince themselves that the project will turn around ”that rarely happens.

Schedule delays may be inevitable. If the original requirements were not clear or a required element was missed, the project may be more complex than anticipated. Work may have progressed beyond the point where functionality can be removed without creating rework . If there is no way to avoid moving out the schedule, and the project is still viable, you need to make sure that the new end date reflects all changes that have occurred since the project was planned.

Cost Trade-Offs

Cost overruns can be the result of inaccurate estimates, schedule delays, scope creep, or omission of critical items from the cost baseline. Because costs may increase from so many areas, it is important to track costs relative to the work that has been completed. What has been spent at a given point in time may be over budget, under budget, or right on track depending on what milestones have been reached. If you budgeted $50,000 for a project phase, have spent $50,000, and the phase is complete, you are right on track. However, if you have spent $50,000 and the phase is only 30 percent complete, you have a problem.

If the project budget is cast in stone and you are experiencing overruns, the only way to make up the difference is to shrink the project. The best way to accomplish this is to meet with the client and the sponsor to decrease the scope of the project that will allow the project to complete with fewer resources and stay within budget. If you find yourself in this situation, make sure you are fully aware of the work that remains. It will accomplish nothing if the client agrees to give up functionality that has already been delivered.

A sponsor or client may push to retain the current scope, and make up for the budget overrun by short cutting testing or other quality activities. If this happens you need to make sure they are willing to accept the consequences of defects that may not be found until the system is in production.

Negotiating project trade-offs may not always be the best solution. If there are no viable alternatives, you need to present a recommendation to cancel the project.

Canceling a Project

In some cases, the best solution for dealing with project variance may be a recommendation to cancel the project. It is better to cancel a project that cannot be adequately funded or staffed to produce the needed deliverables than to let it continue and fail. If a project was approved without adequate planning, you may find yourself in a situation in which there is no viable solution. If requirements are constantly changing, or the client expectation is totally out of synch with the plan, you need to ask the sponsor and the other stakeholders if the project is still viable. If it seems that everything needs to be changed, perhaps there has been a change to the business strategy and this project is no longer needed.

Recommending cancellation of a project does not mean that the project manager has failed, it means he/she is forcing the sponsor and the client to reassess the original objectives and determine if this project still makes good business sense.

Case Study: Chaptal Wineries ”Intranet and Email

You ve been evaluating the project for quality, budget, and timeliness.

Budget While the majority of the budget has gone well ”there have not been huge budget shortfalls ”you perform a quick estimate from the place where you ve gotten hit the hardest ” hardware. The result shows that you re almost $3,000 over budget, or about 3 percent of the overall $100,000 cost of the project.

Category	Actual	Estimated	Difference
Servers	79,124	80,000	$876.00
Network	21,478	20,000	$(1,478.00)
French E1	2,980	2,000	$(980.00)
Australia T1	2,480	2,000	$(480.00)
Chile T1	2,730	2,000	$(730.00)
California T1	1,990	2,000	$10.00
Total	$(2,782.00)

Since you had not ascertained a predetermined variance number for the project, you decide to visit Kim Cox to see what she thinks about the overage. Kim tells you that she had in mind a +/- 5% variance, so she s OK with the fact that you re slightly over. However, just because you re within variance does not mean that you can call yourself overly successful with the project budget.

Quality The overall quality of the various elements of the project have, in your opinion, been high. Signal over the T1s is now good throughout ”the Chilean telecommunications contractor was able to fix the problem easily (after Metor asked for a replacement from the first person who did the configuration). Customer response on the contractor s part was excellent and took no time at all to get going.

You re also especially pleased with your intranet developer, Susan Wilcox. She has produced high-quality pages at a rapid rate. While she ll use up every bit of the allotted time you ve given her, she has committed to not going over and has made all of her deadlines so far. You re quite pleased with the responsiveness and completeness of the pages.

Timeliness With the exception of the 2 weeks wasted waiting on the Chilean telecommunications contractor to produce someone else who could figure out what was wrong with the T1 configuration, there have been no timeliness issues.

Summary

As we discussed earlier in the chapter: things change. Project control can be viewed as the glue that holds hold the project together. Continuous monitoring of project results and the implementation of appropriate action to make course corrections are the keys to delivering a successful project.

An integrated change control system is an umbrella that recognizes change or requests for change, determines the global impacts of a change, and updates all impacted portion of the project plan when a change is made.

Youll use scope change control to handle such issues as scope creep, reviewing and analyzing requests for scope changes, and updating all impacted documents if a scope change occurs.

As project manager, your concerns center around many change control issues. For instance, schedule control requires ongoing review of progress reports and schedule updates, with a focus on any delays to critical path tasks . Cost control compares actual spending with the cost baseline as it relates to the completion of specific deliverables or phases. When providing quality control, youll implement the quality activities defined as part of the quality management plan.

Of course, any project has its risks. A project manager must use risk monitoring and assess the impact of the risk prevention steps identified during planning, identifying and prioritizing new risks, and implementing contingency plans based on a trigger event. Furthermore, the project manager must review and monitor the issues log to confirm that issues are being resolved and closed appropriately.

A project manager is also in charge of determining whether all of the project team players are doing what they set out to do at the cost they had originally estimated. Performance reporting uses a variety of analysis techniques to quantify the project control results for communication with the project stakeholders. Performance in any project element that goes outside predefined limits requires action on the part of the stakeholder team. Trade-offs between quality, scope, schedule, and cost are presented by the project manager. Cancellation of the project is also an action for consideration if the project is no longer viable based on any of the trade-off options.

Exam Essentials

Explain variance analysis. Variance analysis compares actual project results from the schedule tracking or budget reporting to the planned results as documented in the baseline.

Describe the possible impacts to check for when evaluating a major change to the project scope. A major change to the project scope may impact project objectives, the critical path , the schedule end date, budget, project performance indicators, resources, and risks.

Understand the steps involved in responding to a significant variance from plan, such as increased overtime. The reason behind the variance needs to be identified to determine whether scope creep is occurring. The impact on the budget and schedule need to be determined, followed by a plan for corrective action.

Explain how to prevent scope creep when handling requests for changes. The change control process, which includes a thorough analysis of each request and a formal approval process, is used to manage all requests for a change to the project.

Understand the options to present to stakeholders when a project is not progressing as planned. The stakeholders need to be given options that include trade-offs on scope, schedule, budget, or quality. In some cases, project cancellation may also be an option.

Define estimate to complete (ETC), estimate at completion (EAC), and budget at completion (BAC). Estimate to complete (ETC) is a forecast of the cost of all remaining project work. Estimate at completion (EAC) is a projection of final project costs obtained by adding the ETC to the actual project costs to date. Budget at completion (BAC) is the amount of the project budget that remains after subtracting the actual costs spent to date.

Understand who the various standards bodies are that develop some of the essential standards used in IT. Its important to be aware that organizations such as ISO 9000 and ITIL help with quality and operational standards.

Be familiar with the Capability Maturity Model. Understand what CMM represents in helping organizations understand where they are in terms of how they implement projects.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

acceptance	performance reporting
actual cost (AC)	planned value (PV)
actual cost of work performed (ACWP)	quality control
budget at completion (BAC)	rebaselining
budgeted cost of work performed (BCWP)	revision
budgeted cost of work scheduled (BCWS)	rework
Capability Maturity Model (CMM)	risk monitoring and control
control chart	risk trigger
cost control	schedule control
cost performance index (CPI)	schedule performance index (SPI)
cost variance (CV)	schedule update
earned value	schedule variance (SV)
earned value analysis	scope change control
estimate at completion (EAC)	status date
estimate to complete (ETC)	to-complete performance index (TCPI)
inspection	trend analysis
integrated change control	variance analysis
Pareto diagram

Review Questions

You are a project manager for a new software application. You have just learned that one of your programmers is adding several new features to one of the deliverables. What is the best action to take?
1. Make any needed adjustments to the schedule and cost baseline and tell the programmer that any future changes must be approved by you.
2. Request the programmer to remove the coding for the new features, as he is outside the boundaries of the original scope statement.
3. Contact the appropriate functional manager and request a replacement for this programmer.
4. Determine the source of the request for the new features and run this change through the scope change process to determine the impact of the changes and obtain formal approval to change the scope.
You have just received the latest update to the project schedule. Based on the progress to date, system testing is projected to take 3 weeks longer than planned. If this happens, user acceptance testing will have to start 3 weeks late and the project will not complete on the planned finish date. The client scheduled the user acceptance testing participants weeks in advance. What is the best course of action?
1. Explain to the test team that system test will end on the scheduled date and they are accountable for the accuracy of the testing results.
2. Meet with the test team to determine the cause of the delay. If you determine that there are not enough testers to complete all of the scenarios in the time allotted, work with the sponsor to secure additional testers to complete system test as planned. If no alternatives can be implemented, work with the client to resolve the impacts to user acceptance testing.
3. Write a memo to the client stating that you have a new date when the project will be ready for the end user testers.
4. Escalate the issue of the system test delay to the sponsor and let her decide what action to take.
Your $5,000,000 application development project includes the purchase of two new servers, which are currently listed in the cost baseline at $50,000 each for a total of $100,000. Between the time the estimate was made and the equipment was purchased, there was a 10 percent price increase. The bill for the servers will be a total of $110,000. What action should you take? Choose the best answer.
1. Use the new figure to revise your cost estimate and communicate the change to the project team and other stakeholders as part of your ongoing performance reporting.
2. Add the additional server costs as an agenda item for the next project team meeting and work with the project team to develop a recommendation to take to the sponsor on scope reduction to cover the increased cost of the server.
3. Review the scope statement and the schedule baseline for adjustments to make due to the impact of the server cost.
4. Schedule a performance review meeting with the project team member responsible for the estimate.
You are the project manager for a new address verification system. The development phase has experienced some delays, and you are meeting with the development team to look at alternatives to get back on schedule. A suggestion is made by the development manager to skip unit testing and go right to the system test. What is the best response to this suggestion?
1. The development lead has the most information about the complexity of the individual modules. You decide to accept the suggestion, as you already have 3 weeks scheduled for the system test. That should be more than enough time to find any problems.
2. You agree to accept the suggestion, but make it clear to the development lead that she is accountable if this decision leads to rework or problems as a result of the system test.
3. You need to request more information from both the development lead and the test manager regarding the complexity of the unit tests and the potential impacts to the system test if this step is omitted.
4. You should explain to the development lead that no quality activities can be removed from the schedule, but you can agree to a scaled back version of what is reviewed during testing.
The system test results of your address verification system have uncovered a problem with the screen flow that is presented to the end user. Fixing the problem will involve a major rewrite of a portion of the screen flow logic. The end user can still access the missing screens, but this involves additional user training on commands to manually request a specific screen. What is the best course of action?
1. You should send a memo to the client and copy the stakeholder team explaining both the problem and the action required of the end user. Ask the client to determine if there are any schedule changes related to end user training.
2. You should review the test results with the stakeholder team and provide estimates on the impact to the schedule and the budget if the rework is done. This information should be compared with the cost of additional user training and the impact of the manual override on productivity of the customer experience.
3. You should escalate the problem to your sponsor for resolution.
4. You should call an emergency meeting with the team that developed the screen flow logic. Let them know that the problem must be fixed without any impact to the schedule regardless of the hours they must put in. They are salaried employees and are not eligible for overtime, so there will not be any impact to the budget.
Which of the following is not one of the results of completing quality control activities?
1. Acceptance of defects
2. Rework to correct defects
3. Development of a Pareto diagram
4. Process changes
The project you are currently managing requires a new piece of equipment that has only been available in limited quantity in a beta test mode. The manufacturer has assured you that the device will be in production mode in time to meet the committed delivery in your project schedule. Delivery of this device was identified as a high priority risk during risk planning. Because you have no authority to impact the production of the device, your team designed a contingency plan that uses a different device that will allow the project to move forward with reduced functionality. Which of the following is the best example of a trigger that indicated that you need to implement the contingency plan?
1. A major trade magazine has just printed a story quoting informed sources predicting the resignation of the manufacturers CIO.
2. Several of your project team members have come to you to express concern regarding the dependency on this one vendor.
3. Rumors are circulating that testing of the device is not progressing as planned and major rework will be required.
4. The vendor is scheduled to ship the first set of devices on March 1. It is February 3 and you have not received the required written confirmation from the vendor regarding the shipping date.
Which of the following is the correct term for the forecast of the total project cost based on current performance results?
1. Actual cost (AC)
2. Estimate at completion (EAC)
3. Budget at completion (BAC)
4. Estimate to complete (ETC)
Which of the following statements is most effective to communicate a budget overrun to stakeholders?
1. We have spent $325,000 on the development phase compared to the cost baseline estimate of $250,000.
2. We are overrunning our budget by 30 percent.
3. We ran a little over budget in the development phase, but plan to make it up later on.
4. Project expenditures to date have been $325,000.
You are a project manager for a new product your company will be aggressively promoting. Your client is the VP of Marketing and Sales, and at the time the project charter was approved, she was very clear that the product would be launched on June 15, and information regarding the launch has already been provided to several trade publications . Things have been going great to this point: you are within the budget range and all the major milestones have been met. You have just been advised that one feature of the new product is not functioning properly and will require rework. To launch the product with the new feature, you will need to extend the launch date to July 1. How should you communicate this schedule delay to the VP? Choose the best answer.
1. Advise your client that the product release will be delayed 2 weeks because the user requirements for the new feature were not clear.
2. Tell the rework team to do whatever it takes to get the feature in the product, not worry about any testing, and plan on fixing any problems after launch.
3. Advise the VP that you can meet the committed launch date of June 15, but only by releasing the product without this one feature, and adding the feature in 2 weeks to existing customers via a download from the company website.
4. Update the project schedule and communicate the change as part of your regular status report. A 2-week delay is not that big a deal.
You have just received this Pareto diagram (see exhibit) displaying the results of unit testing. Based on what you see here, what action should you take?
1. Have the programmers start working on the category E errors. Since there are fewer errors here, it should be easier to fix and you can complete one of the five categories and report that you are 20 percent done.
2. Send a memo to the programming lead advising him that all the defects must be fixed in one week.
3. Focus the programming team on the defects in category A.
4. Escalate this to the project sponsor, so she can decide which category is most important.
Youre a project manager for a complex IT project thats well under way; youre in the middle of the executing/controlling phase. You have a disgruntled team member who is severely distracting the teams focus. The team member came to the team with some sort of chip on his shoulder but managed to keep it low-key until now. The team member has skills that are critical to the projects success. Whats the best plan to deal with this issue?
1. Ask him to seek a new team to work with.
2. Ask the team member what the issues seem to be. Tell him that things arent working out and that youre seeking a new team to work with.
3. Ask the team member what the issues seem to be. Try to get to the heart of whats bothering him. Ask him how you can help correct the issues, if possible. Stress the importance of the project and his role on the team.
4. Tell the team member what you perceive the issues to be. Ask him whats bothering him. Stress the importance of the project and his role on the team.
Youre a project manager for a complex IT project thats well under way; youre in the middle of the executing/controlling phase. You have a team member who was at one time a star performer but has now begun to slack off. As a result, the tasks she has been working on are behind schedule. Youre beginning to become concerned . Whats the best plan to deal with this issue?
1. Ask the team member what the problem seems to be with her late work. Ask her if there are ways that you can help her return to her former level of productivity.
2. Ask the team member what the problem seems to be with her late work. Tell her that she needs to get back to the level of productivity she was at before she started slacking off.
3. Tell the team member that other team members are asking about herwanting to know why her performance level has dropped off. Ask her if there are ways that you can help her return to her former level of productivity.
4. Ask the team member what the problem seems to be with the late work. Ask her if you can get an assistant to help her finish her work.
What are some methods you can use to control the quality of server installations? (Select all that apply.)
1. Obtain all the gear from the same vendor.
2. Assure that all servers have a 10Mb or higher connection.
3. Assure that all gear comes from the same manufacturer.
4. Create a burn document against which all servers are burned.
5. Make sure youve got a gold-level maintenance agreement.
Stakeholders have come to you to tell you they want to change the scope. Before agreeing to the scope change, what things should you do next? (Select all that apply.)
1. Determine which project constraint (time, budget, quality) is most important to stakeholders.
2. Discuss the proposed scope change with the sponsor.
3. Ask team members what they think about the scope change.
4. Define alternatives and trade-offs that you can offer back to stakeholders.
You are the project manager for a project thats implementing a new manufacturing system that controls the output of widgets. You have just received this Pareto diagram (see exhibit) displaying the results of how the system performed on several different test days, given different system configuration settings. The test basis was 10,000 widgets manufactured per test. Based on what you see here, what action should you take?
1. Scrap the new system. None of the configurations are worth using.
2. Use configuration E.
3. Use configuration B.
4. Not enough data in this chart to allow for a good choice.
Which calculation will show you the ratio of remaining work compared to remaining budget and is represented as a percentage?
1. TCPI
2. BWCP
3. SPI
4. CPI
Youre preparing some variance figures for your project and you want to show the variance between a tasks estimated progress versus its actual progress. What variance formula should you use?
1. SV = BCWS BCWP
2. CV= BCWS BCWP
3. SV = BCWP BCWS
4. CV = BCWP BCWS
Suppose that youve got a task thats going to take 5 days starting on opening of business on Monday and ending on closing of business on Friday. The task is projected to cost $250. The task concludes successfully at noon on Thursday. What is the BCWS?
1. $100
2. $150
3. $175
4. $200
5. $250
Suppose that youve got a task thats going to take 5 days starting on opening of business on Monday and ending on closing of business on Friday. The task is projected to cost $250. The task concludes successfully at noon on Thursday. What is the ACWS?
1. $100
2. $150
3. $175
4. $200
5. $250

Answers to Review Questions

D. The client may have requested the new features. If these are required features omitted from the original scope statement, you need to analyze the impact to the project and obtain approval for the change. If you just make adjustments to the budget and schedule without any analysis, you not only risk being late and over budget, there may be impacts to other areas of the plan or risks associated with this change. Removing the new features may add additional cost and time to the schedule as well as create a potentially hostile relationship with the client. Unless this is a situation where the programmer has repeatedly changed scope outside of the approval process, requesting a replacement resource is not an appropriate response.
B. Any time you have a projected delay in a major deliverable , you want to immediately determine what is causing the delay, as you may determine steps to bring the deliverable back on track. If you determine that there are no options to prevent the delay, you should meet with the client to develop a workable solution to providing testing resources at a later time. Setting an arbitrary finish date for a deliverable that is already behind will almost assure incomplete testing and a potentially poor quality product. Given the magnitude of the impact to the client, this is not a situation that should be communicated in a memo. You need to be part of the solution.
A. A price increase of that magnitude has a negligible impact on a project with a $5,000,000 budget. The change needs to be documented and communicated, but it does not warrant a scope reduction. The estimate was made with the best information available at the time, so the project team member who provided the estimate did nothing wrong. An equipment cost increase alone will not impact the scope or the schedule baseline.
C. Even reducing the number of planned quality activities or the scope of an activity can be risky. Leaving out the unit test could result in defects that could have been corrected early on not being found until the system is being tested end to end. You do not have enough information at this point to assess the impact of that suggestion, and you need to involve the test manager. Regardless of what you may say to the development lead, you are accountable for the entire project and would take the blame if this approach backfires.
B. This is a classic case of the need to evaluate trade-offs with the stakeholder. There is no perfect solution in this case, but situations similar to this occur on a daily basis in the world of project management. Making unreasonable demands on the project team will not resolve the situation; it may even make it worse . This is not an issue that should be decided in a vacuum by the project manager or even the sponsor; it requires input and consensus from the stakeholder team, particularly the client, regarding the best course of action.
C. A Pareto diagram is one of the quality control tools and techniques. It is used to rank importance of a problem based on its frequency of occurrence over time. The actions that are taken following the completion of a quality activity are accepting the defects that were found, reworking the deliverables involved to correct the defects, or changing processes to prevent defects from happening in the future.
D. The vendor has missed a key milestone datethe written confirmation of the device shipping date. The team member concerns may be valid, but the risk associated with a new device produced by only one vendor was accepted when the project was authorized. The speculation regarding the status of device testing may be indications that the device will not be available, but you need to contact the vendor and ask specific questions. The other answers may all warrant further investigation, but you would not want to implement your contingency plan based on unconfirmed rumors.
B. Estimate to complete (ETC) is a forecast of the cost of all remaining project work. Estimate at completion (EAC) is a projection of final project costs obtained by adding the ETC to the actual project costs to date (the AC). Budget at completion (BAC) is the amount of the project budget that remains after subtracting the actual costs spent to date.
A. The stakeholders need to know the amount of money that has been spent, the amount of money that was budgeted, and what portion of the project is included in that number. Presenting just the amount spent or just the percentage overrun does not provide stakeholders with the context they need. Answer C is an attempt to mask what could be a serious issue.
C. Since you are aware that the product release date is the clients top priority, your first option should be one that keeps the launch date and proposes trade-offs in another area. Trying to shift blame to the user requirements will make the situation worse. If the requirements were unclear, you should have resolved this issue during planning. Releasing a product with an untested feature is very risky and a shoddy product could do major damage to the companys reputation. There may be cases where a 2-week delay is not a big issue, but this is definitely not one of them.
C. A Pareto diagram ranks problems based on the frequency of occurrence. The purpose of a Pareto diagram is to direct the quality improvement efforts to those areas that will have the biggest impact. The defects in category A account for 40 percent of the problems, so you want to address those first. Fixing category E may be quicker, but it will resolve only 5 percent of your problems. A Pareto chart is unrelated to the amount of time it should take to fix defects.
C. People, not equipment or code, are the most important thing your project team has going for it. Clearly, this individual came to the team with some sort of issue. Its important that you work with him, not because hes mission-critical to the project, but because he has issues that you might be able to help him with so he can enjoy his time working on the project just like everyone else. Its important that he knows his importance to the team and the project as well.
A. This team member has demonstrated that shes able to handle the level of work youve given her and can produce quality output. Now shes begun to slack off. The problem could be that shes been working too much overtime or that shes lost energy for the project. Its up to you to figure out whats bothering her, then see if you can fix it and get her back on track. You should never bring up that others are asking about her (even if they are). You also shouldnt resort to ordering someone to do something. Telling her to increase her productivity is going to result in exactly the opposite effect. Shes able to do the work, an assistant isnt requiredgetting at the heart of the issue is whats needed.
A, C, D. While its not altogether important that you get all of your gear from one vendor (because most large hardware vendors outsource huge lots of components for their setups anyway), it has support implications for the servers. Settling on a given manufacturer and making sure all the gear is from that manufacturer or that the manufacturer has operational agreements with his outsourced suppliers may go a long way toward making sure the installations are uniform and of good quality. For example, you may have an item in your burn doc that requires that the BIOS for each computer be upgraded to the latest version before the NOS is installed. If youre working with different server manufacturers, then you have to worry about each manufacturers implementation of BIOS updates. A standardized burn doc is mandatoryone standard burn doc for each type of server youre burning.
A, D. Determining the constraint that stakeholders think is driving the project will help you determine the kinds of trade-offs or alternatives you can propose to lessen the effect of the proposed scope change.
B. A Pareto diagram ranks problems based on the frequency of occurrence. The purpose of a Pareto diagram is to direct the quality improvement efforts to those areas that will have the biggest impact. The defects in category E reflect a much smaller percentage of the problems, so this would prove to be the most likely configuration to utilize. Using item B would result in disaster as this bar represents the most defects of all of the manufacturing runs.
A. The to-complete performance index measures remaining work to remaining budget. TCP can be viewed as an efficiency formula where the higher the percentage you derive, the more efficiency youre currently getting out of a task. A TCPI that is more than 20 percent higher or lower than the cost performance index (the ratio of each of the projects tasks to its costs) means that the current estimate at completion (EAC) is not representative of past performance. Here is the TCPI formula:

TCPI = work remaining / funds remaining

Where: work remaining = BAC BCWP

Funds remaining = BAC ACWP
C. The schedule variance (SV) is calculated by taking the budgeted cost of work performed (BCWP) and subtracting the budgeted cost of work scheduled (BCWS). Recall that the BCWS and BCWP are derived from the estimated figures for a task as compared to actual performance (see definitions of these items earlier in the chapter).
E. The BCWS is calculated by dividing the number of days projected for a task by its budgeted cost. So a task that you think will take 5 days and cost $250 is going to cost $50 a day. Regardless of how quickly you finished the task though, your budgeted cost of work scheduled is still $250.
C. The ACWS is calculated by dividing the number of days projected for a task by its budgeted cost, then multiplying the result times the number of days it took to complete the task. So a task that you think will take 5 days and cost $250 is going to cost $50 a day. Since you finished the task at noon on Thursday, you multiply by 3.5 to derive an ACWS of $175.

IT Project+ Study Guide

IT Project+ Study Guide

Assessment Test

Assessment Test

Answers to Assessment Test

Project Control