When it comes time to create the plan for the software development phase of the next cycle, Product Managers often find themselves faced with the same hurdles again and again. This is partly due to the typical personalities found among programmers and software engineers, who demand precision, details, and a clear answer for everything.

As planning jumps quickly to the details, the same objections are raised each time. How can we plan for bug fixes when we don’t know how many there will be? How are we going to rewrite the code in Java when there isn’t enough time with the release dates you’re giving us? We can’t just refuse when Marketing asks for our help with trade show demos!

I have witnessed countless planning sessions where these questions caused progress to grind to a halt. The fact that there were no satisfactory answers was used as a justification (meaning excuse) for loose planning, not setting hard and fast completion dates, or lengthening the development cycle. What resulted was confusion, slipped dates, extensive delays (like taking twice as long as originally promised, always a confidence builder), and the failure to implement significant improvements in architecture or capabilities for years at a time. All this while the competition continued to make progress.

I have also seen software development plans that address all the typical questions and more, and resulted in stable, predictable development that met commitments and moved the product forward. Here are some tips to break through common barriers to good development planning.

[private]

Requirements For Everything

Here’s a tip that applies to all the different issues treated below. Requirements represent all work needed from the Development function. Therefore, include all the non-coding requests that are required by the company. That means third level customer support, helping Marketing with trade show demos, internal training, etc. Such needs are no longer a disruption of the critical path but ones that have been accommodated in the programmers’ schedules.

Get Over the Commitment Problem

Everyone gets stuck on the old “How can we possibly commit to completing all these things by the release date?” problem. Because of course someone has thrown in more requirements at the last minute.

The answer is: don’t commit to them all. Make some of them “hard commits” and some “soft commits”. The hard commits will be done unless something unforeseen arises or a dependency is not met. The soft commits may get done if luck is with you and time permits.

In a highly political situation, I’d even take a couple hard commits and make them soft ones, so that you wind up beating, not just meeting, expectations.

Fixing Bugs

So how do you plan for bug fixes when you don’t know how many bugs there will be? It’s a fair question, and the answer is: you estimate the time, either as a percentage of time, or scientific wild-assed guess, or based on past experience (here’s where the developers can submit estimates of time spent fixing bugs last cycle). Then build that estimate into the plan.

The number of new features that can fit in the next cycle depends upon the time left over after bug fixing and other such needs. This also has the advantage of making the trade-off crystal clear between poor quality in the last release and your ability to move forward in the current one.

Beta Program Support

This one uses the same trick as for bug fixing. Estimate the time needed by engineers or programmers to support the beta effort, and build the resulting number of days into the appropriate individuals’ schedules. To a certain extent, more so than bug fixes, beta support can be scheduled on specific dates.

Sales and Marketing Support

Same as for bug fixes and betas, only I bet one of the problems is that you can never predict when someone’s going to need something. Build the time in, then deal with scheduling the effort according to the next tip.

Unpredictable Dates

It’s all very well and good to set aside a block of time, but the problem with things like bug fixing and sales support is that you never know when it’s going to hit.

This one takes either very tight follow-up on the part of managers or decisive time management on the part of programmers and engineers. Say that a programmer has two months for coding. Bug fixes will take up 20%. One option is to make the schedule so that the first day of each week, for eight weeks, is allocated to bug fixes. At the end of each week, the programmer looks at how much time was actually spent on bug fixing. If less time was spent than was allocated, the programmer should be ahead of schedule on the regularly scheduled work. Time not spent gets moved to the next week. If more time was spent, then the programmer will usually be behind schedule on regular development. Extra time spent gets taken off the following week’s allocation.

You could try the same thing using a longer timeframe, where you put the eight days of bug fixing as the first task on the schedule. The trick here is that the engineer must have the discipline to track, each week, whether they’re on schedule given the time actually used. Their schedule may say day eight of bug fixing, but no fixes were requested yet, therefore the engineer is really on day eight of the next task. This works if you’ve got the right mentality among your developers.

