Project chartering notes

From a person who managed to attend the Bay Area XP December session about Project Charting. I note that Brian Slesinsky uses the same email address schema I do (with both .org and -yahoo).

More information on yahoogroups.com/groups/bayxp

A project charter is an agreement between the developers and 
the gold-owner (project funder, money spender).

- No technology, protocol, user interface, or other design 
  decisions.  
 
  The charter assumes the project will build a black box 
  containing perfect technology.

Prerequisites for charter:

Vision: hazy statement of the overall company goal (1 sentence)
Mission: the direction we will take to achieve that goal (1 sentence)

The Vision and Mission are persistent across multiple projects.

Project Charter components:

External Objectives:
   - not a feature list or a list of stories
   - a binary, measurable way of evaluating the product or 
     service (success or failure)
   - has an assessment date attached (time at which we 
     measure)
   - may be multiple, sequential objectives (milestones), or 
     repeated assessments
   - out of the team or gold-owner's direct control
   - hard evidence used by gold-owner to justify expense
   Examples:
     - car gets X miles per gallon (but be careful not to 
       make it a feature list)
     - survey of beta-testers shows that 90% are satisfied 
       with the beta version
     - three out of the top five consumer magazines give it
       a positive review
     - three of five main suppliers order the product
       (but typically not sales goals since that's too 
       late/indirect for software developers)

  Internal Objectives:
   - things like improving reuse, process maturity, etc.
   
  Project Boundaries:
   - names the external actors
   - names their inputs and outputs
     (doesn't include technology; no specified protocol)
   - events:
   - actor-initiated, detectable events
   - scheduled events (e.g. due date arrives)

Committed Resources:
   - money, people's time, tools
   - work environment
   - access to information
   - access to decision-makers
   - permission to iterate (don't ship the demo)
   - agreement to re-negotiate charter if a committed 
     resource becomes unavailable
   - the developers must say no if committed resources are
     insufficient

Authorizing players:
   - must be able to make a decision on two questions, and 
     make it stick:
        - Is what we've done so far okay?
        - Can we continue?
        - approve and champion objectives
        - must be actual people, not policy or job titles