Project Management tan.tplt Module Objectives Develop core competencies in successfully managing software related programs to three key metrics: On time To budget With Quality Start from top down Corporate look first, then focus on program Corporate management for profitability Management to Bottom Line Business Units and corporation as a whole complete cyclical planning process Establish cost and revenue targets Evaluation is against these "bottom line" targets Seduction: Establish low targets and be a hero by (artificially) beating them Management to Variance Much more demanding corporate climate Establish cost and revenue targets Performance is guaged on how close you come to targets Requires better planning skills, provides most cash flow, investment, and profit control How does this impact you? At some level, you will participate in the cyclical planning process You're required to provide project estimates for planning You're expected to execute plans You're evaluation is based in large measure on how well you and your team performs Program Management Skill and art of managing your program (or your contribution to an overall program) to success Program Life Cycle Models Program Planning tools Execution - Status reporting, risk management Program metrics Program life Cycle Models Various models available All share identification of specific lines of demarcation in the life span of a project We'll consider several commonly used models The Waterfall Model Specific project phases Extend through project obsolescence Use milestones for tracking and evaluation Waterfall Model
Phase Deliverable
Planning Charter
  Contract
Execution Prototype
  Beta
  Field Test
  Production
Maintenance Upgrade Plan
Obsolescence Archive Plan
 Compass Point: Project Scope Goal: deliver to time, budget, quality Our discussions presume projects of considerable scope and/or coporate strategic value Smaller projects require scaled down project management (but still often require project management techniques!) Phase one Planning: the Charter Charter identifies a corporate (funding) sponsor, document aerial veiw of the project, identifies planning scope - spend this much money and thake this much time to plane the project, hopefully completeable by this date Typically created by a planning or program mangagement group Deliverable: document and signed charter (much like a letter of intent) Phase two planning: Functional spec The purpose of phase two is to produce a document covenant between your funding organization and your execution organization Many organizations have the execution arm create this document to support more rapid cycle time and foster early ownership The activity is fleshing out exactly what the funding organization wants, and identifying what it will take to complete the program in a given time frame. Deliverable: contract, consisting of a reviewed and signed functional spec. (You say you want this: presuming I receive the resources I have identified, I can produce it in this time frame) In software development, sometimes a RAD language such as VB is used to construct a viewable GUI Execution phase: Prototype If possible, a prototype is created to confirm contract information. A prototype is a working product model, ideally created in a production development environment The funding organization "signs off" on the prototype, which is often tested with costomers. If significant issues are identified in the prototyping state, the contract may be revisited Execution phase: Beta Whe have a live one (or two) Early version of product, benchtested and typically run at a couple of "customer" locations Usually choose forgiving, loyal, and early adopter customers as beta sites Beta - working, benchtested product almost ready for field test Execution phase: Field Test Working product run at carefully selected customer locations Field test plan is a reviewed document that uses carefully selected (and presumably representative) sites Ideally, entire gamut of product (shipping, manual, support, desk, etc) is exercised At the conclusion of field test, the project team typically reviews which product blemishes need to be addressed before production. These corrections recycled through testing. Execution phase: Production Deliverable: To volue (capacity or ramped) availablility of complete product Includes Phase: Maintenance Support required after program is in production Activities address quality issues as well as version upgrades Phase: Obsolescence Activity: responsibly retiring a product in-place support beyond last product sale Often handled through financial agreements with customers Product archived, and team goes through documented debriefing. Next Look: Tool sets Various tools exist to support activities across project cycles Next lecture we will look at project planning tools