NURTURE — Making It Stick

Module 6A: NURTURE — Theory

R — Reveal

Case Study: The System That Forgot How to Work

The celebration had been justified.

Adrienne Holcomb, Chief Operations Officer at Brookstone Wealth Management, had stood at the front of the conference room eighteen months ago and announced what the numbers confirmed: the client onboarding automation had exceeded every projection.

The project had done everything right. Careful assessment of the opportunity. Rigorous calculation of expected value. Thoughtful design with practitioner input. Disciplined prototyping and iteration. Measured deployment with validated results.

Time to onboard a new client: reduced from 8.2 hours to 2.1 hours. Error rate in compliance documentation: dropped from 6.8% to 1.2%. Advisor satisfaction with the process: up from 2.4/5 to 4.3/5. The $180,000 implementation had already returned $240,000 in its first year—labor savings, faster time to revenue, reduced compliance risk.

The project team received recognition. The technology partner got a testimonial. The executive sponsor moved to a larger role at the parent company. The implementation was featured in an industry publication as a model for intelligent automation.

And then the project ended.

---

The Quiet Deterioration

Eighteen months after that celebration, Adrienne sat in her office with a compliance report that should have been routine.

The quarterly audit had flagged an unusual pattern: twenty-three new client accounts had incomplete beneficial ownership documentation. Not missing—incomplete. The automation should have prevented exactly this scenario. The system was designed to halt onboarding until all required fields were verified.

Adrienne called Derek Vasquez, the IT director who had inherited operational support for the system when the project team disbanded.

"We've had some issues," Derek admitted. "The wealth planning team found that the verification process was rejecting legitimate international clients because their documentation formats didn't match the expected patterns. So we created an override for 'trusted advisor attestation'—the advisor confirms the documents are valid, and the system proceeds."

"When was this override created?"

"About nine months ago. It was supposed to be temporary while we updated the document recognition. The update never happened. Budget constraints."

Adrienne pulled the usage logs. The "temporary" override had been used 847 times. It had effectively disabled the verification system for any case an advisor found inconvenient.

One workaround. Nine months. 847 exceptions. And no one had noticed because no one was watching.

---

Module 6A: NURTURE — Theory

O — Observe

Core Principles of Sustainability

Brookstone's failure wasn't a technology failure. It was a sustainability failure. The system worked exactly as designed—until it didn't, because no one was maintaining it.

This section establishes the principles that prevent such failures.

---

The Sustainability Mindset

Deployment Is the Beginning, Not the End

Projects have phases: initiation, planning, execution, closure. This structure creates a dangerous illusion—that implementation is the destination and deployment is the finish line.

It's not.

Deployment is when the system's real life begins. Before deployment, the system exists in controlled conditions with dedicated attention. After deployment, it must survive in the wild—competing for attention, adapting to change, resisting entropy.

Brookstone treated deployment as the finish line. The project ended. The team disbanded. The celebration happened. And the system began its slow deterioration because no one planned for what came next.

Systems Deteriorate by Default

Entropy affects organizations as much as physics. Without active maintenance:

• Documentation goes stale as reality changes
• Calibration drifts as conditions evolve
• Knowledge erodes as people leave
• Integrations break as connected systems update
• Workarounds accumulate as users find paths around friction

This isn't failure—it's physics. Systems tend toward disorder unless energy is invested to maintain order.

The question isn't whether deterioration will happen. It's whether you'll notice and respond before the damage compounds.

The Project Team Leaves; The System Stays

Project teams are temporary. They form to build something, then move to the next initiative. This is appropriate—you can't keep implementation specialists on every deployed system forever.

But the transition from project to operations is where systems often fail. The project team has the context, the understanding, the investment. They hand off to an operations team that inherited the system but didn't build it, that has a hundred other responsibilities, that may not understand why decisions were made.

Sustainable systems require intentional handoff—not just transferring access, but transferring understanding, ownership, and accountability.

Value Must Be Defended, Not Just Created

Module 5 focused on creating value. The prototype demonstrated improvement. The pilot validated the business case. Production deployment delivered the capability to the organization.

But created value isn't permanent value. Value must be defended—actively maintained against the forces that erode it. Monitoring must detect drift before it becomes disaster. Ownership must ensure someone is watching. Knowledge management must preserve expertise against turnover.

Organizations invest heavily in creating value and underinvest in preserving it. The result: systems like Brookstone's that generate returns in year one and become liabilities by year two.

---

The Ownership Imperative

Every System Needs an Owner

An owner is someone who:

• Monitors the system's health
• Responds when problems arise
• Makes decisions about changes
• Advocates for resources
• Is accountable for outcomes

Without an owner, systems become organizational orphans. Everyone assumes someone else is responsible. No one actually is.

Brookstone's system had no owner after deployment. It had users. It had IT support that would respond to tickets. It had executives who would notice if it completely failed. But no one owned its ongoing health—no one who would notice the slow drift, the accumulating workarounds, the eroding performance.

Ownership Means Someone Wakes Up at Night

Nominal ownership isn't real ownership. A name on an org chart isn't the same as someone who genuinely cares whether the system works.

Real ownership means someone feels responsible—not just technically accountable, but personally invested. When the system fails at 2 AM, someone notices and cares. When performance degrades gradually, someone tracks the trend and acts before crisis.

This level of ownership doesn't happen by accident. It requires explicit assignment, clear authority, adequate time allocation, and genuine accountability.

Unowned Systems Become Everyone's Problem and No One's Responsibility

When something goes wrong with an unowned system, a predictable pattern emerges:

• Users complain to support
• Support logs a ticket
• IT investigates and determines it's a business process issue
• Business says it's a technical issue
• The ticket bounces between departments
• Eventually, someone applies a workaround
• The underlying problem persists

This is how Brookstone accumulated 847 uses of a "temporary" override. Everyone could work around the problem. No one was responsible for fixing it.

The Transition from Project to Operations

The project-to-operations handoff is the highest-risk moment for sustainability. During this transition:

• Attention shifts from the deployed system to the next initiative
• Context transfers imperfectly from builders to operators
• Budgets shift from implementation to maintenance
• Enthusiasm fades as novelty wears off

Organizations that sustain their systems treat this transition as a critical phase, not an administrative formality. They define ownership before project closure. They document what operators need to know. They maintain project team availability for questions during the transition period.

---

The Monitoring Principle

What Isn't Measured Drifts

If you're not tracking performance, you won't notice degradation until it's severe enough to cause complaints. By then, the damage has compounded.

Brookstone's system degraded for over a year before anyone noticed. The compliance audit caught problems that had been accumulating silently. If they had been monitoring the metrics that mattered—onboarding time, error rates, exception frequency—they would have seen the drift months earlier, when intervention was simpler.

Monitoring isn't about generating dashboards. It's about maintaining visibility into whether the system is still delivering the value it was built to deliver.

Monitoring Should Detect Problems Before Users Complain

By the time users complain, the problem is already affecting the business. Effective monitoring creates earlier warning:

• Leading indicators that predict problems before they occur
• Thresholds that trigger investigation before crisis
• Trends that reveal gradual drift before it becomes obvious

The goal is intervention before impact—catching the integration failure before it corrupts data, noticing the calibration drift before recommendations become irrelevant, detecting the workaround pattern before it becomes standard practice.

Leading Indicators Matter More Than Lagging Indicators

Lagging indicators tell you what happened. Onboarding time increased. Error rate rose. Satisfaction dropped. These are useful for understanding the past but come too late for prevention.

Leading indicators tell you what's coming. Override usage is increasing. Support tickets are trending up. A key team member is leaving. Integration sync failures are appearing. These provide time to act before lagging indicators register the damage.

Sustainable monitoring emphasizes leading indicators—the signals that something is changing before performance metrics reflect the change.

Silent Degradation Is the Most Dangerous Kind

Brookstone's integration broke silently. No alert. No error message. Just incomplete data flowing through the system, generating the gaps that compliance eventually caught.

The most dangerous failures are the ones you don't know about—the quiet deterioration that accumulates until the moment of discovery reveals months of damage.

Monitoring must include verification that things are working, not just alerts when they fail. Integration should be tested regularly. Data quality should be validated. Calibration should be confirmed. The absence of complaints isn't evidence of success.

---

The Knowledge Continuity Challenge

Staff Turnover Is Inevitable; Knowledge Loss Isn't

People leave organizations. Retirements, promotions, new opportunities, restructuring—turnover is a constant. What isn't inevitable is losing the knowledge they carry.

Sandra Mireles left Brookstone and took irreplaceable context with her. This happened because her knowledge was never extracted, documented, or distributed. When she walked out the door, that knowledge walked out too.

Sustainable systems treat knowledge transfer as an ongoing practice, not an exit interview afterthought.

Documentation Alone Doesn't Transfer Expertise

A user guide isn't the same as understanding. Documentation captures what to do. It rarely captures why decisions were made, when to deviate from standard procedures, or how to handle situations the documentation doesn't cover.

Expertise transfer requires more than documents:

• Shadowing and mentoring during normal operations
• Explicit capture of decision rationale ("We did it this way because...")
• Scenarios and case studies that illustrate judgment, not just procedure
• Backup personnel who have actually done the work, not just read about it

Single Points of Failure Are Organizational Risks

When only one person understands how something works, the organization has created a dependency that will eventually become a problem.

The "bus factor"—how many people can be hit by a bus before the system fails—shouldn't be one. At minimum, two people should understand each critical function. Better, knowledge should be distributed so that losing any individual doesn't cripple the capability.

Knowledge Must Be Distributed, Not Concentrated

The goal isn't redundant experts. It's distributed understanding. Multiple people who know enough to maintain, troubleshoot, and adapt the system. A community of knowledge rather than a single source.

This distribution happens through cross-training, shared responsibilities, regular rotation, and deliberate knowledge sharing. It requires investment—time that could be spent on other work. But the alternative is the Brookstone scenario: one departure creating a knowledge void that takes months to fill.

---

The Refresh Requirement

Business Changes; Systems Must Change With It

The system that perfectly served yesterday's business may be wrong for today's. Products change. Processes evolve. Regulations update. Customers shift. Markets transform.

Brookstone's routing logic recommended discontinued products because no one updated it when the product portfolio changed. The system was operating on a model of the business that no longer existed.

Sustainable systems include regular alignment checks—verifying that the system still reflects current business reality.

Calibration Drift Is Normal; Recalibration Must Be Scheduled

AI systems and automated decision logic drift over time. Patterns that were accurate when the system launched become less accurate as conditions change. This isn't failure—it's expected behavior that requires regular recalibration.

"Set and forget" is a recipe for obsolescence. Systems that rely on calibration need scheduled recalibration—not when problems become obvious, but as routine maintenance before problems emerge.

"Set and Forget" Is a Recipe for Obsolescence

The temptation to declare something finished and move on is powerful. But systems aren't software releases—they're living capabilities that require ongoing attention.

Every system needs a maintenance rhythm: regular review, periodic refresh, continuous monitoring. The rhythm varies by system—some need weekly attention, others monthly or quarterly. But no system survives on zero maintenance.

Regular Review Prevents Major Rebuilds

Small, frequent adjustments are cheaper than large, occasional overhauls. Brookstone's recovery cost $125,000 because problems accumulated for over a year. If they had addressed issues as they emerged, the ongoing cost would have been a fraction of the recovery cost.

Regular review catches drift early, when correction is simple. Neglect allows drift to compound until correction becomes reconstruction.

---

The Anchor Principle

Systems don't maintain themselves. Someone has to care, or no one will.

This principle underlies all of Module 6.

• Ownership doesn't happen automatically—someone must be assigned
• Monitoring doesn't happen spontaneously—systems must be built
• Knowledge doesn't preserve itself—transfer must be designed
• Value doesn't persist by default—preservation requires investment

If you don't plan for sustainability, you've planned for deterioration. The only question is how long before the decay becomes visible.

---

Proceed to monitoring and measurement design.

---

Module 6A: NURTURE — Theory

O — Observe

Monitoring and Measurement

Brookstone's system deteriorated for over a year before anyone noticed. The compliance audit that finally caught the problems revealed damage that had been accumulating silently—a year of drift that no one was watching.

This section covers how to monitor systems so problems are caught early, when intervention is simple.

---

From Project Metrics to Operational Metrics

Project Metrics Prove Value; Operational Metrics Preserve Value

During Module 5, measurement was intensive. The pilot tracked every relevant metric to validate the business case. Daily observations, weekly reviews, rapid iteration based on data.

This intensity is appropriate for proving value. It's not sustainable for preserving value.

Operational measurement must be sustainable—lightweight enough to continue indefinitely, focused enough to catch what matters, efficient enough to not become a burden.

Different Rhythms: Project vs. Operations

The transition from project to operational measurement requires reducing intensity while maintaining visibility. Which metrics continue unchanged? Which can be sampled less frequently? Which new metrics are needed for ongoing health?

What to Measure: Continuous vs. Periodic vs. On-Demand

Continuous measurement: Metrics collected automatically, always available. System usage, error logs, performance timestamps. These are the vital signs—always monitored, always visible.

Periodic measurement: Metrics collected on a schedule. Monthly accuracy audits, quarterly satisfaction surveys, annual strategic reviews. These provide regular checkpoints without continuous overhead.

