Wednesday, February 19, 2014

The Ideal Relationship

The Great Rift Valley
By User:Doron - Own work,
CC BY-SA 3.0,
This post describes the rationale for a short answer on the LinkedIn discussion called What is the ideal relationship for PM and BA? which was itself inspired by an article called Top 10 Business Analysis Trends in 2014, by ESI International. I noted that ESI predicts increasing cooperation, better differentiation, and more hybrid BA and PM roles. I asked:
  • What kind of BA/PM relationship is best (in your experience)?
  • What was the context for that relationship?
After a few days absence from the thread, I was asked for my 'final analysis'. My answer is below, followed by the rationale for that answer.

What is the ideal relationship for PM and BA?

An ideal relationship between business analysis and project management includes collaboration during a change (if the change is being managed as a project). It also includes the change team being guided by the portfolio team (the folks responsible for deciding to initiate the change (often using a business case).

This relationship has at least two parts because business analysis is a discipline practiced wherever a business might consider or control a change, while project management is a discipline practiced in projects.


It seems that the discussion on LinkedIn and in other forums is hampered by a framing error: we keep taking about business analysis in terms of projects.

Business Analysis isn't done in a project, or before a project, or after a project, or under, or over, or to the right or left of a project. BA tasks are entirely independent of projects. Business Analysis consists of a set of tasks that are performed in a business.

This means that any change will not have 'a business analyst' and discussion of 'the business analyst' binds our thinking, actions, and reactions. These tasks are performed by people in a business to
  • evaluate a potential change.
  • evaluate an actual change.
  • control for the risks of misalignment during a change.
In some cases these tasks are performed taking a view
  • from inside the change, looking out to the context for the change.
  • from outside the change, looking in from the context
  • from the boundary of the change, looking to the into the change and the context at the same time.
Sometimes the business is making a change, and controlling that change (through a project, continuous improvement, or some other approach). Some business analysis tasks are most often performed in this context.

Sometimes the business is considering a change (estimating potential benefits and investments, measuring actual outcomes and costs). Some business analysis tasks are most often performed in this context.

These tasks are performed by many people. Some identify as Business Analysts, and some do not. Some understand that they are performing these tasks, and some do not. A few perform all the tasks, but most do not. If business analysis tasks are performed poorly in any context the business is likely to suffer from actions that are not aligned to purpose, and decisions that are ill informed.

Business Analysis tasks produce necessary information for well informed decision to initiate, decline, continue, or stop a change. If BA tasks are not performed or performed poorly the decision will be uninformed. Uniformed decisions are less likely to be good decisions (for values of 'good' that include aligned to purpose, likely to succeed as intended, etc.).

Business Analysis tasks do not usually provide sufficient information for well informed decision to initiate, decline, continue, or stop a change. Other tasks from other professions and disciplines are also necessary for 'well informed' to be true. Project Management tasks (when a business is running a project) produce necessary information for managing a project, but like business analysis outputs, this information is not sufficient.

Sunday, February 16, 2014

Julian's Practical Completeness Theorem

Completely incompletely complete.
Kurt Gödel (1906-1978) is
one of the most important
logicians ever - right up there
with Aristotle. My idea is
not in the same league
as Gödel's Completeness
Theorem, or indeed,
any of his work --
but I find him inspirational
so you get to see his picture.
(Image from wikipedia)
In the IIBA group on LinkedIn there is a discussion called "How do you know if your analysis is complete", started by Reggie LK Wong. A more general way to phrase Reggie's question might be "How can a person determine when an output is done?" There are a variety of good answers in the thread but no general, underlying principle to unify them -- so I'll propose one.

Julian's Practical Completeness Theorem

The output is complete enough
when it is useful enough.

This can't be simplified to "the output is complete when it is useful" because that kind of statement puts perfection over performance. This reflects a characteristic of business and biology: performance is determined by being successful enough, often enough. This is distinct from completeness in a logical or mathematical sense: that is determined by perfection. I call this 'performance over perfection' -- one of four Personal Principles that I attempt to adhere to in all things.

What is 'Useful'?

The "useful" part of "useful enough" is determined by asking a few basic BA questions:

1. Who will use the outputs of my work?
2. What will that person use the output for?

Each person using a requirements document could have a different purpose for that document. This means that 'complete enough' is likely to vary for each stakeholder. This is often reflected in the structure of the output, the specific details of the output, and the representation of the output (written, verbal, simulation, model, etc.). An "unmeasurable requirement"* probably isn't useful to the person attempting to create a test case, but a directional goal could be quite useful in a presentation to stakeholders.

What is 'Enough'?

Personal Principles
over perfection
evidence trumps
emotions motivate;
data doesn't
minus authority
equals scapegoat
The "enough" part of "useful enough" is based on the risk tolerance of the immediate stakeholder (the person using the output) and the larger team working to achieve some change. "Make a pretty logo" might be enough for a trusted graphic designer with a track record of success and the confidence to proceed. Another graphic designer could need much more detail to believe** that the risk of failure is low enough.

When techniques and templates and standards and reports and so on are based on these ideas they tend to be relatively simple and reasonably reliable. When these things are based on perfection over performance they tend to bloat out with useless information, useless details, and useless tape.***

The Practical Completeness Theorem In Practice

"Rules exist so you think before you break them."
- Terry Pratchett

For Change Agents, many rules are encoded in the templates and processes and standards of the change methodology being used. It takes a lot of effort to figure out 'useful enough', and when you repeatedly have the same stakeholders, needing the same information, it makes sense to 'hard-code' those factors into the work. This saves time and effort -- especially mental effort -- and in some cases it can dramatically improve performance.**** There is a cost of this structure, of course: a loss of flexibility.

This means Change Agents often run up against templates and processes and standards that 'don't make sense' or 'get in the way'. When this happens, take Pratchett's advice: think before you break the rule. When a template has a section you don't use, ask "who uses this information, and for what purpose?" If the answer is something like "In 1983 the folks running the punched-card input terminals needed to know it," perhaps it is time for a change to the template. Often the answer will be "Not me, and I don't know," which is not good a enough reason to break the rule. Ask around. Find out. Often, the answer is surprising, and in many cases it will lead to significant improvement opportunities. For example, you may discover that the information is needed by a stakeholder you never considered, and that it could be provided with less effort and in a more useful form.

*In quotes because it isn't a requirement unless it's measurable -- even if you can jam the words together grammatically. "Spantle a kivalot" and "colourless green ideas sleep furiously" are also grammatical nonsense.

**Evidence is usually preferred to belief, but not always. That's another personal principle: evidence trumps experience. The complete statement is "time permitting, evidence trumps reason which trumps experience."

***Of the red kind.

****Checklists for pilots and surgeons are examples.