Good, Bad, and Ugly Ways to Bring In the Release Date

You haven’t been in product or project management very long if you haven’t already found yourself with a projected product release date that is too late to meet a hard business-driven deadline. When that happens, there are good, ugly, and bad ways to bring the date in. This post will review all three groups so you can use the good ways, experiment with the ugly, risky ways, and oppose the bad ways.

Good Ways to Bring In the Release Date

• Drop or defer planned features. This is by far the best way to bring in a release date, particularly if you realize during initial planning that the projected release date is too late and change the release plan before development has begun. Dropping features from a release before engineering has begun development is cost-free from a technical standpoint, which is why it’s so important to reconcile your functional requirements with available resources before development begins when you have a specific date to hit. Unfortunately, product and project managers often fail to realize that the date will be missed until well along in development, leading to rushed, last-minute feature drops that may prevent the delivery of a compelling, coherent product. If you’re going to cut product features, do it up front.
• Phase features in over a crawl-walk-run period. Without cutting a feature completely, you can often satisfy a customer by giving them a simple or partial implementation in an initial release and following up with an improved version in a later release. For example, you might defer user interface enhancements, ergonomic or performance improvements, automation, or a developer API to a later release.
• Investigate whether engineering is solving more/harder problems than they have to. Engineers usually want very badly to do the right thing because they’ve spent so much of their career cleaning up after others before them did the wrong thing. This commitment to robust design is laudable but misplaced when it becomes over-engineering. When product management fails to give clear guidance about the limits to the scope of desired functionality, engineering may assume it has to develop a better, more scaleable solution than is actually necessary. Having open, collegial discussions about planned features before work begins is the best way to discover such situations. It’s one of the reasons that the conversational model of development, where user stories are the basis for a discussion which in turn is the basis for development, is so much better than writing requirements and throwing them over the wall.
• Make simplifying assumptions. This is another marvelous way to bring release dates in that is cost-free so long as the simplifying assumptions don’t block any critical customer use cases. Make as many simplifying assumptions as you can–but not more than you can! Assume you won’t need to support more than a reasonably expected number of simultaneous users, assume they will rely on a spreadsheet to do data analysis instead of implementing your own robust analytics in the first release, etc.
• Reduce the supported scope of the feature. A classic example of this approach is when you have different customers on different platforms (Windows or Macintosh clients, Windows or Linux servers, etc.) and their requirements are different. By default, engineering will implement all features across all platforms to keep the product’s functionality consistent, and that approach is usually preferable. But when time and resources are limited and you don’t need all features on all platforms, delivering different functionality on different platforms by the necessary deadline is preferable to delivering the same functionality everywhere too late.
• Refine estimates. When the initial release date estimate is too late, engineering can sometimes take a second look and more precisely estimate each item.  They may have produced the initial estimate using quick worst-case estimates for some of the work items. Given additional time to investigate the requirements, they may be able to make the estimates more precise, simultaneously reducing the uncertainty about the date and bringing the date in. Note: this is not the same as “pressure engineering to slash its estimates,” described below!

Ugly, Risky Ways to Bring In the Release Date

Alas, the good ways to bring in the release date often don’t suffice. At that point the product or project manager breaks the glass labeled “emergency use only” and invokes ugly, risky ways to bring in the release date. This is where life gets interesting, in the sense of the ancient Chinese curse.

