In this guide 6 sections
A software project risk register is a shared sheet with a line per risk, giving its trigger, one owner, the planned action and a review date. Five families cover most small projects. Migration gaps, adoption, fixed dates, vendor dependency, single points of failure.
What a risk register is for
It is a sheet, not a report. It sits where the whole project group can open it, and it settles what you will do about a problem before the problem arrives and tempers fray.
Most projects fail in familiar ways. Old customer records refuse to load, staff go on using the spreadsheet, or go-live lands in the busiest fortnight of the year. Writing these down early costs an hour. Skipping it costs weeks.
Keep the list short enough to read aloud. Twelve rows that people actually open will protect the project better than sixty rows that sit unread in a shared folder.
The columns that make it usable
Every row needs the same eight fields. The owner field matters most, since a risk with no name beside it belongs to nobody, so choose a person rather than a department or a vendor.
The trigger is the first sign. For a migration gap it might be a test import that shows four hundred fewer customers than the old system holds, which anyone can check in minutes.
Triggers turn worry into a check. Add a review date to every row, meet on those dates, and leave closed risks in the sheet, greyed out, as a record of what you handled.
- Risk, written as a sentence about what could happen
- Trigger, the first visible sign
- Impact, in days lost or work stopped
- Owner, one named person
- Planned action and fallback
- Review date and current status
Data migration and staff adoption
Migration risks live in the data. Think of duplicate customer records, item codes whose spelling changed, opening balances that miss the ledger, and attachments stored on one clerk’s desktop. Give each to whoever knows the old system best, and hand them a test import to inspect line by line before anyone approves go-live.
Adoption risks live in habits. Staff keep a parallel Excel file. They type a dot into mandatory fields. The owner is usually a team lead, and the action is a short training session plus a date when the old sheet is switched off.
Check both with a sample. Ask three users to finish a real task end to end, then note every spot where they hesitate, reread a label or ask a colleague.
Deadlines, vendors and single points of failure
Some dates cannot move. Think of a financial year end, a filing window, a festival rush or a regulator’s cut-off, then list the last safe go-live day before each and work backwards.
Vendor dependency is next. Who holds the source code, the domain, the cloud account and the licence keys, and can they be reached on a Sunday? Only the vendor? That is a row. Its owner asks for admin access this month.
Key-person risk comes last. One developer who understands the payment integration, or one clerk who knows the discount rules nobody wrote down, is a single point of failure. Fix it with a handover note.
- Last safe go-live date before each fixed deadline
- Who holds the source code, domain and cloud account
- Who can restore from backup if the main person is away
- Contract exit terms and data export format
Running the register week to week
Put a fifteen-minute review on the calendar every fortnight and walk through every row whose review date has passed, noting what changed since the last meeting. Ask three questions only. Has the trigger fired? Is the action done? Does the owner need help?
New risks will appear as work goes on, such as a vendor staff change, a late data export or a new regulation. Add them the day you hear. Close any row the moment its action is complete.
Start today. Copy the eight columns into a shared sheet, write five rows with one from each family, and send the sheet to the owners before the week ends.
Software project risk register
One sheet, five example rows. The eight columns are risk, trigger, impact, owner, planned action, fallback, review date and status; the examples cover migration gaps, adoption, fixed deadlines, vendor dependency and key people. A second tab holds the review log.
Open a blank worksheet to printQuestions owners ask
How many risks should a small software project list?
Ten to fifteen is plenty. List only real threats to the go-live date or daily work, and close rows once their action is done so the sheet stays short enough to read.
Who should own a risk?
The person best placed to act on it. A data risk goes to whoever knows the old records, and a vendor risk goes to whoever signs the contract and holds the account logins.
How often should we review the register?
Every two weeks during the build, then weekly in the final month before go-live, since each row also carries its own review date and high-risk rows come up sooner.
Is a risk register different from an issue log?
Yes. A risk has not happened and has a trigger and a plan, while an issue has already happened and needs a fix. Triggered rows move to the issue log.