Components of a Project Charter

Chapter Objectives

• Describe the five project management processes and how they support each phase of the project life cycle.
• Define the project management knowledge area called project integration management and describe its role in project plan development, project plan execution, and overall change control.
• Develop a project charter and describe its relationship to the project plan.
• Identify the steps in the project planning framework introduced in this chapter and describe how this framework links the project's measurable organizational value (MOV) to the project's scope, schedule, and budget.

Source: Jack T. Marchewka, http://pabipedia.wikidot.com/developing-the-project-charter-baseline-project-plan
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Introduction

Up to this point, we have looked at IT project management from a very high or strategic level. The first phase of the IT project management methodology focuses on conceptualizing and initializing the project. The primary deliverable or work effort of this phase is the development of a business case. The business case defines the project's goal and value to the organization and includes an analysis and feasibility of several alternatives. Moreover, the business case plays an important role in the project selection process by providing sufficient, reliable information to senior management so that a decision whether the organization should support and fund the project can be made.

The basic question when conceptualizing and initializing the project is, What is the value of this project to the organization? Making the right decision is critical. Abandoning a project that will provide little real value to an organization at this early stage will save a great deal of time, money, and frustration. On the other hand, failure to fund a project that has a great deal of potential value is an opportunity lost.

The development of the business case and its subsequent approval represents closure for the first phase of the IT project methodology and the beginning of the next. This second phase, Develop the Project Charter and Plan, requires the planning, creating, review, and acceptance of another project deliverable before considerable time, resources, and energy are committed. This requires a subtle yet important transition from a strategic mindset to a more tactical one that integrates a number of subplans to identify, coordinate, authorize, manage, and control the project work.

These sub plans are separate plans for managing the project's scope, schedule, budget, quality, risk, and people. Together with the processes, methods, and tools defined in the project's methodology, all these areas come together to make up a project governance framework or project infrastructure. Unfortunately, the knowledge, tools, processes, and techniques required to develop a complete project plan cannot be presented in a single chapter. Therefore, the next several chapters will focus on human resources management, scope management, time management, cost management, and so forth that are integrated into a larger and more complete project plan.

Before we get to the details, this chapter provides an overview of the project planning process. This overview will include a more detailed discussion of the five project processes that were briefly introduced in Chapter 2 as part of the IT project methodology. More specifically, it explains how these processes are integrated with the various project management knowledge areas in order to support the development of the project's tactical plan. In fact, it will concentrate on one of the nine knowledge areas called project integration management.

The project charter and detailed project plan make up the project's tactical plan. The project charter defines the project infrastructure and identifies the project manager, the project team, the stakeholders, and the roles each will play within the project. In addition, the project charter formalizes the project's MOV, scope, supporting processes and controls, required resources, risks, and assumptions. This project infrastructure provides the foundation for developing a detailed project plan that answers four major questions: How much will the project cost? When will the project be finished? Who will be responsible for doing the work? And, what will we ultimately get at the end of the project?

In addition, a project planning framework will be introduced in this chapter that links the project's MOV to the project's scope, schedule, and budget. This framework outlines the steps necessary to create a detailed project plan so that management can determine whether the project's budget aligns with the cost analysis conducted in the business case. If the budget exceeds the overall cost envisioned in the business case, iterations to change the plan may be necessary to bring the project's scope, schedule, and budget in line. Cost cutting measures may require using less expensive resources or trade-offs in terms of reducing the scope and schedule. If the total cost of the project exceeds the expected organizational value, then the decision to cancel the project may be appropriate before more time, money, energy, and resources are committed to the next phase. However, once the project plan is approved, it then becomes the project's baseline plan that will be executed and used to benchmark actual progress.

Project Management Processes

The PMBOK Guide® defines a process as "a set of interrelated actions and activities that are performed to achieve a pre-specified set of products, results, or services". In other words, a process is something you do to achieve a result. It may involve some kind of input as well as directions, tools, or techniques to change the input to the desired output or result. For example, if you wanted to bake a cake, you would need specific inputs (ingredients such as flour, eggs, etc.), tools (oven, mixing bowls, mixer, etc.), and directions (a recipe). This whole process could be subdivided into subprocesses such as a mixing process, baking process, measuring process, and decorating process. If this was the first time you had baked a cake, you might follow the recipe directions to the letter in terms of mixing the ingredients and baking time. However, with experience you may experiment with the ingredients to produce a cake that is more to your liking and learn when the cake should come out of the oven - a little early or when it needs just another minute or two.

Quick Thinking - Creating a Project Management Culture

In many organizations, the project manager is held visibly accountable for ensuring that the project is delivered on time and within budget. In many cases, however, the project manager is not given any real authority over the project's resources. For example, many of the resources needed by the project manager may be controlled by several departments or business functions that will be released to the project on an as-needed basis. Without any formal authority, the project manager's power over these resources becomes de facto. The project manager's authority becomes pushed to the limit when the project team is distributed over multiple geographic locations. Many outsourcing projects face the same challenge.

In such cases, the project manager must rely on negotiation, persuasion, and team building, as well as the occasional use of threats or intimidation to make sure things get done. Supervisors or sponsors can fail to meet their project commitments and promises, but the project manager often is held accountable. This can be a challenge for even the most seasoned project managers. Inexperienced project managers often don't stand a chance.

These challenges require a cultural commitment to quality project management and delivery excellence. A project management culture is an environment where all of the project stakeholders share a commitment to the project's success and exhibit a healthy respect for the time and dollars spent on a project. Keane, Inc. developed six principles of productivity management for managing projects, regardless of project size or complexity. The six principles include:

