ep 15

Buffering the Project EXAMPLE 15-2 pg 520

Buffering the Project When managers are asked to submit estimates of task durations for project planning, they sometimes build in extra time (a buffer) "just to be safe." For example, if a manager expects that a task may take four days, he might tell his boss five days (have you ever done this?). However, because these buffers are hidden from the project manager, they often are wasted in terms of helping complete projects on time. A more useful approach is to design buffers into the project plan, making them plain for everyone on the project to see and utilize. A project buffer is simply a designated time period that provides some slack along paths that are critical or highly variable.

There are other, more strategic, reasons to select and include projects in the portfolio. Projects can be viewed as opportunities to learn new things, to build technical capabilities, to develop new partnerships, and to identify the strengths and weaknesses of people in the organization. Projects can also be designed to build upon previous successes or failures in order to move the organization toward long-term strategic goals. In general, managers should evaluate potential new projects by considering three categories of factors:

1. The project's fit with overall organizational strategy and existing portfolio of projects. 2. Financial returns or other benefits associated with the project. 3. The feasibility of the project, including availability of required resources.

define project and project management

A project is a one-time or infrequently occurring set of activities that creates outputs within prespecified time and cost schedules, project management while project management is the combination of planning, directing, and controlling resources (people, equipment, information, material) in a project to meet technical objectives within budget and schedule constraints.

see figure 15-1

As Figure 15-1 indicates, these outcomes usually conflict with one another. A general maxim in project management is, "faster, better, or cheaper; you can have two, but not three." This means that once a project has been planned and resources have been allocated, changes to the budget, schedule, and deliverables require trade-offs. For example, if management wants to reduce the project budget and speed up the schedule, then they must reduce either the quality or the scope of deliverables for the project. On the other hand, by changing the technologies used to execute the project, or by changing how project activities are defined, project managers can sometimes achieve improvements in all three areas.

Initial estimates of task durations are often made assuming certain resource availabilities, without a clear understanding of the schedule. Parallel activities can create overlapping and conflicting resource requirements at certain points in time. For this reason, managers need to evaluate the scheduled requirements and find solutions for resource conflicts. Important resources could include people (skill types), materials, technology (equipment), and capital (cash). Some useful questions to ask are:

• Are resources available in the windows of time identified by the schedule? • Is the same resource required on parallel paths? • Is a resource frequently used only a little at a time (e.g., part-time need for an electrician at multiple stages)? • Should resources be dedicated full-time or part-time?

project definition Project definition starts with the initial idea for the project. The definition is refined as the business case for the project is developed and evaluated and eventually selected and funded. • In the early stages of project definition, it is very important to clarify who are the clients or customers for the project, • and what they care most about. Too often, project personnel assume they know what the customer wants. Even when they do ask the customer, they may not dig deep enough to uncover unexpressed needs that are at the heart of a customer's requirements. A useful approach is to define a project using a concise project objective statement that includes the following contents:

• Scope and major deliverables—desired results, milestones, documents, products. • Schedule—start and end dates. • Resources required—dollars, person-months, special needs (equipment, skills, etc.).

Using these definitions, projects sound a lot like other operational processes discussed in this book, so why do we need a chapter dedicated to project management? There are several specific characteristics of projects that make them particularly challenging to manage:

• Every project is unique, having a planned beginning and end. Most business organizations are designed to efficiently manage repetitive, ongoing activities. Projects are not routine; they are used to manage change. Therefore, they require different management techniques. • Most projects are multidisciplinary, involving many functional specialists who contribute to the overall project goals. The tasks that these specialists perform are interdependent, and because the project is a one-time set of activities, these interdependencies aren't always clearly understood. Imagine, for example, all of the complex relationships between tasks required to design an entirely new car using cutting-edge technologies. • Projects are often staffed with people who are temporarily taken from functional groups (such as finance, operations, marketing, engineering, supply management) that perform routine operations. Along with expertise, these people have their own functional points of view, and they may feel more loyalty to their functional homes than to the project. • Projects often compete with routine operations or with other projects for resources and personnel. For this reason, projects often involve a good deal of conflict among project team members. Because a project is usually a one-time event, it does not usually have the same degree of certainty or repeatability that routine operations do. So it is up to the project manager and her team to anticipate and plan ways to deal with all of the issues mentioned above. Although many operations management concepts may be applied to projects, there are special tools for planning, coordinating, and controlling project activities. This chapter describes these tools and discusses factors that drive project success.

