How to Save a Quarter of Your Implementation Project Budget Using a Business Requirements Quality Checklist

How to Save a Quarter of Your Implementation Project Budget Using a Business Requirements Quality Checklist

Hello, Habre! I am Volodymyr Khrypun, head of the competence center for the development of BPM systems. In short, when you have a business process in your company – actions that are regularly repeated lead to the desired and predictable results, and you (or the business owner) want these results to be better, with less loss and generally for everyone to be happy and if you bought a Lamborghini, you need a team like ours. We help partially or fully automate the company’s business processes.

This article is about a business requirements completeness analysis checklist for digital transformation projects.

The more people work in the process, the greater will be the effect of the implementation of the bpm system. Let’s assume that the operating business is freight transportation, the business has about 100,000 wagons. You have thousands of customers and hundreds of employees. And let’s assume that one of the processes is the coordination with the client of the route that the cargo will take. Result: the route is agreed, the wagons are being prepared for loading. The process involves several departments performing different roles, and every day the company’s employees perform hundreds of actions to achieve the result – such processes are called end-to-end, they are large, complex, but vital for business. Economic effects in such a project can be achieved by simplifying the process, making complex or rarely used steps clear to employees. The most vivid example is “Tasty and full stop” *). They don’t make the tastiest burgers, but they make them fast and with a guaranteed level of quality. Complex processes are simplified and, where possible, automated. Therefore, in 5 minutes we can buy a cheap burger, and the company earns millions from this – everyone is happy (especially the shareholders)).

So, when you automate a business process, the success of the project depends on many factors. The key is the quality of business requirements. Business requirements, on the one hand, have a fairly clear definition, but as practice shows, everyone puts their own meaning into it. Out of 100 business analysts on the market of the Russian Federation and the CIS, only three thoroughly studied the BABOK (Business Analysis Body of Knowledge), and the rest, like the classic “We all learned a little something and somehow.” As a result, business requirements may not cover the entire process, not simplify, but complicate the steps of this process. When the business requirements are done poorly, the work of the rest of the teams will be wasted. And these are a dozen IT employees: system analysts, developers, architects, testers and others. Imagine if a Michelin chef prepares a dish from expired products, but not all the ingredients are there. The cook can do everything perfectly, but eating this dish will be dangerous for health. The same with projects where the business analysis is poorly done.

The stakes in end-to-end automation projects are high – 3-12 months and a budget for the entire development team. In order to eliminate risks related to the quality of business requirements, we have developed a checklist: “Checking business requirements for completeness and consistency”. This is a kind of check of the ingredients before you start cooking. Do we have all the ingredients for the right dish? Are they all fresh and of good quality? If so, then restaurant visitors will be delighted.

The checklist is divided into blocks and we check business requirements based on each of the blocks. The fewer points are filled, the higher the risks that the project terms and budget will multiply.

Composition of the project and its goals

  • The list of interested persons and owners of business processes is recorded. It is indicated which process the interested person is responsible for, or in which process the interested person participates.

  • The effects of the introduction of business process(es) are described. The document specifies at least one of the following effects:

    • economic benefits;

    • saving labor costs;

    • compliance with the terms of the legislation of the Russian Federation and information security requirements;

    • other effects expressed in qualitative and quantitative indicators.

  • The document contains a list of business processes, the transformation of which will allow to achieve the effects stated in the project. If the name of the process is not in the company register, the project team suggests its own name. The name of the process should be no more than 1-2 sentences.

  • For each business process there is a short description, which is contained in one paragraph (no more than 150-300 words). The text should contain the essence of the business process without references to other texts.

Description of the business process

Applies to each business process declared as part of the project. The business process is described from beginning to end, that is, all actions within the process are taken into account.

The boundaries of the business process are marked

  • The start event that initiates the business process is defined and described.

  • Preconditions that must be satisfied by the system before the start of the business process for its successful launch are described.

  • Options for entering the business process are described.

  • Listed outputs and outcomes of successful business process completion.

