Controlling risks, issues, changes and quality
Once you have created your project plan and your monitoring, review and reporting mechanisms the last major area you need to consider is the control mechanisms you need to keep the project on track and allow you to deal with all the issues that occur during a long and complex project.
Risk management
All projects have an element of risk. Risk management is a mechanism to help you predict and mitigate those risks which might otherwise prevent the project meeting the objectives set for it.
You should set up a risk register for the project as a whole and in large projects such as an EDRM project it is valuable to set up a register for each stage in the project. The procedures defined in the infoKit are well suited to an EDRM project and no additional procedures are needed.
The risk owner is important. At various stages in an EDRM project the education organisation will be using the services of third parties - either consultants or an EDRM system/service provider. It is important to make it clear at each stage of the project when defining requirements for third party services/systems where the risk lies. If you appoint a consultant to conduct an audit then the roles and responsibilities of the consultant and the education organisation need to be defined and then the risk register for that stage will be able to clearly define who owns that risk – the consultancy or the education organisation. Similarly when you are signing a contract for a system and associated services it needs to be very clear what the roles and responsibilities are and hence who the owner of the risk is.
Issue management
In addition to risks, issues can and do arise and need to be managed. You should set up an issues log for the project as a whole and for each stage in the project. The procedures defined in the infoKit are well suited to an EDRM project and no additional procedures are needed.
Again the issue owner is important. At various stages in an EDRM project an issue can be assigned to the internal project team or to a supplier or third party consultant. If the owner cannot find a solution to an issue then an escalation procedure should be defined.
Change control
The third area to be controlled is change. In any project we have stated above that there will be changes to the original plan. Some of these are desirable and some are less desirable. They may result from detailed work done in a previous stage which then calls into question some of the assumptions or requirements made for the next stage.
Again the infoKit covers this area well. All proposed changes should be subject to an impact analysis to consider the impact in terms of time, cost and quality. Depending on the impact the change can either be approved by the project team or will need to be escalated up to the steering board.
The infoKit makes the point that change control is particularly important where a contractual relationship exists with a consultancy or with an EDRM system/service provider. JISC infoNet has a standard template for a change request form and education organisations should be sure before entering into a contract that the change control mechanism is defined and meets their requirements. Most change controls in a contractual relationship involve additional costs and hence it is vital that provision is made for the education organisation and the supplier to consider the request for change, consider the options and agree the preferred option and any costs associated with that option.
Quality control
The final vital control is on quality. The best way of controlling quality is through:
A formal project management framework
Adoption of recognised standards where they exist
Detailed specification of requirements
Detailed user acceptance procedures
Defined escalation procedures
We have covered the formal project management structure. Stage six reviews the key standards governing EDRM systems and provides advice on how best to specify your requirements. Stage six also covers user acceptance procedures. The Statement Of Requirements should always require that a user acceptance test be conducted for each major deliverable.
The escalation procedures should also be defined. If agreement cannot be reached on the results of a user acceptance test then the matter should be discussed by the steering board. If agreement cannot be reached then a third party source of impartial advice should be called. That source should be defined in the contract. Failing that then the matter should be resolved by an agreed arbiter as also defined in the contract.
