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)  

Project Life Cycle at a Glance

Here’s a snapshot of our patterns & practices project life cycle circa 2005:

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 are 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 are three things that needed improvement:

1. 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.
2. 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.
3. There was too much agreement up front, with not enough ability to coarse correct in the later stages/phases (needed more agility)

You Might Also Like

7 Habits of Highly-Effective Program Managers
10 Things Great Managers Do
Customer-Connected Development
Extreme Programming at a Glance
Portfolios, Programs, and Projects