• Shorten the beta period. The duration of the beta period is everyone’s favorite first target for cutbacks as soon as the schedule is in trouble. It seems cost-free. You’re still doing a beta test and the customers still get to test the product before it’s released. But shortening the beta period is by no means cost-free. A beta period is only really helpful if it includes unscheduled engineering time sufficient to make meaningful changes in response to customer feedback. Otherwise, it’s just a fancy way of determining in advance what will happen when you launch the product as-is but doing nothing to learn from the insights you gain. Why test the result of driving a car over a cliff if you leave no time to change the next car’s course or bring it to a halt?
• Don’t do a beta test. Everyone’s second favorite way to shorten the release schedule is to eliminate the beta testing period completely. After all, you already know what customers want, so you just have to build it, right? So why waste time on a beta that will just tell you what you already know? Of course, beta tests often tell you things you don’t know. Moreover, there is no way to not do a beta test. If you don’t do a beta test, then your production launch itself is the beta test!
• Focus QA testing on areas of change. In an ideal world, you’d do full regression testing on every release of your product no matter how minor. However, in case anyone slept through the last decade and failed to notice, our world is not ideal. Sometimes there are legitimate business reasons for reducing the QA coverage on a release (particularly on a minor, maintenance, or patch release) by focusing QA testing on the areas of the product that can reasonably be expected to have regressed given the code changes that were just made. The problem of course is that while expectations are always reasonable, products may not be.
• Fork your code tree. Engineering and QA love this one, and rightly so. Checkins and testing are much so fun to do, and this approach gives you the opportunity to do every one in two or more places! Plus, it lets your engineers exercise their mental muscles by trying to keep straight which checkin was made in which tree. But sometimes it’s the right move when you need to do some things for some customers and different things for other customers in a short timeframe and for technical reasons can’t do it all on the tip. This is just a specific example of incurring technical debt, since you’ll have to pay the price to merge the tree again later on.
• Ask engineering to work extra hours for a brief period. Engineers generally have an admirable willingness to put in extra effort when there’s a good business reason, you explain the situation clearly and ask nicely, you work with them to explore other solutions first, and there’s no other solution available. I’ve frequently seen engineers volunteer to stay up all night, work through the weekend, and work through a holiday. But asking them to do this is a privilege, not a right, and you mustn’t abuse it. Engineers have families and lives too, and if you chronically invade their nights and weekends, they’ll understandably leave for better-managed companies. Another problem is that engineers are often working extra hours on an ongoing basis anyway, so be careful about assuming that they have much extra to give.
• Incur technical debt. There are all kinds of ways you can borrow from the future to subsidize the present. (People called “politicians” make careers doing this.) You can defer maintenance, refactoring, performance and scalability work, and bug fixes. These techniques all help you in the short run and hurt you in the long run. When you do this, you must clearly communicate to executive management that sacrifices are being made to meet the target delivery date and that additional work will be necessary later to catch up. Otherwise, management will assume it has a clean slate after the release and will overload the schedule again, leaving no time to catch up and causing the product to deteriorate and engineering morale to suffer.

Bad Ways to Bring In the Release Date

The following ways of bringing in a release date are guaranteed to have bad consequences. It’s only a question of when the bad consequences will occur and how severe they will be. So you should not use these techniques. Of course, that’s rarely stopped anyone!

• Pressure engineering to slash its estimates. Pounding the table and demanding that engineering reduce its estimates in the absence of evidence the estimates are inaccurate is stupid. This is completely different than working together in a collaborative, respectful manner to jointly refine an estimate. Estimates made at gunpoint and under demands to bias in a downward direction are less likely to be accurate than estimates made rationally without pressure. Executives who do this are pressuring engineers to lie to themselves and to the rest of the company. This is enormously destructive to engineering morale and for good reason. Once engineering has been browbeaten into accepting an unreasonable delivery date, they will then be held accountable for hitting it and blamed if they miss, even though it’s the executive who insisted on the unrealistic date who will be at fault.
• Arbitrarily slash engineering estimates for specific items yourself. Engineers love it even more when senior executives, product managers, or sales or marketing staff decide they know better than engineering how long a specific item will take and impose their own estimate for the item. People who do this should be required to code the feature themselves.
• Ignore engineering’s overall schedule estimate and impose your own delivery date by fiat. Best of all is when an executive gets frustrated with unpleasant realities and decides to upend the planning process and live in denial by announcing that a complicated release has to be done by a certain date, so it will be. Executives who do this are saying “I don’t care about your professional experience, and I don’t care about reality. All I care about is being able to say that this release will be done by a specific date, true or not, so I can reach a particular goal.” This is toxic for the entire company’s morale and future prospects and for any chance of actually making the date.

All of the above three techniques have the same tragic, fatal flaw. Engineers are often willing to make extra effort when you work with them respectfully, explain the business need, jointly search for alternatives, and find no other way. They will willingly sign up for extra work when they’ve explored the solution space and have reached their own conclusion that that’s the best answer. But you have to earn this willingness by working with them in a creative, rational, professional, and respectful manner. When you behave irrationally or treat engineering with callous disrespect, you kill the golden goose of creativity, innovation, and extra effort from which unexpected good things often flow. Instead of getting employees who willingly sign up to go the extra mile, you turn them into browbeaten, disempowered serfs with low morale and productivity who work less effectively because they know they’re on a death march to meet a date they never believed in in the first place. Even if engineering sucks it up and hits one unreasonable date imposed from above, that’s not a sustainable approach. Serfs run away from the lord’s estate at the first opportunity.

Engineers will often do the impossible when they believe it’s possible. When you arbitrarily impose dates from above, you kill the faith that enables miraculous outcomes. So use good ways to bring in the release date and ugly ways if you must, but renounce bad ways on pain of death for your company’s future!