Developing the Project Charter & Baseline Project Plan

Information Technology Project Management. Providing Measurable Organizational Value, Third Edition
Chapter 3: Developing the Project Charter and Baseline Project Plan

ISBN: 9780470371930 Author: Jack T. Marchewka
copyright © 2009 John Wiley & Sons Inc.
Developing the Project Charter and Baseline Project Plan

Chapter Objectives

Chapter 3 focuses on developing the project charter and project plan. After studying this chapter, you should understand and be able to:

* 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.

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 subplans 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” (38). 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?

SOURCE: Adapted from Bob Wyatt, Building a Project Management Culture, Computerworld, October 4, 2004.

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. As Figure 3.1 illustrates, 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.

Figure 3.1 Project Processes

[Click to enlarge]
Project Management Process Groups

While the project life and systems development life cycles define the phases of a project, five process groups define appropriate processes for managing the project by function or the kind of work that needs to be done. As illustrated in Figure 3.2, the process groups overlap within and between the phases of the project as the output of one process group within a phase becomes the input for a process group in the next phase.

Figure 3.2 Project Management Processes and ITPM Phases

[Click to enlarge]
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 (2005) 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” (85). 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. (77)

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?

SOURCE: Adapted from Bart Perkins, Executive Sponsors: What They Really Do, Computerworld, September 12, 2005; Kathleen Melymuka, Project Management: Surviving the Sponsor Exit, Computerworld, February 16, 2004; Kathleen Melymuka, Firing Your Project Sponsor Computerworld, February 23, 2004.
Project Identification

It is common for all projects to have a unique name or a way to identify them. It is especially necessary if an organization has several projects underway at once. Naming a project can also give the project team and stakeholders a sense of identity and ownership. Often organizations will use some type of acronym for the project’s name. For example, instead of naming a project something as mundane as the Flight Reservation System in 1965, American Airlines named its system Semi-Automated Business Research Environment (SABRE). Today, SABRE has become a well recognized product that connects travel agents and online customers with all of the major airlines, car rental companies, hotels, railways, and cruise lines.
Project Stakeholders

It is important that the project charter specifically name the project sponsor and the project manager. This reduces the likelihood of confusion when determining who will take ownership of the project’s product and who will be the leader of the project. In addition, the project team should be named along with their titles or roles in the project, their phone numbers, and email addresses. This section should describe who will be involved in the project, how they will be involved, and when they will be involved. Formal reporting relationships can be specified and may be useful on larger projects. In addition, including telephone numbers and email addresses can provide a handy directory for getting in touch with the various participants.
Project Description

The project charter should be a single source of information. Therefore, it may be useful to include a description of the project to help someone unfamiliar with the project understand not only the details, but the larger picture as well. This may include a brief overview or background of the project as to the problem or opportunity that became a catalyst for the project and the reason or purpose for taking on the project. It may also be useful to include the vision of the organization or project and how it aligns with the organization’s goal and strategy. Much of this section could summarize the total benefits expected from the project that were described in the business case. It is important that the project description focus on the business and not the technology.
Measurable Organizational Value (MOV)

The MOV should be clear, concise, agreed on, and made explicit to all of the project stakeholders. Therefore, the project’s MOV should be highlighted and easily identifiable in the project charter.
Project Scope

The project’s scope is the work to be completed. A specific section of the project charter should clarify not only what will be produced or delivered by the project team, but what will not be part of the project’s scope. This distinction is important for two reasons. First, it provides the foundation for developing the project plan’s schedule and cost estimates. Changes to the project’s scope will impact the project’s schedule and budget—that is, if resources are fixed, expanding the amount of work you have to complete will take more time and money. Therefore, the creation of additional work for the project team will extend the project’s schedule and invariably increase the cost of the project. Formal procedures must be in place to control and manage the project’s scope. Secondly, it is important for the project manager to manage the expectations of the project sponsor and the project team. By making the project’s scope explicit as to what is and what is not to be delivered, the likelihood of confusion and misunderstanding is reduced.

For example, the project team and several users may have several discussions regarding the scope of a project. One user may suggest that the system should allow for the download of reports to a wireless personal digital assistant (PDA). After discussing this idea in depth, management may decide that the cost and time to add this wireless PDA capability would not be in the organization’s best interest. In this case, it would be a good idea to state explicitly in the project charter that wireless PDA capability will not be part of the project’s scope. Although you may be clear on this issue, others may still have different expectations. The project’s scope should, therefore, define key deliverables and/or high-level descriptions of the information system’s functionality. The details of the system’s features and functionality will, however, be determined later in the systems development life cycle when the project team conducts an information requirements analysis.

At this point, a first attempt is made to define the project’s scope and is based on information provided by the project sponsor. Only enough detail is needed to plan the project so that estimates for the project schedule and budget can be defined. This may include a high-level view of the project and product deliverables and the criteria for their acceptance by the project sponsor. Detailed system requirements will be specified later on during the execution phase of the project when the SDLC is carried out.