On-demand measurement: Metrics collected when needed. Deep-dive investigations, root cause analyses, specific hypotheses to test. These deploy investigative capacity when continuous or periodic monitoring raises questions.

The art is choosing what goes where. Too much continuous measurement creates noise. Too little misses early signals.

---

Leading vs. Lagging Indicators

Lagging Indicators Tell You What Happened

Classic performance metrics are lagging indicators:

• Time to complete (measured after completion)
• Error rate (measured after errors occur)
• Satisfaction score (measured after experience)
• Compliance exceptions (measured after audit)

These matter—they're the outcomes we care about. But they arrive late. By the time a lagging indicator shows decline, the problem has already affected the business.

Leading Indicators Tell You What's Coming

Leading indicators predict changes in lagging indicators:

• Override usage rate predicts accuracy problems
• Support ticket volume predicts satisfaction decline
• Workaround frequency predicts compliance risk
• Key personnel departure predicts knowledge gaps

Leading indicators provide intervention time. Seeing an uptick in overrides allows investigation before accuracy metrics reflect the damage.

Building Early Warning Systems

For each lagging indicator, identify leading indicators that predict changes:

Monitor leading indicators more frequently than lagging indicators. React to leading indicator changes before lagging indicators confirm the problem.

Examples for Human-AI Collaboration Systems

For systems where AI and humans work together:

Leading indicators for accuracy drift:

• Confirmation rate: Are users accepting recommendations, or overriding frequently?
• Override patterns: Are specific case types triggering more overrides?
• Calibration age: How long since the system was recalibrated?

Leading indicators for adoption decline:

• Usage trends: Is system usage stable, growing, or declining?
• Workaround emergence: Are users finding paths around the system?
• Training requests: Are new users seeking more help than expected?

Leading indicators for integration health:

• Sync failures: Are data synchronization errors occurring?
• Latency trends: Is response time degrading?
• Update frequency: Are connected systems changing without testing?

---

The Three Lenses in Operations

Time: Is the System Still Saving Time?

Time was the first lens in Module 3. In operations, the question shifts from "Will it save time?" to "Is it still saving time?"

Time can erode through:

• Workarounds that add steps
• Degraded system performance
• Calibration drift requiring more verification
• Integration issues causing delays

Monitor time metrics against original baseline, not just against targets. If R-01 delivered 4.1-minute task time, watch for drift back toward 14.2 minutes.

Throughput: Is Quality/Volume Still Improved?

Throughput—quality and volume—can erode through:

• Accuracy drift as calibration ages
• Capacity issues as usage scales
• Error accumulation from unaddressed issues

Monitor error rates, processing volumes, and quality indicators. Compare to both baseline and deployment-era performance.

Focus: Is Cognitive Load Still Reduced?

Focus—the cognitive load on practitioners—is the most subtle lens to monitor:

• Escalation patterns: Are users still handling cases independently?
• SME queries: Is specialized expertise still being accessed at expected rates?
• Practitioner feedback: Do users feel the system helps or hinders?

Escalation trends and support patterns reveal focus erosion before satisfaction surveys capture it.

Each Lens Can Degrade Independently

A system might maintain time savings while accuracy degrades. Or accuracy might hold while practitioners report increasing friction. The three lenses are related but distinct—tracking all three provides complete visibility.

---

Alert Thresholds and Escalation

When Should Monitoring Trigger Action?

Not every fluctuation requires response. The art is setting thresholds that:

• Catch real problems early
• Avoid alert fatigue from false positives
• Scale appropriately with severity

Consider two threshold levels:

Investigation threshold: Something has changed enough to warrant looking. Not emergency—just attention. Example: Override rate increased 5% week-over-week.

Escalation threshold: Something requires action. The owner or leadership must be notified. Example: Error rate exceeds target for two consecutive measurement periods.

Avoiding Alert Fatigue

Too many alerts means no alerts. If the system generates warnings constantly, people stop paying attention. The alert that matters gets lost in noise.

Prevent alert fatigue by:

• Setting thresholds at meaningful levels, not hair-trigger sensitivity
• Consolidating related alerts rather than generating multiples
• Reviewing and adjusting thresholds based on experience
• Distinguishing "investigate" from "emergency"

Escalation Paths: Who Gets Notified at What Threshold

Define these paths before they're needed. When a critical alert fires isn't the time to figure out who should respond.

The Difference Between "Investigate" and "Emergency"

Not every problem is a crisis. Classification matters:

Investigate: Something's different. Could be concerning. Needs human review to assess. Timeframe: days.

Warning: Something's wrong but not critical. Needs attention and tracking. Timeframe: this week.

Critical: Something's significantly wrong. Affecting operations. Needs resolution. Timeframe: today.

Emergency: Something's broken. Business impact is immediate. All resources focused. Timeframe: now.

Most alerts should be at the "investigate" or "warning" level. If you're frequently at "critical" or "emergency," your early warning systems aren't working.

---

Periodic Review Cycles

Daily/Weekly Operational Monitoring

For actively used systems, someone should review key metrics regularly:

• Daily: Are there any critical alerts? Any user-reported issues?
• Weekly: How are leading indicators trending? Any patterns in support requests?

This isn't analysis—it's scanning. A quick check that nothing has gone wrong, nothing is drifting badly, nothing needs immediate attention.

Monthly Performance Review

Monthly, conduct a more thorough review:

• How do current metrics compare to targets?
• How do current metrics compare to baseline?
• Are there trends that warrant investigation?
• Are there recurring issues that need addressing?
• What feedback have users provided?

Document findings. Track trends over time. Identify issues before they become crises.

Quarterly Business Alignment Check

Every quarter, assess whether the system still fits the business:

• Have business processes changed that affect the system?
• Have products, policies, or priorities shifted?
• Is the system still solving the right problem?
• Does calibration or configuration need updating?

This is strategic review—not just "is it working?" but "is it still the right thing to be working?"

Annual Strategic Assessment

Annually, take the long view:

• What lifecycle stage is the system in?
• What investments are needed for the coming year?
• Should we iterate, rebuild, or consider retirement?
• How does this system fit in the broader portfolio?

Annual assessment informs budget planning and strategic decisions about the system's future.

---

Documenting Drift

Tracking Changes Over Time

Drift is gradual. Visible only when you compare across time. Maintain records that enable comparison:

• Monthly metric snapshots
• Change log of modifications
• Issue log of problems addressed
• Trend graphs that show trajectory

Without historical records, drift becomes invisible. "It's always been like this" becomes the explanation because no one can remember otherwise.

Distinguishing Normal Variation from Concerning Trends

All metrics vary. Day-to-day, week-to-week fluctuation is normal. The question is whether variation is random noise or directional trend.

Look for:

• Consistent direction over multiple periods
• Variance outside historical norms
• Correlation with known changes (new staff, system updates, process changes)
• Acceleration: not just change, but increasing rate of change

A week of high override rates might be noise. A month of steadily increasing override rates is a trend.

Building the Case for Intervention

When monitoring reveals problems, document systematically:

• What metrics have changed?
• When did the change begin?
• What's the trajectory if unaddressed?
• What's the hypothesis for the cause?
• What intervention is recommended?

This documentation supports decision-making. It's not enough to say "something's wrong"—you need to explain what, why, and what to do about it.

---

Proceed to ownership and accountability structures.

---

Module 6A: NURTURE — Theory

O — Observe

Ownership and Accountability

Brookstone's system had no owner after deployment. It had users. It had IT support. It had executives who approved the budget. But no one owned its ongoing health—no one responsible for monitoring, maintaining, improving, and defending the system over time.

This section covers how to establish ownership that actually works.

---

The Ownership Gap

Project Teams Disband; Who Inherits the System?

Project teams form to build things. They have defined scope, dedicated resources, clear timelines. When deployment completes, the project ends—and the team moves on to the next initiative.

But the system remains. And the question that often goes unanswered: Who takes care of it now?

The project team had context, investment, and expertise. They understood why decisions were made. They knew where the vulnerabilities were. They cared about the outcome because they'd built it.

The inheritors often have none of these. They received a system, not an education. They have other responsibilities. They may not even know the system exists until something breaks.

This gap—between project closure and operational ownership—is where systems become orphans.

The Danger of "Shared Ownership"

"Everyone owns it" means no one owns it.

When ownership is distributed across a team without clear accountability, responsibility diffuses. Problems are noticed but not acted on—everyone assumes someone else will handle it. Decisions are deferred—no one has the authority to make them. Maintenance is neglected—it's everyone's job, so it's no one's priority.

Shared ownership creates organizational ambiguity. Who monitors the dashboard? Who responds to alerts? Who decides whether to fix or defer? When the answer is "the team," the reality is often "no one specifically."

Why IT Ownership Alone Is Insufficient

The temptation is to assign systems to IT. They're technical. IT is technical. Let IT handle it.

But IT can only maintain what's working—they can't tell if it's delivering business value. They can monitor uptime and response time. They can't monitor whether recommendations are accurate, whether users are satisfied, whether the business problem is still being solved.

IT ownership addresses technical sustainability. It doesn't address operational sustainability. A system can be technically healthy while being operationally useless.

Business Ownership vs. Technical Ownership

Sustainable systems need both:

Technical ownership: Responsible for the system working. Performance, reliability, integration health, security. "Is the system running?"

Business ownership: Responsible for the system delivering value. Accuracy, adoption, user satisfaction, business alignment. "Is the system helping?"

When only one exists, blind spots emerge. Technical owners miss value erosion. Business owners miss technical fragility. Both perspectives are necessary.

---

Defining the Owner Role

What an Owner Does

An owner isn't a title—it's a set of responsibilities:

Monitors: Watches performance metrics. Reviews dashboards. Stays aware of system health. Notices drift before it becomes crisis.

Maintains: Ensures ongoing care. Coordinates updates, calibration, documentation refresh. Schedules and tracks maintenance activities.

Improves: Identifies enhancement opportunities. Prioritizes improvements. Advocates for resources to make the system better.

Defends: Protects against degradation. Pushes back on changes that would harm the system. Raises concerns before problems become severe.

If no one is doing these things, there is no owner—regardless of what the org chart says.

Authority: What Decisions the Owner Can Make

Ownership without authority is frustration. Owners need the ability to:

Operational decisions: When to conduct maintenance. How to respond to issues. Whether to implement temporary workarounds.

Configuration decisions: Minor updates to settings. Calibration adjustments. Documentation changes.

Escalation decisions: When to involve leadership. When to request additional resources. When to trigger emergency response.

Recommendation authority: Proposing improvements. Flagging risks. Suggesting changes that exceed operational scope.

Define the boundary between what owners can decide and what requires escalation. Unclear authority creates paralysis.

Accountability: What the Owner Is Responsible For

Accountability means the owner can be asked to explain outcomes:

Performance accountability: Why are metrics at current levels? What's being done about any gaps?

Maintenance accountability: Is scheduled maintenance happening? Is documentation current?

Issue accountability: What problems have occurred? How were they resolved? What prevents recurrence?

Value accountability: Is the system still delivering expected value? If not, what's the plan?

Accountability requires visibility. If no one asks these questions, accountability becomes theoretical.

Time Allocation: Ownership Is Work, Not a Title

Naming someone as owner doesn't give them time to own.

Ownership requires capacity—actual hours for monitoring, maintaining, responding, planning. If ownership is added to an already-full role without offsetting other responsibilities, the ownership becomes nominal.

Estimate realistic time requirements:

• How many hours per week for routine monitoring?
• How many hours per month for maintenance activities?
• What's the expected issue response burden?
• How much time for improvement planning?

Then ensure the assigned owner actually has this capacity.

---

The RACI for Sustained Systems

RACI clarifies who does what:

R — Responsible: Does the work. The person performing the task.

A — Accountable: Owns the outcome. The person who is ultimately answerable. There should be exactly one A for each task.

C — Consulted: Provides input. Two-way communication—these people are asked before decisions or actions.

I — Informed: Kept in the loop. One-way communication—these people are told after decisions or actions.

Applying RACI to Operational Tasks

RACI prevents ambiguity. When something needs doing, the matrix shows who does it and who's accountable.

---

Succession Planning

Owners Leave; Systems Must Persist

People change roles, leave organizations, get promoted. An ownership structure that fails when one person leaves isn't sustainable—it's fragile.

Succession planning ensures continuity:

• Who is the backup for each owner role?
• Has the backup been trained?
• Does the backup have current context?
• What triggers the transition from primary to backup?

Documented Handoff Procedures

When ownership transitions, what needs to transfer?

Access: Systems, dashboards, documentation, communication channels

Context: Current state, recent issues, pending decisions, known risks

Relationships: Key contacts, stakeholders, support resources

Priorities: What needs attention now, what's in progress, what's planned

A handoff checklist ensures nothing critical is forgotten.

Avoiding Single Points of Failure in Ownership

The bus factor applies to ownership. If one person's departure cripples the system's governance, the structure is too concentrated.

Build redundancy:

• Primary and backup for each role
• Regular backup involvement so context stays current
• Documented procedures so backups can function independently
• Cross-training between technical and business ownership

Training Backup Owners Before They're Needed

A backup who has never engaged with the system isn't really a backup.

Active backup development:

• Include backups in regular reviews
• Have backups handle some tasks routinely
• Share context proactively, not just during crisis
• Verify backups can perform ownership functions

