A Simulationist’s Framework for Business Analysis: Combined Survey Results

These results are combined from versions of this talk given in Pittsburgh, DC, and Baltimore.

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

I would list the steps I take in conducting an analysis project as follows.

Project Planning
Intended Use (Identify or Receive Business Needs)
Assumptions, Capabilities, and Risks and Impacts
Conceptual Model (As-Is State)
Data Sources
      –Requirements (To-Be State: Abstract)
      –Functional (What it Does)
Non-Functional (What it Is, plus Maintenance and Governance)
Design (To-Be State: Detailed)
Implementation
Test
      –Operation and Usability (Verification)
      –Outputs (Validation)
Acceptance (Accreditation)
Project Closeout

As I point out in the presentation the knowledge in the BABOK and the ideas they contain map roughly to these steps, though they are necessarily a bit generalized. The audience members whose surveys I collected reported that they follow the same rough procedures, in whole or in part; they just tend to use different language in many cases.

1. Requirements Gathering
2. Initiation
3. Testing
4. QA
5. Feedback
6. User acceptance

1. Requirement Elicitation
2. UX Design
3. Software Design for Testability

1. Identify Business Goal
2. ID Stakeholders
3. Make sure necessary resources are available
4. Create Project Schedule
5. Conduct regular status meetings

1. Meet with requester to learn needs/wants
2. List details/wants/needs
3. Rough draft of Project/proposed solutions
4. Check in with requester on rough draft
5. Make edits/adjustments | test
6. Regularly schedule touch-point meeting
7. Requirement analysis/design | functional/non-functional
8. Determine stakeholders | user acceptance

1. List the stakeholders
2. Read through all documents available
3. Create list of questions
4. Meet regularly with the stakeholders
5. Meet with developers
6. Develop scenarios
7. Ensure stakeholders ensersy(?) requirements
8. other notes
• SMART PM milestones
• know players
• feedback
• analysis steps
• no standard

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

1. stakeholder analysis
2. requirements gathering
3. requirements analysis
4. requirements management – storage and updates
5. communication – requirements and meetings

1. analyze evidence
2. design application
3. develop prototype
4. implement product
5. evaluate product
6. train users
7. upgrade functionality

1. read material from previous similar projects
2. talk to sponsors
3. web search on topic
4. play with current system
5. ask questions
6. draw BPMs
7. write use cases

1. document current process
2. identify users
3. meet with users; interview
4. review current documentation
5. present proposed solution or iteration

1. meeting with stakeholders
2. outline scope
3. research
4. write requirements
5. meet and verify with developers
6. test in development and production
7. outreach and maintenance with stakeholders

1. As-In analysis (current state)
2. write lightweight business case
3. negotiate with stakeholders
4. write user stories
5. User Acceptance Testing
6. cry myself to sleep 🙂

1. initiation
2. elicitation
3. discussion
4. design / user stories / use cases
5. sign-off
6. sprints
7. testing / QA
8. user acceptance testing

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

I would classify these as specific activities that fall into place in the normal framework and are only listed as non-standard because the individuals reporting them hadn’t done them often enough to see that. I’ve done almost all of these things at one time or another. There is also the possibility that people listed these things as non-standard simply because they were asked to.

As the respondents were of many ages and levels of experience it makes me wonder how people come to be business analysts. It seems to me that most people transition to the practice from other functions, though I’ve met people who began their careers doing it. Certainly the IIBA is making allowances for training beginning professionals in the practice. I am somewhere in between. I began as an engineer and software developer who just happen to analyze systems using the same techniques. Most of the systems were fluid or thermodynamic systems but there was an interval where I worked for a company that did business process reengineering using a document imaging capability.

One other item that comes up in this list is the need to iron out problems with individuals and managers, which sometimes involves working around them. If there’s anything that’s more common than needing to iron out problems with people, I don’t know what it is. That comes up in every profession and every relationship. I can report that my ability to fulfill professional duties, like all others, has gotten easier as I’ve learned how to work with people more cooperatively, smoothly, and supportively.

• 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
• Adjustments in project resources
• 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
• Developers and I create requirements as desired
• documented non-value steps in a process new to me
• explained project structure to stakeholders
• guided solutioning
• identified handoffs between different contractors
• interview individuals rather than host meetings
• iterative development and delivery
• Made timeline promises to customers without stakeholder buy-in/signoff
• make excutive decisions withoutstakeholder back-and-forth
• observe people doing un-automated process
• personally evaluate how comitted mgt was to what they said they wanted
• phased delivery / subject areas
• physically simulate each step of an operational process
• Regular status reports to CEO
• simulation
• starting a project without getting agreed funding from various units
• statistical modeling
• surveys
• town halls
• Travel to affiliate sites to understand their processes
• use a game
• using a ruler to estimate level of effort to digitize paper contracts in filing cabinets gathered over 40 years
• work around manager who was afraid of change – had to continually demonstrate the product, ease of use, and savings
• Write requirements for what had been developed

Name three software tools you use most.

