Next Mile and Space Cowboy have collaborated on a four-part series about requirements. You can read the first part here and the second part here. This third piece helps you, a BA or software project participant, understand whether or not you’re in trouble based on the quality of your requirements.

—

Previously, we stated that organizations view the “requirements” phase as the “getting our shit together before we spend a boatload of money” resolve-building phase. How do you know if your proverbial shit is proverbially together?

Analyze thyself and thy work, dear BA, by examining the effect of your requirements on three axes:

1. Access and utilization
2. Behavioral impact
3. Strategic vacillation

From there, deeper analysis can help diagnose your specific problem and take the edge off your corrective action.

You’ve probably heard some variation of the following software delivery axiom:

“If you can’t deploy, you shouldn’t code.”

The same principle applies to requirements themselves. If you can’t publish for audience consumption in a manner that’s accessible and useful to them, what are you even doing? That’s right, makework. Look for the following signs to avoid wasting your own time.

Requirements difficult to access

Simple accessibility hobbles the utility of more requirements than you’d ever expect. Worse, inaccessibility is generally an indirect problem that isn’t necessarily the BA’s fault or obligation to fix. Most often, this happens when organizations inundate individual contributors with crushing overhead:

• Too many tools
• Burdensome security
• Strict compartmentalization

The mental labor needed to remember where something is, recall how to access it, jump through hoops to open it, and then wade through irrelevant content to find the part you need makes artifact access a punishment and slows all collaboration. When it’s less annoying to work, be wrong, and rework than it is to read requirements, you’ve got an access impediment.

Requirements difficult to navigate or understand

A BA has many duties, but optimizing the signal to noise ratio in their communication and documentation may be the most difficult. You’ll know stakeholders and implementers find your requirements difficult to understand when:

• Readers complain of either too much detail, not enough detail, or both!
• There’s minimal traceability among documents.
• Readers observably stumble through navigation.
• Content challenges readers’ attention span, seems difficult to internalize, contains insufficient decomposition, or said decomposition is at odds with the engineer’s mental model.
• Engineers have difficulty describing the problem.

Solutions to these issues tend to be team-dependent, but you can employ a few tips to lighten readers’ burden:

• Use short, unambiguous, parsable names. For example “MAIN-A12” instead of “Account Details Update - Alternate Design DMB_10/31_FINALV2 (see blue highlight)”.
• Use hyperlinks to ease navigation—lack of deep links forces wasteful hunting.
• Leverage repeatable document structures. Structure conditions your readers; use that conditioning to accelerate their navigation.

You’ll almost certainly need to experiment to find the best way to reach your team.

Documentation not valued

Some company cultures view documentation as a cute suggestion from the kids’ table. If people are trained to believe that documentation is not valuable, they won’t use it. You can try some fixes that probably won’t work:

• Vary the headers to content ratio
• Increased accessibility and usability (as above)
• Adjust formatting to reflect the biases of the program or organization
• Change when and where requirements get presented

This issue can be painful to overcome, requiring leadership buy-in, training, the creation of genuinely valuable documentation, and plenty of time to shake off (or turn over) bad culture. The good news is that the needs filled by documentation don’t simply disappear. Instead of formal documentation, implementers rely on other methods such as chat, email, and meetings. Are you a BA if you document only via those channels? We’d argue yes!

A business analyst’s effort should affect the way stakeholders talk and the way implementation teams work. You’ll know you’re succeeding when you can point to sense-making or output work that permanently altered your project’s trajectory for the better.

By contrast, impotent business analysis efforts follow a common trajectory: robust, even glitzy early work, then scattered, hollow, or unmaintained late-stage work ignored by engineers, none of which centralized discussion or changed anything. You’ll know your business analysis efforts aren’t hitting right if you detect the indicators below.

Repeated conversations on the same topic

“Wait, this again? I thought we cleared that up weeks ago! As you can see here, section 2, paragraph 5, part C clearly states…”

There's an unsettled argument afoot. Worse, this was something the BA was supposed to lock down, but didn’t. Or so it seems. Recurring conversations and re-litigation come from:

• Failure to include all parties initially (“consensus” does frequently require literally everyone)
• Unclear or ambiguous program communication
• Insufficient documentation content or distribution
• Reliance on human memory

Generally, this is a buy-in problem that originated at the management level, but it manifests here at the project level as a cluster of communications-looking symptoms. Don’t be fooled, BAs—disarm the buy-in challenges first with your product owner, then communicate in a way that satisfies the new “everyone”. You’ll need to elaborate settled details progressively, but remember that repetition can easily become noise.

Work in progress blocked pending additional information

Technical PoCs, marketing rollout plans, distribution disruptions, customer data—there’s always an exogenous interloper holding the brake (or steering wheel) on your project. He or she shows up when:

• Leading-edge tech brings out more unknowns and dark corners
• The organization’s onboarding new capabilities
• Implementers started work a little too underprepared
• Overconfidence once again yielded its natural consequences

