Hello and Welcome to the PM Perspective video on Project Charters.
If you've been assigned to a project and you're looking for some practical guidance, then
you've come to the right place.
Today, we're going to answer the following questions:
What is a project Charter?
Why do I need a project charter?
How detailed should a project charter be?
What information goes into a charter?
What process should you use to draft the charter?
And -- stay tuned -- because we're going to show you how you can download a free project
charter template at the end of this video.
Let's start by explaining what -- exactly -- a Project Charter is...
A Project charter is a document of some kind.
It could be a word document or something like a PowerPoint presentation ... the format varies
as does the name.
In your organization you might have something called a project request that serves the same
purpose as the charter, or -- if you deal with outside clients -- your Scope of Work,
or SOW, may also stand-in for the charter.
Whatever the format or regardless of what you call it, the project charter serves three
basic purposes.
The Project Charter is the document you will use to introduce people to your project
The Charter is created in the early days of your project, at a time where you may not
have on boarded everyone to the project team, a Project Charter is a great way to get a
new team member up to speed once they are assigned to your project.
In addition, along the way, if are changes to the team, as new people come into the picture,
send them the project Charter, it'll tell them everything they need to know to get started.
The second reason for drafting a project Charter is to reach an agreement or get alignment
on the most important aspects of your project.
Such as the objectives, scope, budget and so on.
And finally, once the charter has been created you send the final draft out for signatures
and -- in doing so -- obtain approval to proceed with project planning
So what about the size and level of detail in the project charter?
Given the fact that the Charter is drafted before any real planning has taken place a
Charter cannot, and is not meant to be a detailed document.
It only needs enough information to describe the project and the product or solution it
will create.
At larger corporations I've seen 50 page Charters and I have to shake my head.
The problems with these charters is simple -- NO ONE WILL READ THEM!
And if no one reads them, then you can't use it to achieve the three objectives.
A good charter should be 5 pages or less.
Yep -- you heard me correctly -- 5 pages or less.
And I would try to keep it more on the "less" side -- if you know what I mean.
If someone can't read your charter in a few minutes, it can't - and most likely won't
-- do its job.
Now some of you might be wondering, "if my organization doesn't require a Charter, should
I take the time to create one?"
I will answer that question in a minute, but first let's take a moment to talk about perspective.
Everyone views things in life a little differently.
Take this famous drawing, for example.
Most of us have seen this before.
What do you see?
Do you see the old lady? ...or the young woman?
Most of us can eventually see both but at first glance everyone sees something a little
different.
The same differences in perspective happen when it comes to project scope and objectives.
Everyone who gets involved in your project will see in their mind a slightly different
outcome.
Here's the famous "Tree Swing" cartoon that illustrates perfectly what can happen when
various groups of an organization come together to deliver a product or solution.
Every person who's ever managed a project before has a chuckle when they see this cartoon
-- and why is that?
Because we all know -- it's so TRUE!
There's no way to get around it -- people are people -- and they will all have something
different in their heads when they're first introduced to a project.
This lack of alignment is one of the biggest killers of projects today.
So, if there were a tool that could be used to align and clarify what the project team
was going to accomplish and how they were going to accomplish it -- doesn't it make
sense to use it?
I wholeheartedly recommend you draft one as soon as you can after you've been assigned
a project.
Now let's talk about the various pieces of information you put into a Project Charter.
First, I would put a section that gives background information.
List anything a person would need to know in order to understand why the project is
such a god idea.
Is there a new trend in your industry?
Is the company going through a rough patch?
Is there a new strategic direction being set by the board of directors?
Try to think about what an outsider would need to know if you hired them off the street
and add that information to the background section.
Next, you should have a section that outlines the scope.
The scope should describe, at a high level, enough of the attributes of the end product
so that we don't end up in the tree swing situation.
The scope should also describe the actions the team will take, such as: will your team
design and build the product?
Will you test it?
Will you market it and sell a certain number of units?
The key here is to try and define the boundaries of your project, what is the project team
responsible for, where does the project begin and end? ...and to that end, sometimes it's
also important to explicitly spell out what your project team will NOT do, if there's
any possibility that there could be confusion.
SO if -- for example -- your project team will design, build and test the product but
the sale of that product and reaching certain revenue targets is not going to be the responsibility
of the project team, then you should say so in the scope section of the charter.
After that, you should list your objectives.
The objectives should be measureable.
In other words, you should be able to scientifically prove that you and your project team have
met the objectives.
For example.
"Significantly increase sales revenues" is a BAD objective because it's up to interpretation
as to whether or not you've met that objective.
However, "Increase sales revenues by 15% by the end of Fiscal Year 2014" is a GOOD objective!
After that, we should include a section that lists all of the people involved, sort of
a who's who of the project.
In this section you can list, the PM, the Sponsor and all of the project team members,
or if your team is very large you can stick to listing jus the team leads.
Include enough information in this section so that the reader could tap the right person
on the shoulder if they had questions about the product development environment, or the
methods used for testing -- for example.
The next section should list any key dates or milestones.
It's important to point out that these dates are merely guesses or targets -- if you will.
You and your team haven't completed a detailed design of the project and haven't put together
a comprehensive plan so you won't know what the actual dates are.
But it's good to start off with a general understanding of the timeline the team is
shooting for as it may change or even dictate the teams approach to making it all happen.
After that, Include a section on costs.
Again, this is either a guess or a target that will need to be verified.
It's important to list, by fiscal year, the one-time costs to execute, any ongoing costs
or maintenance the company will need to be aware of.
...and finally, you should have a section that lists any Constraints, Assumptions Risks
and dependencies.
A constraint is an external or internal factor that dictates certain aspects of your project.
For example, if your project is to put on a company picnic and you live in a part of
the world where it snows in winter then a constraint might be that the picnic must be
held between the months of May and September.
Another example might be, if you don't have the ability to hire outside help and you only
have access to one developer, that might be a constraint especially in cases where you
need to write a LOT of code.
An assumption is any condition or situation that you and your project team are relying
on in order to achieve objectives.
For example you're project may be building and delivering a custom module for your ERP
system that promises to yield great increases to productivity over the next five years,
the assumption is that your company will be USING that ERP system for the next five years.
There's a small chance that this assumption isn't true -- since people don't change ERP
systems unless they absolutely have to -- but what if there's someone in your organization
who knows something you don't, who reads that assumption you might be glad you called it
out.
A risk is anything that might get in the way of you and your team delivering on objectives.
If you're building a new office building in Miami Florida, one risk might be the risk
of a hurricane bringing construction to an unscheduled stop or even damaging your building.
Finally, there's dependencies, things that must happen before the deliverables of this
project can meet objectives.
An example of this could be -- perhaps -- you're planning the opening night event for a swanky
new hotel, your project would be dependent upon the completion of the Hotel's construction.
Now that we've got a good idea of what goes into the Charter, let's talk a bit about its
creation.
First, let's discuss who should be involved in the creation of the Charter.
The answer might surprise you.
In many organizations, I watch as project managers run back to their offices and quietly
craft the charter in solitude.
This is a mistake.
Yes -- physically -- the Charter can be created in this way but if you create the charter
by yourself you're missing out on a wonderful opportunity.
The BEST way to create a charter is to get everyone -- the sponsor and the team -- in
a room.
Invite everyone to a Project Charter session that you will facilitate.
As you step through the various sections of the charter you will ask probing questions
and record the answers on a flip chart of white board.
What you'll notice that not everyone is coming to the table with the same perspective.
The conversation that takes place as people begin to align their way of thinking is priceless.
It becomes as much a team building exercise as it is an effort to create a document.
The process of alignment to create the charter is often more valuable than the charter itself,
so I urge you to consider involving your team in a charter creation session.
Once you have all of your information, THEN take it back to your desk to draft the Charter.
Send out a draft and ask the team for feedback.
After incorporating the team's feedback, send it out for sign off.
At a minimum, both you and your sponsor should sign.
Okay -- so being a PM myself I know how little time we have to play around on the internet.
I also know that, if you're like most PM's you are not the kind of person to click like
buttons and leave comments.
HOWEVER, I'd like to ask that -- if you found this information helpful --
please click the like button.
Also, if you'd like to see more of these videos, please click the subscribe link.
And if you have any questions at all -- chances are -- your fellow PM's also have them so
please leave your questions and comments in the comments
section below.
Taking these three actions -- and it shouldn't take much of your time -- will help other
PM's find this video when they're out searching for advice.
...and I'd like to tell you that we have more resources to help you out.
If you'd like to download a Charter Template to get you started, we have free templates
available for you over at PMPerspective.com Head over to www.pmperspective/resources/templates
and, when you get there, click on the initiation phase to expand it.
Scroll down to the project charter template and click on the download template link.
It's that simple.
You need to be a PM Perspective member to download, so if you see a "become a member"
link instead of the download link, click it and sign up for free using your email address.
I promise we will not share your address with anyone and will not spam you.
We use your email to send you notifications when great new content, like this video, becomes
available.
I've also included a link to the templates page in the video description.
Anyhow, that's it for now.
Hope you found this information helpful.
Take care, we'll see you in the next video!