1. Define the job in detail - The project manager must be able to draw a boundary around the project in order to define the personnel needed and their roles and responsibilities.
2. Get the right people involved - Project managers rarely get all the right people they need. Often the assignment of people to a project team is not a matter of their skill sets, but their availability. To overcome this issue, a project team must understand their responsibilities and assigned roles, but, more importantly, they must believe that the success of the project is in their best interests.
3. Estimate the time and costs - In many projects, someone provides a short description of the project and then asks, How much will it cost? And how long will it take? These questions are often answered without really understanding what the project is all about or what resources are available. Therefore, dialog is important for setting realistic expectations that include various risks that can impact the project's estimates.
4. Break the job down - The project can be broken down into smaller jobs, with each job defining an area of difficulty, uncertainty, or opportunity in a document called the statement of work (SOW). The SOW then becomes a critical component of the project management culture as it functions as a contract between the project sponsor and project manager that specifies all promises and commitments.
5. Establish a change procedure - This should include rules and guidelines for managing and funding changes. This principle also holds people accountable for changes made when promises documented in the SOW are not kept.
6. Agree on acceptance criteria - This principle focuses on rules and guidelines for accepting work products or deliverables throughout the project. This can help avoid unpleasant surprises along the way, and the final acceptance of a finished and successful project becomes straightforward.

1. How do the six principles help establish a project management culture in an organization?
2. How can a project charter help define a project manager's authority over resources not under his or her direct control?

Similarly, processes are an integral component of project management. They support all of the activities necessary to plan, create, and manage all of the project activities. Project management processes help initiate, plan, execute, monitor and control, and close a project as well as interact with the project management knowledge areas. In Chapter 2, for example, you were introduced to a project management process for developing a business case and another for developing a project's MOV. If you were a caterer hired to bake a wedding cake, project management processes would be needed to define, plan, estimate the cost, and deliver a cake that meets your customer's expectations, budget, and needs while being profitable for you.

On the other hand, product-oriented processes can be thought of as development processes that focus on the tangible results of the project. For an IT project, this would be all of the processes required to design, build, test, document, and implement an application system. Just like baking a cake, product-oriented processes require specific domain knowledge, tools, and techniques to complete the work. Otherwise, this could result in a poor cake or an information system that is a technical failure.

An emphasis or sole focus on project management processes does not provide an ability to develop a quality product, regardless of whether it is a cake or information system. However, focusing on the product-oriented processes may not provide the management or controls to ensure that the delivered cake or information system meets the expectations or needs of the intended customer or user. There must be a balance or harmony between project management processes and product-oriented processes in order to complete a project successfully. As one's experience grows, processes may not have to be applied the same way on all projects. The situation at hand will dictate the appropriateness of how each process should be applied.

Project Management Process Groups

Initiating

The initiating process group signals the beginning of the project or a phase. For example, an organization may initiate a project by requiring the development of a business case as part of its IT governance or as part of its IT project methodology. During this phase, a set of project management processes would define how the project and the first phase of the methodology should be initiated. The approval of the business case would then provide an authorization to start another set of processes to begin the second phase of the IT project methodology in order to develop the project charter and plan. Although all of the phases of the project should have some type of initiating process, the first phases of the IT project methodology would require the most detail and attention.

Planning

The planning process group supports planning of the entire project and each individual phase. Supporting project management processes may include scope planning, activity planning, resource planning, cost estimating, schedule estimating, and procurement planning. The planning process should be in line with the size and complexity of the project - that is, larger, more complex projects may require a greater planning effort than smaller, less complex projects. Planning processes are most important during the second phase of the IT project methodology when the project charter and plan are developed. However, planning processes can be important for each phase whereby objectives and activities may need to be defined or refined as new information becomes available. In addition, planning is often an iterative process. A project manager may develop a project plan, but senior management or the client may not approve the scope, budget, or schedule. Or circumstances may arise that warrant changes to the project plan. This could happen as the result of a competitor’s actions or legislation (external), or even changes to the project team or sponsor (internal).

Executing

Once a project phase has been approved and planned, the executing process group focuses on integrating people and resources to carry out the planned activities of the project plan or phase. During the execute and control phase of the IT project methodology, the product-oriented processes play an important role in developing the IT solution. For example, software engineering processes, tools, and methods for developing and/or implementing a system become critical for delivering the project’s end result. Project management processes such as quality assurance, risk management, and team development play an important supporting role. Although executing processes are part of every project phase, the majority of executing processes will occur during the execute and control phase of the IT project methodology.

Monitoring and Controlling

The monitoring and controlling process group allows for managing and measuring progress toward the project's MOV and scope, schedule, budget, and quality objectives. Monitoring and controlling processes also allow the project manager and team to measure and keep an eye on project variances between actual and planned results so that appropriate corrective actions can be taken when necessary. Supporting project management processes include scope control, change control, schedule control, budget control, quality control, and a communications plan. The emphasis of monitoring and controlling processes will occur during the execution and control phase of the IT project methodology.

Closing

The closing process group provides a set of processes for formally accepting the project's product, service, or end result so that the project or phase can be brought to an orderly close. The project manager or team must verify that all deliverables have been satisfactorily completed before the project sponsor accepts a phase's deliverable or the project's end product. Closure of a project may include processes for contract closure and administrative closure. Contract closure ensures that all of the deliverables and agreed upon terms of the project have been completed and delivered so that the project can end. It allows resources to be reassigned and settlement or payment of any account. Administrative closure, on the other hand, involves documenting and archiving all project documents. It also includes processes for evaluating the project in terms of whether it achieved its MOV. Lessons learned should be documented and made available to other teams. Although each phase must include closing processes, the major emphasis on closing processes will occur during the close project and evaluate project success phases of the IT project methodology.