The scope defined in the project charter can take the form of a narrative description of the products or services produced by the project. This narrative is often called the statement of work (SOW). The SOW can be developed by the project sponsor or by interviewing key stakeholders conducted by the project team.
Project Schedule

Although the details of the project’s schedule will be in the project plan, it is important to summarize the detail of the plan with respect to the expected start and completion dates. In addition, expected dates for major deliverables, milestones, and phases should be highlighted and summarized at a very high level.
Project Budget

A section of the project charter should highlight the total cost of the project. The total cost of the project should be summarized directly from the project plan.
Quality Issues

Although a quality management plan should be in place to support the project, a section that identifies any known or required quality standards should be made explicit in the project charter. For example, an application system’s reports may have to meet a government agency’s requirements.
Resources

Because the project charter acts as an agreement or contract, it may be useful to specify the resources required and who is responsible for providing those resources. Resources may include people, technology, or facilities to support the project team. It would be somewhat awkward for a team of consultants to arrive at the client’s organization and find that the only space available for them to work is a corner table in the company cafeteria! Therefore, explicitly outlining the resources needed and who is responsible for what can reduce the likelihood for confusion or misunderstanding.
Assumptions and Risks

Any risks or assumptions should be documented in the project charter. Assumptions may include things that must go right, such as a particular team member being available for the project, or specific criteria used in developing the project plan estimates. Risks, on the other hand, may be thought of as anything that can go wrong or things that may impact the success of the project. Although a risk management plan should be in place to support the project team, the project charter should summarize the following potential impacts:

* Key situations or events that could significantly impact the project’s scope, schedule, or budget—These risks, their likelihood, and the strategy to overcome or minimize their impact should be detailed in the project’s risk plan.
* Any known constraints that may be imposed by the organization or project environment—Known constraints may include such things as imposed deadlines, budgets, or required technology tools or platforms.
* Dependencies on other projects internal or external to the organization—In most cases, an IT project is one of several being undertaken by an organization. Subsequently, dependencies between projects may exist, especially if different application systems or technology platforms must be integrated. It may also be important to describe the project’s role in relation to other projects.
* Impacts on different areas of the organization—As described in Chapter 1, IT projects operate in a broader environment than the project itself. As a result, the development and implementation of an IT solution will have an impact on the organization. It is important to describe how the project will impact the organization in terms of disruption, downtime, or loss of productivity.
* Any outstanding issues—It is important to highlight any outstanding issues that need further resolution. These may be issues identified by the project sponsor, the project manager, or the project team that must be addressed and agreed upon at some point during the project. They may include such things as resources to be provided or decisions regarding the features or functionality of the system.

Project Administration

Project administration focuses on the knowledge areas, processes, and controls that will support the project. These are actually separate subplans or strategies that make up the project management plan. Administration may include:

* A communications plan that outlines how the project’s status or progress will be reported to various stakeholders. This plan also includes a process for reporting and resolving significant issues or problems as they arise.
* A scope management plan that describes how changes to the project’s scope will be submitted, logged, and reviewed.
* A quality management plan that details how quality planning, assurance, and control will be supported throughout the project life cycle. In addition, a plan for testing the information system will be included.
* A change management and implementation plan that will specify how the project’s product will be integrated into the organizational environment.
* A human resources plan for staff acquisition and team development.

Acceptance and Approval

Since the project charter serves as an agreement or contract between the project sponsor and project team, it may be necessary to have key stakeholders sign off on the project charter. By signing the document, the project stakeholder shows formal acceptance of the project and, therefore, gives the project manager and team the authority to carry out the project plan.
References

In developing the project charter and plan, the project manager may use a number of references. It is important to document these references in order to add credibility to the project charter and plan, as well as to provide a basis for supporting certain processes, practices, or estimates.
Terminology

Many IT projects use certain terms or acronyms that may be unfamiliar to many people. Therefore, to reduce complexity and confusion, it may be useful to include a glossary giving the meaning of terms and acronyms, allowing all the project’s stakeholders to use a common language. Figure 3.3 provides a template for a project charter. Feel free to adapt this template as needed.

Figure 3.3 Project Charter Template
Project Name or Identification
Project Stakeholders

* Names
* Titles or roles
* Phone numbers
* E-mail addresses

Project Description

* Background
* Description of the challenge or opportunity
* Overview of the desired impact

Measurable Organizational Value (MOV)

* Statement or table format

Project Scope

* What will be included in the scope of this project
* What will be considered outside the scope of this project

Project Schedule Summary

* Project start date
* Project end date
* Timeline of project phases and milestones
* Project reviews and review dates

Project Budget Summary

* Total project budget
* Budget broken down by phase

Quality Issues

* Specific quality requirements

Resources Required

* People
* Technology
* Facilities
* Other
* Resources to be provided
o Resource
o Name of resource provider
o Date to be provided

