10 Ways Documents and Spreadsheets Sabotage the Business Analyst’s Career


At long last, Business Analysts are stepping into the spotlight.

Job rankings reports over the past few years (including ones by CNN Money and job search engine Indeed.com) rank Business Analyst as a ‘hot job’ for the future. And survey data spanning from 2008 to 2010 from Blueprint Systems reports that 37% of BAs now use some kind of purpose-built requirements software tool in their role.

Most BAs, however, still rely on documents and spreadsheets to manually stitch together their requirements. For those BAs, this article points out five ways that documents and spreadsheets are hurting your career and preventing you from joining the growing number of BAs who are fully equipped for the future of the profession…

Reason 1: Documents and spreadsheets reduce you to an Office Clerk

96% of BAs say analysis and critical thinking are very important or critical skills.Documents and spreadsheets require that you spend copious amounts of time organizing, double-checking, cross-referencing, searching, copying, pasting and typing.

With so much clerical work going on – how much time and energy do you have left for strategic analysis and critical thinking? You’re in charge of a critically important Business Requirements Document (BRD) yet your contribution to that document might be 85% clerical and only 15% strategic. It’s hard to make an impact in an organization when your own strategic input represents only a sliver of the hard work that goes into your BRD.

Callout: 96% of BAs say analysis and critical thinking are very important or critical skills.

Reason 2: Reviewers don’t like reading your documents (and you end up paying the price)

53% of BAs say the majority of requirements feedback occurs in
the later stages (development and testing) of the development lifecycle.When reviewers are staring at a multi-hundred-page document but not looking forward to reading it, often times they will sign off on the content without reading everything in full. They know that even if the don’t do a detailed review, at least the project will advance to the next stage, and that any errors in the requirements can be caught and corrected during development. But when those errors crop up, the project stalls and a massive rework effort kicks off.

Unfortunately – and quite unfairly for the BA – others may assume that you, and your error-riddled BRD, is what caused the expensive project slowdown and rework which couldn’t be farther from the truth!

Callout: 53% of BAs say the majority of requirements feedback occurs in
the later stages (development and testing) of the development lifecycle.

Reason 3: Documents make you the bottleneck one very project

57% of BAs say requirements change based on feedback from various stakeholders throughout the requirements lifecycle.Inviting others to mark up a document creates a tremendous amount of new ‘open loops’. Every time a reviewer enters a comment, question or suggestion, your To Do list gets bigger. It falls on you to keep track of every newly opened loop and bring every single one to completion. And you know the drill that follows... a whole lot of chasing people down, brokering conversations between stakeholders, sending more emails and writing more revisions. The sad irony here is that you become the bottleneck to your own requirements project!

Callout: 57% of BAs say requirements change based on feedback from various stakeholders throughout the requirements lifecycle.

Reason 4: You lose most of the work that goes into your BRD

95% of BAs use capabilities other than Track Changes to communicate and record feedback, discussion, and rationale for decisions made.When the dust settles at the end of the requirements phase, you’re usually left with
[?]no accessible ‘history’ of how your BRD came to be. All those emails, meetings and important conversations where people explained ideas, answered questions, and made key decisions are gone. Then the change requests come, perhaps new people enter the discussion and before long the rationale behind key decisions gets forgotten.

This is torturous for the BA. Things are going off track, but no one has a way to access past conversations and decisions from the requirements phase.

Callout: 95% of BAs use capabilities other than Track Changes to communicate and record feedback, discussion, and rationale for decisions made.

Reason 5: Using spreadsheets to manage dependencies puts all the risk on you

Dependencies are integral to requirements. You can’t truly understand a set of requirements unless you know all the dependencies between them. Maintaining these dependencies in a spreadsheet not only handicaps your readers, but also makes your analysis tasks more difficult and your maintenance tasks harder.

Managing a separate spreadsheet makes a highly critical process highly error-prone, and puts all the risk of errors and omissions squarely on your shoulders.

Callout: 54% of BAs are using spreadsheets to manage traceability on their projects.

Reason 6: Your documents travel around in cargo class (a.k.a. ‘Email’)

The average number of office emails received each day is 87.The average office worker spends 41% of each workday just managing email.

This is simply horrible news for the Business Analyst. Those emails that carry your BRD around – the very document that is so essential to your role – competes with 86 other emails in the overstuffed inbox of each reviewer. One day later, there are 173 emails to compete with. With odds like these, you can be certain that your document isn’t getting the full, focused attention of your reviewers.

