Review: Halden Software Governance Council draft charter
I checked Halden Software Governance Council — draft charter against the 10 setup steps, Checklist and Template. The draft handles the running of the council well: intake, meetings, escalation and measures are mostly sound. What it lacks is the part that gives the council power. It has no sponsor, no written decision rights or thresholds, and 14 voting members. As written, it could hold meetings but not enforce anything.
Gap table
| Step | What's missing | Why it matters | Fix |
|---|---|---|---|
| 1. Purpose | The purpose says what the council oversees ("software and applications"), not what goes wrong today. | Without a problem statement, nobody can tell later whether the council worked, and scope tends to grow. Checklist item 1 asks for a one-sentence problem statement (XW-003: ISO 19770-1 4.3, 5.2; COBIT APO01). | Rewrite it as one sentence about the current problem, for example that Halden buys and renews software with no single review, which leads to duplicate tools, unmanaged risk and missed savings. Decision needed: the sponsor and members agree the actual problem statement. |
| 2. Sponsor | No sponsor is named anywhere. The COO appears only as the escalation point. | The skill treats this as critical: with no executive who controls the software budget, nothing makes procurement or business units follow the council. It also leaves no one to approve the charter (checklist item 10; XW-027: ISO 19770-1 5.1, 5.3; COBIT EDM01, APO01; ISO 27001 5.1). | Add a Sponsor section giving the name, title and the budget this person controls. The COO is the obvious candidate because they already break ties and sit outside the council, but the draft doesn't say they control the software budget. Decision needed: who the sponsor is. |
| 3. Decision rights | There is no decides / advises / delegated split. The "cost or risk threshold" is mentioned but never set. There's no threshold for AI use, even though AI tools are in scope. No named role decides items below the threshold. | Without written thresholds, the governance analyst has nothing to triage against. Items below the threshold have no owner, so either everything goes to the council (bottleneck) or nothing is formally decided. Scope covers requests, renewals, retirements and AI tools, but the draft never says what the council does with each one (XW-027). | Add the template's decision-rights table: one row each for new requests, renewals, retirements, exceptions and AI tools, with one accountable party, a delegated role and a threshold per row. Decision needed: the cost figure, the risk tiers and the AI-use trigger. Unverified: the draft gives no figures, so I haven't suggested any. |
| 4. Membership | There are 14 voting members: CIO, CISO, and the heads of procurement, finance, legal, architecture, HR, operations, warehousing, transport, customer service, sales and marketing, plus the service desk lead. There's no chair and no non-voting tier. | The limit is 9. Above that, quorum gets hard and decisions slow down. Five business-unit heads outweigh the control functions. The SOP says the chair runs meetings and settles ties below the sponsor, but the draft names no chair (XW-004: ISO 19770-1 5.3; COBIT APO01; ISO 27001 A.5.2; ISO 42001 5.3). | Cut voting members to 7–9: CIO (chair?), CISO, procurement, finance, legal, architecture, plus one or two business leads. Make the other business heads, HR and the service desk lead non-voting or consulted. Decision needed: who keeps a vote and who chairs. |
| 5. Intake | No gap. There's one form, a named triage owner (the governance analyst) who triages weekly, and only above-threshold items reach the council. | The design is right. It just can't work until the step 3 thresholds exist, and that gap is already recorded under decision rights. | Once thresholds are set, also send exceptions and high-risk items to the meeting explicitly, as the template does. |
| 6. Enforcement | Procurement isn't committed to refusing purchases the council hasn't approved. Overlaps with architecture review, change advisory or security/risk boards aren't settled. | Without procurement enforcement, the "share bought through intake" measure can't improve. An unresolved overlap with architecture review, whose head is a voting member, invites items being decided twice or not at all (XW-027). | Add an Enforcement section: procurement will not issue POs above the threshold without a council decision, plus a table of adjacent bodies showing who owns what. Decision needed: the sponsor and the head of procurement agree the purchasing rule. (No matching findings slug, so this is in the table only.) |
| 7. Cadence | No gap. Meetings are monthly for 90 minutes, there's a standing agenda, the analyst keeps a register, and urgent items go to an email vote within 5 working days. | This matches the SOP's monthly cadence and the step 7 requirements (XW-025). | Optional: require the first meeting to open with a real live item, as the template does. |
| 8. Escalation | No gap. Disputes go to the COO, who is outside the council and breaks ties. | There's a clear path with an independent tie-breaker (XW-027). | If the COO also becomes sponsor, say so in the charter so the two roles line up. |
| 9. Measures | No gap against step 9. All four required measures are listed, reviewed quarterly, from a baseline set in the first quarter. | This meets checklist item 9 (XW-025: ISO 19770-1 9.1, 9.3). | Minor: the template also asks for a target per measure. Add targets once the Q1 baseline exists. Decision needed: the target values. |
| 10. Launch / approval | There's no sponsor sign-off line, no charter review date and no 90-day plan. | An unsigned charter has no authority. Checklist item 10 needs sponsor approval and publication, and approval records are audit evidence (XW-020: ISO 19770-1 7.6.3; COBIT MEA02). | Add an "approved by (sponsor)" line, a review date no more than 12 months after approval, and a 90-day plan ending with the first metrics review. Decision needed: sponsor sign-off. (No matching slug, so this is in the table only.) |
Why some things aren't in the findings block
- Purpose, enforcement and approval are real gaps, but none of them fits the seven allowed slugs. They appear only in the table.
- Intake, cadence, escalation and metrics meet their steps as drafted. The missing thresholds hold up intake, but that problem is counted once, under decision rights. The missing targets are a template detail; step 9 doesn't require them.
``findings [ {"type": "charter_gap", "id": "sponsor"}, {"type": "charter_gap", "id": "decision-rights"}, {"type": "charter_gap", "id": "membership-size"} ] ``