Detailed Scheduling Using the Critical Path Method

Detailed Scheduling Using the Critical Path Method Once the overall budget and time estimates for tasks have been established, a detailed schedule can be created. A useful way to plan and communicate schedules is the critical path method (CPM). The Get Real box next page describes the historical origins of this method. Critical path scheduling techniques- display a project in graphic form in a way that identifies the activities that are most important and should receive focused attention. Critical path scheduling is based on several key assumptions: 1. The project tasks have well-defined beginnings and endings. 2. The tasks are independent; the duration of one task is not dependent on the duration of another. 3. A required sequence of the tasks can be established. For small projects, a formal schedule may be unnecessary; a simple check list may be sufficient. For larger projects, however, a special set of scheduling tools can clarify planning and help ensure that tasks are completed in the proper sequence. One such tool is a network diagram. A network diagram - is constructed using the task definitions, estimated lengths, and precedence relationships (the definition of what has to come first, second, and so on).

Establishing a Project Charter

Establishing a Project Charter An excellent way to summarize the project definition and organizational design is by means of a project charter. A project charter-- can be thought of as a contract that signals the authority to launch a project. Many examples of project charters can be found through an Internet search of the term "project charter." A good charter includes several key elements. First, it concisely defines the purpose of the project and establishes its role and priority in the overall project portfolio. It describes the customers, project team members, and other key stakeholders in the project, along with their roles. Finally, it presents the budget, high-level schedule, and major deliverables for the project. A charter serves an important role in establishing the initial plan for the project. As the project unfolds and new opportunities or problems arise, proposed changes to the project must be compared with the project scope as specified in the original charter. Without this sort of initial anchoring documentation, it is easy for a project to turn into something that was never originally intended. Also, by reading and signing the charter, team members understand their roles in achieving the project goals.

Organizing the Project: Pure, Functional, and Matrix Projects Most of the time, projects are planned and executed within an established organization. However, the project manager must organize the specific project team to maximize its potential for success. Projects typically fall along a spectrum of organizational forms, anchored by three specific types: functional project, pure project, and matrix project.

Functional Project A functional project is housed and controlled within a single functional department during each project stage. Imagine, for example, a product development project in which the marketing function makes all of its promotional plans and inputs, then the engineering department creates all of the product designs, then the operations department establishes all of the process plans needed to deliver the product. At each stage of the project, a different function controls the activities and the budget for the project. Once the activities by one function are completed, the project is handed off to the next function. Pure A pure (autonomous) project is housed outside the normal functional departments in the business. The project team is made up of functional representatives that are fully dedicated to the project for the duration of the project's life. A pure project has a single project manager who is responsible for the budget, schedule, and all project activities. Consider, for example, a product development effort in which marketing, engineering, and operations personnel are all colocated and work together to simultaneously develop product promotional plans, product designs, and product process designs. (pg 508) Table 15-1 lists the advantages and disadvantages of each of the project types. Efficiency is the primary advantage of a functional project approach because the project does not disrupt the existing organizational structure. A disadvantage is that project team members often have other job responsibilities, so the project may not receive top priority. This approach is appropriate for projects where the majority of work is in one specific function, little cross-functional integration is needed, and project leadership can be handled via the normal chain of command. The functional approach is mainly useful for incremental, fairly routine projects. On the other hand, if various project activities requiring different functional expertise are interdependent, then a pure project can be much more effective. A pure project structure allows team members from each function to work together to solve problems faster and better. A major disadvantage to a pure project is its cost. Personnel dedicate 100 percent of their time to the project, though they may not always be needed at this level. Also, colocation and reorganization costs can be high. The pure project approach is best when: • Speed is crucial. • The project includes complex or uncertain tasks. • Resource cost is not a tight constraint. • Innovation is needed. • Page 509 • Managers want to shield the project from organizational influences. • A high degree of team commitment is needed. Matrix approach The matrix project approach is probably the most commonly used organizational structure because it balances the advantages and disadvantages of the functional and pure project types. A matrix project utilizes people from different functional areas who are "loaned" to the project from time to time. A full-time project manager plans the project's tasks and schedules, while functional managers determine which people and technologies are used. This approach is appropriate when organizations cannot afford to tie up critical resources on a single project, and when efficient use of resources (cost) is important. From a team member's perspective, the matrix approach can be quite stressful. He or she must balance the requirements of working on several projects at once and working for several managers at the same time. Because of the conflicts that are inherent in the matrix project structure, the stature of the project manager within the organization is critical to the project's success. A "heavyweight" project manager gets the resources and priorities that the project needs by virtue of his ability to influence the functional managers who control the resources. Matrix projects with weak project managers are not likely to succeed.

