Information Technology Project Management - Providing Measurable Organization Value

Information Technology Project Management. Providing Measurable Organizational Value, Third Edition
Chapter 7: The Project Schedule and Budget

ISBN: 9780470371930 Author: Jack T. Marchewka
copyright © 2009 John Wiley & Sons Inc.
The Project Schedule and Budget

Chapter Overview

Chapter 7 focuses on developing the project schedule and budget and introduces a number of project management tools for developing the project plan. After studying this chapter, you should understand and be able to:

* Describe the Project Management Body of Knowledge (PMBOK®) area called project cost management.
* Develop a Gantt chart.
* Develop a project network diagram using a technique called activity on the node (AON) technique.
* Identify a project’s critical path and explain why it must be controlled and managed.
* Develop a PERT diagram.
* Describe the concept of precedence diagramming and identify finish-to-start, start-to-start, finish-to-finish, and start-to-finish activity relationships.
* Describe the concept of critical chain project management (CCPM).
* Describe the various types of costs that make up the project’s budget.
* Define what is meant by the baseline project plan.

Introduction

The last several chapters have been leading up to the development of the project schedule and budget. Chapter 3 introduced the project planning framework (see Figure 7.1). To support this framework, subsequent chapters introduced several Project Management Body of Knowledge (PMBOK®) areas, including project integration management, human resources management, project scope management, and project time management. In this chapter, you will be introduced to another knowledge area called project cost management, which will bring all of the concepts, tools, and techniques covered in the last several chapters together so that the project plan can be developed.

Figure 7.1 The Project Planning Framework

[Click to enlarge]

The project plan contains all of the details of the project’s schedule and budget. It will be used to guide the project team and monitor the project’s progress throughout the project life cycle. Project time management was introduced in the last chapter; however, our focus was on two important processes: Activity definition and activity duration estimation. These two processes are key ingredients for developing the work breakdown structure (WBS) that links the project’s scope to the project plan. The development of a project plan, however, requires a schedule and budget. The project schedule builds upon the WBS by identifying the sequence of activities as well as the interdependencies and relationships. Once the activities, their expected durations, and sequence are identified, various project management tools can be used to map a network of activities to yield the project schedule. This information, in turn, can be entered into a project management software package to make developing the project plan more efficient and to provide a means to monitor and control the project schedule and budget as the plan is executed.

The project budget is determined by the project schedule, the cost of the resources assigned to each of the tasks, and by any other direct or indirect costs and reserves. In addition, a PMBOK® area called project cost management focuses on the processes, procedures, and techniques to develop and manage the project budget. According to PMBOK®, project cost management includes:

* Cost estimating—Based upon the activities, their time estimates, and resource requirements, an estimate can be developed.
* Cost budgeting—Once the time and cost of each activity is estimated, an overall cost estimate for the entire project can be made. Once approved, this estimate becomes the project budget.
* Cost control—Ensuring that proper processes and procedures are in place to control changes to the project budget.

Once the project schedule and budget are determined, the total time and cost of each activity can be summed using a bottom-up approach to determine a target deadline and budget. The schedule and budget must, however, be reviewed and accepted by the project sponsor or client. This may require several revisions and possible trade-offs before the scope, schedule, and budget relationship is reasonable and acceptable to all of the project stakeholders. Once the schedule and budget are approved by the sponsor or client, the plan becomes the baseline project plan. This milestone is an important achievement that marks the completion of the second phase of the IT project methodology and gives the project manager and team the authority to begin carrying out the activities outlined in the plan.
Developing the Project Schedule

Overeager new manager promises his boss a thirty-day schedule for a project to automate passwords on company’s mainframe, midrange, and desktop systems. “We can’t do that,” desktop support pilot fish tells manager when he sees the project plan. “Have you confirmed that the mainframe and midrange support groups can do the product evaluation in the three days you’ve allotted?” fish asks. “No,” says manager, “but if they don’t meet the plan, then it’ll be their fault it fails, not mine.”

From Shark Tank: That’s One Way to Look at It, May 20, 2002. http://www.computerworld.com/careertopics/careers/training/story/0,10801,71293,00.html.

The WBS identifies the activities and tasks that must be completed in order to provide the project scope deliverables. Estimates provide a forecasted duration for each of these activities and are based upon the characteristics of the activity, the resources assigned, and the support provided to carry out the activity. Project networks, on the other hand, support the development of the project schedule by identifying dependencies and the sequencing of the activities defined in the WBS. The project network also serves as a key tool for monitoring and controlling the project activities once the project work begins.

In this section, several project management tools and techniques will be introduced to create a project network plan that defines the sequence of activities throughout the project and their dependencies. These tools include Gantt charts, activity on the node (AON), critical path analysis, PERT, and the precedence diagramming method (PDM). Many of these tools are integrated into most project management software packages; however, it is important to have a fundamental understanding of how these various project management tools work in order to make the most of an automated tool.
Gantt Charts

Working with the U.S. Army during World War I, Henry L. Gantt developed a visual representation that compares a project’s planned activities with actual progress over time. Although Gantt charts have been around for a long time, they are still one of the most useful and widely used project management tools.

Figure 7.2 shows how a basic Gantt chart can be used for planning. Estimates for the tasks or activities defined in the WBS are represented using a bar across a horizontal time axis. Other symbols, for example, diamonds, can represent milestones to make the Gantt chart more useful.

Figure 7.2 Gantt Chart for Planning

[Click to enlarge]

The Gantt Chart in Figure 7.2 depicts the general sequence of activities or work tasks. In this project example, there are five tasks of varying durations and the project should be completed in 15 time periods (e.g., days). In addition, the two shaded diamonds following tasks C and E indicate milestone events.

Gantt charts can also be useful for tracking and monitoring the progress of a project. As shown in Figure 7.3, completed tasks can be shaded or filled in, and one can get an accurate picture of where the project stands for a given status or reporting date. In Figure 7.3, tasks A and B have been completed, but it looks like Task C is somewhat behind schedule.

Figure 7.3 Gantt Chart Reporting Project’s Progress

[Click to enlarge]

Although Gantt charts are simple, straightforward, and useful for communicating the project’s status, they do not show the explicit relationships among tasks or activities. For example, we can see from Figure 7.3 that task C is somewhat behind schedule; however, the Gantt chart does not tell us whether there will be an impact on tasks D or E and whether this impact will push back the project’s original deadline. The Gantt chart introduced in this section follows a more traditional form. As you will see, the Gantt chart used in most project management software packages today has been modified to overcome these limitations.
Project Network Diagrams

Project network diagrams include several useful tools for planning, scheduling, and monitoring the project’s progress. Similar to Gantt charts, project network diagrams use the WBS as a basis to provide a visual representation of the workflow of activities and tasks. However, project network diagrams also provide valuable information about the logical sequence and dependencies among the various activities or tasks. Subsequently, a completion date or project deadline should be developed based on a sound estimating process rather than guesstimating a target date or a date set arbitrarily by upper management or the client.

In addition, project network diagrams provide information concerning when specific tasks must start and finish, and what activities may be delayed without affecting the deadline target date. In addition, the project manager can make decisions regarding scheduling and resource assignments to shorten the time required for those critical activities that will impact the project deadline.
Activity on the Node (AON)

An activity or task focuses on producing a specific project deliverable, generally takes a specific amount of time to complete, and requires resources. Activity on the node (AON) is a project network diagramming tool that graphically represents all of the project activities and tasks, as well as their logical sequence and dependencies. Using AON, activities are represented as boxes (nodes) and arrows indicate precedence and flow.
Quick Thinking—Project Runway

Atlanta’s Hartsfield-Jackson International Airport is one of the world’s busiest, with over 88 million travelers in 2005 and an estimated 120 million by 2010. In 2003, Dwight Pullen, a civil engineer for H. J. Russel & Company in Atlanta, Georgia, was named project manager for a $1.28 billion construction project to build a fifth runway. With only 13 years’ experience, a friend joked that Pullen was the youngest person in the country to manage a billion dollar project. He may have been right.

The 9,000 foot expansion runway project was built over a two-lane highway, Interstate 285, which loops around the city of Atlanta. This included building a 1,264 foot tunnel for the highway and building the runway on top of the tunnel to accommodate large planes like the Boeing 747 and Airbus A-380 that can weigh up to 1 million pounds. The project was expected to provide a financial boom that would save the airline industry an estimated $5 million a week in delay costs and was considered a project of national significance. Pullen says that “getting the project done on time and on budget were absolutely essential to the credibility of everyone involved in the project.” The project was completed 11 days ahead of schedule and at $100 million under budget.

Pullen said that the biggest challenge of the project was dealing with the various stakeholders, which included Atlanta city council members, airport executives, the Federal Aviation Administration, the Georgia Department of Transportation, environmental groups, contractors, engineers, and architects. This required building and maintaining strong relationships with all of them. Although Pullen said that he didn’t have to make best friends or go golfing with these people, he relied on these relationships to help with negotiations and to keep his team focused on milestones. According to Pullen, “Some of my colleagues aren’t that good with the relationship side, and I think that causes projects to fail, be delayed, or go over budget. Contractors will hold up your project if they don’t like you—they’re notorious for that!”

The project plan entailed about as much time in the planning phase as it did in the construction phase. Moreover, the design phase was the shortest phase in the master project schedule and included more than 15,000 scheduled activities. These activities were input into a project management software tool called Primavera®. Pullen contends that the work breakdown structure was critical to this project because it served as a “common language” for everyone working on the project and a best practice that allowed him to be successful in analyzing, forecasting, scheduling, and baselining.

Pullen believes one of his keys to success was the idea of project celebrations to keep morale up and mark the completion of milestones along the way. For example, he instituted cake and ice cream parties for “employee of the quarter,” project team awards, groundbreakings, and safety records. At the end of the successful project, Pullen explains, “We went out and had dinner at the end of the runway, then we got up on top of the runway while the lights were on. It’s absolutely beautiful to see that up close, so that was a phenomenal moment. Then we put the whole team in company trucks and raced all the way down the nearly two miles of runway like an airplane would. It was thrilling and even though the celebration was inexpensive, everybody appreciated it.” In addition, the project team also got to take a ten-minute flight around the city on a 767 that took off and landed on the new runway.

1. What is the importance of using project management software for managing a large-scale project?
2. A project will not fail because of a project manager’s inability to use a particular project management software tool. What is the significance of relationships among the various project stakeholders and the project’s schedule and budget?

SOURCE: Adapted from Karen Klein, A Runway Success, Projects@Work, April 5, 2007.

To construct an AON network diagram, one begins with the activities and tasks that were defined in the WBS. Estimates for each activity or task defined in the WBS should have an associated time estimate. The next step is to determine which activities are predecessors, successors, or parallel. Predecessor activities are those activities that must be completed before another activity can be started—for example, a computer’s operating system must be installed before loading an application package. On the other hand, successor activities are activities that must follow a particular activity in some type of sequence. For example, a program must be tested and then documented after it is compiled. A parallel activity is an activity or task that can be worked on at the same time as another activity. Parallel activities may be thought of as an opportunity to shorten the project schedule; however, they also can be a trade-off since doing more than one thing at the same time can have a critical impact on project resources. The activities, time estimates, and relationships for developing a simple corporate intranet can be summarized in a table similar to Table 7.1.

Table 7.1 Activity Analysis for AON
Activity Description Estimated Duration (Days) Predecessor
A
Evaluate current technology platform
2
None
B
Define user requirements
5
A
C
Design Web page layouts
4
B
D
Set up server
3
B
E
Estimate Web traffic
1
B
F
Test Web pages and links
4
C, D
G
Move Web pages to production environment
3
D, E
H
Write announcement of intranet for corporate newsletter
2
F, G
I
Train users
5
G
J
Write report to management
1
H, I

Once the relationships and time estimates for each activity or task in the WBS have been developed, an AON project network diagram can be created, as in Figure 7.4.

Figure 7.4 Activity on the Node (AON) Network Diagram

[Click to enlarge]

The work in an AON flows from left to right. An activity cannot begin until all of its predecessor activities have been completed. For example, Activity F cannot begin until Activities C and D are done.
Critical Path Analysis

At this point we have a visual road map of our project. Moreover, the time estimates for each of the activities determines the project schedule and tells us how long our project will take to complete. This is determined by looking at each of the possible paths and computing the total duration for each path, as shown in Table 7.2.

Table 7.2 Possible Activity Paths
Possible Paths Path Total
Path 1
A + B + C + F + H + J
18
 2 + 5 + 4 + 4 + 2 + 1
Â
Path 2
A + B + D + F + H + J
17
 2 + 5 + 3 + 4 + 2 + 1
Â
Path 3
A + B + D + G + H + J
16
 2 + 5 + 3 + 3 + 2 + 1
Â
Path 4
A + B + D + G + I + J
19*
 2 + 5 + 3 + 3 + 5 + 1
