1. 10 Steps to Chartering the Project
Derived from “10 Project Chartering Tips ” Baseline
10 Tips,
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 f chartering th
t d ti for h t i the
project team
 But these tips gave no substantial
actions or expected outcomes
 This presentation adds to these10
g
good ideas with the p
practices that
accompany the principles
2

3. Charter The Project In Two Steps
 Describing the project through the set
of “capabilities” needed for business
capabilities
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 a d
t e C t e aste a and
Master Schedule to assign
accountability for the deliverables
 The other relationships are interesting
p g
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
th i t ti f d
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,
ft th d f ll ti t
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
g g
to solutions.
describes how the project product or
project, product,
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
p
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
u de stood
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
p
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
st ategy, economic a ue
strategy, eco o c value added, risk,s ,
and needed stakeholder capabilities
8

9. Milestone Based Measurables
 Better yet, create a deliverables based
plan that predefines 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 t at t e de e ab es a e increasing
that the deliverables are c eas g
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
does. p
passage of time or the consumption
g p
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 sc edu e
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
– H
How will we recognize “d
ill i “done” when it arrives
” h i
– 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
f
 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
don t
This is what adds value to the project
and its deliverables 12