1. 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

2. 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

3. 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
stakeholders
3

4. 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 established
4

5. 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
With the integration of SAP and
PeopleSoft we could make the  Build a list of capabilities through the
improvements in the processing of paradigm on the left
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

6. 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?”
1. The goal - produce visual media, events,
and artwork that builds public understanding  Remember the “mission statement”
of climate change and energize commitment
to solutions.
describes how the project, product, or
2. The formal organization – construct a grass service will positively impact the future
roots organization to distribute the media to
schools and environmental organizations
of the firm
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

7. 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
 What does it mean to have a
capability?
 Ask the following questions first to
 How would we put this capability to define the boundaries of scope
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

8. 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

9. 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
Stage Gates and Milestones are  This does not mean the project is done,
interesting to external executives, just that the deliverables are increasing
but they do not measure the physical
progress of the project.
in their maturity as a function of time
Only a some measure of physical  Never measure progress by the
percent complete does. passage of time or the consumption
This can only be done if it is defined resources – only by Physical Percent
before it is reached. Complete
9

10. 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
Project Management means schedule
managing in the presence of risk,
 The same is true for the technical
not just managing the risk.
performance parameters
Risk is Unavoidable
10

11. 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
Focus on Accountability, all other (accountabilities) with the increasingly
“ilities” follow from there
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?
11

12. 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
Build templates show how to define
 Remember – the customer didn’t buy
 Physical percent complete the templates, they bought the outcome
 Testable requirements of the project
 Measurable business value  Use templates sparingly. Focus on
 Agreements on the interfaces
 The coupling and cohesion of the
outcomes. As they say in the aircraft
system components business – the documents don’t fly
This is what adds value to the project
and its deliverables 12