Project Integration Management

The PMBOK Guide® views project integration management as one of the most important knowledge areas because it coordinates the other eight knowledge areas and all of the project management processes throughout the project life cycle. As Rita Mulcahy points out, it is the project team's responsibility to focus on completing the project work while the project sponsor should be protecting the project from unnecessary changes and loss of resources. However, the project manager or leader's role should be "to put all the pieces of the project together in a cohesive whole that gets the project done faster, cheaper, and with fewer resources while meeting project objectives". According to the PMBOK Guide®:

Integration, in the context of managing a project, is making choices about where to concentrate resources and effort on any given day, anticipating potential issues, dealing with these issues before they become critical, and coordinating work for the overall project good. The integration effort also involves making trade-offs among competing objectives and alternatives.

In many ways, integration is the job of the project manager. For example, let's say that you estimate that a database analyst assigned to your project will require two weeks to create a set of tables. However, right before the analyst is to begin her assigned task, she decides to take a job in another city. Your role as the project manager is to ensure that the project stays on track. This may entail recruiting another database analyst (human resource management), who will be paid a higher salary (cost management) and will now take four weeks (time management) to complete the assignment (Very few individuals are "plug and play". They will need time to assimilate in their new job and surroundings). Hopefully, their work will meet specific database design standards (quality management), but then this could all be overly optimistic (risk management). As you can see, project management processes and knowledge areas are interdependent. An experienced project manager knows there is no single way to manage a project. Project management knowledge, skills, and processes must be combined and applied in different ways in order to meet the project's goal and objectives.

Therefore, an understanding of the integrative nature of projects is especially critical in developing the project plan when all the knowledge areas and project and product-oriented processes must be brought together in order to produce a realistic and usable project plan. The PMBOK Guide® outlines seven processes for Project Integration Management:

1. Develop the project charter - The project charter is a document that formally authorizes the project and gives specific authority to the project manager to apply organizational resources to the project tasks or activities. In fact, the PMBOK Guide® stresses that a project cannot be started without a project charter. Although the project manager may not have been assigned when the business case was proposed, it is critical that he or she be named in the project charter.
2. Develop the preliminary scope statement - Think of the preliminary scope statement as the first iteration or draft of what the project must deliver. This may include project deliverables such as the project plan and the high-level features and functionality of the application system. The preliminary scope statement can be provided by the project sponsor or by having the project team interview key project stakeholders. At this point, the project team needs to "size" the project, i.e., is this a big project? Or a little project? Or something in between? Detailed features of the system (such as should the date be on the left or right hand side of the screen?) are not needed at this point. Those details will be specified when the project team completes the analysis of the detailed user requirements later on when implementing the SDLC. At this point, only enough detail is needed to plan the project activities in order to derive a project schedule and budget.
3. Develop the project management plan - The project management plan is a document that details how the project will be executed, monitored, controlled, and closed. Although the project plan may evolve and change over the course of the project life cycle, it becomes the day-to-day tool that outlines how the project goal and objectives will be met. All subsidiary plans such as a scope management plan, risk management plan, and communications plan are integrated into the project management plan.
4. Direct and manage project execution - The project manager accomplishes the project management plan by integrating all of the project processes into one coordinated effort. Here the project work is carried out to complete the project's scope.
5. Monitor and control project work - During the execution process, effort and resources will be expended to accomplish the project goal and objectives. Therefore, corrective actions may be necessary from time to time when the project's performance strays from the project management plan. On the other hand, preventive actions are sometimes necessary when the project team thinks or believes deviations from the project plan are likely. Corrective actions are reactive, while preventive actions are proactive. In addition, defect repair and rework may be necessary when project deliverables or processes do not meet quality standards.
6. Integrated change control - Change is inevitable during the entire project life cycle. Some approaches to project management and systems development embrace change, while other approaches may not embrace change as well. Regardless, change control processes must be in place so that all proposed changes can be documented, reviewed, and decided upon. Then corrective, preventive, or defect repairs can be made effectively and efficiently. In most circumstances, proposed changes will impact the project's scope, schedule, budget, and quality objectives. As a result, changes should be incorporated into the project management plan.
7. Close the project - As described in the previous section, this includes both administrative and contract closure procedures to ensure that closure is brought to the project or project phase. Regardless of whether a project ends as planned or prematurely, a project should be closed out using the close project process.

In the next section, you will learn how the project process groups and project integration knowledge area combine to create the project charter.

The Project Charter

The project charter and baseline project plan provide a project governance framework for carrying out or executing the IT project. More specifically, the project charter serves as an agreement or contract between the project sponsor and project team - documenting the project's MOV, defining its infrastructure, summarizing the project plan details, defining roles and responsibilities, showing project commitments, and explaining project control mechanisms.

• Documenting the project's MOV - Although the project's MOV was included in the business case, it is important that the MOV be clearly defined and agreed upon before developing or executing the project plan. At this point, the MOV must be cast in stone. Once agreed upon, the MOV for a project should not change. As you will see, the MOV drives the project planning process and is fundamental for all project-related decisions.
• Defining the project infrastructure - The project charter defines all of the people, resources, technology, methods, project management processes, and knowledge areas that are required to support the project. In short, the project charter will detail everything needed to carry out the project. Moreover, this infrastructure must not only be in place, but must also be taken into account when developing the project plan. For example, knowing who will be on the project team and what resources will be available to them can help the project manager estimate the amount of time a particular task or set of activities will require. It makes sense that a highly skilled and experienced team member with adequate resources should require less time to complete a certain task than an inexperienced person with inadequate resources. Keep in mind, however, that you can introduce risk to your project plan if you develop your estimates based upon the abilities of your best people. If one of these individuals should leave sometime during the project, you may have to replace them with someone less skilled or experienced. As a result, you will either have to revise your estimates or face the possibility of the project exceeding its deadline.
• Summarizing the details of the project plan - The project charter should summarize the scope, schedule, budget, quality objectives, deliverables, and milestones of the project. It should serve as an important communication tool that provides a consolidated source of information about the project that can be referenced throughout the project life cycle.
• Defining roles and responsibilities - The project charter should not only identify the project sponsor, project manager, and project team, but also when and how they will be involved throughout the project life cycle. In addition, the project charter should specify the lines of reporting and who will be responsible for specific decisions.
• Showing explicit commitment to the project - In addition to defining the roles and responsibilities of the various stakeholders, the project charter should detail the resources to be provided by the project sponsor and specify clearly who will take ownership of the project's product once the project is completed. Approval of the project charter gives the project team the formal authority to begin work on the project.
• Setting out project control mechanisms - Changes to the project's scope, schedule, and budget will undoubtedly be required over the course of the project. But, the project manager can lose control and the project team can lose its focus if these changes are not managed properly. Therefore, the project charter should outline a process for requesting and responding to proposed changes.

In general, the project charter and project plan should be developed together - the details of the project plan need to be summarized in the project charter, and the infrastructure outlined in the project charter will influence the estimates used in developing the project plan. It is the responsibility of the project manager to ensure that the project charter and plan are developed, agreed upon, and approved. Like the business case, the project charter and plan should be developed with both the project team and the project sponsor to ensure that the project will support the organization and that the goal and objective of the project are realistic and achievable.

What Should Be in a Project Charter?

The framework for a project charter should be based on the project management knowledge areas. Although the formality and depth of developing a project charter will most likely depend on the size and complexity of the project, the fundamental project management and product-development processes and areas should be addressed and included for all projects. This section presents an overview of the typical areas that may go into a project charter; however, organizations and project managers should adapt the project charter based on best practices, experience, and the project itself.

Quick Thinking - The Project Sponsor

According to Gopal Kapur, president of the Center for Project Management, "Sponsorship is not a spectator sport". A project sponsor should be an executive or manager with financial authority, political clout, and a personal commitment to the project. An effective sponsor is critical to the success of an IT project. Although no formal job description exists for a project sponsor, most agree that the project sponsor must provide leadership and direction, as well as political protection and problem-resolution skills. The project sponsor "champions" by:

• Empowering the project manager
• Ensuring sustained "buy in" from other project stakeholders
• Clearing political and organizational roadblocks
• Ensuring the availability of resources
• Reviewing the project’s progress
• Approving plans, schedules, budgets, and deliverables
• Ensuring that the project’s goal is realized

However, as Gopal Kapur explains, "Of all the items that can go wrong on a project, the one the project manager has the least control over is the sponsorship". Often when an IT project experiences problems, there’s a good chance the sponsor is to blame.

1. Why is a good project sponsor or champion so important to the success of an IT project?
2. How could a project manager or team handle a situation where the project sponsor leaves the organization to take a job with another company?
3. How should a project manager handle a project sponsor who is either incompetent or loses interest in the project and withdraws?

Project Identification

Project Planning Framework

In this section, a project planning framework will be introduced. This framework is part of the IT project methodology and provides the steps and processes necessary to develop the detailed project plan that will support the project's MOV.

A project plan attempts to answer the following questions:

• What needs to be done?
• Who will do the work?
• When will they do the work?
• How long will it take?
• How much will it cost?

The project planning framework illustrated in Figure 3.4 consists of several steps and processes. We will now focus on each of these steps to show how the project's schedule and budget are derived.

The MOV

The first step of the project planning framework entails finalizing the definition of and agreement on the project's measurable organizational value, or MOV. Although an in depth discussion of a project's MOV was provided in Chapter 2, it is important here to focus on a few salient points. First, the project's MOV must be defined and agreed on before proceeding to the other steps of the project planning framework. The project's MOV provides a direct link to the organization's strategic mission; however, as Figure 3.4 illustrates, a project's MOV links directly to the project plan. Therefore, a project's MOV acts as a bridge between the strategic mission and objectives of the organization and the project plans of individual projects it undertakes. The MOV guides many of the decisions related to scope, schedule, budget, and resources throughout the project's life cycle.

Define the Project's Scope

Once the project's MOV has been defined and agreed upon, the organization must make a commitment, in terms of time and resources, to define the project's scope in order to estimate the project's schedule and budget. Scope includes the products or services to be provided by the project and includes all of the project deliverables. One can think of scope as the work that needs to be completed in order to achieve the project's MOV. Project scope management is covered in more detail in the next chapter; however, the basic processes include:

• Planning - The project team must develop a detailed scope statement that defines the work to be included, as well as the work not to be included in the project plan. The scope statement will be used to guide future project-related decisions and to set stakeholder expectations.
• Definition - The project's scope must be organized into smaller and more manageable packages of work. These work packages will require resources and time to complete. This may include more detail than the preliminary scope statement in the project charter.
• Verification - Once the project's scope has been defined, the project team and stakeholders must verify it to ensure that the work completed will in fact support the project in achieving its MOV.
• Change Control - Controls must be in place to manage proposed changes to the project's scope. Scope changes can either move the project closer to its MOV or result in increased work that drains the project's budget and causes the project to exceed its scheduled deadline. Proper scope control procedures can ensure that the project stays on track.

Subdivide the Project into Phases

Once the project's scope has been defined and verified, the work of the project can be organized into phases and subphases in order to complete all of the project's deliverables. Phases are logical stages that organize the project work to reduce complexity and risk. In many cases, it is easier to focus and concentrate the project team's effort on the pieces instead of the whole; however, it is important to keep an eye on the big picture.

Each phase of the project should focus on providing at least one specific project deliverable - that is, a tangible and verifiable piece of work. Examples of deliverables include the business case, the project plan, and, most important, the project's product - the information system to be developed or software package to be implemented. In addition, a milestone is a significant event or achievement that provides evidence that the deliverable, phase, or subphase has been completed and accepted by the project sponsor.

Phases are largely determined by the project methodology and the approach chosen for carrying out the systems development life cycle (SDLC). As discussed in Chapter 1, the SDLC can be implemented by using a more structured approach, such as the waterfall method, or by using a more iterative approach. The selection of an approach to implement the SDLC is an important decision that will affect not only how the system will be developed and implemented, but to a large degree outline the phases, deliverables, and tasks defined in the project plan. The appropriate decision depends on how quickly the system needs to be delivered as well as how well defined and stable the requirements of the system will remain throughout the project life cycle. For example, the waterfall model would be more appropriate for a project where the requirements are well understood and complex, but it would not be appropriate for a project following the eXtreme project management paradigm. On the other hand, an iterative approach for carrying out the SDLC would be more appropriate where the project is characterized by uncertainty, change, and tight deadlines.

Tasks - Sequence, Resources, and Time Estimates

Once the project is divided into phases, tasks are then identified. A task may be thought of as a specific activity or unit of work to be completed. Examples of some tasks in an IT project may be to interview a particular user, write a program, or test links in a Web page. When considering tasks, it is important to consider sequences, resources, and time.

Sequence

Some tasks may be linear - that is, have to be completed in a particular sequence - while others can be completed in parallel - that is at the same time. Performing parallel tasks often provides an opportunity to shorten the overall length of the project. For example, assume that a project has two tasks - A and B. Task A will require only one day to complete; task B requires two days. If these tasks are completed one after the other, the project will finish in three days. On the other hand, if these tasks are performed in parallel, the length of the project will be two days. In this case, the length of the project is determined by the time it takes to complete the longest task (i.e., task B). This simple example illustrates two important points: (1) A project is constrained by the longest tasks, and (2) any opportunity to perform tasks in parallel can shorten the project schedule.

Resources

Resources on an IT project may include such things as technology, facilities (e.g., meeting rooms), and people. Tasks require resources, and there is a cost associated with using a resource. The use of a resource may be accounted for by using a per-use charge or on a prorated basis - that is, a charge for the time you use that resource. For example, a developer earns $50,000 a year and is assigned to work on a task that takes one day to complete. The cost of completing that particular task would be prorated as $191 (assuming an eight-hour, five-day work week).

Time

It will take a resource a specific amount of time to complete a task. The longer it takes a resource to complete a specific task, however, the longer the project will take to finish and the more it will cost. For example, if we plan on assigning our developer who earns $50,000 a year to a task that takes two days, then we would estimate the cost of completing that task to be approximately $400. If the developer completes the task in one-half the time, then the cost of doing that task will be about $200. Moreover, if the developer were then free to start the next task, our schedule would then be ahead by one day. Unfortunately, the reverse is true. If we thought the task would take two days to complete (at a cost of $400) and it took the developer three days to complete, the project would be one day behind schedule and $200 over budget. However, if two tasks could be performed in parallel, with our developer working on Task A (one day) and another $50,000/year-developer working on Task B (two days), then even if Task A takes two days, our project schedule would not be impacted - as long as the developer working on Task B completes the task within the estimated two days. While this parallel work may save our schedule, our budget will still be $200 over budget because task A took twice as long to complete. Understanding this relationship among tasks, resources, and time will be important when developing the project plan and even more important later if it is necessary to adjust the project plan in order to meet schedule or budget constraints.

Schedule and Budget - The Baseline Plan

The detailed project plan is an output of the project planning framework. Once the tasks are identified and their sequence, resources required, and time to complete estimated, it is a relatively simple step to determine the project's schedule and budget. All of this information can be entered into a project management software package that can determine the start and end dates for the project, as well as the final cost.

Once completed, the project plan should be reviewed by the project manager, the project sponsor, and the project team to make sure it is complete, accurate, and, most important, able to achieve the project's MOV. Generally, the project plan will go through several iterations as new information becomes known or if there are compromises with respect to scope, schedule, and budget. In addition, many of the details of the project plan are summarized in the project charter in order to provide a clearer picture as to how the plan will be carried out. Once the project plan is approved, it becomes the baseline plan that will serve as a benchmark to measure and gauge the project's progress. The project manager will use this baseline plan to compare the actual schedule to the estimated schedule and the actual costs to budgeted costs.

The Kick-Off Meeting

