Which Should Come First, Requirements Management Tools or Processes? Hint: It’s Not What You Expect!


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.

Fitting a requirements tool to your mature process is like putting a square peg in a round hole

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.


There is a graphic difference in the time added by going “requirements process first” rather than going “requirements tool first.”

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.

Like this article:
  12 members liked this article


Mark Monteleone posted on Saturday, March 24, 2012 12:32 PM
Joy, thanks for sharing your experience and advice on selecting tools over process. I too was surprised at your response; it caused me to read your article several times. On my final read, I retained a concern.

I interpreted your comment on project managers on “don’t get in the way of our doing a good business analysis” as only an attention getter. The BA’s working goal of course is collaboration with the PM. Unfortunately, I occasionally have come across a PM that directs the BA not use a technique only to find out that the PM either did not know what the technique was or had misused it in the past. Upon being educated, I have actually witnessed a PM stating “I need to listen to the BA more.” My feeling has always been that the PM is only as good as the BA that is working on the project. Although let’s make no bones about it, the PM is in charge of the project.

In rereading your article I believe your advice on tools first and processes second is only directed at the establishment of a CoE. For me it does not apply to analyzing a business area. Perhaps that was your intent even though it was not explicitly stated. As BAs, we advise business areas that "good business analysis" is to first determine their requirements based on their process needs and business rules and then select or build appropriate software tools (if needed). This is what BAs call the “diagnostic approach.” Note, we can all point to disasters on business areas picking software tools prior to understanding their needs first.

Given your preference of tools over process for the CoE, you might expect the following question from the business area: “Why is the BA CoE not eating its own dog food?”
undrkvabrtha posted on Wednesday, April 4, 2012 8:24 PM
Just wishful thinking here, Joy - It would be nice to have a 'method' to actually convince people at the CEO and CIO levels about the importance of the dog wagging the tail.

It is repeatedly thrust down one's throat that as long as a vendor's salesman has done his job, high ranking officials somehow think they're buying a business solution.

How do I get anyone up there to read this article?

a'right, I'm being cheeky - but couldn't help wonder ;-)

Undercover Brother
undrkvabrtha posted on Wednesday, April 4, 2012 11:01 PM
Joy, thank you for sharing your views on whether the tail should wag the dog or the dog should wag the tail.

A tool-first approach might be cost-effective for an SME in terms of cost / time taken, and there is always value in looking at what material is available in the market when planning to build a house. I think the latter factor is usually called common-sense.

However, basing one's RQM standards and process on a vendor-specific tool would be a case of the tail wagging the dog.

If the right people are involved, designing a process doesn't take as long or cost as much as your graphic mis-portrayal. What is needed are people who understand analytical principles well, and proper management support .

As an analyst who in an enterprise of 40,000 people handling data pertaining to 14 million other people, Joy - I'd say that when you put the tool first, you're cutting off the inclusion of industry good practices that the said tool may not support in your process.

This means your process and RQM mechanism is only as good as the vendor wants it to be (customising an over-the shelf tool is akin to molesting it - it costs you a lot, and the tool won't like it)

Management support in the form of directives or mandates are usually missing when new processes are designed, and this is primarily

About the 'unlearning curve' - it sounds to me like scaremongering. A qualified and experienced BA would take one look at a tool, and figure out where most of its functions lie.

A quick query - the paragraph titled 'An Example From The Real World' is all about a HYPOTHETICAL SITUATION. Were you trying to contradict yourself on purpose?

I quote you "...that starting with a process first is more than inefficient, itcan lead to resistance inadopting the tool and friction among the teams"

Actually, it doesn't. I strongly question the quality of your survey, and the analytics that lead to your vendor-driven conclusion.

1) The primary reason for resistance is the lack of a firm management directive or mandate. I have yet to see an enterprise where someoene disagrees with a management mandate (which is probably why none of your BAs have disagreed with you-ROFL)

2) The primary reason for friction is that the CIO has not mandated that "this is how it is going to be"

One more thing - just because someone important did 'something', that 'something' is not automatically the correct 'something'. It' s just something.

For instance, ANZ's last CIO implemented HP's QC as a business solution relying on HP to provide the solution.

What this means is that ANZ will have a low-cost solution to testing and very elementary RQM. Is that right or wrong? If ANZ is looking at a long-term bullet proof vendor-independent SDLC, it is just plain stupid, and downright wrong.

People in power will always do things that are incorrect - that does not make them correct. I truly hope prospective management or BAs are not put on the wrong path here.

In a market where product choices are by the dozen, vendor-driven solutions are good for SMEs at the very best, and a long-term disaster for organisations with a long-term vision.

Kent McDonald posted on Wednesday, April 11, 2012 5:27 PM
Hi Joy,
I agree with your suggestion to select your tool priorto fleshing out your process, but with a couple of additional thoughts and some slightly different reasoning.

As one if the othe commenters hinted at, yiu shikdn't select a requirement management tool based on who does the best sales pitch. You shoukd have an understanding of why you are wanting to do use a too, for requirements management and what you are looking to get out of it. In other words, understand your objectives and requirements like you would inany well laid out software package selection approach.

Then, you select the tool that best meets those objectives and adopt a process most appropriate for that tool. Why in that order? Requirements Management is a parity process, meaning it is probably mission critical for your development organization, but it is certainly nkt market differentiating. According to the Purpose Based Alignment model, the best way to address a parity activity is to mimc good practices and simplify.

Most Commercial Off The Shelf (COTS) products are built based on generally good practices for their target domains, meaning if you implement the product as it was intended, you have a fairly good chance of implementing a collection of good practices. Organizations that buy a tool and thentry to customize it to their home grown process are wasting their time and money treating a parity activity as if it were differentiating.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC