Envisioning using Design Thinking

on
A few months ago, I a wrote an article about “Design Thinking and the Power Platform - start of the journey”. Since then, I have learned and experimented with specific “Design Thinking” concepts. This article is about sharing my experience on the techniques I find most suited for Dynamics 365 and Power Platform projects. 

However, before doing so, let me share with you a personal story, MY STORY, about why I am passionate about getting to a shared understanding of requirements and envision great solutions. 
 
Brussels – January 2014.
I enter the board room where I will be presenting the outcome of our “Discovery”. My colleague Peter is already in the room and finalizing his slides for the presentation. For the last 2 months, Peter and I have been working with a major Bank on a “Discovery” project for the Bank’s new Dynamics CRM system. 

Today we are sharing the outcome of the “Discovery”, which is the scope, high-level architecture, roadmap and estimates for the implementation of the CRM System. 

The boardroom is the largest I have ever seen, and a few stakeholders are already present. I have a quick chat with Peter and some of the stakeholders I met during previous workshops. 

A few more people enter the room including Brian who is the Head of Business Applications at the Bank. Peter and I are reporting directly to Brian during this project. Brian gives me a quick nervous look and nod to say hi. 
The room is now full and all the Project Leads and Directors of each of the Business departments involved are present. The project covers the following departments at the Bank: Customer Services, Marketing, Sales, Legal and Broker. 
I feel nervous to present for such a wide audience, but I am confident about the content.

Brian starts the presentation with an introduction and reminds everyone about the purpose of this “Discovery”. Then Brian invites me to continue the presentation.

My plan is to share a scope summary for each department before showing the high-level architecture, roadmap and estimates. 
I start by presenting the scope for Customer Services and Marketing and people are mostly listening and nodding. Then I switch to the Sales scope. This is where my presentation turns into a total mess. 

The Project Lead from the Sales Department cuts in halfway through and asks why her key requirement about multiple opportunities linking to a single quote is not listed.  With an aggressive tone, she reminds me that I was supposed to get back to her with options and is now very surprised that this requirement is not even listed.

After trying to find my words, I explain that as discussed during the workshop, this requirement is not how the Dynamics CRM Sales process works and that we agreed to start with 1 quote per opportunity. She interrupts me again.  “I don’t care if this is not how Dynamics CRM works and I need options to solve the problem I presented to you during our workshop”. She turns to Brian and shouts that she is not signing this “Discovery” as her key requirements are missing.

I felt like the atmosphere in the board room drops below freezing. I look at Brian for a desperate attempt for him to save me from the situation, but he is looking down. I have nowhere to hide and no one to step in for me.
I apologize for this misunderstanding and ask Brian if he is ok for me to redo a workshop with the Sales team to discuss options for this requirement and anything else that I might have missed. We continue the presentation, but I don’t remember the rest of it.

I still remember very vividly how terrible and embarrassed I felt during and after that presentation. Brian was not happy as this additional workshop meant that we would be late with the “Discovery”, pushing other deadlines along the way. 
This misunderstanding costed me and my team a lot of stress and rework as we had to redo some of the design work as well.

Needless to say, that we didn’t achieve the expected outcome of the “Discovery”. Once I submitted the final “Discovery” deliverables I never heard back from my client. An internal contact told me that the Bank redid some workshops and contracted another partner to help them implement Dynamics CRM.

This bad experience hunted me for years. And the worse is that, during the “Discovery” project, I thought that everything was going relatively well. I used traditional Business Analysis methods to gather requirements and facilitate workshops. Asking insightful questions, going through the requirements list, reviewing Business Processes diagrams and trying my best to understand what my client wanted out of the system. 

This experience led me to try to understand why some projects fail and others not. There are many reasons for project failure, but I am now convinced that having a “shared-understanding” of requirements is key to deliver better projects by reducing miscommunication, stress and rework down the track. I made my goal to help individuals implementing Dynamics 365 and the Power Platform reduce misunderstanding and avoid burnout due to stress and rework.  

Today my “Discovery” engagements, that I call “Project Envisioning” look very different than 6 years ago. I use a lot of visuals and diagrams to share my ideas. I leverage a variety of techniques from Business Analysis, User Adoption and “Design Thinking” to help in the process.

I came to realise that I have limited control about how another person communicates her/his requirements. If that person has poor communication skills or forgets to mention something important, that can lead to misunderstanding.

However, what I can control is the way I communicate back my ideas to others. And this is the difference. Today I overshare my ideas and thought process. By explaining how I understood someone’s problem and reframing it in my own words, diagrams, print-screens, mock-ups, proof of concepts and live demos, I am making sure that we have a shared understanding so that others can provide valuable feedback early on.

Project Envisioning within a Dynamics 365 and Power Platform project

The following diagram represents my typical process when implementing Dynamics 365 or Power Platform project using an Agile methodology.

To me the “Project Envisioning” must be done at the start of your project and can be the first sprint of your Project. However, it is important to keep updating the project vision as new requirements arise during the “Project Delivery”. Ex: We might need to perform additional “User Interviews” and update the envisioning documentation during the Project Delivery. 

Let’s explore the 3 stages of the diagram:
  • Project Context:
    • What is the company Business Plan: Understand where the company wants to go. Check the company website and get more insight about the company’s key priorities.
    • What are the company’s current challenges: What are the major challenges for that company and industry? 
    • Solutions and Business Benefits: Understand the solution landscape. Where does the Power Platform and Dynamics 365 fit into the overall solution to solve the company’s challenges?
  • Project Envisioning: More about this stage in the following section.
  • Project Delivery: I recommend using Agile for the “Project Delivery” as it offers faster deployments, higher quality and quicker feedback loops which results in higher user satisfaction and adoption compared to traditional waterfall methodologies. My friend Neil Benson has a dedicated course about Agile and the Scrum framework to deliver Microsoft Business Applications projects. More details under: https://www.customery.com/

Project Envisioning - “Design Thinking Inspired”

The below diagram is my way of doing a Dynamics 365 or Power Platform “Project Envisioning” (Also called project “Discovery” by others in the Dynamics 365 community).
This process assumes the following:
  • My Team and I have a good understanding of the Company’s Business Plan, current challenges, and solution landscape before starting the “Project Envisioning”.
  • Dynamics 365 and/or the Power Platform are part of the solution landscape.
  • The Company has a list of requirements. At least at a High Level so that we have a starting point to build the “Product Backlog”.
  • The “Project Delivery” is  done using an Agile methodology.

Let me describe each the “Project Envisioning” activities:

1. Kick-off Presentation: This is the Kick-off presentation where I share the overall “Project Envisioning” process with all the project stakeholders.

2. Identify Key Users: I use a Use Case diagram to identify the Key Users as it is a powerful and simple technique to visualize high-level requirements with key actors. More info about how I use “Use Case Diagrams” on my projects: https://www.danikahil.com/2019/09/model-your-dynamics-365-solution-use.html

3. Key Success Factors: Key success criteria act as rail guards to help you stay on track during the “Project Delivery”. The following 2 methods can help you when defining Key Success Factors. 
EMPATHISE

4. Interviews with Key Users:
  • User Shadowing sessions: Observation allows you to watch someone at work in their normal environment and see what they actually do, not what that person consciously thinks to tell you during a workshop. To read more about how I run “User Shadowing sessions”: https://www.danikahil.com/2019/11/elicit-dynamics-365-requirements-using.html
  • User Journey & pain points: A User Journey shows the user’s experience and pain points as the user performs a specific business process using the current tools.
DEFINE & IDEATE

5. Requirement validation workshops: Requirement validation workshops are sessions where we work together as a team to get to a shared understanding of requirements. Below are the topics I cover during a “Requirement validation workshops”:
  1. Validate Key Success Factors: Remind the audience about the Key Success Factors and validate that they are still up to date.
  2. Validate Conceptual Diagram: Collaboratively build the Conceptual Diagram during each workshop. You can start with a whiteboard and sticky notes for the first diagram. Refine the diagram after each workshop. More on why and how I use Conceptual Diagrams: https://www.danikahil.com/2019/11/model-your-dynamics-365-solution-part-3.html
  3. Requirements validation using Scenarios & Stories: When discussing requirement details, I use stories so that people can relate to them. It will help them imagine the situation which leads to better understanding of the idea and ultimately better contribution. More on “Getting Buy-In using stories”. https://www.danikahil.com/2020/06/getting-buy-in-of-your-dynamics-365_14.html
  4. Demos & Proof Of Concepts of Dynamics / Power Platform: I take the opportunity to demo Dynamics 365 and Power Platform during workshops. I often use a Proof Of Concept to discuss a particular requirement to validate assumptions and solution ideas. 
PROTOTYPE:

6. Prototype and Mock-ups of Forms and Business Process Flow: Prototyping during your Dynamics 365 or Power Platform engagement is extremely valuable as it will give you the ability to test your thinking and design ideas with real users. No matter how much time you spend analysing and writing specs, many people find it difficult to truly conceptualize something until they have seen it. I usually prototype complex Forms, Business Process Flows and Dashboards. More info about how I prototype: https://www.danikahil.com/2020/03/the-power-of-prototyping-during-your.html

TEST:

7. Proof Of Concepts: Use a “sandbox” environment of Dynamics 365 and the Power Platform as Proof Of Concept to validate solution ideas. Important to remember that Proof of Concepts are not ready-made solutions that you can directly reuse during your project delivery. They are requirements specific and are only used to validate assumptions and solution ideas during workshops.

<< Loop through steps 5, 6, and 7 for each of your main workshops >>

8. Closing Presentation: This is the final presentation where the outcome of the “Project Envisioning” is presented. The main deliverables are:
  1. The Key Success Factors with KPI if possible.
  2. A Conceptual Diagram representing the main features of the solution.
  3. An Architecture Diagram if multiple systems need to integrate with each other.
  4. A summary of the “Product Backlog” categorized by Epics, Features, User Stories and sometimes Tasks with estimates at the Feature or User Story level.
  5. A Project Roadmap: That shows the releases of Features and Epics over time.