Developing the Project Charter and Baseline Project Plan

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.

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.

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

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 details 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 sub plans 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
  • Resource
  • Name of resource provider
  • 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?