Business Analysis Notes

Basics

What Business Analysts Actually Do: Lessons from a 2020 Survey

4 min read · Updated

In short In 2020 DataArt surveyed 328 practicing business analysts in Ukraine about how they elicit, specify, verify and manage requirements, and what goes wrong. The results are a useful reality check against the textbook view, and they point to a few habits worth building.

Based on: D. Gobov, I. Huchenko, State of Business Analysis in Ukraine 2020, DataArt, 2020.

On this page

All figures below come from that survey (Gobov and Huchenko, DataArt, 2020). They describe one country’s IT-heavy market at one point in time, based on self-reported answers. Treat them as indicative, not universal.

Key ideas#

Who answered#

  • 49% worked in outsourcing companies and 18% in product IT companies.
  • More than half worked in companies with 1,500 or more employees.
  • About a third had less than three years of analysis experience; about 16% had more than ten.
  • The largest industry was finance and banking, at about 25%.
  • 58.6% worked with agile approaches; only 14.8% with predictive ones (waterfall or RUP).
  • Only 7% held a CBAP certification.

Elicitation#

Interviews and document analysis were the most used elicitation techniques, followed by interface analysis, brainstorming, prototyping and business process analysis. Document analysis was more common in outsourcing; process analysis was more common in non-IT companies.

Specification and documentation#

  • User stories (79%) and use cases (65%) were the most popular specification techniques; only 13% used neither. Prototyping was used by 54%.
  • Functional requirements, business requirements and a glossary were documented most often.
  • Cost-benefit analysis (8%) and product success metrics (15%) were documented least often.
  • Among non-functional requirements, usability was recorded most often, then security and performance.
  • Half of respondents used company templates.

Verification#

Reviews with the development team (79%) and self-review (77%) were the top two verification approaches. Only 18% reported no problems with requirements quality. Completeness and atomicity (one requirement per statement) were the most troublesome quality characteristics.

Requirements management#

  • The top prioritization techniques were dependency analysis (49%), MoSCoW (45%) and effort vs. value (45%).
  • Only 11% did no traceability at all, but only 37% kept links between business requirements and solution requirements.
  • 78% kept documentation up to date.

How analysts felt about analysis on their projects#

Only 15% were dissatisfied with the state of business analysis on their project. Reasons for dissatisfaction: too little time for analysis (23%), no established approach in the company (20%) and problems working with key stakeholders (17%). Reasons for satisfaction: an established analysis process (56%) and high-quality requirements (35%).

Problems, causes and consequences#

  • Top problems: shifting goals, processes or requirements (43%) and incomplete or hidden requirements (41%).
  • Main causes: no communication with key stakeholders (70%), no clear product vision on the customer side (62%), and no agreed position among the customer’s stakeholders (43%).
  • Consequences: effort or budget overrun (59%), scope creep (58%) and wrong estimates (54%).

Competencies#

Measured against the BABOK® Guide’s underlying competencies, respondents found analytical thinking (55% easy, 11% hard), behavioral characteristics (65% / 14%) and communication skills (63% / 12%) easiest to develop. Interaction skills (40% / 28%) and business knowledge (42% / 20%) were the hardest. The main reasons were lack of practice (58%) and lack of mentoring (53%).

How to apply it#

These takeaways are interpretations of the findings, not conclusions stated by the survey authors.

  1. Fix stakeholder access first. The most cited cause of problems was missing communication with key stakeholders. Put named stakeholders, their availability and escalation paths into your plan before detailed elicitation starts.
  2. Write the vision down. Unclear customer vision was the second cause. A short vision and scope document agreed early gives you something to test shifting requests against.
  3. Check completeness and atomicity explicitly. Add both to your review checklist. Split compound statements; look for missing cases with techniques from Finding Missing Requirements.
  4. Trace business to solution requirements. Most teams trace something, but few link business goals to solution requirements. That link is what lets you cut scope safely when goals shift.
  5. Document success metrics and value. Cost-benefit and success metrics were the least documented items. Even a few lines of metrics and KPIs make later solution evaluation possible.
  6. Go beyond the team review. Reviews with developers and self-review dominate. Adding a short review with business stakeholders catches a different class of errors.
  7. Seek practice and mentoring for interaction skills. Respondents found these hardest and blamed lack of practice and mentors. Ask to facilitate, and ask a senior colleague to observe and give feedback.

Example#

The analyst at The Workshop, a fictional chain of 12 bike-repair workshops, uses the survey as a risk checklist at kick-off: Is the owner available weekly? Is the vision written? Does each user story trace to a business requirement? Are success measures (fewer status calls, fewer parts delays) agreed? Two answers are “no”, and both go into the project risk list.

Sources and further reading#

  • D. Gobov, I. Huchenko. State of Business Analysis in Ukraine 2020. DataArt, 2020.