Globally Dispersed Project Teams

Globally Dispersed Project Teams Throughout this book we have discussed the increasing roles of outsourcing and low-cost country suppliers. Due to these trends, project teams increasingly involve members in different companies and in different locations around the world. For example, a software development project initiated by a U.S. company might involve programmers and design personnel in India and other parts of the world. Managing such globally dispersed project teams involves unique challenges. Cultural, organizational, and technological barriers must often be overcome in order meet project goals. In addition to the obvious challenges associated with team members who speak different languages, one of the biggest cultural barriers involves a reluctance of personnel in one company or location to share information or ask for help from personnel in other companies or locations. Often, this reluctance stems either from an unwillingness to trust project partners, or from the "not invented here" syndrome, which discounts the value of ideas that are not homegrown. The project manager must try to instill in the project team members a longer-term perspective that shifts the focus away from short-term gains and win-lose thinking that can impede project progress. At the same time, it is imperative that the team at the center of the project does not force its culture and perspectives on its project partners. The value of collaboration in projects comes from diversity in culture, perspectives, and skills, not from similarities. Training programs can help members of all companies involved to appreciate their differences, especially when constituents represent different national cultures, languages, and work norms. In addition, a focus and priority placed on project goals and customer satisfaction can help personnel overcome barriers due to cultural differences. Organizational boundaries sometimes stifle globally dispersed projects. Even if partners trust each other and are culturally compatible, stiff hierarchies and long lines of communication can prevent the collaboration from being as effective as it could be. Companies sometimes have strict guidelines regarding who can talk to whom in order to ensure that secrets are kept and that organizational hierarchies are respected. The consequence is that project details may be lost, leading to mistakes, incorrect assumptions, and project delays. Project managers need to ensure that team members establish appropriate working contacts in all functional areas across the respective organizational structures. Page 511 Finally, physical and temporal boundaries can pose difficulties in managing globally dispersed projects. The ability to use 24/7 project operations(where groups in one time zone work while groups in other time zones sleep) is one of the potential benefits that entices firms to pick project partners located in distant locations. However, project managers need to develop the systems for effectively passing work back and forth. Information technologies have come a long way in establishing systems to enable secure and accurate knowledge transfer. In addition, video conferencing and other communication technologies offer some of the benefits of face-to-face communications. Managers of globally dispersed projects need to make sure that different information systems talk to each other and that everyone on the team knows where to go to get questions answered.

MANAGING A PORTFOLIO OF PROJECTS see figure 15-9

Large organizations typically have many projects going on at the same time, at many locations across the supply chain. A business development unit, for example, could be developing several new products simultaneously. Supply chain managers typically have many process improvement and relationship management projects going on, potentially involving product suppliers, customers, consultants, and technology vendors. It is important for managers to view such a mix of projects as a portfolio of efforts that are used to execute the organization's overall strategy. Each project's unique contribution to the overall goals of the business unit should be clearly established. Too often in businesses, projects are not managed strategically. Team members on various projects often do not understand how projects relate to one another and to the business strategy. There are many reasons for this. A primary cause is that often the criteria used to select projects are not consistent with higher-level business goals. For example, projects are often selected using financial criteria alone. Figure 15-9 shows a mix of projects positioned according to their probability of success (risk) and value if successful (contribution). If these were the only important criteria, then we would select only projects that are in the upper right-hand quadrant of the figure.

Analyzing Resources and Trade-Offs

Once an initial project schedule is created, project managers review the resource requirements implied by the schedule to see if they are compatible with project constraints and goals. If a specific resource for a critical path activity is not available during the scheduled time period, the delay affects the entire project. For example, suppose that the "Populate System Data" task in Figure 15-6 is assigned to the marketing department, yet they will not have personnel available to work on this task until Friday, November 10. The project will be completed two days late, assuming nothing else changes. As another example, suppose that the person who is given the task of "Select System Modules" is also given the task of "Prepare Data." Because "Select System Modules" is a critical activity, the person will do that task first, taking nine days. Unfortunately, this means that the "Prepare Data" task will be completed late (because it has only seven days of slack). The start of "Populate System Data" will be postponed by two days, and again the project will be completed two days late, assuming nothing else changes.

