Category: system lifecycle

Design Lifecycle within PDCA – Planning

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, a refresher

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.

PDCA cycle driving continuous improvement

Design Lifecycle

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.

Design Lifecycle

Identifying the Problem (Plan)

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.

Understanding the needs of the organization

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.

Identifying the Problem

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 Elicitation

Requirement Analysis

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.

Design the Solution

Building for the solution includes change management. Any solution focuses both on the technical, the organization and the people.

Ensure you leverage risk management.

Change Management Approach

The Place of Empathy

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.

Prepare for Startup

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.

Review of Process/Procedure

Review of documents are a critical part of the document management lifecycle.

Document Lifecycle

In the post Process/Procedure Lifecycle there are some fundamental stakeholders:

  • The Process Owner defines the process, including people, process steps, and technology, as well as the connections to other processes. They are accountable for change management, training, monitoring and control of the process and supporting procedure. The Process Owners owns the continuous improvement of the overall process.
  • Quality is ultimately responsible for the decisions made and that they align, at a minimum, with all regulatory requirements and internal standards.
  • Functional Area Management represents the areas that have responsibilities in the process and has a vested interest or concern in the ongoing performance of a process. This can include stakeholders who are process owners in upstream or downstream processes.
  • A Subject Matter Expert (SME) is typically an expert on a narrow division of a process, such as a specific tool, system, or set of process steps. A process may have multiple subject matter experts associated with it, each with varying degrees of understanding of the over-arching process.

A Risk Based Approach

The level of review of a new or revised process/procedure is guided by three fundamental risk questions:

  • What might go wrong with the associated process? (risk identification)
  • What is the likelihood that this will go wrong? (risk analysis)
  • What are the consequences? How severe are they if this goes wrong? (risk analysis)

Conducting risk identification is real about understanding how complicated and complex the associated process is. This looks at the following criteria:

  • Interconnectedness: the organization and interaction of system components and other processes
  • Repeatability: the amount of variance in the process
  • Information content: the amount of information needed to interact with the process

What Happens During a Review of Process and Procedure

The review of a process/procedure ensures that the proposed changes add value to the process and attain the outcome the organization wants. There are three levels of review (which can and often do happen simultaneously):

  • Functional review
  • Expert review by subject matter experts
  • Step-by-step real-world challenge

Functional review is the vetting of the process/procedure. Process stakeholders, including functional area management affected by the change has the opportunity to review the draft, suggest changes and agree to move forward.

Functional review supplies the lowest degree of assurance. This review looks for potential impact of the change on the function – usually focused on responsibilities – but does not necessarily assures a critical review.

In the case of expert review, the SMEs will review the draft for both positive and negative elements. On the positive side, they will look for the best practices, value-adding steps, flexibility in light of changing demands, scalability in light of changing output targets, etc. On the negative side, they will look for bottlenecks in the process, duplication of effort, unnecessary tasks, non-value-adding steps, role ambiguities (i.e. several positions responsible for a task, or no one responsible for a task), etc.

Expert review provides a higher degree of assurance because it is a compilation of expert opinion and it is focused on the technical content of the procedure.

The real-world challenge tests the process/procedure’s applicability by challenging it step-by-step in as much as possible the actual conditions of use. Tis involves selecting seasoned employee(s) within the scope of the draft procedure – not necessarily a SME – and comparing the steps as drafted with the actual activities. It is important to ascertain if they align. It is equally important to consider evidence of resistance, repetition and human factor problems.

Sometimes it can be more appropriate to do the real-world test as a tabletop or simulation exercise.

As sufficient reviews are obtained, the comments received are incorporated, as appropriate. Significant changes incorporated during the review process may require the procedure be re-routed for review, and may require the need to add additional reviews.

Repeat as a iterative process as necessary.

Design lifecycle

The process/procedure lifecycle can be seen as the iterative design lifecycle.

Design Thinking: Determine process needs.

  • Collect and document business requirements
  • Map current-state processes.
  • Observe and interview process workers.
  • Design process to-be.

Startup: Create process documentation, workflows, and support materials. Review and described above

Continuous Improvement: Use the process; Collect, analyze, and report; Improve

Phase Appropriate GMPs

Throughout the regulations and guidances you will find something like this: “As with other aspects of the development program, documentation may be ‘less vigorous’ in early phases, but ‘they would still need to be adequate in order to allow for traceability of the manufacturing process.'”

Agencies, like the FDA, have consistently stated that phase 1 is less vigorous but starting in phase 2 you are fully GMP. These regulations are meant to ensure basic safety and documentation standards are met in the manufacture and testing of phase 1 clinical trial material and to encourage the design of quality into the process. It is expected that enhanced process controls and GMP standards will be employed as the material transitions into later clinical stages.

With the speed of development, and the fact early phase material can support commercialization, this phased in approach is an important balancing act in advanced therapeutics like cell and gene therapy.  It is crucial that manufacturers of phase 1 clinical trial material assess potential risks associated with their manufacturing process, facilities, equipment, methods, materials, etc. and the associated impact of these risks on the safety and quality of the material. All significant risks should then be mitigated, and appropriate controls implemented to reduce potential adverse impact for the patients and data generated.

Recognizing the difference between the elements of a strong quality system and what is needed for GMPs. Folks often confuse the two and have difficulties maturing quickly. The stuff in the orange? That’s system and is not GMP dependent.

Some GMP, such as clean room controls or starting materials controls should be robust from the beginning. Others, such as cleaning validation, are developed as you move through the phases.

Process Owners

Process owners are a fundamental and visible difference part of building a process oriented organizations and are crucial to striving for an effective organization. As the champion of a process, they take overall responsibility for process performance and coordinate all the interfaces in cross-functional processes.

Being a process owner should be the critical part of a person’s job, so they can shepherd the evolution of processes and to keep the organization always moving forward and prevent the reversion to less effective processes.

The Process Owner’s Role

The process owner plays a fundamental role in managing the interfaces between key processes with the objective of preventing horizontal silos and has overall responsibility of the performance of the end-to-end process, utilizing metrics to track, measure and monitor the status and drive continuous improvement initiatives. Process owners ensure that staff are adequately trained and allocated to processes. As this may result in conflicts arising between process owners, teams, and functional management it is critical that process owners exist in a wider community of practice with appropriate governance and senior leadership support.

Process owners are accountable for designing processes; day-to-day management of processes; and fostering process related learning.

Process owners must ensure that process staff are trained to have both organizational knowledge and process knowledge. To assist in staff training, processes, standards and procedures should be documented, maintained, and reviewed regularly.

Process Owners should be supported by the right infrastructure. You cannot be a SME on a end-to-end-process, provide governance and drive improvement and be expected to be a world class tech writer, training developer and technology implementer. The process owner leads and sets the direction for those activities.

The process owner sits in a central role as we build culture and drive for maturity.

Sensemaking, Foresight and Risk Management

I love the power of Karl Weick’s future-oriented sensemaking – thinking in the future perfect tense – for supplying us a framework to imagine the future as if it has already occurred. We do not spend enough time being forward-looking and shaping the interpretation of future events. But when you think about it quality is essentially all about using existing knowledge of the past to project a desired future.

This making sense of uncertainty – which should be a part of every manager’s daily routine – is another name for foresight. Foresight can be used as a discipline to help our organizations look into the future with the aim of understanding and analyzing possible future developments and challenges and supporting actors to actively shape the future.

Sensemaking is mostly used as a retrospective process – we look back at action that has already taken place, Weick himself acknowledged that people’s actions may be guided by future-oriented thoughts, he nevertheless asserted that the understanding that derives from sensemaking occurs only after the fact, foregrounding the retrospective quality of sensemaking even when imagining the future.

“When one imagines the steps in a history that will realize an outcome, then there is more likelihood that one or more of these steps will have been performed before and will evoke past experiences that are similar to the experience that is imagined in the future perfect tense.”

R.B. MacKay went further in a fascinating way by considering the role that counterfactual and prefactual processes play in future-oriented sensemaking processes. He finds that sensemaking processes can be prospective when they include prefactual “whatifs” about the past and the future. There is a whole line of thought stemming from this that looks at the meaning of the past as never static but always in a state of change.

Foresight concerns interpretation and understanding, while simultaneously being a process of thinking the future in order to improve preparedness. Though seeking to understand uncertainty, reduce unknown unknowns and drive a future state it is all about knowledge management fueling risk management.

Do Not Ignore Metaphor

A powerful tool in this reasoning, imagining and planning the future, is metaphor. Now I’m a huge fan of metaphor, though some may argue I make up horrible ones – I think my entire team is sick of the milk truck metaphor by now – but this underutilized tool can be incredibly powerful as we build stories of how it will be.

Think about phrases such as “had gone through”, “had been through” and “up to that point” as commonly used metaphors of emotional experiences as a physical movement or a journey from one point to another. And how much that set of journey metaphors shape much of our thinking about process improvement.

Entire careers have been built on questioning the heavy use of sport or war metaphors in business thought and how it shapes us. I don’t even watch sports and I find myself constantly using it as short hand.

To make sense of the future find a plausible answer to the question ‘what is the story?’, this brings a balance between thinking and acting, and allows us to see the future more clearly.

Bibliography

  • Cornelissen, J.P. (2012), “Sensemaking under pressure: the influence of professional roles and social accountability on the creation of sense”, Organization Science, Vol. 23 No. 1, pp. 118-137, doi: 10. 1287/orsc.1100.0640.
  • Greenberg, D. (1995), “Blue versus gray: a metaphor constraining sensemaking around a restructuring”, Group and Organization Management, Vol. 20 No. 2, pp. 183-209, available at: http://doi-org.esc-web.lib.cbs.dk:8443/10.1177/1059601195202007
  • Luscher, L.S. and Lewis, M.W. (2008), “Organizational change and managerial sensemaking: working through paradox”, Academy of Management Journal, Vol. 51 No. 2, pp. 221-240, doi: 10.2307/20159506.
  • MacKay, R.B. (2009), “Strategic foresight: counterfactual and prospective sensemaking in enacted environments”, in Costanzo, L.A. and MacKay, R.B. (Eds), Handbook of Research on Strategy and Foresight, Edward Elgar, Cheltenham, pp. 90-112, doi: 10.4337/9781848447271.00011
  • Tapinos, E. and Pyper, N. (2018), “Forward looking analysis: investigating how individuals “do” foresight and make sense of the future”, Technological Forecasting and Social Change, Vol. 126 No. 1, pp. 292-302, doi: 10.1016/j.techfore.2017.04.025.
  • Weick, K.E. (1979), The Social Psychology of Organizing, McGraw-Hill, New York, NY.
  • Weick, K.E. (1995), Sensemaking in Organizations, Sage, Thousand Oaks, CA.