I tweaked my standard Business Analysis framework to accommodate specific activities for IT consulting engagements. Thoughts below are rooted from my consulting experience for a fintech company.

Consulting requires an approach that is slightly different from the usual implementation projects. The vendor is expected to come up with a comprehensive technical solution for a given business need. Unlike in implementation projects, building this solution is excluded.

To put it in analogy, consultants will only present the blueprint of your dream house. Implementors will build it for you.

Roles

The technical architect is the key resource person in every consulting engagement.

  • He recommends the whole system architecture, which includes system component designs, hardware and security considerations.
  • He presents the required skillset, projected implementation manpower and timeline based on available resources set by the client.

The business analyst is a valuable resource person to add, especially if the client plans to implement the solution.

  • She aligns the architect's technical recommendations with the business requirements.
  • She considers the expected user experience and implementation efforts in defining the functional specifications.

A business analyst in an implementation project can treat a system as a black box. She only considers what goes in and out of the box, not so much on its inner workings.

A business analyst in IT consulting has to incorporate the technical solution to her recommended business flows by dissecting the recommended system components. That's why IT consulting requires a more technical business analyst, or at least someone who has a working knowledge in software development.

Personally, I find consulting more challenging and fun. I have learned so much within a short amount of time. The framework that will be presented serves as my synthesis.

The Business Analysis Framework - General Purpose, System Implementation

The Business Analysis Framework - IT Consulting

Business analysis for IT consulting omits the delivery aspects of the BA framework. The role requires more thinking and ideating than shipping an output.

  • Eliciting requirements remains essential to understand the business context and collate available resources.
  • Analyzing requirements transforms requirements to a solution. This phase also understanding and refining the technical solution done by the technical architect.
  • Lastly, consultants are expected to communicate the working solution to the client.

Now, let's discuss the specific activities per phase.

Business Analysis Activities in IT Consulting

In terms of methodology, IT consulting focuses on the solutioning aspect of software development life cycle (SDLC), and thus heavy on analysis work.

In this diagram, you'll notice the following:

Expected Business Flows + System Architecture = Functional Specifications

The technical architect defines the System Architecture, but the business analyst has to understand this for alignment and definition of functional specifications.

Allow me to discuss each business analysis activity for IT consulting:

  1. Elicit Requirements: Identify business expectations and available resources.
  2. Identify Business Flows: Narrate expected user experience and corresponding system activities.
  3. Align Business Flows and System Architecture: Polish business flows based on defined system architecture.
  4. Define Functional Specifications: Translate business flows to implementation-ready features.
  5. Report Progress: Communicate solutioning progress to the client. Relay contents of functional specifications document.

1. Elicit Requirements

Excerpt from BA Framework - Elicit Requirements:

At this stage, the term 'elicit' is used instead of 'gather' to convey the proactive role of a business analyst during project initiation. A business analyst does not only gather requirements, but also asks the right questions.

For consulting, this involves discussing with the client the following concerns:

  • Business context
    • About the company?
    • Org structure?
    • Why is the project being done? What's the business value?
  • Technical ecosystem
    • How does their current system architecture work?
    • Where will the solution come in?
    • What system components can the solution use or integrate with?
  • User experience
    • Who are the expected users of the solution?
    • What can the system do to its users?

The consultants can request the client to narrate the envisioned solution from their perspective, just to gauge their expectations.

If the client is technically-adept, the consultants can opt to refine their vision and not waste effort in reinventing the wheel.

Collating all relevant business documents from the client is also vital at this point. These artifacts are useful in the analysis phase.

Output: Elicit Requirements

  • Initial Research
  • Minutes of the Meeting / Notes
Back to top


2. Identify Business Flows

At the start of analysis stage, the business analyst is expected to define the expected user experience and corresponding system activities. This activity goes hand-in-hand with the technical architect's solutioning process.

This involves the following tasks:

  1. List down user stories, preconditions and normal flow.
  2. Create a user experience flow chart to illustrate business flows.

Image: User Experience Flowchart for a generic OTP feature

In this example, the client expects the recommended OTP module to behave like this. The technical details are available in the User-System Interaction Matrix, which shall be discussed in the next step.

Output: Identify Business Flows

  • Per Module: User Stories, Preconditions, Normal Flow
  • User Experience Flowchart
Back to top


