Continuity of Operations Software Problems: The 7 That Leave You Improvising, and How to Avoid Them

Why does trying to model every department at once fail so often?

The biggest scope failure in continuity of operations (COOP) builds is starting with a complete organisational sweep. Forty departments, every essential function, every dependency, elicited in parallel. It sounds like the responsible approach and it is how these projects die, because each department is a discovery conversation with people who have day jobs, and the elicitation runs at the speed of the slowest calendar in the building.

Six months in, half the departments are documented, the first half is already out of date, and the sponsor is asking what was delivered. Nothing was, because a partially populated dependency model answers no question. The programme then gets a reputation for consuming time and producing nothing, which is much harder to recover from than a delayed release.

The alternative that works is narrow and provable. Take your three most critical essential functions and trace every dependency to a live system of record: the positions that perform them, the applications those positions use, the infrastructure and vendors underneath, the facility, the vital records. If any link in those three chains cannot be verified today, that is the project, and it is visible to a sponsor in weeks rather than quarters. A first release covering the function and dependency model, succession and delegation, vital records and drift detection runs $55,000 to $120,000 over 10 to 14 weeks in our delivery experience. Departments get added after the model has survived contact with three real functions.

What goes wrong when you migrate the existing plan into the system?

Every organisation wants to import the 200 page plan it already has, and the import is where the uncomfortable discoveries happen. A document can hold contradictions indefinitely because the contradicting facts sit ninety pages apart. A model cannot.

The classic case appears in the first week of migration. An essential function with a four hour recovery time objective depends on an application whose own objective is three days. Nobody wrote that deliberately. The function's objective came from asking a department head how quickly they needed to be back, and everyone answered immediately, so the plan carries forty first priorities with no arbitration between them. The application's objective came from the technology team, who were being realistic. Migration surfaces dozens of these at once, and if the project has not planned for the arbitration work, the team either stalls or, worse, quietly loads both numbers and the model inherits the contradiction it was built to expose.

The second migration trap is names. Plans are full of position titles that no longer exist, department names from a previous reorganisation, and people identified by first name and role. Matching those to the personnel system is manual, it is the highest value work in the whole migration, and it is routinely left to the end. Do it first. A position in the plan with no match in the human resources (HR) system is the single most important record in the build, because it is either a role that was abolished or a person who left, and both are live gaps.

Plan for arbitration sessions in the schedule, with a named executive who can rule on competing recovery objectives. Without that authority in the room, the model records the argument rather than resolving it.

Why do the personnel and asset inventory integrations break after launch?

The whole value of a continuity build is that the plan decays visibly rather than silently, and that depends on bindings to systems you already run. Those bindings are also where these projects break after go live.

The failure is rarely the interface. It is that the source system is not as authoritative as everyone assumed. The human resources system holds employment records but not the acting arrangements that matter during an event, so a plan bound to it shows a vacant position when in practice a deputy has been covering for eight months. The configuration management database is genuinely maintained for servers and genuinely fictional for business applications, so application dependency drift generates alerts that are all noise. The facilities system records space by building and room without any concept of a function being performed there.

What holds together is scoping the binding to the fields each system actually governs, and being explicit about the rest. Bind position holders to the human resources system. Bind acting and delegation arrangements to the continuity system itself, with an expiry, because no other system owns them. Bind infrastructure to configuration management and treat the business application inventory as continuity owned data until the technology team is ready to own it properly. Then send the continuity manager a weekly digest of ten specific drifts rather than an annual review cycle, because ten specific items get fixed and forty emails get eleven replies.

What happens when statutory succession, delegation and vital records are not covered?

Public sector, utility and health system continuity carries constructs that corporate business continuity models treat as optional. Orders of succession set by ordinance. Delegations of authority with specific triggers and limits. Devolution to a geographically separate site. Vital records defined by a records retention schedule. Configured in as custom fields, they become documentation. Modelled properly, they become operational.

Delegation is the one that hurts during a real activation. Most plans describe it in a paragraph. The live question is sharp: who can authorise emergency procurement above the normal threshold, who can direct staff to relocate, who can declare the event, and what happens when that person is unreachable. Model it as a rule with a trigger, a scope, a limit and an expiry, then record who actually exercised what and when. That record answers the auditor and the elected official asking who approved a particular expenditure at 4am, and during the event it prevents the paralysis of nobody being sure they are allowed to act.

