Prove It with Working Software
In the Unified Process, the primary goal of the Elaboration phase is to prove that the architecture works by having a small team, typically the people who form the core of the development team, build an end-to-end skeleton of the system. You do this by implementing just enough functionality described by the technically most difficult requirements. When it comes to package implementations, the goal is to install the package and do just enough of the technically difficult integration work so as to determine if the package will work within your environment as promised. The skeleton that you build during Elaboration will be fleshed out during Construction.
To keep this as agile as possible, remember to do just enough work -- Elaboration should take a couple of weeks, not a couple of months or years. If integrating with your existing accounting system is critical, then do just enough work to connect with that system and share important data. Although you may eventually need to share 2000 data elements with that system, you can likely prove that the package integrates well with the system by sharing only 50 elements for now. Don't worry, you'll do the work to handle the other 1200 during the Construction phase (with an iterative approach you'll also discover that you didn't need as much as you originally thought). Remember that you only need a good gut feel as to whether the package will work, not a detailed comprehensively documented assessment, so strive to only do just enough work during Elaboration.
The 50 data elements that you choose will often be driven by their semantics--pick the elements that are crucial to your success as an organization. If the package doesn't support your data semantics, if you can't translate between the semantics supported by the package and what you desire, or if you're unwilling to change the way that you work to support the package then you've discovered that the package doesn't really meet your needs. When this is the case, you'll need to work with the package that is the next best option on your list, if one is still available. If not then that's an indication that you either need to give up on the idea or build the system yourself.
An important architectural issue that you need to address during Elaboration is to validate the effectiveness of the modification strategies for the package. Do you modify the package's behavior through configuration files or tables? Do you update specific portions of the source code? Can you update the database schema to add your own data elements? How are vendor updates handled? You'll have hopefully identified these strategies through your initial analysis during the Inception phase, but now is the time to prove how well the strategies actually work.
Agile In the Small
Once you've made it into the Construction phase you're very clearly in agile territory. You will prioritize the work that needs to occur to modify the package, each iteration producing working software that implements the highest priority functionality. Because it's a package the 'new working functionality' produced, each iteration is actually existing package functionality that's been modified to meet your organization's needs. This may imply actual changes to the package or increased integration with your existing legacy systems -- accessing the remaining data elements from your accounting system may occur several hundred times each iteration until the work is complete.
Recognize that you're on a very slippery slope when it comes to package modification because with an iterative approach it's easy to do 'just one more iteration' to get it right. The point is that your product owner must heed Capers Jones' good advice -- if you need to modify more than 15 percent of the package then you're probably in trouble -- and rein in their desire to modify the package until it perfectly meets their needs. My advice is that if you need a perfect implementation then a package implementation isnÕt for you and instead you'll need to build from scratch.
An important consideration will be to stick to the modification strategies supported by the vendor -- if you stray from them you will in effect end up owning the code and it will be difficult to take advantage of new releases of the package. A lot of the work will likely be around data semantics, either putting transformation code in place or refactoring your existing data sources and systems to conform with the semantics supported by the package.
Minimally, agilists do developer regression testing throughout the project, and better yet take a test-driven approach to development. This can be problematic if the package that you've chosen doesn't come with a regression test suite, although I'd have to question why you'd consider buying a package that wasn't easy to test. Be that as it may, if the vendor doesn't provide an adequate test suite, then you'll at least need to wrap the package with black-box test cases. You might want to consider partnering with the vendor on this or even selling the test suite back to the vendor to recoup your development costs.
The Transition phase is the same as for new development. You'll need to finalize your testing efforts, fix any last defects that you find, announce the system, train people in it, potentially pilot it or run it in parallel with existing systems, and release it into production. I described an agile approach to this work in The Agile End Game.
Parting Thoughts
Package implementations are risky. They initially look great from a business point of view but can easily run into trouble if the bureaucracy gets out of hand. By applying disciplined agile strategies to package implementation, you can improve your chances of success. These strategies are based on putting together a team that you can trust to do the job, allowing them to actually do the job, doing just enough work to make the decisions that you need to, and doing just enough modification to the package to meet your needs.
Many people are worried about an agile approach to package implementation because it differs so drastically from the traditional strategy. The bottom line is that if your organization isn't capable of putting together a small team to give you a good gut feel about a package in a period of a week or two, then there is little chance that you're capable of actually pulling off the full-blown package implementation. We know that the traditional strategy doesn't work very well, so why not 'go at risk' and try an agile approach?
