outline

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
  • Management for variance

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
• • Software
  • Training
  • manuals
  • Support Desk
  • Marketing Literature
  • Etc.

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