We are all part of the conversation, from inception to design and beyond

Author: Adriana Beal

In my last post, Help a BA! How do I get stakeholders to focus on business requirements?, I wrote:

As discussed above, it’s not only OK, but expected that the business side will be involved in defining the solution that will be built to address a business problem or opportunity. The solution requirements, which describe the characteristics of the solution, are defined through requirements analysis with the participation of the business stakeholders.

Mike Lachapelle left a comment (worth reading in its entirety as it covers various relevant points):

In Adriana’s table, column 1 [business requirements] is the conversation you have with the client, column 2 [solution requirements] is the conversation you have with the solution providers.

I disagree with Mike’s statement, and will go even further to say that column 3 of my table (design) is also a conversation that you have with the client (or business stakeholders of a software project). Here’s why:

1. Business stakeholders are key actors in defining and validating solutions that meet business needs

Even though a well-designed business analysis process will always start from helping clients truly understand the business problem and clarify the business requirements (high-level statements of a business rationale that must be addressed), it doesn’t stop there. The next step in the BA process is to work with these stakeholders to determine the capabilities needed to address the identified business requirements (which determines the solution to the business problem or opportunity). From the Guide to the Business Analysis Body of Knowledge (BABOK®):

Business analysis may be performed to understand the current state of an organization or to serve as a basis for the later identification of business needs. In most cases, however, business analysis is performed to define and validate solutions that meet business needs, goals, or objectives.

Who better than the actual clients or business stakeholders—the people closest to the business need—to validate solution requirements? Ideally, all groups who have an interest in the outcome of the project or are impacted by it (business and technical, internal and external stakeholders) will be represented in discussions to identify potential solutions and select the optimal solution to address the business problem or opportunity.

2. It’s impossible to identify all requirements up front

As Karl Wiegers reminds us, it’s impossible to identify every requirement early in a project. No matter how good you are at identifying and documenting requirements, there will always be something left unsaid that may have a huge impact in project success. In the book How to Cheat at IT Project Management, Susan Snedaker illustrates this reality very well:

There’s a story about a police mobile radio project where the police say there’s a problem with the radio. The engineers look over the radio and the specs and find nothing wrong. They talk to a police officer who says, “The problem is that when I hit a suspect with the radio, it breaks and then I can’t call for backup.” Clearly, the mobile radio was not designed to withstand impact, but that was the reality of the situation. Sometimes when the police were caught off-guard and had nothing else handy, they’d use the radio handpiece to subdue a suspect and it would break, making it impossible for the officer to then call for backup. The manufacturer changed the specs for the handpiece so it could withstand greater impact. Regardless of your opinion about the use of the radio handpiece as a weapon of self-defense, the point is that the radio project had not fully taken into account the users’ real-life application. The result of the project (the original mobile radio) did not meet users needs and was seen as a problem by the users.

I bet many of the readers here will have similar stories to share. In one of my projects, what was supposed to be a highly useful feature turned out to be completely ignored by the end users only because they mainly needed to use the function when they were on the phone with customers. It happened before headsets were easily available, and because the users only had one free hand to access the system, the clever design that allowed them to quickly navigate through pages of customer data, but required two hands to work properly, did not meet their needs.

Continuous involvement from business stakeholders throughout the project (not only during the business requirements phase) is the only way of mitigating the risks associated with requirements that remain hidden until later stages of the project.

3. We are all designers

As discussed in my previous article, it’s quite common for business stakeholders to “jump into design mode” even before the business problem is completely understood. BAs must take the initiative to bring the conversation back to the where it should be. Pat Kennedy, in the comments section of said article, writes a good summary of what is supposed to happen in those cases:

How solutions look in the end, need to be reserved till the end – because……here a BA might have at least three examples of solutions that when one requirement is used to design the look, function or feature without considering all the requirements, plus the knowledge of a GUI designer and or developer then a less efficient and sometimes clumsy interface/feature is the result. So gain agreement that the solution may be different – no less than needed and in many cases better after the complete picture is known. Then changes over time, etc… to make sure the solution includes all the functionality and features it needs to solve the business problem it is needed to solve.

However, that doesn’t mean that the work of business stakeholders is done once the business requirements, or even the solution requirements, are completed. The authors of Subject To Change: Creating Great Products & Services for an Uncertain World: Adaptive Path on Design point out that design “creates articles that we can all look at and think about.” It enables a quick exploration of different combinations, no doubt helping us create a clearer vision of how a system could or should behave.

To quote from the book,

We are all designers. Whether at home–in your kitchen, in your garden, in your closet–or at work, we all arrange separate elements to suit a particular purpose. Because design is so commonly practiced, everyone in your organization can participated when necessary. True, you may have come across a few inflexible, prima-donna designers in your time, unwilling to compromise on a particular curve or color. But although some designers seem inflexible, the actual act of design is nimble and can be blended with other rigorous organizational processes.

Because it is impossible to identify all requirements in early stages of the project, requirements and design must be iterative processes that feed off of each other. Requirements influence design, and design helps surface requirements that may have been previously overlooked.

Design is about making decisions, exploring, evaluating and making tradeoffs. It shouldn’t be left only for designers. In the same book, Subject To Change, the authors describe how at Adaptive Path (a firm specialized in the fields of product design and user experience) “some of the best design decisions come from business leads, marketers, developers, and writers.”

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

Comments

  1. Just wanted to say that this article gave me a lot to think about, and I’m sharing it with several colleagues in my IT team. Thank you for sharing your insights with the business analysis community — much appreciated.

  2. Nice article Adriana.

    I agree with you – in my view we are all designers, and I encourage my business stakeholders to get involved in the (functional) design – someone who has helped to shape a system is much more invested in it when it lands. In particular, if I think I know a better design than one they have suggested, I try my best to get them to “find” the better design themselves by asking them leading questions (sneaky, huh?). That way it is always “their” solution, not “my” solution.

    And as you’ve mentioned previously, you have to be careful to avoid your stakeholders *starting* out in design mode – when I start asking “why” to uncover the underlying problem, often I can then steer them to an alternative solution.

    My business stakeholders definitely draw the line at functional design though – they are not interested in what I call the *technical* design. Try as I might I cannot get them interested in the Java versus C# debate 🙂

  3. Thank you Chris, and Tony, for your nice words.

    @Tony: “I try my best to get them to “find” the better design themselves by asking them leading questions (sneaky, huh?). That way it is always “their” solution, not “my” solution.”

    This is great advice to all BAs — there is nothing better for buy-in than helping the stakeholders “find” the better design themselves ;-).