03.04 Projects and Programs

Why this matters

A working risk register has dozens to hundreds of risks at any given time, and the program is treating only some of them at any given moment. The treatment work needs to be organized (by team, by quarter, by funding source, by initiative) so leadership can answer "what are we doing about risk this quarter?" without reading every individual risk's mitigation plan. Projects in SimpleRisk are the container for that organization: a named bucket that holds related risks together for treatment-tracking and for program-level rollup reporting.

The other reason this matters: projects are the bridge between operational risk work and the governance forum. The forum wants to read about a small number of initiatives (the cloud migration, the SOC 2 prep, the GDPR enforcement update), not about every individual risk that rolls up under each. Project rollups produce that view automatically — the forum sees ten projects, each with its risk count and treatment status, instead of two hundred risks the forum can't read in the time available. Without project organization, the forum either gets the right level of detail by accident or gets the wrong level every time.

The third thing worth knowing, and this is the load-bearing fact for this article, is that SimpleRisk doesn't distinguish "projects" from "programs". There's a single project entity with four status values (Active, On Hold, Completed, Canceled), and that entity does the work of both. Organizations that use "project" and "program" with different formal meanings (a project is a one-time initiative; a program is a recurring set of related projects) need to encode that distinction themselves, typically by naming convention ("PROG-CloudMigration" vs "PROJ-CloudMigration-Phase1") or by setting one project as a parent that the others reference in their names. There's no programs table to populate.

Before you start

Have these in hand before you open the projects page:

One of three permissions, depending on what you need to do: Able to Add Projects gates the + Add project button, Able to Manage Projects gates editing, status changes, priority drag-reordering, and assigning risks, and Able to Delete Projects gates deletion. Without Able to Manage Projects the grid still shows every project, but the drag handle is inert and the edit and status actions don't appear. (See Permission Reference.)
A clear set of initiatives to track. "Project A" and "Project B" with no internal definition produces a project list nobody navigates. "Q3 Cloud Migration" and "SOC 2 Type 2 Prep" tells the reader what each project is and why it exists. Name projects for the initiatives the team actually talks about; the names are the navigation.
An understanding of what kind of grouping you want. Projects are groupings of risks. They're the right tool when "the risks affecting this initiative" is a meaningful question. They're the wrong tool when the grouping is of controls (use frameworks for that), of documents (use the document hierarchy), or of compliance work (use the compliance module's framework grouping). Don't fight the data model; reach for the right abstraction.
A read on whether your program treats "project" and "program" as different things. If yes, decide on the naming convention or hierarchy you'll use to express the distinction inside the single project entity. Document the convention so the second person to use the system follows the same pattern as the first.

Step-by-step

1. Open Plan Projects

Sidebar: Risk Management → Plan Projects opens /management/prioritize_planning.php. The page sits under Risk Management because projects are containers for risks, but conceptually they're a governance-layer abstraction — the page is dual-purpose and the sidebar entry reflects its risk-management origin.

The page opens on a single grid, not a set of separate views. A row of status chips across the top lists Active, On hold, Completed, Canceled, and ALL, each carrying a running count: click one to filter the grid to that status. There's no per-status page to navigate between; switching chips just changes what the same table shows.

Above the grid, the toolbar carries a search box ("Search projects"), a Filters button that opens quick filters for Consultant, Business Owner, Data Classification, and due status (On track, Due soon, Overdue, or No due date), and a Columns picker for choosing which fields the grid shows. The available columns are Due Date, Consultant, Business Owner, Data Classification, Risks, Highest risk, and Status, plus any project custom fields the Customization Extra has defined. Column visibility and order are remembered per user, so a consultant who hides Data Classification sees that choice again next login.

Each row is a project: a numbered Priority column carrying a drag handle, the project name, a due-date pill (colored for overdue, due soon, or on track), consultant, business owner, data classification, risk count, and the highest inherent risk among its assigned risks, shown in the configured risk-level color. A caret at the left of the row expands it into the risks assigned to that project — covered in step 3. The ⋯ menu at the right holds Edit, Change Status, and Delete. Nothing on this page triggers a full page reload; every action updates the grid in place.

The last chip in that row, Unassigned, carries the number of risks waiting for a project; select it and the same card shows that queue instead of the grid. That is where step 3 starts.

2. Create a new project

Click + Add project in the toolbar (visible with the Able to Add Projects permission). The New project dialog asks for:

New Project Name — required. Be specific: "Q3 Cloud Migration" beats "Project."
Due Date, Consultant, Business Owner, and Data Classification — all optional, plus any custom fields the Customization Extra has defined for projects.

Click Add to confirm. SimpleRisk creates the project as Active and places it at the bottom of that status's priority order. The other statuses get assigned later, through the status-change controls in step 5.

3. Assign risks to a project

A risk becomes eligible for planning the moment a management review's next step is set to "Consider for Project" — the review form itself offers an inline project field at that point, so a reviewer can assign it (or spin up a new project by name) without ever opening Plan Projects. Any such risk that isn't already in a project appears under the Unassigned chip, sorted by inherent risk An administrator can widen that net: the setting "Show all risks for planned projects instead of only those reviewed as 'Consider for Project'" makes every open, unassigned risk appear in the queue regardless of its review outcome. An empty queue reads "No risks waiting for a project."

From there, two paths assign a queued risk to a project:

Assign to project, one row or several. Hover a row and click its Assign to project action (the link icon at the right), or check several rows and use the Assign to project button in the bulk bar that appears above the queue. Checking the header box selects the rows on the current page; the bulk bar then offers Select all N to take every risk in the queue. Each risk's teams show as chips in the Team column, with a +N chip carrying the rest when there are more than three.
From inside an expanded project. Click the caret on a project's row to open its risk list — ID, Subject, Inherent Risk, Status, Mitigation (Not planned, Planned, or Mitigated), and Planned Mitigation Date (flagged Overdue once it has passed on a risk that is not yet mitigated), each with a View link and a Remove from project action. The list opens sorted by Inherent Risk, highest first; click any column heading to sort by it, and click again to reverse the order. Click + Add risks to this project to open a picker over the unassigned queue and add one or more risks at once. A project you've just marked Completed still lists the risks that completion closed, alongside any that were already there.

Removing a risk from a project (or unassigning it any other way) sends it back to the Unassigned Risks queue if it still qualifies.

4. Reorder priority within a status

The Priority column is a drag handle as well as a rank. Grab it and drop a project higher or lower in the list to change the order the team intends to work through them; SimpleRisk saves the new order as soon as you drop. Reordering is only available under specific conditions — SimpleRisk's own hint on a disabled handle puts it plainly: "Reorder is available when the list is sorted by priority within one status." In practice that means: pick a single status chip (not ALL), sort by the Priority column, and clear the search box and any quick filters first. Outside those conditions the handle turns pale and stops responding.

5. Move a project through its status lifecycle, or delete it

Open Change Status from a project's ⋯ menu, or select several rows and use the same action in the bulk bar. Checking the header box selects the projects on the current page; the bulk bar then offers Select all N to take every project matching the current chip, search and filters. The Change project status dialog offers all four statuses, and adds a note depending on the move:

Choosing Completed for a project with open risks warns that those risks will be closed with the reason "Fully mitigated."
Moving a project back out of Completed warns that the risks closed when it completed will reopen.
If your account can't close or reopen risks, the dialog says so and changes only the project's status, leaving the risks as they are.

Delete, from the same menu or the bulk bar, removes the project outright rather than just changing its status; the confirmation dialog states how many of its risks will return to the Unassigned Risks queue. Canceling a project is different from deleting it — a canceled project stays in the register, filterable under the Canceled chip and still holding its risk assignments, which is the right choice when you want a record that the work was tried and dropped. Reserve Delete for projects created in error.

6. Use projects for program-level rollup

For organizations running multiple related projects under a "program" umbrella, the convention is naming-based. A few patterns that work:

Prefix convention. Name programs with a PROG- prefix and projects with a PROJ- prefix; reports filter on the prefix to show one tier or the other.
Parent-named convention. Make a single "umbrella" project named for the program (e.g. "GDPR Compliance Program"), and name child projects to reference it (e.g. "GDPR-Data-Mapping," "GDPR-DSAR-Workflow," "GDPR-Vendor-Reviews"). The umbrella project holds risks that are program-level rather than project-specific.
External grouping. Track the program-to-project relationship in an external tool (a project-management system, a wiki page, a leadership tracker) and treat SimpleRisk's projects as the operational grouping only. This is the path most organizations end up on, because their program tracking exists for reasons SimpleRisk doesn't try to model.

Pick one and document it. Mixing conventions across the project list produces a tracker nobody can navigate.

7. Programmatic project management via the v2 API

The v2 API covers the whole Plan Projects workflow, not just creation:

GET /api/v2/management/projects — list projects, filterable by status.
GET /api/v2/management/project/detail — fetch one project's details.
POST /api/v2/management/project/add — create a new project.
POST /api/v2/management/project/edit — update a project's fields.
POST /api/v2/management/project/delete — delete a project.
POST /api/v2/management/project/update_status — change a project's status.
GET /api/v2/management/project/{id}/risks — list the risks assigned to a project.
GET /api/v2/management/projects/unassigned_risks — list risks waiting for a project.
POST /api/v2/management/projects/assign_risks — assign one or more risks to a project.
POST /api/v2/management/projects/reorder — set the priority order of projects within a status.
POST /api/v2/management/projects/display_settings — save a user's column visibility and order.

For automation, this is now a complete surface: scripted creation, status sweeps, and bulk risk assignment can all go through the API instead of the UI.

Common pitfalls

A handful of patterns recur when teams use the projects feature.

Creating a project for every risk. A "project" with one risk in it isn't a project; it's a label. Projects exist to group related risks; one-risk projects produce noise without producing rollup value. If a risk doesn't naturally belong with other risks in an initiative, leave it unassigned to any project.
Treating Canceled as Delete. Canceling a project keeps it in the register — filterable under the Canceled chip, queryable via the API, retained for audit-trail purposes. That's intentional; canceling preserves the record of "we tried this and decided not to continue" while removing the project from active circulation. Use Canceled when the work won't happen; reserve Delete for projects created in error, and remember Delete returns the project's risks to the Unassigned Risks queue rather than leaving them attached to a record that no longer exists.
Letting On hold become a graveyard. A project parked On hold for six months is functionally canceled, just less honestly. That status exists for genuinely-paused work expected to resume in a foreseeable timeframe. When that timeframe expires without the work resuming, move the project to Canceled (or back to Active if the resume actually happens). Letting On hold accumulate produces a chip full of items the program isn't actually deciding on.
Reordering as decision theater. A program that drags projects up and down within a status weekly without those reorderings affecting which project actually gets worked on next is reordering as performance, not as priority-setting. The Priority column is meant to drive the operational queue. If it doesn't, either start treating it as the queue, or leave the order alone and accept that the priority lives elsewhere.
Pretending "programs" exist when they don't. SimpleRisk's project entity is the same entity used for both projects and programs. A team that builds workflows assuming a separate programs table — bulk operations, custom reports, integrations — discovers the assumption is wrong only after the workflow is built. Confirm the data model; build for the entity that actually exists. The single project entity is what you have.
Forgetting what Completed does to open risks. Moving a project to Completed doesn't just relabel it — it closes every open risk still assigned to it, with the reason "Fully mitigated," and moving the project back out reopens them. A team that completes a project as a bookkeeping formality, without checking what's still open inside it, can close risks that weren't actually resolved. Read the dialog's warning before confirming; it tells you exactly how many risks are about to move.
Project name drift. A project named "Q3 Cloud Migration" stays named that way even when it's still running in Q1 of the following year. The name fossilized; the underlying initiative kept going. Rename projects when their scope or timeline changes; the name is the navigation, and stale names are bad signage.
No retrospective on completed projects. A project marked Completed and then ignored is missing the learning step. The risks that landed in the project, the treatment work that happened, the residual exposure that's left — all of it is data the program can use to calibrate future treatment estimates. Spend ten minutes on a brief retrospective when completing a project; the lessons compound.