JDA’s Focus included a session that really should be required viewing for anyone involved in any kind of technology development. The session was presented by Pam Sheen, Solution Manager for Enterprise Store Operations for Dunkin’ Brands, and, corny as it may sound, it was like music to my former CIO ears. Here’s why.

In some ways, in the age of “The Hacker Way ” and Rapid Application Development (RAD), capturing critical business requirements almost seems like an anachronism. It’s a fairly long process, and requires capturing both the “as is ” and the “will be ” in somewhat excruciating detail. Plus, it’s associated with something all of us have trouble with, although few of us acknowledge it: that thing is change. And it’s slow. And frustrating.

Unfortunately, it’s also necessary.

Pam highlighted bullet points explaining what a Business Requirement is:

• Articulates key activities that must be performed to meet the company objectives
• Creates a story describing those processes
• Is a tool to gain agreement among stakeholders
• Provides a foundation to communicate with a solution provider about what a system has to do
• Becomes the baseline for future project phases. At the end of the day, it’s the Bible telling the story of a business process.

Lots of people focus much more on RFPs (Requests for Proposal). I’m going to editorialize for a minute here. I’ve seen my share of RFP’s in my career. In fact, there are ARTS standards for certain RFP’s. That’s great as far as it goes, I suppose, but it’s just not enough. RFP’s are NOT a substitute for a Business Requirement. And, in full disclosure, I am not, and have never been a fan of them.

Some could argue that an RFP is the next phase of a project, but all too often, the first thing technology vendors receive from potential clients is a short narrative followed by an enormous check-list of features and functions that are required. The problem with them is like any other set of yes or no questions, the forest can be missed for the trees. In the case of many RFPs, they’re more like a set of leaves that are to be constructed into trees, which will then be joined together to become a forest. And they don’t address that fundamental image: what the heck is that new forest supposed to look like, anyway?

It’s an amusing image, and helps see how expectations can get all screwed up and implementations can take forever. What are the chances the architect is going to get that forest right? Someplace between slim and none. He might not even get a single tree built correctly.

There’s not a business user in the world who thinks that way. Truthfully, a good system designer doesn’t think that way either. It’s much more sensible to start with an overarching process, and then break that process into sequences of activities. Finally, it’s time to get into the detailed activities that happen in that sequence.

Back in 2012, I got juiced over the notion of empathy and design thinking. This is a core tenet of SAP’s technical group and it posits an interesting concept: A system has to be viable for the business, technically feasible, and most interestingly, it also has to be desirable. People have to want to use it. Now this is truth, but it also might lead you to believe getting there is also fun.

I can appreciate the irony that working through a Business Requirement might make you think that it’s impossible for something desirable is going to come out the other side. It can be annoying, no doubt. But it’s really important.

My best advice to business users: go through the process. Get a solidly described Business Requirement. And if your IT person wants to take you straight to an RFP… really… just say no.

I appreciate those rare times I’m reminded of the things I found most valuable when I was in the world of IT. It happened in 2012, and it happened again last week. Thanks to Pam and JDA for making that possible!