Risk Register and Issue Log Template (IDK-04)

Template IDK-04, version 1.0. Phase: All phases.

How to use this template

Set it up during Initiate Project and keep it alive until the closure document is signed. A register that is only opened before a steering group meeting is a report, not a control.
The customer project manager owns it. The supplier project manager contributes risks from the delivery side. Every team member may raise an entry.
Section 4 is starter content: risks that recur in ERP implementations. Keep the ones that apply, rewrite them for your project, delete the rest. Do not present the starter list as your risk analysis.
A risk is something that may happen. An issue has happened. When a risk occurs, close it in the register and open it in the issue log with a reference.
It is done for the first gate when the scales are agreed, every open risk has one named owner and a response, and the escalation rule in section 6 is accepted by the steering group.

Template metadata
Field	Value
Template ID	IDK-04
Phase	All phases
Owner	Customer project manager (with supplier project manager support)
Approver	Steering group
Qualification gate	Project Initiated (register and process in place); reviewed at every later gate
Version	1.0

Document control

Version	Date	Author	Change	Approved by
0.1	[YYYY-MM-DD]	[name, role]	Process, scales and starter register
1.0	[YYYY-MM-DD]	[name, role]	Baseline for gate Project Initiated	[steering group chair]

1. Risk process

Step	What happens	Who	When
1. Identify	Risks are collected in workshops, in the weekly project team meeting and from each phase review. Each is written as cause, event, effect: "Because [cause], [event] may happen, leading to [effect]."	Anyone; logged by the PMs	Continuous
2. Assess	Probability and impact are rated with the scales in section 2. The rating comes from section 3.	PMs with the person who raised it	Within [agree in project] of logging
3. Plan response	One response type is chosen: avoid, reduce, transfer, accept. For reduce: concrete actions. For accept: a stated trigger and a fallback.	Risk owner	Before the next project team meeting
4. Assign and act	One named owner per risk. Actions enter the project plan with dates, like any other task. The owner reports progress; the PMs check that actions are actually performed.	Risk owner, PMs	Reviewed weekly; top risks at every steering group

Closing a risk requires a reason: occurred (moved to issue log), no longer possible, or reduced to a level the steering group accepts.

2. Scales

Ratings are described in words so that two people rate the same risk the same way.

2.1 Probability

Rating	Meaning
Low	Would surprise the team. No sign of the cause today.
Medium	Could reasonably happen. The cause is present but under some control.
High	Expected to happen unless something changes. Early signs are already visible.

2.2 Impact

Rating	Schedule	Cost	Solution quality and business operation
Low	Absorbed inside the phase; no milestone moves	Absorbed inside the workstream budget	Inconvenience; a workaround exists and users accept it
Medium	A milestone moves but the gate date holds	Needs contingency released by the sponsor	A process works with a manual step, or a benefit is delayed
High	A gate or the go-live date moves	Needs a budget decision by the steering group	A business-critical process cannot run, or data cannot be trusted

Project-specific definitions agreed for this project: [add or adjust].

3. Rating matrix

Probability \ Impact	Low	Medium	High
High	Moderate	Major	Critical
Medium	Minor	Moderate	Major
Low	Minor	Minor	Moderate

Rating	Handling
Critical	Reported to the steering group with a response plan. Owner at sponsor or steering group level.
Major	In the top-risk list of the status report. Owner at PM or process owner level.
Moderate	Managed by the PMs. Reviewed weekly.
Minor	Logged and reviewed at each phase end.

4. Risk register

Columns: P = probability, I = impact. Status: open, reducing, accepted, occurred, closed.

4.1 Project-specific risks

ID	Raised	Risk (cause, event, effect)	Area	P	I	Rating	Response type	Response actions	Owner	Next review	Status
Example: R-101	[YYYY-MM-DD]	Because supplier and part data sit in two legacy systems with different numbering, duplicate suppliers may be loaded, leading to split purchase history and wrong payment terms on purchase orders	Data, procurement	High	Medium	Major	Reduce	Procurement data steward merges duplicates in the source before load cycle [n]; match rule agreed; validation query run after every load in Data Migration Manager	Procurement data steward	[YYYY-MM-DD]	Reducing
Example: R-102	[YYYY-MM-DD]	Because warehouse roles are defined late, the acceptance test may be run with broad permission sets, leading to access problems discovered only at go-live	Security, inventory	Medium	High	Major	Reduce	Functional roles for warehouse drafted before the security-and-data test cycle; testers log in with end-user permission sets only	Technical analyst, security	[YYYY-MM-DD]	Open
[ID]	[YYYY-MM-DD]	[risk]	[area]	[P]	[I]	[rating]	[type]	[actions]	[name]	[YYYY-MM-DD]	[status]

4.2 Starter content: risks that recur in implementation projects

Listed roughly from most to least damaging. Rate each for your own project; the P and I columns are left empty on purpose.

