Software Engineering, Project Management, and Effectiveness
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 2005Here'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:
PhasesProjects cycled through the following phases:
MilestonesThe milestones included:
Three Things That Worked WellHere's three things that worked well with the original project cycle:
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 ImprovementHere's three things that needed improvement:
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:)
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/