“You are about to embark on a major transformation, what would you follow to baseline a major software selection?”

What is current-state modelling?

Current-state modelling looks at an existing process experience to answer the following questions:

• What is the current user experience for particular scenarios?
• How is the organisation delivering that user experience through processes, systems, people, policies, etc.?
• How might we improve to support a better experience for the user?

Current-state modelling becomes an “check-point” of the current experience and the current organisational practices that result in that experience.

Why would you do current-state modelling?

Current-state modelling is hugely beneficial for organisations that suffer from working in silos (who doesn’t right???).

The benefits of current-state modelling are:

• Shared understanding across business units of how your organisation delivers — often organisations aren’t even aware of the breadth and depth view of their business, and what the experience is.
• Shared understanding of how process execution results in the user’s experience — by looking end-to-end, you can see how processes, systems, or policies might be causing pain.
• Identification of improvement opportunities — both in how to improve the user experience as well as the delivery process.
• Alignment across stakeholders — by looking at the service across the organisation, gain a shared understanding and more easily align on directions for improvement.

Current-state model format

Current-state modelling uses a “checklist” of sorts to break down the often mysterious mechanics of delivery from the user’s perspective.

You have the end-to-end steps of the particular scenario you are modelling:

Underneath each step, you have layers that break down both the on-stage activity and the behind-the-scenes.

The top set of these layers are about painting the picture of the current state, these are:

• Step definition: Define what is happening in that step
• Touchpoint: A point of interaction between the user and the process
• Actor: A person in the scenario — either the user, support staff, or 3rd parties involved in delivery
• System: Technology systems that support the process
• Policy: Rules or regulations that apply to aspects of the business process
• Information: Facts or observations relevant to the step
• Metric: Data or statistics about this step

Then you also have layers for capturing questions and insights:

• Question: Questions that you have about the step that need to be followed up on and actioned
• Critical moment: Sources of pain and experience breakdown (potential or actual) — what can go wrong in this step
• Opportunity: Identified realisations, ideas, or opportunities to improve or fix for a broader impact

You may have one more more (or none) of each of the above layers — these layers simply act as a checklist to make sure you’ve thoroughly documented the reality of what is happening and support that particular step.

These layers paint a full view of what is supporting each step, which helps your team gain a full understanding of what is being delivered.

Current-state modelling process

To create a current-state model:

1. Identify what scenarios you want to model
2. Break down your scenarios into steps
3. Assemble a cross-functional working group to create the end-to-end model 
4. Go deep into the steps, and begin identifying opportunities for improvement
5. Really look hard  for improvement opportunities, both tactical and strategic
6. Create an action plan to implement improvements

This process can result in both smaller, incremental changes to your business, but it can also help your organisation identify more strategic directions to explore to radically change and improve services. Where you focus might depend on the maturity of your organisation, and the resources available for improvement or innovation.

Future-state modelling

Where current-state modelling is focused on looking at the reality of an existing process and how that results in user experience, future-state modelling is about inventing something new, both for the user and for the organisation.

There are several factors to consider:

• What should we be offering? What need does it solve for the user? Is there a business case for solving that need? Does this fit within our organisation’s portfolio and capabilities?
• What is the ideal user experience? What will truly be the best experience that users wish to have? How might we find this out? How might we test this?
• How feasible is the ideal user experience? Is our blue-sky desired experience realistic to deliver? Do we have the capabilities to deliver it, and if not, what are our gaps?
• How might we deliver the desired user experience? What could be the minimum viable approach to test this new process? What could we start doing today to test our assumptions? Then how could we scale that implementation to fully offer a robust process and service to the user? What resources would we need? What realistically can we deliver, and when?

When you are defining a new process, you are both imagining an ideal experience for the user, but also imagining a business model that can support consistent, quality delivery of that experience. You are inventing a new business model! There is no aspect of this that is easy.

Future-state modelling can help your team to balance the tough conversations about resourcing, process, systems, implementation, and support that are necessary in order to create a great, new user experience.

Before you make a future-state model…

Because of the complexity of envisioning new experiences and the business models and structures to support those experiences, you will need more than just modelling  to help your team through this process.

Before you dive into future-state modelling, you need to already have defined your desired experience. The reason is, the modelling format works best when you already know what specific steps of the user experience you want to support. Future-state is all about breaking down those steps to explore how the organisation might be able to deliver that experience.

There are a number of techniques you can use to explore what you should be doing:

• Current-state modelling — If you are looking to innovate on a service that your organisation already provides, it will be hugely beneficial to ground yourself on understanding how you currently deliver today. This can lay the foundation for thinking about reinventing into something different. If you do current-state modelling first, you can also use this to do a gap analysis between current and future state for implementation planning.
• User research — Go out into the field and learn what problems your peers are having, their pain points, their desires. Techniques you might use are: user interviewing, surveys, market research, contextual inquiry. This research should inform the foundation of your problem framing, helping you make a clear business case for your new service.
• Problem framing — Make sure your organisation is aligned on solving the right problem for the users. Don’t just jump at the most obvious thing, but instead use Abstract Laddering, Problem Tree Analysis, or Jobs To Be Done to help your team narrow in on the right problem that your service will solve for.
• Value proposition — Define the value proposition. What problem is it solving, for who, and what value will it provide? This should be your guiding light to help your team stay aligned through the design process.
• Storyboarding — Leverage your users and your team to generate high-level storyboards that start to define the specific aspects of the ideal user experience. 
• Future-state journey mapping — Going deeper than high-level storyboarding, use a journey map format (doing/thinking/feeling) to break down the specific steps you think should be part of your future-state experience. Get more concrete here and outline all the steps a user might take for the key scenarios. 

The outcome of these activities is a clear direction and desired user experience defined.

Why would you do future-state modelling?

• Explore feasibility of the desired user experience — Because modelling helps you break down all the details of your organisation’s delivery process, doing this with a cross-functional team can help you explore the feasibility of your desired experience from an implementation and support standpoint. Things you thought might be a great idea might be completely impossible to implement.
• Adjust the desired experience to match the capabilities of your organisation — If you discover during modelling that your big vision is in fact too big, you can use this opportunity to adjust and redefine the desired experience to something more feasible. If this happens, you will want to make sure to leverage your pre-work on problem framing and value proposition to ensure your team stays aligned even if you are reducing the scope you had hoped to deliver.
• Gain alignment across all business units and stakeholders about the desired client experience, and how to deliver that experience as an organisation — By bringing together a cross-functional team to map out your new delivery model, you will gain shared understanding and alignment across teams as to both what you are trying to deliver to the users, and how you will work together efficiently to deliver that experience.
• Create a checklist for implementation — One of the best outcomes of future-state modelling is the concrete “checklist” for implementation and planning. You literally can reference your model blueprint for action items to put straight into your project plans.

Future-state format

The format differs slightly from the current-state modelling format because it is serving a different need: to explore (and, in a way, prototype through mapping) the process, and identify next steps for implementation.

Similar to a current-state model , the top layer is the end-to-end steps of the new desired experience, for key scenarios of your operation . These steps should cover a linear service scenario both from the user perspective and behind-the-scenes (hidden) steps as well.

Below each step, you can use a number of layers to begin to block out your delivery model:

• Step definition: Specific action happening within the scenario. Can be an on-stage or behind-the-scenes step, ordered chronologically.
• User action: What action the user is doing in this step
• On-stage Touchpoint: What the user is interacting with in this step
• On-stage Actor: Who the user is interacting with, and what action they are doing
• Behind-the-scenes Actor: Who is doing something behind-the-scenes, and what action they are doing
• Behind-the-scenes Touchpoint: What the actor is interacting with behind-the-scenes
• Systems: Technical systems, infrastructure, automation, etc. that supports the process
• Policies: Any rules and regulations that are in play in this step
• Questions: What questions do we have that we need to go answer?
• Potential pitfalls: What are the pitfalls, the possible failures, frictions, or critical moments
• Implementation owner: Who will own implementing this step (or aspects of this step)?
• Project phase: Will this step be included in now or at a future date?

A completed future-state model might be very messy as a first cut, but that is fine. It is meant to be a master plan from which to harvest your implementation and planning action items, such as:

• What touchpoints (interfaces, documentation, training materials) do we need to design and create?
• What policies need definition?
• What systems and integrations need to be built?
• What supporting materials and help paths do we need in place?
• What processes need to be defined and documented? (and what training is needed?)
• Who will be responsible for implementing each step?
• When will you implement what?
• What open questions does our team still have that are blockers?

A word of warning, do not go to market for new enterprise software (or even an upgrade to your existing platforms) until you have taken a good hard look at what your future-state is.

Future-state modelling process

The process itself is similar to current-state modelling, in that you need to assemble a cross-functional team to define the service delivery model. One thing to consider is that future-state modelling typically takes significantly more time than current-state modelling, because there is a lot of discussion and negotiation that needs to happen as part of the process of defining what the future looks like and the implementation strategy to deliver it. Plan to have multiple sessions blocked for the process, but also make sure to have the right stakeholders in the room who can be decision-makers for their particular area.

Here is the high-level of the future-state process:

• Do pre-work to define ideal experience
• Break down ideal experience into steps for key scenarios across the lifecycle
• Organise a cross-functional working group to blueprint out the model for your key scenarios
• Work with a program manager to start visualising an implementation roadmap and action plan

After modelling, you may end up needing to create additional artefacts to assist the team in implementation, such as user task-flows, more concrete storyboards or journey maps, and specific design specifications for interfaces, software configuration, and other client-facing deliverables. 

Final Thoughts… 

I hope this post has given you a view of how to utilise  modelling for two different contexts: an existing business model, and a new future-state business model. Both of these types of modelling are valuable, and can help your organisation become more user-focused in operational delivery but also assist with key decisions you make along the way!