In the post “Design Lifecycle within PDCA – Planning” I laid out a design thinking approach to planning a change.
Like most activities, the level of effort is commensurate with the level of risk. Above I provide some different activities that can happen based on the risk inherent in the process and problem being evaluated.
This is a great reason why Living Risk Assessments are so critical to an organization.
In the post “Review of Process/Procedure” I mentioned how the document draft and review cycle can be seen as an iterative design cycle. In this post I want to expand on the design lifecycle as a fundamental expression of PDCA that sits at the heart of all we do.
PDCA (and it’s variants) are a pretty tried and true model for process improvement. In the PDCA model a plan is structured in four steps: P (plan) D (do) C (check) A (act). The intention is create a structured cycle that allows the process to flow in accordance with the objectives to be achieved (P), execute what was planned (D), check whether the objectives were achieved with emphasis on the verification of what went right and what went wrong (C) and identify factors of success or failure to feed a new process of planning (A).
Conceptually, the organization will be a fast turning wheel of endlessly learning from mistakes and seeking to maximize processes in order to remain forever in pursuit of strategic objectives, endlessly searching for the maximum efficiency and effectiveness of the system.
This design lifecycle just takes the PDCA spiral and spreads it across time. At the same time it breaks down a standard set of activities and recognizes the stage gates from moving between startup (or experiment) and continuous improvement.
At it’s heart problem-solving requires understanding a set of requirements and building for success.
I always go back to the IEEE definition of “A requirement is a condition or capability needed by a user to solve a problem or achieve an objective; a condition or capability that must be met or possessed by a system or system component to satisfy a contract ,standard, specification , or other formally imposed document; a document representation of condition or capability “
A requirement can be explicitly stated, implicit, inherited or derived from other requirements.
The first place to look for requirements is the organization itself.
The cultural needs of the organization drives the whole problem-solving and requirement gathering activity and it starts by being clear on Strategy and understanding the goals and objectives and how these goals percolate to the different business processes that we are improving. This gives a good starting point to focus on what opportunities to be explored and what problems to be solved.
It is not uncommon in the problem-solving phase that the objectives/needs are not known, so we must work our way through figuring out what the initial need is. Go back to the fundamentals of understanding the business processes “as-is” and review existing regulations, standards, guidelines and other internal sources of requirements followed currently. This is the time to interview stakeholders and go the GEMBA.
We state the problem, and re-frame it. And now we can move on to Requirement Elicitation.
Requirement Elicitation is the process of probing and facilitating the stakeholders to provide more clarity and granular details pertaining to the (usual) high-level requirement gathered so far. This is a discovery process, exploratory in nature, focusing on finding enough details so that a solution can be envisioned and developed. Elicitation is not an isolated activity, and has been happening throughout the process by all the discussion, interaction, analysis, verification and validation up to now.
You should be engaging with knowledge management throughout the cycle, but ensure there is specific engagement here.
It is a progressive process where the requirement clarity ushers in increments and may need multiple rounds of probing/discussions. As the new details are uncovered the requirements are further elaborated and detailed. There are a whole toolbox of elicitation techniques and like any engagement it is important to properly prepare.
Requirement Analysis pertains to extracting the requirement out of the heaps of information acquired from various stakeholders and communicated and turned into documentation in a form that is easily understood by the stakeholders, including the project team. Here we are engaging in requirement refinement, modification, clarification, validation & finalization and engaging in extensive communication.
A requirement can be classified as:
We build for traceability here, so as we build and test solutions we can always trace back to the requirements.
Building for the solution includes change management. Any solution focuses both on the technical, the organization and the people.
Ensure you leverage risk management.
In this design process, we address and use empathy to acquire insight into users’ (stakeholders) needs and inform the design process and create a relevant solution. Using an approach informed by cognitive empathy, we apply different methods to build up that competence and insight, enabling us to prioritize the needs of the users and make the results of the process more desirable.
Psychological safety, reflexivity and sense-making inform our work.
By engaging in Design Thinking we are ready for Startup. Moving through the three steps of:
We have created a plan to execute against. Startup, which can often be Experimentation, is it’s own, future, post.
Interesting perspective on adapting what makes us successful as problem solvers as we move into more senior leadership positions. Resonates very well with some of my own challenges, so I stronly recommend listening to this episode.
Psychological safety enables individuals to behave authentically, take risks and express themselves candidly. In the workplace, psychological safety captures how comfortable employees feel as team members. Timothy Clark gives four elements of psychological safety:
This is done through four pillars:
Reflexivity is the extent employees reflect upon the work tasks they have completed and identify ways of improving performance – it is the information-processing activity. Using reflexivity, employees develop a better sense of what is done, why and how, and can adjust their behaviors and actions accordingly. Reflexivity is a powerful process that can drive performance in a learning culture that requires psychological safety to flourish. When employees reflect upon their work tasks, they need to have a deeper and better understanding of what they have done, what was done well and not as well, why they engaged in these behaviors, and changes and adaptations needed to result in better performance. People are not likely to engage in reflexivity unless they feel psychologically safe to take interpersonal risks, speak up, and admit failures without feeling uncomfortable or fearful of status and image loss.
Psychological Safety is the magic glue that makes transformative learning possible. Psychological Safety and reflexivity enables a problem solving culture.
Clark, T.R. 2020. The 4 Stages of Psychological Safety. Oakland, CA: Barrett-Koehler
Edmondson, A. 2018. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation and Growth. Hoboken, NJ: John Wiley and Sons
West, M.A. 1996. Reflexivity and work group effectiveness: A conceptual integration. In M.A. West (Ed.), Handbook of work group psychology. Chichester, UK: Wiley.
Zak, P.J. 2018. “The Neuroscience of High-Trust Organizations.” Consulting Psychology Journal: Practice and Research 70(1): 45-48
Improvement is a process and sometimes it can feel like it is a one-step-forward-two-steps-back sort of shuffle. And just like any dance, knowing the steps to avoid can be critical. Here are some important ones to consider. In many ways they can be considered an onion, we systematically can address a problem layer and then work our way to the next.
The vague, ambiguous and poorly defined bucket concept called human error is just a mess. Human error is never the root cause; it is a category, an output that needs to be understood. Why did the human error occur? Was it because the technology was difficult to use or that the procedure was confusing? Those answers are things that are “actionable”—you can address them with a corrective action.
The only action you can take when you say “human error” is to get rid of the people. As an explanation the concept it widely misused and abused.
| Attribute | Person Approach | System Approach |
| Focus | Errors and violations | Humans are fallible; errors are to be expected |
| Presumed Cause | Forgetfulness, inattention, carelessness, negligence | “Upstream” failures, error traps; organizational failures that contribute to these |
| Countermeasure to apply | Fear, more/longer procedures, retraining, disciplinary measures, shaming | Establish system defenses and barriers |
Human error has been a focus for a long time, and many companies have been building programmatic approaches to avoiding this pitfall. But we still have others to grapple with.
We like to build our domino cascades that imply a linear ordering of cause-and-effect – look no further than the ubiquitous presence of the 5-Whys. Causal chains force people to think of complex systems by reducing them when we often need to grapple with systems for their tendency towards non-linearity, temporariness of influence, and emergence.
This is where taking risk into consideration and having robust problem-solving with adaptive techniques is critical. Approach everything like a simple problem and nothing will ever get fixed. Similarly, if every problem is considered to need a full-on approach you are paralyzed. As we mature we need to have the mindset of types of problems and the ability to easily differentiate and move between them.
We remove human error, stop overly relying on causal chains – the next layer of the onion is to take a hard look at the concept of a root cause. The idea of a root cause “that, if removed, prevents recurrence” is pretty nonsensical. Novice practitioners of root cause analysis usually go right to the problem when they ask “How do I know I reached the root cause.” To which the oft-used stopping point “that management can control” is quite frankly fairly absurd. The concept encourages the idea of a single root cause, ignoring multiple, jointly necessary, contributory causes let alone causal loops, emergent, synergistic or holistic effects. The idea of a root cause is just an efficiency-thoroughness trade-off, and we are better off understanding that and applying risk thinking to deciding between efficiency and resource constraints.
Our problem solving needs to strive to drive out monolithic explanations, which act as proxies for real understanding, in the form of big ideas wrapped in simple labels. The labels are ill-defined and come in and out of fashion – poor/lack of quality culture, lack of process, human error – that tend to give some reassurance and allow the problem to be passed on and ‘managed’, for instance via training or “transformations”. And yes, maybe there is some irony in that I tend to think of the problems of problem solving in light of these ways of problem solving.
Investigations of a Dog 