Achieve Internet: Role-Ready Business Analysts for Enterprise API and Platform Projects
How Business Analysis Canada placed role-ready business analysts on Achieve Internet's API portal, enterprise software and modernization projects.
- 6 business analysts in one dedicated, managed team
- 1 lead BA as Achieve's single point of contact
- 3 onboarding waves of two analysts in the first quarter
- ~18 months, with the team at six throughout
Project at a glance
- Client
Achieve Internet, a San Diego software development company that builds enterprise software, API developer portals and modernization projects on Apigee, Azure and custom platforms - Engagement model
Staff augmentation. A dedicated team of six business analysts was embedded in Achieve's delivery teams and worked on Achieve's live client projects under Achieve's project leadership. - Team
One lead business analyst, two API portal business analysts, two integration and platform business analysts, and one modernization business analyst - Delivery
Remote from Canada, with working hours overlapping US Pacific time for client workshops and team ceremonies - Duration
About 18 months. The team was built up in three waves of two analysts during the first quarter, in step with Achieve's pipeline. - Our role
Business Analysis Canada hired, onboarded and managed the six analysts. Achieve's project managers and technical leads directed day-to-day work. Our lead BA was Achieve's single point of contact for staffing, allocation and quality. - Scope
Requirements elicitation, functional specifications, acceptance criteria, data and integration mapping, delivery support and user acceptance testing support
The challenge
What problem was the client trying to solve?
Achieve's engineering team was strong, but client delivery was growing faster than its analyst capacity. Without enough BAs, requirements work fell to engineers and project managers, and builds started on scope that had not been validated.
- Too few BAs
Achieve had more concurrent client projects than its analysts could support, particularly when several discovery phases ran at the same time. - Engineers filling gaps
Engineers and project managers were filling the gaps by writing requirements themselves, which took time away from solution design and delivery. - Rework and disputes
Incomplete requirements led to rework, estimates that slipped, and disagreements with clients over what had been agreed. - Specialist work
The work was specialist. API portal projects need analysts who understand gateways, API credentials, OpenAPI specifications and developer onboarding. Modernization projects need analysts who can inventory legacy features, content and integrations. - Starting from scratch
Short-term contractors brought in project by project had to learn Achieve's process from scratch each time, and their knowledge of the client left with them. - On Achieve's terms
Any added analysts had to work as part of Achieve's team, to Achieve's methods and quality bar.
Dedicated team
Why a dedicated team rather than project-by-project contractors?
Achieve needed BA capacity that covered several specialisms and stayed with its clients from discovery through delivery. A managed team made that possible.
Specialisms under one roof
API portal, integration and modernization skills sat in the same team, so each project got the right analyst and specialists could support each other's projects when needed.
Continuity across phases
The analyst who ran discovery stayed involved through build and user acceptance testing, so clients did not have to explain their business twice.
Peaks absorbed inside the team
When several discovery phases started at once, analysts moved between projects rather than Achieve sourcing and onboarding new contractors.
Cover
Analysts were briefed on each other's projects, so absences did not stall refinement sessions or client sign-offs.
Peer review
Specifications and data mappings were checked by a second analyst before the lead BA's quality review.
One point of contact
Achieve worked with one lead BA on staffing, allocation and performance instead of managing six individual contractors.
Team structure
How was the team structured?
1 person
Lead business analyst
Focus
Team lead and Achieve's point of contact; quality review, allocation and onboarding; hands-on discovery on complex projects
Typical projects
Across all projects, leading discovery for the largest client engagements
2 people
API portal business analyst
Focus
Catalogs, documentation, developer onboarding, access and approval workflows, and gateway integration on Apigee and Azure
Typical projects
API developer portals
2 people
Integration and platform business analyst
Focus
Business rules, data mapping, roles and permissions, and connections to CRM, ERP, identity and content systems
Typical projects
Enterprise software, and integration work on portal and modernization projects
1 person
Modernization business analyst
Focus
Legacy inventories, keep, change or retire decisions, and migration and cutover requirements
Typical projects
Platform modernization, such as moves off Drupal 7
Our business analysis approach
How did we approach the engagement?
We set up the team as a managed service with defined roles, onboarding to Achieve's delivery model, and quality checks before any work reached Achieve.
- Understanding Achieve's delivery model
We reviewed Achieve's discovery approach, Agile delivery process, Jira workflows, specification templates and Definition of Ready and Done, so our analysts' work would slot straight into Achieve's process. - Team design
We sized the team from Achieve's mix of discovery and delivery work and defined a role profile for each position, listing the skills, platforms and seniority needed. - Matching and approval
We proposed analysts whose experience matched each role. Achieve interviewed and approved all six before they joined a client project. - Onboarding in three waves
The lead BA and one integration and platform BA started first, followed by the two API portal BAs, then the modernization BA and the second integration BA. Each analyst learned Achieve's methods, tools, templates and client conduct, received a project brief from Achieve's project manager, and joined their first client calls alongside Achieve's leads. - Team playbook
The lead BA kept a shared playbook of Achieve's templates, worked examples of specifications, data mapping and feature parity templates, and checklists, so all six analysts produced work in the same format. - Embedded delivery
Analysts ran or supported discovery workshops with Achieve's clients, elicited requirements, wrote specifications and acceptance criteria, and joined backlog refinement with Achieve's engineers to answer questions and clarify edge cases. - Validated scope before build
Specifications and acceptance criteria were reviewed and approved by the client, through Achieve, before development started. A story met Achieve's Definition of Ready only when it had agreed acceptance criteria. - Quality review
Each artifact was checked by a second analyst, then reviewed by the lead BA against an agreed checklist before it went to Achieve. The checklist covered completeness, testable acceptance criteria, consistency with earlier decisions and correct use of Achieve's templates. - Allocation planning
The lead BA and Achieve's delivery lead agreed assignments every week, and every two weeks they reviewed upcoming projects so analysts could be moved before a discovery phase started. - Handover
At the end of each assignment, analysts filed all documents in Achieve's repositories and briefed the project team, so knowledge stayed with Achieve.
Team flex
How did the team move between Achieve's projects?
The team stayed at six throughout, and analysts were reassigned as projects changed phase.
Several discovery phases at once
The lead BA and the integration and platform BAs split the discovery workshops, while the API portal BAs continued supporting projects already in build.
A project moving from discovery to build
The analyst who ran discovery stayed on part-time for refinement and user acceptance testing, and used the rest of their time on the next discovery.
A large API portal program
Both API portal BAs worked on it, and an integration and platform BA covered identity, SSO and back-office integration requirements.
A modernization with a large legacy estate
The modernization BA led the inventory and parity decisions, and an integration and platform BA mapped data migration and integrations.
Holidays and absence
An analyst already briefed on the project covered sessions and sign-offs, using handover notes updated every week.
Ways of working
How did the team fit into Achieve's routines?
Project ceremonies
Each analyst joined the stand-ups, refinement sessions, sprint reviews and client demos on their assigned projects.
Internal team sync
The six analysts met weekly to share progress and risks, and to reuse solutions from one project on another.
Monthly review with Achieve
Achieve's leadership and our lead BA reviewed quality, feedback from project managers and engineers, and the coming months' demand.
Replacing an analyst
If an analyst did not suit a role, we would propose a replacement within an agreed notice period and overlap the two for handover.
Project types
What did our analysts do on each type of project?
API developer portals on Apigee and Azure
What Achieve's client needed
A portal to publish APIs, govern access and onboard developers
What our analysts did
- Elicited requirements with API product managers and platform teams
- Mapped developer journeys
- Specified catalog, documentation, app registration, credential and approval workflows
- Documented gateway integration rules
Typical outputs
- Developer journey maps
- Functional specifications
- User stories with acceptance criteria
- Access and approval rules
- Gateway integration notes
Enterprise software and integrations
What Achieve's client needed
Web platforms connected to CRM, ERP, identity and content systems
What our analysts did
- Elicited business rules
- Defined integration requirements and data mappings
- Specified roles and permissions
- Documented edge cases and error handling
Typical outputs
- Functional specifications
- Source-to-target data mappings
- Integration specifications
- Role and permission matrices
Modernization
What Achieve's client needed
A move off legacy platforms reaching end of life, such as Drupal 7, without losing what users rely on
What our analysts did
- Inventoried existing features, content types, integrations and reports
- Ran keep, change or retire decisions with the client
- Defined migration rules and cutover acceptance criteria
Typical outputs
- Current-state inventory
- Feature parity matrix
- Content and data migration mapping
- Cutover acceptance criteria
Deliverables
What did Achieve's engineers get from the analysts?
Artifact
What it captured
How Achieve's engineers used it
Discovery summaries
Objectives, stakeholders, constraints and open questions
Shaping estimates and the solution approach
Current-state process and system maps
How work and data flow today, including integrations and pain points
Solution design
Functional specifications
Behaviour, business rules, roles and data for each feature
Building features to agreed scope
User stories with acceptance criteria
Implementation-ready backlog items
Sprint work and test cases
Data and integration mappings
Source-to-target fields, transformations and the team responsible for each data set
Integration and migration development
Feature parity matrices
Keep, change or retire decisions for each legacy feature
Modernization scope
Role and permission matrices
Who can see and do what
Access control development
UAT scenarios
Business acceptance tests written with the client
Client sign-off before release
Governance
How did we protect Achieve's client relationships?
These rules were written into the agreement before the first analyst started.
- Analysts worked as members of Achieve's project teams, under Achieve's project leadership, using Achieve's tools, templates and communication channels.
- Analysts never contracted with, quoted or sold to Achieve's clients, and a non-solicitation clause covered the engagement.
- Analysts signed NDAs with Achieve and, where required, with Achieve's clients. Access to client systems went only through Achieve-managed accounts.
- Analysts followed each client's security and access requirements, including any extra screening a client required.
- Client data was never stored on Business Analysis Canada systems.
- Day-to-day questions went to Achieve's project managers, and our lead BA handled staffing, allocation and performance.
Which BA techniques and tools did we use?
Techniques
- Stakeholder interviews and workshops
- Requirements elicitation
- Journey mapping
- BPMN process modelling
- Functional specification
- User stories with Given/When/Then acceptance criteria
- Data mapping
- Integration specification
- Role and permission modelling
- Feature parity analysis
- Definition of Ready
- Requirements traceability
- UAT planning
- Peer review
Tools
- Jira
- Confluence
- Miro
- Lucidchart
- Figma
- Postman
- Swagger Editor
Results
What were the results?
- 6 business analysts in one dedicated, managed team
- 1 lead BA as Achieve's single point of contact
- 3 onboarding waves of two analysts in the first quarter
- ~18 months, with the team at six throughout
A stable six-person BA team covering API portal, integration and modernization work.
- Achieve's engineers built against validated scope, with acceptance criteria agreed before sprints started.
- Less rework and fewer scope disputes, because clients had approved specifications and criteria before development.
- Engineers and project managers spent their time on solution design and delivery instead of writing requirements.
- Discovery peaks absorbed by moving analysts between projects, without sourcing new contractors.
- Continuity from discovery through build and user acceptance testing on each project.
- Consistent, peer-reviewed artifacts across projects, in Achieve's format.
“
Lessons learned
What can other software development firms learn from this engagement?
- Build the BA team around your project types. API portal, integration and modernization work each need different knowledge.
- Keep the discovery analyst involved through build. Continuity saves the client from repeating itself and protects the agreed scope.
- Validated scope costs less than rework. Get acceptance criteria agreed with the client before sprints start.
- Use the Definition of Ready as the agreement between the BA and engineering. No agreed criteria means the story is not ready.
- In modernization, decide what to keep, change or retire before migrating. Copying every legacy feature by default carries old problems forward.
Is requirements work falling to your engineers?
Talk to a senior business analyst about adding a managed BA team to your client projects, working inside your delivery process and to your quality bar.
Achieve Internet: Role-Ready Business Analysts for Enterprise API and Platform Projects
