At some of the software companies where I used to work, I remember the silence that would fall — not to mention the faces — every time some disgruntled bearer of bad tidings let it be known that yet another software release date had slipped. Sometimes there was a reason, like our biggest new customer wanted a certain piece of functionality by yesterday.

And sometimes there was no reason at all. It was like the weather. It just happens that way. Software always winds up delayed. What can you do?

It turns out there’s plenty you can do to set up a situation at your company where software is released on planned, publicly announced dates — dates that don’t slip.

Yes, it is possible to set software release dates and meet them every time. And the benefits this brings in terms of predictability and stability lead not just to better software development but more motivated employees in any number of departments.

It’s worth every minute of your effort to move your company onto a development schedule with fixed dates. Read on for some suggestions about how to go about it, and what to expect.

Note: A past issue, The Development Plan: a Dose of Reality, provides tips for dealing with hard to schedule development tasks.

[private]

You’re the Salesman

Switching to a development schedule with fixed release dates, dates that don’t slip, is definitely going to be a sales effort on your part.

On the minus side, you have people who don’t believe it can be done, sales reps and executives who want the prerogative to add unscheduled features in mid-stream, managers who can’t recognize reality when it comes to estimating coding and testing time, and developers who don’t want their feet held to the fire for the impossible dates set by these same managers. Various sections below provide tips for dealing with this.

On the plus side, you can propose a way of developing software that has the following appeal:

• Developers know exactly what they’re scheduled to do and don’t spend any down time as project priorities are debated.
• Sales reps can speak with confidence about upcoming functionality, or submit customer requirements that are deal-breakers for new business, and commit to specific dates, dates that are met come what may.
• Marketeers can proactively update their collateral, programs and messages to be ready for release when the software is ready. No more scrambling to catch up, or going out on a limb to describe great features that never come to pass during the lifetime of the brochure.
• Trainers can also prepare their materials for release with the software release.
• QA testers can schedule testing efforts that begin on set dates, and can expect the functionality to be ready for testing on those dates. Boy, does that sound great, or what?

What’s In It For Me?

What you want to keep foremost in your mind is the fact that if you’re going to sell this idea to the management team, you need to explain to each individual what’s in it for them and for the people under them.

Different departments are going to appreciate different benefits. Some examples are listed in the previous section.

And what’s in it for the CEO? Easier sales negotiations for one, when the reps are clear about what they can commit to for which date. But more important is the fact that your software will develop faster and more predictably. Where time (oh, I mean money!) was wasted before, with delays and mismatched schedules between work teams, major departments can do more things with the same number of people.

Same Time Next Year

One way to implement a new system of fixed date releases is to make it easy to remember, by having the dates stay the same each year. I’ve seen companies that do their releases by the calendar year. Development goes from January to December, after which the new version is rolled out to the customer base over a period of months. Everyone in the company always knows when the next version will be released.

Align With Quarterly Quotas

If your sales reps have quarterly quotas leading them to push to close deals at the end of March, June, September, and December, set release dates one month ahead of each quarter: March 1, June 1, etc. They can use the build-up to new features plus a successful release to get prospects off the dime by the end of the quarter.

Shorter Cycles

Once you lose the leeway to bump release dates up or move them back, managers may view a release set for, say, nine months from now as too far off. Try shortening the release cycle so that no release seems very far off. The atmosphere of anticipation remains strong, as does the pride of success when frequent releases appear to be continuously introducing new functionality.

With our typical attention spans, nobody can grasp a 12 or 18 month period of time in any concrete way. But six months? Yes. Three months is even easier. We’re all used to three months with quarterly corporate reporting.

It’s a whole lot easier for the average technical person to estimate work and keep to planned dates in a three-month period than in, say, a 16-month one. You can promise anything for 16 months from now, it might as well be the next century.

Speed up the biorhythms of your development, and you’ll have a more alert, reactive organization.

Internal Cycles

Even though you may decide to create three-month cycles, you are not obligated to release software commercially each time. B2B applications that release software every three months are likely to find their customers begging them to slow down the pace.

You can have internal releases that adhere to the discipline of integration testing and even beta, but don’t go commercial. Want to release every six months? Have a three-month internal release, then a commercial one. How about every nine months? Have two internal releases, then commercial.

Just Say No

Now that having fixed dates means that you commit to a specific set of new features, and new ideas must wait until the next release, what happens? In walks the Vice President of Sales, or Professional Services, or Marketing, or the CEO, stating that you absolutely must have this new feature in the next release. It can’t wait, millions in sales are riding on it.

What you will be thinking in your head, after all that hard work on the development plan, is “No, no, a thousand times no!” While you probably want to be more diplomatic (in the beginning, at least), it’s essential to just say no.

Now, “no” is not very permanent. In the very next breath, you can say: “But we can put it in the next release, and that’s only four months away. Do you think this prospect will purchase and roll out the software before four months are out? (I didn’t think so either.)”

A shorter cycle is the saving grace of the setup, since fixed dates means you don’t introduce unplanned functionality.

When You Can’t Say No

Sometimes, just sometimes, you really do have to get a feature in that isn’t in the development plan for a release that’s already underway.

This is why you want to build in “soft commits” in the expected new features. Advertise them from the very beginning as possibilities. You can cut out one or two of these and replace them with the emergency functionality that has to be in there to sign a contract next week.

With a short cycle such as three months, it’s likely that you can be aware of these potential emergencies during the planning process, and build them into the schedule as fall-back projects, which you won’t carry out unless that all-important contract actually gets inked, at which point you’ll already know what other functionality drops off the list. And you portray that other functionality as a “soft commit”.

Fighting Pushback

As Harriet Lerner, Author of The Dance of Connection, points out, when you make a change to the way you do things, those around you will often react with a “Change back!” response.

Be prepared for pushback. When someone reacts to one of the inevitable difficulties or glitches by stating for the umpteenth time that they don’t think fixed dates will ever work, then it’s time to remind them of what’s in it for them. Go over the benefits, and acknowledge that not system’s perfect. In fact, if you do develop a perfect system, they can rest assured that they’ll be the first to know.

But seriously, fixed release dates benefit just about everybody. Everybody except those people who never want to be pinned down to any date.

Winning Over the Company

Getting everyone on board, I mean really on board, with fixed release dates will take time. Specifically, most people will need to see it work a couple of times before they’re won over.

First, get the support of the management team. Ask the managers who object most strongly to give you a chance to prove that fixed dates work, and to not speak out actively against it at the very least.

Outside of the management team, the majority of your coworkers won’t be actively against the idea. In fact they would probably like fixed dates, but they won’t actively support the new system, either. After they see it work the first time, where you enthusiastically announce to one and all that you have met the dates as planned, they’ll relax and be happy enough. After one or two more on-time development cycles, you’ll have their full support.

Then there are the doubters. They would like to see it happen, but they just don’t believe it can. After one successful cycle, they won’t doubt so loudly, but will need to see a couple more before they’re convinced.

Finally, there are those that don’t think it will work, and don’t think it’s a good idea. And they’re happy to speak up about it any chance they get. The only thing that will win them over is time — give the most difficult ones a year — and constant reminders of how the company is benefiting from the new, more efficient, more predictable, more stable, more motivating software development approach.

Each time a fixed date in the cycle — requirements, planning, development, integration, QA, beta, commercial release — is met, you have the opportunity to send out a general email congratulating those who made it happen, and pointing out that once again, you were on time, and the dates didn’t slip.

After a while, everyone wonders how you could ever have done it any other way.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]