Compartilhar via

Project Life Cycles at patterns & practices

  • Artigo

Note: This article is updated at Project Life Cycle at patterns & practices.

Periodically I like to revisit our project life cycle in patterns & practices. I like to see how it's shape-shifted over the years.  (Note - our project life cycle wraps our product cycle)

patterns & practices Project Life Cycle Circa 2005
Here's a snapshot of our patterns & practices project life cycle circa 2005:

PAGProjectLifeCycle

I used this as a baseline to reflect against.  Here are the phases, stages, and milestones:

Phases
Projects cycled through the following phases:

  • Planning
  • Design
  • Implementation
  • Stabilization
  • Release

Stages
Stages included:

  • Requirements
  • Specifications
  • Iteration 1
  • Iteration N
  • Final Test and Edit Pass
  • Production

Milestones
The milestones included:

  • Proposal Approved
  • Vision Scope Approved
  • M0 (Milestone Zero) / Specifications Approved
  • Technical Review and Solution Approved
  • Test and Edit Complete
  • Go / No Go
  • Customer Availability

Three Things That Worked Well
Here's three things that worked well with the original project cycle:

  • There were clear phases, stages, milestones, and deliverables, along with criteria.
  • The project cycle was decoupled from the product cycle.  This gave management a simple frame for understanding projects.  This also gave each project flexibility to choose the most appropriate software development methodology depending on the product.
  • There was sufficient time between key milestones to provide a frame + air-cover.  This helped avoid randomizing engineering and being able to see the forest from the trees.

Additionally, the key milestones such as Vision Scope and MO were something of a ceremony and tended to include the right representation across the p&p team.

Three Things That Needed Improvement
Here's three things that needed improvement:

  • It was a lot of overhead for smaller projects.  It worked well for larger programs (collections of projects), but it was tougher for individual projects.
  • It was tough to bootstrap projects.  M0 and Vision/Scope could be especially tough.  In retrospect, there were two key issues: 1) asking the right questions at the wrong time (premature) 2) chickens with controlling votes over pigs. (See Turning Chickens Into Pigs.)
  • There was too much agreement up front, with not enough ability to coarse correct in the later stages/phases (needed more agility)

Comments

  • Anonymous
    August 04, 2008
    Thanks for another great post, You mentioned that you projec needed more agility! What do you think of iterative design? It seemed that all of your team's design was done before impl. started ... I have to add that iterative design causes scope changes constantly and senior managers in my company don't like that ... too much agility! The stages and phases that you described very well would match the requirements needed to manage my manager's expectations, though:)

  • Anonymous
    August 05, 2008
    The comment has been removed