Category Archives: Thoughts

Opinion pieces, ideas I want to throw out for feedback, and stuff that is not deliberately inflammatory (like Rants are).

A Mind-Map View of the BA Decision Focus Argument

I use mind-maps in my day-to-day business analysis work, and I use them more often when exploring subjects I want to write about in a blog post.  So it should come as no surprise that I built a mind-map for my recent article The Role of the Business Analyst – It’s Time for a New Perspective.  And I have continued to expand on it and I continue to think about my perspective on the subject.

Given that, I figured some of you who are not as familiar with mind-maps might find it interesting to see the mind-map I have been working with (updated as of today) and maybe get some ideas how you might use them for your own needs (either professional or personal).  I am currently using the MindMaple ‘Lite’ software, but you can find links to it and several other mind-mapping packages on the Mind-Mapping Software page of the wiki.

Here is the mind-map.  Click the image to see a larger version.

A mind-map view of my argument for BA's to take a decision-focus.

As always, comments and feedback are appreciated.

The Role of the Business Analyst – It’s Time for a New Perspective

The conceptual role of the business analyst has evolved over the years.  Unfortunately, in my opinion it has not evolved enough in either the minds of most business analysts or in the minds of those who employ them.  For far too many the role of Business Analyst is still one that is focused only on project work and for most of those it is one that begins and ends with requirements.

But that concept of the role of the Business Analyst is one that I emphatically disagree with.  I believe that it inhibits the application of business analysis skills to situations where they could benefit the organization and which thus reduces the value the business analyst can provide to an organization.

While the IIBA has attempted to change this view with the new definition of what a Business Analyst does in BABOK v3.0, I think that definition also misunderstands and short-changes the role that the business analyst can play in an organization.  I believe that even the newest IIBA definition  continues to tie business analysis (as both a function and a job) too closely with the project environment.  And that this close conceptual tie to project work is holding back the profession and limiting its value.

So with this article I want to build on the concepts I started putting forward in April 2016 with my post “Have we mis-identified the core purpose and value proposition of Business Analysis?”  I want to put forward for discussion a new perspective of business analysis that I hope will both broaden and clarify the concept of what a business analyst does, and how it can provide value to organizations.

I want to do this not only because I believe it represents a needed change for the field, but because I feel that that the recent entry of the PMI into the business analysis arena, and especially their role definition for business analysis, threatens all of the progress made over the last decade in moving the concept of business analysis away from a requirements focus.  And that if those of us who practice business analysis can’t make a broader, clearer, and more robust definition of business analysis the default understanding of the field; we may soon be back to being thought of as just “those people who write software requirements”.

Continue reading

The Absent Brain Problem

Ron Ross recently had an excellent article on Modern Analyst titled “The Story of Al’s Spreadsheet and Absent Brains” in which he makes several very valuable points.  Those include:

  • “Around the globe there is extensive core operational business knowledge running businesses day-to-day that is highly inaccessible. Just putting your fingers on it, much less revising it, consumes vast amounts of vital resources. We live in a service provider’s dreamscape. It makes you wonder how brittle (read not agile) many companies’ operations really are today.”
  • “To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand.”
  • “Operational business knowledge can be either tacit or explicit (read ‘accessible’). The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’.”

The closing paragraph of his article is, “So make sure when you lose your Al, he doesn’t walk out the door with the day-to-day knowledge you need to run your business. Encode it as business rules!”

Of course, business rules are Ron’s normal answer to many problems (often validly).  But I think in this case he is drastically cutting short the type of information you need to make explicit.  It needs to be more than just business rules.  It needs to include:

  • terminology
  • business processes
  • reference and training guides
  • descriptive materials on what different units within the organization do and how they do it
  • what applications are used by the organization, for what purpose, and by whom
  • business rules
  • regulatory rules and interpretations
  • and a whole lot more

My test would be, “Can a new hire come into your organization and with nothing more than access to your knowledge repository figure out your work vocabulary, organization structure, what different units do, what tools are used, and how to do their job at a basic level?”

But having this information captured in an explicit form (preferably structured and searchable) isn’t just of value for business continuity and ensuring critical knowledge doesn’t walk out the door with departing employees; it’s of tremendous value for projects.  This information helps with scoping a project, acts as a continuously updated “current state” of the organization that can be leveraged, and allows critical subject matter experts to only have to devote project time for difficult-to-answer questions that require greater expertise.

In my experience (and yours may differ) the time spent by the project team gathering, synthesizing, and analyzing this information is among the most critical efforts of the project as well as being among the most likely to be cut short or skipped in an effort to “deliver something tangible” or “get going” or “show progress”.  Not doing this well or at all is in my experience the single greatest cause of scope creep, missed requirements, and missing stakeholders.

Unfortunately, creating and maintaining an accurate business knowledge repository requires organizational commitment and constant encouragement and support from management.  It can’t be done as a project, or an initiative, or any other temporary activity.  It has to become a constant act that is integrated into the entire organizations day-to-day activities.  It requires a commitment of time and effort from ALL employee’s.  And that is why it is so hard to do even an initial attempt, let alone keep it up.

But if you want to improve your projects; as well as your training, onboarding, and many other activities; keep Ron’s article in mind.  Just make sure you look at capturing more than just business rules. 

Agree.  Disagree.  Or have thoughts of your own to share?  Please comment!


© 2016 by David Olson

Have we mis-identified the core purpose and value proposition of Business Analysis?

I have recently found myself wondering if we have fundamentally mis-identified the core value proposition of business analysis, or if my view of the issue is skewed by past experience?  So I thought I would lay out my thoughts and see what others have to say.

First, let’s look at the IIBA definition of business analysis from the BABOK v3:

Business Analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.“[emphasis mine] [1]

And while we’re at it, let’s check the PMI definition from their recent Business Analysis Practice Guide:

In short, business analysis is the set of activities performed to identify business needs and recommend relevant solutions; and to elicit, document, and manage requirements.[2]

Since the PMI definition is virtually identical other than tacking on an explicit function around requirements, let’s use the IIBA definition from here on.

The first thing I take from the definitions is that both the IIBA and PMI seem to identify the core purpose of Business Analysis as being the practice of defining needs and recommending solutions.

But what is the core value proposition of Business Analysis?

Continue reading

Why I Chose Not to Renew My IIBA Membership

I had a call this morning from the IIBA to confirm whether I had received their emails reminding me that my membership had expired (yes) and whether I had deliberately not renewed (also yes).  I was at work and didn’t really have time to chat, so when they asked why I was choosing not to renew I gave a few quick responses and had to end the call. But I wanted to explain my logic in more detail here so that:

  1. I could see if anyone else out there has the same issues I do or can provide good reasons why I am wrong
  2. I could provide a fuller explanation in case anyone from the IIBA actually cares and is willing to consider changes
  3. In hopes of changing the minds of some people so that they too stop being IIBA members

This isn’t going to be short, but I’m going to try and keep my discussion of each issue relatively brief if I can. Please read on if you are interested.

So here are my major concerns with the IIBA:

Continue reading

How do you decompose your analysis?

I was reminded today of a discussion that a co-worker and I were having a while back with some Business Analysts and Project Managers who worked in other Project Management groups within our company (we have several).

We were discussing the ways our different groups approached basic project documentation such as Project Charters, Business Cases, and various Requirements documents; the various “levels” of information that the documents contained; and what those “levels” were called.

It soon became obvious that the different groups didn’t always decompose their project and analysis efforts using the same terms and “levels”.

Rather than trying to explain that concept more, I’ll instead demonstrate how I prefer to decompose a project and analysis effort so that you can actually see what I mean.

Continue reading

Learning the Stakeholders Language with Concept Maps and Glossaries

Perhaps the single most important thing a business analyst can do when they start working on an initiative (whether it be a project, process, or problem analysis) is to learn the language of the stakeholder(s) they will be working with.

Learning the language of your stakeholder(s) should be among the very first tasks you undertake as a business analyst. Indeed, in my opinion, it is the very foundation of EVERY other activity a business analyst undertakes with that stakeholder.

  • It is difficult to understand the business problem(s) you are trying to solve if you do not understand the subtleties of the language the stakeholder is speaking. Even common terms used within the larger organization can have subtly different meanings to your stakeholder that are important for you to know.
  • When working with multiple stakeholders, you cannot communicate optimally with them if you do not do so in language that they understand at the most complete level.
  • When working with multiple stakeholders, you cannot identify potential differences in stakeholder needs if you do not understand the exact language each stakeholder is speaking,
  • You cannot most effectively plan to elicit information if you do not know the meanings and relationships of the concepts the stakeholders use.
  • And you cannot fully understand the information you elicit from stakeholders if you do not understand the full meaning of what they communicate.

Continue reading

Do We Really Need Use Case Diagrams?

I’ve never been a fan of Use Case Diagrams.  I always thought they were an example of forcing information into diagram form that is better captured in a simpler structure, just because someone thinks diagrams are always easier to understand.  Or because the folks behind UML thought they had to have a diagram for every possible need, no matter that putting some information in diagram form actually makes some things harder to understand.

For systems with lots of functionality and dependent use cases, a Use Case Diagram can be practically un-usable.  Especially once you start having a lot of <<Extends>> and <<Includes>> in the diagram.  Luckily, most of the Use Case Diagrams I have seen don’t have many actual use cases in them, and have few or no <<Extends>> or <<Includes>>.  For the simple systems, a Use Case Diagram isn’t that bad.

But in the end, I think they are a bit of overkill when you balance the usefulness of the results versus the amount of effort.  You need diagramming software of some sort at a minimum, and I think there are simpler options.

Take the Use Case Diagram below, which comes from the Use Case Diagram page in this site’s wiki:
Continue reading

We are not Business Analysts

Have you ever struggled to explain to someone what you do?  Not just to that distant cousin at the family Christmas party, or the random person you are chatting with in line at Starbucks; but people who actually work within your organization?  Or even worse, the senior people who are going to be taking part in your project and who have no idea what a Business Analyst does?

Have you mumbled something about projects, processes, and software?  Maybe mentioned requirements elicitation, analysis, and documentation?  The problem isn’t that you don’t know your job, the problem is that your job title is wrong.  We are not business analyst’s.

Continue reading

Waterfall, Waterfall, Where for art thou Waterfall?

I’ve often had issues with the way the “Waterfall” development methodology is portrayed by the rabid (or not so rabid) agile proponents (or “Agilista’s” as I sometimes call them).  The way it’s described has never matched the way it’s practiced at my employer, or where any other BA I have spoken to has worked.  That’s not to say that some places don’t practice it that way, but that is not the fault of the methodology; any more than the frequent complaints that businesses who adopt “agile” and fail “aren’t doing it right”.

A while back I came across a couple of blog posts that triggered my research into the Waterfall method, and I wanted to pass them both on.  They are:

Rather than write a Rant about it, I decided to write up a wiki page that tries to just cover the information without too much opinion creeping in.  I have never gotten around to adding some of the final details on Waterfall variants, but the full history and mis-perceptions of “Waterfall” are covered I think.  Give it a look if you are interested.