Business Analysis books – a recommended reading list

by Nick de Voil 30. August 2017 16:01

When I deliver a training course, I always finish by inviting the delegates to get in touch in the future if they have any questions. If I never hear from them again, it makes me sad. So I was pleased to hear from Eleanor, a participant on a Business Analysis Practice course that I ran last year. She's decided it's time to build up her library of business analysis books, and is looking for recommendations.

Naturally my first reaction was to ask for more details about her requirements. She said “Not a reference book as I'll never read it. My biggest worry is something that's too dry.” I suspect that many people would say something along the same lines. I’ve noticed that the majority of good BAs, even if they have a high level of academic achievement, are very practical people who don’t have that much patience with theory.

That’s the first problem I have with answering the question on the basis of my own preferences – some of the books I find most indispensible are either reference books, or rather dry, or both. In the list below, I’ve tried to indicate where either of those is the case. I've also indicated where a book is what I'd describe as a textbook.

The second problem is that most of the books I find most useful aren’t business analysis books. I like books about user experience design, organisational theory, communication theory, sociology, psychology etc.

The list below, then, identifies some books that I can see on my shelves (or in piles on the floor...) at the moment, which are clearly related somehow to business analysis, and which I definitely learned something new and distinctive from. I’ve tried to keep it focused. It will definitely change and grow over time and I'll add comments about individual books.

There's a disproportionately low number of books about Agile in the list. That's because I find many of the key books about Agile to be incomplete or misleading.

  • Adzic, G. (2012). Impact Mapping: Making a big impact with software products and projects. Provoking Thoughts Limited.
  • Alexander, I. F., & Beus-Dukic, L. (2009). Discovering requirements: how to specify products and services. John Wiley & Sons.
  • Beyer, H., & Holtzblatt, K. (1997). Contextual design: defining customer-centered systems. Elsevier.
  • Bolman, L. G., & Deal, T. E. (2017). Reframing organizations: Artistry, choice, and leadership. John Wiley & Sons. High theory content!
  • Booch, G. (2005). The unified modeling language user guide. Pearson Education India. Dry! Reference book!
  • Bradley, G. (2016). Benefit Realisation Management: A practical guide to achieving benefits through change. CRC Press.
  • Cadle, J., Paul, D., & Turner, P. (2010). Business analysis techniques: 72 essential tools for success. BCS, The Chartered Institute for IT.
  • Checkland, P. (1981). Systems thinking, systems practice. High theory content!
  • Christensen, C., & Raynor, M. (2013). The innovator's solution: Creating and sustaining successful growth. Harvard Business Review Press.
  • Cockburn, A. (2000). Writing effective use cases, The crystal collection for software professionals. Addison-Wesley Professional Reading.
  • Cohn, M. (2005). Agile estimating and planning. Pearson Education.
  • Constantine, L. L., & Lockwood, L. A. (1999). Software for use: a practical guide to the models and methods of usage-centered design. Pearson Education.
  • Culmsee, P., & Awati, K. (2013). The Heretic's Guide to Best Practices: The Reality of Managing Complex Problems in Organisations. iUniverse Star.
  • Davies, R., & Davies, A. (2016). Value Management: Translating Aspirations into Performance. Routledge
  • De Wit, B., & Meyer, R. (2010). Strategy: Process, content, context. Cengage Learning EMEA.Textbook.
  • Gilb, T., & Finzi, S. (1988). Principles of software engineering management. Reading, MA: Addison-Wesley.
  • Goldsmith, R. F. (2004). Discovering real business requirements for software project success. Artech House.
  • Gottesdiener, E. (2012). Discover to deliver: agile product planning and analysis. EBG Consulting, Inc.
  • Guenther, M. (2012). Intersection: how enterprise design bridges the gap between business, technology, and people. Newnes.
  • Hackos, J. T., & Redish, J. (1998). User and task analysis for interface design.John Wiley.
  • Jackson, M. (1995). Requirements and specifications: a lexicon of software practice, principles and prejudices. Addison Wesley, Wokingham.
  • Johnson, G., Scholes, K., & Whittington, R. (2008). Exploring corporate strategy: text & cases. Pearson Education. Textbook.
  • Kalbach, J. (2016). Mapping experiences: A complete guide to creating value through journeys, blueprints, and diagrams. O'Reilly Media, Inc.
  • Kaner, S. (2014). Facilitator's guide to participatory decision-making. John Wiley & Sons.
  • Lauesen, S. (2002). Software requirements: styles and techniques. Pearson Education.Textbook.
  • Morgan, G., Gregory, F., & Roach, C. (1997). Images of organization.
  • Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2014). Value proposition design: How to create products and services customers want. John Wiley & Sons.
  • Osterwalder, A., & Pigneur, Y. (2010). Business model generation: a handbook for visionaries, game changers, and challengers. John Wiley & Sons.
  • Patton, J., & Economy, P. (2014). User story mapping: discover the whole story, build the right product. O'Reilly Media, Inc.
  • Paul, D., Cadle, J., Yeates, D. (Eds.) (2014). Business analysis. BCS.
  • Pullan, P., & Archer, J. (Eds.) (2013). Business Analysis and Leadership: Influencing Change. Kogan Page.
  • Robertson, S., & Robertson, J. (2012). Mastering the requirements process: Getting requirements right. Addison-wesley.
  • Rumbaugh, J., Jacobson, I., & Booch, G. (2004). Unified modeling language reference manual, the. Pearson Higher Education. Dry! Reference book!
  • Scholtes, P. (1997). The leader's handbook: Making things happen, getting things done. McGraw Hill Professional.
  • Schwarz, R. (2002). The skilled facilitator: A comprehensive resource for consultants, facilitators, managers, trainers, and coaches. John Wiley & Sons.
  • Senge, P. M. (2006). The fifth discipline: The art and practice of the learning organization. Broadway Business.
  • Silver, B., & Richard, B. (2009). BPMN method and style. Aptos: Cody-Cassidy Press. Reference book!
  • Slack, N., Chambers, S., & Johnston, R. (2010). Operations management. Pearson education.Textbook.
  • Stickdorn, M., Schneider, J., Andrews, K., & Lawrence, A. (2011). This is service design thinking: Basics, tools, cases. Hoboken, NJ: Wiley.
  • Ulwick, A. W. (2005). What customers want: Using outcome-driven innovation to create breakthrough products and services. McGraw-Hill Companies.
  • Ward, J., & Daniel, E. (2006). Benefits management: Delivering value from IS & IT investments. Chichester: John Wiley & Sons.


