The Crucial Role a Business Analysis Plays in a Technology Project

It is widely appreciated in the financial technology industry that business analysts can play a vital role in bridging the specification and implementation gap between client and technology provider. Clients, whether treasury or bank users, list requirements in the anticipation of meeting these ideals through a new solution; while the technology provider understands the needs and delivers solutions in accordance. Nonetheless, the whole exchange of requirements and solution between these two entities is not always straightforward.

The project scope and expectations from both sides can vary and escalate to a situation where either or both parties decide to end the project abruptly, or even prosecute each other in the courts. In most circumstances the misinterpretations are small, but erupt unexpectedly in the final stages of a project, which can lead to reworking and huge cost overruns.

A third party entity, fulfilling an independent role, can be the business analyst, who can seamlessly connect these two sides. The analyst should strive for clear client requirements and a flawless technology solution from the vendor. Business analysts possess domain knowledge in various financial products and have a holistic view of the programme by connecting multiple stakeholders.

Therefore, a business analyst is crucial for a banking technology project because they can add absolute value in terms of cost savings, quality assurance, timeline adherence and client satisfaction.

Five Areas Where Business Analysts Can Shine

1. Acquaintance with financial products and their lifecycle
A bank might be selling hundreds of products and their variants to clients, nevertheless all of them fall under certain product groups based on their nature and the manner they are processed. For each product group, a business analyst should be able to depict the lifecycle and associated events. This exercise will guide the business analyst to understand how many systems process the events end-to-end and how many teams/roles perform these. Once this foundation is established, it’s easier to relate any new requirement that originates.

In case of foreign exchange (FX) business, for example, the following particulars should be listed in detail:

  • Product groups: FX spot, FX forward, FX non-deliverable forward (NDF), FX options and FX swaps.
  • Lifecycle and events for each product group: FX spot – order, match exchange rate, revaluation, settle on nth day, amend the deal, cancel the deal, etc.
  • Application(s) that process each event.
  • Team(s) that perform each event.

In parallel, these products and events should be viewed from a broad perspective, such as credit risk, market risk and operational risk, finance, tax, fees, etc. This activity helps the business analyst develop a holistic view of products and their processing. It also gives the extra confidence of holding a map of a new territory while commencing expedition.

2. Exemplification of requirements
Clients may describe requirements that are not necessarily along the lines of what they really want. As some users might handle activities in a specific manner on a day-to-day basis, their description of a certain requirement may be skewed towards addressing issues related to only those tasks. A requirement that addresses current needs, as well as caters to needs that will arise in future, is seldom expressed.

A business analyst should question the purpose of requirement and perform exemplification that involves:

  • Inspecting the requirement from multiple dimensions and investigating every aspect of it, keeping its final usage by users in mind.
  • Providing realistic business scenarios as examples to minimise misinterpretation.

Some indicative project questions that should be asked, clarified, analysed and discussed are:

  • Why does the client need this functionality? How was this requirement identified? What is the overall business context?
  • What action of the system or user triggers the functionality expected out of this requirement?
  • What are the prerequisites to carry out this functionality?
  • What must happen immediately after this functionality is performed?
  • At what stage and in what form does this new functionality enter into the standard business process execution, such as input of an FX deal? Does it alter the existing process flow?
  • Is this requirement dependent or associated to other requirements?
  • What are the business rules for this functionality?
  • Which role in the bank, for example a treasury dealer, is the primary consumer of this functionality?
  • What are the channels through which the user acts on this functionality?
  • What changes are anticipated in the future? What sort of flexibility is envisaged?

Clarity around the requirements should be well established in analysis stage, which itself can dodge a faulty design. The cost of correcting problems in the final stages is enormous as compared to amending them in analysis phase.

3. Mediation between client and technology provider at critical junctures

At every stage, there should exist quality gates and sign-offs to determine that both entities have agreed on the deliverables in order to proceed to next stage. For example if the design has not been approved by the client, the technology provider cannot progress in building the solution.

During the course of the project, there would be many misinterpretations as to the scope and requirements of a project. Ideally, the project initiation, or scope, document should clearly define which aspects are in-scope and which are out-of-scope. However, as the different stages are passed and detailing sets in, certain features start to hover between in-scope and out-of-scope, or sometimes emerge as fresh requirements.

A business analyst should be equipped to sense such divergences and immediately bring the client and technology provider together to highlight the issue. This occasion provides opportunity for both entities to voice their view point, and a business analyst can facilitate the discussion for a mutually agreeable resolution. A business analyst should avoid the practice of assuming certain aspects based on one’s own experience and communicating inaccurate information, else such practice may yield difference of credibility between both the entities and ruin the image of the business analyst.

4. Test scenario preparation ahead of the design phase
In the majority of projects, test scenarios are prepared when the testing phase is about to commence. As an ideal practice, test scenarios should be prepared once requirements are documented and analysed.

The benefits of this practice are:

  • The technology provider can create an appropriate solution design, as it is aware of how the solution would later be tested.
  • During detail designing, test scenarios can provide pointers to any essential functionality that is not explicit in the requirements.
  • As the scenarios are prepared in the analysis phase itself, they can be agnostic to solution design, while methodically verifying the solution output.

Detailed test cases that branch out from test scenarios can be prepared post-design to be in sync with design-related modifications.

5. Solution validation with a view on its long-term usage and flexibility
Implementing new solution may alter the existing system functionality. Such outcomes are more often than not hidden and difficult to detect. A business analyst should review the design in detail and identify the potential impact on all connected components.

While validating a solution, a business analyst should also assess its long-term usage for the specific area and check how flexible the solution is in accommodating future changes. Wherever possible, hard coding of the logic should be avoided. New logic or formulae should be broken into multiple components and each of the components should be made configurable. This allows the client to re-configure the parameters and achieve desired customisation on their own, rather than depending on the technology provider.

For example, when a new fee is created under FX deal processing, some features such as fee amount, percentage slabs, fee waiver criteria, amortisation flag, and so forth can be retained as configurable parameters. A treasury or bank can re-define the fee as necessary by simply changing the parameters with no dependency on the technology provider.


These five features are principally associated with a business analyst role. Shortcomings in these areas can cause a project to derail beyond repair or lead to expensive corrective steps. Although a business analyst role is desired consistently across all phases of a technology project, higher impetus should be given on these five areas which are crucial for the project and have the potential to contribute continuing value.



Related reading