When the primary owner leaves, the backup should already know the system—not be learning it under pressure.

---

Governance Structures

Regular Review Meetings

Sustainability requires recurring attention. Schedule governance touchpoints:

Operational review (monthly): Owner-led review of metrics, issues, and health. Quick, focused, action-oriented.

Strategic review (quarterly): Owner and sponsor assess business alignment and future needs. Longer, more reflective.

Annual planning: Budgets, major initiatives, lifecycle assessment. Connected to organizational planning cycles.

Meetings without agendas become optional. Define what each session covers and what decisions it produces.

Decision Rights and Escalation

Clarity about who decides what prevents paralysis:

When escalation is required, the path should be defined: who to contact, how to present the issue, what information is needed.

Budget Ownership for Maintenance

Systems cost money to maintain. If maintenance budget isn't allocated, maintenance doesn't happen.

Ensure ownership includes:

• Operating budget for ongoing costs
• Maintenance allocation for planned work
• Contingency for unexpected issues
• Enhancement reserve for improvements

Budget without accountability is wasted. Accountability without budget is impossible.

Change Management for System Modifications

Changes to the system should follow defined process:

Request: What change is proposed? Why? Assessment: What's the impact? What's the risk? Approval: Who decides? At what threshold? Implementation: How is the change made? Verification: Did it work? Any side effects? Documentation: Is the change recorded?

Ad-hoc changes accumulate into unmaintainable systems. Formal change management preserves integrity.

---

When Ownership Fails

Signs That Ownership Has Lapsed

How do you know ownership isn't working?

• Dashboards that no one reviews
• Issues that persist without resolution
• Documentation that doesn't match reality
• Users developing workarounds without response
• Problems discovered through external audits, not internal monitoring
• No one who can answer questions about the system

These symptoms indicate nominal ownership without real engagement.

Recovery from Ownership Gaps

When ownership has lapsed:

1. Acknowledge the gap: Admit that the system has been orphaned. Avoid blame—focus on recovery.

2. Assess the damage: What's deteriorated? What needs immediate attention?

3. Assign ownership explicitly: Name the owner. Define the role. Allocate time.

4. Rebuild governance: Establish monitoring, meetings, accountability structures.

5. Recover the system: Address accumulated problems. Update documentation. Retrain users.

Recovery costs more than prevention. But denial costs more than recovery.

Rebuilding Accountability After Neglect

Trust in ownership must be rebuilt:

• Consistent execution over time
• Visible progress on recovery
• Responsiveness to new issues
• Communication about status and plans

Accountability isn't restored by announcement. It's restored by action.

---

Proceed to knowledge management.

---

Module 6A: NURTURE — Theory

O — Observe

Knowledge Management

Sandra Mireles left Brookstone, and critical knowledge left with her. She understood why decisions had been made, which configurations were fragile, and what the design rationale was. Eight months after her departure, no one at Brookstone could answer basic questions about their own system.

This section covers how to manage knowledge so it survives turnover.

---

The Knowledge Erosion Problem

Staff Turnover Is Constant; Knowledge Loss Is Optional

People leave. Retirements, promotions, resignations, restructuring, life changes—turnover is a permanent feature of organizations. A 15% annual turnover rate means complete team replacement every seven years on average.

The question isn't whether people will leave. It's whether their knowledge leaves with them.

Sandra's departure didn't have to create a crisis. Her knowledge could have been documented, shared, distributed. But it wasn't—because knowledge management wasn't designed into the system's sustainment. When she left, the organization discovered too late what they had lost.

Tacit Knowledge vs. Explicit Knowledge

Not all knowledge is equal in its capture difficulty.

Explicit knowledge can be written down: procedures, configurations, specifications. It's the "what" and "how"—documented and transferable.

Tacit knowledge lives in people's heads: judgment about edge cases, intuition about when to deviate from procedure, understanding of why things were designed a certain way. It's the "why" and "when"—harder to capture, harder to transfer.

Most knowledge management focuses on explicit knowledge because it's easier. But tacit knowledge is often what makes systems work. The documented procedure says "do X." The experienced practitioner knows "unless Y, in which case do Z"—knowledge that never got written down.

The "Patricia Problem": Expertise Concentrated in One Person

In Module 2, Lakewood's Returns Bible problem centered on Patricia—the one person who knew the policies. Her knowledge made the process work. Her absence would have made it fail.

This pattern recurs: critical expertise concentrated in one person. A "Patricia" for every system. Someone who answers questions, solves problems, knows the history. The organization depends on them without realizing the dependency—until they leave.

The Patricia problem isn't about Patricia. It's about the organization's failure to distribute what Patricia knows.

What Happens When Key People Leave

When expertise walks out the door:

Immediate impact: Questions go unanswered. Problems take longer to solve. Decisions get delayed because context is missing.

Medium-term impact: Workarounds accumulate as people figure out alternatives. Quality degrades as institutional knowledge is reinvented, often incorrectly.

Long-term impact: The system becomes a black box. No one understands why it works the way it does. Changes introduce regressions because no one knows what they're breaking.

Sandra's departure was medium-term impact at Brookstone. The crisis wasn't immediate—but within months, the knowledge gap was creating problems no one could solve efficiently.

---

Documentation That Works

Why Most Documentation Fails

Documentation efforts typically follow a pattern:

1. Project team creates comprehensive documentation
2. Documentation is stored in a central location
3. System changes
4. Documentation is not updated
5. Documentation no longer matches reality
6. Users stop trusting documentation
7. Documentation becomes useless

The failure isn't in the initial creation. It's in the maintenance. Documentation written once is instantly deteriorating. Without continuous updates, it becomes fiction.

Living Documentation: Updated as Part of Work, Not Separate From It

Sustainable documentation integrates updates into the workflow:

• System changes trigger documentation updates—not as a separate task, but as part of the change process
• Documentation is stored where work happens, not in a separate repository
• Review of documentation is part of regular operations, not a special project
• Documentation authors are the people doing the work, not technical writers observing from outside

The principle: if documentation update isn't built into the process, it won't happen.

Levels of Documentation

Not all documentation serves the same purpose. Different levels for different needs:

Quick reference: One-page guides for daily use. Key steps, common decisions, where to find help. Lives at the workstation.

Detailed guide: Complete procedures for complex tasks. Step-by-step with screenshots, decision trees, exception handling. Lives in the knowledge base.

Decision rationale: Why we did it this way. Design decisions, trade-offs considered, alternatives rejected. Lives in the project archive but is accessible.

Each level has different update rhythms. Quick reference updates frequently. Decision rationale rarely needs updating unless the fundamental approach changes.

Who Maintains Documentation and When

Documentation ownership must be assigned:

Without assigned ownership, documentation becomes orphaned like systems become orphaned.

---

Training and Onboarding

New Hire Onboarding for System Users

When someone new joins the organization, how do they learn to use the system?

Ad hoc onboarding: "Ask whoever's around." Inconsistent, incomplete, quality varies by who happens to be available.

Structured onboarding: Defined program with curriculum, materials, and competency verification. Consistent, complete, quality controlled.

Sustainable systems require structured onboarding. New users should reach competency predictably, not randomly.

Training Updates When Systems Change

Systems change. Training must follow. But often:

• System updates ship
• Users figure out the changes on their own
• Some discover new features; others don't
• Some learn workarounds; others learn correct procedures
• Inconsistency compounds

Sustainable training ties updates to system changes:

• What changed?
• Who needs to know?
• How will they learn?
• When will they learn it?

Training isn't a project event—it's an operational function.

Competency Verification: Do People Actually Know?

Completing training doesn't mean competency was achieved. Verification confirms learning:

• Observation: Watch someone do the task correctly
• Testing: Quiz or assessment of knowledge
• Certification: Formal verification before allowing independent work

For critical systems, competency verification isn't optional. You need to know that users can actually use the system, not just that they attended training.

Training the Trainers: Sustainability of Training Capability

Who trains the trainers?

If training depends on one person's knowledge and that person leaves, training capability leaves with them. Sustainable training requires:

• Multiple people who can deliver training
• Training materials that stand alone (not dependent on trainer knowledge)
• Train-the-trainer programs for new trainers
• Regular verification that trainers are current

The goal: training capability that survives individual turnover.

---

Distributing Expertise

Avoiding Single Points of Failure

A single point of failure is a person (or role, or system) that, if absent, would cause critical capability to fail.

In knowledge terms: Is there anyone whose departure would leave critical questions unanswerable?

Identify single points of failure:

• Who are the "go-to" people for specific knowledge?
• What happens if they're unavailable?
• Is there anyone whose absence would stop work?

Then eliminate them—not the people, but the single-point-of-failure status.

Cross-Training Strategies

Cross-training distributes expertise:

Shadowing: Secondary person observes primary person working. Gains exposure but not practice.

Paired work: Primary and secondary work together. Secondary gains practice under supervision.

Rotation: Secondary takes primary role periodically. Gains independent experience.

Documentation: Primary documents what they know. Secondary reviews and tests.

Each strategy has different depth. Shadowing provides awareness. Rotation builds competence.

The "Bus Factor": How Many People Can Leave?

The bus factor measures resilience: How many people would need to be hit by a bus (or win the lottery, or resign together) before the system fails?

• Bus factor of 1: One person's absence causes failure. Extremely fragile.
• Bus factor of 2: Need two people absent simultaneously. Better, but still risky.
• Bus factor of 3+: Three or more people have critical knowledge. Reasonably resilient.

For critical systems, target a bus factor of at least 2. For truly critical systems, target 3.

Building Redundancy Without Inefficiency

Redundancy costs. Two people knowing everything is less efficient than one person knowing everything and another person doing other work.

The balance: sufficient redundancy for resilience without excessive redundancy that wastes capacity.

Focus redundancy on:

• Highest-impact knowledge (where absence would hurt most)
• Most volatile roles (where turnover is most likely)
• Hardest-to-replace knowledge (where rehiring is slowest)

Accept less redundancy on:

• Broadly available skills (easy to hire)
• Well-documented procedures (easy to learn)
• Non-critical functions (low impact if delayed)

---

Capturing Decision Rationale

Why We Did It This Way (Not Just What We Did)

Documentation typically captures what: the procedure, the configuration, the workflow. It rarely captures why: the reasoning behind the choices, the alternatives considered, the constraints that shaped the design.

But "why" is essential for maintenance. Without it:

• Changes are made that violate original assumptions
• Trade-offs are forgotten and remade (often worse)
• Problems are solved that had already been solved
• The system's coherence degrades through accumulated modifications

Design Decisions That Future Maintainers Need to Understand

Some decisions need explanation:

• Why this integration pattern instead of that one
• Why these validation rules exist
• Why this exception was built in
• Why performance was optimized here but not there
• Why certain configurations were chosen

Future maintainers will face situations where they need to decide: Is this intentional or accidental? Can I change this or will something break? Understanding the original reasoning enables better decisions.

Iteration Logs as Institutional Memory

Module 5's iteration process generated learning. That learning is institutional memory:

• What we tried that didn't work
• What adjustments were made and why
• What feedback drove which changes
• What patterns emerged

Iteration logs capture this memory. Without them, future efforts repeat past mistakes.

The "Why" File: Documenting Reasoning, Not Just Results

Create explicit "why" documentation:

• One document per major design decision
• Context: What was the situation?
• Options: What alternatives were considered?
• Rationale: Why was this option chosen?
• Trade-offs: What was sacrificed for this choice?
• Triggers: What would indicate this decision should be revisited?

The "why" file is the institutional memory that enables intelligent future decisions.

---

Knowledge Refresh Cycles

Regular Review of Documentation Currency

Documentation ages. Regular review keeps it current:

Reviews should verify that documentation matches reality. If they diverge, either documentation or reality needs to change.

Testing Whether Documentation Matches Reality

Documentation review isn't reading—it's testing. Can someone follow the documentation and achieve the expected result?

Methods:

• Have someone unfamiliar try to follow the documentation
• Compare documented procedures to observed practice
• Check documented configurations against actual configurations
• Verify screenshots match current interfaces

Discrepancies reveal stale documentation or undocumented changes—both problems worth discovering.

Updating Training When Systems Change

System changes trigger training questions:

• Does existing training cover the new functionality?
• Do any training materials reference changed elements?
• Will users discover changes through use, or do they need proactive training?
• Are there new competencies that need verification?

Training updates should be part of the change process, not an afterthought.

Archiving Obsolete Knowledge Appropriately

Knowledge becomes obsolete. Old procedures no longer apply. Historical decisions no longer matter. Keeping everything forever creates noise that obscures current guidance.

Archive strategy:

• Remove obsolete content from active documentation
• Move to archive with clear "historical only" marking
• Retain for reference but don't include in active materials
• Delete after appropriate retention period

The goal: current documentation is trustworthy. Historical content is accessible but clearly labeled.

---

Proceed to system lifecycle management.

---

Module 6A: NURTURE — Theory

O — Observe

System Lifecycle

Systems aren't permanent. They have lifecycles—introduction, growth, maturity, decline. Managing systems sustainably means recognizing which stage you're in and planning for the full journey, including the eventual ending.

This section covers how to think about system lifecycle and the decisions that arise at each stage.

---

The System Lifecycle

Introduction → Growth → Maturity → Decline

Systems evolve through predictable stages:

