Project Charter

The Project Charter – Sign Off

Professor of Project Management Project Initiation
Initiation

The Project Charter can be looked at as a contract between you and your project sponsor or you and your manager. It documents your understanding of the expectations of the sponsor and what you are expected to deliver and when. Like any contract, it should be concluded with a signature indicating agreement.

Why get a real signature? It is amazing how people will pay close attention to what is in a document when they have to sign their name to it! I have seen cases on my own projects as well as those I consulted on where misunderstandings are cleared up prior to charter sign off. This has and will save many hours of effort avoiding taking a project down the wrong path. For these reasons I highly recommend getting a real signature and posting a PDF image of the Project Charter in the project repository.

Once you have a signed-off charter, you now have one of the deliverables subject to formal Change Management. Any request that would change any component of the charter should have a formal change benefit/impact statement signed off and the Project Charter should be changed to a new version and signed off again.

In my next post we will move to the Planning Phase and begin a multi-part discussion on the Project Management Plan.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

Advertisement

The Project Charter – Constraints

Professor of Project Management Project Initiation ,
Initiation

Constraints are any limitations to solution options that have been imposed on a project. It is important to know these early on so time is not wasted pursuing these options. Here are some examples:

  • The solution must work with Microsoft Edge as that is the company standard
  • The solution must be an Oracle product for seamless integration with our other Enterprise systems
  • The new department we are adding as a result of this project must fit into this 30′ x 50′ area

When project constraints are uncovered, be sure to understand the reason why. It is possible some constraints could be removed. I was involved with a project where the service provider was already selected but without looking at the competition. I convinced my business partners to conduct formal “Request for Proposal’s” with the leading competition and the result was a different provider was selected.

Constraints are included in the Project Charter so that the Sponsor and Core Project Team understand and agree.

My Kindle Book, “Project Management For The Real World”, is available at

http://www.amazon.com/do/b089krddvn

Now available in paperback!

The Project Charter – Issues

Professor of Project Management Project Initiation ,
Initiation

Issues are any event or known problem that will negatively impact your project’s schedule, scope, budget or quality. Issues differ from Risks in that Issues are 100% will or has happened whereas Risks may or may not happen with a probability less than 100% and greater than 0%. Risks that are not actively managed are more likely to become Issues.

At Project Charter time, you want to highlight the most severe impacting issues. Look specifically for the impacts in the following areas:

  • Schedule – issues that will delay your project start, or impact key milestones and the target completion date.
  • Scope – Issues that can prevent you from delivering the defined project scope
  • Budget – Issues that can cause the project to go over the allowed budget
  • Quality – Issues that will affect the quality of the delivered solution

In a future post I will address Issue Management in detail.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

Now available in paperback!

The Project Charter – Stakeholders

Professor of Project Management Project Initiation ,
Initiation

Project Stakeholders are the people and entities affected or impacted in any way by the project. Defining this list is critical in communication planning. It will also help you in defining the project scope. Stakeholders are identified by reviewing the Project Scope and consulting with Subject Matter Experts for the domain of the project.

There are two classifications of Stakeholders:

  1. Those that will be needed to perform project tasks.
  2. Those that will interact with or receive the product, service or result of the project.

The Stakeholders in classification 1 are the members of your project team. Some of these will constitute your core team and will be needed full-time or near full-time for the duration of the project. Others will be needed only for specific tasks over limited periods of time. When you have this list I recommend creating a spreadsheet with these names along with their roles, responsibilities, manager, and contact information.

The Stakeholders in classification 2 are your project’s “customers”. These are the people who will be the target of a formal Change Management strategy (more on that in upcoming posts). The success of your project will often depend on how you manage communication and change with this group of Stakeholders. The five key areas for managing this group of Stakeholders are:

  1. Awareness – communicate early and often with this group before they are impacted
  2. Desire – impart an understanding of why this is good for them and for the company
  3. Knowledge – training in new processes and behaviors
  4. Ability – make them successful by setting up a support structure
  5. Reinforcement – monitoring the expected behaviors and business outcomes and being prepared to make adjustments as new knowledge comes to light

There are some Stakeholders that can be a member of both groups. Typically members of the Project Sponsor’s team will participate in the project and also be affected by the result.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

The Project Charter – Timeline

Professor of Project Management Project Initiation ,
Initiation

The Project Charter should contain a high-level timeline so that expectations can be set and preliminary commitments established. If not enough is known at Charter time to be reasonably certain of this timeline, then it should be noted as to when the baseline schedule will be established.

The timeline will contain elements that depend on your organization’s methodology. You will want to note target completion dates for major milestones and phases. Here is an example for a software development project:

  • Requirements – Jan 31
  • Design – Feb 23
  • Development/Unit Testing – April 8
  • System Testing – April 30
  • User Acceptance Testing – May 21
  • Transition to Production – June 8
  • Production Stabilization – July 8

