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.
Quality 4.0 is Industry 4.0 which is really just:
However, Quality 4.0 is really a lot more than the technology, it is all about using that technology to improve our quality management systems. So Quality 4.0 is really all about understanding that the world around us, and thus the organizations we work in, is full of complex and interconnected challenges and increasingly open systems of communication, and that we can no longer afford to address complex issues as we have in the past. The very simple idea behind Quality 4.0 is that current and future challenges requires thinking that is consistent with a living world of complexity and change.
As such there is nothing really new about Quality 4.0; it is just a consolidation of a lot of themes of change management, knowledge management and above all system thinking.
System Thinking requires quality professionals to develop the skills to operate in a paradigm where we see our people, organizations, processes and technology as part of the world, a set of dynamic entities that display continually emerging patterns arising from the interactions among many interdependent connecting components.
There are lots of tools and methodologies for managing systems. Frankly, a whole lot of them are the same that have been in use in quality for decades; others are new tools. The crucial thing to remember about Quality 4.0 is that it is an additive and transformative way to look at quality, and quite frankly one can go back and read Deming and see the majority of this there.
When I work on systems (which is according to my job description my core function), I keep some principles always in mind.
| Principle | Description |
| Balance | The system creates value for the multiple stakeholders. While the ideal is to develop a design that maximizes the value for all the key stakeholders, the designer often has to compromise and balance the needs of the various stakeholders. |
| Congruence | The degree to which the system components are aligned and consistent with each other and the other organizational systems, culture, plans, processes, information, resource decisions, and actions. |
| Convenience | The system is designed to be as convenient as possible for the participants to implement (a.k.a. user friendly). System includes specific processes, procedures, and controls only when necessary. |
| Coordination | System components are interconnected and harmonized with the other (internal and external) components, systems, plans, processes, information, and resource decisions toward common action or effort. This is beyond congruence and is achieved when the individual components of a system operate as a fully interconnected unit. |
| Elegance | Complexity vs. benefit — the system includes only enough complexity as is necessary to meet the stakeholder’s needs. In other words, keep the design as simple as possible and no more while delivering the desired benefits. It often requires looking at the system in new ways. |
| Human | Participants in the system are able to find joy, purpose and meaning in their work. |
| Learning | Knowledge management, with opportunities for reflection and learning (learning loops), is designed into the system. Reflection and learning are built into the system at key points to encourage single- and double-loop learning from experience to improve future implementation and to systematically evaluate the design of the system itself. |
| Sustainability | The system effectively meets the near- and long-term needs of the current stakeholders without compromising the ability of future generations of stakeholders to meet their own needs. |
In order to be successful utilizing these principles when designing systems and processes we need to keep user at the forefront — striving to be sensitive to the user, to understand them, their situation and feelings: to be more empathetic.
We leverage both the affective component and the cognitive component of empathetic reasoning, in short we need to both share and understand.
We are in short asking 5 major questions:
Think holistically, think empathetically with the user, and ask questions about system behavior. Everything else falls into place from there.
The alternative is messier, but more democratic.
— Read on hbr.org/2018/09/design-thinking-is-fundamentally-conservative-and-preserves-the-status-quo
An interesting article that sums up some of my thoughts and that I definitely need to respond to in more depth.
Investigations of a Dog 