ArgonDigital - enterprise automation experts

Share This Post

Pick your Requirements Management Tool, then Design your Requirements Process

I was recently on a panel “Process and tools, which comes first?” at BA World Toronto. It was actually a PM focused panel, and I was a BA on the panel bringing my opinion about which I wanted PMs to focus on. My answer was actually quite simple: I don’t really care whether they focus on process or tools, I just do not want either to get in the way of us doing good business analysis! That caused some chuckles, but clearly resonated well with the group. That said, let’s now apply that same question to the business analysis field: Process or Tools first?

Really the answer is the same, but I’ll get more specific here because I actually have a strong opinion about which should come first in our industry. Of course the short answer is you really need both.

It’s pretty common to hear “Don’t just go putting a tool in place that no one knows how to use, but instead, build a process and then buy a tool later to work with that process”. I actually see it in practice all the time – organizations will have a 2 year plan to build a better BA practice where they won’t even consider a tool for BAs to use until they are well into year 2 because they have to get their processes in place first. Well, that, and many of them can’t get budget for a tool because the value just isn’t understood. This whole situation annoys me to no end because it’s quite backwards! I won’t go into the need for a tool here, you can see my other post on that here.

But with regards to the process than tool, here’s the deal: if the tools on the market were completely customizable with ease, that strategy would absolutely work. But they aren’t. Most tools on the market assume some basic methodology pieces and are based on someone thinking about obvious best practices. Each tool varies as to what is easy to do right in the tool, versus what should be imported into it, versus what you should in a completely different tool. So given that, doesn’t it make more sense that we use common sense and what we know are reasonable best practices (even if they aren’t implemented company-wide) to select a good tool, and THEN we build practices that work with using that specific tool? If we do that, surely we are more likely to see our BA teams actually use the tools we purchase because they become built into the best practices!  In fact you can design these practices in a way that make it absolutely necessary to use the tools.

Let me give you an example, let’s say there is a requirements management tool that allows you to build process flows right in the tool, but it doesn’t allow you to import from Viso. Plus you can link the steps in those flows to requirements in the tool directly. Given this kind of functionality, it’d be wise to build a process that asks BAs to just go into the tool to build their process flows and make the links to requirements. And then they can export copies for review or just do reviews right in the tool even. Now, in most organizations, they would invest time in developing a BA template for process flows in Visio and training the BAs to use it. They would also then make a nice Excel template to link process flow steps to requirements. And again, they would train BAs to use that. Then, when the practices feel “stable”, the leaders would find this tool that actually does all this for them and implement it. But at that point, they have to REtrain the BAs on creating flows and requirements in the tool. Oh 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 BAs and developers and testers are now comfortable in 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).

The reality is, the tools out there are good enough you can just select one now and build this same type of practice around what the tool offers you. You don’t need to over think the decision, just pick a reasonable one and make it work for your organization, long before you get people trained in habits that you don’t actually want them to have long term.

Pick your Requirements Management Tool, then Design your Requirements Process

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage