Their inclination toward using Word and Excel is very much understood. The gratification is immediate—except for styling and indentation there is not much effort required. This is where the gratification stops and complexity begins. After all, no BA is an island, and the collected requirements are supposed to be shared and managed by multiple stakeholders. Such stakeholders include requirements reviewers, developers, testers and marketing managers.
When an entire set of requirements is handled as one big chunk of text it is quite impossible to reach proper levels of governance, collaboration and business intelligence.
 |
| Image courtesy of Dilbert.com |
Comparing handling requirements using Word and Excel to managing requirements using managed systems reveals the shortcomings of Word and Excel. Here are just a few that come to top of mind:
Lack of Governance
- Lost Requirements – When a requirement boils down to one or a few paragraphs, with an unintentional flick of a button, a requirement can be mistakenly deleted. And when the document is saved, the requirement is practically purged. These are the times when you start praying to the gods of Word and Excel and email that you have a previous copy to find the requirement.
- No Workflow Enforcement – A document as a whole and even the particular sections and paragraph are expected to follow some sort of workflow. For example, going from draft stage to Review and Sign-off stages. As no inherent means are provided by Word and Excel to do so, each company finds itself inventing some color-coding, labeling by comment, dedicated table mechanisms to achieve that flow. Such mechanisms rely on the authors’ good will and meticulousness to manage and maintain those mechanisms. Such methods are fragile and break quite quickly.
- No History – Unless you put the effort of keeping a change table or saving the document in My_Feature_2014_11_10.docx there is no way for you or any other stakeholder to examine the changes that were made or to learn of the particular person who made a change. Not to mention that reverting back to a previous copy of a section in the document is almost impossible. When regulations and auditing come into play, no history means there is no way your process will ever be approved.
- No Access Permission Level – Once you (and any other person) are in the document for editing purposes you are free to modify anything you want either intentionally, inadvertently, or even maliciously without leaving a trace.
Lack of Collaboration
- No Single Source of Truth – Even if you utilize shared repositories such as
MS Sharepoint there is no guarantee that the Sharepoint copy is indeed the latest. Even as the owner of the document, you cannot assure that all the other stakeholders are retrieving the last copy you shared. This results in multiple copies that are scattered around the company with no true reflection of what is the most updated truth. - No Concurrent Access – When using a document all the requirements are turned into one big chunk of information. If you wish to edit one section, no one can edit another at the same time. The matter becomes worse when conflicting edits can be made on the same section without any mechanism to reflect them.
- No Proper Collaboration– Reviewers have much to say about the document content. The more reviewers the messier the document gets with multicolored comments and notations. Eventually all comments are cleared to leave a clean, agreed-upon content, losing all traces of all past comments and interactions.
Lack of Analysis
- No change Impact analysis – How can you make sure that modifying the billing system requirements will affect the ordering system requirements? With Word or Excel you cannot. As it is plain data. And again, unless you cover the text with numerous tags, colorings and annotations, it is almost impossible to follow up on any possible change impact.
- Planning vs. Delivery – To improve the content definition from one release to another, one must be able to assess the effectiveness of the content definition. Using plain documents, there is no easy way to assess the planned content against the actual delivered content.
- Dependency on Tacit Knowledge – Each part of the content carries with it extra information such as the rationale of the requirement, the reasons for de-scoping it, the steps taken in refining it, etc. All this information, if not captured in designated placeholders of a system (e.g. attributes, comments) is kept only as tacit knowledge of the one handling the content. This means that highly valuable information is as transient as the content owner in his position. When the content owner sends out an email “It has been great working here for the past 6 years and now it is time for me to explore new challenges…”, all of that valuable information leaves the building with that ambitious employee.
Word and Excel are great tools for handling documents however they fall short greatly in handling data.
BA’s documents imply much data and that draws the line from which Word and Excel become a liability for companies who rely on top quality requirements gathering and management.
How can you turn your BAs from working with Word and Excel to work directly with your application lifecycle management systems? Is it a technology issue? A functional issue? Is it just breaking the habit?
Have you managed to make the transition from using documents to using managed systems? If you have I would love to hear from you. Feel free to reach out to me in the comments section below.
I will be very happy to meet you and hear about your experience in this matter and your ideas in the upcoming HP Discover Barcelona – Join me in Discussion Forum DF5316 titled “Engaging BAs to work with managed systems” - There are a limited number of available seats, so make sure you register in advance.
You can register for HP Discover in Barcelona here. Trust me, you won’t want to miss one minute of the action!
See you there,
Ofer