Assumptions and Risks

* Assumptions used to develop estimates
* Key risks, probability of occurrence, and impact
* Constraints
* Dependencies on other projects or areas within or outside the organization
* Assessment project’s impact on the organization
* Outstanding issues

Project Administration

* Communications plan
* Scope management plan
* Quality management plan
* Change management plan
* Human resources plan
* Implementation and project closure plan

Acceptance and Approval

* Names, signatures, and dates for approval

References
Terminology or Glossary
Appendices (as required)
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.

Figure 3.4 The Project Planning Framework—Defining the MOV

[Click to enlarge]
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 indepth 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 (DeCarlo 2004). 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 (DeCarlo 2004; McConnell 1996). 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 access 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.
Review Questions

1.

What are project management processes? Give one example.

2.

What are product-oriented processes? Give one example.

3.

Why must a balance exist between project management processes and product-oriented processes?

4.

Describe the initiating processes. Give one example of an initiating process to support a particular phase of the IT project methodology.

5.

Describe the planning process. Give one example of a planning process to support a particular phase of the IT project methodology.

6.

Describe the executing process. Give one example of an executing process to support a particular phase of the IT project methodology.

7.

Describe the controlling process. Give one example of a controlling process to support a particular phase of the IT project methodology.

8.

Describe the closing process. Give one example of a closing process to support a particular phase of the IT project methodology.

9.

Describe how the output of project management process groups in one phase becomes the input or catalyst for the process group in the next phase. Provide an example.

10.

What is the difference between contract closure and administrative closure?

11.

Describe project integration management and its relationship to the other Project Management Body of Knowledge areas.

12.

Describe project plan development and its importance to the second phase of the IT project methodology.

13.

Describe project plan execution and its importance to project plan development.

14.

Describe overall change control and its importance to the project team.

15.

What is the purpose of a project charter?

16.

Why can a project charter serve as an agreement or a contract?

17.

Why is a project charter a useful communication tool?

18.

Why should the project charter and project plan be developed together?

19.

How does the project charter support the project plan?

20.

How does the project plan support the project charter?

21.

Describe the project planning framework.

22.

Why is it important that the project’s MOV be cast in stone?

23.

Describe how the project’s MOV supports the development of the project’s scope, schedule, and budget.

24.

What is a project’s scope?

25.

Why should a project be divided into phases?

26.

What is a deliverable? What is the relationship between phases and deliverables?

27.

What is a milestone? Why are milestones useful?

28.

What is a task? Provide three examples of some typical tasks in an IT project.

29.

What impact can the sequence of tasks have on a project’s schedule?

30.

How can resources impact the schedule of a project?

31.

What is a baseline plan? What purpose does it serve once the project team begins to execute the project plan?

32.

What is a kick-off meeting? What purpose does it serve?

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:
1. Come up with a name for the project.
2. Identify the project stakeholders, their roles, and their titles.
3. Provide a brief description of the project.
4. Develop a MOV for this project.
5. Specify the project’s scope in terms of the high-level features or functionality that should be included in the Web site.
6. Specify what should not be included in the project’s scope.
7. Specify the resources that will be required and provide an estimated cost for each resource. (Be sure to include a reference or sound basis to justify the cost for each resource.)
8. Identify some of the risks associated with this project.
9. You are free to make assumptions as needed, but be sure to document them!
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:
1. People (and their roles)— Your team is responsible for planning the project. However, the project may need additional individuals with both technical and nontechnical expertise to develop the system.
2. Technology— In the previous assignment, you estimated the hardware, network, and software needs for a system to support your client. You will also need various hardware, network, software, and telecommunication resources to support the project team.
3. Facilities— Husky Air has limited space. The project team will have to do most of its project and development work at a different site.
4. Other—for example, travel, training, and so on.
5. An estimate for the cost of each resource—Use the Web, trade journals, newspaper advertisements, and so forth as a basis. For example, if you need to hire a programmer, then you could use want ads or salary surveys as a basis for an annual base salary or hourly wage. The people who work on the project (including you and your team) will be paid a base salary or hourly wage plus benefits. Therefore, the cost of any people on your team will be a base salary (the person’s gross income) plus an addition 25 percent paid out in benefits. Be sure to include a reference for all the sources you use.

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 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?

SOURCE: Adapted from a three-part series by Alan Koch, The People Premium, Processes for People, and The Role of Tools, Projects@Work, October 6, 2005, December 1, 2005, and February 2, 2006.
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, mine 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?

SOURCE: Adapted from Daniel Starr, Choosing Your Armor, Projects@Work, November 3, 2005.
Bibliography

DeCarlo, D. 2004. eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility. San Francisco: Jossey-Bass.

McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Redmond, WA: Microsoft Press.

Mulcahy, R. 2005. PMP® Exam Prep for the PMBOK® Guide, 5th ed. Minneapolis, MN: RMC Publications, Inc.

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

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