Originally posted on BA Times in February 2013.
Once upon a time BAs were required to write long requirements documents that told an entire story. This story started with business requirements, functional and non-functional requirements, which fed detail design documentation, technical architecture and system specifications. This story allowed for, those of us who dared to, tracing each defined goal down to lines of code if need be. It was like a beautifully constructed 5000-piece puzzle. If you looked closely and took some time you could see how the puzzle was weaved together. The concept was that if a puzzle piece was removed you could see what was missing, the impact to the pieces around it and the bigger picture.
Songwriters did a similar thing in the past. They created albums: a collection of individual songs that told a story. Some artists worked hard to find a theme for an album and had clear reasons for the songs chosen for the album and the order. Some consumers liked the fact that an album had a purpose. Other consumers could not stand that you had to buy an entire album so you could hear the one or two songs you loved. Even though they had to buy full albums, that did not mean they had to listen to the full album the way the artist intended. That’s where the tape cassette helped out and people started making their mixed tapes, essentially their own album. This was the beginning of what eventually became how music is purchased today and the popularity of services like iTunes. These services changed how consumers bought music. Even though artists may still make albums that have a theme or tell a story, consumers just buy what they want when they need it.
The same thing is happening with BAs. Long documents are taboo. Hand anyone an old-school document and the eye rolls begin. People get overwhelmed. Consumers of analysis just want the pieces they needed to do their job. Even before BA practices switched from writing long documents, consumers started picking and choosing what they needed — just like the mixed-tape craze. Now there is a big switch from long documents to much-focused pieces for a specific function being developed. The focus is on one small piece of the puzzle. Like songs, each of these smaller sections of the requirements document can stand alone.
I think iTunes and YouTube unfortunately have turned the music industry into a one-hit-wonder world. Think of songs like Call Me Maybe or most recently Gangnam Style. On the flip side, I am thrilled the iTunes phenomenon has hit the business analysis industry. Many of you have witnessed the waste. A 5000-piece puzzle was put together when all you needed was a 1000-piece puzzle. Solutions were not started until all of the requirements were completely put together. This caused big issues when the goal of the project changed and some or all project requirements were not useful. The move to focusing efforts on smaller features and functions to be developed and delivered to the business is a positive move. But…something is lost.
Although this incremental approach to building the puzzle sounds great, there are downsides. How do you start a puzzle? You start with the border first so you know the boundaries of the puzzle and it helps you see how the smaller pieces fit into the larger picture. The same applies to business analysis work. Are you starting your work on the right issue or opportunity? Have you thought through what is trying to be accomplished before you start your puzzle or are you just starting to construct your solution? Do you know the boundaries of your analysis effort?
Using well-known analysis techniques like a context diagram can help get the team on the same page with understanding what is in the boundary of your initiative and what is not. Need help making decisions on the level of effort you should put forth with your project? If so, use the Purpose Based Alignment Model covered in Kent McDonald’s book Stand Back and Deliver. To help see the bigger picture and where things fit, use a decomposition diagram. Start with a mind map to outline the features and functions of a product. Even though you may be working on a smaller piece, make sure at a minimum you know how it fits into the bigger picture. Whether people admit it or not, they like it when they know the bigger picture.
Finding this balance will show how you add value to your team.
All the best,
- #AskAnAnalyst Podcast Episode 27: Remote Agile Team Success - March 23, 2017
- #AskAnAnalyst Podcast Episode 26: Are BAs Becoming Obsolete? - February 28, 2017
- #AskAnAnalyst Podcast Episode 25: State of Agile - February 7, 2017
- #AskAnAnalyst Podcast Episode 24: An Agile Mindset - January 27, 2017
- A Monthly Guide to Becoming a Better Business Analysis Professional - January 11, 2017
- #AskAnAnalyst Podcast Episode 22: Business Analysis in 2017 - January 10, 2017
- #AskAnAnalyst Podcast Episode 21: Business Analysis in 2016 - December 8, 2016
- #AskAnAnalyst Podcast Episode 20: Effectively Give and Receive Feedback - November 15, 2016
- #AskAnAnalyst Podcast Episode 19: Live from #BBCCon - November 3, 2016
- #AskAnAnalyst Podcast Episode 18: More Business Analysis Basics - October 4, 2016