Â
Path 5
A + B + E + G + I + J
17
 2 + 5 + 1 + 3 + 5 + 1
Â

*Critical Path

As can be seen in Table 7.2, the longest path in the AON network diagram is 19 days. This number is significant for two reasons. First, this tells us that our project is estimated to take 19 days (i.e., the project deadline will be 19 days after the project starts). Second, and perhaps more importantly, Path 4 is also our critical path. The critical path is the longest path in the project network and is also the shortest time in which the project can be completed.

Identifying the critical path is a major concern to the project manager because any change in the duration of the activities or tasks on the critical path will affect the project’s schedule. In other words, the critical path has zero slack (or float). Slack, which is sometimes called float, is the amount of time an activity can be delayed, that is, take longer than expected, before it delays the project. For example, Activity E is not on the critical path. In fact, the only path that includes Activity E is Path 5. Subsequently, the start of Activity E could be delayed for two days or take up to three days to complete before the project schedule is affected. On the other hand, Activities A, B, D, G, I, and J have no float because delaying their start or taking longer to complete than we estimated will increase the total duration of the project by the same amount.

As a result, knowing the critical path can influence a project manager’s decisions. For example, a project manager can expedite, or crash, the project by adding resources to an activity on the critical path to shorten its duration. The project manager may even be able to divert resources from certain activities, for example, Activity E because this activity has some slack or float. Diverting resources can reduce the overall project schedule, but keep in mind that there may be a trade-off—shortening the schedule by adding more resources may inflate the project’s budget.

Another way to shorten the project schedule is to look for parallel activity opportunities. Doing two, or several, activities that were originally planned to be completed in sequence at the same time can shorten the critical path. It is known as fast tracking the project.

Can the critical path change? The answer is, absolutely! As a result, it is imperative that the project manager not only identify the critical path, but monitor and manage it appropriately. In fact, it is very possible for a project to have more than one critical path.
PERT

The program evaluation and review technique (PERT) was developed in the late 1950s to help manage the Polaris submarine project. At about the same time, the critical path method (CPM) was developed. The two methods are often combined and called PERT/CPM.

PERT uses the project network diagramming technique to create a visual representation of the scheduled activities that expresses both their logical sequence and interrelationships. PERT also uses a statistical distribution that provides probability for estimating when the project and its associated activities will be completed. This probabilistic estimate is derived by using three estimates for each activity: optimistic, most likely, and pessimistic.

An optimistic estimate is the minimum time in which an activity or task can be completed. This is a best-case scenario where everything goes well and there is little or no chance of finishing earlier. A most likely estimate, as the name implies, is the normally expected time required to complete the task or activity. A pessimistic estimate is a worst-case scenario and is viewed as the maximum time in which an activity can or should be completed.

One can use the following equation to compute a mean or weighted average for each individual activity that will become the PERT estimate:

[Click to enlarge]

The total expected time to complete the project can be easily found by summing each of the individual activity estimates or:

[Click to enlarge]

For example, on our project used earlier, a project manager and team came up with the estimates presented in Table 7.3.

Table 7.3 Activity Analysis for PERT
Activity Predecessor Optimistic Estimates (Days) a Most Likely Estimates (Days) b Pessimistic Estimates (Days) c Expected Duration
A
None
1
2
4
2.2
B
A
3
5
8
5.2
C
B
2
4
5
3.8
D
B
2
3
6
3.3
E
B
1
1
1
1.0
F
C, D
2
4
6
4.0
G
D, E
2
3
4
3.0
H
F, G
1
2
5
2.3
I
G
4
5
9
5.5
J
H, I
.5
1
3
1.3

Analyzing the various paths using PERT provides the critical paths presented in Table 7.4. As can be seen in Table 7.4, the critical path is still Path 4 and the expected completion date of the project is 20.5, or 21 days if we round up. In this case, the deadline increased from 19 days using the AON method to 21 days using the statistical technique associated with PERT. In the first case, the most likely estimates were used, while PERT took into account not only the most likely estimates, but optimistic and pessimistic estimates as well. PERT is well suited for developing simulations whereby the project manager can conduct a sensitivity analysis for schedule planning and risk analysis. But, like any planning and scheduling tool, its usefulness is highly correlated to the quality of the estimates used.

Table 7.4 Possible PERT Activity Paths
Possible Paths Path Total
Path 1
A + B + C + F + H + J
18.8
 2.2 + 5.2 + 3.8 + 4.0 + 2.3 + 1.3
Â
Path 2
A + B + D + F + H + J
18.3
 2.2 + 5.2 + 3.3 + 4.0 + 2.3 + 1.3
Â
Path 3
A + B + D + G + H + J
18.6
 2.2 + 5.2 + 3.3 + 4.0 + 2.3 + 1.3
Â
Path 4
A + B + D + G + I + J
20.5*
 2.2 + 5.2 + 3.3 + 3.0 + 5.5 + 1.3
Â
Path 5
A + B + E + G + I + J
18.2
 2.2 + 5.2 + 1.0 + 3.0 + 5.5 + 1.3
Â

*Critical Path

Precedence Diagramming Method (PDM)

Another tool that is useful for understanding the relationships among project activities is the precedence diagramming method (PDM). This tool is similar to the AON project diagram technique and is based on four fundamental relationships shown in Figure 7.5.

Figure 7.5 PDM Relationships

[Click to enlarge]

* Finish-to-start (FS)—A finish-to-start relationship is the most common relationship between activities and implies a logical sequence. Here, activity or task B cannot begin until task A is completed. For example, a program is tested after it is written. Or, in other words, the code is written and then tested. This relationship is similar to the successor and predecessor relationships used in the AON method.
* Start-to-start (SS)—A start-to-start relationship between tasks or activities occurs when two tasks can or must start at the same time. Although the tasks start at the same time, they do not have to finish together—that is, the tasks can have different durations. A start-to-start relationship would be one type of parallel activity that can shorten a project schedule.
* Finish-to-finish (FF)—Another type of parallel activity is the finish-to-finish relationship. Here, two activities can start at different times, have different durations, but are planned to be competed at the same time. Once both of the FF activities are completed, the next activity or set of activities can be started, or if no more activities follow, the project is complete.
* Start-to-finish (SF)—The start-to-finish relationship is probably the least common and can be easily confused with the finish-to-start relationship. A SF relationship, as illustrated in Figure 7.5, is exactly the opposite of an FS relationship. In addition, an SF relationship means that task A cannot end until task B starts. An example of an SF relationship in real life might be a nurse working at a hospital. This person may have to work until relieved by another nurse who arrives to start the next shift.

