Transformations are large, complex, and lengthy, and most of the more visible changes will depend on massive redesigns to customer journey, technical solutions, existing processes, and/or a number of other changes that will only come later. However, if you are to build excitement and momentum across the organization, you can’t afford to wait that long.
When your teams start developing their plans, they need to think about securing early wins in the initial months of the program. These don’t need to be big. They could be pilots or prototypes for parts of a process change, a new approach to an old problem, a mock-up for a new app. You must feed small victories to your organization to build momentum and increase the organization’s confidence in your vision.
When left alone, workstream teams usually find it challenging to come up with early wins. Oftentimes they feel overwhelmed just thinking about the larger plan and don’t want to deal with what they consider to be distractions. However, those “distractions” are essential to ensure they are on the right track.
They are the difference between testing and getting feedback on paper vs. waiting for the coding to be fully completed and functional; it is days of prototyping vs. months of development, it is hundreds of dollars vs. thousands or even millions. The earlier you get the feedback from the users, the more targeted your teams will be at designing the solutions. And the more targeted they are, the faster and cheaper your company’s efforts will become.
How do you help teams think about early wins?
There are several ways to generate ideas for these early wins. The most popular one is the brainstorming session, which I am sure you’ve already participated in. In those sessions, your team collaborates to generate ideas, building on each other's contributions while holding back judgment. Brainstorming may work under the right circumstances and with the right moderator, but more often than not, it falls short. Such sessions are often short and are held in the middle of the workday; it is not uncommon for employees in those sessions to struggle to add value because they lack understanding of the bigger context.
Thankfully, there are superior approaches to brainstorming that you should consider, including Design Thinking and Design Sprint.
Design Thinking is a methodology that focuses the problem solving on the final user for which the solution is being created, be it a customer, vendor, department, or employee. It is usually a longer process that starts by researching the end user through interviews and observations to really understand the problems that need to be solved (even when the users find it hard to articulate them). Once the user’s needs and problems are clearly defined, ideation, prototyping, and testing for feedback follow. It is a highly interactive and non-linear process to bring innovative solutions to life based on how end users think, feel, and act.
Design Sprint or Google Sprint, as the name already suggests, was developed by Google and is a 5-day process designed for answering critical business questions with the end users in mind. It is a much more streamlined and structured process with clear deliverables for each of the weekdays: it starts with mapping out the problem and choosing the focus area, followed by ideation, prioritization, prototyping, and testing for feedback. And did I mention it only takes 5 days?
Both Design Thinking and Design Sprint focus the team’s efforts immediately on the end users. Both are highly collaborative, leverage people from different departments, and build on the idea of rapid problem solving and interactions with the objective of developing a testable prototype to solicit feedback from end users.
How are they different? For starters, Design Thinking is a much longer and more involved methodology (we are talking about months) than the 5-day process from Design Sprint. But that time investment also brings insights that can help you address or even redefine problems in a much deeper way. Design Thinking is also much more interactive and non-linear, while Design Sprints follow a prescribed time-bound recipe.
Which one should you choose?
It depends on the situation. If you have a large, complex situation with a broad scope for which you are trying to define the question and come up with potential solutions, you should consider Design Thinking. It may take you longer to iterate and finish the process, but it will bring you unprecedented clarity and insights.
However, if you already have a very clear and well-defined question in mind and face a time constraint, then Design Sprint is definitely the better option. You can have meaningful progress and direction quickly and with very limited investment.
How should you implement the chosen methodology?
Because the early success of your effort is at stake, I strongly encourage you to hire an expert in your chosen methodology to run the sessions. They will more than pay for themselves by running great sessions with your key leaders.
How about Agile?
Agile is not a problem solving approach; instead, it is a fantastic project management methodology that you should learn and embrace. It was created as an alternative to the traditional (and more rigid) waterfall approach and encourages concurrent work, interaction with stakeholders, and flexibility to adjust scope even late in the game. Instead of long timelines, teams are encouraged to break their work into smaller sprints with mini deliverables.
Once you answer your questions using either Design Thinking or Design Sprint, then you should execute the solution using an Agile methodology.
CEOs and transformation leaders must ensure that their teams are thinking about both short and long term deliverables. Also, by using the right problem solving methodology, your early wins will give you amazing insights about the final product you need to build all while creating momentum by demonstrating tangible wins to your organization.
Comments