The flow chart is a simple, but important, graphic organizer. Placing the states or steps of an event or process into the correct sequence allows you to reach conclusions and make predictions.
However, its simplicity means we don’t always work to be consistent and can benefit from a little effort to ensure users are aligned.
I am a huge fan of including flow charts in all process and procedure documents.
Steps for Building a flow chart
Capture
Capture the events or steps of the process. Resist the urge to arrange them sequentially and concentrate on capturing the events/steps only.
Cull
If there are more than eight steps in a flow chart we start creating cognitive overload. If a process or procedure has more than eight steps you need to:
Ensure the steps are at the right level, sometimes we have substeps represented and we can cull that. Ensure they are all on the same level of process/procedure/task.
Decide we need to break the procedure into multiple documents. This is a great way to decide what work instructions are necessary.
Look for opportunity for process improvement.
Sequence the events and draw the flow chart
The focus now shifts to temporal relations. The correct sequential arrangements of steps or events helps to reach conclusions about past events and prepare for future events.
Example
I’m writing the procedure for my mornings, I capture the following:
Eat breakfast
Take shower
Take dog out
Get dressed
Decide on tea
Heat water
Drink tea
Read for 30 minutes
Deal with morning email
Snuggle with dog
Taking a look at the list I realize that not everything is on the same level of process/procedure/task and end up with a shorter list.
Breakfast
Take shower
Take dog out
Get dressed
Read for 30 minutes
Deal with morning email
Snuggle with dog
Notice how I combined all the tea stuff into a breakfast category. When brainstorming my list I put a lot of weight on tea, because it is important to me (yes I have been using tea as a training example since 2005, I just love tea).
I can then put them in sequence:
Flow Chart for my morning
When I was making things sequential I realized that two of my activities (read and dog snuggle) were concurrent, so I combined them as one step.
Process drives the work we do. We can evaluate processes on two axis – complexity and strategy – that help us decide the best way to manage and improve the processes.
Process by Complexity and Strategy
Process complexity and dynamics are what types of tasks are involved in the process. Is it a simple, repetitive procedure with a few rules for handling cases outside of normal operation? Or is it a complex procedure with lots of decision points and special case rules? Think of this like driving somewhere. Driving to your local grocery is a simple procedure, with few possibilities of exceptions. Driving across the country has a ton of variables and dynamism to it.
While complexity can help drive the decision to automate, I strongly recommend that when thinking about it don’t ask if it can be automated, only ask what would be involved if a human were to do the job or how it is done with current technologies. Starting with the answer of automation leads to automation for automation’s sake, and that is a waste.
Dynamics is how much the process changes – some change rarely while others change rapidly to keep pace in response to changes in product or external factors (such as regulations).
Strategic importance asks about the value the process contributes to meeting requirements. Is the process a core competency, or an enabling process that needs to be accomplished to ensure that you can do something else that meets the core requirements? Needless to say, one company’s strategic process is another company’s routine process, which is why more and more we are looking at organizations as ecosystems.
Processes are in a hierarchy, and we use levels to describe the subdivision of processes. We’ve discussed the difference between process, procedure and task. At the process level we usually have the high-level process, the architecture level, which are the big things an organization does (e.g. research, manufacture, distribute), mid-level processes that are more discrete activities (e.g. perform a clinical study) to even more discrete processes (e.g. launch a study) which usually have several levels (e.g. select sites, manage TMF) to finally procedure and task.
Level of Process
Includes
Key Ways to Address
High-Level Process
How key objectives are met, highly cross functional
To truly get to this level of understanding of process, we need to understand just what our process is, which is where tools like the SIPOC or Process Scope diagram can come in handy.
Process Scope Diagram
To understand a process we want to understand six major aspects: Output, Input, Enablers, Controls, Process Flow, People.
Simple processes usually follow a consistent, well-defined sequence of steps with clearly defined rules. Each step or task can be precisely defined, and the sequence lacks branches or exceptions.
More complicated processes involve branches and exceptions, usually draw on many rules, and tend to be slightly less defined. Complicated processes require more initiative on the part of human performers.
Complex processes are ones that require a high level of initiative and creativity from people. These processes rapidly change and evolve as time passes. Successful performance usually requires a connection to an evolving body of knowledge. They are highly creative and have a large degree of unpredictability. Most complex processes are viewed at the system level.
Sources
Benedict, T. et al. BPM CBOK Version 4.0: Guide to the Business Process Management Common Body of Knowledge. ABMP International, 2019.
Harmon, Paul. Business Process Change. Morgan Kaufmann, 2019.
Nuland, Y. and Duffy, G. Validating a Best Practice. Productivity Press, 2020
Written procedures with their step-by-step breakdown are a fundamental tool for ensuring quality through consistent execution of the work. As a standardized guideline for tasks, procedures serve many additional purposes: basis of training, ensuring regulatory requirements are met, ensuring documentation is prepared and handled correctly.
As written prescriptions of how work is to be performed, they can be based on abstract and often decontextualized expectations of work. The writers of the procedures are translating Work-as-Imagined. As a result, it is easy to write from a perspective of ideal and stable conditions for work and end up ignoring the nuances introduced by the users of procedures and the work environment.
The day-to-day activities where the procedures are implemented is Work-as-Done. Work-is-Done is filled with all the factors that influence the way tasks are carried out – spatial and physical conditions; human factors such as attention, memory, and fatigue; knowledge and skills.
Ensuring that our procedures translate from the abstraction of Work-as-Imagined to the realities of Work-as-Done as closely as possible is why we should engage in step-by-step real-world challenge as part of procedure review.
Work-as-Prescribed gives us the structure to take a more dynamic view of workers, the documents they follow, and the procedural and organizational systems in which they work. Deviations from Work-as-Prescribed point-of-view are not exclusively negative and are an ability to close the gap. This is a reason to closely monitor causes such as “inadequate procedure” and “failure to follow procedure” – they are indicators of a drift between Work-as-Prescribed and Work-as-Done. Management review will often highlight a disharmony with Work-As-Imagined.
The place where actions are performed in real-world operations is called, in safety thinking, the sharp-end. The blunt-end is management and those who imagine work, such as engineers, removed from doing the work.
Our goal is to shrink the gap between Work-as-Imagined and Work-as-Done through refining the best possible Work-as-Prescribed and reduce the differences between the sharp and the blunt ends. This is why we stress leadership behaviors like Gemba walks and ensure a good document change process that strives to give those who use procedure a greater voice and agency.
A task is the steps for doing a particular piece of work.
Procedure are activities made up of a series of tasks.
A process is an upper level description of a series of activities required to accomplish an objective. Processes are made up of procedures or tasks. They have inputs and outputs.
Process
Procedure
Task
Flow of sequences of activities that transform input elements into results
Specific and required way to carry out a process
Describe the correct steps to perform a specific task
What we do By Whom Where it takes place When it happens
How the work must be performed
How to accomplish a specific task within a process with very detailed directions
Orchestration the work
Mandatory method
Mandatory guidance
Can link to 0, 1 or more procedures
It may consist of 0, 1 or more task instructions
Focus on the instructions of 1 task
Transversal by business units
Cross functional or only 1 business unit
Only 1 business unit
Participate more than one role
Participate more than one role
Participate only one role
Encapsulates activities
Explains how to do but doesn’t get to all the details of how it is done
All of the detail of all the steps to follow in an activity
Provides the workflow model at the highest level using BPMN
Document with both narrative and images, usually in the form of use cases and workflow diagrams
Document with the maximum detail that explains step by step the instructions that must be carried out in an activity
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
Investigations of a Dog 