Have you ever experienced this? Management attends a trade show and discovers the greatest requirements tool since the bread slicer. It will solve all your requirement issues and produce happy, satisfied business customers - or so the vendor claims. The manager purchases the tool and suddenly it's your job to implement it throughout the organization. "Go forth and do great things." your manager mandates. You walk away dumbfounded wondering, "Where do I go from here?" Experience tells you there is more to it than just purchasing the software; some analysis is necessary in order to successfully launch a new tool at your organization.
This two-part series describes a tried and true approach to selecting and implementing a new requirements management tool within an organization. Based on experience implementing tools at several organizations, this first article describes a method to successfully prepare, plan, and select a new requirements tool. Part two will describe how to successfully implement the selected tool as well as some lessons learned along the way.
Assess Tool Readiness
"Assessing is theory, facts, and art form."
~ Jim Murphy
Through my years of experience I've seen the obsession some organizations have with implementing a tool in order to enforce a loose, poorly followed requirements gathering process - believing that a tool will solve all of the requirements management issues in an organization. However, if poorly implemented, a tool will only exacerbate a poor or non-existent process and wreak havoc on the organization.
As an example, one organization had little to no requirements processes in place. Management was determined to implement a tool in order to enforce a process across the organization. Elaborate rules and regulations were devised by teams of people who were not requirements practitioners. These rules did little but enforce the nomenclature utilized within the tool. Little thought went into the intent of capturing requirements, determining stakeholder goals and needs, and managing requirements over the development lifecycle. What ensued was mass chaos throughout the analyst organization. Analysts were angry at the need to capture requirements in the tool, saw little value in the process, and out-right refused to utilize the tool. The result: the use of the tool was discontinued. Thousands of dollars were wasted on license fees, training, and implementation. Analyst productivity declined and there was a feeling of ill-will throughout the organization!
Don't let this happen to you! Before embarking upon a tool implementation, one should begin by understanding what is expected from the tool and then assess the organizational readiness for a tool. This can be as formal or informal as needed for your organization. The point is to actually look at your organization, determine why a tool is necessary, and asses the readiness for adopting a tool.
Know the Theory
First, have a clear understanding of what the expectations are of the tool and what problems your organization is looking to solve by purchasing a tool. It is a good idea to attack this project with the same analysis skills you would a typical IT project. Begin by writing the vision statement and problem statements. These will give you a clear direction for selecting a tool and guide the team when rolling out the tool across the organization. Some points to consider:
- Determine what pain points you are trying to eliminate by implementing a tool. For example:
- Problem: Requirements are captured in disparate Word documents and continually change without stakeholders being alerted.
Solution: Providing a repository to house all requirements - Problem: Once a project is launched, requirements are difficult to find and rationales for requirements are often forgotten.
Solution: Providing a tool which captures discussion, rationale, and decisions for project requirements. - Problem: Projects are routinely launched with major re-work after the implementation due to poorly defined requirements.
Solution: Providing a tool which illustrates requirements in a manner meaningful to stakeholders - through models, screen mock-ups, use cases etc.
- Problem: Requirements are captured in disparate Word documents and continually change without stakeholders being alerted.
- Determine what goal the organization is trying to achieve by implementing a tool. For example:
- Reduce the amount of money spent on re-work after a project is installed by generating models and written use cases from screen mock-ups to aid in eliciting higher quality requirements from stakeholders.
- Increase speed to market by creating prototypes and generating requirements based on the prototype.
- Document what the vendor has promised (if one has been selected for you).
Get the Facts
The next step is to assess the readiness of your organization. Consider not only how it will impact the analysts, but also the other stakeholders involved. Some points to consider when assessing your organization:
- Is a tool necessary?
- What impact will implementing a tool have on the organization?
- What development methodology is utilized by analyst groups? Is it the same across the organization or do some follow waterfall while others follow agile development processes?
- How mature is the requirements process across all analyst groups?
- Are some stronger than others?
- Are processes similar across groups?
- How disparate are processes across groups?
- Are there additional organizational changes occurring that may impact a successful tool implementation?
- If so, what is the time frame for implementation? Will it interfere with a tool implementation?
- What format are requirements typically gathered in? (e.g. Word document, Excel, e-mail, napkins, hallway conversations, dreams)
- What is the maturity of the PM, Development, and QA organizations?
- How will the stakeholders perceive the change? Are they open to receiving requirements in a new format? Will the process be seamless to them?
During this exercise, capture the risks and issues that may occur if a tool is implemented. Record the response to the risks and issues so that they may be resolved during the tool rollout.
Remember that a tool is exactly that - just a tool. Its implementation will have significant impact on the organization and any tool that is selected needs to be thoughtfully considered and carefully planned.
Based on your assessment, it may be necessary to recommend deferring the purchase of a tool until any process issues are shored up. It is fundamentally necessary to have solid requirements practices in place before implementing a tool. Get your facts in order and make recommendations on how to improve your processes before a tool is implemented. For example, if documenting requirements is sketchy (at best) in your organization, recommend to management that all of IT, not just analysts, be trained in best practices for correctly documenting requirements within your software methodology. Training all of IT sets expectations on what is acceptable requirements deliverables and holds analysts accountable for producing quality requirements.
Create a plan for addressing the issues encountered during the assessment and recommend a time frame for improving the requirements practice, including an appropriate time for implementing a tool. Generally, management will appreciate a well thought out plan, rather than a haphazard approach to implementation.
Select a Tool
A fool with a tool is still a fool.
~Anonymous
Hopefully you find yourself in the situation where you and your team have the ability to evaluate and select a tool, rather than management dictating which tool you must use (or worse yet, one they have already purchased.) If you are able to select a tool, then you are in luck. If not, know that most tools on the market offer sufficient improvement over capturing requirements in an ad hoc manner that some benefit of implementing the tool will certainly follow.
When beginning the selection process, start with the problem statements that were created during the assessment phase. Any tool that is selected will need to address the pain points of your organization. This will help ground you as you begin your search, and keep you from being distracted by the many bells and whistles that companies offer. When it comes to selecting a tool, the most important criteria is that it addresses the pain points you are experiencing. Bells and whistles will only encumber your process rather than enhance it. At its most basic, a tool should enhance your existing process, not detract from it.
As a part of your selection process, determine the criteria which are most important and evaluate the tool according to these criteria. A simple spreadsheet that ranks the criteria for each candidate vendor will help in objectively evaluating a tool. Have each team member rank the features/needs for each vendor which are determined necessary for the tool to succeed at your organization. A scale from 1-10 may be used, where 1 is least favorable and 10 is most favorable. Do the same for the priority column and calculate the total value for the features, and in turn, the vendor's product. Here is a sample:
|
Feature/Need |
Product Ranking |
Priority |
Total Value |
|
Integration with MS Word |
3 |
7 |
21 |
|
Visual depiction of requirements |
1 |
9 |
9 |
|
Traceability |
4 |
8 |
32 |
|
Integration with development tools |
3 |
2 |
6 |
|
Integration with test suite |
4 |
3 |
12 |
|
Ability to define custom properties |
5 |
1 |
5 |
|
|
|
Vendor total: |
85 |
Once you have narrowed the field down to a few choice vendors, evaluate the products thoroughly. The best way to do this is to try before you buy. If at all possible, negotiate a trial period with each vendor where you can put the tool to the test on a real project. The only true test to tell if the tool will work in your organization is to try it out in real life. No demo projects, no smoke and mirrors, just good old fashioned writing your own requirements in the tool in order to learn its quirks and limitations. This may add some extra time and produce some redundancy in your project documentation as you will want to continue to store whatever you produce within your own directories, but the small pain up front will alleviate pain on the back end once the tool is implemented. Complete the ranking process again once you have completed the trial run. This should produce a clear winner.
Next up: Implementing a tool without causing mass chaos in your organization.
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.
Subscribe to this comment's feed
written by DougGtheBA, April 07, 2009
-
- +0
-
-
written by lisa.waterman@chevron.com, April 07, 2009
-
- +0
-
-
written by JohnBull, April 07, 2009
-
- +0
-
-
written by bmclenna, April 07, 2009
I think it would be impossible for many reasons for our org to force one tool usage for all developers.
Are there any other gov agencies that have a similar situation and what approaches are being taken to 'consolidate' and automate requirements management from many vendors?
Thank you
-
- +0
-
-
written by dvansant, April 07, 2009
Finally, I absolutely agree that you should make sure that you have ample opportunity to trial the software on a live project, no exceptions.
-
- +0
-
-
written by haroldwolf, April 07, 2009
-
- +0
-
-
written by Kupe, April 07, 2009
As expert BAs we need to implement the practices we use every day for our business partners. Understand the true business need before implementing a solution.
There are many great tools out there that can help us improve, but we need to do some analysis before moving forward. I'm looking forward to part II.
-
- +0
-
-
