Operations | Process | Resources | Strategy
STAY CONNECTED AND SIGNUP TO RECEIVE INSIGHT updates
Think of a production system and you’ll probably conjure up some kind of assembly line. Whether you imagine humans or machines doing the work, this mental model feels wedded to manufacturing. It needn’t be—production principles are universal.
An airline’s check-in desk is part of a production line. So is the hospital’s procedure for admitting patients. Running scripts in software development is production. As is the sales pipeline that gets software to market. Insurance claims and loan applications? Production systems. And the barista in the café offers a vivid everyday production system—so obvious we almost don’t see it as such.
Perhaps we don’t naturally think of these examples as production environments because they don’t result in physical products that would hurt if you dropped it on your toe. But even the kind of heavy industrial environments we at Ensemble operate in offer plenty of counterintuitive examples, including:
- managing technical service requests in an engineering environment
- processing contractor applications for mobilisation to site
- onboarding employees into vacant project positions
- processing accounts payable and receivable
All these examples are production systems that benefit from a systemic approach. Let’s examine a simple process made up of four steps, each of which is linked to the other. And let’s say the capacity to do work for each step is as shown in the diagram. It doesn’t really matter what the process is, but let’s use technical notifications as an example.
Let’s say that the person at the first work-centre, an inspector, generates 20 notifications per day. The person at the second work-centre has the capacity to assess 14 of those notifications per day. The highly skilled planner can only manage to plan 10 notifications per day and, at the end of the process, back office has capacity to close out 20 notifications per day.
On the demand side, the manager of the process has been told to allow for a regular demand of 10 notifications per day. In the majority of cases, the manager would be looking very closely at costs and would wonder:
Why do I have all this extra capacity? The planner can only handle 10 units per day, so she’s the bottleneck. Yet this capacity perfectly meets demand.
So I’ll scale back the capacity of all the work-centres to 10. This will balance the system to match the demand while reducing costs by removing unneeded extra capacity.
The manager who thinks this way, trying to perfectly balance supply and demand across a connected sequence of steps is in for a nasty surprise. With the newly ‘balanced system’ (all work-centres at 10 capacity), production consistently falls short. Why? The manager discovers that common cause variation means that each of the steps in the process has only a 90% chance of processing their full quota of 10 notifications per day.
By the laws of statistics, the cumulative probability of getting ten completed is reduced to 90% to the power of 4—that is, 90% x 90% x90% x90%—or a cumulative 65%. In other words, almost one in three notifications would not be completed on time. The name of this statistical fact is covariance—when there are individual fluctuations between dependent events.
And of course, over in the real world of the plant, what if equipment failure increases and demand changes? If it’s lower than forecast, we end up with people standing round idle. While if it’s higher than forecast, we delay return to service.
First, find your constraint
If, as per the Theory of Constraints, systems are governed by their constraints, the first thing we must do, is to find the constraint. What’s yours? Do you know? Is it where it is because you’ve designed your value-creation engine to take advantage of the laws of physics? Or are you forever its victim, watching it turn up, unannounced, in a different place every day…like whack-a-mole?
Once we find our constraint, if we want to optimise its performance for value creation. How can we go about doing that?
The TOC approach to managing production systems is called Drum Buffer Rope (DBR). Let’s take a closer look at how Dr Eli Goldratt, the physicist founder of the method came up with such a name.
The constraint in our example is the planner, who can only plan 10 jobs per day. We call this bottleneck resource the drum, because it beats the rhythm of value creation. The power of the solution lies in the fact that a 10% gain at the drum is a 10% gain for the system as a whole. That is, 10% more capacity for the planner means 10% more production for the whole maintenance system. 10% more production for the maintenance system means less downtime, more reliable performance and more throughput. By the same logic, increasing the capacity of a non-constraint by 10% has no positive effect on the system and, in fact, may produce a negative effect by increasing the backlog and stress at the bottleneck.
“A 10% gain at the drum is a 10%
gain for the system as a whole”
In most cases, the value of that gain in throughput dwarfs whatever gain there might be in micromanaging the operating expense of each component part. Moreover, designing your production around your drum lets you use it as a synchronisation tool for the whole—everyone marches to the same drum beat. And, it bears repeating, because by definition everyone has more capacity than the drum, 10% gained at the drum is 10% gained for the system as a whole.
Understanding this requires a mindset shift. Everyone has to play as one band. If the drum is starved because the upstream process was goofing off or produced the wrong component, the whole system loses out. So how do we ensure that the drum never runs out of work? Well, we place a buffer in front of it. This buffer is in effect the stored capacity of the upstream functions. We want to size the buffer so that it’s not so big as to flood the engine with work in progress, but not so small that the drum misses a beat because it’s starved. This is why everyone on the team has to understand the idea of supporting the constraint—their colleagues working at the drum.
To keep the size of the buffer right, we tie a rope to the release of inputs at the entry point to our engine. The buffer is sized to be big enough to accommodate the time it takes from the input step until it is ready to be processed by the drum. As soon as the drum has begun work on the buffer, it gives a tug on the rope to release the next work packet, such that it arrives in good time to keep the whole value-creation engine running smoothly.
And, yes, the rope means that occasionally those working in non-constrained work-centres will be asked to slow down, or even stop work, so as not to flood the engine. This is profoundly counter-intuitive to our natural assumption of what it means to be ‘productive’.
With our drum-buffer-rope system in place, we give our system its best chance of 10 out of 10 performance. At this point, there is no way to squeeze more juice out of the system in its current configuration. If we want to uplift the system now, we need to invest in additional resources. Most organisations jump straight to this step long before they need to—and often with unintended consequences.
Adding another planner at the drum takes the combined uplifted capacity to 20 jobs, which is at first glance more than the plant demands. The internal constraint of the production system has become external. It’s time to find new tasks to which we can put this hitherto hidden capacity. Could we encourage the team to be more proactive in bringing innovation to their work? How might they use the time dividend released to contribute to ensuring that ever shorter turn-times deliver ever more throughput—reliably, on time and at the requisite quality?
Let’s recap the steps to implementing DBR—one of the twentieth century’s least known, but most effective, innovations in productivity:
- Establish your process flow
- Quantify the capacity available at each process step based on the demand for each unit of production
- Find which process step represents the bottleneck to overall process productivity and declare it the ‘drum’
- Establish how long it takes for work to flow from the start of the process to the drum, then create a ‘buffer’ that keeps the drum fed for at least that lead-time
- Develop a mechanism to signal release of the inputs by tying a ‘rope’ from the drum to input release
- Monitor when the drum is running at or near systemic capacity (say 80% of maximum nameplate) and prepare to uplift system capacity and reassign the drum
One final note. It is a tragic truth that most managerial leaders are all too keen to use the productivity gain of DBR to fire people who they believe are now surplus to their requirements. This mindset completely misunderstands the ‘systems thinking’ approach to improving production. Firing people may provide a short-term cost-saving, but is foolish in the medium- and long-term if you want to develop a culture of continuous improvement which, after all, is the only way you can sustainably compete. Why would employees wish to improve production if they knew that in doing so, they would be putting their own jobs at risk?
To accomplish the principles of Just Work—in which everyone has the right to be well-managed—we must rather tap into aspiration and imagination. Do the hard yards of gaining the trust of your workforce to co-create better ways to do better work.
____________________________
The Theory of Constraints offers a new operating system fit for our complex world of change. To learn what that operating system might look like, we invite you to download our Executive Guide to Critical Chain Project Management [PDF].
The change of mindset from standard thinking to Theory of Constraints (TOC) is both profound and exhilarating. To make it both fun and memorable, we use a business simulation. Just as astronauts need a few zero-gravity rides in a special aircraft before they experience the real thing in space, the game simulates the effects of TOC. We call it The Right Stuff workshop and we’d love to run it with you.
____________________________
[Background photo: ‘Coffee smarts’ by Nathan Dumlao on Unsplash]
“Every situation, no matter how complex
it initially looks, is exceedingly simple”
—Eliyahu Goldratt
Understanding the jobs healthcare professionals need to accomplish
Healthcare professional jobs to be done
A clinician checking a monitor is performing an action. The job may be detecting a meaningful change in the patient’s condition soon enough to respond appropriately. A specialist reviewing a report may be trying to decide whether an intervention is suitable, rather than simply consuming more information.
This distinction matters to medical device development. A product can make an action easier while leaving the clinical job difficult or creating additional work elsewhere.
Question 1.1.4 asks how well your organization understands the jobs healthcare professionals are trying to get done. A strong answer describes those jobs from their perspective and uses evidence to identify the outcomes they need to achieve.
“The job explains why the information matters and what must happen after the professional receives it.”
Define the clinical purpose behind the interaction
Begin with what the healthcare professional needs to accomplish. Depending on the role, this may involve recognizing risk, determining eligibility, delivering treatment, explaining options or evaluating outcomes.
Keep the job statement independent of a preferred product. “Review our dashboard” describes an interaction. “Determine whether the patient requires a change in care” describes clinical progress.
Define the context and boundaries. The work may differ across acute care, routine follow-up and home monitoring. A job that includes several independent clinical purposes may need to be separated into smaller, researchable scopes.
The team should be able to explain why the professional performs the work, what constitutes completion and who depends on the result.
Identify who performs each job
“HCP” covers professionals with different responsibilities, authority and expertise. A physician deciding on treatment, a nurse preparing a patient and a technician acquiring measurements may interact with the same device for different reasons.
Identify the job executor and the people who influence or support the work. Clarify who can make the relevant decision, who supplies necessary information and who acts on the result.
Do not assume that the purchaser, prescriber and daily user have the same needs. A product selected for one group’s convenience can introduce burdens for another.
Research each important perspective while retaining a clear account of the job under investigation. Differences across professional roles should inform the design rather than disappear into an average customer profile.
Study the work in its actual setting
Clinical research combines observation with empathy interviews. Applied to healthcare professionals, it examines clinical work where it happens.
Watch how professionals prepare, locate information, make decisions and respond to interruptions. Ask them to explain recent cases and the reasoning behind their actions.
Observe the tasks before and after device use. A procedure that looks efficient may depend on extensive preparation by another team. A report that looks clear may require a clinician to reconstruct its meaning from several systems.
Discuss observations with the people involved. Familiar workarounds may compensate for a missing capability. Understanding them helps distinguish a product preference from a need that governs successful completion of the job.
Separate current behavior from the desired outcome
Professionals often describe needs through the solution they know: another field, a different screen or a new report. These requests provide useful clues, but they still require interpretation.
An illustrative request for “all the data on one page” may reflect a need to establish whether enough information is available for a decision. The best response depends on the missing information, its relevance and the decision being supported.
Ask why the requested change matters. What uncertainty would it remove? What work would it reduce? What would the professional be able to accomplish more effectively?
Map the complete clinical job
Use the eight-step job framework to investigate the work surrounding the visible activity.
- Define. Establish the intended clinical result and the decision or action required.
- Locate. Obtain the evidence, equipment and resources needed.
- Prepare. Arrange the patient, environment and supporting work.
- Confirm. Verify readiness and determine whether proceeding is appropriate.
- Execute. Perform the assessment, procedure or other clinical activity.
- Monitor. Evaluate progress and recognize deviations from the intended result.
- Modify. Change the approach within the professional’s authority when necessary.
- Conclude. Document, communicate and prepare for the next episode of care.
Treat these steps as prompts for discovery. In practice, professionals may revisit information, pause a procedure or return to preparation. The map should preserve the dependencies that make the job possible.
“Preparation and follow-up are part of the clinical job even when they happen outside the product team’s field of view.”
Convert clinical experience into measurable needs
A desired outcome statement describes how the professional judges success. It identifies the direction of improvement, a measure, what is being controlled and the context in which it matters.
For example: “Minimize the time required to determine whether the information needed for an eligibility decision is complete.” Another might be: “Reduce the likelihood that a clinically significant change is missed during review of monitoring results.”
These are illustrative research statements, not claims of demonstrated product performance. They require validation with the professionals whose work they describe.
Avoid combining several outcomes into one statement. Speed, completeness and accuracy may all matter, but respondents need to evaluate each clearly. An outcome should also leave room for alternative ways of satisfying the need.
Preserve judgment and accountability
Clinical jobs involve interpretation and responsibility as well as information processing. Understanding the outcome does not establish that the product should take over the professional’s decision.
Clarify where the device supplies evidence, supports a task or performs a defined action. Examine what the professional needs to recognize limitations, handle exceptions and decide when additional expertise is required.
A design that reduces routine effort can introduce new review work or uncertainty. Research should capture these consequences alongside the intended benefit.
When professionals ask for greater confidence, determine what supports that confidence: appropriate evidence, clear limitations, interpretable results or a reliable escalation process. Design decisions should preserve the professional’s ability to act responsibly within the care setting.
Establish priorities through importance and satisfaction
Once qualitative research has produced clear outcomes, use quantitative research to determine their importance and how well current approaches satisfy them.
Ask professionals to rate the outcome itself, with a defined reference situation. Satisfaction should concern their current ability to complete the job, rather than whether they like a brand or presentation.
Include relevant variations in setting, experience and workload. The priorities of a high-volume specialist service may differ from those of a clinician who encounters the condition occasionally.
Opportunity assessment considers importance together with the gap between importance and satisfaction. It helps direct attention toward underserved outcomes. Apply consistent scales and interpret scores alongside the underlying evidence. Necessary safety requirements remain obligations even when survey respondents rank them differently.
Look for hidden differences between groups
Average scores can conceal important difficulties. A need may be well served for experienced users but poorly served for professionals without immediate specialist support.
Examine whether respondents cluster around different patterns of unmet outcomes. Investigate the circumstances that explain those patterns.
A group may struggle primarily to prepare the patient. Another may struggle to interpret results or coordinate follow-up. These differences can call for different product capabilities, training or service arrangements.
Bring clinical needs into the target product profile
A target product profile connects prioritized outcomes with the Voice of Technology and the Voice of Business in one shared definition. For healthcare professional jobs, this creates a shared view of what the solution must enable.
Technical assessment examines feasibility and readiness. Business assessment clarifies objectives, resources and implementation conditions. Clinical evidence and relevant requirements shape what can responsibly be promised.
Record the important outcomes, intended users and operating context. Identify the measures and evidence that will establish whether a concept improves the job.
Use the profile to guide tradeoffs. A feature that helps one professional may transfer work to another. The team needs to assess its effect on the complete clinical activity and the patient pathway.
Test concepts against the work they should improve
Concept evaluation should examine realistic tasks and scenarios with representative professionals. Ask what the proposed approach changes about their ability to achieve the priority outcomes.
Observe preparation, interpretation, exceptions and handover. Measure relevant effort or performance where the study supports it. Investigate whether support requirements make adoption practical in the intended setting.
A preference survey can identify an attractive concept, but it does not establish successful clinical use. Keep unresolved questions visible and plan the evidence needed to answer them.
Connect the results with the wider care system. The Theory of Constraints helps determine whether improving this job releases capacity or removes an obstacle governing patient progress.
“A useful concept improves an important clinical outcome of the job and remains practical within the system delivering care.”
What comes next
Examine one clinical job your solution supports. Can the team state its purpose, identify its executor and show which outcomes remain poorly served?
Observe the work, validate the outcome statements and measure priorities. Then test concepts against those outcomes and their effects on patient flow. That is how Patient Centered Design connects professional insight with better products and more dependable care.
Understanding the Jobs Patients Need Doing
A patient may ask for a smaller device, a clearer display or an easier app. Those requests matter, but they leave a deeper question unanswered: what is the person trying to accomplish, and why does the current approach make it difficult?
Someone using a monitoring device may want to understand whether their condition is changing, decide when to seek help or manage daily activities with greater confidence. The device is one means of achieving that outcome.
A powerful question asks how well your organization understands the jobs patients are trying to get done. A strong answer connects patient research with clearly defined outcome statements that become the formal user needs your teams use to build the design history file. Outcome-based user needs are easier to validate, flow more easily into design requirements, and result in faster time to market.
“A feature request describes a possible answer. Understanding the patient’s job to be done sets your design team up to deliver a better solution faster.”
Define the job from the patient perspective
A useful job statement describes an activity the patient needs to accomplish in a relevant context. It should remain understandable without naming your product or preferred technology.
“Use our app every day” describes behavior your organization wants. “Provide a way to recognize when a change in my condition requires professional advice” describes the outcome a patient actually desires.
The distinction affects research. If the team starts with the app, it will ask how to improve screens and interactions. Starting with the job opens questions about information, confidence, timing and support. The best solution may involve changes beyond the app.
Define a scope the team can investigate. “Live a healthier life” expresses an aspiration but is too broad to guide detailed engineering decisions on its own. “Minimize the time it takes to find a solution to my health concern without needing to talk to a doctor or call someone” gives a team a direction, a measure, an object of control and contextual clarifier(s).
Distinguish the job from the journey
Journey mapping shows how people move through a particular care pathway. Job mapping examines what they must accomplish to achieve their purpose, including the work surrounding the interaction with your solution.
The two perspectives complement each other. A journey may show that a patient waits for follow-up. The job perspective asks what they are trying to understand or decide while waiting.
This matters because current processes can become embedded in the team’s assumptions. Patients may need a reliable way to recognize an important change; they do not necessarily need the exact sequence of activities currently provided.
Use the journey to understand context and dependencies. Use the job to examine whether a different approach could help the patient achieve the desired outcome more effectively.
Study daily life where it happens
Patient research begins with observation and empathy interviews at the Gemba, the place where the activity actually occurs.
For patients, that place includes the home and the settings in which they manage health alongside ordinary responsibilities. Ask people to demonstrate routines, explain decisions and describe recent experiences.
Observe what they do. Immerse yourself in the circumstances surrounding the activity. Engage through questions that let them explain their purpose in their own language.
A person may say that managing treatment is straightforward while observation reveals multiple reminders, improvised storage or reliance on a partner. Those arrangements can reveal effort and uncertainty that have become familiar enough to go unreported.
The aim is to understand the why your solution will win before making any decisions about what your solution will do. Customers will want your solution because of the outcomes it gives them, not because of what you made.
Recruit for differences that affect the job
Patients with the same diagnosis may struggle with different parts of an activity. Differences in confidence, experience, resources and support can change how they define success.
Recruit participants whose circumstances reflect the population you intend to serve. Include relevant variations in health literacy, technology familiarity, physical ability and access to care. Are you targeting the tech savvy millennial, a busy parent trying to run a family with four kids or a retiree living in a managed healthcare facility?
Research should also examine emotional and social needs. A patient may want reassurance about managing a task alone or worry about drawing attention to a condition. Keep these needs visible alongside functional outcomes without assuming one design choice resolves them all.
Examine the complete job
The job mapping framework divides a job into eight recurring steps. These steps prompt investigation beyond the most visible interaction.
- Define. Establish what the patient needs to achieve and the circumstances that matter.
- Locate. Establish how the patient will find the information, materials or support required, including your solution.
- Prepare. Uncover how the patient will arrange the environment and resources for the job to be done.
- Confirm. Understand how the patient will make the decision to go forward with your solution and determine whether everything is ready for the intended next action steps.
- Execute. What outcomes matter to the patient as they get your solution and start using it. Often this is the ONLY job step the team looks at.
- Monitor. How will the patient assess and know for sure your solution is progressing successfully.
- Modify. Rarely do things work perfectly on the first try. Identify outcomes that are important to the patient when adjustments to the approach are needed when conditions or results require it.
- Conclude. Complete the set of outcomes by understanding how the patient completes the activity or prepares to repeat it.
Apply these prompts to actual patient work. Some steps may recur or overlap. The map should help the team discover needs, rather than force experience into an artificial sequence.
“The most useful innovation may help a patient prepare, recognize an exception or recover confidence before it changes the device itself.”
Turn patient language into outcome statements
Interviews generate verbatims: patients’ own descriptions of experiences, difficulties and expectations. Preserve that evidence, then interpret what each statement reveals about the job.
An illustrative verbatim might be, “I keep checking because I don’t know whether the reading matters.” The desired outcome may concern recognizing a meaningful change or understanding what action is appropriate.
A structured outcome statement identifies the direction of improvement, a measure, the object being controlled and relevant context. For example: “Minimize the time required to determine whether a change in a reading requires contacting my care team.”
Ask the team if there are uncovered outcomes that can set your solution apart related to how it is purchased, installed, received, set up, learned with training support, transported, maintained, upgraded, replaced or disposed.
This formulation gives research and design a clearer target. It does not establish a clinical threshold or promise that a device can safely make the decision independently, but often the features that will make your solution “easy to use” or set you apart will come from these outcome statements.
Preserve meaning as you organize the evidence
Several comments may describe the same need. One comment may contain multiple needs. Review the evidence carefully before combining it into a set of outcomes.
Remove duplication, separate distinct outcomes and retain links to the original accounts. Use plain language that patients can understand. Avoid embedding a particular feature in the statement.
Check the interpretation with participants or other appropriate reviewers. “I want fewer notifications” might mean reducing irrelevant interruptions while preserving important information. Treating it as a demand to suppress all alerts would misrepresent the need.
The output should be a coherent set of outcomes organized by job step. Completeness and clarity matter but typically it is ideal to have at least 100 and no more than 200 outcome statements for the team.
Measure importance and satisfaction separately
Qualitative research discovers needs and explains them. Quantitative research helps determine how widely they matter and how well existing approaches satisfy them.
Ask patients to rate the importance of each outcome and their satisfaction with their current ability to achieve it. Make the reference situation clear so respondents evaluate comparable experiences.
A high scoring importance outcome with low satisfaction deserves investigation. High satisfaction may indicate that the need is already well served so the team can use what already exists and put more time in creating innovative solutions to high importance low satisfaction outcomes. Low importance can reduce its priority, although clinical safety requirements cannot be dismissed through a popularity score.
Use a research design appropriate to the intended population. The outcome statements are easy to rate on a five point Likert scale. Choose population quantitative research in alignment with your target persona groups.
Identify opportunities within patient segments
The Outcome Driven Innovation approach uses importance and satisfaction to identify underserved outcomes. Its opportunity calculation adds importance to the positive gap between importance and satisfaction.
Use compatible scales and a clearly defined calculation. Interpret the result alongside the underlying responses, research quality and the clinical context.
Examine differences between groups. An outcome that appears adequately served overall may remain difficult for patients with less support or a different level of experience.
These differences can reveal meaningful segments based on unmet needs. They help the organization avoid treating demographic similarity as evidence that patients need the same solution. Prioritization should retain enough detail to explain whose outcome the proposed improvement will change.
Connect outcomes with development decisions
A target product profile brings the priority outcomes together with business goals, available technology and other relevant requirements. It helps the team agree what success should look like before committing to a concept.
Translate patient outcomes into design inputs and measurable requirements while preserving traceability to the evidence. Define which questions remain uncertain and what research or testing will resolve them.
Evaluate concepts against the outcomes they are intended to improve. Ask whether the proposed approach reduces effort, uncertainty or difficulty for the relevant patients and results in higher satisfaction scores than the baseline solution. A favorable reaction to an attractive prototype provides limited evidence unless the team can connect it with better execution of the job.
Keep patient progress connected to system performance
A priority patient need may involve work performed by a clinician, caregiver or service provider. Investigate those dependencies before deciding that a product change will solve the problem.
The Theory of Constraints helps identify where improvement can change the performance of the wider pathway. A better patient interaction can have limited effect if access to essential support remains constrained.
A Value Management Office can coordinate the initiatives needed to address these connected issues and keep investment aligned with patient outcomes.
“Patient insight becomes useful design evidence when the team can show which outcome matters, who struggles with it and how the solution improves it.”
What comes next
Use patient jobs to be done to review one priority patient job. Can your team state it clearly, map its steps and demonstrate which outcomes are highly important and poorly satisfied?
Start with observation and patient conversations. Build and validate the outcome statements, measure priorities and test concepts against them. That discipline gives Patient Centered Design a practical foundation for better products and more lives changed for good.