Introduction: The system is new. High attention, intensive support, active learning. Users are adapting, bugs are discovered, calibration is refined. Everything requires effort.

Growth: The system expands. More users, more use cases, broader adoption. Value increases as reach extends. Enhancements add capability.

Maturity: The system stabilizes. Adoption plateaus. Value delivery is consistent. Improvements become incremental rather than transformative. The system is established.

Decline: The system weakens. Technology ages. Business needs shift. Alternatives emerge. Maintaining becomes harder than value justifies. The end approaches.

Different Management Needs at Each Stage

Each stage requires different focus:

Managing a mature system like an introduction wastes resources. Managing a declining system like a growth phase wastes even more.

Recognizing Which Stage You're In

Stage recognition isn't always obvious. Signs to watch:

Introduction indicators:

• High support burden per user
• Frequent bug discoveries
• Active calibration adjustments
• Users still learning

Growth indicators:

• User count increasing
• New use cases emerging
• Enhancement requests accumulating
• Value metrics improving

Maturity indicators:

• Adoption stable
• Value metrics steady
• Maintenance routine
• Enhancements incremental

Decline indicators:

• Performance degrading despite maintenance
• Alternatives gaining attention
• Maintenance burden increasing relative to value
• Users working around rather than with the system

Planning for the Full Lifecycle from the Start

Sustainable systems plan for the full journey:

• Introduction support needs: What resources are required for launch?
• Growth investment: What will expansion require?
• Maturity maintenance: What's the steady-state operating cost?
• Decline transition: How will the system eventually be replaced?

Planning for decline during introduction seems premature. But knowing that decline will come shapes decisions throughout: avoiding lock-in, maintaining documentation, preserving migration paths.

---

When to Iterate

Signs That Iteration Is Appropriate

Iteration makes sense when:

• Core value proposition remains valid
• Problems are addressable through modification
• Architecture can accommodate needed changes
• Investment in iteration is proportional to remaining system life
• Users support continued development

Iteration is enhancement of something working—not repair of something broken or transformation of something obsolete.

Small Improvements That Preserve the Core

Iterative improvements:

• Address specific, identified issues
• Don't require architectural changes
• Can be validated quickly
• Build on existing capability
• Maintain system coherence

Small, frequent improvements compound. A 2% improvement monthly becomes 27% annually. Iteration is the mechanism of compounding.

The Build-Measure-Learn Cycle in Operations

Module 5's build-measure-learn cycle continues in operations:

Build: Implement the improvement Measure: Track impact on relevant metrics Learn: Interpret results, decide next action

The rhythm changes—operational cycles are typically longer than prototype cycles—but the discipline remains. Changes are tested, measured, and evaluated, not assumed to be improvements.

Incremental Enhancement vs. Maintenance

Distinguish enhancement from maintenance:

Maintenance: Preserving current capability. Bug fixes, calibration, documentation updates, security patches. Keeps the system working as intended.

Enhancement: Expanding capability. New features, improved functionality, additional use cases. Makes the system work better.

Both are necessary. But they have different justifications, different budgets, and different governance. Conflating them creates confusion about what work is happening and why.

---

When to Rebuild

Signs That Fundamental Reconstruction Is Needed

Rebuild is appropriate when:

• The core architecture can no longer accommodate requirements
• Technical debt has accumulated past maintainability
• The underlying platform is end-of-life
• Business needs have fundamentally changed from original design
• The cost of iteration exceeds the cost of reconstruction

Rebuild isn't failure—it's recognition that the current foundation has served its purpose and a new foundation is needed.

Technical Debt Accumulation Past Recovery

Technical debt—shortcuts and workarounds that create future maintenance burden—accumulates in every system. Small debts are manageable. But debt compounds.

When technical debt reaches critical levels:

• Every change is harder than it should be
• Changes introduce unexpected side effects
• Simple improvements require disproportionate effort
• The architecture fights against modifications

At this point, paying down debt through iteration may be more expensive than starting fresh.

Business Changes That Outpace Original Design

Systems are designed for specific business contexts. When business changes, systems may not fit:

• Products or services fundamentally changed
• Customer segments shifted
• Regulatory requirements transformed
• Competitive dynamics altered
• Organizational structure reorganized

A system designed for yesterday's business may obstruct today's operations. Rebuild creates a system for current needs.

The Rebuild vs. Iterate Decision Framework

When multiple factors favor rebuild, the decision becomes clearer. When factors are mixed, deeper analysis is needed.

---

When to Retire

Signs That a System Should Be Decommissioned

Retirement is appropriate when:

• The problem the system solves no longer exists
• Better alternatives have emerged and been adopted
• Maintenance cost exceeds value delivered
• The system creates more friction than it removes
• Regulatory or security requirements can no longer be met

Retirement isn't failure—it's recognition that the system's purpose is complete.

The Courage to End What Isn't Working

Organizations often prolong systems past usefulness:

• Sunk cost fallacy: "We invested so much..."
• Fear of transition: "What if the replacement is worse?"
• Inertia: "It's always been there..."
• Unclear ownership: No one has authority to end it

Ending requires courage. But continuing systems that should end wastes resources, frustrates users, and blocks better alternatives.

Retirement Planning: Data Migration, Transition Support

Retirement isn't just "turn it off." It requires planning:

Data migration: What data must be preserved? Where does it go? How is migration validated?

Transition support: What replaces the retired system? How do users learn the alternative? What's the transition timeline?

Archive: What documentation is retained? What historical records must be kept? Where are they stored?

Decommissioning: How is the system actually turned off? What cleanup is required? Who verifies completion?

Plan retirement as carefully as implementation. A botched retirement creates chaos.

Avoiding the "Zombie System"

Zombie systems persist without purpose. They're not actively maintained, not officially retired, just... there. Users work around them. IT keeps them running. No one owns them or ends them.

Zombie systems waste resources, create confusion, and represent organizational inability to make decisions.

Regular lifecycle reviews should identify zombies. Each system should be clearly: actively supported, planned for retirement, or retired. "Just there" isn't a valid status.

---

Connecting Back to A.C.O.R.N.

Module 6 Feeds Back to Module 2

The A.C.O.R.N. cycle is continuous, not linear.

Module 6's sustainability monitoring may reveal:

• New friction worth assessing (→ Module 2)
• Value calculations that need updating (→ Module 3)
• Workflow designs that need revision (→ Module 4)
• Implementations that need iteration (→ Module 5)
• New sustainability requirements (→ Module 6)

Each discovery feeds back to the appropriate module. The cycle continues.

When Sustainability Monitoring Reveals New Opportunities

Operating a successful system creates learning:

• Adjacent processes that would benefit from similar treatment
• Extensions that would add value
• Problems revealed by the system's success
• Opportunities the original assessment didn't identify

This learning generates new opportunities—candidates for the Module 2 assessment process.

The Continuous Improvement Cycle

A.C.O.R.N. isn't a one-time methodology. It's a continuous practice:

Assess: Identify opportunities Calculate: Quantify value Orchestrate: Design solutions Realize: Build and deploy Nurture: Sustain and improve

Each cycle builds capability. Each success creates foundation for the next. Each lesson informs future efforts.

Portfolio Management: Balancing Maintenance and New Development

Organizations face a perpetual tension:

• Maintenance: Sustaining existing systems
• Development: Building new capabilities

Both compete for resources. Underinvesting in maintenance leads to Brookstone-style deterioration. Underinvesting in development leads to stagnation.

Portfolio management balances these demands:

• What's the maintenance burden of current systems?
• What capacity exists for new development?
• Which systems justify continued investment?
• Which opportunities warrant new implementation?
• How do we avoid overcommitting in either direction?

Module 6 informs this balance by making maintenance requirements visible. Systems with clear sustainability plans have predictable maintenance costs. Systems without them create unpredictable demands.

---

The Long View

Thinking in Years, Not Quarters

Quarterly thinking optimizes for short-term metrics. But systems operate for years. Decisions made for next quarter's numbers may create next year's problems.

Sustainability requires longer horizons:

• What will this system need in two years?
• How will business changes affect it?
• What's the expected useful life?
• When should we start planning for replacement?

Short-term thinking creates long-term debt. Long-term thinking builds lasting capability.

Building Systems That Can Evolve

Systems that last are systems that adapt:

• Modular architecture that allows component replacement
• Clear interfaces that enable integration changes
• Documentation that supports future modification
• Knowledge distribution that survives turnover

Adaptability isn't just a technical quality—it's an organizational quality. Can the organization adapt the system as needs change?

Sustainability as Competitive Advantage

Organizations that sustain their systems well:

• Accumulate capability rather than churning investments
• Compound value over time
• Attract better talent (people prefer well-maintained systems)
• Move faster (solid foundation enables rapid building)

Organizations that sustain poorly:

• Repeatedly rebuild what they already built
• Lose value as systems deteriorate
• Burn out staff fighting chronic problems
• Move slowly (unstable foundation impedes progress)

Sustainability isn't overhead—it's infrastructure that enables everything else.

The Organization That Learns from Its Implementations

Each implementation teaches lessons:

• What worked and what didn't
• How estimates compared to reality
• What patterns recurred
• What capabilities developed

Organizations that capture and apply these lessons improve over time. Their estimation gets better. Their implementations get faster. Their sustainability gets stronger.

This learning is Module 6's ultimate output: not just sustained systems, but an organization that gets better at building and sustaining systems.

---

Connection to What Comes Next

Module 6 completes the A.C.O.R.N. cycle. But the cycle itself doesn't end.

Every sustained system creates:

• Data about what works
• Knowledge about the organization
• Capability for future efforts
• Foundation for additional improvements

The discipline of orchestrated intelligence isn't a project you complete. It's a practice you develop. Each cycle builds on the last. Each implementation strengthens the next.

---

End of Module 6A: NURTURE — Theory

Systems don't maintain themselves. Someone has to care, or no one will.

---

---

Module 6B: NURTURE — Practice

R — Reveal

Introduction

Module 6A established the principles of sustainability. This practice module provides the methodology: how to design monitoring, assign ownership, manage knowledge, and plan for the full system lifecycle—ensuring that what works today continues working tomorrow.

---

Why This Module Exists

The gap between successful deployment and sustained value is where organizations lose their investments.

Module 5 delivered a working system with demonstrated results. R-01 achieved its targets: 71% time reduction, 2.6 percentage point error improvement, near-elimination of Patricia queries. The pilot validated the business case. Production deployment began.

But deployment is a beginning, not an ending. Brookstone Wealth Management had a successful deployment too—a client onboarding system that delivered $240,000 in first-year returns. Eighteen months later, their compliance audit revealed performance worse than pre-implementation. The system worked exactly as designed. What deteriorated was everything around it: the monitoring, the ownership, the knowledge, the attention.

Module 6 provides the discipline to prevent this decay.

The deliverable: A Sustainability Plan with defined ownership, monitoring infrastructure, and knowledge management—a comprehensive framework for preserving the value you've created.

---

Learning Objectives

By completing Module 6B, you will be able to:

1. Design operational monitoring systems that detect problems before they become crises, balancing visibility with sustainable overhead

2. Establish ownership structures with clear accountability, defined authority, and realistic time allocation

3. Create knowledge management infrastructure that survives turnover, distributes expertise, and keeps documentation current

4. Plan for the full system lifecycle including iteration, refresh, and eventual retirement

5. Build a complete Sustainability Plan that can be handed to operations and executed without project team involvement

6. Recognize sustainability failures early through leading indicators and intervention triggers

---

The Practitioner's Challenge

Three forces undermine sustainability:

The Pull of the New

New projects are exciting. Maintenance is mundane. Organizations naturally allocate attention and resources toward building new capabilities rather than preserving existing ones. The pilot that succeeded last quarter becomes invisible—still delivering value, but no longer commanding attention.

The Assumption of Permanence

"It's working" becomes "it will keep working." The system that functioned yesterday is assumed to function tomorrow. This assumption ignores the reality that systems exist in changing environments—staff turnover, business evolution, technology updates, calibration drift. Without active maintenance, deterioration is the default.

The Diffusion of Responsibility

The project team disbands. Operations inherits a system they didn't build. IT assumes the business owns it. The business assumes IT maintains it. In the gap between these assumptions, no one actually does the work of sustained attention.

---

Field Note

An operations director at a manufacturing firm described the moment she realized sustainability required intentional design:

"We had deployed a quality prediction system—AI that flagged likely defects before they happened. First year was fantastic. Error rate dropped by half. The team celebrated. The project managers got promoted. Everyone moved on to the next thing.

"By year two, the model was drifting. The production mix had shifted—we were making different products with different characteristics. The model had been trained on the old mix. No one noticed because no one was watching. We'd stopped monitoring accuracy after the first six months.

"By the time someone ran the numbers again, the system was barely better than random. We were making production decisions based on predictions that were essentially noise. The maintenance cost of fixing it was almost as high as the original implementation.

"Now every deployment includes a sustainability plan before we call it done. Who watches? What do they watch? When do they act? If we can't answer those questions, we haven't finished the project—we've just created a liability."

---

What You're Receiving

Module 6 receives the following from Module 5:

Production Deployment (Complete or In Progress)

For R-01:

• Phased rollout planned (2 waves over 4 weeks)
• Wave 1 completed with 10 representatives
• Full deployment to 22 representatives underway
• All deployment artifacts prepared

Baseline Metrics and Pilot Results

