» Lire en français: French
Organizational life, and indeed the world, is full of complex, poorly defined, so called “ill-structured” problems that need solving. While teams have a variety of tools to choose from to help tackle these problems, those tools invariably fail to address both the challenges of working collaboratively and of addressing the specific problem at hand.
8 min read
Now, though, Hazbi Avdiji, Dina Elikan, Stéphanie Missonier and Yves Pigneur, academics at HEC Lausanne, have devised three fundamental design principles which can be used by managers and their teams to create tools that aid collaborative problem-solving tailored to a specific ill-structured problem.
In the modern volatile and uncertain business environment, many of the challenges that organizations face are complex, messy, and intangible. These poorly defined problems are often described as ill-structured problems. Difficult to frame, ill-structured problems have no “right” solution, or clearly identified end state. Instead there are multiple routes to a solution, a solution may take on numerous forms, many stakeholders may be involved, and there is often disagreement on the best way to proceed.
These types of problems occur at multiple levels: at a global level, (e.g. tackling climate change); organizational eco-system level, (e.g. adapting city infrastructure to population growth); and organizational level, (e.g. determining the best way of operating for the future). And, because of their complexity, dealing with these types of problems frequently involves the cooperation of teams. In an organization, for example, management problems are often tackled by teams of individuals drawn from a wide variety of functions and disciplines.
Teams need the right tools
Invariably these teams use a variety of tools to aid problem solving. These tools help with information sharing, idea generation, task direction, collective understanding and motivating participation and cooperation, for example.
Some of the most important types of tools in this context are tools that help teams with the essential but often difficult process of collaboration. These tools help teams build and manage a shared understanding, facilitating communication, the exchange of information, and coordination between individuals. However, these collaboration tools are not designed to solve specific management problems.
The demand for tools that aid collaboration and help solve specific ill-structured problems has led to the recent creation of a new generation of tools designed to combine collaboration support with a focus on management problems. However, the drawback with many of these tools, given their critical importance in helping to optimally frame and effectively solve problems, is that they tend to be designed by practitioners, not rooted in evidence-based academic research, and not comprehensively tested and evaluated prior to development or in use.
Consequently, the authors decided to use their analysis of two tools that do combine collaboration with specific problem solving and have a sound academic underpinning, to create design principles that would allow organizations to develop similar tools in the future.
The tools that the team analyzed were: the Business Model Canvas, for the ill-structured problem of business model development, which has been used by over five million people globally, and referenced by more than 5,000 academic studies; and the Team Alignment Map, developed in June 2016, that has attracted more than 400 requests for proposals and training.
Although designed by different teams, to solve different problems, the two tools have a number of common characteristics. For example, both tools are collaborative, address specific ill-structured management problems, were part of design science projects and involved end users in the design and evaluation process.
Three Key Design Principles
The analysis of these two tools confirmed the significance of three key design principles that could be used to inform future development of tools to support collaborative solving of specific ill-structured problems.
Design principle 1: Develop an ontology identifying the main components of the problem and the relationships between those components.
In order to try and solve an ill-structured problem collaboratively, the problem needs to be presented in a way that enables productive and focused discussion.
The first step in designing an appropriate collaborative tool is developing an ontology for the problem. In other words: to identify the key concepts that the problem involves and the relationships between those concepts; produce precise and unambiguous text definitions for the concepts and their relationships; and identify terms that can be used to refer to the concepts and relationships.
This provides the basis for a common “language” and understanding to improve communication between stakeholders when addressing the specific problem. Identifying a number of components of the problem subject area provides structure to a problem when none is apparent, a unifying framework of elements to be considered during problem solving activities.
This initial design step requires considerable effort and inquiry. In the case of the Business Model Canvas, for example, its ontology was based on an extensive literature review of the dimensions involved in business modeling. While the ontology for the Team Alignment Map drew on well-developed academic theory of team collaboration. There must also be rigorous development and thorough testing – assessing for consistency, completeness, and conciseness, for example – to ensure that a problem is correctly represented.
Design principle 2: Translate the ontology into a shared visualization where components are represented as empty spaces and arranged according to their relationships.
Having created an ontology it can be represented as a shared visualization that consists of the identified concepts, structured logically into empty problem spaces. This focuses attention on a common frame and helps to avoid ambiguities either in discussions, or regarding the way the problem is framed and understood between the stakeholders.
Other forms of shared visualization could be used, but the authors’ investigations and feedback from practitioners suggested a form where concepts are depicted as empty spaces, with team members using them as problem spaces in which they can co-design solutions, is optimal.
Design principle 3: Use the visualization as shared support – a problem space on which solutions can be prototyped.
Team members can then use the shared visualization to help co-design a solution to the once ill-structured problem. Co-design is an iterative process of inquiry and co-creation. Team members draw on their diverse knowledge, experience, and insights to generate ideas, in a trial-and-error approach to solving the problem.
In the Business Model Canvas, for example, the shared visualization takes the form of a large poster (the “Canvas”) with nine spaces representing the blocks of the business model. Individuals can use sticky notes to fill the empty spaces in the shared visualization. The benefits of using sticky notes are that they can easily be added, amended, or removed as the group discussion and reflection unfolds.
Test, evaluate, refine, utilize
In proposing the design principles the authors stress the need to test, evaluate, and refine any tool being developed, at each stage, in different settings and contexts, incorporating feedback from practitioners and facilitators. They also emphasize the need to include all three key design principles.
With the development of these three key design principles, management teams finally have a thoroughly tested method for designing tools to help frame and collaboratively solve whatever ill-structured problem they hope to tackle (and also structured problems should they want to apply a design thinking approach).
Related research paper:
Avdiji, H., Elikan, D., Missonier, S. and Y. Pigneur (2018). “Designing Tools for Collectively Solving Ill-Structured Problems” in Proceedings of the Fifty First Hawaii International Conference on System Sciences (HICSS), pp. 400-409.