Business Analyst tools stink, part 1
Ted Hardy, MBA, CBAP, is starting his ninth year as a BA and his third as a BA manager. He has worked around the globe for companies and clients in the high tech, finance and service industries. He specializes in business process analysis and communicating the impact of technology to his customers.
This is part 1 in a 2 part series. Part 2 will be posted tomorrow, so check back then for the conclusion.
One of the best things about being part of a BA community is how the thoughts of other BAs can spark a new line of thinking for yourself. You open up a link written by someone who you think highly about, read through the text, browse the diagrams and then somewhere near the bottom you have to stop reading to work through your own miniature brainstorm. Something the author wrote perked up a dormant neuron, just like that morning cup of tea perks you up. The same thing recently happened to me as I read Three Reasons to Upgrade from Business Rules to Decision Models by Barbara von Halle and Larry Goldberg.
The most intriguing thing to me was how they, unknowingly, captured one of my biggest complaints about the tools BAs have at their disposal for properly documenting process, procedures and requirements. The authors did a fabulous job making the case for why we should consider moving to decision models, but it only emphasized more that the tools to pull off such a change in focus simply do not exist.
Ways in Which Our Tools Fail
That is not to say that there are no quality tools out there for a BA to use, far from it. There are numerous tools to capture requirements and their attributes, to help map business processes, to capture sign-off from stakeholders and design prototypes or early mockups. Each of these tools is usually specialized for a single task, which is not a bad thing, but the failure of each of these tools comes in one of two stages.
The first failure is that of integration. Lets assume that our organization creates minimally functional prototypes whenever its time to do a system upgrade. We bring out our prototyping tool, create a few screens, add the needed fields, text and graphics, possibly throw in a little screenflow magic and tada, we have our prototype. Our stakeholders review that, possibly in a JAD session, give feedback which becomes a refined prototype and eventually makes its way into some type of requirements document.
Now, we have this great prototype that we need to reference in our requirements document. We’ve got a few options:
- Screenshot = The most expedient solution is also the most destructive. All of the wonderful interaction captured within that prototype is gone in favor of something that can be printed out to be marked up by our stakeholders. The interaction can be marginally retained by adding in a series of shots or by placing navigation trails on top of the screenshots, but the ‘flavor’ of using the prototype just isn’t there.
- Video = This gives the stakeholder a better understanding of system usage, but still does not allow the stakeholder to actually use the application. They can see someone else use the prototype, but do not have their own first person viewpoint. While its easy to mark up a screenshot, its very difficult to do that with a video. You can’t print it out like you could a screenshot, so while this solution gains something in terms of what the end goal is, it lacks considerably in terms of usability as a medium for capturing quality feedback.
- Link = If that prototype can be bundled into a single executable file, or is something that can be served up as a web page, the requirements document can contain a link to the prototype that the stakeholder can use to launch the application. If the prototype can not be run without specialized tools installed or the application cannot be run from outside of a secured environment, then this is not a viable option.
The second way in which existing tools fail is really an outgrowth of our society, with the focus on the printed page. The page formats we use (be they US Letter, A3, A4, Legal, whatever) are all based upon our trained desire to hold, touch and experience a physical representation of whatever information we are consuming. Gradually our society is changing, but the printed page still skews our sense of what is correct usage.
Why, in our digital age, is the 8.5"x11" page format the default setting in the US for word processing documents? The Google Doc I am using to write this is formatted this way, even though I will never ever print this document. While many people do print their documents, due to cost and environmental concerns, you will see less and less printing as the years go by and new professionals enter the business place that are more comfortable working with electronic media that physical media. Once the tipping point is reached where it is no longer the default mode to print, I am willing to bet that our document processing tools will still default to printed paper sizes. To me, this is absurd. Don’t believe me? Take a look at this document I’m writing:
Sure, I could zoom in so that those large gray sections on either side of the screen are filled with text, but then I could see only a very small vertical slice of my document. I’m not saying its a better solution to have the text to remain the same size yet go from margin to margin as that would make the document very difficult to read. But this does illustrate that none of the paradigms we have inherited really fit with our current situation.