pg 511 Work Break down structure see figure 15-3

Once the major elements of a project are defined and approved, the project management team can begin detailed planning by developing a work breakdown structure (WBS). As shown in Figure 15-3, the WBS - is a hierarchical listing of project activities. This particular project is designed to install a new supply chain planning system software program. The project includes steps needed to tailor the design of the software to the specific company's needs, to make adjustments to data that will be used in the system, to train the users and prepare user manuals, and to solve problems once the system is initiated (system rollout). While this is a fairly small project, a larger WBS hierarchy might include many levels, including tasks and subtasks, that are ultimately broken down to the lowest-level tasks, known as work packages

Planning for Uncertainty Up to this point we have assumed that estimates of task durations are fixed and accurate. In reality, it can be very difficult to accurately estimate durations, especially when tasks are new or when they are dependent on circumstances outside the control of the project team. In this section we will discuss three tools for managing uncertainty in projects: probabilistic estimates, buffering, and risk analysis. Probabilistic Task Duration Estimates

Probabilistic Task Duration Estimates One method for analyzing the impacts of uncertainty on projects is to use probabilistic task duration estimates,- which include a range of possible task durations for each task, rather than relying on a single point estimate. "Best case," "worst case," and "most likely case" durations are estimated for each task in the project. By making some assumptions about the statistical properties of these estimates, project analysts can create distributions of possible outcomes for each project task, and ultimately for the project as a whole. Instead of simply expecting the project to be completed on a certain date, the project manager can use this new statistical information to estimate the probability that the project will be completed on or before a given date. If the probability of completion by a given deadline is unacceptably low, then the manager can using project crashing, buffering, or other techniques to improve the project's chances of on-time completion. The calculations for probabilistic task duration estimations are illustrated in the supplement to this chapter.

PROJECT COMPLETION postproject review

Project completion occurs when all project deliverables have been completed to the satisfaction of the client, sponsor, and other decision makers with acceptance authority. Project managers should make sure that project team members stay motivated at this stage, as it is easy for them to experience burnout, or to start turning their attention to other projects prematurely. It is usually a good idea to hold reviews of all activities, with checklists and other reports to make sure that no final deliverables are missed. post project review Immediately after project completion is also the best time to evaluate the key successes and failures of the project. This activity is commonly known as a postproject review (also called a postmortem). Ideally, an independent team should review the project and develop a detailed report of lessons learned. This team is not to second-guess or place blame, but to identify both effective and ineffective practices that can be compared against other project reviews. This will help ensure that the good practices are repeated and that the weaker practices are corrected in future projects. In addition, the postproject review can be the time to recognize the contributions of project team members and to highlight the success of the project to executives throughout the organization. Points to be addressed in a postproject review include: • How well were deliverables met in terms of scope, quality, and dealing with changes throughout the project? • How well was the project budget met? Where were the important variances? • Was the project on time? What were the constraining resources? • Have all remaining project tasks been completed? Have results been communicated to all important stakeholders? • Is the customer happy? How has this project affected our relationships with customers? • Are the project team members satisfied? What specific morale issues need to be addressed? In what ways were employees' skills and knowledge enhanced? • What problems were solved on this project? What new market or technical knowledge needs to be documented and used in future projects? • What was learned regarding new management approaches or use of new project management technologies (organizational approach, software, information systems, and so on).

PROJECT EXECUTION grant chart

Project execution is the phase in which the project work is actually done. At this point, the project manager plays the important roles of encouraging, monitoring, and controlling performance. For small projects, performance monitoring can be fairly informal; the project manager can frequently speak with each of the project team members. In larger projects, however, it is important to determine the levels of reporting frequency and formality that project managers will require. This is often a question of balance. Managers don't want project team members to be so busy preparing status reports that they never get any work done. On the other hand, more frequent reports give managers a more up-to-date picture of the project's status. One way to achieve balance is for project managers to give most of their attention to critical path activities, and less to others, unless they are particularly risky. For example, a large project might require weekly reports from owners of critical path activities, and only monthly reports from owners of noncritical activities. It is also especially important to get regular status updates early on in the project. Research shows that early budget and schedule performance are strong predictors of the ultimate completed project performance. Page 522 Status reports should contain updates on budget, schedule, and the quality of output. Though many more sophisticated reporting formats exist, a common and simple way to communicate schedule status is through use of a bar chart (also known as a Gantt chart) showing percentage completion for each activity. Figure 15-8 displays an example of an MS Project bar chart. Note that the dark line through the center of any task bar indicates the percentage that the task is complete. For example, task 2, "Prepare Data," is 50 percent complete. "Select System Protocols" (task 12) has been completed entirely. "Populate System Data" awaits the completion of "Prepare Data" before it can star

