I found Doctor BA in his garden out behind his modest house in the country. At first all I could see was a three foot wide floppy hat covering his signature mane of white wavy hair. He was on his hands and knees moving black soil around with his hands. Next to him laid out uniformly were shovels, spades, hoes, a pitchfork, and the always present flip chart easel, pad and markers and pot of coffee. Nearby was an old hand push lawn mower that only people of a certain age will remember seeing much less using.
“You seem to be gardening the old fashioned way.” I remarked to him as I took a seat in the wooden Adirondack chair nearby. He pushed his hat back on his head so I could see his face.
“It’s the best way. Plain, simple tools don’t get in the way of communing with nature, of feeling the earth and truly understanding the elements of growing things.”
“I see. Doesn’t it take longer?”
“Maybe. But with the automated lawn mowers and such it is easier to make a mistake and then you have to redo it. With these tools I approach the work in a more contemplative and focused way. Less chance of a mistake. Better results in the end and after all, that is what we are after.”
“Well it just so happens that I have a question about tools.”
"What tools do you suggest a business analyst use in pursuit of his or her vocation? What tools can be used as best practices for business analysts?”
Doctor BA stood up, took off his gardening gloves, adjusted his hat, brushed the dirt off the front of his dress shirt and tie and walked over to the flip chart.
“Let me make a bulleted list for you. It will be easier to understand.”
With that, he wrote on the flip chart page: I didn’t have any note paper with me so I turned on my phone to record him so I could get everything he said.
“Best tools for business analysts work:
- Pencil
- Eraser
- Paper
- White board
- White board markers
- Flip chart easel and paper (easel optional)
- Flip chart markers”
He could probably tell from the quizzical look on my face that explanations were due although generally no such prompting is necessary for Doctor BA to expound. He poured a cup of coffee for each of us from the pot on the picnic table and commenced to explain.
“The problem with automated tools is that you can get so wrapped up in how the tool works and what features are available that you forget that you are defining or solving a problem. I watched a group of business analysts circling one fellow at a desk top computer once. They were working on an entity relationship diagraming tool. They spent an inordinate amount of time adjusting the sizes of boxes and centering lines on those boxes and so forth. The group certainly was animated and involved, but they were not discussing alternatives or possibilities or solutions or anything like that. They were discussing how the diagram should look. In fact, there was one box in the middle that was unlabeled and they still spent time adjusting the box size and connectors to the box. When that happens, the business analysts are more concerned with documenting, believing that their worth is based on the appearance of the document rather than its content."
“Why is the emphasis on documentation over analysis more prevalent now?"
“I believe it is the result of automation. We have these tools to make all the diagrams easier to draw and store and use. And all that is wonderful. But because the process can go faster, the users of the process also want to go faster and don’t spend the requisite time gathering information and analyzing that information. Sketching a diagram on a piece of paper while you are eliciting a description of a problem domain process is a terrific way to gain understanding. You don’t have to interrupt the responder describing the process to make your diagram neater or more readable. And you can let the responder describe the process, or the desired process, in any order since you can pencil in additions, and quickly erase changes of mind. The purpose of the diagram is to gain understanding of what the responder is describing. You can even confirm your understanding by showing the responder your diagram. And you can throw the sketch away at the end if need be. The sketch has served its purpose."
“But if you have a tool, say Visio or Rose or Smart Draw or whatever, you don’t tend to make that diagram since you will be diagraming when you get back to your computer. You rely on words and your notes and then later try to convert those words and notes into a diagram, partly for understanding, one would hope, but mostly to document what you learned and include said document in the overall pile of pretty pictures you turn in to someone for review. To prove that the job was done."
“And because it appears on the computer screen you perceive it as formal and spend a lot of time making it ‘look good’ or ‘right’. This is something that is not of concern with paper and pencil or marker and flip chart."
“Remember, what is important is what we are thinking, what we are creating, what we are solving, not what we are drawing or documenting."
Doctor BA paused for another cup of coffee, draining the pot. He surveyed his garden.
“And another benefit of these tools: they are always available. You don’t have to worry about computer crashes, lack of power, inability to connect to some network or other. And they are quite portable. I don’t need to set anything up if I am using paper and pencil. Just pull them out of my jacket pocket or brief case.”
I wanted to take a picture of the flip chart with my camera as I usually do, but the sunlight was too bright and Doctor BA’s notations were washed out. Fortunately, I Doctor BA had some extra paper on the table and I automatically took notes because when I replayed the recording the wind and bird sounds distorted the recording so I was not able to render his explanation word for word.
As Doctor BA finished his last cup of coffee, he made one last comment, “And simple tools are usually less expensive.”
Doctor BA escorted me to the front of the house where I had left my car in the driveway. He also lent me one of his bicycles to get home when my trusty car did not start.
Author: Steve Blais, PMP, PMI-PBA
Steve Blais, PMP, PMI-PBA, is an author, consultant, teacher and coach who has nearly 50 years’ experience in Information Technologies working as a programmer, project manager, business analyst, system analyst, general manager, and tester. He has also been in an executive position for several start-up companies. He develops business analysis and agile processes and trains business analysts, project managers, and executive for organizations around the world. He is the author of Business Analysis: Best Practices for Success (John Wiley, 2011) and co-author of Business Analysis for Practitioners: a Practice Guide (PMI, 2014) and a contributor to the Business Analyst Body of Knowledge, V3 (IIBA, 2015).