10 Steps to Chartering the Project

Derived from “10 Project Chartering Tips,” Baseline

http://www.baselinemag.com/c/a/IT-Management/10-Project-Chartering-Tips/

1

Why these 10 Tips and not 10 others?

A recent Baseline magazine article

presented 10 tips for chartering the

project team

But these tips gave no substantial

actions or expected outcomes

This presentation adds to these10

good ideas with the practices that

accompany the principles

2

Charter The Project In Two Steps

Describing the project through the set

of “capabilities” needed for business

success is the 1st stage

The 2nd stage is to build high level

requirements, feasibility analysis and

the business case around these

capabilities

By continuously focusing on the

added capabilities the temptation to

dive into the technical details too soon

– in the chartering phase – can be

avoided.

The role of the charter is to define the

boundaries of the project in some unit

of measure meaningful to all

stakeholders3

Identify the Stakeholder

These include the project staff as well

the representatives from all parties

affected by the project

Define these members through their

roles and responsibilities (R&R) on

the project

Use a R&R matrix to form the RACI

(Responsible, Accountable,

Consulted, Informed) matrix – focus

first on the Accountability

Use the RACI in the Master Plan and

Master Schedule to assign

accountability for the deliverables

The other relationships are interesting

but not all that useful once

accountability is established4

Brainstorm Capabilities, not Requirements

Requirements gathered during the

requirements session must first focus

on the “Capabilities” of the project’s

product or service, rather than

features and functions

It’s too soon to be defining technical

and operational requirements at the

chartering session

Use a tool like Mindjet's Mindmanager

to capture these capabilities in a

hierarchical manner

Build a list of capabilities through the

paradigm on the left

With the integration of SAP and

PeopleSoft we could make the

improvements in the processing of

accounts payable by closing 3 days

after month end for all tier 1 accounts,

using staff from the regional accounting

centers in North America.5

The Mission Statement

Define the mission in terms of

observable changes in the outcome of

the business processes

What will be different in the business

once this project is complete?

Will we be able to measure the value of

the sunk costs in units meaningful to the

stakeholders?

If so, can we call this the “mission?”

Remember the “mission statement”

describes how the project, product, or

service will positively impact the future

of the firm

1. The goal - produce visual media, events,

and artwork that builds public understanding

of climate change and energize commitment

to solutions.

2. The formal organization – construct a grass

roots organization to distribute the media to

schools and environmental organizations

3. The operational structure – build local action

committees to “pull” this media into

community organizations to increase the

awareness of local actions on the

environment. 6

Put Boundaries on the Project’s Scope

Define the mission in terms of

observable changes in the outcome of

the business process

Connect these boundaries with the

needed business capabilities first

Only then define the top level technical

requirements

Avoid detailed technical requirements

until the business capabilities and their

measure of compliance have been

understood

Ask the following questions first to

define the boundaries of scope

What does it mean to have a

capability?

How would we put this capability to

work to earn its keep?

If there is a new request, how does

it add value to what we have

defined as the project?7

Control Non–value Added Changes

Controlling changes for the sake of

controlling change adds no value

Determine if the requested change

increases the value of the delivered

product or service, if so incorporate the

change

If not, archive the change request in the

change control system for later

consideration

Test each change request against

strategy, economic value added, risk,

and needed stakeholder capabilities

8

Milestone Based Measurables

Better yet, create a deliverables based

plan the pre–defines the business value

or each deliverable

Milestones are simply rocks on the side

of the road you look at as you pass by

Predefined value of deliverables

provides an assessment of those

deliverables at the point in time they

were expected to be delivered

This does not mean the project is done,

just that the deliverables are increasing

in their maturity as a function of time

Never measure progress by the

passage of time or the consumption

resources – only by Physical Percent

Complete

Stage Gates and Milestones are

interesting to external executives,

but they do not measure the physical

progress of the project.

Only a some measure of physical

percent complete does.

This can only be done if it is defined

before it is reached.9

Set Risk Tolerances for Cost, Schedule, and

Technical Performance

How long are you willing to wait to find

out your late, over budget, and off

specification?

Every point estimate in the project is

actually a random variable

Understand the probability distribution

from which this random variable is

drawn

Use this information to model the

inherent risk in the project’s cost and

schedule

The same is true for the technical

performance parameters

Project Management means

managing in the presence of risk,

not just managing the risk.

Risk is Unavoidable

10

Make Clear Statements Of Ownership

With the RACI diagram built in the

previous step this comes for free

Add the top level deliverables

Add the measures of maturity at each

assessment point in time

The result is a Master Plan

A Plan is a Strategy for the successful

delivery of the outcomes of the project

By connecting the people

(accountabilities) with the increasingly

maturity (assessment of physical

percent complete at a point in time) and

risk adjusted forecasts of future

performance – the stakeholder can

answer the question where are we?

Focus on Accountability, all other

“ilities” follow from there

11

Have A Few Templates, But Only A Few

Templates are a good starting point, but

never the ending point

Project success of the depends on

factors not amenable to templates– What does “done” look like

– How will we recognize “done” when it arrives

– How much longer and how much more

money needs to be spent to get to “done”

Don’t be fooled by the templates, they’re

not the essence of project management

Remember – the customer didn’t buy

the templates, they bought the outcome

of the project

Use templates sparingly. Focus on

outcomes. As they say in the aircraft

business – the documents don’t fly

Build templates show how to define

Physical percent complete

Testable requirements

Measurable business value

Agreements on the interfaces

The coupling and cohesion of the

system components

This is what adds value to the project

and its deliverables12