When Business Requirements Aren’t Good Enough

Requirements are inputs to achieve the project objectives that transcend from routine operations to enhance the value proposition of a business endeavor. Stakeholders invariably perceive an endeavor to be successful only if they are able to clearly correlate the derived outcome to predefined business requirements. Thus project success is best defined in terms of effective user requirements.

A simplistic interpretation of ‘requirements’ stipulates that it is “a promise to deliver the right outcome”. This is a very basic assumption but draws out the merit and intention of a carefully laid down user requirement. A promise to uphold and deliver the desired outcome is a true reflection of the intent and clarity while formulating effective requirements. The role of a business analyst is critical to ensure that the requirements identified and agreed upon are capable of attaining the desired outcome.

We will attempt a study of an endeavor where things went wrong, wherein an intended enhancement of a business process did not end up delivering the desired outcome. (N.B. the organisation name shall remain anonymous. Permission to use the assignment for this article was sought and approved by the client.) I was exposed to this case when I was asked to support the resolution of an incident and investigate the possible causes. This is the story of when requirements go wrong!

The process constituted steps to process direct debits towards customer loan repayments. It was inefficient, was disconnected, and exposed the organisation to risk.

1. Disconnection: Users have to generate customers’ direct debit payments due for a given day from a designated system (referred to as system 1 for the purpose of this study) and upload the file to another system (referred to as system 2 for the purpose of this study). The file is currently uploaded manually. However, it can easily be streamlined and set up for automation by eliminating user intervention.
2. Inefficient: Manual handing of system files is not considered efficient and is incompatible with systems integration practices. It not only slows down the process but also exposes the database to umpteen risks and errors that can potentially render the process ineffective.
3. Risk: A significant risk associated with manual data handling is compromise in confidentiality of sensitive customer information (i.e., bank account details) and its potential exposure to theft.

A business analyst was asked to look into the possibility of automating a process where the current process had multiple manual touch-points. The business analyst studied to understand the desired future state and successfully documented the desired process to recommend a stable future state. The future state process design was supported by requirements and rules to guide the endeavor to streamline the process. The proposed solution entailed the following transition:

1. Integrate system 1 and system 2 to establish seamless processing.
2. Minimize user intervention in processing direct debit payment files.

These requirements and the desired process map were communicated to the Information Technology (IT) team for development and implementation. The enhancement was tested based on the requirements and rolled out to production.

On day one of go-live, the business users identified a defect in production associated with the roll-out of the direct debit process enhancement. They were unhappy and expressed their dissatisfaction pertaining to the entire process of solution development. They instantly claimed that the ‘requirements ‘elicitation was passive and ineffective in capturing all the critical parameters’.

In an attempt to understand and define the problem statement, the business analyst had asked the question “What do you do and how can it be done better?” The users stated their story and expressed the pain and how they envisaged the desired solution. It appeared that the users narrated their story by focusing on the future state. It mainly revolved around how they would like the future to be. This is a common practice, where business users tell their stories while thinking forward. The business analyst then documented what he/she was told, got it reviewed, and shipped it to the IT team for development. This is what IT received as ‘requirement’:

‘The solution must integrate system 1 and system 2, where user intervention is not required to process direct debit payments files.’

This requirement caused a serious discomfort and embarrassment to the business. Day one from going live, according to the incident description, ‘direct debit entries for written off and closed accounts are being generated … This has impacted x% of customers with written off accounts...'  (N.B. The anonymity agreement with the organization subject of this case study restricts revealing the whole details of the impact.) Why wasn’t this requirement good enough?

1. Generic and high-level requirements. Insufficient details were provided to progress on to the development phase of the solution with such requirements.
2. The business analyst took it for granted and believed what he/she was told to be the complete truth that would hold true in all scenarios. Even though he/she documented the current state process accurately, he/she did not go beyond and above what he/she was told. However, the information gathered turned out to be incomplete. The business analyst missed details, business rules, exceptions to the rules, etc. (a) and (b) are examples. Hence the requirement was incomplete.
   1. When the users generate the file from system 1 and upload it to system 2, system 2 processes the file, excluding certain accounts, using a set of criteria that stipulates that “closed and written off accounts must not be included in the direct debit processing”.
   2. System 2 also validates information contained on the file and pops up errors on the screen for the user to validate and manually exclude or rectify before uploading.
3. The business users reviewed their story. In general, users validate only what they have communicated. They tend to trust that the business analyst knows what they are doing and seldom proceed to question their domain. The user safely assumes that they are only required to validate their own story and not the interpretation of the business analyst.
4. In general, the IT team expects that the requirements provided are complete and have been validated to ensure the desired outcome. Their focus is limited to the system or functional requirements and its implementation across the impacted technology components.

The root cause analysis reflected that the process went wrong at every stage of the process. However, the requirements elicitation stage showed passivity and slackness that cascaded to the subsequent stages of the process. This could be correlated to the passive approach adapted by the business analyst.

It is the role of a business analyst to gather information and conduct intelligent application of knowledge acquired through reasoning and assertion of facts relevant to the current scenario. It is imperative to ask the right questions, examine every step of the process, and understand what happens behind the scenes.

The user only narrates the story that they can visualize; they don’t necessary communicate every episode of the story. Thus the business analyst should have been diligent enough to identify the gaps and evolve a comprehensive plan with intelligent requirements.

When the requirements are elicited, do the users provide details? They tell story, not requirements. Jonathan Gottschall, author of The Storytelling Animal, says science backs up the long-held belief that story is the most powerful means of communicating a message. People tell stories because it is a part of human nature; we like to tell stories, read books, and dramatize on TV, cinema, etc.

In this case study, the business analyst did requirements ‘elicitation’ but no ‘analysis’. In the requirements elicitation context, business users tell stories because they like to be heard and understood. However, listening to the user story is not ‘analysis’; it’s merely ‘elicitation’. Information can be amassed through various collection disciplines: human source, written communication, documents, and many others. The system of remodeling the unknowns to acknowledged facts, issues, conditions, legacy, and human sources is the analysis that identifies the requirements.

In summary, requirements analysis is not an exact science. We are called ‘analysts’ for a reason: being able to walk in, assess, analyse, and construct a process that would work for the instance we have at hand. We don’t heedfully auricularly discern stories and convert them to ‘requirements’. Our integrated value lies in going above and beyond the story and expanding beyond engendering deliverables. We coalesce critical thinking and perspicacious curiosity to transform stories to abstracts and propose the needs. In this case study, the story as told by the user covered only the highlights and left the investigation of the unknowns to the analyst.