November 5, 2012
by jculliferslalom
Introduction
My Twitter feed would explode if, as a business analyst (BA), I was required to tweet all of my project requirements. For this and many other reasons, tweeting requirements is unlikely to become a best practice any time soon. First, there is the very public nature of Twitter, and second, the brevity that Twitter requires at 140 characters or less per tweet.
Everyone knows that business analysts write extensive (read: lengthy) Word documents and Excel spreadsheets full of requirement statements to demonstrate a thorough understanding of the subject matter at hand. In some organizations, the bigger the document, the more highly regarded the business analyst—even though few (if any) of their stakeholders actually read the material they’ve written. To be clear, I consider stakeholders to be both the business and technical project partners who consume requirement and rule statements for validation or production. Feel free to tweet me back @justincullifer if you disagree with my claim that stakeholders are not reading the material.
Considerations
A colleague of mine shared that, in a former position, he managed a team of a dozen or so individuals in a product management organization. Business analysts were a part of this team, responsible for eliciting and capturing requirements for technology projects. His BAs produced the customary requirements documents from which developers coded and testers tested. He shared that one of his brightest BAs used to include, in every requirements document over the course of several years, a statement that said, “If you read this, call me at [phone number], and I will give you $20.” Her phone never rang. While a comical anecdote, the more serious implication is what many of us have known for a very long time: lengthy requirements documents are nearly impossible to consume and retain.
Attention span varies from person to person. Some of us have the ability to work heads-down, fully immersed in the subject matter at hand. Others work in patterns of on-and-off focus time intermixed with breaks for conversation, reading news, or catching up on email. Still others find it difficult to focus for any significant length of time and therefore devote little time to any one item. We can take a lesson from network news media and social media, who accommodate those with the shortest attention span by delivering sound bites, headlines, tweets, and wall posts. Perhaps BAs should consider this approach, as BAs must deliver informative statements in a timely manner.
This returns us back to the hypothetical use of Twitter for the delivery and consumption of requirements and rule statements. If BAs are limited to 140 characters, they are going to try really hard to make the very best of those 140 characters. Here are some ideas about potential content:
- They might mention the user role to which the requirement or business rule pertains by using an @ mention. For example, @Librarian must always obtain a @Customer driver’s license number prior to issuing a library card.
- They could specify locations by leveraging the cross-hair “add your location” feature.
- Attaching a static wire-frame using the camera’s “add an image” feature may prove particularly useful when tracing requirements to visualize user interface pages.
- A link to artifacts, videos, or models using a bit.ly link would surely maximize the 140 available characters. Now, now—no cheating! Linking to lengthy Word documents or Excel spreadsheets would break our imaginary set of rules!
In this fictitious world of tweeting requirements, the onus would be on the BAs to make the most of their brief statements. To simply tweet hundreds or thousands of tweets negates the remarkable nature of this concept: concise and targeted requirements. Concise and informative headlines, tweets, and wall posts are exactly what media outlets have found that people are accustomed to and respond to in today’s connected world. Is it possible that leveraging Twitter might be the next leap in the evolution of BAs focused on delivering requirements that have been fully vetted for clarity and accuracy?
Consumption of high-quality requirements is critical to the success of every project. Imagine that your project stakeholders (the ones validating the accuracy of the requirements) followed their BAs’ Twitter handles and kept close tabs on newly tweeted requirements as they came across their respective Twitter timelines. The stakeholders could elect to reply to each tweet with corrective feedback, or even re-tweet requirements to other stakeholders for validation. Since tweets appear at the speed of light, the stakeholders would be forced to frequently monitor their timelines, so as not to miss any critical requirements or rule statements and, subsequently, their opportunity to provide feedback or approval. Tools like Tweetdeck may enhance this process, but each would require the stakeholders’ attention. A by-product of this fictitious world is the fact that the BA would have significant influence over their stakeholders’ schedules, which is only a dream of BAs in most organizations. The same concept would apply to consumers farther along in the project’s lifecycle, such as developers, testers, and trainers, who would also need to monitor their timelines for the same material.
In spite of the perceived benefits of tweeting requirements, I realize that organizational barriers will continue to require the production of Word documents and Excel spreadsheets most of the time. Industry trends are favoring the adoption of robust requirements management systems like Jama Contour and IBM RequisitePro. These systems have lower costs of entry and flexibility than ever before, allowing project teams to capture, manage, and consume requirements effectively. Arguably, the downside of such systems (and Word and Excel) is that these systems still allow BAs to freely enter extensive amounts of text that someone, eventually, is going to have to consume. To the points made earlier, BAs must understand that their stakeholders consume information in sound bites and must clearly articulate requirements to accommodate all levels of interest and attention.
Conclusion
Given the concurrent trend of businesses seeking to expedite speed-to-market and respond to customer feedback quickly, I believe that BAs will need to find creative ways to follow more pragmatic approaches to their elicitation, documentation, and delivery behaviors.
Leveraging advanced requirements methodologies, such as Requirements Visualization, enable business analysts to work collaboratively with user experience designers to elicit, capture, and deliver the right requirements at the right time. In turn, stakeholders can maximize their time and gain greater visibility into every stage of their projects. Interactive models traced to thoughtfully produced requirement and rule statements ensure that stakeholders are engaged and interested.
Until your organization adopts a contemporary requirements methodology, consider my tweeted requirements proposition: keep requirements succinct, accurate, relevant, and as easy to consume as possible.
Like this:
Like Loading...