For R-01:

Identified Risks

From Module 5 handoff documentation:

• Policy database staleness (business changes not reflected)
• CRM update compatibility (vendor changes breaking integration)
• Calibration drift (recommendations becoming less accurate over time)
• Knowledge concentration (Patricia still holds tacit expertise)
• Attention drift (monitoring lapsing after novelty fades)

Preliminary Ownership Assignments

From Module 5 production preparation:

• System owner: Customer Service Manager
• Technical owner: CRM Administrator
• Business sponsor: Director of Customer Service
• Executive sponsor: VP of Operations

---

Module Structure

Module 6B proceeds through six stages:

1. Monitoring Design

Translating pilot measurement into sustainable operational monitoring. Which metrics continue? What thresholds trigger action? Who reviews what, and when?

2. Ownership Assignment

Formalizing the ownership structure. Defining roles, responsibilities, authority, and time allocation. Creating accountability that persists beyond project closure.

3. Sustainability Plan

Integrating monitoring, ownership, and maintenance into a comprehensive document that operations can execute independently.

4. Knowledge Management

Designing documentation, training, and cross-training that preserve expertise against turnover. Eliminating single points of failure.

5. Lifecycle Management

Planning for the system's future: iteration schedules, refresh triggers, and eventual retirement criteria.

6. Course Completion

Connecting R-01's journey through all six modules. Establishing the continuous improvement cycle.

---

The R-01 Sustainability Plan

Throughout Module 6B, we complete the R-01 example:

• Module 2 identified R-01 (Returns Bible Not in System) as a high-priority opportunity
• Module 3 quantified the value: $99,916 annual savings
• Module 4 designed the solution: Preparation pattern with automated policy lookup
• Module 5 built it: prototype validated, targets achieved, deployment underway

Module 6 sustains it:

• Designing monitoring that detects drift before value erodes
• Assigning ownership that persists beyond the project team
• Creating knowledge management that survives turnover
• Planning for R-01's evolution as business needs change

By the end of Module 6, R-01 will have a complete sustainability framework—not just a working system, but a system with infrastructure to remain working.

---

Proceed to monitoring design methodology.

---

Module 6B: NURTURE — Practice

O — Observe

Monitoring Design

The pilot measured intensively—daily observations, detailed tracking, comprehensive data collection. That intensity was necessary to prove the case. It's not sustainable for ongoing operations.

This section covers how to translate pilot measurement into operational monitoring that balances visibility with practicality.

---

From Pilot Metrics to Operational Metrics

The Transition Challenge

Pilot measurement is a project activity with dedicated resources. Operational monitoring must be embedded in normal work—sustainable indefinitely, executed by people with other responsibilities.

Which Pilot Metrics Continue

Not all pilot metrics need permanent tracking. Categorize each:

Continue unchanged: Metrics essential for detecting value erosion Reduce frequency: Metrics important but stable enough for less frequent measurement Discontinue: Metrics that were pilot-specific and no longer needed Add new: Operational metrics that weren't relevant during pilot

For R-01:

---

The R-01 Monitoring Framework

Metrics That Continue from Pilot

Primary Value Metrics:

Leading Indicators:

Operational Dashboard Design

The monitoring dashboard should display:

Primary Panel: Current Performance

• Task time (last month): [value] vs. target
• Error rate (last month): [value] vs. target
• Escalation rate (last week): [value] vs. target
• Usage rate (last week): [value] vs. target

Secondary Panel: Trends

• 12-week trend line for each primary metric
• Variance from baseline highlighted

Tertiary Panel: Leading Indicators

• Override rate trend
• Low-confidence percentage
• Support ticket volume
• Calibration age (days since last review)

Alert Panel:

• Any metrics exceeding alert thresholds
• Time in alert state
• Assigned owner for investigation

Alert Thresholds for Each Metric

Define three threshold levels:

Investigation threshold: Something changed. Worth understanding. No emergency. Warning threshold: Something is wrong. Needs attention this week. Critical threshold: Something is seriously wrong. Immediate action required.

For R-01:

Review Schedule

---

Leading Indicator Identification

What Signals Problems Before They're Severe

Leading indicators predict problems in lagging indicators. By the time task time increases, the problem has already affected operations. Leading indicators catch earlier:

Override rate rising: Recommendations are less trusted. Possible calibration drift, policy changes, or accuracy degradation.

Low-confidence recommendations increasing: The system is less certain. May indicate edge cases increasing or model drift.

Support tickets trending up: Users are struggling. May indicate training gaps, interface issues, or accuracy problems.

Patricia queries returning: Users are bypassing the system for expert guidance. May indicate trust erosion or capability gaps.

For R-01: Specific Leading Indicators

Building Early Warning Capability

Early warning requires:

1. Automatic collection: Leading indicators must be collected without manual effort
2. Threshold definition: Know what "normal" looks like to spot abnormal
3. Alert configuration: Trigger notification when thresholds exceeded
4. Response procedure: Know what to do when early warning fires

For R-01:

• Override rate: System logs automatically
• Low-confidence: System logs automatically
• Policy mismatches: Requires user reporting (feedback mechanism)
• Patricia queries: Requires Patricia's tracking or survey

---

Alert and Escalation Design

When to Alert (Thresholds)

Alerts should trigger when:

• A metric exceeds defined threshold
• A metric trends in concerning direction for defined period
• Multiple indicators move together (compound signal)
• A metric changes suddenly (even if still in range)

Alerts should NOT trigger for:

• Normal day-to-day variation
• Single-point anomalies
• Expected seasonal patterns
• Known temporary conditions

Who to Alert (Roles)

What Action to Take (Response Procedures)

Investigation alert:

1. Review relevant data
2. Identify potential cause
3. Determine if action needed
4. Document finding
5. Continue monitoring or escalate

Warning alert:

1. Immediate data review
2. Root cause analysis
3. Develop response plan
4. Implement corrective action
5. Monitor for improvement
6. Report to sponsor

Critical alert:

1. Immediate response team engagement
2. Impact assessment
3. Containment actions (workaround, rollback if needed)
4. Root cause investigation
5. Permanent fix implementation
6. Post-incident review
7. Prevention measures

Avoiding Alert Fatigue

Too many alerts means no alerts. Prevent fatigue by:

• Setting thresholds that mean something (not hair-trigger)
• Consolidating related alerts
• Distinguishing investigation from emergency
• Tuning thresholds based on experience
• Regular alert hygiene reviews

---

Monitoring Documentation

What to Track

Where to Track It

Who Reviews It

How Often

---

R-01 Monitoring Dashboard Specification

Dashboard Layout

+---------------------------------------------+
|  R-01 OPERATIONS DASHBOARD                  |
|  Last Updated: [timestamp]                  |
+---------------------------------------------+
|                                             |
|  CURRENT PERFORMANCE          ALERTS        |
|  +------------------+        +----------+   |
|  | Task Time  4.1m  |        | [count]  |   |
|  | Target     <5m   |        | active   |   |
|  | Status     ✓     |        | alerts   |   |
|  +------------------+        +----------+   |
|  +------------------+                       |
|  | Error Rate 1.7%  |        LAST REVIEW    |
|  | Target     <2%   |        [date]         |
|  | Status     ✓     |        [owner]        |
|  +------------------+                       |
|  +------------------+                       |
|  | Escalation 4.8%  |                       |
|  | Target     <5%   |                       |
|  | Status     ✓     |                       |
|  +------------------+                       |
|  +------------------+                       |
|  | Usage      91%   |                       |
|  | Target     >80%  |                       |
|  | Status     ✓     |                       |
|  +------------------+                       |
|                                             |
|  LEADING INDICATORS                         |
|  +------------------+------------------+    |
|  | Override Rate    | 10.2% (normal)   |    |
|  | Low Confidence   | 7.3% (normal)    |    |
|  | Patricia Queries | 2.4/day (normal) |    |
|  | Calibration Age  | 12 days          |    |
|  +------------------+------------------+    |
|                                             |
|  12-WEEK TRENDS                             |
|  [Trend lines for primary metrics]          |
|                                             |
+---------------------------------------------+

Alert Configuration

Monthly Report Template

R-01 MONTHLY PERFORMANCE REPORT
Month: ___________  Prepared by: ___________

EXECUTIVE SUMMARY:
[2-3 sentences on overall health]

VALUE METRICS:
| Metric      | Target | This Month | Prior Month | Trend |
|-------------|--------|------------|-------------|-------|
| Task Time   | <5 min |            |             |       |
| Error Rate  | <2%    |            |             |       |
| Escalation  | <5%    |            |             |       |
| Usage       | >80%   |            |             |       |

LEADING INDICATORS:
| Indicator        | Normal | This Month | Status |
|------------------|--------|------------|--------|
| Override Rate    | 8-12%  |            |        |
| Low Confidence   | 5-10%  |            |        |
| Patricia Queries | <3/day |            |        |

ISSUES AND ACTIONS:
[List any issues encountered and actions taken]

NEXT MONTH FOCUS:
[Planned activities, known risks]

RECOMMENDATION:
[ ] Continue normal monitoring
[ ] Investigate [specific area]
[ ] Escalate to [stakeholder]

---

Proceed to ownership assignment.

---

Module 6B: NURTURE — Practice

O — Operate

Ownership Assignment

Monitoring detects problems. Ownership ensures someone responds. Without clear ownership, alerts become noise—noticed, perhaps, but not acted upon.

This section covers how to establish ownership that actually works: roles with defined responsibilities, authority commensurate with accountability, and time to do the work.

---

R-01 Ownership Structure

The Ownership Roles

Four distinct roles support R-01 sustainability:

System Owner: Customer Service Manager

Who: The manager responsible for returns processing operations.

Why this person: Closest to the work. Sees daily operations. Knows the representatives. Can detect problems through direct observation before metrics show them. Has authority to make operational decisions.

Responsibilities:

• Reviews operations dashboard weekly
• Responds to alerts within defined timeframes
• Makes operational decisions (process adjustments, training priorities)
• Escalates issues beyond operational scope
• Represents system interests in department decisions
• Maintains relationship with technical support

Time allocation: 2-3 hours per week during normal operations; more during issues.

Technical Owner: CRM Administrator

Who: The administrator responsible for CRM configuration and maintenance.

Why this person: Understands how the system works technically. Can troubleshoot, reconfigure, and coordinate with IT. Maintains technical health.

Responsibilities:

• Monitors system health (availability, performance)
• Performs routine maintenance (sync verification, backup confirmation)
• Troubleshoots technical issues
• Implements approved configuration changes
• Coordinates with IT for infrastructure issues
• Maintains technical documentation

Time allocation: 1-2 hours per week during normal operations; more during technical issues.

Business Sponsor: Director of Customer Service

Who: The director with authority over customer service operations and budget.

Why this person: Has the authority to allocate resources, approve changes, and make decisions that exceed operational scope. Represents business interests.

Responsibilities:

• Reviews monthly performance reports
• Approves enhancement requests
• Resolves cross-functional issues
• Advocates for resources when needed
• Makes strategic decisions about system future
• Connects system performance to business objectives

Time allocation: 1-2 hours per month during normal operations; more during strategic decisions.

Executive Sponsor: VP of Operations

Who: The VP with ultimate authority over operations and budget.

Why this person: Can resolve conflicts that exceed director authority. Connects system to organizational strategy. Provides executive visibility.

Responsibilities:

• Reviews quarterly strategic assessments
• Approves significant budget requests
• Resolves escalated conflicts
• Champions system value at executive level
• Makes retirement/replacement decisions
• Ensures organizational commitment

Time allocation: 30 minutes per quarter during normal operations; more during major decisions.

---

RACI Matrix for R-01

RACI clarifies who does what for each task:

• Responsible: Does the work
• Accountable: Owns the outcome (one per task)
• Consulted: Provides input before action
• Informed: Notified after action

Operational Tasks

Maintenance Tasks

Improvement Tasks

Strategic Tasks

---

Time Allocation

Realistic Time Requirements

Ownership requires actual time, not just nominal assignment.

Integrating Ownership into Existing Responsibilities

Ownership cannot simply be added to full workloads. Either:

• Reduce other responsibilities proportionally
• Accept that sustainability will suffer
• Assign to someone with capacity

For R-01:

• Customer Service Manager: Sustainability monitoring replaces some direct supervision time (appropriate—monitoring the system IS managing the operation)
• CRM Administrator: R-01 maintenance becomes part of standard CRM duties
• Director: Monthly reviews replace existing ad-hoc status discussions
• VP: Quarterly reviews integrated into operations review cadence

When Dedicated Resources Are Needed

Consider dedicated resources when:

• System complexity exceeds part-time management capacity
• System criticality demands constant attention
• Multiple systems require coordinated oversight
• Sustainability requirements exceed available capacity

R-01 does not require dedicated resources—the complexity and criticality are manageable within existing roles. If Lakewood implements additional AI-augmented processes, portfolio-level oversight may eventually justify dedicated capacity.

---

Succession Planning

Backup for Each Owner Role

Every owner role needs a backup who can step in during absence or permanent transition.

Handoff Procedures

When ownership transitions (temporary or permanent):

Immediate handoff (absence):

1. Notify backup of absence period
2. Ensure access to systems and documentation
3. Brief on current status and pending items
4. Define escalation for issues beyond backup authority
5. Confirm contact method for urgent matters

