Method of procedure (mop)

A Method of Procedure is a detailed, step-by-step document that describes exactly how to perform a specific operation, typically for critical system changes, deployments, or maintenance activities. MOPs specify every action, verification step, and rollback procedure needed to execute a change safely. They're most common in environments where errors are costly - telecommunications, data centers, financial systems, and other mission-critical infrastructure.

Why it matters

Complex operations go wrong when steps are missed, sequences are incorrect, or contingencies aren't planned. The consequences in critical systems can be severe - outages, data loss, security breaches, or safety incidents. Human memory and improvisation aren't reliable enough for high-stakes operations.

MOPs address this by documenting procedures so thoroughly that different operators can execute them identically. They capture institutional knowledge, reduce dependence on specific individuals, and create a reviewable record of what should happen.

For product managers working with critical systems, understanding MOPs helps set realistic expectations for change velocity and appreciate why certain operations require extensive preparation.

Mop components

Comprehensive MOPs include several elements.

Purpose and scope. What does this procedure accomplish? What systems does it affect? What triggers its use?

Prerequisites. What conditions must exist before starting? What approvals are needed? What resources must be available?

Step-by-step instructions. Detailed actions in exact sequence. Each step should be unambiguous and verifiable.

Verification steps. How to confirm each step succeeded before proceeding. What to check and what results indicate success.

Timing estimates. How long should each step take? What's the total expected duration?

Rollback procedures. How to undo changes if something goes wrong. At what point is rollback no longer possible?

Contact information. Who to contact for escalation at each stage.

Success criteria. How to confirm the entire procedure succeeded.

Creating mops

Effective MOPs require careful development.

Start with expert knowledge. Document how experienced operators actually perform the procedure, not how it theoretically should be done.

Be extremely specific. "Update the configuration" is too vague. "Edit /etc/app/config.yaml using vim and change the 'max_connections' value from 100 to 200" is specific.

Include verification. After each significant step, include how to verify success before proceeding.

Plan for failure. At each step, what could go wrong? How would you detect it? How would you recover?

Test the MOP. Have someone unfamiliar with the procedure follow it exactly. Gaps and ambiguities become obvious.

Version control. MOPs should be versioned. When systems change, MOPs must be updated.

When mops are used

MOPs are appropriate in specific contexts.

Critical systems. Systems where failure has significant business, safety, or regulatory impact justify MOP overhead.

Infrequent operations. Rarely performed procedures are easily forgotten. MOPs preserve knowledge.

High-risk changes. Changes with significant potential for harm warrant detailed planning.

Regulated environments. Industries with compliance requirements often mandate documented procedures.

Knowledge transfer. When operations must be performed by people other than those who designed the system.

Mops and automation

MOPs and automation have a complex relationship.

MOPs can describe automation. The procedure might be "run deployment script X" - the automation itself is documented in the MOP.

Automation can replace MOPs. When operations are fully automated and reliable, detailed human procedures become unnecessary.

MOPs remain for edge cases. Even highly automated systems need procedures for unusual situations automation doesn't handle.

MOPs document what to do when automation fails. Backup procedures for when automated systems don't work as expected.

Modern DevOps practices favor automation over manual MOPs, but critical systems often maintain MOPs for situations where automation is insufficient or unavailable.

Mop reviews and approvals

In formal environments, MOPs go through review processes.

Peer review. Technical colleagues verify accuracy and completeness.

Change advisory board. Cross-functional review assesses risk and coordination needs.

Stakeholder approval. Those accountable for affected systems sign off.

Scheduling. Changes are scheduled for appropriate windows with appropriate personnel available.

This governance adds overhead but reduces risk for critical operations.

Common mop challenges

Several patterns cause MOP problems.

Outdated procedures. Systems change but MOPs don't. Following old procedures on new systems causes problems.

Insufficient detail. Procedures that assume too much knowledge fail when executed by others.

Untested procedures. MOPs that haven't been tested in realistic conditions may have hidden gaps.

Over-reliance on MOPs. Following procedures without understanding them leads to poor judgment when unexpected situations arise.

MOP proliferation. Too many MOPs become unmaintainable. Focus on critical operations.

Mops in product context

For most software products, formal MOPs are overkill. But MOP thinking applies.

Runbooks are lighter-weight operational documentation for routine tasks.

Deployment checklists ensure consistent release processes.

Incident response procedures document how to handle outages.

Recovery procedures describe how to restore from backups or failures.

The principle - documented, tested, step-by-step procedures for critical operations - applies even when full MOP formality isn't justified.

The goal isn't bureaucracy but reliability. When operations are important enough that failure is unacceptable, the discipline of MOPs helps ensure success.