Formal chartering may be the step most frequently overlooked by
organizations when beginning projects. Root cause analysis of project
failures often identifies "poor vision" or "lack of a charter" as a key
reason projects go awry or are cancelled.
Knowing this, why is developing a good project charter apparently so
difficult? It is certainly not due to any complex technical reason,
like not being able to find a word processor advanced enough to
document the information. There are a few reasons so many projects have
ineffective charters.
Business managers that sponsor projects are not experts in project management.
The care and nurturing of projects are merely a fraction of their job
duties. Business managers simply need results. Many times they feel
their responsibilities are complete if they simply identify the problem
to someone (like a project manager) that is assigned to correct it. If
it is the role of the project sponsor to create the charter, they may
need some training or assistance in order to develop a charter that
serves as a foundation for future project work.
It is often not clear which role in an organization is responsible for developing a charter.
Since the business manager has clearly identified the problem to
someone assigned to help (the PM again), they will often revert back to
other duties, leaving the task to the PM. The 5% rule now comes into
play: If a single task is assigned to 2 people equally, each will take
5% ownership of its completion. It should be clearly documented in an
organizations project methodology which role is responsible for
developing the charter.
If it is clearly the responsibility of the project manager, project charters are often only developed half-heartedly,
leading to unclear vision from the beginning of the effort. Many times
the project manager has not been a party to the business discussions
leading to the birth of the project. Once assigned, it is often seen as
a sign of weakness for a PM to go back over territory already covered.
What PM wants to acquire the reputation of not being able to jump in
with both feet and get the project moving? Revisiting lofty ideas such
as business objectives, goals, and critical success factors can come
across as being excessively process-oriented and not focused on
achieving results. As a result, many PM's will move forward with the
uneasy feeling that they are missing something.
As a project manager, what is your role and responsibility when it
comes to chartering projects? Well, since you probably do not control
the funds needed to sponsor a project, it is unlikely that you will
have the gravitas (my favorite word from a previous election cycle) to
charter them yourself. Basically, it comes down to this.
The business managers will often put together an unsuitable charter.
However, this does not mean that you should accept this shortcoming and
move forward anyway. Remember, you are ultimately responsible for the
success of the project, so it is in your best interest—in fact your
responsibility, especially if you are a PMP—to insure an appropriate
charter is in place before investing additional effort/hours/cost.
Here are some items you should make certain are addressed through
whatever chartering process your organization employs. If your company
doesn't even recognize the concept of chartering, you may need to
introduce these concepts a little at a time and walk them through the
process without using any official sounding terms like charter, mission
statement or vision document.
Step 1: Identify and recruit a project sponsor/champion.
There should be a single business manager that has interest enough
in the project to be the guardian of its funding and a representative
to the rest of the management team. The person must understand the
business need and objectives of the project. If you can't find one,
there is a problem. Projects are (or should be) executed to achieve
business objectives. If no one cares about the objective enough to be
champion, management should be asking why you are doing the project at
all.
The PM is sometimes put in this position, but it is rarely
effective. A project manager in a meeting with business managers ends
up like a server at your favorite chain sit-down eatery. ("Hi, my name
is Dave and I'll be your serv—err, project manager today.") If you find
yourself on a project without a clear sponsor/champion in the
management ranks, your best solution is to find one quick. Without one
you will be in some difficult spots very soon. It is a rare PM that can
push back against the demands of the business managers without
succumbing to de facto adoption of every scope addition they can dream
up.
A project without a clear sponsor or champion is seen by business
managers as a free resource to get done anything they need that can
even remotely be related to the original objective. It's like a bill
going through congress; all manner of additional spending gets attached
to it that couldn't stand on its own. This will result in the project
having as many objectives as there are stakeholders and a project
manager trying to satisfy the demands of many masters.
Step 2: Assign a dedicated project manager.
Hopefully, this has occurred, which is why you are on the project.
This aspect of chartering is mostly outside of the control of the
project manager, but here are some aspects where you may have some
influence.
Project managers should be assigned as early in the planning process
as possible. Often, business managers assume that planning the goals,
objectives, critical success factors, and other lofty aspects of
business and projects fall under their purview and theirs only.
However, even if project managers are only there to listen, it will
dramatically improve their ability to manage the project later on;
especially when scope that doesn't help achieve the original objective
tries to creep into the project plan.
You should push to be involved as early as possible in the project selection and chartering process. Your success depends on it.
Step 3: Document the business need for the project.
If a project already has a sponsor, you might assume the business
need has already been documented. This is not often the case. Many
times a project sponsor instinctively knows the benefit but doesn't
formally describe or document it. If this sponsor leaves the company or
becomes disassociated with the project, who will step in and fill the
void if the business need is not clear?
Sometimes, business managers volunteer to be a champion because the
project has a high profile and they wish to be involved in some way. If
this is the case, how will the project survive rough seas like company
cutbacks or a new CIO that wants to review every IT project before
re-prioritizing? If the business need is documented well, even the
project manager will be able to explain its value to the organization.
Understanding the business value will help you keep yourself and
your team motivated. Most people will perform at a higher level when
the objective of the project has a significant impact. Even if the
impact is not grand, having a clear understanding of the value and its
beneficiaries will keep teams better motivated than when no one is
certain why the project is even being executed.
In cases where the business value is determined to be low or
non-existent (these projects do exist), it is better to know this early
and avoid unnecessary spending by the organization. If the organization
initiates the project anyway, as the project manager you should
understand the increased risk of losing funding down the road and plan
accordingly.
Components of a Good Charter
Whether the sponsor, senior management, project manager or all of
the above write the project charter, a good one should address the
following topics.
- Business need for the project – As described above, this is
a key purpose of the charter. Without a clear, documented business
need, a project is a ship without a compass (much less a GPS system) in
uncharted water. The business need should indicate the type of benefits
the project will produce to the organization such as cost reduction,
revenue increase, or increased customer satisfaction.
- Business case – The business case should translate the
business need into dollars (or yen, pesos, euros, pounds, etc.). Your
organization should have a standard format for presenting business
cases in order to evaluate multiple projects for selection.
- High-level project scope – This should be developed from
information gathered primarily from the project sponsor. Since the
sponsor is funding the project, it is important to understand their
vision of the project before suffering the slings and arrows of the
many other stakeholders. Also, while the business need may be large,
the project scope may be limited to specific areas.
- Critical success factors – Identify and document any aspects
of the business, project, project team, schedule, deliverables, etc.
that, if not achieved, would be detrimental to project success. Well
understood and documented CSFs will aid in resolving conflict over
project direction when tough choices must be made regarding project
scope, schedule, cost, or quality alternatives.
- Project constraints and assumptions – Document each of these
early and revisit them often. They should be project level constraints
and assumptions at this point, such as project funding limits, required
completion dates, or quality demands.
- Authority of the project manager – The charter should lay
out the responsibility of the project manager, to clarify their role
when dealing with the stakeholders and organization. Without this
authority description, the project is reliant on the individual skill
of the PM. If there is one role that must be crystal clear to insure
successful completion of the project, it is that of the project manager.
- Signatures – Getting signatures on a charter may seem like a
formality that if skipped is not a big deal (similar to developing the
charter in the first place). Not true. Signing the charter represents a
threshold that says, "I have read, understood and agree to the
information contained in this project charter." Without a signature
requirement of some sort, the charter is just another planning document
that may or may not be reviewed and clearly understood by stakeholders.
Without sponsor and management signature, how will stakeholders not
closely associated with the project have clarity around the projects
importance within the organization?
There are often conflicting opinions as to whether the sponsor,
senior management or the project manager should be responsible for
developing the charter. In theory, the best case is for the sponsor to
develop the charter, but realistically this is often delegated to the
PM once the business need is identified (perhaps superficially) and the
project manager is assigned. If the charter is developed with
discipline, rigor, and the participation of appropriate key
stakeholders, who does the writing and stewarding through the process
of development becomes less important.
Happy Chartering!
