Project chartering notes
Book page
Written with a loving hand by kitt some time around 19:45 on 21 December 2004
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