3. Align Business Flows and System Architecture

Alignment is the most valuable contribution that a business analyst can offer in a consulting project. This entails matching each business requirement with proposed technical implementation.

An Important Note! Unlike in implementation projects, the vendor in a consulting engagement has indicate the technical details involved in proceeding a business flow. Transparency what they actually paid for!

After defining the expected user experience and initial system activities, the business analyst must fill in the recommended business flows with technical details. Collaboration with the technical architect is crucial at this stage.

During alignment stage, the business analyst is expected to do the following:

  1. Match each user story with expected system features
  2. Incorporate technical components relevant to the business flows. Examples of technical details are the ff:
    • Are there important APIs need to be called to perform a task?
    • Available services of Application 1? Types of ESBs needed to access Application 2?

Image: Redacted User-System Interaction matrix

Based on the screenshot, the client has already informed us during elicitation stage that Application 2 can only be accessed using an ESB. I just filled out the ambiguities with technical details as the analysis went along.

Output: Align Business Flows with System Architecture

  • User-System Interaction Matrix
  • Table of involved technical components per business flow: Services, APIs, etc.
  • UML Diagrams:
    • Sequence Diagrams - To depict API behaviors
    • State Diagrams - To depict transaction states
  • Wireframes and Mockups
Back to top


4. Define Functional Specifications

Now that the proposed solution is clear, it's time to consider implementation. The following items must be defined:

Functional Modules

  • Categorization of all features based on similarities.
  • For example, all OTP-related features are under the OTP module. All administrative tasks are grouped together.

Use Case Index

  • Itemized features ready for implementation.

Excerpt from BA Framework: Analyze Requirements:

For instance, a business requirement would sound like this:

1.3.1 The system shall allow the users to perform calculations for trading amounts, calculations for market fees for energy, and calculations of market fees for reserves as separate processes.

The corresponding functional specifications, or use cases, for that requirement are the following: 

Settlement Process Type: Main  
Step 1: Calculate Settlement Amounts  
Step 2: Calculate GMR (without Energy and Reserve Market Fees)  
Step 3: Finalize Calculations

Settlement Process Type: Energy Market Fees  
Step 1: Calculate Energy Market Fees  
Step 2: Finalize Energy Market Fees

Settlement Process Type: Reserve Market Fees  
Step 1: Calculate Reserve Market Fees  
Step 2: Finalize Reserve Market Fees

Image: Sample Use Case Index with Functional Modules/Category

Acceptance Criteria

  • Working details of each feature. This will be refined into use case descriptions during actual implementation.

Image: Redacted Acceptance Critera

Output: Define Functional Specifications

  • Functional Modules
  • Use Case Index
  • Acceptance Criteria
Back to top


5. Report Progress

Progress reports are opportunities for the vendor to cascade solution developments and to raise any issues.

During progress reports, the business analyst communicates the following:

  • Process Flows
  • User Experience - Show wireframes
  • Functional Specifications
  • Potential Implementation constraints

The technical architect also defends his rationale on his technical designs.

Output: Report Progress

  • Presentation Slides - Progress Report
  • Minutes of the Meeting
  • Latest snapshot of Functional Specifications Document
  • A repository of final diagrams and wireframes
Back to top


Consulting Output

My first consulting engagement requires us to produce a Functional Specifications Document (FSD), which mainly contains the following:

  • Proposed Solution and Process Flows
  • Functional Specifications
  • System Architecture

We are still polishing the FSD as of this writing. It currently has 91 pages.

Final Thoughts

Throughout the consulting stint, I find myself frequently revising the FSD due to changes in the solution. The job required me to learn and adapt quickly.

This experience made me appreciate the black box's inner workings. I learned so much technical concepts in this project, such as how APIs and ESBs work and understanding system architecture as a whole. I know these working knowledge is not enough, but it's a start.

The experience is also an eye-opener in estimating effort and negotiating technical services to clients.

To conclude, the value of business analysis in IT consulting are:

  • Alignment of expected business flows and technical solution
  • User experience and project implementation considerations in defining functional specifications

Business analysis work tends to be more technical in IT consulting than in system implementation projects. Business analysts in IT consulting are required to convey the technical solution in terms of business flows and functional specification.

Lastly, the work still adheres to the objective of business analysis in general: to identify and solve the right business problem—with an invaluable specialization.

Back to top