Managing Software Updates

I'm just back from working with one of our YMCA's for a few days. We installed a software update while we were there, and it got me thinking. Books are written about managing software rollouts in organizations. But what about the minor update? Your vendor has fixed a few bugs, added a few features you and others have been asking for - now it's ready. What planning and preparation is needed before installing? To hear Tim O'Reilly talk, the direction the industry is moving in is to make the software update a non-event. In a now-famous piece, What is Web 2.0?, he claims that the new models have brought about the end of the software-release cycle, and goes on: The open source dictum, "release early and release often" in fact has morphed into an even more radical position, "the perpetual beta", in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis. It's no accident that services such as Gmail, Google Maps, Flickr, del.icio.us, and the like may be expected to bear a Beta logo for years at a time. But your mission-critical systems are NOT Gmail or Flickr. Sudden and unexpected changes in software behavior are not just little treats for your staff, but issues that require policy consideration and training. They can change your workflow. They can expose you to risk. And a day long unexpected outage, like Google's Blogger outage the other day, can be a real problem if it occurs at the wrong time. A real-life example. The changes that we've been making for enhanced credit card security basically narrow the window during which a full credit card number is retained by the system. This has an impact on issuing a credit card refund. During the walkthru of the new credit card features for this YMCA, the team realized staff members now need to ask for the card number again when a member requests a refund. Other minor policy issues came up as well during our walkthru - and these changes needed to get out to the full staff before the new features could be installed. Besides these usage issues, there is risk to consider. There is always a risk of some new problem when changing your software. The more enhancements and fixes in the release, the higher the risk. The more setup and interfacing with other players and systems, the higher the risk. In this example, the big risk is obvious: what if we get the new software set up wrong and it is not communicating with the bank? The users could be out cash! So even for routine maintenance updates in your mission-critical systems, I'd stop, take a breath, pull your technology committee together, and consider the following: Workflow considerations. What are the changes in this version? Do any of them require a policy decision or a change in workflow? Do any of these changes represent a real problem for us? Are there new features we'd like to hide, turn off, or make available only to certain users? Can that be done? Is there any training warranted? Do we need to hold any sort of training or walkthru with a larger group of staff to make sure everyone is on the same page about the changes. Do we have in-house documentation we ought to update? Risk Management Considerations How high is the risk associated with this update? If the risk is high, careful testing is worth the time it takes - if the risk is low, you might be costing yourself money by spending days testing it. How will we determine if the risk conditions are occuring? In this example, how will you make sure the payments are being authorized and settled properly and card numbers properly starred out after posting? When is the best time for us to encounter this risk? For example, if you are expecting a rush of registrations next Tuesday, that's a bad day to make this change. Either do it early enough to be sure you are solid by then, or put it off until after that date. Using this open-eyed approach when scheduling an update with your vendor can make the transition to the enhanced software much less of a hassle and get you reaping the benefits of the new features sooner. Tags: nptech, implementation, tech_planning