Making Time-Cost-Scope Trade-Offs

Remember the "faster-better-cheaper" trade-off discussed earlier in the chapter? If resource conflicts exist in the schedule, or if the current plan exceeds the budget or schedule requirements, changes to the plan may be required. Suppose that the current plan exceeds the available budget for the project. A simple change would be to reduce the scope of activities and eliminate some of the deliverables for the project. If that is not an option, the project managers often make trade-offs between budget (cost) and schedule (time). Suppose that current project activities are running late, or that the client has moved up the due date so that the current plan no longer meets the required deadline. In either case, more money could be spent to hasten project activities to meet the required completion date. In project management terminology, speeding up an activity is known as crashing the activity. When many activities are crashable, the decision regarding exactly which activities to crash can be complicated. However, by following a simple set of rules the project manager can usually find the lowest cost way to speed up a project in order to meet its deadline. The supplement for this chapter illustrates the procedure for crashing projects in detail.

Risk Analysis see table 15-3

Risk analysis is an important thing to do early on in project definition, at the development of the WBS, and after a detailed schedule is created. Project managers should always consider "Murphy's Law: What can go wrong, will go wrong!" There are numerous tools available for assessing project risk. A simple risk analysis technique5 involves several steps: • Step 1: Hold a team brainstorming session to identify the possible risks associated with technologies, resources of all kinds, markets and customers, and competitors. • Step 2: Establish the probability that each risk event will occur. • Step 3: Establish the potential impacts of each risk event on the budget, schedule, and deliverables of the project. • Step 4: Determine plans for dealing with the risk events that are of highest probability and impact. Risk mitigation plans could include: • Preventive measures • Contingency plans • Emergency funds • Time buffers • Step 5: Select the risk mitigation plans that give the best prevention or protection against risk for the minimum investment required. The final steps of this analysis can be communicated as a risk table. An example of a risk table is shown in Table 15-3. In addition to the steps above, the risk planning team should establish a signal or metric that determines the circumstances under which a contingency or risk mitigation plan should be invoked. These "triggers" establish concrete decision points for the project team. For example, the team might decide that they would rent snowmaking machines once filming had been delayed by one week. Risk assessment is typically one of the most important, and most neglected, activities in project management.

Selecting a Project Manager

Selecting a Project Manager Project managers need to have both technical and social skills. Good project managers typically have many of the following traits: • A leader, an enthusiastic influencer of people. • A clear and sometimes forceful communicator. • A good time manager who is self-motivated. • A high tolerance for ambiguity and stress. • Politically astute and well-connected with the customer and with important people in the organization. • Capable of understanding critical technical details of the project, including issues from different disciplines and functional areas. • Has high ethical standards. A project manager has to be both a generalist and a specialist. Good project managers can identify the most important schedule, technical, and resource-related details while not losing sight of the overall goals of the project and how they fit into the overall business strategy. They can speak the various "languages" of executives, technical personnel, and customers. How does a person become an excellent project manager? Experience is the best teacher. However, because projects occur irregularly in many organizations, project management is sometimes referred to as the "accidental profession." Training, disciplined work on areas of weakness, and a wide variety of experiences in different functional areas of the firm are helpful in giving the project manager a broader view, along with the opportunity to build relationships across the organization. Informal relationships with key resource managers are invaluable to project managers. Training programs offered by companies and by societies such as the Project Management Institute can also be helpful (www.pmi.org). Selecting a project manager for a given project can be tricky. Many times the "perfect" person isn't available or doesn't exist. Good project managers are a rare commodity. Usually the stature of the project manager should match the priority and importance of the project. Major projects should be led by top executives, whereas small projects provide a good training ground for junior managers. Sometimes it is useful to match the personal characteristics of the manager with those of the project. For example, the development of a new technology is best led by someone with an advanced technical background, coupled with a strong understanding of business strategy. It is important to create a profile of all of the technical and social factors that might be important for a given project so that a manager who best fits the profile can be identified.

Stages in the Life of a Project Figure 15-2 (see figure)