For projects not involving software, your phases and major milestones will be named according to the nature of the project. Here is an example where the project is to order and install new equipment in several locations:

  • Scope established – Jan 15
  • Products Ordered – Jan 30
  • Products Tested – Feb 21
  • Products installed in pilot locations – March 15
  • Products installed in all locations – June 1

Note that this doesn’t imply a strictly sequential order. In most projects there are phase overlaps.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

The Project Charter – Scope Of Work

Professor of Project Management Project Initiation ,
Initiation

At the Project Charter level, the scope of work is not meant to be all-inclusive and at a fine level of detail. That is done when detail requirements are addressed.

You can derive part of the scope by taking each Project Objective (refer to the post on Project Objectives for more detail) and listing the major work activities needed to accomplish that objective. These should be at a level of detail enough to get a high-level understanding of the effort and duration of the activity. This is a judgment call and varies by type of project.

In addition to the above, you can list the major business processes that are impacted by the project. A process is impacted if one of the following is true:

  • there will be new or changed process steps
  • there will be new sources of data or information for the process
  • there will be new recipients of data or information from the process
  • there will be changed or additional owners of the process.

Listing the major activities and the impacted processes should be sufficient for scope at the Project Charter level. Your organization’s standards may require more, but this should be the minimum.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

The Project Charter – Project Objectives

Professor of Project Management Project Initiation , ,
Initiation

In the previous post I defined and discussed Business Objectives and their importance. Project Objectives are very different from Business Objectives. I have seen Project Charters with the two types of objectives mixed into one objectives section and I find it very confusing. I recommend placing Project Objectives in its own section.

Project Objectives should satisfy the following criteria:

  • Produce a product, service or result that survive and are maintained after the project is over. Some examples of this are (1) a new business “Standard Operating Procedure”; (2) new software installed that meets all of the acceptance criteria.
  • Each Objective should have a definition of “done” that is agreed to by the Project Sponsor and the Project Team. This definition should be measurable and verifiable.

Project Objectives are important for the following reasons:

  • They define the scope of the major deliverables of the project
  • They will be used to define much of the activity scope of the project
  • Meeting all of the Project Objectives is one of the criteria for project closing

The combination of having well defined Business and Project Objectives will get your project off to a great start and help keep it on track. Take care to get these right.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

The Project Charter – Overview

Professor of Project Management Project Initiation
Initiation

When I teach Project Management the Project Charter (sometimes referred to as “Project Definition”) is one of my “points of emphasis”. I state that if you only do one of the things I teach, then the Project Charter is it. All of your planning and execution will be based on the elements contained in there.

The Project Charter is important enough that I will be dedicating the upcoming blog posts to examine the contents in detail and include examples. Here are the sections:

  • Business Objectives
  • Project Objectives
  • Scope
  • Timeline
  • Stakeholders
  • Risks and Assumptions
  • Issues
  • Constraints
  • Dependencies
  • Sign off

On the TV Series “CSI” analyst Gil Grissom once said “Sometimes you have to slow down to go faster”. This applies to the Project Charter. Many involved with a project want to move forward quickly and don’t want to spend the time on this key deliverable. This is a huge mistake. Having a well defined and signed off Charter will make all of the subsequent phases of the project move faster and more smoothly.

My Kindle book, “Project Management For The Real World”, is available at

http://www.amazon.com/dp/b089krddvn

The Project Charter – Sign Off

Professor of Project Management Project Initiation

 

Initiation

The Project Charter can be looked at as a contract between you and your project sponsor or you and your manager. It documents your understanding of the expectations of the sponsor and what you are expected to deliver and when. Like any contract, it should be concluded with a signature indicating agreement.

Why get a real signature? It is amazing how people will pay close attention to what is in a document when they have to sign their name to it! I have seen cases on my own projects as well as those I consulted on where misunderstandings are cleared up prior to charter sign off. This has and will save many hours of effort avoiding taking a project down the wrong path. For these reasons I highly recommend getting a real signature and posting a PDF image of the Project Charter in the project repository.

Once you have a signed-off charter, you now have one of the deliverables subject to formal Change Management. Any request that would change any component of the charter should have a formal change benefit/impact statement signed off and the Project Charter should be changed to a new version and signed off again.

In my next post we will move to the Planning Phase and begin a multi-part discussion on the Project Management Plan.

The Project Charter – Constraints

Professor of Project Management Project Initiation

Initiation

Constraints are any limitations to solution options that have been imposed on a project. It is important to know these early on so time is not wasted pursuing these options. Here are some examples:

  • The solution must work with Microsoft Edge as that is the company standard
  • The solution must be an Oracle product for seamless integration with our other Enterprise systems
  • The new department we are adding as a result of this project must fit into this 30′ x 50′ area

When project constraints are uncovered, be sure to understand the reason why. It is possible some constraints could be removed. I was involved with a project where the service provider was already selected but without looking at the competition. I convinced my business partners to conduct formal “Request for Proposal’s” with the leading competition and the result was a different provider was selected.

Constraints are included in the Project Charter so that the Sponsor and Core Project Team understand and agree.