Jobs To Be Done

by Nick de Voil 5. January 2017 18:12

I've been reading Alan Klement's book "When Coffee and Kale Compete" about Jobs To Be Done (JTBD).  You can download it for free at .

In my opinion, JTBD is a really helpful theory and it goes some way towards relieving some of the problems I feel are inherent both in standard UX-style and also traditional BA-style analysis of people's needs and motivations. I think it will help us to come up with a better synthesis of the two. There's a lot of wisdom in there.  For example, Klement points out what's wrong with longitudinal studies (but also clarifies when he thinks they're appropriate) and and also (one of my pet hates) the Five Whys. And this on personas was music to my ears:

Personas include data such as race, age, and gender; however, these data represent only the natural, common variation among the people who use the product. But common variation doesn't help you understand... For example, a persona may describe a customer who likes to use the product on weekends. Now, is that important to the design, or is it a distraction? Is it real, or was it fabricated to "bring the user to life"? How many customers said they use it on weekends? One? Ten? One hundred? When invalid data are co mingled with valid data, how can you tell the difference? Personas do not distinguish variation due to either common or special causes. The layman who does not understand statistics will believe any variation within a system is due to special cause.

Have a read and tell me what you think.

Interaction in a Social Context

by Nick de Voil 3. May 2012 20:15
I've been interested for some time in how usability can be extended into, and integrated with, the field of enterprise systems design - not just in terms of the surface details of user interface, but also  at a deeper level of what Ronald Stamper calls "organisational semiotics", trying to get away from the Model Human Processor and taking into account things like social psychology, social anthropology, cultural analysis and discourse analysis.

The latest edition of Interfaces magazine has an intriguing article called Enterprise Usability Architecture, which talks about integrating usability with enterprise architecture. The interesting part comes at the end, where it says that "social models of HCI fill a gap that exists in both disciplines". It refers to the "Model of Interaction in a Social Context (MISC)".

This aroused my curiosity. I had never heard of MISC, and nor had Google, but eventually I found it in the PhD thesis of one of the article's authors, Sarah McDaid: "A model for human-computer interaction based on human-human communication in a social context".

MISC is an ambitious model identifying seven "layers" of the human-to-human communication process: task, presentation, session, control, cognition, effector and physical. Without going into all their meanings here, suffice it to say that this scheme is very helpful in showing some of the things that are often left out of consideration, both in ineffective person-to-person communication, and in traditional systems design. MISC then goes on to identify elements for consideration at each level. Some of these are familiar - for example, the Task level includes consideration of Goals, Sub-tasks etc. But others are less so. At the Presentation level, Roles, Relationships, Responsibilities, Social Rules and Social Norms are considered. The Session and Control levels deal with conversation structure.

Most interesting for me is the so-called Cognition layer. As McDaid writes, "This layer endeavours to take account of the personality and life-experiences of the participants and the impact that this has on their interpretation of the proceedings around them. These elements of the model are principally derived from work done in the field of social psychology." It includes elements like personality, emotional state, causal attribution, stereotyping and meta-perception.

The article in Interfaces does not specify how any of this is to be integrated into enterprise architecture, but I like McDaid's agenda and I do believe that this is a useful framework from which many good things might come.