Stages in the Life of a Project Figure 15-2 shows the stages in the life of a typical project, along with the level of resources typically required in each stage. Early project definition and planning activities may involve only a few people relative to the large number of personnel and other resources required in the execution of the project. However, the definition and planning stages are critical, because they define how the execution and completion stages will be done. Though the project life profile shown in Figure 15-2 is "typical," not all projects follow this profile strictly. For example, new product development projects often have early testing and prototyping stages that precede the full-scale execution of the project. Many projects are characterized by numerous starts and stops. Sometimes projects are killed in early stages or even in the midst of execution. As business needs, technologies, and environmental conditions change, the definition, scope, and execution of projects changes, too. Because many of the project success factors discussed above are established in the early planning stages of a project, a project manager usually has the greatest influence on the success of the project in the planning stage. Once a project has been defined and planned, many of the potential outcomes of the project have been set. Once a project is under way, it is often difficult to make major changes. For this reason, most of this chapter focuses on project definition and planning activities.

Table 15-2 and 15-5 see example 15-1 516

Table 15-2 shows project information for the planning system installation project. Figure 15-5 shows a network diagram for the planning system installation project. Each circle (or node) represents a task, and the arrows connecting the tasks show the precedence relationships among them. A parallel relationship between two tasks means that they can be performed simultaneously. For example, when building a house, one crew can landscape the yard at the same time that another crew installs the light fixtures indoors. On the other hand, sequential activities depend on each other—pouring the concrete for the foundation of a house cannot be done until the site excavation is completed. Such sequential and parallel relationships are indicated in Figure 15-5 as well. For example, the start of "Debug System" must follow the completion of "Test System." However, the start of "Prepare Documentation" is not dependent on the start or completion of "Set System Protocols," so parts of these two tasks could be done simultaneously. It is important for every project to have a single starting point and a single ending point. The "Start" activity at the left end of the project consumes zero days because it is simply a node that indicates the proposed start date of the project. Page 517 The latest start date and latest finish date for any task are computed by adding the task slack to the earliest start and earliest completion dates possible for the task. Another way to compute the latest start and completion dates for all the tasks in the project network is to make a backward pass analysis. The backward pass is done by starting with the project completion date (defined by the critical path), and then subtracting the task times from right to left along the paths in the network.

Practice using these equations to verify the numbers shown in Figure 15-5. Another detailed example of how to use these equations is provided in the solved problem at the end of the chapter.

The information detailing the critical activities, earliest and latest starts and completions, and task slack helps project managers know where to focus their attention, and how much flexibility they have in scheduling noncritical tasks. Frequently re-analyzing a project in this way as tasks are completed helps project managers more effectively allocate resources. For example, if a critical task is completed late, then a manager might decide to move resources from a noncritical activity to other activities on the critical path in order to get the project back on schedule. Figure 15-6 shows how the planning system implementation project network diagram looks when it is created using Microsoft Project, a widely used project management software program. In Figure 15-6, each box (or node) represents an activity. Each box contains the task slack, the earliest start and earliest complete dates, and the estimated duration of the task. Note that a tool such as this can automatically calculate calendar dates, accounting for weekends and holidays. Figure 15-6 shows that, assuming no work is done on weekends, the estimated completion date is Monday, December 4. Since many project managers use software programs like this one to manage project information, we will use this format for the rest of the examples in this chapter.

example figure 15-1

Think about all the activities involved in building a home. Can you identify a new technology that has enabled this type of project to be completed faster, better, and cheaper? On December 17, 2002, Shelby County Habitat for Humanity built a house in 3 hours, 26 minutes, and 34 seconds—breaking the previous record of 3 hours, 44 minutes, and 59 seconds. Go to any Internet search site and type "World's Fastest House." You will find a short video that shows the project through a time-lapse sequence. Imagine the project management work needed to set up and execute such an event!

project objective statement

project objective statement : The identification of project deliverables, schedule, and resources in specific, concise, clear, measurable terms. A good project objective statement contains all of these issues in specific, concise, clear, measurable terms. Consider the following example: • "we will put a man on the moon and return him safely to earth by the end of the decade, at a cost of less than $10B. o Defining a project in this way has several advantages. 1. First, stating things clearly and concisely creates a strong vision and challenge for the project team members 2. . Second, it establishes a baseline for detailed activities needed to achieve this overall objective, and those that should not be included. This list of activities should be reviewed with the customer to ensure that the expected deliverables can be achieved. For example, suppose your company is hired to produce a movie from a given screenplay within six months and at a cost of no more than $30 million. Does this include hiring of the actors? Promotion of the movie? In order to avoid surprises, your team must work with customers in determining all the deliverables associated with this objective statement.

Once the time and cost estimates have been produced, the planning team makes initial adjustments based on overall budget and schedule constraints. Figure 15-4 shows a cost-allocated WBS for the planning system project introduced in Figure 15-3. The costs for project tasks are usually initially estimated by work package managers, and then added up to compute the costs for the major tasks and for the project as a whole. Then, adjustments and reallocations are made if the costs do not meet budget limitations or expectations. There may be some negotiations between project managers and customers, or between managers of major tasks in the project in order to arrive at an overall resource allocation that is reasonable and achievable. Managers typically use a combination of cost data from past similar projects and detailed resource analyses to make their cost estimates.

see figure 15-4

technology factors and social factors what are factors that will contribute to to project success?

technology factor Systems, equipment, and processes that define how project work is done social factors Project team culture, norms of behavior, values, enthusiasm, experience, authority, and influence of team members. In practice, there are many technological factors that make projects more or less successful. Think of technologies as including all "ways of doing things." Hard technologies • including equipment, facilities, computers, and communications systems help project team members to execute tasks more quickly, more cheaply, and with better quality. In addition, soft technologies including • decision support and planning software, information systems, organizational structure, and measures and reward systems can be very important contributors to success. Sometimes operations managers tend to focus on these technical factors. However, research has shown that social factors are often of equal or even greater importance to the success of projects. Social factors include the project team culture, norms of behavior, values, enthusiasm, experience, authority, and influence of team members. Project managers need to pay close attention to both the technical and the social aspects of their projects. The following list contains factors that are generally acknowledged to be important contributors to project success: • A vision of project objectives that is clearly communicated and widely understood. • A committed, talented, and well-connected project leader. • Sufficient resources and top management support for the project. • Disciplined procedures coupled with flexible project team members. • Team members who have a "winning" spirit.

Organizing Project Teams What makes a good project team? The following list provides some of the best practices identified in research for creating high-performance project teams.

• Break the overall project group into teams, each with less than 10 members. • Make sure that team members are committed; use volunteers if possible. • To the extent possible, ensure that team members serve on the project from beginning to end. • Try to get team members assigned full-time to the project, and have them report to only one boss. • Design teams such that all relevant functional areas and needed skills are represented on the team; this includes interpersonal skills and roles as well as technical skills. • Help the team members understand the importance of their team, and pick team leaders who foster cooperation and trust. • Colocate team members within conversational distance of each other. Though there is a wealth of research on this topic, it is still difficult to guarantee team success, even if all the "known" best practices are followed. Through preproject training, team members learn about the different roles they might play on the team. Training helps team members to learn how to handle conflict. Importantly, they can recognize their need to evolve quickly as a team member to become productive. By setting early milestones and deliverables, the project manager can encourage the team to coalesce into a productive working unit.

How Projects Succeed A "successful" project meets the following objectives

• Completed within budget. • Completed on time. • Deliverables meet the expectations of customers, project team members, and other stakeholders. Meeting "deliverables" objectives includes completion of the specific work outputs of the project, as well as achieving goals such as learning new lessons from the project, executing activities with minimal environmental impact, and other considerations.

When to Kill a Project Sometimes the best way to execute a project is to actually "execute" it, that is, to kill it. This can be a very difficult decision and process. Consequently, unhealthy projects are often allowed to persist for too long. Projects are often aggressive efforts that involve lots of uncertainty, and conditions that initially made the project attractive can quickly change. For this reason, it is important for project sponsors and managers to periodically gage the progress of a project from a strategic perspective. If a project is no longer expected to meet its objectives, it should be killed quickly to avoid wasted resources. There are many reasons to kill a project, including:

• Consistent budget or schedule overruns. This can be an indication that resource needs and costs were severely underestimated at the beginning of the project. Or perhaps conditions have changed so that inexpensive resources are no longer available. At some point rising costs may exceed the value of the project. • Page 523 • Failure to create value. Projects sometimes involve technical hurdles that just cannot be surmounted at a reasonable cost. On the other hand, the project may be meeting its objectives, but those objectives are no longer valuable. For example, suppose that a competitor introduces a new product that makes your new product project obsolete. Customers and clients may also change their minds about a project based on changing needs and market trends. • Changing priorities. Organizations change their priorities over time, and these changes may make a current project less attractive. For example, if a company falls on hard times financially, it may need to scrap projects that do not provide immediate benefits. In another case, a new project idea may come along that is actually more important or gives a better return than the current project. In this case it would be prudent to kill the current project and shift the resources to the new opportunity. • Wrong resources. Perhaps the project idea still has merit, but the organization does not currently have the skills or talent needed to bring the project to a successful conclusion. Sometimes political forces come into play that stifle a project's progress. As some point it may be better to kill the current project and start again when proper resources and a unified commitment become available.

