Enterprise Implementation of IBM ALM
Part 1: The Pilot and Implementation for $200M project
Author: Corby James
We helped a large bank implement IBM Rational Doors Next Generation (DNG) for a $200M package implementation and customization project.
Our team delivered:
DNG installation and configuration
Requirements process definition and customization
Development of usage models and training documentation
Management consulting concerning adoption issues
Reduced the time and effort to capture and approve requirements
Reduced the time to do change impact analysis
All analysts now successfully using tools which gives them one source of record for all requirements
They have full traceability from business requirements to data, user interface, external interfaces, etc.
A large, national bank (we call them the Bank) implementing a massive package application for their core banking systems recognized that a lack of automation and tooling for requirements and testing put their project at high risk.
The Bank engaged with IBM to start with Rational Quality Manager (RQM). With the help of IBM, they were able to successfully set up their testing disciplines to use the tool and starting building what will become 20-30,000 test cases. This initial implementation was a departmental level and was put on hardware intended to scale for only the fifty (50) or so testers on the project.
With additional learning through multiple iterations, the Bank saw the following issues and impediments for delivering the project on time and on budget:
The requirements process was almost completely manual. With thousands of complex requirements and a very involved approval workflow, the amount of time it took to get requirements to development was on average around ninety (90) days.
The change management process was highly convoluted and impact of change was completely manual.
The development team sat in India and were challenged to gain appropriate context from what was sent to them.
Past just business requirements, the team captured a series of increasingly detailed system requirements and design documents that were derivatives of the business requirements. These included user experience, data, conversion and interface specifications. Because of the manual process and the extent of the changes, these documents took extensive amounts of time and manual effort to keep in synch.
The quality assurance (QA) group struggled with getting detailed information to build their test cases.
With these issues in mind, the Bank next focused on adopting Rational Doors Next Generation (DNG). Following best practices, the Bank initially engaged us to pilot DNG to assure that it could handle the variety of requirement types, artifacts, and representations. In addition, they wanted to evaluate usability, ability to work with MS Word and Excel documents, and the product scalability. The pilot took several weeks and was completed successfully at which point the bank engaged us to guide them through the full implementation of DNG for this, their biggest project.
Over the course of the next few months, we focused on rolling DNG out to over two hundred (200) analysts. While there were many challenges to this, we can summarize below.
The implementation of the tool was the easiest part of the process. While Rational tools are simple to install, the process isn’t hard given the documentation that IBM provides. The one thing we had to overcome was working with the Bank’s operation team to get permissions set and ports open.
The single biggest impediment to adoption was one of culture and organizational change. We faced strong opposition from some of the team leads that would have ultimately killed the effort if not for a strong and consistent advocate and executive support. Even with this, key decisions on how the tool was implemented were revisited a number of times and compromises were made on the configuration of the tool.
Finally, we had to fight through legitimate issues with DNG. Because of the size and complexity of the requirements, we uncovered a number of DNG bugs and missing features. We also faced challenges getting the reports we needed from the tool.
We also learned a number of lessons from this project.
First, overcoming the organizational impediments isn’t an easy or simple task. We would have failed if the program executives didn’t get behind us. Even with this, we still had to overcome objections and work to get the teams on board by delivering a lot of training and one on one hand holding. So following good PeopleFirst™ practices, adopters should know and understand the proclivity of an organization towards adoption of a specific tool(s). This has to be an honest appraisal. And though this sounds self serving, getting help from someone experience in this area will help.
Next, understand that tools like the IBM ALM stack are very flexible and can be configured to do almost anything. What most buyers don’t take into account is the time and effort involved to configure it to suit their needs. If you have small projects and well established practices, configuration can be fast (a few weeks). If you have lots of different project types, heterogeneous processes, and domain complexity, configuration will take much longer (months). By the way, don’t take this as a bad reflection on IBM’s tooling. This lesson holds true for anything you might implement.
Finally, a finer point regarding configuring a requirements tool is to keep the reporting requirements and capability of the various reporting options front in mind. It is easy when creating attributes and artifacts to forget about elements that might be necessary to get the management reports fully populated.