A Simulationist's Framework
for Business Analysis
Part 15:
Why Use Business Analysts
and Their Techniques?
R.P. Churchill
CBAP, PMP, CSPO, CSM, A-CSDLean Six Sigma Black Belt
www.rpchurchill.com/presentations/TWSLseries/15_WhyUseBA www.rpchurchill.com | Portfolio | Presentations
30 Years of Simulation
Continuous simulation of the heating of a square billet and Discrete-Event simulation of a multi-phase process.
30 Years of Simulation
|
Industries
|
|
|
Questions About Business Analysis
Why should organizations use business analysis methodologies and techniques?
What does business analysis do that other practices don't?
What qualities should individual BAs have?
What do BAs actually do?
What benefits can BAs bring at different levels of experience?
Let's look at some answers.
What Does Business Analysis Do That Other Practices Don't?
Practice bodies sometimes try to pirate content from each other's practice areas.
Many people believe that "Agile solves everything," while I largely think Agile remains a scam.
The PMI jettisoned half of the material in the most recent PMBOK (370 pp in V7 vs. 760 pp in V6), on the theory that "Agile solves everything."
I thought the material in PMBOK volumes 4, 5, and 6 was excellent (I first earned my PMP in 2009), and remains valid in Agile contexts (even if many PM practices were originally developed for Waterfall).
Different practice bodies make their certification hurdles easier or harder for different reasons (education vs. cartelization).
What Does Business Analysis Do That Other Practices Don't? (continued)
I compare and contrast business analysis to many other practice areas in part 11 of this series. Even more practices could have been included (e.g., several types relating to architecture).
Project management is mostly about resources while business analysis is more about the details of identifying and developing solutions based on expressed and clarified needs. There is a certain amount of overlap as shown below, but I tend to think of business analysis as occurring within a project management wrapper.
Agile does NOT obviate all – or any – of the material in either the PMBOK or BABOK.
What Qualities Should Individual BAs Have?
BAs are learning and translating machines.
They should be intensely curious, both about people and processes (and any supporting technologies, usually including software).
They should have strong communication skills, especially including active listening and empathy.
They should be able to talk to people in any role at any level of an organization (both internal and external) – in language they understand.
They need to be able to use a wide range of collaboration tools for communication and expressive tools for documentation and developing shared understanding.
What Do BAs Actually Do?
Ensure that proper procedures are used to effectively carry engagements to good results (similar to how ScrumMasters are charged with employing Scrum techniques).
Ensure As-Is states are fully understood through detailed processes of discovery and data collection. This includes developing a fully shared understanding of the verbiage and data items involved in any effort.
Ensure expressed requirements (an abstract form of the To-Be state) are fully captured — and then effectively translated into properly contextualized action items that, when completed, will achieve the capabilities and results that are truly needed.
Ensure a(n appropriately) wide range of solution designs (a more concrete form of the To-Be state) are considered and helping to identify the criteria by which the preferred one will be chosen. The BA does not need to be a subject matter expert in all areas of this process, but should ensure that the right ones are involved and that the process is honest and thorough.
Ensure all design items are implemented, tested/accepted, and effectively deployed.
Ensure all items in all phases address the originally identified intended use(s) and requirements (through the discipline of traceability), so the problem is solved without excess effort, waste, or complexity.
Turning Expressed Requirements Into Something Usable
This means properly contextualized action items that, when completed, will achieve the capabilities and results that are truly needed.
I recently encountered a list of requirements similar to these:
- Automate scheduling and tracking of items
- Show item aging using different colors
- Use scanners to track items (implementing this feature seems particularly scary)
- Group items for shipping to minimize number of deliveries, considering both weight and volume
- Fill in holes of shipping between factory and distribution hub
- Communicate status to customers better
- Optimize routing of delivery vehicles
- Match customer account info with orders
- Make integrated data available to more users
- Create dashboards
- Use remote server capabilities (e.g., AWS)
What problems do you see? How can these be improved?
Turning Expressed Requirements Into Something Usable (continued)
Those requirements are perfectly legitimate, but they lack context.
They address considerations from the very general to the very specific.
"Automate" is an overly general concept.
If you give this list to implementors without further elaboration or clarification, what might you expect to get back? What are the chances it'll be what you really need?
What kind of implementors might you need? Can your existing ones help? How many will you need? Where should they be located? What skills do they need?
We need more details.
Here's how to get them.
Getting the Necessary Details
First, we need a clear and fairly complete understanding of the As-Is state. What's happening now, and where, and who is involved?
The best way to do this is by creating a process map (or similar artifact).
This gives everyone a shared understanding to work from, and accurately guides all participants to know what "holes" to fill in and how.
Discovery gives you the nouns and verbs, and that gives the context to do data collection, which gives you the adjectives and adverbs.
Without a clear, shared understanding of these things, you're mostly just guessing.
Getting the Necessary Details (continued)
Next, we need to identify the correct level of detail. Consider:
The listed requirements should be considered at different layers.
All details ultimately have be be addressed at the middle layer (conceptual/logical/application), and be implemented at the technology layer (physical/machine/data). Items at the top layer either derive from these or drive how these are divided up.
This provides the specific guidance for what implementors and tools will be needed. It also drives buy vs. build decisions, and judgments on when to ask for customizations.
Realizing the Desired Capabilities
Even with the giant leaps in clarity and shared situational awareness, we still need to provide specific instructions that implementors can use.
The correct technologies have to be acquired in terms of hardware, communications, security, data stores, programming languages, scanning devices, bar code or QR printers, and so on.
The correct instructions need to be written so each programmer, UI/UX designer, database engineer, hardware installer, and network administrator can implement the specifically defined capabilities.
All participants must be trained to use and maintain the system.
The system should be designed and documented so it is robust, understandable, modular, upgradeable, and maintainable. Connections must be maintained with the vendors and in-house implementation and support personnel.
None of This Happens By Accident
If you don't know where you're going, any road will get you there.
If you do know where you're going, you'll know exactly which roads to take and why, and can properly prepare for the journey.
Which method do you think will be cheaper and more likely to lead to success? What is the cost of failing?
Quoth Agent Smith in the first Matrix movie, "One of these lives has... a future. One of these... does not."
Which life do you want?
What Benefits Can BAs Bring At Different Levels of Experience?
People generally don't start out as BAs. This means they usually drift into it from other practices, and often have some experience.
A trained BA will have a reasonable sense of what to do and when. They might not be as flexible and adaptable as one with more experience.
More senior BAs will have seen more situations and know their industries and organizations better, and may have experience in other practice areas.
A really good BA will have experience in just about everything, but at that point they probably should be called business or enterprise architects.
BAs can come from almost any background, if they have the qualities described previously.
How Should BAs NOT Be Used?
They should not be relegated to a single phase (typically requirements), and then shuffled away to work on something else.
Instead, they should be involved in the full life cycle to aid project managers, product owners, senior SMEs, executives, and other responsible parties.
This presentation and other information can be found at my website:
E-mail: bob@rpchurchill.com
LinkedIn: linkedin.com/in/robertpchurchill