Steve Blais is someone I often refer to in my presentations as “the consummate business analyst.” We’ve met Steve before – I interviewed him in 2010 about the essence of business analysis. Since then, he’s published a new book, Business Analysis: Best Practices for Success. And while I haven’t finished the book yet, I’m really impressed with what I’ve read so far. And Steve has been gracious enough to answer a few more questions…this time about the process and concepts behind how the book has come to be.
Laura: When and why did you decide to write a book on business analysis?
Steve: Years ago, I began collecting comments and observations about business analysis as I started to review business analysis processes for companies in a consulting role. I noted how similar the processes were to work I had been doing in the past and not calling it business analysis. The comments and observations grew into a tome of nearly nine hundred pages which I called at the time, “The Beginning and End of Software Engineering,” referring to the business analyst’s Solution Life Cycle which starts before software engineering begins and does not end until well after software engineering has completed the product. This evolved, or perhaps devolved, into the current book which went through a couple of rewrites to reduce the scope, and several title changes. The leftover material has been repurposed as parts of upcoming books in the business analyst series for John Wiley.
Laura: You mentioned that there were several different working titles. How did you settle on the subtitle, Best Practices for Success? And, on a related note, how would you address the philosophy of some BA thought leaders that there are no “best practices,” only “better practices” or “continuous improvement?”
Steve: While the book is filled with many and varied tricks, tips, techniques and practices, any one of which might be the best for an individual, in the end there are no real “best practices” for everyone. However, there are enough of them in the book that most likely the business analyst reader will pick up and try one or two of them and find that they become the business analyst’s own best practices for success. Perhaps the title might read, Business Analysis: Best Practice for Success, which means that successful companies and organizations practice business analysis in a formalized process. Or perhaps, the plural on Practices might refer to the fact that Business Analysis is not just one practice, but a collection of practices from defining business problems to testing the solutions to facilitating decisions to transitioning the solution into the business environment. All these business analysis practices taken together spell success for the enterprising organization. And the business analyst is the person behind those practices.
Laura: The body of BA literature is growing each year, how does your book set itself apart from the pack?
Steve: I haven’t read the entire body of BA literature as yet, but I’m working on it. So far, I’d say the difference is that my book is practical rather than academic, theoretical or standards based. My book reflects my real life experience and that of hundreds of fellow business analysts around the world. I also include a lot of “guerilla tactics” that do not follow the rules or standards but are tricks and techniques that get the job done and solve the problem. For example, what do you do when the senior manager presents the solution she would like to see implemented, and when you get into the elicitation you realize that her solution is inferior to all other solutions? But she is the boss. I suggest a rather novel and a bit unusual human tactic to get out of that particularly political situation. These are the techniques you won’t find in the standards manuals.
Laura: What was the most challenging part of writing the book?
Steve: Actually, it was a technical thing. Because I had been writing the book for so many years I collected lots of quotes and references over those years and when the book was near completion, the editors at John Wiley asked me to complete the references in the bibliography and in the footnotes completely, with page numbers and volume references for magazines and that sort of thing. Well, I hadn’t recorded my quotes to that level of detail, so I had to do considerable research through archives of magazines and newspapers to try to find the exact page numbers and so forth. Many I didn’t find, especially the quotes I took out of newspapers or those which were in personal emails or from conversations. So I ended up taking many references out simply because I couldn’t get the accurate source. It was about two weeks of continued work. That was much harder than any of the writing.
Laura: I love the questions you’ve incorporated into the book. Where did these questions come from?
Steve: From business analysts all over the world and they are all actual questions. Many of the questions came from many different business analysts, as did the problems business analysts face that are listed in the appendix. I have continued the concept with an “Ask Dr. BA” page on the book website which addresses questions received since the book was published. The answers are, as usual, somewhat whimsical in tone, but have the same practical tips as the book.
Laura: I always find that writing helps me learn. Did you have that experience as well? If so, what did you learn about business analysis by writing this book?
Steve: Yes, indeed. If nothing else, writing forces you to do research into the various topics you are writing about. Doing that research, whether it be reading previous books and articles on the subject or talking with practitioners, gives you alternate perspectives and a wider view of the topic than when you started. It is a matter of keeping your mind open to the new ideas even when those ideas conflict with your previously held views and opinions. There is usually no “one best way” to do anything. Rather, there are best ways to do things based on the situation and circumstances. So, you start thinking in questions instead of didactic statements. And when you get answers to those questions, you learn, and keep learning.
Writing, whether you are writing a book, an article or an email, helps focus your thoughts. As such, you can assemble a mass of amorphous ideas and vague impressions into a cohesive concept on which you can build principles and practices.
As an example, I have always felt there was more to business analysis than documenting the business needs into a requirements template for use by the development team. I observed that the end result, the product, was better when I wandered away from the cozy confines of the IT project and explored the business processes surrounding the computer software and hardware. When I started to record my thoughts on better ways to develop requirements and the software depending on the requirements, the concept of the business analyst being more than a requirements recorder and change documenter began to become clear. And as I wrote more and investigated more, I realized that most business analysts felt the same way. The book then evolved into a description of an overall process from problem definition to business solution, and has spawned the kernels of several more books on that subject. And the fun part is that I am still learning, even after forty-four years in the business.
Laura: Anything else you’d like to share with our readers?
Steve: The business analyst is the solver of business problems in the organization. As a business analyst, start by defining the real business problem, not accepting the “need” presented by a stakeholder. Focus on the problem and the solution to that problem even if the solution does not involve software development. Understand the whole business process around the problem you are solving. Be proactive. Take chances. Make recommendations. Analyze the business.
Currently, the business analyst is facing a change in the approach to software development. There is the onslaught of agile and the perspective of the erosion of the business analyst position as agile development teams work directly with the business stakeholders with no “middleman” business analyst involved. Business analysts who focus on analyzing the business and identifying improvements in the organization’s products and services rather than documenting requirements, have no fear from the agile evolution and will find they have a prominent place at the table. I devote the next book, Center of the Organization: the Agile Business Analyst to that subject.
Read More About Better BA Practices
7 Secrets of Good Business Analysts
Are You Stretching Enough to Become a Great BA?
How Do I Convince My Team to Adopt Better Requirements Practices?
Thanks for taking the time to expand your views, Steve! I am happy to know that we are on the same page on this (as in any other topic so far, heh).
I completely agree there is much analysis to be done when we move out of the room after a good face-to-face requirements session — I have so many examples of rework and unmet needs caused but people thinking that one conversation could take care of all the details. As you say, looking at what is going on in reality with the business process is extremely important, as it is to sit down and apply techniques such as building a decision matrix to make sure all scenarios have been covered (the answer is usually no).
I do indeed agree, Adriana, and love your rephrasing of my sentence. Even user stories and backlog items have to be written clearly and unambiguously. There is a trade-off that is missed many times. I can spend a few extra minutes to clarify my thoughts, findings and requirements and write them so that the business and the development team and anyone else understand them, or we can all get together in a room and spend an hour hashing it out until we all understand. Granted, either way I must be a facilitator and communicator, but when the requirements are known and I write them clearly, there is a lot of time saved, and as you so elegantly put it, not just now, but in the future.
Writing careless thoughts and ideas on an index card or as an entry on a backlog just because it doesn’t matter since what is real is the ensuing conversation sometimes seems like a shirking of one’s responsibility to perform due diligence and analyze the situation. There is indeed analysis that goes on in a room when a product stakeholder or two meet with the development team, but I submit there is even more analysis that can take place when you move out of the room and into the business to see what is really going on. And it doesn’t matter what the title of the person who does that is, whoever takes on that task is playing the role of business analyst.
Thanks for the interview, Laura! It’s always a pleasure to read Steve’s thoughts.
Steve, I can see myself quoting your last remarks until people get tired of hearing them :-). I would just rephrase a bit what you said regarding documenting requirements, to read:
“Business analysts who focus on analyzing the business and identifying improvements in the organization’s products and services rather than merely documenting the need presented by a stakeholder, have no fear from the agile evolution and will find they have a prominent place at the table. ”
As I accumulate experiences with agile, I become more and more convinced that relying mostly on face-to-face conversations and producing just enough documentation to allow the software to be built (as proposed by agilists) may generate short-term benefits, but in general at a high cost to future decision-making, software maintainability, and system adoption rates. I even see, in practice, a level of incoherence between the agile concepts of “embracing change” and “barely sufficient documentation”, as the latter often proves to be a hindrance to future change, as people struggle to remember, or are no longer available to share, undocumented implementation details, and the reasons behind them.
Would you agree with the statement that the ability to write quality requirements and system documentation is not going away in an agile world?