The frequency of reported tool use matches closely with my own experience. Excel is such a generalized and approachable tool that people tend to use it for almost everything. It’s no wonder BAs explicitly report using it more often than anything else. Word and PowerPoint are almost as ubiquitous and like SharePoint, Outlook, and similar tools they organize and enhance communication and mutual understanding. Jira and Confluence are used quite often to manage requirements and work products using a standard relational tool. They are used quite often are more and more shops adopt Agile methods in general and Scrum and its cousins in particular.

Specialized tools like SQL and R come up less often than I might have expected, but we’re working with a small sample size and there may be cases where audience members use it but not as often as other tools they did report. Several specialized development tools were listed, showing that there is an overlap between analysis and development skills.

• Excel (15)
• Word (11)
• Visio (8)
• Jira (7)
• Confluence (5)
• SharePoint (4)
• PowerPoint (3)
• MS Outlook (2)
• Notepad (2)
• SQL Server (2)
• Adobe Reader (1)
• all MS products (1)
• ARC / Knowledge Center(?) (Client Internal Tests) (1)
• Azure (1)
• Basecamp (1)
• Blueprint (1)
• CRM (1)
• database, spreadsheet, or requirement tool for managing requirements (1)
• Doors (1)
• Email (1)
• e-mail (1)
• Enbevu(?) (Mainframe) (1)
• Enterprise Architect (1)
• Google Docs (1)
• Google Drawings (1)
• illustration / design program for diagrams (1)
• LucidChart (1)
• MS Office (1)
• MS Project (1)
• MS Visual Studio (1)
• MS Word developer tools (1)
• NUnit (1)
• OneNote (1)
• Process 98 (1)
• Python (1)
• R (1)
• requirements repositories, e.g., RRC, RTC (1)
• RoboHelp (1)
• Scrumhow (?) (1)
• SnagIt (1)
• SQL (1)
• Tableau (1)
• Team Foundation Server (1)
• Visible Analyst (1)
• Visual Studio (MC) (1)

Name three non-software techniques you use most.

It’s a bit more difficult to group and count these. The ideas of interviewing and meeting come up more than anything else, though almost never in exactly the same language. Various forms of diagramming, modeling, and decomposition come up often as well, and those are tools I emphasize in my own practice and in the slides. It might make a fun group exercise to group these into categories, though I’m sure the results would not be surprising.

• communication (3)
• meetings (2)
• prototyping (2)
• Scrum Ceremonies (2)
• “play package” (1)
• 1-on-1 meetings to elicit requirements (1)
• active listening (1)
• analysis (1)
• analyze audience (1)
• apply knowledge of psychology to figure out how to approach the various personalities (1)
• business process analysis (1)
• calculator (1)
• conflict resolution and team building (1)
• costing out the requests (1)
• data modeling (1)
• decomposition (1)
• develop scenarios (1)
• diagramming/modeling (1)
• documentation (1)
• elicitation (1)
• expectation level setting (1)
• facilitiation (1)
• fishbone Diagram (1)
• five Whys (1)
• handwritten note-taking (1)
• hermeneutics / interpretation of text (1)
• impact analysis (1)
• individual meetings (1)
• initial mockups / sketches (1)
• interview end user (1)
• interview stakeholders (1)
• interview users (1)
• interviews (1)
• JAD sessions (Joint Application Development Sessions) (1)
• listening (1)
• lists (1)
• Notes (1)
• organize (1)
• paper (1)
• pen and paper (1)
• phone calls and fate-to-face meetings (1)
• process decomposition (1)
• process flow diagrams (1)
• process mapping (1)
• process Modeling (1)
• recognize what are objects (nouns) and actions (verbs) (1)
• requirements meetings (1)
• responsibility vs. collaboration using index cards (1)
• rewards (food, certificates) (1)
• shadowing (1)
• Spreadsheets (1)
• surveys (1)
• swim lanes (1)
• taking notes (1)
• test application (1)
• training needs analysis (1)
• use paper models / process mapping (1)
• user group sessions (1)
• user stories (1)
• whiteboard diagrams (1)
• whiteboard workflows (1)
• wireframing (1)
• workflows (1)

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

We unsurprising find our goals to be, roughly: automate, create, change, develop, improve, process, redesign/re-engineer, replace, simplify, update. Ha ha, it’s almost like we’re talking about business analysis and process improvement!

• 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 and ease reporting (new tool)
• automate new process
• automate the contract management process
• automation
• block or restore delivery service to areas affected by disasters
• clear bottlenecks
• create a “how-to” manual for training condo board members
• create a means to store and manage condo documentation
• create a reporting mechanism for healthcare enrollments
• data change/update
• data migration
• develop data warehouse
• develop effort tracking process
• develop new functionality
• document current inquiry management process
• 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
• maintain the MD Product Evaluation List (online)
• map geographical data
• move manual Excel reports online
• process data faster
• process HR data and store records
• provide business recommendations
• recover fuel-related cost fluctuations
• redesign
• reduce technical debt
• re-engineer per actual user requirements
• reimplement solution using newer technology
• replace current analysis tool with new one
• “replat form” legacy system (?)
• simplify returns for retailer and customer
• system integration
• system integration / database syncing
• update a feature on mobile app