Problems in CPMS

Something in CPMS doesn't work ...

If some part of CPMS isn't working properly that can be frustrating. In more extreme cases, a problem with CPMS could stop you doing your work. 

If you encounter a problem while using CPMS, send an email to the CRN Service Desk to log it with the IT help team.

Try to include as much information as you can when you report problems, including screenshots of the issue or any error messages, the account you are logged in with, the url of the page you are viewing and anything else that might help the team resolve the problem.

Current Known Problems

Every month, a group of RDN staff, each representing different services in CPMS, review all new problems that have been raised.  This group makes sure that the problem is well understood and then they prioritise the problem against the full list of known problems.  

Find out what problems have been identified and are still open

This group of staff also works with the development to fix the problems and test the fixes in CPMS before they are released.

New problem fixes are released at the end of each month.  For information on the latest releases, please check the Releases page.

Prioritising Problems

Problems must be prioritised so that the development team knows which one to work on next.  During the monthly review meeting, the RDN group discusses each of the problems and ranks them in an ordered list, which is then shared with the IT development team.

The criteria used for prioritising the problem tickets are below:

• P1 – Loss of critical application functionality relating to Vital Business Functions - the service is unavailable for users and clients, who are unable to perform their day to day business. Potential financial and reputational loss with no known workaround available. The issue is likely to be impacting multiple sites or more than 20 users. Those impacted are unable to perform their normal RDNCC work.

• P2 – Users are unable to use critical functionality in the system relating to the Vital Business Functions. This could result in potential reputational impact for RDNCC along with breach of SLA for higher priority incidents (P2/P3) and impact to associated reporting functions.  Any workaround still causes severe business impact. Likely to be 10-20 users  impacted across single or multiple locations, where they are restricted in their ability to perform their normal RDNCC work.

• P3 – Users are unable to use a piece of functionality which is deemed non-critical for the application but is still important to the running of the system. Potential workaround available which reduces the level of impact for users, and there is no direct impact to critical elements of the application. Reputational/financial impact is unlikely. Likely to be  5-10 users impacted at a single location with no widespread impact. If there is a workaround, it is likely to be causing business impact either through additional time to perform tasks or functionality not giving an equivalent result.

• P4 – Users are experiencing an issue with the system. However there is minimal impact to the performance of the system, there is no impact to critical elements of the system and a workaround is available which ensures impact on normal RDNCC work is low. No reputational or financial impact experienced. Likely to be around 5 users  impacted in an isolated scenario.

• P5 – A user is experiencing an issue with the system which is an isolated incident and is not being experienced by other users using the same application, there is no impact to the critical functionality of the system . Likely to have very localised  impact, and there are no concerns around reputational/financial impact.

Other criteria considered to decide priority include: does this affect external users?, how many people inside RDN are affected by this?, is there a workaround and how time-consuming is it?, is this preventing core business functions from occurring?