briteskies-knowledge-base

The Importance of a Project Charter

Dave Balser
10/2014

project-charter-header

At the beginning of every IT project, there is excitement and anticipation. Although everyone involved may be chomping at the bit to start, the first step of any project this involved should be creating a project charter.

A project charter serves as an internal document and contract for the project team. It lays out the scope and objectives of the project, and the roles and responsibilities of the project team members. Going through the process of creating the project charter can often be the most important part of a successful project management process.

Briteskies project charters are generally comprised of the following sections:

  •       Statement of Need
  •       Benefits
  •       Critical Success Factors
  •       Measures of Success
  •       Approach
  •       Stakeholders and Customers
  •       Project Scope
  •       Assumptions, Constraints and Dependencies
  •       Project Team Structure
  •       Communication Plan
  •       Project References
  •       Approval

The primary purpose of the charter is to get agreement on all of these aspects of the project before the project begins. The process of creating a charter is the mechanism that facilitates this agreement. Through the project lifecycle, the charter becomes the reference document for the project manager, stakeholders and everyone else impacted by the project as it states what was agreed upon and how it will be accomplished. 

1. Statement of Need

The project charter begins with a Statement of Need. This brief section highlights the general goals of the project and, most importantly, why the project is happening. Whether it is a software upgrade or complete replatform, the Statement of Need gives the “what” and “why” of the project.

For the sake of example, let’s say we are working on an upgrade. The Statement of Need may look something like the following.

Example:

The Customer’s currently installed version of the software is 1.0. This project is to upgrade the installation to the current version, 2.0. The upgrade is required for The Customer to remain current and retain maintenance and support.

Here is an example of a company that experienced an upgrade with our team.

2. Benefits

This section of the project charter furthers the explanation of the “why” of the project. What will happen and how will it improve the company? It is a statement of the business benefits that correlates to the business case that was made for the approval of the project. It gives a more concrete look at the results of the project and the advances that will be gained.

Following the upgrade example, the Benefits section may look like the following. 

Example:

Along with maintaining support, The Customer should realize the following additional benefits from the upgrade:

  • This upgrade will provide the most updated version of the software, with all the current features and functionality available.
  • The upgrade will provide an opportunity to improve business processes.
  • The Customer will improve the quality of its workforce by training users in current best practices.
3. Critical Success Factors

As the name suggests, this section outlines which aspects of the project are crucial for success. If these select factors are not achieved, the project timeline or budget will surely suffer.

As an example:

  • Strong project management
  • Thorough and complete testing of all business processes
  • Minimal disruption from other projects
4. Measures of Success

The metrics included in this section are those that will determine whether or not the project is successful, and should be directly impacted by the aforementioned Critical Success Factors. These are the specific measures by which the project team and the project itself will be evaluated. 

Example:

  • Upgrade completed without unexpected disruption to the business
  • Upgrade completed within budget and timeframe

5. Approach

In this section of the project charter, we start getting into the “how” of the project. How is the project going to be implemented to address the Statement of Need, Critical Success Factors and Measures of Success? This section is one of the most important to discuss with all parties involved so as to ensure everyone is on the same page with the project implementation strategy and methodology.  

Example:

  • Perform a “like for like” upgrade
  • Implement base functionality without modifying program code.
  • Perform the installation, configuration and testing in an alternate environment dedicated only to this project.

6. Stakeholders and Customers

This lists those outside of the consulting team who are involved and impacted by the project. It serves as the list of those to whom the project team is accountable. If the project consists of multiple phases, it is important to indicate who is affected by which phase. 

Example:

Individual: Role: Affected By:
Mr. Jones Owner/President Phase 1
Mr. Smith CIO Phase 1
Ms. Doe Vice President Phase 1
Mrs. White Customer Service Phase 2

7. Project Scope

Project Scope is a more detailed section of the charter. It is often broken into three subsections: Scope, Deliverables and Out of Scope. The Project Scope provides boundaries for the work, which helps maintain focus and avoid scope creep. This is another aspect that helps to meet timeframe goals. The scope statement in the charter is the reference point used by the project manager to say "yes" or "no" to various requests throughout the process. 

Example:

Scope

  • The upgrade is limited to platform-specific data and interfacing applications and third-party programs.

Deliverables

Often broken into milestones with deliverables tracked accordingly

Milestone: Deliverable:
Technical Phase A detailed go live task list, test scripts and results of mock go live
Go Live Stats reports and issue logs
Post Go Live Support Status reports and support

Out of Scope

Specific call-outs of functionalities or technologies that some may consider in scope. A statement of what is out of scope is as important as a statement of what is in scope to determine the boundaries of a project. 

  • Non-platform applications
  • Functionality not specifically identified in the Scope section

8. Assumptions, Constraints and Dependencies

This section outlines a few crucial parts of the project. The first, Assumptions, lists which responsibilities each party will oversee; such as who is paying for what and which members of the customer’s staff will be available. The Constraints and Dependencies section lays out things that may negatively affect the project and that need to be taken into consideration. This section also includes a list of Risks, which are another important list for all parties to be aware of as the project begins so that proper mitigation strategies can be discussed ahead of time. 

Example:

Assumptions

  • The Customer will staff the internal project team with personnel that have sufficient business and industry knowledge to make key decisions.
  • The Customer will purchase, subscribe to, install, and maintain all necessary third-party applications.

Constraints/Dependencies

  • PTO, holidays and other scheduling constraints that affect project team availability will be published, as they become known.

Risks

  • Code changes required by the project could impact go-live if modifications or custom code are installed after the code freeze date.

9. Project Team Structure

In this section of the charter, the roles of each member of the project team are assigned and explained. Occasionally categorized by customer or development team, this outlines the role, the person assigned to it, and the responsibilities of that role. This eliminates any confusion as to who is responsible for which aspect of the project, and helps ease communication when questions arise.

Example:

Role: Resource: Responsibilities:
Managing Director Mrs. Roberts Business contact, recipient of notifications
Project Managers Mr. Williams Provide project leadership, recipient of notifications
  Mr. Smith  
Senior Technical Ms. Matthews Technical lead for the development team 

10. Communication Plan

The Communication Plan outlines when and how The Customer and the development team will talk to each other as well as the larger customer community. Whether that is through weekly, optional meetings, mandatory daily status updates, or anything in between, depends on the project and the teams involved. The Communication Plan should come from the larger change management process to ensure that everyone impacted by the project receives regular updates. 

Example:

  • Weekly project status meetings will be chaired by the development team Project Manager and attended by The Customer’s Project Manager and all technical and functional resources assigned to the project.

11. Project References

This is usually just a link out to a collaborative website that is assigned to this project specifically.

Example:

SharePoint Project Site

12. Approval

After all of the aforementioned regulations and specifics have been determined and agreed upon, we come to the Approval. This section gives a few statements saying that all involved parties agree with the overall Project Charter and is signed by the necessary parties, just like any other binding agreement.

Example:

The Customer approves this Project Charter. Any changes to this project must be approved, in writing, by The Customer and the development team.

Click to Download Our JD Edwards Methodology

A Great Offer, Just a Click Away

Lorem ipsum dolor sit amet, consectetur adipiscing elit

Subscribe by Email

Comments (1)