An advantage of using PDM is that the project manager can specify lead and lag times for various activities. More specifically, lead time allows for the overlapping of activities. For example, a project plan may have two activities or tasks that have been identified as a finish-to-start relationship. These two activities may be the setup of computers in a lab followed by the installation of an operating system on those computers. If we had two people, one to set up the computers and one to install the operating systems on each computer, the project plan might specify a finish-to-start relationship where the installation of the operating systems cannot begin until all of the computers have been set up in the lab. Based on this project plan, the person who installs the operating system must wait and watch while the other person works.

Let’s assume, however, that it takes about half the time to install an operating system as it does to set up a computer. Furthermore, there is no reason why the software person cannot begin installing the operating system when the hardware person has about half of the computers set up. In this case, both tasks will finish about the same time, and we have created an opportunity to shorten the project schedule. By scheduling the task of installing the operating systems when the task of setting up the computers is 50 percent complete, we have used the concept of lead time to our advantage.

On the other hand, let’s suppose further that before our hardware person starts setting up the computers in the lab, we want the lab walls to be painted. This would be another finish-to-start relationship because we would like to schedule the painting of the lab before we start installing the computers. Using lead time in this case, however, would not make sense because we do not want the hardware person and painters getting in each other’s way. In this case, we may even want to give the freshly painted walls a chance to dry before we allow any work to be done in the lab. Therefore, we would like to schedule a lag of one day before our hardware person starts setting up the computers. Another way of looking at this is to say we are going to schedule a negative lead day in our project schedule.
Critical Chain Project Management (CCPM)

Critical chain project management (CCPM) may be one of the most important recent developments in modern project management. CCPM was introduced in a 1997 book called Critical Chain by Eliyahu Goldratt and is based on his previous work called the Theory of Constraints.

CCPM is based on the idea that people often inflate or add cushioning to their time estimates in order to give themselves a form of “safety” to compensate for uncertainty. People may build safety into each task for three basic reasons. First, you may inflate an estimate if your work is dependent upon the work of someone else. For example, you may add a cushion to your time estimates if you believe there’s a good chance your work will be delayed if the person you are depending upon will not finish their task or work on time. Second, you may increase an estimate of an activity because of pessimism arising from a previous experience where things did not go as planned. Third, the project sponsor or customer may not be happy with a proposed schedule and therefore decides to cut the schedule globally by, say, 20 percent. If you know this is going to happen, you may inflate your estimates by 25 percent just to guard against the cut.

If people tend to build safety into each task, then why do projects still finish late? The answer is mainly human nature. More specifically, many people tend to wait until the last minute before they begin to work on a task. This is often referred to as “student’s syndrome,” as many students procrastinate and then begin working on an assignment right before it’s due—regardless of how much time is available. If things don’t go exactly as planned, the task or assignment ends up being late.

The second reason why projects are still late has to do with Parkinson’s law. This law states that work expands to fill the time available. For example, an individual or team assigned to complete a particular task will rarely report finishing early because there is no incentive to do so. They may be afraid that management will cut their estimates next time or the individual or team waiting for them to complete their task won’t be ready. As a result, the safety built into an estimate disappears. Any time saved by completing a task early is wasted while any overruns get passed along.

A third reason why added safety does not ensure that projects are completed on time has to do with the multitasking of resources. Goldratt calls this resource contention, whereby a project team member often is assigned to more than one project. In addition, this person may be required to attend meetings, training, or be pulled off one project task to work on another. As a result, this person can become a constraint to the project because they are no longer able to devote time and energy to tasks on the critical path. Subsequently, the task takes longer, and so does the project.

CCPM follows a completely different assumption: Instead of adding safety to each task, put that safety in the form of buffers where needed the most. This would be in the form of feeding buffers, resource buffers, and a buffer at the end of the project. Figure 7.6 provides a comparison of a traditional project network schedule and a CCPM schedule. The top diagram illustrates a project schedule that would have safety built into each estimate. The project has five tasks, with each task estimated to be completed in ten days. The critical path would be Tasks A, B, C, and E, so the project schedule is 40 days.

Figure 7.6 The Critical Chain Project Schedule

[Click to enlarge]

However, CCPM begins by asking each person or team assigned to a task to provide an estimate that would have a 50 percent chance of being completed. For our example, let’s say that each task will have a 50 percent chance of being completed in five days. Instead of adding safety to each task, we place buffers where needed. More specifically, we add a buffer to the end of the project by taking one-half of the time saved from the individual tasks. In this example, we saved a total of 20 days from our critical path tasks A, B, C, and E. Therefore, one-half of 20 equals 10 days, and that becomes our project buffer. In addition, task D requires a “feeder” buffer, since the work completed in Task D will be an input to Task C. This is important because a bottleneck can occur when a task acts as a feeder to any task on the critical path. If Task D is delayed or takes longer than planned, it will impact when Task C can either start or finish.

As a result, this will have an impact on the critical path of the project. To minimize the chance of this happening, a feeder buffer is added to Task D that is one-half of the time saved (i.e., 2.5 days).

However, the critical chain is different from the critical path in that it also takes into account resource contention. Continuing with our example, let’s say that each project task is to be completed by a different resource (i.e., person or team). Task C is on the critical path but is also part of the critical chain because of its potential to become a bottleneck if the resource assigned to this task must multitask by working on different projects. If this is the case, the CCPM approach takes a more project portfolio view and would suggest that other projects begin or start so that the person or team working on Task C can be dedicated to work solely on this particular task for this project.

Therefore, CCPM proposes that a resource buffer be created so that the resource working on this task can dedicate time and effort to complete the task with a 50 percent probability in five days. In this case, the critical path and critical chain are the same; however, our project under the CCPM approach is expected to be completed in 30 days.

The CCPM approach requires that everyone understand that since each project task has a 50 percent chance of being completed as scheduled that approximately half of the tasks will be late. This is fine since this is the reason for having the project buffer. Instead of tracking each task individually, we become more concerned with the project buffer. In other words, the project will be late only if it uses more than the ten days allotted in the project buffer. Instead of penalties for being late, the organization may have to provide bonuses or other incentives for completing tasks early.
Project Management Software Tools

A number of software tools are available to make project planning and tracking much easier. In fact, it would be almost unthinkable to plan and manage even a small project without the aid of such a tool. In this section, you will see some examples of how these software tools incorporate and integrate the project management tools and concepts described in the previous section. The overview is intended to show you what these tools do, rather than tell you how to use them.
Quick Thinking—The Map is Not the Territory

Project planning is a critical activity regardless of whether one follows an agile or traditional approach to project management. Too often projects deviate from plans, and the project manager simply assumes that the project needs to be brought back on track. Unfortunately, this may be the result of a poor initial plan or because software is intangible and requirements can be difficult to specify.

Traditional approaches to project management tend to emphasize planning early in the project life cycle when not enough is known about the problem, business environment, or team dynamics. On the other hand, agile methods tend to embrace the realities of IT projects and focus on making planning a more visible and iterative component of the project life cycle. However, a project sponsor will require some indication of how long a project will take and how much it will cost so some sort of schedule and budget will be needed at the beginning of a project. This will require planning the entire project at a high level that outlines an overall timeline and iteration boundaries, but none of the details about individual features should be included in each iteration. Detailed iteration plans that include use cases or user stories are developed from meetings between the developers and customers for each iteration. The high-level plan is then updated to include new details, and velocity. Instead of trying to develop large, detailed plans that quickly deviate from reality and become difficult to maintain, Mike Griffiths of Quandras Development suggests that we are better off leveraging each team member’s ability to manage complexity locally by creating lightweight plans that embrace inevitable changes. Moreover, this supports the PMBOK® guideline to encourage planning throughout the project life-cycle in terms of “rolling wave planning” and “progressive elaboration.” Rolling wave planning is defined as an iterative approach to where planning is ongoing, while progressive elaboration involves developing a plan in steps and continuing increments. Unfortunately, many project managers focus the bulk of their planning too early in the project and therefore create large plans that are difficult to change, so that these two ideas are rarely implemented.

1. Alfred Korzybski is credited with the quote, “The map is not the territory.” How does this quote reflect the realities of project planning?
2. Does an agile approach to project planning better support the PMBOK® concepts of rolling wave planning and progressive elaboration than a traditional approach to project planning where the project manager tries to develop a detailed project plan early in the project life cycle? How could these two concepts be implemented better when a more traditional approach is followed?

SOURCE: Adapted from Mike Griffiths, Extreme Planning, Ganthead.com, January 22, 2007.

As you can see in Figure 7.7, the Gantt chart view integrates not only the Gantt chart, but the project network diagram and PDM techniques. Tasks A and B show a finish-to-start relationship, while Tasks B and C show a start-to-start relationship. Tasks D and E show a finish-to-finish relationship. The task Project Complete has a duration of zero days and, therefore, represents a milestone. The Network Diagram View in Figure 7.8 then highlights the project’s critical path. One of the most useful tools for scheduling and planning a project is a simple calendar. Figure 7.9 illustrates a Calendar View of the project.

Figure 7.7 Microsoft Project® Gantt Chart View

[Click to enlarge]

Figure 7.8 Microsoft Project® Network Diagram View and Critical Path

[Click to enlarge]

Figure 7.9 Microsoft Project® Calendar View

[Click to enlarge]

Developing the project schedule and budget is an important planning process that requires that we sometimes define and estimate a large number of activities several months into the future. But, of course, predicting the future is difficult, and detailed project plans will have to be changed frequently to be useful. A technique called rolling wave planning is becoming common to help deal efficiently with project planning. Instead of developing a large, detailed project plan requiring frequent updates, the project manager can prepare an overall summary plan, or master schedule, and then develop detailed schedules for only a few weeks or a few months at a time (Haugan 2002).
Developing the Project Budget

The project’s budget is a function of the project’s tasks or activities, the duration of those tasks and activities, their sequence, and the resources required. In general, resources used on a project will have a cost, and the cost of using a particular task or activity must be included in the overall project budget. Unless these costs are accounted for, the project manager and the organization will not know the true cost of the project.
Cost Estimation

Estimating the cost of a particular activity or task with an estimated duration involves five steps:

1. Defining what resources will be needed to perform the work
2. Determining the quantity of resources that are needed
3. Defining the cost of using each resource
4. Calculating the cost of the task or activity
5. Ensuring that the resources are leveled—that is, not overallocated. An example of an overallocated resource would be assigning a project team member to two tasks scheduled at the same time.

For example, let’s suppose that we have identified a particular task and estimated that it will take one day to complete and requires one project team member. Let’s also assume, for simplicity, that no other resources are needed.

This estimate may require that we define a cost for using this particular resource. For example, if our team member earns $20 an hour, that sum is what our employee sees on his or her paycheck (before taxes and other deductions). The organization, however, may also provide certain benefits to the employee (health care, life insurance, and so forth) that should be included in the cost for using this particular resource. Since these costs are going to vary from organization to organization, let’s assume that our friends in the accounting department have conducted a cost accounting analysis for us and that the true cost of using this particular employee (i.e., hourly wage plus benefits) is $25 an hour. Subsequently, if we pay our employee for one day’s work (i.e., an eight-hour day), the cost of completing this particular task is:
Cost of task
= Estimated duration × True cost of the resource
 = 8 hours × $25/hour
 = $200

We can even estimate the cost of a salaried employee by prorating her or his salary. This just means that we assign a portion of that salary to the task at hand. For example, let’s say that the fully loaded, or true annual, cost to the organization is $65,000. If this employee works a five-day work week, the associated true cost to the organization would be for 5 × 52 = 260 days a year. Therefore, the prorated cost per day would be $65,000 ÷ 260 workdays = $250 a day.

However, this whole process can be greatly simplified if we use a project management software tool. We still have to identify the tasks and accurately estimate their durations, but determining the costs of a particular task and for the whole project becomes painless. Figure 7.10 shows how resources can be assigned to specific tasks on a project.

Figure 7.10 Using Microsoft Project® to Assign Resources to Tasks

[Click to enlarge]

The project’s total budget is computed using a bottom-up approach by summing the individual costs for each task or activity. As shown in Figure 7.11, the basic budget for this project is $5,203.85.

Figure 7.11 Using Microsoft Project® to Compute the Basic Budget

[Click to enlarge]
Other Costs

It is important to keep in mind that our example has only considered direct costs, or the cost of labor for using this resource directly. In addition to direct labor, resource costs include indirect labor, materials, supplies, and reserves (Kinsella 2002). To determine the total project’s budget, we need to include other costs as well. These costs include:

