Tools of the Trade Part II; Implementing a Requirements Management Tool
Part one in this series described how to prepare, plan, and select a requirements management tool. Selecting the tool is usually the easy part. Implementing the tool without causing mass chaos brings a greater challenge. Now that a tool has been selected, what is the best way to gain acceptance and adoption of the tool within your organization? Change rarely comes without some resistance. This article will address how to maneuver through the resistance in order to successfully implement a requirements management tool by recruiting early adopters, marketing the tool, and communicating the change early and often. Finally, I will address some lessons learned while implementing a tool at several organizations.
Implement a Tool
Production is not the application of tools to materials, but logic to work.
~ Peter F. Drucker
Form a Team
Once the tool is purchased, implementation will take some planning, training, and mentoring in order to effectively rollout the tool. If you haven’t already, start with forming an implementation team. This team will represent the tool and its benefits to the greater IT department. The team will also help plan, create guidelines and best practices, and mentor analysts in their given departments.
Treat this implementation just like you would any other IT project. Start with a project plan, determine implementation tasks, and assign resources. Then execute on the plan.
Once the project plan is in place, get the team members completely trained and comfortable with the tool. At one organization we brought in the tool vendor to train the team members and a few key QA folks. We gave the vendor some samples of use cases from our own projects and utilized these as examples during the training. Team members then began using the tool on their own projects. As we met together we learned from our own experiences and utilized these experiences to draft best practice guidelines for the organization. Best practices included how to structure requirements within the tool, creating templates for different types of projects, naming conventions, and tips and tricks for some of the tool’s quirks.
Recruit Early Adopters
Once the team has established some guidelines and tested the tool out on their own projects, it is time to branch out. Find a few experienced analysts who are willing to be early adopters of the tool. Have team members train and mentor the early adopters on how to use the tool. Early adopters should then go through a complete project lifecycle while using the tool. Periodically touch base with early adopters to apply what they learned from their experience to the best practice guidelines. Also, gather feedback from the developers and QA team members on their perceptions of the tool. Since these groups typically consume the output of requirements gathering, they will need to accept the tool and perhaps adapt their work habits to accommodate a new method for managing requirements. Don’t underestimate this change!
Communicate Early and Often
As with any change, there will always be nay-sayers and skeptics. Implementing a requirements management tool will be no different. In fact, writing requirements in a tool rather than a Microsoft Word document requires a change in mindset. This change is easy for some to make and difficult for others. The implementation team can smooth this transition through communication. Hold forums where the tool is demonstrated, the benefits and limitations are discussed, and early adopters’ experiences are shared. Hold these forums on a regular basis so that teams are kept informed as to the progress, and reminded of the tools benefits.
Word-of-mouth advertising will go a long way to help encourage other analysts to adopt the tool. Have the early adopters talk about their experiences and spread the good news throughout their teams. After trying the tool on a few development projects, one early adopter expressed his enthusiasm for the tool stating “I want to write all of my requirements in this tool.” By trying the tool out on a few simpler projects, he became comfortable with the tool, its limitations, and saw the benefits gained from utilizing the tool. We harnessed his enthusiasm to help sell the tool during an analyst open forum. He also spread the word to his immediate team members and more people signed up to use the tool on their next project.
An Excuse to Celebrate
Finally, use the tool as an excuse for a party! At one organization, to gather excitement for the event, we hosted online trivia questions on our SharePoint site. We posted daily questions and the top five winners received gift certificates to the event establishment. At the event we re-iterated the benefits of the tool, provided links to training simulations, demonstrated examples of successful projects, and distributed the best practice guidelines. Once the formalities were complete, we broke out the entertainment and used the opportunity to socialize with our peers.
When it was all said and done, the tool implementation was really a non-event. There was no loud outcry, no grumbling amongst peers, no mass chaos, and no wasted money. We methodically went about our task of implementing the selected tool, sought help from our peers, and repeatedly delivered the same message throughout the organization which resulted in an easy transition to tool adoption. The complete process took about a year. We steadily increased user adoption during that year and by the time we held our event, most people had already begun using the tool. Compared with the previous implementation of a tool mentioned in part one, where little thought went into the needs of the user community, this tool implementation went off without a hitch.
Final Thoughts
Wisdom too often never comes, and so one ought not to reject it merely because it comes late.
~Felix Frankfurter
Despite the claims of many vendors, no tool is perfect. It is better to discover early on in the process the limitations of the requirements management tool. Once you know the limitations, devise a plan on how to work around the limitations and minimize the impact to your organization.
Test the performance of the application prior to purchasing. One of the biggest frustrations of a tool I have personally used is its inability to perform when multiple users are accessing the repository. Loading some projects will take 10 minutes or longer, while working in other projects completely freezes the tool. If at all possible, learn this before you buy! It will save you great frustration and keep analysts productive.
Never underestimate an employee’s need to resist change. It’s only natural. We all do it. Plan for it, accept it, and continue to communicate the benefits of the tool even when met with organizational resistance. Eventually people come around and the use of the tool will become a part of daily life within the organization.
Finally, learn from your experiences. Have an open mind and listen to the experiences of early adopters and implementation team members. Tout your successes and learn from your failures. Success will, undoubtedly, follow.
Renee Saint-Louis is a Senior Systems Analyst with a subsidiary of The Schwan Food Company where she established and led an Analyst Center of Excellence. Prior to joining Schwan, Renee served as the Requirements Elicitation Practice Lead at a large insurance company. Renee has been a practicing analyst for more than 10 years.