« Visualizing Your Project Meetings
Projects Fail Because Project Managers Are Doing the Wrong Project »

Software Projects and Release Dates

February 21, 2010 | Author: PM Hut | Filed under: Project Management Musings

Software Projects and Release Dates
By Melanie Carasso

The thing about software projects is that sooner or later, they’re supposed to be shipped out the door. Preferably sooner. This sounds easy - design some code, write it, test it, document it, and you’re done. The traditional criteria for project success were that the software is delivered on time, and on budget, and meets the requirements for scope & quality.

Another way of thinking about project success is that the software must deliver functionality that your users want. This kind of thinking led to the rise of Agile development - deliver early & often, get customer feedback, embrace scope changes, and ship as soon as you have enough scope & quality to satisfy your users. Working out what ‘enough’ means can be as difficult as creating the software. Luckily, that’s why we have product managers, and lots of other blogs written for and by them.

What happens if there is conflict within your organisation about the stickiness of the release date? Many companies have been trained to declare a release date months (or years) in advance, and then do whatever it takes to meet that date. Date-driven releases make sense in a number of scenarios:

  • Your industry is bound by government regulations (e.g. medical software with fee and drug information that must be updated on certain dates each year).

  • Your company has shareholders who view hitting release targets as one measure of company performance.

  • Your company has quarterly revenue expectations that rely on software releases shipping in that quarter.

  • Your product is affected by seasonal deadlines (”in stores now for Fathers’ Day!”)

  • Your project is bound by date-related penalty clauses (a common occurrence for custom software solutions, but rare for shrinkwrapped software).

  • You have heavy downstream dependencies that are expensive or impossible to move - such as limited integration windows with hardware components; large-scale training or marketing activities; heavily booked QA teams; or locked-in schedules for third-party CD & collateral printing.

If your company or project doesn’t fall into any of these situations, how seriously do you need to take date slippages? If you’re in the luxurious position of market leadership, it’s a valid approach to give your development team more time to get the product right before shipping, even if that means the planned date has slipped once or more. Being a little relaxed about the date means less pressure on your teams, which means less burnout, better morale, and (in theory) a better product.

Which is all good until the competition catches up with you. So give your development teams as much time as they need, but no more. And check your rearview and side mirrors often.

Melanie Carasso is the program manager at Atlassian, an Australian software company that develops collaboration and development tools including JIRA and Confluence. Melanie has been managing software projects and programs for the past 8 years in various regions of the waterfall-agile spectrum, at telecommunications, medical management and industrial automation companies. Before diving into software project management, Melanie worked as a research scientist in microelectronics and fiber optics at Bell Labs and IBM in the US. She holds a PhD in chemistry from the University of Sydney and is PMP certified. In her blog, The Agile Program Manager, she shares her thoughts on managing programs in an agile way.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Sunday, February 21st, 2010 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Isn’t this something that is typically described in the project charter? When this is described correctly, you will always have something to fall back on when problems occur. I believe that expert opinions can be very handy on this topic. Off course, there are always things that come and go, and you’ll have to deal with them anyway, but a good charter will already get you half way there.
Unfortunately a prediction of time will always be a hard topic…

Kenneth van Rumste wrote on February 26, 2010 - 3:43 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories