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.
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.
It is important that the project charter specifically name the projet 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.
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 Organisational 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.
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 to manager 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 smart phone. After discussing this idea in depth, management may decide that the cost and time to add this smart phone 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 smart phone 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.
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.
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.
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.
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 project team, the project charter should summarize the following potential impacts: –
1. 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.
2. 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.
3. 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.
4. Impacts on different areas of the organization–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
5. 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 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:
1. 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.
2. A scope management plan that describes how changes to the project’s scope will be submitted, logged, and reviewed.
3. 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.
4. A change management and implementation plan that will specify how the project’s product will be integrated into the organizational environment.
5. 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.
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.
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.