Monday, 28 July 2014 11:42

Better Tools: Efficient Table Management

Written by

As a Business Analyst, I know that models and diagrams are the most effective way of expressing ideas, information, and outcomes. However, no matter how much I use visual content, I am often required to prepare text-heavy documents.

Whether it is requirements statements, business cases, service levels, project reports or dozens of other documents, sometimes I need to prepare written content as efficiently as possible.

To present written content, I try to maximise my use of tables, typically using Microsoft Word. I found the that the standard table tools in Word were not as efficient as I needed, so I set out to address these deficiencies.

This article outlines my thoughts on why tables are so effective, and indicates the improvements that I have made to Word's table management features. I then describe the techniques I used to build them, and provide a link where you can find further details and copies of each of the tools.

What Tables Offer

From a BA perspective, I believe tables provide the following benefits:

Item Feature Comment
1 Conciseness
  • The limited space in a table drives a focus on recording key information. Unnecessary content is discouraged.
  • Bullet points are encouraged.
  • Short phrases, possibly ungrammatical, can be used.
2 Usability
  • Readers are much more likely to scan a table; large amounts of information can be viewed at a glance.
  • Tables also allow the reader to spot patterns and search for detail that would otherwise be lost in regular text.
  • Tables focus attention onto the key points on the page.
3 Context
  • The column and row headings provide context to table entries that would be lengthy and repetitive to record in regular text.
4 Structure
  • The order of rows and their presence in particular sections conveys important structural information.
  • Numbering rows aids the review process and provides traceability.
5 Speed
  • Tables allow information to be captured and formatted quickly. This is important for BAs working to deadlines.
Monday, 28 July 2014 09:12

Business Analysts: Born or Made?

Written by

The short answer is both – shortest blog ever or ??? IF you know BOB F., please let him know he can claim his prize from me for his excellent answers presented in my last blog.

Back to our topic.  I for one have often blamed :)* my mother, Kathleen Ferrer (nee Morgan, September 26, 1923 – June 26 2014), the only person who both bore me and made me. I often thanked her for my life and her influence, and will miss her very, very much.

I thought I would try to investigate the common experiences or characteristics that lead one to an ongoing BA career.

So, here are some data from my life, left blank for the moment. Fill it in on paper or in your head if you wish, AND EVEN BETTER – Click here to link to the survey:

Then contribute YOUR experiences and characteristics (anonymously) to help all of us BAs and BA wannabes know – Born or Made?

All participants will receive a summary of the survey results if wished :)

Sunday, 27 July 2014 08:05

Assumptions in Analysis

Written by

Being an analyst is not an easy job! As thrilling as it may sound, working with unknowns is a nightmare. As one begins to work towards identifying the unknowns, an important challenge comes to the fore - How do we manage the unknowns that remain so even after dedicated efforts? Should we give up? Having loose ends impact the overall solution that shall be developed. And eventually impact the business objectives or even worse leading to failure of the business objectives!
Assumption – Defn: a thing that is accepted as true or as certain to happen, without proof.

Assumptions are as important as architecture, design, solution, model etc. Identifying assumptions is not rocket science and is not a cakewalk either. Discussing the solution with engineers, or design with architects, or while interviewing users - are some entry points that help capture statements or boundary conditions that have the potential to turn into actual assumptions.

While in the nascent stage of solution or requirements definition, assumptions provide a wonderful placeholder to document and manage the unknowns. As numbers of users grow and product/software evolves requests to modify the solution increase as well. Most of these requests, if not all, would require a change in the assumptions that were initially documented. It is extremely important to keep review the assumptions periodically and keep those up-to-date. Take, for example, an assumption that smart phone users may not have the blue-tooth switched on all the time, thereby indicating an extended battery life. With the arrival of smart watches, which must be paired using blue-tooth with a smart phone for optimum benefits, the assumption on blue-tooth usage must be taken out of the solution!