Edit

Project initiation

The initiation phase is critical for project success as most preparation and business analysis activities are conducted during this phase. Effective, detailed, and qualitative requirement gathering at the project's beginning helps to maximize benefits and minimize costs while delivering value to a customer. Having a clear scope and success criteria enables you to achieve all this.

You should consider numerous factors to achieve project success and identify constraints and assumptions to avoid challenges during delivery.

The Data Analyst should take the tasks listed and consider a checklist to ensure nothing critical is missed.

Requirements elicitation

Document analysis

The project begins with the requirements elicitation that starts with document analysis. Document analysis is a means to obtain initial requirements by studying available documentation and identifying relevant information.

Document analysis can include analysis of the contract, the statement of work, existing specifications, guidelines and procedures, market studies, and much more. Document analysis is used to gather details of existing solutions, including business rules, entities, and attributes that need to be included or updated in a new solution.

Sources of requirements can be different. Let's consider the most frequent ones.

Statement of Work

The Statement of Work (SoW) is the most important document that includes a high-level description of the scope of work, timelines, and budget. SoW can contain success criteria and delivery requirements if identified at this stage. Quite often, they are defined only on a high level, and the delivery team should communicate with a client to understand the current process flow and the requirements for the future flow.

SoW also contains the list of features descoped for the project. For example, it can be handwritten text processing, connections to some third-party systems, and so on. If any other dependencies are revealed, they are not covered by the solution, and the client agrees to descope them. You should document such decisions in Business Requirements Document or Solution Design.

Business Requirements Document

Requirements are frequently captured by a client in a formal document, usually Business Requirements Document. If there is such a document at the beginning of the project, the Data Analyst should work out requirements in BRD, figure out gaps, clarify unclear requirements with the client, and investigate and define the required details. Capture the changes in the written form as updates to BRD or Solution Design.

Solution Design

The Solution Consultants team can propose a high-level business process schema at the beginning of the project. The proposed design is validated and detailed by the delivery team. The Data Analyst works on clarifying business requirements with the client, and the Solution Architect or the Team Lead proposes a technical design of the solution. All the details and requirements, including a finalized list of fields, a number of classes, particular documents (templates) for training, third-party systems to connect, and other issues are captured in the document. Solution Design should be reviewed with the client and approved before the delivery starts.

Document samples

The Data Analyst reviews samples presented by a client and tries to identify and analyze the following things:

• Quality of the original documents and possible quality after OCR (documents with handwritten fields, complex templates, poor scanning quality should be identified)

• Tagging patterns of fields

• Variety of templates

Each issue identified should be addressed, including:

• Fields that are always handwritten should be descoped, since there will be no value to train the model on.

• Complex templates or field logic should be worked out with the MLE to find the best approach to tag them and train the model. Suppose there are any limitations identified, for example, more than one group of line items needs to be extracted or any complex grouping of fields is required. In this case, communicate the limitation to the client and descope if possible.

• Poor quality of documents should be raised to the client. You should request to replace documents with ones that have better quality or align with the client that statistics can be affected due to OCR errors.

• A large scope of documents should be limited, especially for POC projects. If there is an unlimited number of templates, there should be a clear agreement with the client on which templates to select for tagging and model training first. The selection should be prioritized, for example, top 100 clients, most common vendors, and so on.

Communication with client

The main responsibility of the Data Analyst is to capture and document requirements, communicate with a client, study the current processes, and educate the client on the changes in automated flow.

Though requirements elicitation in requirement workshops with the client can be a team effort, the Data Analyst is a key person to drive this activity. The Data Analyst needs to collect all the questions from the team, prepare their own, and address them to the client. After sessions, the Data Analyst captures all the business logic revealed while communicating with the client and provides it to the team in the form of the requirements.

As a result, the requirements should be aligned with the client and fixed. The Data Analyst should prepare documentation that contains all the requirements and approve it with the client.

At this stage, the Data Analyst needs to prepare the following:

• A list of questions regarding process in general, documents logic, volumes (check the Data Analyst's checklist)
• Documentation with requirements (BRD, Solution Design, Manual Task mock-ups)

Requirements analysis

A Data Analyst's responsibility is not only to capture the exact requirements but make sure that, once delivered, the requirements in the final solution bring automation value to the client.

The Data Analyst should analyze elicited requirements in the following aspects:

• If the requirements are feasible and sufficient to achieve the automation goal.

  Feasible requirements mean that the scope of requirements identified can be delivered within the project timeline by the defined team, and there are no technical constraints to the delivery identified so far.

• If the requirements are contradictory.

  All the requirements should be straightforward and unambiguous to understand. The Data Analyst should check that there are no contradictions in the business logic captured from different stakeholders. If there are any, they should be resolved by a formal decision of key stakeholders.

• If there are any gaps in the requirements.

  All the requirements should present the end-to-end solution, at least on a high level. You can clarify some details later but make sure that the delivery scope is identified and that key features making up Minimal Viable Product (MVP) are detailed for the team not to meet any unexpected impediments during delivery.

• If the requirements are sufficient to start the delivery.

  Sufficient requirements can be considered within the MVP scope. Based on the process knowledge and feedback from the stakeholders, the Data Analyst should identify what are the most critical features that can form MVP and make sure all the details for key features are captured first.

• If success criteria can be achieved with the requirements.

  All requirements should be analyzed in terms of success criteria or the standards by which the team and the client can judge whether an automation goal is achieved. Captured requirements allow to trace the path to measure success criteria and execute them on the desired level.

• If all the potential expected exceptions within the requirements are revealed and accounted for in the design.

  A solution should not be designed as a happy path only. Instead, it should allow to capture and process various exceptions directly in the process flow without switching to a manual process. That's why the Data Analyst needs to reveal all the possible exceptions and ensure they are considered in the solution.

Improvement opportunities

The Data Analyst should not only capture high-quality requirements and follow them but also try to identify opportunities to improve business operations. Some common examples of such opportunities include:

• Increase consistency of behavior. Different workers can handle similar cases differently. Make sure that the most optimal approach is selected and it covers all the business logic and corner cases.

• Eliminate redundancy. Different stakeholders can request various functionality while their needs are met with a different single solution, reducing the cost of the implementation.

• Reduce complexity of interfaces. Where a new interface is needed, or the WorkSpace customization is required, think of a simple design that can meet users' needs.

• Automate or simplify the work people perform. Capture relatively simple tasks, for example, comparison or calculation, where decisions are made based on strict or inflexible rules that can be included in automation and reduce manual work.

Value

Once most of the requirements are captured, and the current process is more clear, the Data Analyst considers additional room for improvement. A client can have their vision of value, but once the picture is complete with all the process bottlenecks and pain points, the Data Analyst can consider additional focuses for value, which include but are not limited to:

• Process efficiency and transparency.

  WorkSpace capabilities allow delegating tasks to particular users and creating queues to handle documents in a flexible manner. If there is an urgent document, it can be easily picked up and processed. Additionally, there is a possibility to utilize out-of-the-box and custom analytics that helps to monitor the throughput and efficiency. Thus, the client can save additional costs on managing tasks and manual statistics.

• Apply productivity improvements.

  Employees can use WorkSpace as a single touch point, which can be customized to fit the reference information for review. While reviewing, a user can have everything in one place instead of managing multiple applications and doing manual data entry.

• Improve employee morale.

  Automation helps release people from mundane tasks, get them to know technology, and increase their expertise by reviewing complex tasks and exceptions that machines can't manage. By automating routine and repetitive tasks with robotic process automation, employees can focus on more fulfilling and value-added tasks.

• Provide good customer services.

  Automation helps to standardize processing and make it more smooth. One of the challenges a business can face is that someone might forget something or be slow to do a particular task. Automation can be used to provide reminders or even remove these tasks from the user workflow, so employees don't need to remember or be reminded every time.

  Quite often, it goes together with reducing time to process documents or fewer documents required for processing and quicker response for the customer, which all means improved customer experience.

• Reduce human errors.

  Automation of repeated actions can reduce the likeliness of a mistake due to a human factor. Sometimes, the cost of a mistake can be high, so reducing the possibilities of mistakes means reducing a significant amount of costs.

Happy path versus exceptions

Once a Business Process diagram is created, the Data Analyst should work it out end-to-end to identify all possible business exceptions. It is necessary to remember that each step of the process can have its business exceptions, and you need to work with SMEs to understand them. For exceptions, you need to know all the possible triggers or identifiers and the exception flow that can include wait time, document reprocessing, or a user notification of an exception so that the document is processed manually on time. It is critical to identify exceptions and design the workflow for them during the solution design stage because adding an exception flow to the completed Business Process can be cost and effort-intensive and might require Business Process redesigning.

Traceability

Requirements traceability is the tracking of requirements throughout the product development lifecycle. It is a documented thread that provides forward and backward visibility into all activity surrounding each requirement, including design, development, testing, and support. Requirements traceability ensures that each business need is tied to an actual requirement and each requirement is tied to a deliverable.

You can trace a requirement in one of the following ways:

• Forward: define which requirements will be affected if they need a change.
• Backward: identify the origin of each software requirement.
• Forward: define links between individual requirements and specific product elements.
• Backward: trace specific product elements to requirements so you know why each item is created.

Requirements traceability often takes the physical form of a requirements traceability matrix (RTM), a manual spreadsheet or a table that demonstrates how the requirements are related to other requirements, solution components, and other artifacts, such as test cases.

Requirements documentation

The most critical output from the investigation stage is requirements captured in the written form and approved by the client as a scope for implementation. The reason for documenting requirements is to obtain a clear baseline set of features for implementation and build the most optimal solution based on requirements' details and target success criteria.

Different projects necessitate different deliverables, and documentation varies depending on the project.

A new production development often is a new customized software development project. This scenario includes all requirements, including business requirements, technical requirements, functional requirements, and other vendor specifications to be documented. During this implementation, you should prepare a Business Requirements Document, a Solution Design, and a user guide.

POC is a short, focused, and agile development, so that these projects can specify few formal requirements. A project or sprint plan, user stories, and field mapping might suffice.

Upgrading the existing WorkFusion solution with new features, for example, a change in a Business Process, new data, or an infrastructure upgrade to a new version, requires only changes in the business and technical requirements to be included in the documentation. Process and data requirements, business rules, and functional and technical requirements that are affected need to be specified.

There are a couple of reasons why you should document requirements:

• All the details are integrated into one document so that nothing is missed.
• Written requirements aligned with the client serve as a baseline and source of truth in conversations about change requests.
• Documented requirements help to manage client expectations and align what will be done.
• Development sprints and timelines can be planned.
• Project success can be measured with the help of success criteria.
• A scope creep probability is minimized.

A degree of detail should be reasonable. You should detail your documentation as much as possible to capture all the requirements and features. However, do not spend too much time polishing of the documentation instead of actual delivery.

A Data Analyst's responsibility is to prepare the documentation and receive client approval of the requirements captured. Different use cases might require a different degree of detail, so a particular format can be selected by the Data Analyst.

To capture the requirements, prepare the following documents:

• Business Requirement Document. Business Requirement Document (BRD) is a document to record the functional, quality, and usability requirements in formats that are easily consumable for future analysis, architectural and design activities, and most importantly, in a format understandable by all business stakeholders.

  BRD should have details of the future process features, systems to be connected to, details of the IE fields for extraction, a list of classes for classification, details of input and output data, a list of out-of-the-scope features, and any other relevant information.

• Solution Design. Solution Design is a document that contains a description of the approach to the delivery: a high-level process diagram, a description of process steps, Data Stores, ML models, and Manual Tasks. Target success criteria and descoped features should also be included in Solution Design. If possible, include the requirements for a UAT process, for example, test data or test cases.

• Manual Task mock-ups. Manual Task mock-ups are optional and might not be needed where no customization is planned for a Manual Task. When an out-of-the-box Manual Task is used, a list of fields is enough to be included in BRD or Solution Design. In the case of Manual Task customization, the Data Analyst should prepare a mock-up and approve it with a client. The following tools can be used to prepare mock-ups: Diagrams.net, Balsamiq, Figma, and so on.

• User guide. You can create a user guide later than the investigation stage, for example, at the UAT stage. This document intends to assist users in running Business Processes and using the automated workflow. It contains details about the WorkFusion Platform and services, and guidelines for a particular use case. A user guide should be arranged as a set of instructions to perform a specific task in the automated flow or modify any settings.

templates

Find the documentation templates attached and use them. Remember that you should specify not only the data mentioned in the contents of these documents but all the valuable information regarding your use case. Feel free to modify the structure, add attachments and enrich these templates.

Requirements validation

Requirements validation is a key milestone of the initiation phase, which is ended with a formal approval and baselining of the requirements with stakeholders. It is critical to align with the stakeholders that you have correctly understood the requirements and have a consensus regarding the project scope. Before this stage, the requirements should have been validated multiple times in different forms. For example, verbal agreements are transformed into text requirements, text requirements are supported and verified by diagrams, UI mock-ups, and so on. Among multiple validations, this is the key and a final one, a formal check point before the actual delivery starts.

To fulfill the validation, take time to present the requirements documentation to the stakeholders and let them review it and put notes or questions. You can find out that they have changed their mind about some features or delivery terms, and the appropriate changes in the documentation are required. If the stakeholders are too busy to study and sing-off a BRD document, highlight in a gentle manner how critical this effort is and that the requirements-gathering process closes at this point, meaning it is the last call for changes. Later on, all change requests will go through a change management procedure.

Final resolution

At the validation point, you should have many details about your project. Here is where the following things should be brought up, discussed, and finalized:

• Assumptions are the factors that are believed to be true but have not been confirmed. These statements are used to judge the best approach for the delivery, but at the same time, assumptions can pose a certain degree of risk if they do not prove true. All assumptions should be clearly documented and confirmed where possible to identify and manage risks related to the ability of a solution to meet the business needs.
• Constraints are defined as restrictions or limitations on possible solutions. The Data Analyst is responsible for identifying and documenting any restrictions or limitations to the solution design and delivery. Solution constraints describe aspects of the current state or planned future state that cannot be changed. They are not requirements since they are not implemented in any form by the project team. Constraints are provided to the project team to inform them that the options to consider are not available.
• Business constraints describe limitations on available solutions or an aspect of the current state that the deployment of the new solution cannot change. Business constraints appear from sphere standards, business rules, regulations, SLAs, and so on. Constraints must be carefully examined to ensure that they are accurate and justified.
• Technical constraints include any architecture decisions made that can impact the solution design. They can include development languages or hardware and software constraints. Technical constraints can also describe restrictions such as resource utilization, message size, timing, software size, a maximum number, and size of files, records, and data elements. Technical constraints include any enterprise architecture standards that must be followed. They might create a situation where a requirement cannot be met using the current solution approach or by a solution component, and the project team has to identify other ways to meet the associated business need.