Planned transition (role change):

1. Two-week overlap period minimum
2. Joint review of all documentation
3. Introduction to key contacts
4. Shadow current owner through review cycles
5. Graduated responsibility transfer
6. Formal handoff meeting with key stakeholders
7. Post-transition support availability (30 days)

Knowledge Transfer Requirements

For each ownership role, document:

• Regular activities and their schedules
• Decision-making frameworks used
• Key contacts and relationships
• Historical context (why things are the way they are)
• Common issues and resolutions
• Escalation triggers and paths

Trigger Events for Succession

---

Governance Structure

Review Meeting Schedule

Decision Rights

Escalation Procedures

Change Management Process

For changes to R-01:

1. Request: Documented request with rationale
2. Assessment: Technical and operational impact review
3. Approval: Per decision rights matrix
4. Implementation: Scheduled with appropriate oversight
5. Verification: Testing and validation
6. Documentation: Updated materials and training
7. Communication: User notification if affected

---

Ownership Assignment Template

OWNERSHIP ASSIGNMENT DOCUMENT

System: ________________________________
Effective Date: ________________________
Document Version: ______________________

SYSTEM OWNER
Name: _________________________________
Title: _________________________________
Backup: ________________________________

Responsibilities:
[ ] Dashboard review (frequency: ________)
[ ] Alert response
[ ] Operational decisions
[ ] Escalation when appropriate
[ ] User relationship management
[ ] Documentation ownership

Time Allocation: _______ hours/week

TECHNICAL OWNER
Name: _________________________________
Title: _________________________________
Backup: ________________________________

Responsibilities:
[ ] System health monitoring
[ ] Routine maintenance
[ ] Technical troubleshooting
[ ] Configuration management
[ ] IT coordination
[ ] Technical documentation

Time Allocation: _______ hours/week

BUSINESS SPONSOR
Name: _________________________________
Title: _________________________________
Backup: ________________________________

Responsibilities:
[ ] Performance review (frequency: ________)
[ ] Enhancement approval
[ ] Resource allocation
[ ] Strategic decisions
[ ] Cross-functional coordination

Time Allocation: _______ hours/month

EXECUTIVE SPONSOR
Name: _________________________________
Title: _________________________________
Backup: ________________________________

Responsibilities:
[ ] Strategic assessment (frequency: ________)
[ ] Major decision approval
[ ] Executive visibility
[ ] Conflict resolution

Time Allocation: _______ hours/quarter

GOVERNANCE
Weekly Review: _____ (day/time)
Monthly Review: _____ (date)
Quarterly Review: _____ (schedule)

SIGNATURES

System Owner: __________________ Date: ________
Technical Owner: ________________ Date: ________
Business Sponsor: _______________ Date: ________
Executive Sponsor: ______________ Date: ________

---

Proceed to sustainability plan.

---

Module 6B: NURTURE — Practice

O — Operate

The R-01 Sustainability Plan

This section provides the complete R-01 Sustainability Plan as a worked example. The plan integrates monitoring, ownership, knowledge management, and lifecycle planning into a single document that operations can execute independently.

Learners should adapt this template for their own opportunities.

---

R-01 Sustainability Plan

1. Executive Summary

System Overview

R-01 (Returns Policy Integration) is an AI-augmented system that provides customer service representatives with automated policy recommendations for returns processing. The system integrates with Lakewood Medical Supply's existing CRM to display applicable return policies, confidence indicators, and escalation guidance when representatives process return requests.

Current Status

Key Performance Results

Annual Value Delivered

*Extrapolated from pilot; first year production will confirm.

Sustainability Approach Summary

This plan establishes:

• Monitoring framework to detect value erosion early
• Ownership structure with clear accountability
• Knowledge management to survive turnover
• Lifecycle planning for long-term evolution

---

2. Monitoring Framework

Metrics Dashboard

Primary Value Metrics (Monthly Measurement):

Leading Indicators (Weekly Monitoring):

Alert Thresholds

Review Schedule

Escalation Procedures

---

3. Ownership Structure

Role Assignments

RACI Summary

Decision Authority

Succession Procedures

• Backup assignments documented
• Cross-training completed
• Handoff procedures documented
• 30-day post-transition support commitment

---

4. Knowledge Management

Documentation Inventory

Training Program

Cross-Training Plan

Bus Factor Status

---

5. Lifecycle Planning

Current Lifecycle Stage

Stage: Early Production (Month 2)

Characteristics:

• High attention from ownership
• Active monitoring of all metrics
• Rapid response to issues
• Frequent calibration reviews
• User feedback actively collected

Expected Duration: 3-6 months post-deployment

Transition Indicators to Growth:

• Metrics stable for 3+ months
• Support ticket volume normalized
• User feedback themes addressed
• Calibration rhythm established

Anticipated Evolution

Refresh Schedule

Retirement Criteria

R-01 retirement would be triggered by:

• Business process elimination (returns no longer processed)
• Technology obsolescence (CRM replacement incompatible)
• Superior alternative (better solution available at reasonable cost)
• Value erosion beyond recovery (sustained performance below baseline)
• Cost exceeds value (maintenance burden exceeds benefit)

None of these conditions currently apply.

---

6. Risk Register

Known Risks and Mitigation

Risk Response Triggers

---

7. Budget and Resources

Ongoing Operational Costs

Maintenance Budget

Enhancement Reserve

Total Annual Sustainability Budget: $11,500

ROI Tracking

*Assuming stable performance

Comparison to Implementation Cost

---

8. Approval and Commitment

Plan Approval

This Sustainability Plan is approved by the following:

Review Schedule

Change Control

Modifications to this plan require:

• Documentation of proposed change
• Impact assessment
• Approval by Business Sponsor (significant changes by Executive Sponsor)
• Communication to all owners
• Updated plan distribution

---

Sustainability Plan Template

Learners can adapt the R-01 Sustainability Plan for their own opportunities using the following structure:

[OPPORTUNITY NAME] SUSTAINABILITY PLAN

1. EXECUTIVE SUMMARY
   - System overview
   - Current status
   - Performance results
   - Value delivered
   - Sustainability approach

2. MONITORING FRAMEWORK
   - Metrics dashboard (targets, thresholds)
   - Leading indicators
   - Alert configuration
   - Review schedule
   - Escalation procedures

3. OWNERSHIP STRUCTURE
   - Role assignments
   - RACI matrix
   - Decision authority
   - Succession procedures

4. KNOWLEDGE MANAGEMENT
   - Documentation inventory
   - Training program
   - Cross-training plan
   - Bus factor status

5. LIFECYCLE PLANNING
   - Current stage
   - Evolution timeline
   - Refresh schedule
   - Retirement criteria

6. RISK REGISTER
   - Known risks
   - Mitigation strategies
   - Response triggers

7. BUDGET AND RESOURCES
   - Operational costs
   - Maintenance budget
   - Enhancement reserve
   - ROI tracking

8. APPROVAL AND COMMITMENT
   - Signatures
   - Review schedule
   - Change control

---

Proceed to knowledge management implementation.

---

Module 6B: NURTURE — Practice

O — Operate

Knowledge Management Implementation

Monitoring detects problems. Ownership assigns accountability. But both depend on knowledge—understanding how the system works, why it was designed that way, and how to maintain it. When that knowledge erodes, even good monitoring and strong ownership can't prevent deterioration.

This section covers how to implement knowledge management that preserves expertise against turnover.

---

R-01 Documentation Inventory

User Documentation

Quick Reference Card Contents:

• When the system activates (return request with policy lookup)
• How to read the policy recommendation
• What confidence levels mean
• When to accept vs. override vs. escalate
• How to report issues

Technical Documentation

Operational Documentation

Training Documentation

Decision Rationale Documentation

---

Documentation Maintenance

Update Triggers

Update Responsibility Matrix

Review Schedule

Version Control

All documentation follows version control:

• Version number in document header (v1.0, v1.1, v2.0)
• Change log at end of document
• Previous versions archived (accessible but clearly marked)
• Current version date on all materials

---

Training Program Design

New User Onboarding

Target: New customer service representatives

Format: Self-paced module (15 minutes) + Live Q&A session (30 minutes) + Buddy pairing

Content:

1. What R-01 does and why (3 min)
2. How to use the system (5 min demonstration)
3. Reading recommendations and confidence levels (3 min)
4. When to accept, override, or escalate (3 min)
5. Practice scenarios (integrated throughout)
6. Quiz verification (1 min)

Delivery:

• Self-paced module available in LMS
• Live Q&A scheduled weekly (or as needed for new hires)
• Buddy assigned from pilot group for first week

Verification:

• Quiz score >80% required
• Supervisor observation of first 10 returns with system
• Competency checklist signed off within 2 weeks

Refresher Training Schedule

System Change Training

When the system changes:

1. Assess training impact: Does this change require user behavior change?
2. Develop targeted content: Focus only on what changed
3. Deliver before go-live: Users know what's coming
4. Verify understanding: Quick check or observation
5. Update all materials: Documentation matches new system

Training Effectiveness Verification

---

Cross-Training Implementation

Who Needs Cross-Training

Cross-Training Schedule

Patricia → Keisha (Policy Expertise):

• Weekly 30-minute knowledge transfer sessions (12 weeks)
• Keisha shadows Patricia on complex cases
• Patricia documents decision rationale for edge cases
• Keisha handles complex cases with Patricia available
• Gradual independence over 3 months

CRM Admin → IT Support Lead (Technical):

• Joint maintenance sessions monthly
• Documented procedures reviewed together
• IT Support Lead performs maintenance with oversight (quarterly rotation)
• Emergency procedures walkthrough

System Owner → Senior CS Rep (Operational):

• Shadow weekly operational reviews
• Participate in monthly performance reviews
• Handle alert response with System Owner oversight
• Gradual delegation of routine monitoring

Competency Verification

Bus Factor Improvement Tracking

---

Knowledge Capture Procedures

Capturing Lessons Learned from Issues

When issues are resolved:

1. Document the issue (what happened, when, impact)
2. Document the resolution (what fixed it, why it worked)
3. Identify prevention (what would have caught this earlier)
4. Update relevant documentation:
   • Troubleshooting Guide (if technical)
   • FAQ (if user-facing)
   • Monitoring procedures (if detection gap)
5. Share with relevant parties

Issue Log Template:

ISSUE LOG ENTRY

Date: __________ Issue ID: __________
Reported By: __________ Severity: __________

DESCRIPTION:
What happened: ________________________________
When noticed: ________________________________
Impact: ________________________________

RESOLUTION:
Root cause: ________________________________
Fix applied: ________________________________
Time to resolve: ________________________________

PREVENTION:
What would have caught this earlier: ________________
Documentation updated: [ ] Yes [ ] No [ ] N/A
Monitoring updated: [ ] Yes [ ] No [ ] N/A
Training updated: [ ] Yes [ ] No [ ] N/A

KNOWLEDGE CAPTURED:
Lessons learned: ________________________________
Shared with: ________________________________

Updating Decision Rationale Documentation

When significant decisions are made:

• Document the decision
• Document the alternatives considered
• Document why this option was chosen
• Document what would trigger reconsideration

Add to Decision Rationale document with date stamp.

Recording Workarounds

When users develop workarounds:

1. Capture what they're doing differently
2. Understand why (what need isn't being met)
3. Decide: address the underlying issue or document the workaround
4. If documenting workaround: add to FAQ with clear guidance
5. Track for future enhancement consideration

Archiving Obsolete Content

When documentation becomes obsolete:

1. Remove from active locations
2. Move to archive folder with "ARCHIVED" prefix
3. Add note: "Archived [date] - replaced by [new document]"
4. Retain for reference period (typically 2 years)
5. Delete after retention period

---

Knowledge Management Templates

Documentation Inventory Template

DOCUMENTATION INVENTORY

System: ________________________
Last Updated: ________________________

USER DOCUMENTATION
| Document | Version | Location | Owner | Last Review |
|----------|---------|----------|-------|-------------|
|          |         |          |       |             |

TECHNICAL DOCUMENTATION
| Document | Version | Location | Owner | Last Review |
|----------|---------|----------|-------|-------------|
|          |         |          |       |             |

OPERATIONAL DOCUMENTATION
| Document | Version | Location | Owner | Last Review |
|----------|---------|----------|-------|-------------|
|          |         |          |       |             |

TRAINING DOCUMENTATION
| Document | Version | Location | Owner | Last Review |
|----------|---------|----------|-------|-------------|
|          |         |          |       |             |

NEXT REVIEW DATE: ________________________

Training Checklist Template

TRAINING COMPLETION CHECKLIST

Trainee: ________________________
Start Date: ________________________
Trainer/Supervisor: ________________________

PRE-TRAINING
[ ] System access granted
[ ] Training materials provided
[ ] Buddy assigned (if applicable)

TRAINING COMPLETION
[ ] Self-paced module completed
    Score: ________ (>80% required)
[ ] Live Q&A session attended
[ ] Quick Reference Card provided

COMPETENCY VERIFICATION
[ ] Supervisor observation completed (first 10 transactions)
[ ] Competency checklist items verified:
    [ ] Can locate policy recommendation
    [ ] Understands confidence levels
    [ ] Knows when to override
    [ ] Knows when to escalate
    [ ] Can report issues

SIGN-OFF
Trainee signature: ______________ Date: __________
Supervisor signature: ______________ Date: __________

NOTES:
________________________________
________________________________

---

Proceed to lifecycle management.

---

Module 6B: NURTURE — Practice

O — Operate

Lifecycle Management

Systems don't exist in steady state forever. They evolve through stages—intensive early attention, growth and expansion, stable maturity, and eventual decline. Managing sustainability means recognizing which stage you're in and adjusting approach accordingly.

This section covers how to manage R-01 through its lifecycle and connect back to the continuous improvement cycle.

---

R-01 Current Lifecycle Stage

Stage: Early Production

R-01 is in early production—the first months after deployment when the system requires intensive attention.

Characteristics of Early Production:

• High ownership engagement
• Active monitoring of all metrics
• Rapid response to issues
• Frequent calibration reviews
• User feedback actively collected
• Support readily available
• Documentation being refined based on real usage

Expected Duration: 3-6 months post-deployment

Current Status (Month 2):

Transition Triggers to Growth Stage

R-01 will transition to Growth stage when:

Estimated transition: Month 4-6

---

Lifecycle Stage Planning

Stage Transitions Expected

Management Approach at Each Stage

Early Production (Current):

• Weekly operational reviews
• Daily dashboard monitoring
• Monthly calibration review
• Active feedback collection
• Rapid issue response
• Documentation refinement

Growth:

• Bi-weekly operational reviews
• Weekly dashboard monitoring
• Quarterly calibration review
• Enhancement pipeline active
• Possible expansion to new use cases
• Optimization of efficiency

Maturity:

• Monthly operational reviews
• Weekly dashboard scan
• Quarterly calibration review
• Maintenance-focused
• Minimal enhancements
• Steady-state operations

Decline:

• Quarterly reviews
• Replacement planning active
• Migration preparation
• Reduced investment
• Transition focus

Resource Requirements at Each Stage

*Decline requires more sponsor time for transition decisions.

Warning Signs of Premature Decline

---

Enhancement Pipeline

Features Deferred from MVP

During Module 5 implementation, features were deferred to achieve minimum viable prototype:

Prioritization Criteria

Enhancements are prioritized based on:

Implementation Approach for Enhancements

1. Collect: Gather enhancement requests through feedback mechanism
2. Analyze: Assess against prioritization criteria
3. Prioritize: Rank in enhancement pipeline
4. Plan: Scope implementation approach
5. Approve: Business sponsor approval for budget/resources
6. Implement: Follow Module 5 methodology (prototype → test → deploy)
7. Validate: Measure impact against projection

Avoiding Scope Creep in Maintenance Mode

Rule: If it takes more than a day, it goes through the enhancement pipeline.

---

Refresh Cycles

Policy Database Refresh

Frequency: Weekly (automated) + Quarterly review (manual)

Weekly Automated Sync:

• Policy database syncs with source system
• Changes logged automatically
• Alerts for significant changes

Quarterly Manual Review:

• Verify sync is capturing all changes
• Review policy categories for drift
• Assess whether new policies need system handling
• Update calibration if needed

Owner: Technical Owner (sync), System Owner (review)

Calibration Review Schedule

Calibration Triggers (outside schedule):

• Override rate >15% for 2+ weeks
• Low-confidence recommendations >15%
• Policy mismatch reports >5/week
• New policy category introduced

Integration Testing After Connected System Updates

When CRM or Order Management updates:

1. Pre-update: Review release notes for potential impact
2. Testing: Test R-01 functions in staging/test environment
3. Validation: Verify key integrations work correctly
4. Deployment: Monitor closely after update goes live
5. Documentation: Update technical docs if behavior changed

Owner: Technical Owner

Annual Strategic Review

Each year, conduct comprehensive strategic review:

• Compare current performance to original baseline
• Assess value delivered vs. projected
• Review lifecycle stage assessment
• Evaluate enhancement pipeline priorities
• Consider technology and business changes
• Decide: continue as-is, enhance significantly, rebuild, or retire
• Update Sustainability Plan

Owner: Business Sponsor with all owners

---

Iterate vs. Rebuild vs. Retire Decision Framework

Criteria for Each Decision

Decision Matrix

Decision Process

1. Annual strategic review triggers assessment
2. Gather data: performance, costs, business context, alternatives
3. Apply decision matrix
4. Develop recommendation with rationale
5. Present to Executive Sponsor
6. Decide and document
7. Execute decision (iterate plan, rebuild project, or retirement plan)

R-01 Application

Current Assessment: Iterate

What would trigger rebuild: CRM replacement with incompatible platform; fundamental change to returns process architecture.

What would trigger retire: Elimination of returns processing; acquisition by company with different systems; AI capability that makes this approach obsolete.

---

Connecting to New Opportunities

When Sustainability Monitoring Reveals New Opportunities

Operating R-01 generates learning that may reveal new opportunities:

Feeding Back to Module 2 (ASSESS)

When new opportunities are identified:

1. Document the observation and hypothesis
2. Preliminary friction assessment (is this worth investigating?)
3. Add to opportunity pipeline
4. Prioritize against other opportunities
5. If selected: enter Module 2 Assessment process

Connection to A.C.O.R.N.:

• Module 6 monitoring reveals friction → Module 2 assesses
• Module 2 validates opportunity → Module 3 calculates value
• Module 3 builds business case → Module 4 designs solution
• Module 4 produces blueprint → Module 5 implements
• Module 5 deploys → Module 6 sustains
• Cycle continues

The Continuous Improvement Cycle

R-01 is not a one-time project. It's the first iteration of a continuous improvement cycle:

Cycle 1 (Complete):

• Identified: Returns Bible friction
• Built: R-01 Policy Integration
• Result: 71% time reduction, $109,907 annual value

Potential Cycle 2:

• Opportunity: Similar case display
• Assessment: Does showing similar past cases reduce escalation further?
• If validated: Design, build, deploy enhancement

Potential Cycle 3:

• Opportunity: Learning loop
• Assessment: Can system improve from override patterns?
• If validated: More significant technical implementation

Each cycle builds on the last. Each success creates foundation for the next.

R-01 as Foundation for Additional Improvements

R-01 establishes:

• Infrastructure (CRM integration, policy database)
• Capability (recommendation engine pattern)
• Knowledge (what works for this team)
• Trust (representatives believe AI can help)
• Process (A.C.O.R.N. methodology proven)

Future returns management improvements can build on this foundation rather than starting from scratch.

---

Lifecycle Management Template

LIFECYCLE MANAGEMENT PLAN

System: ________________________
Current Stage: ________________________
Assessment Date: ________________________

CURRENT STAGE CHARACTERISTICS
[ ] High attention / Stabilizing
[ ] Growing / Expanding
[ ] Stable / Maintaining
[ ] Declining / Transitioning

TRANSITION CRITERIA TO NEXT STAGE
| Criterion | Threshold | Current | Gap |
|-----------|-----------|---------|-----|
|           |           |         |     |

RESOURCE PLAN BY STAGE
| Stage | System Owner | Technical Owner | Sponsor |
|-------|--------------|-----------------|---------|
|       |              |                 |         |

REFRESH SCHEDULE
| Refresh Type | Frequency | Owner |
|--------------|-----------|-------|
|              |           |       |

ENHANCEMENT PIPELINE
| Feature | Priority | Estimated Effort | Target Stage |
|---------|----------|------------------|--------------|
|         |          |                  |              |

LIFECYCLE DECISION CRITERIA
Iterate when: ________________________________
Rebuild when: ________________________________
Retire when: ________________________________

NEXT ASSESSMENT DATE: ________________________

---

Proceed to course completion transition.

---

Module 6B: NURTURE — Practice

Transition and Course Completion

What Module 6 Accomplished

Module 6 completed the A.C.O.R.N. cycle by establishing sustainability infrastructure—ensuring that the value created in Modules 2-5 persists beyond the project team's attention.

The Journey Through Module 6:

1. Understood the sustainability imperative

   • Learned from Brookstone's failure: successful deployment that deteriorated
   • Established the anchor principle: systems don't maintain themselves
   • Recognized deployment as beginning, not ending

2. Designed operational monitoring

   • Transitioned from intensive pilot measurement to sustainable operations
   • Identified leading indicators for early warning
   • Established alert thresholds and escalation procedures
   • Created dashboard and reporting infrastructure

3. Established ownership and accountability

   • Assigned clear ownership roles with defined responsibilities
   • Built RACI matrix for all operational activities
   • Designed succession planning for continuity
   • Defined governance structure and decision rights

4. Built knowledge management infrastructure

   • Inventoried all documentation with maintenance schedules
   • Designed training program for new users and refreshers
   • Implemented cross-training to eliminate single points of failure
   • Created procedures for capturing lessons learned

5. Planned for system lifecycle

   • Assessed current lifecycle stage (Early Production)
   • Defined management approach for future stages
   • Established enhancement pipeline and refresh cycles
   • Created decision framework for iterate/rebuild/retire

6. Created the Sustainability Plan

   • Integrated all elements into comprehensive document
   • Established budget and resource requirements
   • Documented risks and mitigation strategies
   • Obtained ownership commitment and approval

---

The R-01 Journey Complete

R-01 has traveled through all six modules of The Discipline of Orchestrated Intelligence:

Module 1: THE PARADOX OF CAPABILITY

Recognized the fundamental challenge: AI capability is abundant, but the ability to orchestrate it wisely is rare. Vance's failed document automation showed what happens when organizations rush to deploy without understanding their own friction.

Key learning: Capability without clarity is dangerous.

Module 2: ASSESS

Mapped organizational friction systematically: Used the Unified Friction Framework to identify where cognitive load, operational drag, and opportunity cost accumulate. Assessed 15+ opportunities against strategic value and implementation complexity.

Selected R-01: Returns Bible Not in System emerged as highest-priority opportunity—high strategic value (customer-facing, frequent, winnable) with manageable complexity.

Key learning: The map is not the territory.

Module 3: CALCULATE

Quantified the value: Applied the Three ROI Lenses (Time, Throughput, Focus) to build a rigorous business case.

R-01 Value Case:

• Time savings: $76,176/year (9.2 minutes saved × 8,280 returns × $1.00/minute)
• Error reduction: $15,480/year (60% error reduction × 360 errors × $43 cost)
• Focus improvement: $8,260/year (75% reduction in Patricia queries)
• Total: $99,916 annual value

Key learning: Proof isn't about being right—it's about being checkable.

Module 4: ORCHESTRATE

Designed the human-AI collaboration: Used the Preparation pattern—AI prepares context (policy recommendations) before the interaction, enabling faster and more accurate human decisions.

R-01 Blueprint:

• Current state: 8 steps, 14-28 minutes, high cognitive load
• Future state: 5-6 steps, 9-14 minutes, AI-augmented decision support
• Integration: CRM-embedded policy recommendations with confidence indicators

Key learning: Design for the person doing the work, not the person reviewing the work.

Module 5: REALIZE

Built, tested, and deployed: Scoped minimum viable prototype, tested with pilot group, iterated based on evidence, prepared for production.

R-01 Results:

Validated value: $109,907/year (10% above projection)

Key learning: One visible win earns the right to continue.

Module 6: NURTURE

Established sustainability: Designed monitoring, assigned ownership, built knowledge management, planned lifecycle.

R-01 Sustainability:

• Monitoring dashboard with leading indicators and escalation
• Ownership structure with succession planning
• Documentation inventory with maintenance schedules
• Cross-training to eliminate Patricia as single point of failure
• Annual sustainability cost: $11,500 against $109,907 value

Key learning: Systems don't maintain themselves. Someone has to care, or no one will.

---

The A.C.O.R.N. Cycle Continues

Module 6 completes one cycle of A.C.O.R.N. But the cycle itself is continuous.

Module 6 Monitoring Reveals New Opportunities

Operating R-01 generates learning:

• Representatives requesting similar case display → potential enhancement
• Patterns in override behavior → calibration opportunities
• Adjacent policy areas (warranty, shipping) → expansion candidates
• Training effectiveness insights → broader onboarding improvements

Each observation is a potential seed for the next cycle.

New Opportunities Return to Module 2

When Module 6 monitoring surfaces a potential opportunity:

1. Document the observation and hypothesis
2. Enter Module 2: Does this pass initial friction assessment?
3. If yes → Continue through ASSESS, CALCULATE, ORCHESTRATE, REALIZE, NURTURE
4. Each cycle builds on previous capability

The Portfolio Evolves Over Time

Organizations don't implement one opportunity forever. They build portfolios:

Year 1: R-01 (Returns Policy Integration) deployed Year 2: Similar Case Display enhancement added; Warranty Policy (W-01) assessed Year 3: W-01 deployed; Exchange Processing (E-01) in design Year 4+: Portfolio of AI-augmented processes operating, each with sustainability infrastructure

Each implementation teaches lessons. Each success creates foundation. The organization's capability compounds.

---

Course Key Principles Summary

Each module established an anchor principle. Together, they form the discipline:

These principles work together:

• Clarity (Module 1) enables accurate assessment (Module 2)
• Assessment enables rigorous calculation (Module 3)
• Calculation enables human-centered design (Module 4)
• Design enables rapid realization (Module 5)
• Realization enables sustained value (Module 6)
• Sustainability generates new opportunities (back to Module 2)

---

What Comes Next

Applying the Methodology to Your Organization

The course has demonstrated the discipline through R-01. Now apply it to your own context:

1. Identify your friction: Where does cognitive load, operational drag, or opportunity cost accumulate in your organization?

2. Assess systematically: Use the Unified Friction Framework to evaluate opportunities against strategic value and implementation complexity.

3. Calculate rigorously: Apply the Three ROI Lenses to build business cases that can be verified, not just believed.

4. Design for humans: Create workflows that augment human judgment rather than replacing or burdening it.

5. Realize quickly: Build minimum viable prototypes, test with real users, iterate based on evidence.

6. Sustain intentionally: Design monitoring, ownership, and knowledge management before declaring victory.

Building Organizational Capability

Individual implementations are valuable. Organizational capability is transformative.

From project to capability:

• First implementation teaches the methodology
• Second implementation refines the approach
• Third implementation becomes standard practice
• Subsequent implementations are routine

Building the infrastructure:

• Assessment templates refined and shared
• Calculation models standardized
• Design patterns documented
• Implementation playbooks created
• Sustainability frameworks replicated

Developing the people:

• Champions who've done it mentor others
• Success stories create organizational learning
• Failure lessons prevent repeated mistakes
• Expertise distributes across the organization

The Discipline as Ongoing Practice

The Discipline of Orchestrated Intelligence isn't a project you complete. It's a practice you develop.

Each cycle builds capability:

• Better at recognizing friction
• Faster at calculating value
• More skilled at human-centered design
• More efficient at implementation
• More reliable at sustainability

Each implementation teaches lessons:

• What works in your context
• Where your organization struggles
• Which patterns to replicate
• Which pitfalls to avoid

Each success creates foundation:

• Technical infrastructure to build on
• Organizational trust in the approach
• Champion network to support adoption
• Proven value to justify investment

---

Closing

The discipline of orchestrated intelligence begins with a recognition: that the power to automate is not the same as the wisdom to orchestrate.

Organizations that mistake capability for competence build fast and fail slow. They deploy what they can, not what they should. They celebrate launches but neglect sustainment. They accumulate technical debt while announcing transformations.

Organizations that develop the discipline do something different. They start with friction, not features. They calculate before they commit. They design for the humans who do the work. They prove value before scaling. They build sustainability from the beginning.

The difference isn't just in outcomes—though outcomes are dramatically better. The difference is in posture. One organization chases capability. The other cultivates judgment.

R-01 is a returns policy lookup system. It saved $109,907 per year for a medical supply company. That's meaningful, but modest.

What's significant is what R-01 represents: proof that the discipline works. Proof that assessment leads to good selections. Proof that calculation enables good decisions. Proof that design can serve humans rather than burden them. Proof that rapid realization actually works. Proof that sustainability can be designed in.

Each proof point creates foundation for the next. Each success earns the right to continue. Each implementation teaches lessons that improve the next.

The discipline of orchestrated intelligence isn't a project you complete. It's a practice you develop. Each cycle builds capability. Each implementation teaches lessons. Each success creates foundation for the next.

The work continues.

---

End of Module 6B: NURTURE — Practice

End of The Discipline of Orchestrated Intelligence

---

---

Module 6B: NURTURE — Practice

T — Test

Measuring Sustainability Quality

Module 5's TEST section measured whether the prototype worked. Module 6's TEST section measures whether the sustainability infrastructure will preserve that success.

This section covers how to validate the Sustainability Plan and track whether sustainability is actually working.

---

Validating the Sustainability Plan

Is Monitoring Comprehensive and Sustainable?

Is Ownership Clearly Assigned with Accountability?

Is Knowledge Management Infrastructure in Place?

Is Lifecycle Planning Realistic?

---

Sustainability Plan Quality Metrics

Monitoring Coverage

Ownership Clarity

Documentation Completeness

Knowledge Distribution (Bus Factor)

---

Leading Indicators for Sustainability

Early Signs That Sustainability Is Working

Early Signs That Sustainability Is Failing

What to Watch in the First 90 Days

90-Day Sustainability Audit Checklist:

• All scheduled reviews held
• Dashboard reviewed daily
• At least one alert responded to (or confirmed none triggered)
• Documentation updated at least once
• Issue log has entries
• Backup has participated in at least one review
• Metrics within target range

---

Lagging Indicators

Evidence That Sustainability Succeeded (6-12 Months)

Evidence That Sustainability Failed

Value Preservation vs. Value Erosion

Threshold for intervention: Any metric below 85% of target for 2+ consecutive periods.

---

Red Flags

Monitoring Lapses

Ownership Gaps

Documentation Staleness

Knowledge Concentration

---

The Sustainability Audit

Periodic Assessment of Sustainability Health

Conduct formal sustainability audit quarterly (first year) then semi-annually.

What to Check

Audit Template

SUSTAINABILITY AUDIT

System: ________________________
Audit Date: ________________________
Auditor: ________________________
Period Covered: ________________________

MONITORING
[ ] Dashboard reviewed on schedule
[ ] All metrics being collected
[ ] Alerts functioning correctly
[ ] Reports generated on schedule
[ ] Escalation procedures followed (if applicable)
Issues: ________________________________

OWNERSHIP
[ ] All owners active
[ ] Reviews held on schedule
[ ] Time allocation adequate
[ ] Backups engaged
[ ] Governance functioning
Issues: ________________________________

KNOWLEDGE
[ ] Documentation current
[ ] Training materials up to date
[ ] Cross-training progressing
[ ] Bus factor at or improving toward target
[ ] Issue log maintained
Issues: ________________________________

PERFORMANCE
[ ] All metrics within target range
[ ] No concerning trends
[ ] Value preserved or improved
[ ] No unresolved issues
Issues: ________________________________

OVERALL ASSESSMENT
[ ] Healthy — continue current approach
[ ] Warning — address identified issues
[ ] Critical — immediate intervention required

RECOMMENDATIONS:
________________________________
________________________________

NEXT AUDIT DATE: ________________________

How Often to Check

Exception: Return to quarterly if warning or critical status identified.

Who Should Audit

Recommended: System Owner conducts routine audits; Business Sponsor reviews annually; Peer or external audit for critical systems or after issues.

---

Proceed to share exercises.

---

Module 6B: NURTURE — Practice

S — Share

Exercises and Course Consolidation

This SHARE section consolidates Module 6 learning and completes the course. The exercises help learners internalize sustainability principles, apply them to their own context, and prepare for ongoing practice.

---

Reflection Prompts

Complete these individually before group discussion.

Prompt 1: A System That Faded

Think of a system, process, or initiative in your organization (or a previous organization) that was successfully implemented but deteriorated over time.

• What was the system?
• What did success look like initially?
• How did you (or the organization) realize it had deteriorated?
• What caused the deterioration? (ownership gaps, monitoring lapses, knowledge loss, other?)
• What would have prevented the fade?

Write 2-3 paragraphs describing this experience.

---

Prompt 2: The Ownership Gap in Your Organization

Consider the systems and processes in your current organization.

• How is ownership typically assigned after projects complete?
• Are there systems that seem to have no clear owner?
• What happens when something goes wrong with an "unowned" system?
• How does your organization handle the project-to-operations transition?

Identify one system that would benefit from clearer ownership and describe what that ownership structure should look like.

---

Prompt 3: Knowledge Transfer in Your Organization

Reflect on how your organization handles expertise and knowledge.

• When key people leave, how much knowledge leaves with them?
• What documentation exists for critical systems? Is it current?
• How are new employees trained on existing systems?
• Are there "Patricias" in your organization—single points of expertise that everyone depends on?

Identify one knowledge vulnerability and describe how you would address it.

---

Prompt 4: Your Personal Tendency

Some people are natural builders—they love creating new things. Others are natural maintainers—they find satisfaction in keeping things running well.

• Which tendency describes you better?
• How does this tendency affect your behavior after a project launches?
• What do you need to consciously do to balance your natural tendency?
• How might you partner with someone of the opposite tendency?

Write honestly about your preferences and what they mean for sustainability.

---

Prompt 5: Sustainability for Your Capstone Opportunity

Think about the opportunity you've been developing through this course (or would develop if applying this methodology).

• What monitoring would be essential to preserve value?
• Who should own the system once deployed?
• What knowledge needs to be protected against turnover?
• What lifecycle stage would it enter, and how long until maturity?

Draft a one-page sustainability approach for your opportunity.

---

Peer Exercise: Sustainability Plan Review

Format: Pairs, 45 minutes total

Setup (5 minutes)

• Pair with a partner
• Exchange your Sustainability Plans (or sustainability approaches from Reflection Prompt 5)
• Each person will review their partner's plan

Individual Review (15 minutes) Review your partner's plan with these questions:

Monitoring:

• Are the right metrics being tracked?
• Are leading indicators identified?
• Is the monitoring sustainable (not too burdensome)?
• Are escalation paths clear?

Ownership:

• Is ownership clearly assigned?
• Does the owner have time and authority?
• Is succession addressed?
• Is governance realistic?

Knowledge:

• Is documentation adequate?
• Is training designed?
• Are single points of failure addressed?
• Are update triggers defined?

Lifecycle:

• Is the current stage correctly identified?
• Are future stages anticipated?
• Are refresh cycles scheduled?
• Are retirement criteria considered?

Note 3-5 observations (strengths and gaps).

Partner Discussion (20 minutes) Share your observations with each other:

• What did you find strong in your partner's plan?
• What gaps or risks did you identify?
• What would you suggest improving?
• What did you learn from reviewing their approach?

Debrief (5 minutes) Reflect individually:

• What will you change in your plan based on this feedback?
• What did you learn from reviewing someone else's approach?

---

Teach-Back Assignment

The Assignment

Explain the principle "systems don't maintain themselves" to someone outside this course. This could be a colleague, manager, friend, or family member who works in any organization.

The Conversation (20-30 minutes)

1. Explain the concept (5 minutes)

   • Systems that work today won't automatically work tomorrow
   • Deployment is the beginning, not the end
   • Value must be defended, not just created
   • Someone has to own sustainability, or no one will

2. Help them identify an example (10 minutes)

   • Ask them about a system, process, or tool in their work that has deteriorated
   • What happened? How did they notice?
   • What was missing? (Ownership? Monitoring? Knowledge management?)

3. Discuss prevention (10 minutes)

   • What would have prevented the deterioration?
   • Who should have owned it?
   • What monitoring would have caught problems early?
   • How could knowledge have been protected?

Reflection

After the conversation, write a brief reflection:

• Who did you talk to? What was their context?
• What example did they identify?
• What surprised you about the conversation?
• How did explaining the concept deepen your own understanding?
• What would you explain differently next time?

---

Discussion Questions

Use these for group discussion or individual reflection.

Question 1: Why Maintenance Gets Neglected

Organizations consistently underinvest in maintaining existing systems while overinvesting in building new ones. Why does this pattern persist? What organizational or psychological factors drive it? What would change this pattern?

---

Question 2: Attention on Systems That Work

When a system is "working," it becomes invisible—no longer commanding attention. How do you maintain appropriate attention on systems that aren't causing problems? How do you prevent "working" from becoming "neglected"?

---

Question 3: Sustainability vs. Innovation Investment

Organizations have limited resources. Every dollar spent on sustainability is a dollar not spent on new development. How do you determine the right balance? What principles should guide this allocation?

---

Question 4: Retire vs. Rebuild

Knowing when to end something is as important as knowing how to sustain it. What makes retirement decisions difficult? How do you know when a system should be retired rather than rebuilt or enhanced? What organizational dynamics make retirement harder than it should be?

---

Question 5: Organizational Structures for Sustainability

Some organizations are better at sustaining their implementations than others. What organizational structures, roles, or practices support sustainability? What would you implement in your organization to improve sustainability?

---

Course Completion: Key Takeaways

The Full A.C.O.R.N. Cycle

The Six Module Principles

1. Capability without clarity is dangerous — The power to automate is not the same as the wisdom to orchestrate.

2. The map is not the territory — Your understanding of organizational friction is incomplete until you investigate systematically.

3. Proof isn't about being right—it's about being checkable — Calculations should enable verification, not just belief.

4. Design for the person doing the work, not the person reviewing the work — Human-centered design serves the practitioner, not the approver.

5. One visible win earns the right to continue — Demonstrated value, not promised value, creates organizational permission.

6. Systems don't maintain themselves. Someone has to care, or no one will. — Sustainability requires intentional design, not hopeful assumption.

The Discipline as Practice

The Discipline of Orchestrated Intelligence is not a methodology you execute once. It's a practice you develop over time.

• Each cycle teaches lessons
• Each implementation builds capability
• Each success creates foundation for the next
• The organization's judgment improves with practice

What Comes Next

• Apply the methodology to your own organization
• Build capability through repeated cycles
• Develop champions who can mentor others
• Create organizational infrastructure to support the discipline
• Return to the principles when you get stuck

The work continues.

---

Final Reflection

Before completing the course, write a brief reflection:

1. What was the most valuable insight you gained from this course?

2. What will you do differently in your work as a result?

3. What capability will you develop first?

4. Who will you share this with?

---

End of Module 6B: NURTURE — Practice

The discipline of orchestrated intelligence isn't a project you complete. It's a practice you develop. Each cycle builds capability. Each implementation teaches lessons. Each success creates foundation for the next. The work continues.

---