6.19.2013

Pattern: One Clearly Defined Project At A Time

Applicability

All the time.

Definition

Prefer working on one project at a time. Finish it before moving on to the next. The project should have a definitive start and end centered around clearly defined business objectives.

I don't mean to suggest you shouldn't have multiple projects in your work life. Just prefer to minimize the number within a context, say a team of people working together. That said, there is value in minimizing the number of teams you are involved with :)

Motivation

A common issue in software development is run on development. This introduces many risks:

  • Failure
  • Budget overrun
  • Infrequent delivery of results
  • Inability to measure success/failure of investment
  • Vestigial feature explosion
  • Incomplete feature explosion
  • Confusion about what the software does
  • Confusion about what the software should do
  • Buggy software
  • Lack of real world feedback
  • Lack of learning - reflection rarely occurs
  • Lack of trust - trust is built on results
  • General sadness for everyone as the work drags on with little or no results :(

Mechanics

Constrain each project based on a set of business objectives. Keep the list short and projects will start and end quickly.

If higher priority objectives arise, decide if they can wait. Ask what the value of doing it now versus a few weeks or months from now. If there's really no value (other than maybe excitement) then wait! If not, then decide what to do with the current project.

In my experience, working on clearly defined projects one at a time means we spend less time on each project, we know when we are done and we can quickly move on to the next highest priority objective. This often negates the need to interrupt a project.

Tips for interrupting a project

  • Replacing objectives - New objectives replace current objectives
    • Craft a project to address the new objectives and in the process discuss what has been done for the current objectives.
    • Determine what should remain
    • Determine what should be removed - if the objectives change there are going to be features that aren't necessary. Get rid of them or be prepared to pay to support them in the long run.
  • Different objectives
    • If at all possible discuss how to wrap up the current project with a subset of the objectives accomplished.
    • If that's not possible, put the work aside and switch gears.
      • Plan a time to come back to the current objectives. It's easy for months and years to pass. These easily become features that you may not get any value from but you pay to support.
      • If new and current objectives affect the same system, discuss removing or setting aside the current work so you can focus solely on the new objectives.




comments powered by Disqus