Beware Of Assumptions

You all know what assume makes out of U and ME. This old adage stays true to this day and is very applicable to the business world.

Assumptions are some of the biggest culprits in scope creep, misunderstandings, and successful projects being declared failures. This article will provide examples of each and ways to take the assumptions out of the picture and make your project a success.

Assumptions in requirements elicitation sometimes happen by accident such as when a user forgot to tell you about a particularly important piece of functionality. They sometimes happen maliciously as in the case of a sponsor trying to squeeze in programming that would never have been approved if presented to senior management up front.

In the first (non-malicious) case, the way to battle assumption related omissions in requirements gathering is through questioning multiple people early in the project. Question the sponsor, their direct reports, and most importantly other stakeholders. For example, a sponsor from the operations department asks for screen changes and a few reports. Make sure to question stakeholders from the marketing and relationship management departments. They may uncover hidden requirements that would surely lead to uncovered requirements gaps upon project implementation. Also, question the sponsor’s direct reports (diplomatically of course). Often, they are aware of steps in the process that their superior is not.

In the case of malicious requirements creep, the sponsor uses the excuse that they made an “assumption” that the piece of functionality they’re requesting is in scope when in fact they know it is not. The way to avert this is by carefully documenting and communicating the scope. This should be done in writing and orally over the course of several meetings leaving no doubt in anyone’s mind.

Ah, misunderstandings. That’s just an assumption by another name. My favorite story about misunderstanding is sitting in a key stakeholder’s office describing how an IT solution made up of multiple screen changes will make his life easier. He was happy, of course until he casually mentioned how thrilled he was that we modified the reports to match the screens. Oh,oh -we never talked about reports. It turned out; he was assuming that we knew enough to modify reports as well as screens. Always make the requirements in scope painfully obvious to avoid this situation.

One of the banes of the profession is a project where requirements are carefully crafted and executed, but the project is still declared a failure by the business. Digging deeper, the people declaring the project a failure have most likely made assumptions about the project that have been false. For instance, an operations manager may have assumed that a project will allow for increased headcount for his group, but that has not materialized. A business head may have assumed that a system enhancement will drive additional sales. When additional sales don’t materialize as an outcome, the project may be blamed.

Finally, make an effort to close all assumptions as soon as possible. Do this by asking questions even if some of the questions sound obvious. Keep asking until there are no assumptions left. To make things easier, use the following table as a guide to ferreting out assumptions during requirements elicitation. While by no means exhaustive it should serve as a starting point to generate your own.

Good luck BAs!

Written by Lee Grinberg

The Book, The Movie, and the Business Document

Communication using only words – whether verbal or written – leaves much to the imagination. Which is part of the appeal when it comes to reading for pleasure?

Think of a book you’ve read and enjoyed which was later interpreted as a movie. With the book, your interpretation of the appearance of the settings and characters is a product your imagination, which is shaped by your unique life experience. Every reader of that book comes away with a somewhat similar, but different perspective.

An author can narrow down some of the variance in interpretations by adding more descriptive detail. Think of a book you’ve enjoyed for its vivid descriptions of setting and depth of character development. This can be great for a riveting novel that we wish would never end.

Perhaps, upon leaving the movie based on a book you’ve read, you considered (or commiserated over) how different the characters and the scene were from how you’d imagined them. Your interpretation of the words in the book is as valid as anyone’s. It just didn’t match those of the producer of the film, and possibly, the author of the book. This makes for interesting discussion and critique.

In the book’s cinematic version, with the addition of the audio and visual elements, all viewers come away with a shared mental image of the appearance of the settings and characters, because the additional sensory dimensions make them more explicit. Similarly, visuals, such as pictures, diagrams or other types of models can be helpful in our business communication because they eliminate much of the “imagination,” or ambiguity of words, making meaning more explicit. Visuals serve to calibrate the natural differences in our mental images.

Now, unlike that great book or movie, most of us don’t read business documents such as a requirements specification for enjoyment. And unlike the book, there can be significant repercussions when one reader’s interpretation of the content varies widely from another’s. The Big Thick Document (BTD) is a product of the notion that increasing a document’s length to add more detail will improve the communication value of the document. Unfortunately, the opposite is more often the result because the longer document is, the:

  1. Less likely to be read
  2. Less likely to be understood if it is read
  3. More likely errors or omissions are to be overlooked, as readers tend mistake length and detail for precision and accuracy.

Thoughtful use of visuals – even, and especially in rough or early drafts – adds a dimension of “understandability” to the ideas expressed in documentation that is not possible in a mostly text-based format, and at very little additional cost. In fact, often it is more work manipulating language to describe something than it is to represent it visually. To this end, a white board or a blank sheet of paper and a drawing utensil are valuable tools when it comes to working through ideas to establish common understanding.

A few questions we may ask to help us optimize our efforts:

  • What can we give business stakeholders who want to confirm for us that we’re on the right path that isn’t overwhelmingly long and difficult to decipher?
  • What can we give delivery team members that, first, summarize the details and provides context, then, expresses the details in as easy a form as possible to understand and use to do their work?
  • How can we strike an acceptable cost/benefit balance in doing these things?

By Bartosch Salmanski


Testing Nonfunctional Requirements in an Agile Lifecycle

Effective nonfunctional testing is often the forgotten testing task. It can be the elephant in the room that no one wants to talk about.

To start with, nonfunctional requirements (NFRs)—such as performance, reliability, installability, scalability, usability, security, availability, and so forth—are hard to quantify. Just as importantly, finding someone who has the depth and breadth of knowledge to define NFRs is usually a challenge.

In a traditional waterfall cycle, we may have some definitive NFRs in the system or requirements specification. In safety-critical systems, NFRs are much better defined, but for many commercial software development environments, NFRs remain elusive and tend to be a “late in the lifecycle” testing activity.

As organizations embrace agile, NFRs may be an even greater challenge—both functional and nonfunctional requirements must be considered and validated in each (short) sprint. Ideally, NFRs are a continuous focus during each sprint, instead of being left to the last one.

Here are some ways to better address NFRs in your agile development lifecycle.

Defining nonfunctional requirements:

For brand-new products, use analysis, experiments, and comparative testing, and collect or test user expectations.

    • Analyzing the technical, data, and network architecture will yield important characteristics and constraints.
    • Design experiments and do comparative testing to evaluate and select the best alternatives.
    • Speaking with users and asking successively detailed questions can help quantify NFR expectations. For instance, if customers say, “I need it to go fast,” you can further define what they mean by fast. You also can demonstrate the product to users and get their feedback immediately, such as by saying, “Let me load this home page for you, and you tell me if it loaded quickly enough.”

For evolving products, use analytics tools to mine existing application and system data.

  • Analyze data from customer usage—clicks, workflows, feature usage, errors, abandons, and so forth.
  • Analyze information from production systems, including resource usage (memory, process, CPU, and input/output rates), network traffic characterization, security attack attempts, and database statistics.
  • Review help desk and issue tickets for outages, defects, enhancement requests, and user errors.
  • Use video and screen-capturing software to record user sessions and analyze problem areas.

Documenting nonfunctional requirements:

In waterfall methodologies, NFRs are included in a separate document or category in the repository. But in agile, NFRs normally cut across several user stories, or even the entire system, sp require some special consideration.

  • First, ensure that NFRs are being discussed and defined during the agile release or theme planning and that a conversation around how to test these characteristics is started.
  • Define scenarios that cut across stories. A scenario describes a real-world example of how people or organizations interact with a system. Scenarios then act as constraints across stories, and they have rules and restrictions that must be met.
  • Alternatively, create backlog items for each NFR and link user stories to these NFR backlog items. These will later be estimated and scheduled into the appropriate sprint.

Continuously testing both functional and nonfunctional characteristics across sprints is the key to delivering a minimum viable product.

By Michael Sowers

How Can a Business Analyst Help You?

Sometimes project stakeholders I work for or with aren’t familiar with the role or the value of the business analyst. I’ve posted about Karl Wiegers’ Bills of Rights previously, and think those are a great way to introduce the role to a new business stakeholder who may not be familiar with the types of value a BA can provide, and what he/she should do to help the process along.

