Categories: Issues, Problems and Projects
The table below provides general guidance on whether a work item should be categorized as an Issue, Problem or Project. Each work item should be considered in relation to the relevant dimensions and the highest category applicable chosen. If you are unsure which JIRA to add the work item to, please contact @Cathy Richardson for guidance.
Dimensions | Issue | Problem | Project | Explanatory Comments: |
|---|---|---|---|---|
Editorial guidance | Editorial guidance already exists. | A change to Editorial guidance may be or is required as part of the work being done.
| A change to Editorial guidance is required as part of the work being done.
| |
Concept model | No changes to the concept model are required. | A review of or change to the current concept model is required with the scope of work limited to a single attribute or range. For example:
| A review or change to the concept model is required with the scope of work impacting more than one attribute or range. For example:
| |
The type of issue/problem/project that needs to be worked on: |
| In addition to the above some other examples would be:
| In addition to the above some other examples would be:
| |
Analysis | Nil or a piece of work where a decision:
would enable the solution to be determined and the work progressed. Note: this would be a decision that could be reached in a meeting, not one where analysis and extensive discussion would be required. | Analysis required. | Analysis required. | |
Solution testing before development | Not required | Required but can be done using current authoring tooling functionality in either the UAT or production environments. | Required | |
Impact of change:
| Terminology: Low or consequences of change can be determined and are positive. E.g. changing the modelling of a high level concept. Clinical: To be determined | Terminology: Low - high. If medium to high: consequences of change can be determined (may be through solution testing) and are positive. Clinical: To be determined. | Terminology: Medium to high. | |
Documentation: Please note content tracker documentation is under review and refinement. |
| Content Tracker documentation required. This may be:
An update to Editorial Guidance may be part of the documentation required. | Project level documentation required. This may include Content Tracker documentation. An update to Editorial Guidance may be part of the documentation required. | |
Role/skills: This is not who must do work rather just an idea of the level of skills required given the potential complexity. |
|
|
| |
Resource implications: Resources may be required given the complexity of the issue and/or tooling support not just because of the number of concepts. Focus here has been effort over complexity and tooling support. |
| A work item that may only require a few days work through to planned resources but can be managed within a release. | Requires planned resources over more than one or more releases with efforts by more than one staff member. | |
Stakeholder involvement required
| While the CMAG or MF may be advised, input is not required. | May require SME, advisory group or requester input. | Consultation required. | |
Tooling | Current tooling functionality supports progression of the work item. | Current tooling functionality supports progression of the work item. Simple changes e.g. a MRCM rule change would be acceptable for Problems. | Tooling change required. | |
Examples of potential trackers that may fit that category |
|
|
|
Copyright © 2025, SNOMED International