Callout: The average number of office emails received each day is 87

Reason 7: Writing documents soaks up time and slows down progress

As small pieces, or entire sections, of your BRD get completed, technically each one is ready to share. However, everything tends to sit inside the document until the final piece falls into place and the document is polished to the BA’s satisfaction.

So reviewers see nothing until one day when the entire Version 1 arrives with a thud in their inbox. Any potential time savings for feedback and review are squandered, making it more likely for feedback and change requests to extend throughout the entire requirements lifecycle.

Reason 8: ‘Track Changes’ kills any hope of real collaboration

Using a document’s ‘Track Changes’ feature only encourages your reviewers to enter feedback while sitting alone, in silence, in front of their computers.

When this happens, there are no conversations happening. No sharing of ideas, no opportunity to clarify something, or to ask a question, or to give a helpful answer.

Instead you have individuals squeezing more and more words into a document that gets messier and harder to read with every added sentence. And... you guessed it, you’re the one who gets the nightmarish task of sorting, comparing, and keeping track of all the commentary.

Callout: 84% of BAs value collaboration as a very important or critical part of their role.

Reason 9: Documents force everyone to 'translate’ ideas into text

People mentally conceive ideas using imagery and pictures, yet a long and detailed document like a BRD forces everyone to translate their colorful visions into flat, dull text.

As others read that text and translate it into their own mental pictures, misunderstandings are inevitable. When reviewers express their confusion, the kneejerk reaction of the BA is often to write more text in an attempt to add clarity to the words on the page. But the opposite result is achieved... as the page count of your BRD goes up, the clarity and readability of all the ideas inside it actually goes down.

In contrast, many Business Analysts recognize visual modeling as a superior way to communicate ideas purely and clearly. Most BAs, however, are so consumed by the gargantuan task of writing and clarifying the text content in the BRD that the time for thorough visual modeling just isn’t available.

Callout: 58% of BAs view modeling as a critical or very important part of the requirements process.

Reason 10: You simply can’t get much better or faster at your job when your tools hold you back

The vast majority of Business Analysts (88% according to our most recent survey) still use documents and spreadsheets to some degree to perform their job. For these BAs, no matter how much more knowledgeable and capable they become, the actual impact they can make inside their organizations is diminished to the degree that they rely on highly manual documents and spreadsheets as their primary office tool.

However, not every BA is willing to let their career path be held back by antiquated tools. 37% of Business Analysts now use some kind of purpose-­‐built requirements tool to improve the way they do their job. Many of them still produce a BRD, the difference is, they’ve embraced the software tools that let them do so with a single mouse-click.

Take Charge of Your Career…

The future of this profession belongs to the growing number of Business Analysts that have broken away from the chains of documents and spreadsheets in favor of requirements definition and management tools that are purpose-built for the Business Analyst role.

If you’re not familiar with these technologies, it’s time to educate yourself. To compete as a Business Analyst of the future, you must have the right tools for the job. Get a clear idea of how these requirements tools can help you perform better and faster, and embrace the bright future that this profession has to offer.

Author: Tony Higgins, VP Product Marketing, Blueprint Software Systems Inc.

Tony Higgins [@higginstony] is a 27-year software industry veteran, who has spent much of the past decade focused solely on developing software requirements solutions that support and enhance the role of the Business Analyst in today’s enterprise.

Did you like this article? Watch a free on-demand webinar on the same topic presented by Tony called “Top 10 Career-Crushers that Threaten Every Business Analyst – And How to Prevent Them!” 

Like this article:
  31 members liked this article


Tony Markos posted on Monday, April 22, 2013 10:01 AM

Great article! Critical topics! Using text to describe the required behavior of a system is trying to use a one dimensional technique to describe a multidimensional entity. Same basically with spreadsheets.

BA's need to think Agile Modeling - not text and spreadsheets. For both Agile and Waterfall projects, what I have found is that some higher level Data Flow Diagrams (including a Context diagram) focusing on the unchanging essentials, a few ERD's, and maybe some screen shots is all that is needed. The detailed requirements can be handled in conversations between the developers.

Note: The Data Flow Diagrams also serve as minimal, yet quality documentation of traceability.

Gitter Done!
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC