When working through potential change – new workflows, integrations, systems, etc – it is often the case that risks and opportunities come to mind. Sometimes these are resolved or become better expressed or remain as more thinking and discussion takes place.
As our exploration and understanding of a problem or solution space develops, it seems prudent to have a simple checklist to record these things as they occur, to elaborate them as they develop and eventually to strike them off or to carry them forward in various ways; for example
- As formal risks for the ‘real’ risk register
- As issues to be resolved in systems design, development or implementation
- As opportunities to be exploited in the proposed undertaking
- As possibilities parked for the future
The important thing is to capture them as they occur, to record them in a rolling list that is not so formal as to make recording difficult or threatening.
You might want to differentiate several lists (Risks, Opportunities, Questions, Tender requirements, etc), but experience suggests that you should save that categorization for a later stage and start with a simple ‘catch all’ list, which can be maintained in a shared document. A spreadsheet may be best so the entries can be categorized and filtered at a later stage.
- Step 1a – Set up a document or spreadsheet in the simplest format you can imagine; for example, just two columns – Name (Originator) and Description
- Step 1b – In a face-to-face setting this might take the form of a special flip chart page that becomes a document at the end of the session
- Step 2 – Enter stuff as it occurs, trying to stick to the broad scope of ‘unresolved things’, such as risks, issues, opportunities and future possibilities
- Step 3 – Share the list with permission to add and amend as appropriate
- Step 4 – Review the list whenever you review the overall task; for example, when progressing a Requirements Catalogue for procurement
- Step 5 – At the end of the task, you are likely to be left with items on this list which must therefore find a place in the ongoing documentation (for example, as formal risks or as requirements for future phases)
The objective of the method is therefore to capture issues and ideas as they occur, without the inhibitions associated with a formal risk register or requirements catalogue. This appears very simplistic but can be very effective.
Here is the list that the University of Stirling team drew up during an exploratory discussion of reading list workflows:
Examples of Use
This method is used or referenced in the following LMS Change Case Studies
This method is related to a number of more formal mechanisms used to make specific lists – Risk Register, Requirements Catalogue. It is perhaps closest in spirit to what SSDAM Structured systems analysis and design method) calls a Problems & Requirements List (PRL) – for example see “An introduction to Requirements Engineering” by Ian Bray (2002).