Project selection should be based on a business case-, a well-developed justification including both financial and strategic reasons for the project. A comprehensive business case includes:

• Financial and market analyses identifying required resources, costs, and benefits of the project. • Description of assumptions, risks, and how risks will be managed. • Importance of the project to the organization's strategic mission. Small projects may not require such a formal analysis, but some evaluation of benefits, costs, and risks should always precede the start of a project.

We can summarize all of these network relationships in the following equations, which make up the critical path algorithm:

• Forward pass: Calculating the earliest start and finish dates. • Earliest start date for a task = Maximum (latest) earliest finish date for all predecessors of that task (Earliest start date for tasks at the beginning of the network = 0) • Earliest finish date for a task = Earliest start + Task duration • Project completion date = Maximum (latest) earliest finish date for all tasks • Backward pass: Calculating the latest start and completion dates. • Latest finish date for a task = Minimum (earliest) latest start date for all followers of that task • Latest start date for a task = Latest finish date − Task duration • Calculating task slack: Task slack = Latest start date − Earliest start date, or latest finish date − Earliest finish date

Small projects may include only two or three levels in a WBS, whereas larger projects typically require many more levels of detail. The Get Real boxes in the chapter give an idea of the scope of work involved in huge projects such as staging the Olympics (see page 513) and expanding an airport (page 519). A work package defined at the lowest level of the WBS should have a measurable outcome that is assignable to a single individual or group. Responsibility for each work package should be unambiguous, and metrics should be clear. Here are some of the best practices for developing a WBS: Page 512 (Develop a WBS for a small project such as painting your parents' house. You might start by writing down each task on a sticky note. Then arrange the notes on a wall in a hierarchical (top-down) fashion. How can you ensure that you have not forgotten any tasks?)

• Involve all project leaders in developing the WBS. This will instill ownership and provide creativity. • Each work package should include a noun and a verb to imply action (e.g., "Meet with customers" rather than "Customers"). • As a rule of thumb, low-level tasks should be designed to be between 8 and 80 work hours in duration.3 • Include a risk analysis (discussed later in the chapter) at the WBS stage. • Include any and all activities that consume resources, including project planning and management activities. • Think hierarchically (top-down) or in a pure brainstorming mode. A hierarchical approach starts with major tasks and then identifies all subtasks related to each major category. A brainstorming approach allows for a rapid-fire listing of all activities that come to mind. • Don't worry about the sequencing or time-phasing of activities. Scheduling comes later. • A flexible and effective way to capture activities is to write them on sticky notes and paste them onto a wall. Then the notes can be reorganized to create the WBS hierarchy. • For complex projects, it may be helpful to have two separate teams develop WBSs independently. Then bring the teams together and compare results. The WBS can be used to estimate, allocate, and ultimately monitor resources for each of the work packages and major tasks in the project. The business case typically includes a preliminary budget based on rough cost estimates. The detailed WBS provides the framework for developing both time and cost estimates and for monitoring the progress of the project once activities begin. Usually time estimates are needed first, in order to then calculate the costs of needed workers, equipment, and so on. Time estimates can be based on similar projects when many have been completed. For example, in the construction industry an experienced estimator can forecast the time and the cost required to construct a building just by knowing the type of construction and the number of square feet of floor space. For really new projects, estimating is more difficult, and it is usually beneficial to have a team of people to develop estimates together.

In addition to monitoring the budget, schedule, and quality/scope conditions of an ongoing project, it is often important to monitor other key indicators of project progress and success. Sometimes project managers routinely estimate the financial returns of a project using metrics like net present value and return on investment. It is also important to frequently answer questions like:

• Is our customer happy? • Are the project sponsors/leaders still committed? • Are we overcoming technical hurdles and avoiding risks? • How is the project team's morale? • Do we have issues that are not being resolved? • Is the project receiving the resources that it needs? • Are we being socially responsible (safe and environmentally friendly)?