A Simulationist’s Framework for Business Analysis: Round Two

On Tuesday I gave this talk again, this time for the IIBA’s Metro DC Chapter. Here are the results from the updated survey. The results from the first go-round are here.

List at least five steps you take during a typical business analysis effort.

Everyone uses slightly different language and definitely different steps, but most of the items listed are standard techniques or activities described in the BABOK. Remember that these are things that actual practitioners report doing, and that there no wrong answers.

Some of the BAs report steps through an entire engagement from beginning to end. Other BAs report steps only to a certain point, for example from kickoff to handoff to the developers. Some start off trying to identify requirements and some end there. Some talk about gathering data and some don’t. Some talk about solutions and some don’t.

What do you take away from these descriptions?

  1. identify stakeholders / Stakeholder Analysis
  2. identify business objectives / goals
  3. identify use cases
  4. specify requirements
  5. interview Stakeholders
  1. project planning
  2. user group sessions
  3. individual meetings
  4. define business objectives
  5. define project scope
  6. prototype / wireframes
  1. identify audience / stakeholders
  2. identify purpose and scope
  3. develop plan
  4. define problem
  5. identify objective
  6. analyze problems / identify alternative solutions
  7. determine solution to go with
  8. design solution
  9. test solution
  1. gathering requirements
  2. assess stakeholder priorities
  3. data pull
  4. data scrub
  5. data analysis
  6. create summary presentation
  1. define objective
  2. research available resources
  3. define a solution
  4. gather its requirements
  5. define requirements
  6. validate and verify requirements
  7. work with developers
  8. coordinate building the solutions
  1. requirements elicitation
  2. requirements analysis
  3. get consensus
  4. organizational architecture assessment
  5. plan BA activities
  6. assist UAT
  7. requirements management
  8. define problem to be solved
  1. understand the business need of the request
  2. understand why the need is important – what is the benefit/value?
  3. identify the stakeholders affected by the request
  4. identify system and process impacts of the change (complexity of the change)
  5. understand the cost of the change
  6. prioritize the request in relation to other requests/needs
  7. elicit business requirements
  8. obtain signoff on business requests / validate requests
  1. understanding requirements
  2. writing user stories
  3. participating in Scrums
  4. testing stories
  1. research
  2. requirements meetings/elicitation
  3. document requirements
  4. requirements approvals
  5. estimation with developers
  6. consult with developers
  7. oversee UAT
  8. oversee business transition
  1. brainstorming
  2. interview project owner(s)
  3. understand current state
  4. understand need / desired state
  5. simulate / shadow
  6. inquire about effort required from technical team
  1. scope, issue determination, planning
  2. define issues
  3. define assumptions
  4. planning
  5. communication
  6. analysis – business and data modeling
  1. gather data
  2. sort
  3. define
  4. organize
  5. examples, good and bad
  1. document analysis
  2. interviews
  3. workshops
  4. BRD walkthroughs
  5. item tracking
  1. ask questions
  2. gather data
  3. clean data
  4. run tests
  5. interpret results
  6. visualize results
  7. provide conclusions
  1. understand current state
  2. understand desired state
  3. gap analysis
  4. understand end user
  5. help customer update desired state/vision
  6. deliver prioritized value iteratively
  1. define goals and objectives
  2. model As-Is
  3. identify gaps/requirements
  4. model To-Be
  5. define business rules
  6. conduct impact analysis
  7. define scope
  8. identify solution / how
  1. interview project sponsor
  2. interview key stakeholders
  3. read relevant information about the issue
  4. form business plan
  5. communicate and get buy-in
  6. goals, objectives, and scope

List some steps you took in a weird or non-standard project.

It’s interesting to see what different people consider to be out of the ordinary. Over time they’ll find that there isn’t a single formula for doing things and that many engagements will need to be customized to a greater or lesser degree. This is especially true across different projects, companies, and industries.

I think it’s always a good idea for people involved in any phase of an analysis/modification process to be given some sort of overview of the entire effort. This allows people to see where they fit in and can build enthusiasm for participating in something that may have a meaningful impact on what they do. This can be done in kickoff and introduction meetings and by written descriptions that are distributed to or posted for the relevant individuals.

The most interesting “weird” item to me was the “use a game” entry. I’d love to hear more about that.

  • Steps:
    1. Why is there a problem? Is there a problem?
    2. What can change? How can I change it?
    3. How to change the process for lasting results
  • after initial interview, began prototyping and iterated through until agreed upon design
  • create mock-ups and gather requirements
  • describing resource needs to the customer so they better understand how much work actually needs to happen and that there isn’t enough staff
  • explained project structure to stakeholders
  • interview individuals rather than host meetings
  • observe people doing un-automated process
  • physically simulate each step of an operational process
  • simulation
  • statistical modeling
  • surveys
  • town halls
  • use a game
  • using a ruler to estimate level of effort to digitize paper contracts in filing cabinets gathered over 40 years