Once the project charter and project plan are approved, many organizations have a kick-off meeting to officially start work on the project. The kick-off meeting is useful for several reasons. First, it brings closure to the planning phase of the project and signals the initiation of the next phase of the IT project methodology. Second, it is a way of communicating to everyone what the project is all about. Many kick-off meetings take on a festive atmosphere in order to energize the stakeholders and get them enthusiastic about working on the project. It is important that everyone start working on the project with a positive attitude. How the project is managed from here on will determine largely whether that positive attitude carries through.

Chapter Summary

Processes are important to project management because they support all of the activities needed to develop and manage the development of an IT solution. Product-oriented processes focus on the development of the application system itself and require specific domain knowledge, tools, and techniques. On the other hand, project management processes are needed to manage and coordinate all of the activities of the project. A balance of both product-oriented processes and project management processes is needed; otherwise, the result may be a solution that is a technical success but an organizational failure. In addition, five project management process groups were introduced that support both the project and each phase of the project. These include: (1) initiating, (2) planning, (3) executing, (4) controlling, and (5) closing.

Project integration management is one of the most important Project Management Body of Knowledge areas. Its purpose is to coordinate and integrate the other knowledge areas and project processes. Project integration management processes focus on (1) develop project charter, (2) develop preliminary project scope statement, (3) develop project management plan, (4) direct and manage project execution, (5) monitor and control project work, (6) integrated change control, and (7) close project.

The project charter serves as an agreement and as a communication tool for all of the project stakeholders. The project charter documents the project's MOV and describes the infrastructure needed to support the project. In addition, the project charter summarizes many of the details found in the project plan. A well written project charter should provide a consolidated source of information about the project and reduce the likelihood of confusion and misunderstanding. In general, the project charter and project plan should be developed together - the details of the project plan need to be summarized in the project charter, and the infrastructure outlined in the project charter will influence the estimates used to develop the project plan.

The project plan provides the details of the tactical plan that answers these questions: What needs to be done? Who will do the work? When will they do the work? How long will it take? How much will it cost?

A project planning framework was introduced and recommended a series of steps to follow in order to develop a detailed project plan. The details with respect to carrying out these steps will be the focus of subsequent chapters. Once the project charter and plan are approved, the project plan serves as a baseline plan that will allow the project manager to track and assess the project's actual progress to the original plan. A kick-off meeting usually brings closure to the second phase of the IT project methodology and allows the project team to begin the work defined in the plan.

Extend Your Knowledge

1. You have just been hired by a local swim team to develop a Web site. This Web site will be used to provide information to boys and girls between the ages of 6 and 18 who are interested in joining the team. In addition, the Web site will provide information about practices and the swim meet schedule for the season. The team would also like to be able to post the meet results. The head coach of the swim team is the project sponsor. He would also like the Web site to include pictures of the three assistant coaches and of the different swimmers at swim meets and practice. The swim team is supported largely by an association of parents who help run the swim meets and work the concession stand. Several of the parents have asked that a volunteer schedule be part of the Web site so that the parent volunteers can see when they are scheduled to work at a particular meet. The head coach, however, has told you that he believes this functionality can wait and should not be part of the Web site now. Two people will be helping you on the project. One is a graphic artist; the other is a person who is very familiar with HTML, Java, Active Server Pages (ASP), and several Web development tools. Based upon the information provided, develop the basics of a project charter. Although you will not be able to develop a complete project charter at this point, you can get started on the following:

2. Suppose a company is interested in purchasing a call center software package to improve its customer service. Describe the project management processes that would be needed to support the first two phases of the IT project methodology.
3. Plan a kick-off meeting for a project team.

Global Technology Solutions

The quiet drive back to the office was a welcome respite for Tim Williams, even though he was catching the tail end of rush hour traffic. Traffic was moving well below the speed limit, so the time alone gave him a chance to reflect on the activities of the last few weeks. The business case for Husky Air was complete, and Tim had presented it to the company's senior management not more than 30 minutes ago.

Just as Tim was about to turn on the car's radio, his cell phone rang and he was immediately brought back to reality. Tim answered, and heard his business partner Kellie Matthews ask, "So, how did it go?"

"Not bad!" Tim replied. "In fact, senior management approved our recommendation and is willing to make funds available for us to go on to the next step".

Kellie laughed and teased, "I guess that means we can pay the office rent next month. So what's our next step?"

The traffic had now come to a complete stop, so Tim didn't feel that talking on his cell phone would distract him. "Now that we've completed the business case and Husky Air gave us the approval and funds, I would say that the first phase of our project methodology is complete," he said. "The next thing we need to do is develop a project charter and baseline plan that will outline what we're going to do, how we're going to do it, when we're going to do it, and how much it will cost".

"Wow," exclaimed Kellie, "I thought that was all outlined in the business case".

"The business case was a strategic plan, the project charter and baseline project plan are going to be our tactical plan," Tim explained. "This will also be a reality check to make sure that we can deliver the application to our client within the guidelines that were specified in the business case".

"Will this require another approval by Husky Air's management?" asked Kellie".

Actually, there will be several more," answered Tim. "In fact, the CEO was pleased that our methodology has approval or review points throughout the project life cycle. He said that Husky Air hired a consulting firm a few years ago to develop an inventory system. The consultants didn't keep senior management informed after the project was approved. So the CEO was surprised to find out that the project was only half complete when the agreed upon project deadline arrived. Husky Air's management had only two choices: Cancel the project and take the loss, or bite the bullet and continue funding a project that would cost twice as much as originally planned. Needless to say, they intend never to hire that consulting firm again".

"Well if the client is happy then we should be happy as well," Kellie said.

