A Wicked Problem Case Study

This blog posting will make more sense to you if you have a basic understanding of wicked problems.

On a recent client engagement we received a statement of work (from the IT department) to replace an existing proprietary system. This system was brought into the company via an acquisition of another organization several years ago.  It was a document management solution that housed only Adobe PDF files, and made custom web service calls to allow people to comment on PDFs within the browser and to sign off on their tasks. Over the years the application had become buggy (the web service calls would fail after Windows updates were run on workstations) and there was no internal knowledge to support the application anymore, which resulted in IT performing registry hacks on end user workstations so the application would work again.

As you can imagine, there was not a lot of confidence by end users in the system, so they worked around the system by storing their comments in Office files (word or excel) outside the system.  The process this system was enabling involved the merchandising, regulatory and legal departments and played a major role in their product development life cycle to ensure they hit their launch dates and got product in the stores.

Finding the Underlying Problem

When we began talking with the merchandising group, they thought by replacing this system they could cut the product development life cycle by 2-3 months, resulting in launching products sooner.  I asked, “How long is the typical development cycle?”  They said around 9-12 months (so that would be a big reduction in cycle time).  We took a look at the database to see the average time a document took to get approved, and the results were 42 days.  Hmm, the business thought they could reduce a process by 2-3 months by replacing an existing system, but the process averaged only 42 days to complete.

This tidbit changed the way we needed to attack the project.  We could not just run with what IT brought us in to do – create a new application in SharePoint to replace the existing one – because the business would not gain the benefit they wanted, which was to be able to launch more products in less time (shorten the development life cycle).

We were now stepping into a learning problem domain, rather than a knowing problem domain. From the book, “Dialogue Mapping, Building Shared Understanding of Wicked Problems” by Jeff Conklin, “with a knowing problem, the problem is clear to all participants and even though it might require specialist expertise to solve, many of the variables are well understood.  With a learning problem:

1. People will examine potential solutions just to explain the problem.
2. Each instance of examining the solution will impact the understanding of the problem.”

Creating the Strategic Pathway

Since the project was going to go in a new direction, I needed to be able to uncover how this project could tie to the strategic goals of the organization.  I began by reading through their annual report to gather their strategic objectives, and then met with the Director of merchandising to get a quick verification of my assumptions.

To communicate how the project would help meet the goals, I utilized the Kapitola Pathway technique (documented by Paul Culmsee and Kailash Awati in their book entitled, “The Heretic’s Guide to Best Practices“, which I showcase in the video below:

Understanding the Unique Factors

Breakthrough Thinking, a problem structuring technique, utilizes seven principles to work through problems.  The uniqueness principle assumes initially that the problem, issue or opportunity is different.  Just because one organization solves a problem in a certain way, it does not mean that the same solution will apply elsewhere.  This principle recognizes that despite superficial similarities, every problem is embedded in a unique context of people, culture, issues, opportunities and constraints.

This company had a few unique factors to consider:

1. They do not manufacture their products.  The company hires vendors to manufacture their products.  One of the major roles of a brand manager (the person responsible for bringing the product to market) is to manage the vendors to a timeline to ensure they launch their product on time.
2. Each brand manager used their own Excel spreadsheet to track projects.  This led to a lack of visibility for management and constant requests from the director to her brand managers for updates of where things stand.
3. High volume of products.  Brand managers bring more than 400 products to market a year, so they are managing numerous vendors and products at one time.  Being able to improve visibility into the process was imperative.
4. New brand managers took a while to get up to speed.  The lack of standard processes and visibility into how you were performing posed challenges when new brand managers would come on board – meaning it took longer for a brand manager to be effective in their job.
5. Lack of Collaboration.  With the lack of visibility into the development life cycle, and working several products at one time, collaboration both within the merchandising department (between brand managers) and between departments (merchandising, regulatory, legal) resulted in a lot of “fire-storms” to put out emergencies and rush products through the process to not miss launch dates.

Project Fragmentation

We met with each respective department and it was obvious that depending on who you asked, you would receive a different viewpoint as to what the problems were that prevented the groups from working together better.  The group was having trouble presenting ideas of how to improve the situation, but did not have a problem in stating what was currently wrong.

To get the groups to begin seeing each other’s point of view, we ran a 2 hour workshop incorporating the Speedboat innovation game.  This helped the team understand how each group worked, and what was holding the process back from being as efficient as possible from the other department’s perspective.  We documented the findings and labeled each finding as green (yes), yellow (possibly), or red (no) to indicate whether SharePoint could improve the current situation.

We were doing this to help set the expectations that technology alone would not address the problem.  The groups of people were going to have to change the way they worked to improve the process as well.  With an understanding of why it was important (via our strategic pathway), and a better understanding of how each group worked, everyone could see why change was needed.

Examining the Product Development Life cycle

The next step in the project was to begin dialogue around the product development life cycle.  Here, the management of the company did a wonderful thing – they gave the work back by placing it where it belonged – to the people who are impacted by the problem.  This approach to leadership is discussed in the book, “The Practice of Adaptive Leadership: Tools and Tactics for Changing Your Organization and the World” by Ronald A. Heifetz, Marty Linsky, and Alexander Grashow.

4 brand managers were tasked to analyze the current way they worked and come up with a way to improve it.  The brand managers were a key stakeholder of this project – they are the ones that own the problem.  The brand manager is responsible for bringing products to market on time and on budget.  Since they perform the work every day, they knew the problem the best.   I utilized dialogue mapping to track some of the dialogue and we worked our way through documenting the life cycle and coming to agreement on key tasks that every brand manager should track, and how long those tasks should take.  It was also determined that brand managers would need the ability to add tasks in an ad-hoc manner depending on the unique circumstances of their products and vendors.

Brand managers were forming a shared commitment to addressing the problems.  Buy-in to changing the way you work was emerging as we progressed with the project since the stakeholders were learning more about the problem as they were examining ways to improve it.  They were owning the problem.  This mindset would help to ensure the new system would be utilized to help brand managers do their jobs better.

Creating Shared Understanding

The process we went through, focusing on iterative dialogue among all stakeholders, helped the company identify the key underlying problem, a lack of visibility into the entire Product Development Life cycle.

The stakeholders gained a shared understanding of how each grouped viewed the problem, we worked through why coming to a better way of work was important to the company, we understood the unique characteristics of the organization, and the key stakeholders – the ones who will use the system every day to do their jobs – gained a shared commitment to make the changes necessary to improve the business.

As a result, in addition to building an application to replace the existing proprietary system (which focused on one process within the product development life cycle), we ended up building another application to track products throughout the entire life cycle, something the company never had before.

By understanding the dynamics of wicked problems, we were able to take a different path on this project than we would have before.  We understood the proper approach to utilize to tackle the problem.  We were able to facilitate the client to a shared understanding of their problem, and a shared commitment to the solution.

Resources to Learn More about Wicked Problems

I wrote this blog post to provide a real-world example of the important lessons I learned after attending the SharePoint Governance and Information Architecture class by Paul Culmsee, and more recently through his book, “The Heretics Guide to Best Practices” which was co-authored by Kailash Awati.    Their book provides a central resource to learn more about these techniques, the history behind them, and why they work.

I feel very strongly these techniques can help the SharePoint community provide more value to our clients, and provide better solutions.  I am excited to see some of the most respected SharePoint professionals (Michal Pisarek, Andrew Woodward, Ruven Gotz, Ant Clay) writing about their experiences utilizing these approaches.  For a great description of problem domains, also look at the Cynefin Framework (You Tube) or the  management article on Harvard Business Review.

As always your questions, suggestions, or comments are valued.