Project Life Cycles at patterns & practices

JD Meier

2 Aug 2008 11:21 PM

Comments 2

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:

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)

patterns and practices, Project Management, Software Engineering

Comments

Kash Baghaei

4 Aug 2008 3:54 PM

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:)
JD Meier

5 Aug 2008 11:41 AM

Thanks Kash.

I'm a fan of iterative development for the right scenarios. It's great for when you haven't done exactly the same thing before -- since you don't know what you don't know and you need to be flexible.

I've seen the most effective iterative development continuously deliver incremental value and keep the customers involved so there's less surprises. The way to constrain risk for these projects is to fix time and budget, but flex scope.

I can understand the concern around constant scope changes. A few things help:

1. have a vision up front -- if there's too much shape-shifting there may be a lack of vision

2. know the key "tests for success"

3. tune and adjust review cycles so that you can separate the forest from the trees (if you review too frequently, it can be easy to lose the macro view)

If you really need to fix scope, then what I often see is the schedule has to be very flexible and there's often surprises when the scope delivered doesn't match expectations (because people are human and requirements are a tough space -- particularly around user experience)

Keep in mind the figure is circa 2005, but to clarify, the "candidate" design was done before implementation, and shape-shifted as necessary throughout the project. Also, while the project cycle was less iterative, the product cycle was more iterative and incremental.

Also, check a relevant post on my ShapingSoftware blog - http://shapingsoftware.com/2008/06/23/evolutionary-incremental-and-high-risk/