The traffic started moving again, and Tim said "I'll see you in the office tomorrow morning. We have a lot of work ahead of us".

Kellie agreed, and they both said goodbye before hanging up. Tim relaxed as the traffic started to move again. Even though there was still much work to be done before the actual work on the system would begin, he felt good that they had cleared the first hurdle. "What the heck," he thought. He turned off at the next exit and headed for his favorite Italian restaurant. "It's important to celebrate the small but important successes along the way," he told himself. "Pizza is perfect".
Things to Think About

1. Why is it important to have several status review and decision points throughout the project's life cycle?
2. Aside from reality checks, what other purposes do status reviews and decision points throughout the project's life cycle provide?
3. How does a business case differ from the project charter/project plan?
4. Why is it important to celebrate the small but important successes?

Husky Air Assignment - Pilot Angels

Defining the Project Infrastructure

Husky Air's management has decided that building a custom information system will provide the most value to their organization. Your team has been asked to continue with the project and develop this system.

The first step before planning the details of the project's schedule and budget requires that you define an infrastructure for your project. The infrastructure is the foundation for the project charter. Knowing what resources you need or are available and their associated cost will directly influence your schedule and budget estimates. This will entail defining the stakeholders of the project and the resources that will be required.

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

1. The 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 list of the resources needed to complete the project - This should include:

Case Studies

People, Processes, and Tools

People, processes, and tools play an important role in projects. People provide value to projects because of their creativity. A person's ability to create is not something easily replaced by a machine even though the dream of artificial intelligence has been around for decades. Projects start with a goal or need and creativity allows us to make conceptual leaps that allow us to come up with new ideas to solve a problem or overcome a challenge. In addition, creativity often is prompted by another inherently human trait called vision, or our ability to see what is not yet there - that is, to imagine. Projects often start out as someone's vision that becomes a guide for the project work to be done and motivation for creative energy. Lastly, the combination of creativity and vision provides a unique outlet for our intellect. We carry around a number of facts in our heads, but intellect is more than what we know. Intellect is our ability to use those facts to uncover relationships and is the enabler of creativity.

Unfortunately, people are not perfect. Although people are essential to projects, people are also a main reason why projects experience problems and even fail. Another human trait is our ability to make mistakes. For example, we would most likely trust a compiler because we expect it to compile a program correctly, but we may not have the same degree of trust in a program that someone wrote that wasn't properly tested, reviewed, examined, and retested. People can make errors that impact a project significantly. Time, effort, and money must be spent fixing those errors. Moreover, people can also forget things. While we can all forget facts and information, we can also forget to do things. An activity may require a number of steps, and a person may omit one or more steps if they aren't familiar with the activity or when their attention is diverted. Regardless, omissions often result in someone having to go back and filling in the missing work or redoing what was already done. Another human shortfall is that people can be imprecise. A systems analyst, for example, may fail to document fully the requirements of a system. The programmer may make assumptions to fill in the blanks, resulting in a system that may not satisfy the user's needs.

Since people bring unique abilities to a project, it is important that we seek opportunities to enhance their value while mitigating their shortcomings. This is the basic reason for processes and tools. Recently, the topic of processes has been a controversial issue. Many people believe that processes get in the way or stifle creativity. The truth is that we follow processes in many of our day-to-day routines. These routines that we repeat regularly help us get through the day without having to stop and think through every step each time we do something. This frees up our minds so that we can focus on things that require our conscious attention; for example, each of us has a morning routine (i.e., process) for getting up and getting to work or school.

Processes fail when they do not meet the needs of the people who must follow them. A process becomes unconscious when it meets our needs and doesn't get in the way. People complain about ineffective processes when they fail to meet our needs or when they become a waste of our time and effort.

Processes provide value when they compensate for our human shortcomings in terms of helping us compensate for errors, omissions, or imprecision. They get in the way when they impede creativity, vision, or intellect. For example, a morning routine that includes checking the weather and traffic reports can help us choose the best time to leave or the best route for our commute. Therefore, a process should help us do all the things we're supposed to do and do them in the right order and with the right amount of detail or precision required. Since not every error, omission, or imprecision can be avoided, processes also provide necessary checks and balances to detect and correct mistakes before they become problems. Moreover, a process that is followed inconsistently will produce inconsistent results, while a process followed consistently will provide consistent results. Often processes are undocumented, but the need for documentation increases as more people become involved in a process. This helps new staff learn the rules and what is expected of them.

Tools, on the other hand, can improve efficiency by magnifying or leveraging a person's efforts or by replacing the human effort. For example, a long time ago programmers wrote code that ran by stringing together the 1s and 0s or bits so the computer's processor could directly execute the program. Compliers replaced the task of programmers having to write code directly to the processor while magnifying their work by allowing them to write higher level abstractions using a programming language. A human could therefore spend time analyzing a problem and applying creativity and intellect to solve it, while the compiler translates each line of this source code into the language the computer could understand.

Tools are appropriate when people spend a great deal of time working on processes that do not involve a great deal of creativity. A tool should help them spend less time on mundane activities and more time on the challenging aspects of their work. This can improve the quality of their work-life as they spend more time on interesting and challenging work.

However, adoption of a tool often necessitates a process change. For example, a code repository tool may require a process change that now requires programmers to check code out to work on it and then check it back in when they are done. While this may be a small change, one should consider whether a tool should be adopted if it changes the process so significantly that it then becomes a hindrance or waste of time and effort. Tools should make people and processes more efficient and effective. Tools and processes that reduce efficiency and effectiveness are not worth adopting.

