30-60-90 day plan for business analysts
On this page
- Three downstream measures of a business analyst's work
- Days 1-30: Learn the business by mapping it
- Days 31-60: Own requirements for one change
- Days 61-90: Take a change through acceptance
- Mapping the current state properly
- What "on track" looks like
- A filled example
- Questions for the check-ins
- What the hiring manager owes the new business analyst
- Common mistakes
- Adapting the plan
- Questions people ask
A business analyst sits between the people who run a process and the people who change the systems behind it. Their output is mostly documents: process maps, requirements, user stories, acceptance criteria. That makes the role easy to fill with activity and hard to judge. A useful 30-60-90 day plan for business analysts judges those documents by what they cause downstream: whether developers build the right thing the first time and whether the users accept it.
This plan is written for the IT manager, product owner, or operations leader hiring a business analyst for internal systems or process change, such as an ERP, CRM or workflow project. If the role is mainly about queries and dashboards, use the 30-60-90 day plan for data analysts; if the role decides what a customer-facing product should do, the 30-60-90 day plan for product managers fits better. The general template is the 30-60-90 day plan template for new hires.
Three downstream measures of a business analyst's work
Agree these with the new analyst and the delivery team in week one. None of them needs a new tool; most teams can count them from the ticket system.
| Measure | How to count it | What it shows |
|---|---|---|
| Clarification rate | Questions developers or testers raise about a requirement after it is marked ready | Whether requirements are complete and unambiguous |
| Requirement-related defects | Defects found in testing or after release that trace to a missing, wrong or unclear requirement | Whether the analyst found the edge cases |
| Acceptance on first pass | Share of stories or features users accept in user acceptance testing without rework | Whether the analyst understood what the users actually needed |
Days 1-30: Learn the business by mapping it
Goals
- Get access to the ticket system, the requirements repository, the test environment and read access to the main business systems.
- Read the current backlog, the last two completed projects' requirements and any process documentation, and note how they are structured.
- Pick one real process in the area the analyst will support, for example order entry to invoice, and map its current state by sitting with the people who do each step.
- Check the map with those people and correct it, then compare it with the official documentation and list the differences.
- Meet the main stakeholders and the delivery team: developers, testers, the product owner or project manager.
- Take notes and draft summaries for at least two stakeholder meetings or workshops someone else leads.
Deliverables by day 30
- A validated current-state process map with pain points and workarounds marked.
- A short list of improvement ideas from the mapping, each with the business reason.
- A stakeholder list: who decides, who is consulted and who must be told about changes in the area.
Days 31-60: Own requirements for one change
Goals
- Take ownership of one change of moderate size, such as a new approval step, a report or an integration between two systems.
- Lead the requirements workshop for it with the hiring manager present.
- Write the requirements in the team's format, typically user stories with acceptance criteria, including the exception paths: what happens when data is missing, a user lacks permission or a step is skipped.
- Walk the delivery team through the requirements before work starts and log every question raised.
- Draft the future-state process map and agree it with the process owner.
Deliverables by day 60
- Requirements for the change signed off by the process owner and accepted as ready by the delivery team.
- A future-state process map.
- The first count of clarifications raised, with how each was resolved.
Days 61-90: Take a change through acceptance
Goals
- Write or review the user acceptance test scenarios from the acceptance criteria, including the exception paths.
- Run user acceptance testing with the business users, log defects and separate true defects from new requests.
- Get sign-off from the process owner, or a clear list of what blocks it.
- Prepare the change's handover material: updated process documentation and a short guide for users.
- Start requirements for the next item in the backlog without the hiring manager leading the workshop.
Deliverables by day 90
- One change accepted by users, or a dated plan to acceptance.
- The three downstream measures for that change, reviewed with the hiring manager.
- Requirements for a second change in progress, led independently.
Mapping the current state properly
The day-30 process map is the analyst's first real test, and it is easy to do badly. A map built in a conference room from what managers say should happen will look tidy and be wrong. Ask the new analyst to follow these rules:
- Watch the work, then ask. Sit with the person doing each step while they do it on real cases, not a demonstration. Ask what they do when something is missing or wrong.
- Record the workarounds. Spreadsheets kept on the side, email approvals, sticky notes and re-keying between systems are usually where the improvement is.
- Note volumes and times. How many cases a day, how long each step takes and how long work waits between steps. Waiting time is usually larger than working time.
- Check it back. Show the finished map to the people in it and ask what is wrong. If they correct nothing, they probably were not reading it closely.
What "on track" looks like
| Checkpoint | On track | Worth a direct conversation |
|---|---|---|
| Day 30 | Process map built from observation and corrected by the people who do the work; workarounds found | Map copied from old documentation; analyst has not sat with users |
| Day 60 | Requirements include exception paths; delivery team accepts them with few questions | Requirements describe only the happy path; developers come back with many basic questions |
| Day 90 | Users accept the change with little rework; new requests handled separately from defects | Acceptance testing turns into redesign; scope grows during testing |
A filled example
Business analyst: Omar Haddad (invented), business analyst supporting the finance team at a 600-person manufacturer during a procurement system rollout.
Day 30: Mapped purchase requisition to payment by sitting with buyers and accounts payable clerks. Found that orders under a certain value were routinely approved by email outside the system and entered later, which the official process did not mention.
Day 60: Owned requirements for in-system approval of low-value orders, including what happens when an approver is on leave, the cost center is closed or the order is split to avoid the threshold. Developers raised a handful of questions, mostly about delegation rules.
Day 90: Ran acceptance testing with four buyers and two approvers. Two defects traced to requirements, both on delegation; one new request was logged for the next release instead of added to scope. The process owner signed off two weeks after testing began.
Questions for the check-ins
- Where did the real process differ most from the documented one, and why?
- Which stakeholder is hardest to get a decision from?
- Which requirement are you least sure about, and what would settle it?
- What did a developer or tester ask that you wish you had covered?
What the hiring manager owes the new business analyst
- Access to users. A business analyst who cannot sit with the people doing the work can only rewrite old documents.
- A named process owner for each change who can make decisions and sign off.
- A clear format for requirements, or permission to propose one.
- Protection from becoming a note-taker for every meeting in the department.
Common mistakes
| Mistake | Result | Fix |
|---|---|---|
| Starting with the solution | Requirements that describe a screen, not the need | Map current state first, then ask what problem the change solves |
| Only the happy path | Defects in exception cases found after release | Require exception paths in every set of acceptance criteria |
| Treating new requests as defects | Scope grows during testing and the date slips | Log new requests separately for prioritization |
| Analyst as order-taker | Every stakeholder request goes straight into the backlog | Ask the analyst to challenge requests against the business reason |
Adapting the plan
- Agile teams: the analyst often works as or with the product owner; replace signed-off requirement documents with refined backlog items and acceptance criteria agreed in refinement.
- Large system implementations: the day-90 change may be a configuration workstream rather than a single feature; use the vendor's fit-gap sessions as the requirements workshop.
- Analysts who also do reporting: add a day-60 goal to define one report's metrics with the business owner.
If you are still hiring, the business analyst phone screen questions test for the listening and requirement skills this plan depends on.
Questions people ask
What is a good first deliverable for a new business analyst?
A current-state map of one real process, built by sitting with the people who do the work rather than from existing documentation, and checked back with them. It teaches the analyst the business, shows whether they listen well, and almost always uncovers workarounds the documentation does not mention.
How do you judge the quality of a business analyst's requirements?
By what happens downstream. Good requirements produce few clarifying questions from developers, test cases QA can write directly from the acceptance criteria, and few defects traced back to a missing or ambiguous requirement. Track those from the first piece of work the analyst owns.
How is a business analyst different from a data analyst?
A data analyst answers questions with data: queries, dashboards and analyses. A business analyst defines how a process or system should change: current and future process maps, requirements, user stories with acceptance criteria and acceptance testing. Some roles mix the two, so name the split in the job description and the plan.
Should a new business analyst lead stakeholder workshops in the first month?
Usually not alone. Have them take notes and draft the summary for a workshop someone else runs, then lead one with support in the second month. Running a workshop well depends on knowing the stakeholders, and that takes a few weeks to learn.