From the “Lost Art of Concept Modeling” Series.
Concept modeling has been one of the best tools in my Business Analysis toolkit for understanding complex projects. Done well, the concept model facilitates necessary up front conversations needed for accurate delivery of projects. This series will provide the tools and techniques to help improve your product or project conversations.
There have been many conversations in the past few years advising, “If you are going to fail, fail fast”. I would like to offer that we do not need to fail for the sake of failing. Structured conversations early in the project cycle establish the needed context for the details that will come up in subsequent analysis. Concept models establish this context with easy to understand diagrams using nouns and actions that are agreed upon by the business stakeholders during the modeling exercise. The right amount of up front work eliminates rework later on in the product development cycle.
Note: Concept models are not limited to projects or products. You will see me use these terms interchangeably throughout this series.
Too Much Detail Too Soon
Most of the challenges in projects, from my experience, have been the lack of common understanding of business terms and processes. Conversations end up diving into excruciating detail of the actors performing the work and all of the steps needed to complete the work. These conversations take a large amount of time and provide little value to all of the participating stakeholders.
During the early stages of understanding, we do not need to know how the work is done. We just need to know what work is being done.
Flow first, detail later.
To assist with understanding the what, consider a stakeholder meeting who were talking about finance processes in the product value chain. In this example, assume the stakeholders are talking about an insurance product. The purpose of the conversation is to understand the product life cycle value chain (aka Value Stream).
During the conversation one of the participants was explaining a step where the customer provides a payment. To which I ask, “What do you mean by, payment?”.
In a stunned, moment of silence (You can hear them thinking why they have this Andrew guy here asking absurd questions!). I then add, “Do you mean when the customer pays for the insurance?”
The finance team says my case is when the customer finances their deal. The payment is when the dealer sends the money to the third party administrator. However, this is specifically called a remittance. In the back end of the system, the payment represents the allocation of funds to a specific dealer invoice.
The claims team member then mentions that a payment for them is when the claim is authorized and during the settlement process a payment is made to the service centre that performed the repair.
The concept model provides the bridge between the plan and the details.
Benefits of the Concept Model
Given the above example, there are many opportunities to make invalid assumptions based on my current knowledge on payments. The business may have different (yet completely valid) process around payment handling that are specific to their business.
In my experience, most concept models for a specific value chain in the business (or product) can be drafted during a 90 minute conversion with stakeholders. The stakeholders have a document that provides:
- General understanding of the business flow in a simple (but not simplistic) diagram. They can post this up on the wall for their project team to reference when they need a refresh on common processes and terms.
- Ease of on-boarding new team members as the concept model provides a high level view of the product or service. The concept model structures the information
- Staging point for deeper conversations. Product managers or business leads can assign value to different elements within the concept model. This enables prioritization of features or micro services. Detail conversations can begin at the most responsible moment in the product development, within the specific feature area in the concept model.
- Conversation starter. Having the concept models posted on a wall in the break room or communal meeting area can help spur conversations about the project. The models are continuously updated as the team learns new information about the product. Updating the wall charts is a great way to show project sponsors that progress is being made.
- Frames the information architecture. Data models built using agreed upon nouns and verbs reduces the amount of research time required for future analysis or defect resolution. Physical database tables with no alignment to the business domain increases the chance of making mistakes as improper context may be mis-communicated between the technical team and business stakeholders.
Plan – Understand – Specify
Plan: Start with the vision and objectives. Establish metrics and success criteria.
Understand: Build the concept model with a focus on understanding at a high level what the product or service does and the results to measure. Ladder up to the metrics from the planning stage.
Specify: Begin the detailed specification level work. Develop tests to challenge assumptions and provide data for the metrics set at the Understand and Plan levels.
Upcoming Posts
In an upcoming post in this series, I will explain Triggers, Results, Activities, Cases, and demonstrate how these can be used to build some of the early concept models for your project or change management initiative.
As a note, these are Agile “manifesto soluble” techniques. As an Agile practitioner I have been on the lookout for the techniques that enable the best quality of learning in the shortest amount of time.
Need Assistance?
Ask me about my “train the trainer” workshops. Arm your Business Analysts, Project Leads, Product Managers, Product Owners (and many others!) with the tools to build a common understanding across the teams. Elevate the quality of requirements, user stories and other deliverables while reducing defect rates. All done in Agile time frames – hours instead of days or weeks!
