Yesterday I gave my talk at the Orlando IIBA chapter meetup. The updated presentation is here:
https://www.rpchurchill.com/presentations/zSimFrameForBA_Orlando/SimFrameForBA.html
This presentation was a bit different than previous ones because I’ve begun to add some new material dealing with what I call The Unified Theory of Business Analysis. I call it this because the surveys I’ve conducted (previous combined results are here) show that the contexts in which people perform business analysis can vary widely. This effort has been my attempt to get a handle on the practice and communicate my findings to an audience.
Specifically, I’m coming to the conclusion that the reason things look so different to different practitioners is because most people are only trying to solve a limited problem most of the time. My framework describes a process for conducting a full scope engagement from beginning to end, and most people — and certainly most business analysts — typically find themselves involved in a limited subset of such efforts.
Let’s look at a possible map of an entire (small) business or physical process.
Let’s also consider the process of completing an end-to-end process as a whole.
The first question we might ask is How can the 50 BA Techniques from the BaBOK be applied? We can imagine that some techniques are best applied to certain subparts of an operational process and during certain phases in time of a project process.
The next question to ask might be Where do the most commonly used software tools fit? Excel appears to be the most common tool BAs use to compile and manipulate information, while Jira and similar systems are used for communication and tracking. Visio, Word, Confluence, Outlook, and SharePoint are also used a lot by BAs.
Another source of confusion might be that a BA does not always participate in all phases of a project. He or she might be involved only in the requirements phase or the user testing phase or the discovery phase or even in a limited subset of phases. I’ve pointed out previously that all projects and efforts perform all of these phases implicitly, but some may be streamlined or omitted as the size of the effort scales down. The entire process takes place implicitly or explicitly even if any one participant or group only sees a small fraction of the activity.
A further consideration is whether the BA is looking at the function of a part of a process or the characteristics of what will perform that function. For example, the abstract part of a solution might involve calculations to be performed, messages to be passed into and out of a process component, and items to be stored and retrieved. The concrete part of a solution might involve determining the qualities the server must have to carry out the abstract functions with sufficient speed and reliability. That is, sometimes the BA will evaluate what something has to do and sometimes what something has to be.
The point is that organizations exist to provide value, and it takes many different kinds of people to make that happen. Business analysts are generally right in the middle of the action.
* * * * *
I also got a few more survey responses, the results of which are reported below.
List 5-8 steps you take during a typical project.
- planning
- elicitation
- requirements
- specification writing
- QA
- UAT
- identify the problem
- studying subject matter
- planning
- elicitation
- functional specification writing
- documentation
- identify stakeholders
- assess working approach (Waterfall, Agile, Hybrid)
- determine current state of requirements and maturity of project vision
- interview stakeholders
- write and validate requirements
- problem definition
- value definition
- decomposition
- dependency analysis
- solution assessment
- process mapping
- stakeholder interviews
- write use cases
- document requirements
- research
List some steps you took on a weird or non-standard project.
- A description of “weird” usually goes along with a particular person I am working with rather than a project. Some people like things done a certain way or they need things handed to them or their ego stroked. I accommodate all kinds of idiosyncrasies so that I can get the project done on time.
- data dictionary standardization
- document requirements after development work has begun
- For a client who was unable to clearly explain their business processes and where several SMEs had to be consulted to form the whole picture, I drew workflows to identify inputs/outputs, figure out where the gaps in our understanding existed, and identify the common paths and edge cases.
- investigate vendor-provided code for business process flows
- reverse code engineering
- review production incident logs
- team up with PM to develop a plan to steer the sponsor in the right diection
- track progress in PowerPoint because the sponsor insisted on it
- train the team how to read use case diagrams
Name three software tools you use most.
- Visio (5)
- Jira (4)
- Excel (3)
- Confluence (2)
- Google Docs (2)
- email (1)
- Gephi (dependency graphing) (1)
- Google Calendar (1)
- MS Teams (1)
- OneNote (1)
- Version One (1)
- Visual Studio Team Services (now Azure DevOps) (VSTS) (1)
- Word (1)
Name three non-software techniques you use most.
- critical questioning
- critical questioning (ask why fiive times), funnel questioning
- data analysis
- informal planning poker
- interviews
- meeting facilitation (prepare an agenda, define goals, manage time wisely, ensure notes are taken and action items documented)
- observation
- Post-It notes (Any time of planning or breaking down of a subject, I use different colored Post-Its, writing with a Sharpie, on the wall. This allows me to physically see an idea from any distance. I can also move and categorize at will. When done, take a picture.)
- process mapping
- relationship building
- requirements verification and validation
- stakeholder analysis
- stakeholder interviews
- visual modeling
- whiteboarding
- wireframe
Name the goals of a couple of different projects.
- automate a manual form with a workflow
- automate the process of return goods authorizations
- build out end user-owned applications into IT managed services
- develop a new process to audit projects in flight
- develop an interface between two systems
- implement data interface with two systems
- implement software for a new client
- implement vendor software with customizations
- integrate a new application with current systems/vendors
- merge multiple applications
- migrate to a new system
- redesign a system process to match current business needs
- update the e-commerce portion of a website to accept credit and debit cards
These findings fit in nicely with previously collected survey data.