The role of a Business Analyst (BA) is one of detailed analysis and clear communication. It involves identifying assumptions, translating software jargon for the intended audience, and identifying misunderstandings as early in a project as possible.
Most of my professional life as a BA has been spent working on internal projects. Since moving to Dispatch, I’ve seen the consultant side of the equation, and I can tell you that consultants want the same outcomes as the client:
- The project gets done on time.
- The client is happy with the outcome.
- The project stays within budget.
For a BA, these all depend on lowering the risk of engagement, meaning that everyone understands the expected outcome. The thing that struck me the most when I began working as part of a consulting team is how few customers bring formal requirements to the table. Usually, we get a Statement of Work, written at a very high level, and often signed by someone on the client’s side who is not part of the project team. This means that we have to move quickly to accurately define what the outcome will be, informed not only by discovery, but our knowledge of the systems in scope, and our experience with other customers with similar integrations.
One of the unique elements of integration projects is that the discovery process is very multi-dimensional, which necessitates a very strong Business Analyst who works with a System Architect and Project Manager to facilitate and document the outcomes of this process.
- If one or more of the applications to be integrated is new to the client, part of discovery is for the client to learn how the application(s) work, how that differs from their existing systems, and whether their current processes should change to accommodate the new systems.
- Integration projects typically involve different functional teams in the organization, so sometimes these projects create “a-ha” moments between these teams as they learn what happens upstream and downstream from the work they do.
- Workflow automation projects that span systems and functions will result in changes in day-to-day jobs. Less manual work, data entry, data validation etc. Client teams need to explore what the “art of the possible” is to streamline business processes and need to understand exactly what that will mean in each function.
- While it can be straightforward to automate a “standard” workflow, there are often many exceptional use-cases and scenarios to consider. The BA must help the client fully understand what should happen in each of these scenarios so that the automation doesn’t fail.
- The BA needs to help the client navigate between a wish list of automation requirements and a pragmatic specification that takes into account project budget and system complexity. It may be technically possible to automate all use-cases and scenarios, but pragmatically it likely doesn’t make sense to design an automation for a non-critical event that seldom occurs.
- Finally, the BA is a translator between business requirements and technical specifications. The outcome of discovery needs to be a clearly documented and unambiguous set of requirements that developers can use to build the integration.
Based on our experience with past projects, we can tailor discovery to identify any complexities quickly. For instance, in a Workday (HRIS) to Greenhouse (applicant tracking system) integration, we would ask about the current and desired approach to handle the recruiting, hiring and onboarding of contract workers. We’ll work through questions about which application should be the source of truth when a job is closed, whether the integration should automate the “hire” Business Process, whether a “hire” in Workday should result in a user being provisioned in Greenhouse, how re-hired employees will be identified, etc. Your experience and library of documentation from past projects are invaluable assets to ensure the full spectrum of potential use-cases is fully explored. Ultimately, a robust Business Analyst process will accelerate the documentation sign-off process, give confidence to the client team, and help avoid last-minute surprises when the integration moves to production. Explore our other blog, for twelve questions to consider when defining requirements for a data integration project.
As any BA can tell you, some of the issues with getting a document signed off are it may not be read carefully enough, or the right audience may not read it. While it’s important to be flexible during the life of a project, the more that can be done to reduce surprises, the better; so you want your documentation to be as close to representing the final state of the project as early as possible. It’s vital to write a list of tests and expected outcomes and deliver these to the customer as soon as possible.
Many BA’s may find that last point to seem backwards. After all, it is ultimately the customer who knows their business processes and what they want from the vendor. Saying that the vendor should write the test cases might sound like saying that the students should draft exam questions. But the point isn’t that the vendor defines what “success” looks like, the point is to show the vendor’s understanding of what the use cases are, and the expected outcomes. The consultants also have the benefit of having worked with the applications and workflow automation solutions with other clients, so they have insight regarding system limitations or potential unintended consequences of a given approach and how to design a test suite to detect and eliminate these issues. Documenting deliverables with this approach can help the client identify any misunderstandings before development has gone too far down the wrong path. Of course, the client is free to write their own test cases; the important thing is that it makes the deliverables clear.
The other advantage of providing the client with test cases is that the format of the document makes it clear what kind of information the developer needs to be able to address any bugs. A defect tracker can have headings like “reference number,” “screengrab,” etc. There are as many ways of tracking test results as there are clients, but whether they use Jira or Excel, at least they are aware of what will help the developer get to the bottom of issues most quickly.
Providing test cases also forces the customer to think about the resources that they will need to complete testing. The most successful projects include client representatives that are functional experts in each of the systems being integrated, not just the managers of the departments involved.
Now that we are confident that the scope is established, the developer can continue the build with confidence. Meanwhile, the BA can begin drafting support documentation such as the Operations Manual and the FMEA. These will have to be reviewed by the developer, but having the drafts shortens the project timeline and reduces demands on the developer when the clients need a fast turnaround, such as during User Acceptance Testing.
By promoting an understanding of what “success” looks like early on, and freeing up the developer’s time, the BA helps to smooth the path to go-live.
Contact us to learn more about our products and services.
Dispatch Integration is a software development and professional services firm that develops, delivers, and manages advanced data integration and workflow automation solutions. We exist to help organizations effectively deal with the complex and ever-changing need to integrate data and optimize end to end workflows between cloud-based, mission-critical applications.
Read More from Dispatch Integration:
DIVE IN – Integration Project Management: Part 1
What’s an FMEA, and Why We Use It
Automating Employee Discount Card Management
Data Integration: Life in Production
Ben Lemire is an experienced Business Analyst and Data Integration Specialist. He specializes in data migration, developing test plans, executing and leading UAT and writing operation manuals, and integration architecture documents.