The basic scenario of the business process is described

  • Textual description of the business process in sequence, the process is analyzed step by step. First, the main branch of the process is analyzed – successful, then alternative and failed branches.

  • There is no need to switch between parts of the document to create a complete picture of the business process. The process is described sequentially and linearly.

  • If a business, functional or non-functional requirement is described that is used in multiple stages (or steps) of a process (or processes), it is fully described in each stage (not presented separately).

  • The business process should include all user actions that ensure the achievement of the business process result, including outside the system.

  • If the customer plans to change the business process to achieve the planned effects, the document must contain a detailed description of the business process with attached as-is and to-be diagrams, accompanied by a text explanation. Description of the process “as-is” – how the process works now, that is, before the digital transformation project. Description of the “to-be” process – the target state of the process, which will allow achieving the effects declared in the project.

  • If the systems in which the business process is carried out are predefined, for each step/stage the system in which the step is performed must be explicitly written. If the operation (step/step) is performed by employees outside the systems, this should also be reflected and indicated in the textual description and diagrams.

  • The recommended notation for describing a business process is BPMN 2.0. Acceptable: EPC, IDEF0 together with IDEF3, block diagrams, if they meet all the requirements of the checklist.

All alternative branches of the business process are described

  • All alternative branches are listed, for each alternative branch the step/stage of the main scenario where the branch may occur is indicated.

  • Alternative branches are described with a clear indication of the events and main stages of the process at which the transition to the alternative scenario takes place.

  • Listed results and results of successful completion of alternative branches of the business process.

All failed branches of the business process are described

  • Failed fields are described: events and results of unsuccessful completion of a business process.

  • Failure branches must consider alternative branches, if any: for each alternative branch, a failure path must be considered.

The requirements for reporting based on the business process are defined

  • Metrics by which the project team determines the achievement of project goals should be part of the reporting.

  • The business logic for calculating the metrics needed to assess the project’s effects is clearly written.

  • The reporting requirements requested by business customers are defined. Required reports are described: there is a list with the name of the report and the specified metrics that must be included in the report.

  • For each calculated parameter, the formula and business logic of the calculation are specified in the report.

  • A business process takes into account the actions and steps that provide data for a specific metric/report.

Description of system integrations

The points of integration with external systems are identified and described, or it is indicated that there are none.

  • There is a description at which stage of the process information (data) obtained from another system is used.

  • There is a description for what purpose data from another system is used within the business process.

  • The data obtained as a result of the integration is sufficient to achieve the objectives of the business process/step within the business process that requires information from the external system.

  • The frequency of data exchange is specified (for example, a time interval or an event).

Additional requirements for business process description

Apply optionally: we recommend making a description of the status model if the business process consists of more than 7 stages and includes 2 or more performers.

  • The status model of the business process is described, which allows to simplify the understanding of intermediate results that arise during the execution of the process.

  • The status model takes into account failure and alternative branches of the business process.

  • The roles and access rights required for the business process are indicated. The relationship with business process operations is described and the information to which the user must have access (from the point of view of business logic) is indicated.

  • Change monitoring requirements are defined: who should see the history of changes, at what level of detail.

  • A glossary has been written. All terms and abbreviations used in the document are defined.

  • Requirements are consistent – there are no situations where one requirement conflicts with another.

Requirements for use cases

Use when the IT system in which the operation (step/step of the business process) will be performed is understood in advance, and there is an idea of ​​the target behavior of the system.

  • Tracing (communication) of the usage scenario and the business process element is provided. The relationship between the scenario and the business process element is clearly shown, that is, it is indicated at which stage/stage of the business process the scenario works.

  • If the business process is implemented in two or more systems, it is clearly displayed in which system the scenario is executed.

  • A usage scenario reflects specific user and system actions within a business process.

  • The description of the use case is sufficient and atomic for implementation. There is no need to search for additional information that will significantly affect its implementation outside the script.

Anyone who studied at a driving school could hear from the instructors that traffic laws are written in blood. Likewise, our checklists are a reaction to missed deadlines and inefficiently spent budgets. For each point, one or more accidents. After implementing the Checklist: “Checking business requirements for completeness and consistency”, we started to save from 15 to 30% of the declared project budget, the accuracy of business requirements implementation deadlines approached 95%.

I hope you find this article useful. Write in the comments what should be added or removed from the checklist, we are constantly improving our processes and approaches.

PS Despite the fact that I am writing the article from my account, many people worked on the checklist: Valery Navogorska, Anastasia Sereghina, Oleksandra Dovbysh. Feedback, mentoring, and useful experience were shared by the heads of PGK Maxim Yeliseev, Anton Panteleev and Oleksandr Dolgov.

Related posts