Vital records are the half nobody funds. Essential functions get attention because they are visible. The deeds, case files, licences, personnel records and utility as built drawings get a table, and the function cannot be performed without them. Each needs a format, a storage location, a copy that is not in the same building or the same cloud tenant, a restoration procedure someone has actually run, and an owner who is a person rather than a department name. Tie them to the retention schedule you already maintain rather than building a second list, because a second list diverges within a year. Then sample test restorations quarterly and record the result, since an untested backup is a belief rather than a control.

Should you build custom or configure what you already own?

Fusion Risk Management and Castellan are capable business continuity platforms with genuine dependency modelling, and for a mid sized private organisation they are the right purchase. Riskonnect approaches continuity as one module within governance and risk, which suits an organisation buying the whole suite. Veoci is flexible and many emergency managers already run other functions on it, so continuity becomes configuration inside an environment their team knows.

Configure rather than build if you already own one of these and your continuity requirement is corporate in shape. Configure rather than build if you are small enough that one person genuinely holds the picture, if your plan is under fifty pages, or if your regulatory driver is a checkbox rather than a real audit. Software will not manufacture discipline you do not currently have, and a maintained document plus an honest annual tabletop is proportionate for a single agency with fifteen staff and one alternate site.

The reasons buyers move away from configuration are two, and both are structural. Continuity touches every department, so per user pricing across a forty department county or a multi campus health system becomes a large recurring line for software most of those users open twice a year. And the statutory constructs above are native to your obligations and configured into theirs. Build when the plan spans dozens of departments, when those constructs must be modelled rather than described, when the plan needs to reflect systems that change weekly, when you have failed an audit on currency, or when a real activation has already shown you the document was unusable.

How do hidden costs get into the quote?

Continuity quotes are unusually prone to underestimation because most of the work is not software.

• Department elicitation counted as one line. Each department is a discovery conversation, a set of essential functions and an argument about recovery objectives. Department count is the primary cost variable, not feature count.
• Inventory quality assumed. An organisation with a maintained configuration management database has an integration. An organisation whose application inventory is a spreadsheet last touched under a previous administration has an inventory project inside the continuity project, and it is better to admit that in week one than discover it in week six.
• The offline export treated as a report. An automatically generated, current, offline usable version of every plan is a core requirement, and it has to be tested the way a backup restoration is tested.
• Exercise management deferred. Exercises produce the only real data the programme has, and bolting the module on later means the first year of exercises is not captured.
• Recovery objective arbitration. Somebody senior has to rule between competing priorities, and that time belongs in the plan.

The full platform adding exercise management with corrective action tracking, activation mode with role based task assignment, devolution and alternate facility planning, departmental self service and audit reporting runs $140,000 to $320,000 across 6 to 11 months.

What separates a build that works from one that fails here?

Three things, and none of them is a feature list.

The first is that the system detects contradictions rather than storing them. Ask a prospective developer to model, on a whiteboard, an essential function whose recovery objective is shorter than one of its dependencies. If they show you how the system raises and surfaces that conflict the moment it is created, along with positions that have no named successor, applications with no owner and vital records with no verified separate copy, they understand the assignment. If they show you a form for entering functions, you are commissioning a document with a database behind it.

The second is that the system works when it is not available. A continuity platform that depends on the infrastructure it is meant to help recover has failed at its only job. There must be an exportable, current, offline usable version of every plan, generated automatically and held somewhere independent, and it should be verified on a schedule.

The third is that exercises feed the objectives. Capture what was tested, who took part, what actually failed, the recovery times observed rather than planned, and corrective actions with owners and due dates. Then push observed times back into the model, because a function that has never recovered faster than eleven hours across three exercises does not have a four hour objective, it has an aspiration and a documented history of missing it. Auditors want evidence of exercise and closure, not a well written plan.

Settle ownership before kickoff, including exported plans and exercise history. At Digital Heroes the organisation owns the code and the data from the first commit.