Setting aside time based on estimates for needs whose dates cannot be predicted has one pitfall: if the estimated time isn’t actually used, you absolutely don’t want this time to be wasted. Have back-up work from the requirements, where it is clear that an enhancement will make the release only if you require less bug fixing, beta, or sales support than was estimated. Have the developers ready to jump onto these extra projects when they have completed their planned enhancements.

External Dependencies

Another challenge is planning for tasks with outside dependencies. The requirement may call for assistance from a third-party partner to integrate with their product. An enhancement may require specific research findings from Marketing in order to know precisely which features go into it.

Such tasks can still be planned. Just make sure that the dependency is written loud and clear, with the associated risk documented in the plan as well. For example, the dependency reads: “Database schema information required from Company X in order to tie in to their database.” The corresponding risk is: “If Company X does not supply database schema by x date, this task cannot be completed for this release.”

If anything, this turns up the heat on Marketing or partner contacts to do their part if they want to see the enhancement that comes from their effort.

And just like work with unpredictable dates, have back-up projects in case the dependencies are not met. The key is not to have progress drag to a halt because of uncertainty with one project. Make sure the developers have a project in their back pocket.

Migrating to a New Platform

There comes a time in every product’s life – more and more frequently these days – when you have to move the product to a new platform or architecture, for example recoding a Visual Basic app in Java to stay abreast of the changing requirements in the marketplace.

This is a big undertaking. You can’t afford to screw up the entire product with a bad migration. Lots of companies get stuck at this point. Do they work for 18 months, with no other enhancements except for the fact that it’s now a Web version? New capabilities from the competition are hitting the market fast enough that nobody can afford to do that.

And if your development cycle is short and fast, say three months long, the effort seems impossible within that time frame.

You’re going to have to do some creative thinking. Here’s where some skilled product management can work its magic.

Try this: define this as a research project, where resources are allocated during one release to take a specific component — hopefully one that’s relatively freestanding — and migrate it to the new coding platform. But this research is applied, not theoretical. As soon as you find a successful approach (possibly after trying two or three promising ones) the product of your research is not a report or presentation, it’s a part of the product, as finalized as the timeframe permits.

At the end of the release, the results are demonstrated and explained to the entire development staff, complete with what has been learned about what works and what doesn’t. The next release takes the defined — and applied — approach and uses it to migrate more components. Again, new lessons learned are applied backwards to the first component, and also used in the next release.

Continue this until all components are in the new platform. I think you’ll find that the momentum increases with each release, because you are benefiting from cumulative experience, and you have avoided the trap of spending nine to twelve months going down the wrong path, and having to start over.

Rearchitecting

This is really a version of what I described above under Migrating to a New Platform. This is for such efforts as modularizing or componentizing, or taking a hazily defined or interwoven product and making it more object oriented, separating standard layers from customizations, and the like.

For efforts like these, use the same perspective of research with practical application. Do an initial chunk as research. The most important output of the research is knowing how to implement the effort with the rest of the product, after having applied and tested the method with one portion of the product. And the fact that one portion of the product is already completed is that much better.

Transformational Enhancements

Some enhancements end up creating a sea change in the product, so that their effect is similar to rearchitecting. For example, you may add an enhancement to an ERP package that, in order to add a customer service capability, transforms and presents information in a customer centric way, rather than consolidating steps for internal processes (like shipping) across multiple customers. Taking the customer centric view and making it interactive, where a service call can affect shipping, invoicing and the supply chain, turns the enhancement into a transformational one.

You can use the same research approach with transformational enhancements, with iterative steps applying the lessons learned in each release to continue and expand the transformation in the next release.

So Much Coding, So Little Time

This covers a few of the common hurdles that lie in your way when planning software development to move a product forward. By identifying hard and soft commits, setting aside time for bug fixing and support of other releases or efforts, scheduling for unpredictable requirements, and using an applied research approach to move forward on the most major enhancements, you can clear the hurdles without losing momentum.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]