* Indirect costs—These costs include such things as rent, utilities, insurance, and other administrative costs. For example, a consulting firm may charge a client $150 an hour per consultant. Included in that hourly fee would be the salary and benefits of the consultant and enough margin to help cover the administrative and operation costs needed to support the consulting office.
* Sunk costs—Sunk costs are costs that have been incurred prior to the current project. For example, a previous attempt to build an application system may have ended in failure after three months and $250,000. This $250,000 would be considered a sunk cost, regardless of whether any work from the previous project is salvageable or of use to the current project.
* Learning curve—Often we have to “build one and throw it away” in order to understand a problem or use a new technology effectively. In addition, inexperienced people will make mistakes and new technology will usually require a steep learning curve in the beginning. As a result, time and effort can be wasted. This time to learn should be considered in either the project schedule or budget.
* Reserves—Reserves provide a cushion when unexpected situations arise. Contingency reserves are based on risk and provide the project manager with a degree of flexibility. On the other hand, a project budget should have some management contingencies built in as well. Of course, reserves are a trade-off. Upper management or the client will view these as fat that can be trimmed from the project budget; however, the wise project manager will ensure that a comfortable reserve is included in the project’s budget. For example, it would be sad to think that the project’s budget would not allow the project manager to buy pizza or dinner for the team once in a while as a reward for working late to meet an important milestone.

Resource Allocation

Once the resources have been assigned to the project, it is important that the project manager review the project plan to ensure that the resources are level. In other words, resources cannot be overallocated—that is, most resources cannot be assigned to more than one task at the same time. Although the project manager may catch these mistakes early on, it is important that the level of resources be reviewed once the project schedule and resource assignments have been made. Not catching these mistakes early can have a demoralizing effect on the team and lead to unplanned (i.e., unbudgeted) costs.

A project management tool such as Microsoft Project® provides the means for identifying overallocated resources. Figure 7.12 provides an example of the resource allocation view, where a project team member has been assigned to two tasks at the same time. A project manager has the choice of creating a new relationship for these tasks (e.g., FS) or reassigning another resource to one of the tasks. In addition, many software management tools can level resources automatically for the project manager.

Figure 7.12 Example of Resource Overallocation

[Click to enlarge]
Finalizing the Project Schedule and Budget

The project schedule and budget may require several iterations before it is acceptable to the sponsor, the project manager, and the project team. In addition, it is important that the project manager document any and all assumptions used to come up with duration and cost estimates. For example, this documentation may include estimating the salary of a database administrator (DBA) who will be hired at a future date. Instead of allocating a cost of what the project manager thinks a DBA will cost (or worse yet, what upper management would like to pay), he or she could use salary surveys or salary information advertised in classified advertisements as a base cost estimate. So, the project manager should document the source of this cost in order to give the cost estimates greater credibility. In addition, the project plan may include several working drafts. Having assumptions documented can help keep things organized as well.

Once the project schedule and project plan are accepted, the project plan becomes the baseline plan that will be used as a yardstick, or benchmark, to track the project’s actual progress with the original plan. Once accepted, the project manager and project team have the authority to execute or carry out the plan. As tasks and activities are completed, the project plan must be updated in order to communicate the project’s progress in relation to the baseline plan. Any changes or revisions to the project’s estimates should be approved and then reflected in the plan to keep it updated and realistic.
Chapter Summary

Once project activities or tasks are identified and activity durations are estimated, the sequencing of these activities will help determine the project schedule and estimated completion date. Several techniques were introduced in this chapter. The use of project management software tools can help simplify the development of the project schedule. In addition, these tools can help the project manager identify and monitor activities that are on the critical path. They can help the project manager make decisions with respect to allocation of resources or the rescheduling of activities. In addition, these tools provide a useful information system capable of communicating the actual progress of the project to the original baseline plan.

In general, if a project uses a resource, the cost associated with that resource must be included in the project’s budget and must be accounted for as a cost to the project. Project costs are both directly and indirectly related to the resources needed to complete a particular task or activity or support other resources that do. It is important that the right resources and the right quantity of resources be assigned to the project activities.

Together, the approved project schedule and project budget make up the baseline project plan. Approval of this plan by the project client or upper management gives the project manager and team the authority to carry out this plan. Actual progress is then compared to this plan to determine whether the project is on track, ahead of plan, or behind the plan. In order to keep the plan realistic, revisions or changes to the plan should be approved and made.
Review Questions

1.

Describe the PMBOK® area of project cost management.

2.

Discuss why no project ever failed because of someone’s inability to draw a nice looking project network diagram.

3.

What are some advantages project network diagrams have over traditional Gantt charts?

4.

Define predecessor, successor, and parallel activities. Give a real world example of each.

5.

How can parallel activities help shorten the project schedule? Are there any trade-offs?

6.

What is meant by slack (or float)?

7.

What is the difference between crashing and fast tracking a project’s schedule?

8.

What is the difference between AON and PERT?

9.

Define the following and give a real world example of each (other than the ones described in this book): finish-to-start; start-to-start; finish-to-finish; start-to-finish

10.

What is the difference between lead and lag? Give real world examples (other than the ones used in this book) of how a project manager may use lead and lag in a project schedule.

11.

Why do many people inflate their estimates?

12.

Does adding safety to each task or activity ensure that the project will be completed as scheduled? Why or why not?

13.

In the context of critical chain project management, what is resource contention?

14.

In the context of CCPM, what is the purpose of buffers?

15.

What is the critical chain? How is it different from the concept of a critical path?

16.

Describe the steps necessary for estimating the cost of a particular activity or task that has an estimated duration.

17.

What does prorating the cost of a resource mean?

18.

Why should the project manager ensure that the project resources are leveled?

19.

Why should assumptions used in estimating be documented?

20.

What is a baseline plan?

21.

When does the project manager or team have the authority to begin executing the project plan?

Extend Your Knowledge

1. Develop a network diagram using the AON technique and calculate the critical path using the information in the table.
2. Enter the information from the table into a project management software package. What is the critical path?

Task/Activity Estimated Duration Predecessor
A
1 day
None
B
3 days
A
C
4 days
B
D
2 days
B
E
1 day
C
F
3 days
C, D
G
3 days
E
H
1 day
F
I
2 days
G, H
J
5 days
I
Global Technology Solutions

Kellie Matthews stopped in the doorway of Tim Williams’ office. Tim was just finishing a conversation on his cell phone, and he motioned for her to come in and sit down. After pressing the end button, he asked “How did your meeting go this morning?”

Kellie sat back in her chair. “I think it went well,” she said. “It was with a local textbook distributor interested in purchasing and implementing a call center software package. There are a number of software packages available from different vendors, but the company is not really sure which one best suits its needs. Its information systems department is stretched pretty thin working on several projects already, so it is considering outsourcing this project. I have another meeting with management later this week, so keep your fingers crossed. We may have another client.”