A few days back, while waiting for a meeting to begin, I jotted down a few quick ideas of my own that I thought I might share with stakeholders with whom I hadn’t previously worked if questions arose over what help and services I can provide by fulfilling my role as a BA.

I didn’t put a great deal of time into this list, and it is by no means conclusive, but I thought I’d share in case it may be of value to someone.

As a business analyst, I can help you:

  • Develop your business case, and determine whether your business case is viable and warrants investment of company resources.
  • Distinguish a business problem’s symptoms from its root cause, and help you discover the true root cause.
  • Ensure that all of the key questions have been asked, and their responses documented.
  • Ensure that issues are captured, resolved, and their resolutions documented.
  • Provide you with the honest perspective of a disinterested “third party” who is beholden to no particular business unit or stakeholder.
  • Make sure that the right decision makers are involved in the project and have an opportunity to provide input.
  • Identify all the systems, processes and users that are impacted by the business problem, and/or the solution.
  • Ensure that the system/process users’ interests are known and communicated to other project stakeholders.
  • Fill in gaps in your current-state process documentation. You need to understand how things work today if you’re goal is to fix today’s problem.
  • Understand the solution options that are available, and help you and the other project stakeholders prioritize those options based on their merits, and eventually select the best option.
  • Feel confident that those who will implement the solution understand what is required of them and of the systems or processes under their purview.
  • Provide you with quality specifications and process documentation that will serve as a valuable reference regarding decisions made and solutions implemented.

As I said, this is a quick-hit list. Some of the items are rather specific; others could be decomposed into numerous other sub-items. What items might you add? Are there items included here that you think fall outside of the normal responsibilities of a business analyst?

By Jonathan Babcock

Business Analytics

There is a major change happening in the IT industry—the use of big data and analytics to guide how businesses are run. Many companies are embracing analytics as part of their core strategies.

Unfortunately, some of those companies think that they can just purchase an analytics solution, implement it, load and collect data—and poof! all their problems will be solved. There are many software solutions available for business analytics, but there is also still a need for requirements analysis to ensure the right solution is selected and implemented correctly.

Business analytics implementations need software requirements, just like any other commercial, off-the-shelf solution. There will be business requirements, functional requirements, non-functional requirements, and business rules. Requirements models help us understand how people will use the solution and help guide the configuration of the system according to the business rules.

The process to elicit and develop requirements for business analytics projects can be broken down into four steps, as shown in the following diagram. I’m going to focus on the fourth step: Define the data transformation analysis requirements. Find more information on the other three steps in the white paper “Forward Thinking for Tomorrow’s Projects: Requirements for Business Analytics.”

Business Analytics 2

In an analytics project, once you have identified the data and understand how users want to consume and use the results of analytics solutions, then the main focus is on determining what analyses must convert the data into in order to get those results.

Sometimes, users just explore the raw data objects and attributes because they don’t really know what they want. However, it’s important with big data to at least zero in a bit on what kinds of problems users want to solve and what type of analysis they might want on the data. Otherwise, the analytics solution might do too much and be too overwhelming to be useful.

Good business analysts (BAs) can help stakeholders figure out what they want from the solution by brainstorming what possibilities exist with analytics solutions.

Business analytics solutions can enable future-state strategic analysis, such as exploring “what-if” scenarios. For example, “What if we could offer a new service and predict what our future sales would be for that service—before we ever deploy it? How would that be helpful?”

A good analytics solution with the right data can run models and algorithms to enable these types of data predictions. That said, prediction models and usage scenarios still must be specified in the requirements so that the analytics system can be configured correctly. Furthermore, the analyses that transform the data might require computations, statistics, or that other business rules be applied to the data prior to its being delivered in the solution.

Business analytics projects need software requirements defined, just like any other project. The approach is slightly different: Prioritize using decisions, define how information will be used, specify the data needs, and define the analyses that transform the data. When defining those analyses, we can’t assume the analytics solution will just come configured to do what we need our solution to do.

By Joy Beatty