10 tips for Chartering a Project
Upcoming SlideShare
Loading in...5

10 tips for Chartering a Project






Total Views
Views on SlideShare
Embed Views



1 Embed 21

http://learn.pmstudent.com 21



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

10 tips for Chartering a Project 10 tips for Chartering a Project Presentation Transcript

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