As the lone business analyst on a panel of project managers at BA World Toronto in 2011, I was asked my opinion about whether I’d want project managers to focus on processes first or tools first. Without hesitation, my response was “I don’t really care whether project managers focus on process or tools first,as long as they don’t get in the way of our doing good business analysis!”Even though most of the audience was comprised of project managers, thankfully I got some chuckles and the remark resonated well with them. In applying the same question to business analysis and business architecture, however, my actual response has produced enoughsurprise and discussion that it might be characterized as “unexpected”. In short, while you do need both processes and tools, I think it is best and most productive to put a tool in place first.
Why Should We Implement a Tool First?
I have often heard business analyst practitioners and management say things like, “Don’t put a tool in place that no one knows how to use; instead, build a process and then buy a tool later that will work with that process.” Despite that, I maintain the “process first” approach will actually slow the progress of a business analyst teammaturing its practices. Why? If the requirements management tools available today were highly customizable, and customizable with ease, implementing a process first would absolutely work. We would implement our processes and then just customize our favorite tool to work with those processes. The reality is that requirements management tools aren’t highly customizable yet. Further, most tools on the market assume some basic methodology as their foundation, and so to implement the tools to fit your own customized methodology instead of theirs would require a significant amount of customization—something not likely to happen given the lack of tool customizability.
Figure 1.Fitting a requirements tool to your mature process is like putting a square peg in a round hole.
Don’t Create an Unlearning Curve
Wesee the negative impact of the “process first” choice in practice all the time. For instance,organizations will have a two-year plan to build a better business analyst practice by implementing a BA Center of Excellence,and won’t even consider a requirements management tooluntil they are well into their second year because they have to get their processes in place first. These organizations don’t even give the tool implementation timing a second thought. However, once business analyst teamshead down this path and get two years into their maturity plan, they can’t get budget for a tool because the value just isn’t understood by executive management—after all, they probably have spent a lot of time and money already and feel like the team should just execute on business analysis.
This whole situation annoys me to no end because it’s not only inefficient; it compounds the issues surrounding maturing business analyst teams!Since tools are not infinitely customizable, a business analyst team that focuses on process first will have to suffer through an “unlearning curve” when they adopt a tool AFTER they have established their processes. By “unlearning curve”, we mean that the team will have spent time defining processes and templates, getting business analysts to follow them, getting developers and testers used to them, and then when the rug is pulled out from under them and their tool doesn’t work with those processes and templates, the entire team has to be retrained. And adoption of best practices is typically quite challenging to do once, let alone twice!
How Do We Pick a Tool First?
We are proposing that you implement your tool first and build your processes to work with it. Are we saying that you should ignore processes completely and pick a tool? Not at all! Business analyst teams should usetheir common sense and what we know are reasonable best practices (even if they aren’t implemented company-wide) to select a tool. Once you have your tool, you can decide what your business analysts should do directly in the tool (perhaps they can create Process Flows there), what they should plan to import into the tool (maybe the tool can store session notes linked to requirements), and what should be done in completely different types of tools (maybe issue tracking on requirements has to be done in another tool).
This not only saves time because the team doesn’t lose efficiency due to an “unlearning curve,” it ensures that the requirements management tool selected is built into your organization’s best practices. You can even go as far as to define those best practices such that the tool becomesnecessary to execute them, encouraging (almost forcing) adoption.
An Example from the Real World
To make the inefficiencies in the “process first” approach crystal clear, let’s imagine a hypothetical requirements management tool that allows you to build process flows and link the steps in those flows to requirements right within the tool. Now imagine this same tool doesn’t allow you to import from Visio. Given its particular functionality, it’d be wise to build a process wherebusiness analysts go into the tool to build their process flows and make the links to requirements. Business analysts could then export copies for review, or even do reviews within the tool. In the “process first” approach, an organization would not implement a tool at first, but would develop a process whereby business analysts are trained to use a template for developing process flows in Visio. Business analysts would then be trained touse an Excel templatewhich links process flow steps to requirements. Then, when the practices are well-learned by the business analysts and are “stable,” the team would seek a tool that actually does all this for them—something like our hypothetical tool above.
Once the team finds such a tool and implements it,the managerswould then have to retrain the business analysts on how to create flows and requirements in the tool. And, by the way, the development and testing teams are also now used to the Visio and Excel templates as well, so they have to be retrained too. And unfortunately, because the business analysts and developers and testers are now comfortable with their “stable” workflow and processes using Visio and Excel, they won’t adopt the new tool very quickly because it doesn’t add much value for them—or so they think.Management will need to spend extra time overcoming resistance while retraining, further adding friction to what should be a straightforward development of best practices.
Figure 2.There is a graphic difference in the time added by going “requirements process first” rather than going “requirements tool first.”
Now What?
Now you see why I am a firm believer in “tools before process”—it is obvious that starting with a process first ismore than inefficient, itcan lead to resistance inadopting the tool and friction among the teams. Based on the results of extensive research Seilevel conducted in evaluating requirements management tools, there are now a wide variety of tools that are good enough to implement for requirements management without your team having to spend time on a lengthy evaluation process.Feel free to use the Seilevel research and templates to adjust criteria weighting to your particular situation, then select a tool and start buildingprocesses and best practices around the tool. You don’t need to over-think the decision; do some basic homework, pick a tool that has features you are interested in, and implement it before yourbusiness analystsbecome entrenched in habits that aren’t productive long-term, habits that will require time spent in the “unlearning curve.”
Author Bio
Joy Beatty is Vice President of Research and Development at Seilevel. As a managing principal she drives innovation and development for new methodologies that improve requirements elicitation and modeling, assisting clients as they build Business Analysis Centers of Excellence.
For more of Joy’s writings, please visit the Seilevel blog at http://requirements.seilevel.com/blog/.
Seilevel is a professional services company focused exclusively on helping clients change the way they create requirements in order to enhance business outcomes. In addition, Seilevel offers numerous requirements resources such as templates and how-to-guides.