Phase 1 - Businesses in this phase are somewhat aware of some pain points and inefficiencies. Aligning all business stakeholders on identified pain points is critical. At this phase it's critically important to answer the following questions:

What? - What are the pains and inefficiencies we're experiencing as an organization?

So what? - Why do each of the points identified matter? If we solve those problems, what benefits can be expected? What is the expected cost or impact of NOT solving these problems?

- A business review of current and anticipated pain points and inefficiencies

- One half-day to full-day workshop program to help identify business pain points and associate potential technical solutions

At the end of this phase an organization should have a clear idea of their operational and competitive inefficiencies and struggles. Collectively, stakeholders should all agree on identified points and should have all reached alignment on whether the problem is a technical problem (can be addressed solely with technology), a non-technical problem (must be addressed by process, behavior, and expectations rather than technology), or a hybrid problem (technology and modified human behavior create a solution).

Phase 2 - Organizations in this phase have started or are in the process of starting to envision how potential solutions to their most pressing pains might look. The top 2-3 use cases are identified and agreed upon by the stakeholder audience.

- A one day workshop to:

-- Review identified pain points and inefficiencies  

-- Focus on technological or hybrid problems

-- Selection of top 5 pain points

-- Can we envision a use case for 2-3 of these pain points?

-- Prioritize selected use cases

-- For each selected use case:

--- Create a problem description (recap of 'what?' and 'so what?' questions)

--- Define S.M.A.R.T. goals for each use case (specific, measurable, actionable, relevant, timely)

At the end of this phase an organization should have identified and prioritized 2-3 use cases based on pain points identified in Phase 1. Each use case will have a short description of the problem, why solving the problem matters, and what the goals used to define success for each use case are. This level of detail will enable solution designers and stakeholders to begin outlining use case proof-of-concept solutions.

Phase 3 - In this phase a business will architect a proof-of-concept solution for 1-2 of the top use cases identified in the previous phase. Architects will work with stakeholders to define the level of detail required in each POC to effectively tell a compelling solution story to the larger stakeholder group and business community.

- A one to two day workshop to focus on:

-- Identifying basic solution parameters (open vs close, public vs private, permissioned vs permissionless)

-- Defining solution Guiding Principles

-- Defining solution personas (current state)

-- Defining User Stories (ideal future state)

-- Defining Functional Requirements (what the solution must do)

-- Creating an idealized process map

-- Defining solution Assets, Participants, and Transactions

At the end of this phase a organization should have high-level architectures sufficient enough to begin construction of a POC for the highest level use cases identified. Development teams can now begin rapid prototyping cycles of POCs. 

NETWORK ARCHITECTING --

Phase 4 - While development teams are working to deliver POC iterations, the organization should be giving thought to any required infrastructure or administrative items. Any required network infrastructure should be identified and a plan should be created to either manage the required assets on-premises or to shop for a suitable service offering. The goal of this phase is to create an environment suitable for testing POCs and collecting feedback from the larger stakeholder group (in short, we want to take POCs outside of development environments into a separate test environment)

- Identify required infrastructure components

- Install or outsource them

A working infrastructure to deploy POCs to for wider consumption and testing by the organization. 

Phase 5 - In this phase POCs are being delivered to business stakeholders for review, testing, and feedback. This is an iterative phase and is likely to repeat many times. In each iteration it is critically important to focus on small, incremental improvements and short (no more than 1 week) development cycles. The goal of this phase is NOT to build a production-ready solution; a proper POC should convey enough of a potential story to an end user to help them decide whether the final solution would address the identified problem or pain point accurately and effectively. 

- Review POC with stakeholder audience

- Allow stakeholders to test POC solution

- Collect feedback

- Document new features and requested changes

- Provide level-of-effort estimates for each feature / change

- Sprint planning with the stakeholder group

-- Select work items to fill the next sprint

-- Prioritize work items

At the end of each phase iteration the team should have an updated product backlog and sprint plan for the next 1 week sprint. Features and changes which do not create a qualitatively different POC but will be required for a production release should be marked as "MVP" for inclusion in the minimum viable product release. The overall goal of the POC phase is to get stakeholder buy-in on a solution development; the goal of the POC phase is NOT to create an actual MVP or production-ready solution.