“I will,” Tim said. “That might stretch things around here a little bit, but we’ll cross that bridge when we come to it.”

Kellie agreed. “So how are things going with the Husky Air project? Have you finished the schedule and budget?”

Tim chuckled and said, “I knew that you were going to ask that. Actually, we are making good progress. The phone call that I just finished was with Husky Air’s CEO. He’s pretty anxious to find out how much the project will cost and how long it will take to complete. We have a meeting next week to present the project charter and plan to him and several other senior managers.”

“Will you be ready?” Kellie asked.

Tim picked up his coffee mug from his desk, took a sip, and then said, “We completed the work breakdown structure yesterday. That helped us to identify all of the tasks or activities, the resources that will be required, and each activity’s estimated duration. Right now, we’re trying to determine which activities need to be completed sequentially and which can be completed in parallel. That will help us develop a project network of activities that will allow us to develop a schedule and budget once we enter everything into the project management software package. To finally answer your question, I’m pretty confident that we’ll have a draft of the project plan ready by next week.”

Kellie leaned forward in her chair and asked, “That sounds reasonable. So what do you hope happens at next week’s meeting?”

“If this were a perfect world, I’d hope that our client would approve everything and we could get started right away,” he said, laughing. “But I know that’s not likely to happen. I’m sure that once we present the schedule and budget to them next week, we’ll have to make some changes. But, I’m confident that we’re close to the original estimates outlined in the business case, so we should only have to make some minor modifications. Once approved, we then have our baseline project plan and we can get started on the real project work.”

Kellie stood up to leave. “I have to return a few phone calls before lunch, but please keep me informed and let me know if I can help out,” she said.

Tim was grateful and knew that he could count on Kellie’s help. As Kellie was walking through the doorway and back to her office, Tim was turning to his computer to answer the six e-mails that had arrived in his inbox since he had last checked 30 minutes ago.
Things to Think About

1. How does the work breakdown structure (WBS) link the project’s scope to the schedule and budget?
2. Why might a project manager expect a project plan to go through a number of iterations before being accepted by the project sponsor or client?
3. What role does project management software play in developing the project schedule and budget?

Husky Air Assignment—Pilot Angels
The Project Schedule and Budget

Now that you have defined the project’s scope, it’s time to start the process of determining how the work will be accomplished. This will require that you draw upon work you did in several previous assignments.

Please provide a professional-looking document that includes the following:

1. Project name, project team name, and the names of the members of your project team
2. A brief project description
3. The project’s MOV (This should be revised or refined if necessary.)
4. A detailed project plan
1. If you used a spreadsheet to create your work breakdown structure (WBS), you may want to cut and paste the phases, deliverables, milestones, and activities into Microsoft Project®.
2. Add and assign the resources that you identified in your WBS to each activity or task. Be sure to assign a cost for each resource.
3. Link the tasks. Look for opportunities for shortening the project schedule by performing tasks in parallel (i.e., start-to-start or finish-to-finish).
5. Answers to the following questions:
1. What are beginning and end dates for your project? How many days will it take to complete the project?
2. Does your project have a single critical path or multiple critical paths? What is the importance of the critical path?
3. Does your project have any over allocated resources? If so, be sure to level your resources.
6. An electronic copy of your project plan—Depending on what your instructor tells you, submit your project plan on disk or electronically.

Case Studies
Planning for Success

Chris Morris is a senior IT project manager for Agere Systems, Inc. with over 2,000 projects in his portfolio. A few years ago, major IT initiatives at Agere were in trouble. According to Morris, “Everybody had Microsoft Project® on their desktop and Gantt charts on their wall. The problem was that we weren’t making project decisions based on what was affordable or good for the company.” Project plans ended up being more historical records than future projections. Moreover, there was no clear way to see interdependencies among projects.

Agere decided to take advantage of a project management software package called Primavera®, establish a dedicated project management office, and apply lessons learned and methodologies to every IT project. The results have been more predictable and accurate project schedules and budgets, as well as IT projects that better meet business goals that are achieved for less money. Morris acknowledges that success was not quick or easy.

Based in Allentown, Pa., Agere is a leading manufacturer of integrated chips for wireless devices, disk drives, and network equipment. The company has approximately 7,000 employees and about $2 billion in revenues. The company was spun off from Lucent Technologies in 2001 as the technology industry encountered major challenges and drastic belt tightening. Not surprisingly, Agere’s IT budget was slashed from $270 million in 2001 to about $94 million in 2003.

However, before the spinoff from Lucent, Agere made the decision to implement Oracle’s enterprise resource planning (ERP) system. As Morris explains, “The company had close to 550 business applications that we were executing the business on. It became clear that an integrated package was needed.” To support this project, Agere chose Primavera®, but the IT department wasn’t taking full advantage of this project management software tool. More specifically, project teams weren’t creating project plans that provided accurate schedules and budgets. Even worse, IT was trying to support every project requested by the business units. Morris further explains, “We were doing too many things outside the concept of business benefits. We stopped making good business decisions.”

The high-risk ERP project was in trouble due to divisional conflicts, disjointed planning, and poor resource control. Morris admits, “After a year of execution the project was still essentially at square one. From a pure planning perspective, the project plan was useless as a guide for completion.”

The project needed to be jumpstarted. The project team began by conducting a thorough understanding of Primavera®’s features and functions so they could have a better idea of how the software tool could be better utilized. As Morris points out, “By discovering what Primavera® could do, and why it did what it did, we were really able to understand program management.” The team was able to turn the project around and get it back on track before Agere was spun off from Lucent.

Morris outlines seven steps for program management success:

