Of Waiters and Business Analysts

To many, making software and software products may seem mysterious, but the challenges are very similar to those in other industries. Let’s explore a common dilemma faced in software using roles from a restaurant — this story may sound familiar:

A Customer only has 30 minutes and $10 to eat lunch. He has never been to this short-order, quick-turnaround diner. In order to make things very efficient, the cook stays in the kitchen cooking and the waiter interacts with the customers and relays the orders to the cook.

Waiter: “Hi. What’ll ya’ have?”

Customer: “Smells great in here. I’ve heard good things about this place. I need to eat quickly and hurry back to work. How about something simple and quick. Just a burger, please.

Waiter: [writes on a notepad] “Burger. Got it. Comin’ right up.”

[15 minutes later waiter places a picturesque entree on the customer’s table.]

Waiter: “Here you go. I must say, this is the best looking burger the kitchen has made all day. Enjoy!”

[places a check for $10 on the table]

Customer: “What is this?”

Waiter: “It’s a burger, sir. It was made by one of the best short-order cooks in the city. You ordered a burger. I have it right here on my notepad.”

[shows notepad to customer]

Customer: “Yes. It looks nice…but, this isn’t what I expected.”

Waiter: “You said you wanted a burger. Here is your burger.”

Customer: “I expected medium-rare, Romaine lettuce, fresh tomatoes, bacon, and A-1 sauce on a wheat bun. This is well-done, shredded lettuce, onions, no bacon, and with mustard on a white bun.”

Waiter: “OK. We certainly have all of those things. I’ll have the cook make that burger for you, too. But, it’s the lunch rush and he’s slammed. I can’t guarantee a quick turnaround, plus I’ll have to charge you another $10 and it will take maybe 20 more minutes.”

Just like ambiguities and assumptions can ruin an order, they very often ruin software projects.

We’ve all seen something like this before, and we’ve all had great experiences at restaurants as well.

While this story depicts a communication breakdown which happens quite often in building apps, the truth is most of the time everyone is trying really hard to get things right. The client generally has some idea of what they want and they do their best to pass that information along. The project manager, designer, quality assurance engineer, and engineering team are doing their best to hear what the customer wants, talk about solutions, and create a great product.

The role of communicating about, understanding, and capturing requirements belongs to different individuals depending on the size of a project. In a very small project, perhaps a single developer wears all the hats including serving as the project manager (PM) and business analyst (BA). As teams grow in size, the benefits of creating specialized roles begin to pay off. When the project manager and engineering team are struggling to manage requirements, it’s time to bring in a BA.

In our story above, if the waiter had said something like, “We have a ‘Build Your Own Burger’ system here. Let’s start with the bun. White or Wheat? How would you like the burger cooked?…”, we may have had a better start, and that’s just the beginning. Owning and managing requirements is an iterative process. Just like code, requirements are a living piece of the project which have to be maintained and changes have to be adjusted for. When a BA records requirements changes, those changes will be communicated to the PM and then propagated to the design and engineering teams. The team will also give feedback to the BA concerning the impact of those requirements changes, and the BA will then raise concerns back to the customer. This team dynamic is what makes for a healthy software project, and when the BA is a part of it, we’re all the more likely to build what the customer wants.

Software Projects May Fail for More Reasons than Bugs in Code

A client may consider the software developed for them a failure when it doesn’t do what they expect it to do. When one thinks of a software project failing, buggy code is usually the first thing that comes to mind. Apps crashing, network timeouts, “404 Not Found”, are all unexpected things that we’ve encountered as consumers. Consider that building the wrong thing can be at least as devastating to a project as buggy code can be, if not more so. One unexpected way that projects often fail is due to poorly-defined requirements. Often, a development team will deliver rock-solid, bug-free code that does what it is expected to do. Well… what the dev team thinks it is expected to do.

Acceptance Testing (where the client tries the software before it is delivered to their customers) is one way to catch failures before they go to production. But, that’s a very late catch. That’s catching it after a lot of work has been done designing, architecting, developing, and testing. And if a product fails in Acceptance Testing, some portion of the work will have to be redone, and that may have significant time and energy costs.

At this point, the client is not happy and may feel like all of the time, money, and effort up to this point has been wasted. The burger in the story above failed Acceptance Testing and you saw one possible outcome of that failure.

Clients are a Wealth of Information

The translation of a client’s vision into clearly and consistently documented requirements provides ample opportunity for information to be lost or distorted. The client is a critical source of information about their line of business and customers, and they will be critical in helping the team bring the dream to fruition, especially if the development team is outside of the organization and brought in as a contractor. One common error is the presumption that the development team knows as much as the client does about their line of business. Some experts have a tough time teaching others about their field just as some talented athletes have a tough time coaching inexperienced players. It can be difficult to transfer years of knowledge and wisdom in a short period of time.

I’ve been on a project team as a developer building financial management software for an oversight team in major government agency. The scale of the project was massive, with tens of billions of dollars being represented in software that updated daily with calculations down to the penny. Major decisions were made based off of this system. All of the subject matter experts had advanced financial degrees and had worked in the finance industry for several years.

The risk of error during the calculations was very high — as well as the consequences — but organizing and presenting the data was relatively simple.

In order to mitigate the risk of shipping software that produced incorrect data, I had to spend a lot of time as a Business Analyst learning about the business from the client’s point of view before my team could even begin writing the first line of code. When communication was clear and unambiguous, delivering the product went smoothly. This was a large project that lasted several years and new requirements came periodically as more features were requested. When the time came to review those requirements, they were carefully (and painlessly) implemented.

I stayed engaged with the client throughout the project to make sure the software being built was in line with requirements. The end result was functional, accurate accounting software that exceeded the client’s expectations.

Final Thoughts

Every software project has some level of business analysis involved and someone facilitated that. Larger, more complex projects greatly benefit from having a dedicated BA or even a team of BAs on very large projects. Even though the client may know everything they need, they may not be available whenever a the implementation team needs information or if they provide it in written form, it may not be at the level of detail such that an implementation team can run with it.

A Business Analyst may have several responsibilities on a project. A BA might:

  • Serve as a liaison between the client and the implementation team. And in doing so, helping establish and maintain a great working relationship between the client and implementation team.
  • Effectively record and communicate the details to the implementation team, knowing how to record requirements in a way that is easily and unambiguously consumed by the implementation team. A “Technical BA” might even go so far as to write low-level details about databases, data models, endpoints, payloads, etc…
  • Serve as a client representative to the implementation team. For example, when a developer wants to know, “OK, what problem is the customer looking to solve here?”, the BA could provide the context and back-story along with the immediate answer.
  • Manage the updates to requirements or the addition of new requirements. Good software evolves. It evolves to better meet current needs or it evolves to meet new needs. Both of which start with requirements.

The Business Analyst plays a critical role in the system. Sounds a lot like what a waiter might do in a restaurant, doesn’t it? Maybe reread the list above in the context of a waiter in a restaurant. Adding a BA to own requirements will relieve the project management, design, and engineering teams and allow them focus more on what they do best. Maintaining requirements may take a little more time early in the process, and keeping up with changes takes discipline, but doing so can save time, money, and a client relationship later.

The post Of Waiters and Business Analysts appeared first on Possible Mobile.

Originally published on Possible Mobile

Like what you read? Give POSSIBLE Mobile a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.