1. Discuss the relationship between people, processes, and tools. When is this relationship most effective? When is it least effective?
2. Can good people make up for poor processes? Can good processes make up for incompetent people?
3. We've all encountered a process that we felt wasted our time and/or money. This could be in our job, waiting in line trying to renew our driver's license, or at a fast food restaurant. Describe an inefficient process that you may have performed as part of a job (past or present) or a process you encountered in your day-to-day life. How did this process stifle a person's intellect or ability to be creative? Could the process be improved? Could a tool be used to free a person from the mundane tasks and improve the quality of their work life?

The Project Battlefield

Daniel Starr tells an interesting story that compares an ancient parable to a modern-day confrontation. If he had lived 2000 years before with his Celtic ancestors, the story might have unfolded something like:

Summoned was I, summoned to the stronghold of mine enemy. There he stood, a great brute of a man, brandishing an immense spear and shouting epithets in his foul tongue. My heart did sink as he advanced, for I knew my own short blade was no match for such a great weapon. And so, summoning up all of my courage and that of my ancestors, I removed my helmet, released the buckles that held my armor and let it fall to the ground. There I stood, unprotected, exposing my breast to his attack. With a mighty roar he charged toward me, and when his spear-tip was inches away I ducked to the side, reached out with my left arm and grasped his weapon, taking a grievous wound to the hand, and held on with all my might. Unwilling to release his spear, my enemy attempted to pull the spear away from my grasp. This I fought, and slowly drew him closer until, when our eyes were but a hand's breadth apart, I took the small dagger I had hidden in my right hand and slid it through the chink in his armor and then between his ribs. He fell away gasping and bleeding, and while I did not kill him, this enemy never troubled me again.

Since Daniel was born in 20th century America, the story happens in a different way. He was project manager for a small software development team who had "plenty of responsibility and no official authority". He describes his reputation in the organization as "the hairy wild man genius in the software department".

On a Wednesday morning, his phone rang. It was the executive secretary asking him to attend a meeting in conference room 2. When he arrived, Daniel found a group of executives and Ted, a middle manager who for some reason had never quite liked him. Perhaps it could be Daniel's long hair, casual dress, or the fact that he rode a motorcycle to work.

With the manner of a prosecuting attorney, Ted held up a piece of paper and read a description of a bug that his people had found in some software Daniel's team was responsible for. Daniel thought it was odd that he had not heard about this issue through the formal trouble-reporting system. After reading the charges, Ted asked, "What do you have to say about this?"

Daniel asked politely to see the report, and with some disdain Ted handed it to him. While reading the report, several defenses crossed Daniel's mind: "Why hadn't the report been formally reported?" "Could Ted's people have been misusing the software again?" Or a number of excuses came to mind like "The system is still a prototype".

After about 30 seconds, Ted spoke up and said "Well!!?"

Daniel replied, "I guess I messed up". A murmur began among the executives. Daniel added calmly, "It's a simple mistake. I should have a patch by tomorrow and a complete fix for Friday's release".

The attitude among the executives began to change, and Daniel suddenly realized that no one was looking at him anymore - all eyes were now on Ted. The expression on their faces said "Why are you wasting our time?!" After an awkward moment of silence, one of the executives turned to Daniel and excused him from the meeting.

Daniel saw Ted later that afternoon. Although Ted didn't say anything to him, he did have a pained expression on his face. Daniel had to work late on Thursday to get the fix into Friday's release as promised, but Ted never bothered him again.

As Daniel philosophizes, "Some things don't change. Whether it's fought with swords and shields or words and processes, life is still a battle, decided by weaponry and armor".

For example, we all develop our personal suits of armor that fit us so well that we may not even know we're wearing them. This personal armor could be in the form of nicknames (e.g., Buzzsaw Bob), policies (e.g., "please put that in writing"), reputations (e.g., "he's the only one who knows how the system works"), the way we use email or voice mail, and so on. Although the list is endless, the purpose is to deflect or absorb words, actions, changes, problems, or anything that might threaten our sense of comfort or safety. On projects, this may include added processes, standards, control of communication channels or information, checklists, audits, etc. to protect our projects from unpredictable and hostile environments.

In Daniel's battle with Ted, his armor included his reputation, the rules regarding bug reporting, the manual he wrote describing how the software was and wasn't to be used, and the understanding that the system was still a prototype so a certain number of problems could be expected.

Although armor can protect you (it can let you get work done), in many cases it can slow you down, limit your agility, and consume your strength. Moreover, a particular piece of armor is effective against some weapons while ineffective against others. For example, chain mail made up of interlocking steel rings can be effective against a sword, but useless against poison-tipped darts. Subsequently, armor evolves. Armor designed to protect a person from arrows and swords is now on display in museums. Modern armor is designed to protect soldiers from bullets and shrapnel.

In summary, Daniel Starr suggests that people be aware of their armor in terms of its value and limitations. We often build our personal armor unconsciously in response to attacks we suffer or threats we perceive. To become a more effective project leader or even a better person, one should take an inventory of their personal armor. The questions then become: How well does this armor protect me? What is the cost in terms of losing agility and flexibility? What pieces of armor need replacing or repair?

1. Daniel's first-century counterpart took a "grievous wound to the hand" when he deflected his opponent's spear. How did Daniel take a similar wound when he admitted that he made a mistake? How did this change the situation with Ted?
2. What armor might a project manager wear when he or she develops the project charter and project plan? When would this personal armor be useful? How could it become more of a hindrance than offering protection to the project manager and team?