10 Steps to Chartering the Project




Derived from “10 Project Chartering Tips ” Baseline
              10               ...
Why these 10 Tips and not 10 others?

  A recent Baseline magazine article
   presented 10 tips f chartering th
         ...
Charter The Project In Two Steps

              Describing the project through the set
               of “capabilities” n...
Identify the Stakeholder

          These include the project staff as well
           the representatives from all parti...
Brainstorm Capabilities, Not Requirements

                                            Requirements gathered during the
 ...
The Mission Statement

                                                     Define the mission in terms of
              ...
Put Boundaries on the Project’s Scope

                                         Define the mission in terms of
          ...
Control Non–value Added Changes

              Controlling changes for the sake of
               controlling change adds...
Milestone Based Measurables

                                          Better yet, create a deliverables based
          ...
Set Risk Tolerances for Cost, Schedule, and
            Technical Performance
                                     How lo...
Make Clear Statements Of Ownership

                                      With the RACI diagram built in the
            ...
Have A Few Templates, But Only A Few

                                          Templates are a good starting point, but
...
Upcoming SlideShare
Loading in …5
×

10 tips for chartering a project (v2)

1,176 views

Published on

Published in: Business, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,176
On SlideShare
0
From Embeds
0
Number of Embeds
236
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

10 tips for chartering a project (v2)

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

×