| Usability experts have coined the term "out of box experience" (OOBE) to describe the experience a person has using a computer or other device for the very first time. Some companies excel in creating superior OOBEs, mostly because they care about being excellent in this area. Apple computer has a well-deserved reputation for creating superior OOBEs, starting with the original Macintosh: Simply take it out, plug it in, turn it on, and you're ready to go. This tradition continues with the popular iMac series. In software, the OOBE begins when the person who is going to install the software first acquires it. This could be through purchase of a CD-ROM or DVD at a local store. Alternatively, and increasingly, it could be when the user downloads the software directly onto her machine, either through a technical process, such as secure ftp, or through a more user-friendly distribution process, such as any number of software programs that manage downloading of large files for a user . The Cost of Poor Installation Our enterprise-class software worked great when the server was finally installed. I emphasize finally, because our initial server installation process was so complex and error prone that it required sending at least one, and usually two, members of our professional services team to the customer's site to install the system and verify its initial operation. We didn't think this was a problem because we charged our customers for installation support. Once we created this standard charge, we thought no more about it. Fortunately, our director of customer support challenged our assumptions and analyzed both their real and their opportunity costs. The real-cost calculation showed that we didn't make any money by charging for onsite professional services. Most of time we just broke even; the rest of the time we lost money. Even if we didn't lose any money, however, we certainly lost an opportunity to improve customer satisfaction. The opportunity cost, which measures the alternative uses of a given resource, presented a more sobering analysis. Simply put, was it better to have a member of our extremely limited and valuable professional services team doing "routine" installations or some other activity, such as a custom integration? In this case, common sense was supported by reasonable analysis. The opportunity costs of our poor installation process were substantial, so we took it upon ourselves to improve it to the point where a customer could install the system with no more than one phone call to our technical support team. This turned out to be a bit harder than we expected. At first, we thought we knew all of the problems and how to fix them. We didn't. We eventually used Excel to build a dependency matrix that identified each step of the install and their inter-dependencies. It enabled us to redesign the installation process, removing unnecessary work and identifying good candidates for further automation. The team also did some real out-of-the-box thinking on automation, and used Perl to execute the install. One trick was that the Perl executables were included in our distribution so that Perl could be run from the CD without installing Perl on the target system. This worked surprisingly well (for our server; our client was installed using InstallShield). We eventually achieved our goal, improving customer satisfaction and our profitability at the same time. Perhaps, if I'm lucky, someone from Oracle will read this chapter! | The OOBE continues as the customer attempts to install the software. Common packaged software, such as video games or basic productivity tools, is often installed automatically when the user inserts a CD-ROM and an autorun facility starts up. For high-end professional software, installation can be substantially more complex, possibly requiring one or more programs to be executed to verify that the software can be installed properly (more on this later). It is helpful if the marketect establishes some clear goals for the tarchitect regarding installation. One useful goal might be for an "average user" to be able to perform installation without having to make any phone calls to technical support. Of course, the definition of an "average user" varies substantially based on the kind of software you're building. It could be a schoolteacher with basic computer skills or an MCSE-certified system administrator with extensive knowledge of operating systems. For companies that employ use cases, I recommend at least one that captures software installation. |