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.