The Project Charter

The project charter and baseline project plan provide a tactical plan 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 proj ect 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 proj ect 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 experi enced 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 proj ect plan if you develop your estimates based upon the abilities of your best people. If one of these individuals should leave sometime during the proj ect, you may have to replace them with someone less skilled or experi enced. 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.

ARE IT PROJECTS DIFFERENT?

Many organizations view project management as an investment to improve the likelihood of success of IT projects. However, Gopal K. Kapur believes that the principles and practices of project management have been developed by the engineering profession. Based upon his experience, first as a civil engineer and then as an IT project manager, Kapur strongly believes that IT projects are more difficult to manage than engineering projects. For IT project management to work, the IT profession must adapt and expand the engineering Project Management Body of Knowledge. Kapur lists seven key differences:

1. The engineer uses artists' renderings, architectural models, and drawings that describe clearly the final product or end state before construction begins. However, the final product or end state of an IT project is not always clearly defined or known until the later stages of the project.

2. The phases of a construction project are more lin ear, and the boundaries for each phase are well defined. On the other hand, the phases of an IT project are more complex because they tend to overlap or spiral.

3. The construction process for engineering projects is based on fabricating the end product from pretested and predesigned components, while the code for most IT projects must be developed or written from scratch.

4. The deliverables for most engineering projects are defined precisely in terms of specifications. Deliverables for IT projects, however, are seldom defined as precisely and may be open to interpreta tion by various stakeholders.

5. Engineering projects often have extensive data bases that contain accurate cost information that are available to estimators. IT estimation generally is based on best guess estimates because there are few sources that can provide historical information.

6. In engineering projects, the roles and responsibili ties of team members are generally well defined (e.g., carpenters, plumbers, electricians, painters, and so forth), while a single person on an IT project may have to take on several roles or responsibilities.

7. Engineering drawings and specifications make use of standardized symbols, terms, and text. Little con fusion arises from blueprints that depict electrical wiring or a map of the landscape. IT vendors, on the other hand, tend to try to create new terms, sym bols, or text in order to distinguish themselves from their competition.

SOURCE: Adapted from Gopal K. Kapur, Why IT Project Management is So Hard to Grasp, Computerworld, May 3, 1999, http://www.com-puterworld.com/managementtopics/management/proj ect/story/0,1080 1,35529,00 Jrtml.

• 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 spec ify clearly who will take ownership of the project's product once the proj ect 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 nine project management knowledge areas and processes. 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 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.

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 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 e-mail 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 e-mail 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 upon, 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 also 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 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 explicitly state 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.

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 over come or minimize their impact should be detailed in the project's risk plan.

• Any known constraints that may be imposed by the organization or proj ect environment should be documented. 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 organiza tion. Subsequently, dependencies between projects may exist, especially if dif ferent 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 controls that will support the project. It 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 his/her 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.4 provides a template for a project charter. Feel free to adapt this template as needed.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment