Business Use Case
Key Roles
Responsible:
No-code Business Architect
Approve:
No-code Stakeholder
Contribute:
No-code Creator(s)
Contribute:
Power Users / Subject Matter Experts
Inform:
IT, Security, Enablement
Introduction
This Toolkit for Business Use Case provides example checklists and questions to help you define your application’s intended business requirements and outcomes. The Business Use Case should be in clear and simple language and defined by the designated business sponsor of the application. In this Toolkit content we will explore some of the more detailed implementation questions and considerations as you complete this stage. Refer to supporting material around both the key Roles and Responsibilities (Chapter 4) and Application Matrix (Chapter 5) which will be referenced throughout the guidance.
The outcome of this stage should be a clear articulation of the project business goals and objectives, primarily anchored around defining the scope and impact of the business process(es) that will be addressed by the no-code application.
Stage Pre-requisites/Inputs
It is common that you may have started gathering some of the relevant inputs to this stage without even realizing it! Common inputs may include:
Business case or business justification: There may be a high-level justification that has been put together as part of prior discussions on rationale for the project.
Functional requirements: As far as the new application is concerned, inquire if there are any existing RFI/RFQ/RFP docs, UI mockups, meeting or demo recordings/minutes where requested features may have been discussed.
Process diagrams: There may be existing process documents that outline the current state of the process. Explore if there are descriptions of processes, standard operating procedures, etc.
IT systems/architecture: There will likely be some existing diagrams or reference materials that define what systems are in place that may need used or integrated as part of this project.
User/customer interviews/feedback: There may be notes or feedback collected from existing feedback or quality channels that have helped define the need for process improvement.
Organizational chart: Collect any information on which teams/groups may be users of the new application and business process(es).
Stakeholder responsibility matrix: This may help identify the key participants to involve in this stage (and later stages) for collecting requirements and feedback.
Don’t worry if this documentation may often be raw, unstructured and incomplete – just focus on collecting and harvesting what exists. It still provides important context for the activities in this stage.
Once you have collected any Stage inputs, you are ready to begin defining the Business Use Case. In addition to reviewing and synthesizing existing materials, much of your understanding may need to be captured as part of interviewing your primary No-code stakeholders and subject-matter experts as part of a set of working sessions. Following are sets of questions that you can use as part of these sessions.
Key Questions: DIY Delivery Model
If you have already determined (using the Application Matrix) that this project will be delivered using a DIY delivery model, here are questions to focus on answering as part of the interactive sessions; these answers should be documented as part of the final Business Use Case deliverable produced.
|
Why |
|
|
Who |
|
|
What/ |
|
|
When |
|
Key Questions: No-code CoE or Fusion Delivery Models
For more advanced delivery scenarios (e.g. using No-code CoE or Fusion models), here are some additional recommended questions to address when completing the Business Use Case. These may apply as your application takes on more Business, Technical and Governance complexity.
|
Why |
|
|
Who |
|
|
What/ |
|
|
When |
|
Key Questions: Success Criteria
Regardless of the complexity of the delivery model, you should conclude by making sure that you have clearly documented the overall success criteria for the project. There may be multiple viewpoints on success criteria, so make sure to focus on the perspective of the primary Stakeholder and sponsoring business unit. It is recommended you ask questions that help define “SMART” success criteria.
Specific: Have you defined the specific and concrete KPIs or benchmarks to know exactly where you are in terms of realizing the no-code application goals?
Measurable: How will we measure the results that the new application has on the business?
Achievable: How much direct control do we have on achieving the project goal? Is it achievable compared to previous performance?
Relevant: What is the anticipated return on investment (ROI)? What would it mean if we failed to reach the project goal?
Timebound: What is the longest and shortest possible time to achieve this goal? Are there potential blockers or time-related factors that could delay progress?
Best Practice Tips
This stage should consider the full-picture definition of the business vision and requirements. It’s easy to start constraining your thinking based upon how the application might be released or anticipating how it might be broken into releases over time. Resist that temptation – scoping will come later (during the Project Assignment stage), but for now, maintain a broad view of what the business solution needs to be.
Carefully select the no-code stakeholder which is the primary business owner of the requirements and is the person ultimately accountable and responsible for representing the sponsoring business function or unit. There should only be one business owner, and they will act as the ultimate viewpoint when it comes to making any decisions on requirements or priorities.
Focus on the “what” (i.e. the outcomes that must be achieved) not the “how” (i.e. how should the application be built). As discussed earlier in this chapter, manage scope to the top of the Requirements Pyramid and avoid getting into User or System level requirements details. It’s easy to get pulled into trying to document a lower level of requirements during this stage, but clearly manage the level of detail – the additional requirements will be captured in later stages of the no-code lifecycle.
However (and this may sound contradictory), it’s never too early to begin anticipating governance requirements, even if this is largely going to be addressed in later stages of the lifecycle (in Chapter 14 “Governance”). You should begin to identify if internal or external regulatory/security/compliance/data governance restrictions need to be taken into account so that you can begin to plan for involvement with the right resources. You should identify the SMEs that should be involved in later stages of the project and who will help define and execute the necessary governance checks.
Understanding the current state of the business process is an important part of answering the above questions. Depending on the current level of understanding of the existing process, it may be recommended to perform user-shadowing to see what they do now and how they accomplish current tasks.
Finally, keep in mind that the Business Use Case is a living document and must necessarily evolve as the business evolves. You will need to periodically revisit the Business Use Case to review if it must be realigned as the needs of the business change; ongoing changes are a given in the rapid and dynamic environment in which most enterprises compete. This will help future releases of the no-code app stay aligned with the core business vision and process, and bring together a commonly shared view across business and development helps improve the alignment.
Example Credit Union Mortgage Lending Workflow
To close off this stage, let’s provide a short example focused on a Credit Union lending workflow. To illustrate that a Business Use Case need not be voluminous in length, we’ve provided a very short and succinct example worded in the format of a user story. (note that it’s not required to use this format, but it’s a common and widely used technique).
“As COO of our Credit Union I want to automate mortgage lending workflow for physical applications using a no-code system in H2 2024 to align different manual processes into one, correct, automated process that has to work in the same way in all branches of our union.”
Taken together, these two artifacts of the business use case have been addressed in the checklist outlined earlier in this section.
|
Why |
|
|
Who |
|
|
What/ |
|
|
When |
|
As you can see, we now have clarity on scope, objectives, timing, and users from this short definition. While you can certainly add more details you already have a very good start to a decent business use case that can be later decomposed into smaller use cases and features.