1. Block and tackle—By clearly identifying the remaining work for the ERP project, the project team was able to develop a realistic and logical plan that focused on the critical path. The schedule became like a police officer, while variance reports acted as an auditor.
2. Move beyond the basics—As the team became more knowledgeable in its approach to project management, it began using the resource profile and loading reports to analyze resource demand and increase the accuracy of the project plan. The team also ran “what if” scenarios to understand the impact scope changes would have on the schedule and resource load. As a result, the team improved the accuracy of the project plan and could plan for multiple possible project paths. Shortly, thereafter, the team started meeting commitments.
3. Repeat and extend—This next step became critical as a project management approach was extended to all major IT projects. All projects now had a sound project plan with extended resource loading moving beyond the view of only a single project. Most importantly, Agere created a program management office (PMO) charged with developing standards, identifying cross-project constraints, providing consistent project management support for key initiatives, and measuring the success of the project portfolio. The PMO could then provide commit dates for all projects based on resource projections with respect to consumption and capacity. Primavera® was a key component for having this ability. As Morris points out, “We were able to use the functionality in Primavera® as a guide for developing methods and standards. We’re now able to model 100 percent of our activities and make project decisions based on the financial and human resources available.”
4. Involve the business units—Due to the tightening of budgets, the PMO had to prioritize projects and justify their value to the organization. The best way to do this was to involve the business units. This included the formation of a portfolio review board that included senior management representation from each of the business units. The board makes decisions regarding work prioritization and the allocation of financial and human resources. This resulted in a shared ownership and accountability for the IT portfolio.
5. Integrate with financial management—Unfortunately, to some degree project management still took place in a vacuum. Therefore, it was important that each project budget be integrated with financial management. The PMO began tracking project costs and comparing them with the planned budget. This was accomplished through the use of project codes.
6. Decentralize project management—In terms of plan accuracy and decision-making effectiveness, the PMO was still viewed with skepticism even after two years since its inception. Therefore, a decision was made to decentralize some of the project management processes such as time reporting. As Morris says, “That has a few key advantages. To be able to report on work, the work had to be planned. You can then track how good you are at making estimates versus actual.”
7. Simplify project management—As management of the project portfolio becomes more broadly distributed, it becomes accessible to more individuals. For example, Primavera Methodology Manager® allows for consistent and simplified planning for lower level projects. According to Morris, “We built a series of templates that ask questions and, based on the answer, construct a plan. Users don’t have to apply codes and resources, they just use the Methodology Manager and validate the data.”

Two factors were critical for Agere’s ability to transform IT project management. The first was unwavering support of multiple senior managers. The second was an effective project management solution. As Morris states, “Primavera® provided the only tool with the complete functionality we needed. This includes the ability to operate across all Agere locations, the ability for multiple users to work with a project plan simultaneously, and robust, role-based security.” In addition, Morris believes Primavera® provided some tangible benefits, “The biggest benefit was the ability to reduce our budget. We could not have gone from a $270 million to a $94 million budget in 18 months without the ability to understand what our project load is and where our resources are.” A recent analysis of the 11 largest projects indicated that all were on time and within budget.

1. How is managing IT projects from a project portfolio view different from a single-project view? What are the advantages? What are some challenges?
2. With a tightening of budgets for IT projects, what was the significance of Agere involving the business units in making decisions about work prioritization and resource allocation?
3. Chris Morris believes that Agere will view project management the way IT sees it: as a core competency. Do you believe project management should be a core competency for most organizations?
4. Should all projects be planned using a project management software tool?

Adapted from Eric Shoeniger, From Chaos to Competency, Projects@Work, June 17, 2004.
Poor Baseline Plans Lead to Federal Waste of IT

According to a survey of 104 U.S. government IT executives, an estimated $12 billion dollars was wasted on IT projects in 2007. The study, called A Cracked Foundation, was conducted by Price Systems, a provider of program affordability management solutions.

The study suggests that 46 percent of the failed (cancelled, over-budget) projects could have been avoided if project baseline plans were more realistic, thus saving an estimated $5.5 billion annually. According to Larry Reagan, a vice president at Price Systems, “Agencies require stronger foundations upon which to base government IT program structures in order to avoid the continued rate of collapse. Better baselines can help fill in these structural cracks—arming agency personnel with the tools, training, and historical data necessary to build projects on solid rock.” The study found that only 18 percent of the government IT executives expressed confidence in their IT budgets, with about 69 percent reporting that they usually begin to notice problems about halfway through their projects.

In addition, the study also reports:

* Seventy-eight percent believe they have inadequate cost estimating training.
* Seventy-seven percent believe they have inadequate risk identification and management training.
* Seventy-three percent believe they have inadequate initial baseline development training.
* Sixty-seven percent believe they have inadequate project management training.
* Sixty percent believe they do not have the necessary methodologies to collect historical data to produce realistic estimates when a baseline changes.
* Fifty-eight percent believe they do not have the necessary historical data to produce realistic estimates.
* Fifty-four percent believe that they have inadequate tools to manage the cost estimating, control, and reporting processes for IT programs.

The respondents contend that the main reasons why projects are over budget include poor project management, scope creep, the lack of proper baselines, and late understanding of risk. Moreover, the IT executives surveyed reported that the most important tool for ensuring that IT projects are on budget is a fully coordinated baseline, followed by training, project management tools, and defined risk management.

Similarly, the IT executives identified schedule management, cost management, and risk management as being the most challenging baseline elements for their organizations. The study also reports why project managers fail to establish effective baselines. More specifically, 64 percent attributed this to a lack of personnel to perform the functions effectively, 47 percent stated a lack of training, 47 percent stated that timelines were too short, and 34 percent claimed that projects teams were not given appropriate tools and data for establishing accurate baseline plans up front.

Reagan claims, “In these days of heightened federal fiscal accountability, our government is not in a position to waste billions of dollars that could be redirected toward any number of programs. Supported by stronger structural foundations—including assigning responsibility for program affordability management; integrating cost estimating, project control, and knowledge management into a single team; providing effective training and certification; implementing a methodology for regularly scheduled, independent baseline reviews; and establishing the consistent use of a resusable knowledge-based framework—better baselines can empower agencies to achieve project and program objectives, effectively enabling them to better deliver upon their missions.”

1. Do you agree that improving IT project baseline plans will help avoid failed projects?
2. Consider Larry Reagan’s statement in the last paragraph. Do you agree with his assessment? Is there anything you would add that could be done to improve project success, not only for the federal government but for any type of organization?

SOURCE: Adapted from:

Larry Reagan, A Cracked Foundation: A Critical Look at the Role of Baselining in Government IT Project Management.

Vice President—Government Solutions, and Robert W. Young—Executive Director, Price Systems, Poor Baselines Cause of Federal IT Waste, Study Finds, Projects@Work, November 30, 2006.
Bibliography

Goldratt, E. M. 1997. Critical Chain. Great Barrington, MA: The North River Press.

Haugan, G. T. 2002. Project Planning and Scheduling. Vienna, VA: Management Concepts.

Kinsella, S. M. 2002. Activity-Based Costing: Does It Warrant Inclusion in A Guide to the Project Management Body of Knowledge (PMBOK Guide)? Project Management Journal 33(2): 49–55.

Project Management Institute (PMI) 2004. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square, PA: PMI Publishing.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License