New information begets new requirements, and new requirements mean changes, rework, and throwaway work. The amount of “new” on your project will determine how regularly additional information becomes an implementation blocker.

When this issue strikes, conduct a root cause analysis to determine what was missing, paying attention to any patterns. If this particular style of blocker becomes a regular occurrence, figure out a playbook for handling it, as mitigation will be your only path forward.

Lots of feedback from QA

While generating feedback is quite literally QA’s job, too much feedback means something went awry further up the chain. Analyze their feedback on software builds to discern its core cause:

• Incorrect implementation
• Incorrect specification
• Incorrect understanding of requirements
• Incorrect requirements

From there, take corrective (or evasive) action as the situation demands. This will likely involve stakeholders who hate this part of their job, but that’s life, and rework is cheaper than releasing garbage.

Note that when implementation takes too long, stakeholder and reviewer expectations have time to shift, and they certainly will! If this happens, re-validate requirements just before development begins.

Unfortunately, it’s normal for an engineering project’s direction to waver. There’s a magnetism generated by the cosmological battle between the disorder of that day’s whims, individual agendas, and current Strategeist against the order of hard facts, truths, and original intentions. Every software project needs both forces, but it means implementers follow a shifting compass heading.

Requirements capture both order and disorder. While strategy will vacillate, requirements help limit the amplitude (and the resultant institutional drama) of said vacillation. Pay attention to the following signals to know whether your project’s strategy is overheating beyond your control.

Requirements outdated before development begins

The best early warning that you’re overheating is when the first version of your requirements becomes obsolete immediately after publication:

• Implementation leads don’t reference the requirements in discussion.
• Design and engineering implementers start doing what they want.
• Project managers feel the project slip from their hands.
• Testers pound their fists because they expected to write their test plan based on requirements, but now they don’t have a target, must wait until engineering’s finished, and can’t get ahead of their work—they can feel crunch time coming from months away.

The good news is that when this happens, it happens early enough to not create a catastrophe, and it causes enough ire to get escalated to someone who can crack the whip. The bad news is that any fix can pause progress, provoke several confrontations, and spin off a ton of rework.

Requirements change too frequently

You’ll get a second crack at knowing you’re in strategic danger when the cyclical documenting, undocumenting, and redocumenting of requirements arrives. You’ll find this most often when expert implementation stakeholders disagree:

• The team “gets things started” and looks busy, but this unagreed-upon start creates confusion and results in wasted effort and rework.
• Requirements get communicated to the engineering team before decisions are settled at the stakeholder level.
• Writing requirements becomes perfunctory, grinding busywork.

When this happens, the PO and the BA must wrangle troublemakers, let them air their grievances, and settle any differences. Instead of engineering to a half-baked plan, ask the engineering implementation team to perform research, or barring that, just do some team-building activities. You’ll be better off paying them to play paintball for a week rather than burning them out and losing their confidence.

Delivered software does not meet stakeholder expectations

You’ve hit critical temperature when software builds and releases simply do not match stakeholder expectations. This happens when:

• Stakeholders were not sufficiently engaged.
• Stakeholder expectations were not managed.
• Stakeholder expectations were not clearly captured.
• Stakeholder expectations were not fully communicated.
• Implementation challenges and changes were not communicated up the chain

Do your best to not get here. It means you’ve wasted the most time and money possible!

For the sake of the project’s direction, your requirements should act like a nuclear reactor’s control rods: moderating the natural reaction, preventing meltdown.

Solutions to requirements challenges rarely come fast, and if they did, they affect such a large and diverse audience they’d implement slowly anyway.

Seriously, act carefully

Firing off rapid changes from the hip might seem like the bigshot, ownership-seizing bootstrappy answer to your flagging BA effort. That won’t work. It won’t work because you’ll do it again. And again, and again. Then you, the BA and the PO, the keepers of the project’s official permanent-record-grade definition, discredit yourself and your work. What was the point of you?

Act with consideration. For any issue, try building an Ishikawa (Fishbone) diagram. Get acquainted with how others conduct root cause analyses (for example, USCSB‘s case studies). Also, be sure to log issues so that you can detect patterns over time.

What if my requirements are good, but I get pushback from my engineers?

Pushback may not mean your requirements are bad, but could indicate an issue with your solution. They may be trying to prevent you from overcomplicating the solution or re-inventing the wheel. Engineers can be reticent, so ask them to describe their concerns. They may be able to suggest an alternative approach that meets the requirements while saving time and money.

Pushback can also indicate a lack of engineering involvement early in the process. Their early involvement has at least two benefits:

1. It helps to ensure they have the same contextual understanding as everyone else.
2. It gives them the opportunity to influence the shape of the solution, often reducing cost and/or improving usability.

Engineers will point out when they don’t think the juice is worth the squeeze. They may not fully understand the value of the juice, and they may think the squeeze is harder than you think it is. They may even be right!

---

Space Cowboy and Next Mile make requirements effective. Reach out to us for software and hardware requirements that make your project more efficient.