ID	Risk	Typical early sign	Response that works	Suggested owner
S-01	Senior management is not visibly committed	Steering group members send deputies; decisions wait	Steering group members act as champions in their own areas; attendance and decisions are minuted	Executive sponsor
S-02	The wrong people are on the team, or the right people are not released	Workshops attended by whoever is free; core team answers operational calls during sessions	Key people with authority to decide; backfill agreed in writing (IDK-03 section 6); extra capacity planned for peaks	Executive sponsor
S-03	Project management is weak	Plan not updated; same issues reappear; meetings without actions	Realistic plans; plan, do, review cycle per team every week; short whole-team stand-up; risks and issues worked actively	Both PMs
S-04	Scope grows without decision	"Small" additions agreed in workshops; consultants building undocumented items	Scope baselined in the plan and scope statement and signed by the steering group; every change documented and communicated (IDK-07)	Both PMs
S-05	Pressure for modifications and for keeping legacy interfaces	Requests to make the new system look like the old one	From the first day, modifications and integrations need steering group authorisation; standard functionality is tried first	Steering group
S-06	Resistance to change	Rumours, low workshop engagement, requests driven by habit	Communication strategy and plan; messages about benefits for each group; the system is not modified to soothe users	Change lead
S-07	Other projects compete for the same people and attention	Core team pulled into other initiatives	Sponsor keeps this project among the top business priorities and resolves conflicts at steering group	Executive sponsor
S-08	The solution does not meet the need or the quality expected	Tests designed only by the project team; decisions not reviewed	Right team; test design involves the wider business; steering group reviews major decisions; unit tests, then end-to-end tests by the team, then by end users	Customer PM
S-09	Data migration fails or arrives late	Data sources unknown; cleansing not started; first load attempted late	Identify data and sources early; start cleansing early; documented strategy; trained technical team; several full load iterations	Customer data lead
S-10	End users are not trained or do not accept the solution	No training plan; trainers not named	Plan who is trained, in what, when and by whom; train the trainer; expert users teach their colleagues	Customer PM
S-11	Go-live fails	Cutover plan exists only in the supplier's head; no rehearsal	Documented and approved cutover plan; rehearsed more than once with full data volumes; rollback plan with a point of no return	Both PMs
S-12	Teething problems after go-live overwhelm the business	Help desk unprepared; no local presence	Training that shows each user what they personally gain; support present on site; expert users as first contact; help desk trained in basic administration	Customer PM
S-13	Benefits are not realised	Business case not looked at after approval	Time-bound benefits in the business case; sponsor accountable; reviewed at every steering group	Executive sponsor
S-14	Tailoring blocks future updates	CRIM log grows; no one asks how objects behave at the next release update	Update cadence discussed at project start; technical solution manager reviews each CRIM item for update impact	Technical solution manager

5. Issue log

An issue is a fact that needs action now. It has a priority, not a probability.

Priority	Meaning
High	Stops a workstream or threatens a milestone. Needs a resolution path within [agree in project].
Medium	Slows work; a workaround exists.
Low	Does not affect the plan. Fixed when convenient.

ID	Raised	Raised by	Issue description	Area	Priority	Impact if unresolved	Owner	Agreed action	Due	Status	Resolution and date	Linked risk or change request
Example: I-014	[YYYY-MM-DD]	Functional team lead, procurement	Approved authorisation rules for purchase requisitions differ between the two companies; the Book of Rules assumes one rule set	Procurement	High	Prototype scenario for requisition approval cannot be finalised	Head of procurement	Decide on one rule set or document both; decision paper to PMs	[YYYY-MM-DD]	Open		[CR reference if raised]
Example: I-015	[YYYY-MM-DD]	Technical analyst, integrations	Third-party transport system has no test instance available for integration testing	Integrations	Medium	Integration INT-03 tested late, risk to acceptance test entry	Customer IT lead	Request test instance from vendor; interim test with recorded messages	[YYYY-MM-DD]	In progress		R-[n]
[ID]	[YYYY-MM-DD]	[name]	[issue]	[area]	[priority]	[impact]	[name]	[action]	[YYYY-MM-DD]	[status]	[resolution]	[reference]

Defects found in testing are not logged here. They live in the test tracker with their own classification (cause, blocks deployment, contractual, owner, closure date). Only a defect that threatens a milestone is lifted into this log.

6. Escalation rule

Situation	Escalated to	By	How fast
Risk rated Critical, or any risk whose response needs budget, scope or date change	Steering group	Both PMs, through the sponsor	Next steering group; extraordinary meeting if the decision cannot wait
High-priority issue not resolved by its due date	Executive sponsor	Customer PM	[agree in project]
Issue where the two PMs disagree	Both sponsors	Either PM, after telling the other	[agree in project]
Issue blocked by a person or department outside the project	Executive sponsor	Customer PM	[agree in project]
Any issue whose resolution changes a baseline	Change control (IDK-07)	Issue owner	Before work continues

An escalation is written: the issue, the options considered, the recommendation, the decision needed and the date it is needed by. Putting it in writing often settles it before the meeting.

7. Review rhythm

Review	Participants	Scope
Weekly project team meeting	PMs, workstream leads	New entries, overdue actions, Major and Critical risks, High issues
Steering group	Steering group	Top risks and issues, escalations, trend since last meeting
Phase review	PMs, sponsors	Full register; lessons feeding the next phase

Approval

Name	Role	Date	Signature
[name]	Executive sponsor (customer)	[YYYY-MM-DD]	______________________
[name]	Customer project manager	[YYYY-MM-DD]	______________________
[name]	Supplier project manager	[YYYY-MM-DD]	______________________

Independent template aligned with the IFS implementation methodology. Not an official IFS document. IFS is a registered trademark of IFS AB.

Marketplace