Scheduling Product Releases

When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?

Jeff Lash has a good article, Set the Right Release Date. Jeff’s style is very distinctive, and you’ll enjoy the way he presents his point-counterpoint positions. In his article, he points out that a release date may or may not have a compelling event tied to it.

A compelling event is one that has financial significance. If you have a release date tied to a conference, Jeff asks – will that conference generate a lot of sales? Or is it just a convenient time to have a release? When you question the motivation for a release date, you may find that it is arbitrary.

• That’s the date because that’s what we decided six months ago. Arbitrary.
• That’s the date because we release on the first of every month. Arbitrary.
• We have to have it on date X in order to be in the stores for Christmas. Compelling.
• The release must coordinate with the refresh of our flagship product or we’ll lose sales. Compelling.

Building a Business Case

Jeff makes a very valid point – when faced with the possibility of slipping the date, you need to be able to build a business case for not slipping before you make the sacrifices required to not slip.

Meeting the product release date might mean working overtime. And that cost can be very high – make sure that the death-march is worth it. It might mean adding people to the project, although that isn’t likely to work. Adding people to an already-late project doesn’t fix the problem in the short term.

Avoiding project delays might mean releasing on-time with reduced functionality. The key to this analysis is to use structured requirements, and trace from the deliverables to the value.

For example, imagine the following hypothetical product:

Order Processing Product

First you identify a set of goals. Then you define the use cases that enable your customers to achieve the value inherent in those goals. Finally you define the requirements that support the use cases.

Example Goals

• Goal 1: Reduce the cost of order fulfillment by 20% – value to customers = $1,000,000.
• Goal 2: Reduce the time that inventory restocking takes by 50% – value to customers = $200,000.

Example Use Cases

• Use Case 1: “Fill Customer Order” – supports Goal 1.
• Use Case 2: “Audit Inventory Levels” – supports Goal 2.
• Use Case 3: “Validate Order Contents” – supports Goal 1.

Example Requirements

• Requirements 1,2, and 3 support Use Case 1.
• Requirements 4 and 5 support Use Case 2.
• Requirement 6 supports Use Case 2 and Use Case 3.
• Requirements 7 and 8 support Use Case 3.

The Unexpected Event

You find out that the development team can not complete the code for Requirement 4 in time. What is the impact of not having Requirement 4?

This is where traceability saves you. If Requirement 4 can’t be delivered in this release, then customers will not be able to use our product to audit inventory levels. This change affects the use cases that are enabled by the release. If inventory auditing is not enabled, then restocking times will not be reduced for our customers with this release. The cost to customers of not achieving Goal 2 is $200,000. Therefore, the cost of delivering without requirement 4 is $200,000 to the customers.

Assume that your pricing model is such that you are charging $50,000 for the product / feature that achieves Goal 2. You will lose $50,000 in revenue by releasing without Requirement 4.

Imagine that you can find the resources to release Requirement 4 (and therefore Use Case 2) on the original date, and the opportunity cost of those resources is $40,000. If you didn’t already know how to calculate ROI, this would look like a good decision.

$50,000 in additional revenue is probably not worth more than $40,000 in additional costs. Revenue comes at a profit margin. It wouldn’t be unreasonable for you to operate at a 40% profit margin. That means that $50,000 in incremental revenue only results in $20,000 in incremental profit for your company. You’ll lose $20,000 if you force requirement 4 into the release without slipping the schedule.

The Analysis

This analysis is simplified. Normally, you would estimate the impact of a delay, which is most likely “get the money later” not “don’t get the money.” With a compelling event, a delay might represent a loss in revenue. Without a compelling event, a delay will be more likely to create a delay in revenue. There are other harder to calculate impacts too – how many customers are gained or lost based upon the consistency of product releases? Have you already told your customers what will be in the next release?

A change to a committed release schedule may have a larger impact than a change in an anticipated or unexpected release.

Conclusion

The important element is to make a reasoned decision, based on financial analysis of the costs of delaying a release (or a feature). You shouldn’t always “stick to the schedule” any more than you should always “stick to the functionality” and slip the schedule.