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.