Companies, in the drive to produce new capabilities in their software product and roll them out to the market, run into conflicting priorities. One priority is to keep Development producing new features, where the key is meeting announced dates and moving on to work on the next version. The other priority is for Production to move customers up to the newest software, where the priority has to be doing it at the right time, and doing it right.
When you provide hosted software, you add yet another dimension to the mix. Unlike installed software, where you can send out CDs and let the customers drive their own upgrades, you have to deal with both conflicting priorities, namely Development and Production, because your company has taken on a role that software companies didn’t traditionally have to deal with. That is the role of implementation and production manager, which entails very different priorities from a software developer.
Read on below for a discussion of how these two priorities push and pull you in two different directions and how to handle them.
[private]
The Development Goal: Getting It Done
The challenge with software development is figuring out a way to get development for a given release completed and closed out, so that the Development team can move on to building the next release. After the vast majority of new capabilities are completed, you can often wind up with a period where things are stalled in bug fixing mode. Bug fixing is inevitable, of course, but developer time tends to get wasted during this phase as programmers keep themselves available for constant interruptions to fix defects, and don’t commit time to new work because of that. And managers hesitate to hand out work for the next version for fear it will distract developers.
As a Product Manager who wants to see continued progress towards adding new capabilities, you want to follow a push model for setting development dates. You want to make sure that Development makes the jump in their mind, and in their tasks, towards the preparatory stages for the next version.
That’s one reason why the idea of setting fixed dates for development can be so successful. It provides artificial boundaries around coding work that you can use to push the Development department onto the next version.
The Production Goal: Keeping It Running
It’s a different challenge to get software out into production, meaning taking officially released software and getting customers up and running on it. It follows a pull model, where customers drive the timing of when they want to upgrade and use new capabilities.
Getting software up and running at a customer involves much more than just functioning software. It requires that the customer’s organization understand the new capabilities, learn how to use them, determine how to apply them, train the staff and change the way they work with the software. And since these things are outside the control of your company, which made the software, the timing has to come, to a certain extent, from the customer.
Getting Development Out of the Way
When development of capabilities has been handed off for QA testing and production readiness, Development can start getting in the way. If programmers continue to add new functionality instead of just fixing bugs, then they just add to the testing workload and extend the date when the product can be released.
It helps to begin involving developers in requirements and design sessions for the next set of capabilities as soon as most new capabilities are done. Because requirements fall heavily on Product Management, and so does the preparation for release of the product, it takes careful planning and balancing of your schedule to manage to help with both of these at once.
Keeping Development On Call
Yet even though you want to move Development on to the next version, developers must be available and on call to fix all the bugs as fast as they are found. Developers have to be ready to drop requirements and design work for the next version to respond to fixes to the one about to come out.
One method is to set expectations with developers and testers alike by estimating a certain percentage of time, say 50 to 70 percent, which developers are expected to spend on bug fixing. If the developers understand that this is the mode they need to work in for the duration of the pre-release period, they can adjust. Only if bug fixing time exceeds the estimated percentage do you have to revisit your timelines for the next release.
Work on requirements and design can be done at a high level between bug fixing tasks. It doesn’t necessarily require significant amounts of time so much as close attention and focused thought (though this is not always easy when you’re in interruption mode).
Production: the Right Time
To get a software release to the point where it’s ready for production requires balancing many things. Having online help, documentation, and contracts or packaging prepared is relatively straightforward. The hard part is working as a team to judge whether the remaining known issues and defects are balanced out by the new capabilities that are now like inventory starting to age on the shelf. When the remaining issues aren’t as important as putting the new capabilities to use, you have reached the right time to declare your release ready for production. It’s a call you have to make as a team, and support as a team.
When Customers Put On the Brakes
It’s best to let the customer help drive the process of moving up to the next release. But customers are naturally torn between benefiting from the new capabilities and all the work they perceive they must do before they get there. The amount of work tends to be exaggerated in their minds. So you may wind up with customers who needlessly put on the brakes when you try to move them forward.
It is your company’s job to help nudge some of those customers forward. You can try, as Product Manager, to step in to help whoever is in charge of the customer relationship, perhaps going a level or two higher than the person who is holding the timeline back, in order to get buy-in from the customer’s upper management that the move to new capabilities is a priority.
Another thing to take advantage of is success stories of other customers who have completed the move and are happy. Having some wins under your company’s belt that you can describe to hesitant customers can help convince them that an upgrade is less risky than they might think.
Installation vs. Hosting
The situation is dramatically different when your company is hosting your software product. On the one hand, you have more control of when a customer upgrades. On the other hand, your company is responsible for many production tasks, and may need to upgrade multiple customers and databases at once, if they share code on the same server.
Hosting allows you to follow more of a push model for upgrading your customers, because it is under your control. But you need to be extremely sensitive to your customers and their fear of problems.
Database Upgrades: an Unknown Quantity
One of the biggest unknowns is database upgrades. In any hosted product of any level of complexity which has been in use for a while, each customer’s database has unique data. If customers have purchased a hosted product, they have done so in order to have no headaches when it comes to upgrades. So your upgrades of customer databases must be seamless, and this may well be your biggest challenge.
One advantage you have in a hosted product is the ability to access customer databases (with appropriate permission) in the form of backups you take as part of your normal hosting procedures. Use these backup databases to do a true field test of the upgrade to your latest version, and ask customers to participate by providing them a period to review the upgraded data to verify its accuracy and completeness. When customers see that the data is in good shape, they are reassured and less hesitant about the upcoming release.
Linear vs. Overlapping Phases
One decision you will face is how your company can take advantage of the wrapping up of one release, where developers are doing less and less work, and the starting of the next version, where developers start out doing a little work and do more and more. If you really want to save time and keep momentum going, you can have two versions overlap.
The final phase of one version can take place during a month’s time where you also begin the first phase of the next version. On day one of that month, most of the time, if not all of it, is spent on the current version. By the last day of the month, most of the time, if not all of it, is spent on the new version. Then the current version is declared released.
While the idea of overlapping versions is a good one, I have to say that in my experience I have rarely seen it work. Most organizations I have worked with have been forced to make their schedule linear, where one version is closed out and stopped before work gets underway on the next.
Balancing Push and Pull
I wish I could provide a formula for balancing the push toward new development and the pull of careful production rollouts. What I have found is that Product Management needs to work closely with Development, Production, and all other departments involved to balance the push and the pull. This balance will be different at each company, and perhaps different for separate products at the company.
The balance that is right for you depends upon your company culture, the quality of the code going to QA testing, and the complexity of your product and its database. It also depends upon the number of customers you have, whether they are hosted, and how mission-critical your software is.
As Product Manager, you need to be intimately involved in all these considerations in order to keep the momentum going on your product. You need to push such things as fixed dates for Development, or failing that, dates which slide within well defined parameters according to well defined guidelines. At the same time, you need to help the Production team deliver tightly managed but flexible upgrades to each customer to get them up and running on the new capabilities.
The best part about moving to a new version of software is the point where you let out a big sigh of contentment, knowing that customers are up and running and any major glitches have been worked out. You’ll know you’ve gotten there when you have your first conversation with a customer who is already taking a major new capability, one that you worked hard to define, refine, and develop, for granted.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com
[/private]