Scott is Practice Leader Agile Development for IBM Rational.
Whenever you read about agility, 99 times out of 100 it is about new software development. Among those rare writings that look beyond software development, perhaps 1 out of 100 describe how to take an agile approach to package implementations. This is truly unfortunate because package implementations, often referred to as 'commercial off-the-shelf' (COTS) installations, are common in practice. Capers Jones, in Applied Software Measurement, Third Edition estimates that in Fortune 500 organizations, COTS packages account for 35 percent of their total software, for close to 50 percent in medium-sized organizations, and upwards to 100 percent in organizations of less than 100 people. The question then becomes, how can you apply agile strategies to package implementations?
Figure 1 depicts a lifecycle for package implementation, using the terminology of the Unified Process to help you to break out of the serial waterfall thinking that is predominant amongst package implementation methodologists. On the surface the process appears to be serial, but that doesn't mean that your approach can't be agile.
Package implementation projects have the potential for significant bureaucracy -- the desire to make a perfect decision, instead of accepting the fact that what you really need is a good enough decision, motivates management to require onerous levels of bureaucracy that do little more than increase overall project risk. The agile strategy is to focus on high-value activities, to do just enough work to address the goals and to avoid needless documentation and reviews. The most important thing that you can do is to put together a team of competent people who can be trusted to get the job done, and if that's not a viable option for you, then my best advice is to stop the effort right now until you're able to do that.
In the Beginning
At the start of any project, you must choose the right process for the situation you find yourself in. First, make a buy-versus-build decision, and if you want to buy then recognize that you must change your business processes to reflect those of the package you select. Capers Jones reports that if you need to modify more than 25 percent of the system, then it would be cheaper to build a specific system in the long run. He also recommends that you should really avoid modifying more than 15 percent of a package, and that if the vendor is hostile to supporting you if you do modify the package, then his recommendation drops to 5 percent. Second, choose an initial version of your process and the tailor it accordingly. For example, you're likely to follow a different process for a $500 package than for a $500,000 package -- one process size does not fit all.
Assuming that you've decided to buy, the next question you need to ask yourself is whether the package has already been selected. Ideally, all package purchases should be based on technical, financial, and operational merits, but in reality such decisions are often political in nature. When this is the case, there is little value in evaluating candidate packages. This is true even if your goal is to produce the documentation to make it look as if you've followed the process to reach the decision that you've already made -- this is not only blatantly wasteful, it is ethically questionable.
If you really are in a position to select from several options, then you need to base that selection on requirements. This doesn't mean that you need a detailed requirements specification, but it does mean that you'll need more than a collection of user stories written on index cards. It's the need to make an informed decision based on requirements that lead many organizations to believe that you can't do agile package implementations, but nothing could be further from the truth. The agile approach is to recognize that you need a requirements specification and you should therefore do just enough work to fulfill this need. So, you don't need a 50-page specification but you likely do need a five to 10 page spec.
In addition to understanding your business requirements, here are some additional considerations for your requirements specification:
- The technical requirements must reflect your enterprise business and technical architecture vision. The package that you purchase must fit into your overall environment -- it will not exist in a vacuum.
- You need to ask the vendor what tailoring strategies they support. How you will modify the code and data is absolutely critical to development and long-term maintenance.
- Identify the integration strategies that this package supports. The package will need to work with several of your existing systems, and they will only support specific integration strategies.
- Ask about the success rate of the vendor. Are you about to purchase a package that 90 percent of organizations struggle to install successfully?
- You need to specify your quality needs. Does the package come with a full regression test suite? If not, then that will be a serious problem for an agile team because they expect to have such assets.
Once your requirements are in place, you need to identify potential packages. The first step is to do some research online to identify candidates. For larger packages you'll send out a request for information (RFI) to vendors and ask them to rate their packages against your defined requirements, a step that potentially adds calendar time but could reduce your overall cost. Many organizations want to have at least three packages to choose from but sometimes that's not realistic. In many situations, there are only one or two viable contenders (if you're lucky). Adding packages to your list that really aren't viable not only wastes your time, it also wastes the vendor's time.
Once you've gathered information about the candidate packages, the next step is to analyze and then rank your options. This is where many organizations get into trouble because they desperately want to make a perfect decision. The reality is that your choice doesn't need to be perfect, it just needs to be good enough--perfect decisions can be time consuming and expensive to make, whereas good enough decisions are quicker and much less expensive. Say for example you spend three months comparing five potential packages and decide on package C. You purchase C and then two months later a new version of package A is released that is now slightly better than C. Disaster has struck because your decision is no longer perfect! This sort of one-upmanship between competitors happens continuously, so don't get caught in a decision-making spiral.
An important observation is that by the time you've analyzed your viable options, you pretty much know which package is the most likely to meet your needs the best. So, instead of investing time and money in doing a 'bake off' between all of the packages, you should instead choose the best option available to you and focus on proving that it meets your needs. This strategy works because if one package is by far ahead of the pack, then assuming that your initial analysis was done competently, chances are very good that's the package that you'll go with. If several packages are pretty much equal, according to your analysis, then it really doesn't matter which one you start with. If you have the people and funding available to you, then you might want to experiment with several packages in parallel, but this runs the risk of increasing the overall project time due to the additional reviews that you'll need to choose the 'perfect' package.