Name three software tools you use most.

The usual suspects show up at the top of the list, and indeed a lot of a BA’s work involves describing findings and tabulating results. There are a lot of tools for communicating, organizing, and sharing information, whether qualitative findings (nouns and verbs discovered during process mapping), quantitative findings (adjectives and adverbs compiled during data collection), graphics (maps, diagrams, charts), or project status (requirements, progress, participants, test results). A few heavy duty programming tools are listed. These seem more geared to efforts involving heavy data analysis, though Excel is surprisingly powerful in the hands of an experienced user, particularly one who also knows programming and error detection.

  • Excel (8)
  • Visio (7)
  • Word (7)
  • Jira (4)
  • Confluence (3)
  • SharePoint (3)
  • MS Outlook (2)
  • Adobe Reader (1)
  • all MS products (1)
  • Azure (1)
  • Basecamp (1)
  • Blueprint (1)
  • CRM (1)
  • database, spreadsheet, or requirement tool for managing requirements (1)
  • Doors (1)
  • Enterprise Architect (1)
  • illustration / design program for diagrams (1)
  • LucidChart (1)
  • MS Project (1)
  • MS Visual Studio (1)
  • PowerPoint (1)
  • Process 98 (1)
  • Python (1)
  • R (1)
  • requirements repositories, e.g., RRC, RTC (1)
  • Scrumhow (?) (1)
  • SQL (1)
  • Tableau (1)
  • Visible Analyst (1)

Name three non-software techniques you use most.

I was surprised that there was so little repetition here. Different forms of interviewing come up most and a couple of thoughts are expressed in different ways, but the question asked what non-software tools were used most. One might expect that people would do many of the same things, but it’s a question of how each individual looks at things from their own point of view. “Business process analysis,” for example, is a high-level, abstract concept, while other items are lower-level, detailed techniques. Again, all of these items are valid, this just illustrates how people think about doing these sorts of analyses differently, and why the BABOK is necessarily written in a general way.

  • active listening
  • business process analysis
  • calculator
  • communication
  • conflict resolution and team building
  • costing out the requests
  • data modeling
  • decomposition
  • develop scenarios
  • diagramming/modeling
  • facilitation
  • Five Whys
  • handwritten note-taking
  • hermeneutics / interpretation of text
  • impact analysis
  • individual meetings
  • initial mock-ups / sketches
  • interview end user
  • interview stakeholders
  • interview users
  • interviews
  • listening
  • organize
  • paper
  • pen and paper
  • process decomposition
  • process mapping
  • prototyping
  • requirements meetings
  • rewards (food, certificates)
  • Scrums
  • shadowing
  • surveys
  • swim lanes
  • taking notes
  • use paper models / process mapping
  • user group sessions
  • whiteboard workflows

Name the goals of a couple of different projects (e.g., automate a manual process, interface to a new client, redesign screens, etc.)

The most common goals listed were automation and improvement, which is to be expected. In fact, pretty much every item on the list represents a process improvement of some kind, which is pretty much the point of what business analysts do.

  • adhere to regulatory requirements
  • adjusting solution to accommodate the needs of a new/different user base
  • automate a manual login/password generation and dissemination to users
  • automate a manual process
  • automate a manual process, reduce time and staff to accomplish a standard organizational function
  • automate a paper-based contract digitization process
  • automate new process
  • clear bottlenecks
  • data change/update
  • data migration
  • enhance system performance
  • implement new software solution
  • improve a business process
  • improve system usability
  • improve user interface
  • include new feature on mobile application
  • increase revenue and market share
  • map geographical data
  • process data faster
  • provide business recommendations
  • reimplement solution using newer technology
  • “replat form” legacy system (?)
  • system integration
  • system integration / database syncing
  • update a feature on mobile app

I’m scheduled to give this presentation in Baltimore in a few weeks, and may have still more opportunities to do so. I’ll repeat and report new survey results after each occasion, and I’ll report the combined results as well.

I’d love to hear any observations you have on these findings and answer any questions you may have.

This entry was posted in Tools and methods and tagged , , , , , . Bookmark the permalink.

2 Responses to A Simulationist’s Framework for Business Analysis: Round Two

  1. LN says:

    Great article Bob.

    Can you have a theme that’s bit easier to read.

    • Thanks, LN. Coming from you that means a lot.

      I may update the blog theme when I get through a WordPress course I have in my queue, but it’s not the highest priority just at the moment. When it happens the goal will be to use the same headers, footers, and colors as the rest of the site.

Leave a Reply