Kill the Business Requirement, Long Live Culture

Home / Blog / Kill the Business Requirement, Long Live Culture

Culture is a large part of every tech implementation. I dislike the term “business requirement”, it is overused, and doesn’t have the right meaning anymore. What it is really about is CULTURE; what can the culture accept, and what is the culture willing to change.

In the technology industry, I believe that we go about the process backwards—the process of defining configurations. Our process is: Tell me [the consultant] everything about your culture, Then I’ll focus group all the different stakeholders. I’ll convert it to business requirements and decide what the right configuration is. 

Versus a process that would require a lot less churn: Give me [the few true business decision-makers] a laundry list of the configuration options, and after we give it some thought, let’s talk about it, especially any compromises the choices may result in; and then I’ll tell you what the right choices are for my business.

As a business operations technologist, I’d much rather take the time to think through and talk through such a list, than to have to onboard another consultant to my culture; and then narrow-down pie-in-the-sky ideas to reality. In a project with a high level of business interaction and impact, the current model is next to impossible--unless you have the volume of work to support full immersion of the consultant into your world. There’s a lot of subtilties in a culture that you’ll never get until you live & breathe it for quite a while.

It seems incredible to me that these sorts of laundry lists don’t exist.


Staying within the guardrails of native functionality is the single most important thing a business can do to future-prepare their technology


 

Go Native or Go Home

This alternative approach is particularly meaningful in the new reality of monthly software updates, and surprise new feature introductions.  Given today’s rapid release cycle, organizations can no longer commit the time and money required to support thorough testing, validation and re-customization with each update.  As a result, businesses are beginning to adopt a native-only approach where customizations are either not an option, or they are focused only on truly business-critical activities.

Organizations are also beginning to recognize the value of changing their expectations or processes to fit the way a solution is intended to work.  We are taking a deeper look at requests that would require customization and working with the business stakeholders to find a native solution.  This is an area that consumerization of tech has worked to our benefit.  Stakeholders are more willing to compromise because they’re a bit more tech-savvy as a result of their personal consumption of tech.

In today’s model of “business requirements” it is difficult to even know when you are asking for a combination of things that the software doesn’t do, or doesn’t do well.  Often, those of us on the business side of the equation don’t even know we’re asking for something that is challenging to deliver.  We are just in a place where we are unfamiliar with the necessary level of detail and providing answers that are uninformed of the consequences.  In these scenarios, the business requirements becomes the easy scapegoat when something gets missed.

This Might Be My Nirvana

It seems like business requirements work well when you’re developing something custom. But what about businesses that have adopted a Native Only approach?  Don’t we need to change our knowledge gathering process to work more efficiently with them?

I think I would be in heaven if every software came with a list of business-focused configuration choices [or if every consultant prepared such a list for the software they specialize in].  After walking through the choices, the consultant would then build a document/model showing how the config choices would work in reality.


My questions for you

Wouldn’t such an approach get us closer, with a lot less grief?
What are your thoughts about getting rid of the business requirement legacy?
What would we loose with such an approach?

I’m super interested in this idea, and would love to hear your thoughts, even if you think I’m not all right in the head for coming up with it.

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *