Risk List

Release Information

Project:	PIMS
Internal Release Number:	0.1
Related Documents:	Project plan Software development methodology
References:	Risk Management during Requirements by Tom DeMarco and Tim Lister Taxonomy-Based Risk Identification by Carr, Konda, Monarch, Ulrich, and Walker (SEI)

Process impact: This document records the major project risks, and plans to control them. For each risk the plan should include:

mitigation plan: Measures you will carry out now, to reduce the likelihood and/or impact of the risk. Alternatively, you can decide to accept the risk.
indicator: A sign you will monitor to determine if the risk is beginning to have an impact on the project.
contingency plan: What you will do if the risk does arise. For catastrophic risks, the only response is to cancel the project. Most risks consume development resources, so the contingency plan is to reduce project scope. Other plans are stated explicitly below.

TODO: You should update these lists regularly. They should be reviewed by customers and developers from time to time.

NB: There are many risks whose impact is to cost development time. Since the project is of fixed duration, this would mean some features cannot be implemented. The severity attached to these risks is low, because at present the project scope has not been determined. Once there is a complete list of requirements, the severity of these risks must be reconsidered.

Major risks

Name	Description	Likelihood	Impact	Plan	Status	Monitored by
Requirements	Requirements are only partly known at project start. Customers may not allocate sufficient resources to exploring requirements. Some important requirements may never be discovered; urgent requirements may be discovered too late; and requirements may not be discovered fast enough to keep the development team busy. These are particularly important since newly hired developers are unlikely to be familiar with protein science.	Medium	Critical to Catastrophic	Discover requirements like this. Customers to prioritise the scientific goals. Requirements will be detailed first for the top priority goals. Indicator: Track the rate at which requirements are discovered. Contingency: request more customer effort.	Green	Requirements Lead
Goals	Stakeholders goals may conflict. This may lead to opposing pressures on developers from their PI and from the project manager.	Medium	Critical	Keep an explicit list of stakeholders goals, signed by the PIs. The project manager will report progress to each declared goal, and match planned contributions to goal. Indicator: creep in requirements for current delivery.	Amber	Project Steering Board
Communication	Misunderstandings or disgreements among development team members about the product to be created. They are dispersed among several sites, and have not worked together before.	Medium	Critical	Use these tools to help communication. When consensus cannot be acheived, project manager to take decisions. The main indicator of misunderstandings or disagreements will be software defects detected by our QA activity.	Amber	QA lead
Acceptance	Customer may accept delivery of the system although it does not really meet their goals.	Medium	Critical	Customers are asked to declare acceptance criteria as each release is planned, and 2 years into the project to discuss acceptance criteria for the final system.	Green	Project Steering Board
Scope	The total features requested may be beyond what the development team can deliver in the time available.	High	Marginal	Assign levels of important to the use cases. Make the first review of project scope after 12 months.	Green	Project Manager
Robots	The interfaces for laboratory instruments are not yet known, and may be varied. This may mean a lot of work or some requirements not being met.	High	Marginal	Aim to convince manufacturers to follow a standard format. Also design a common format that can be transformed into a manufacturer-specific control file.	Green	Project Manager / Project Steering Board

Minor risks

Process impact: The severity of a risk is its likelihood multiplied by its impact. Risks are classified as minor if they have low likelihood, negligible impact, or medium likelihood and marginal impact.

TODO: Review this list regularly, to decide whether the likelihood or impact of a risk has increased to make it a "major" risk.

Name	Description	Likelihood	Impact	Mitigation Strategy	Status	Monitored by
Estimate	The development team might not be able to estimate the work time, preventing customers from deciding priorities effectively.	Medium	Marginal	The development team will gain experience in estimating the work, and deliver the first estimates after 12 months. We will compare estimated work to actual work.	Green	Project Manager
Retention	Some developers may leave the project before it is finished.	Medium	Marginal	Employing locations should provide support for continuing professional development. The project manager will discuss career goals with each developer, and try to assign tasks appropriately.	Green	Project Manager
Database	The amount of database activity required for one user request might make it hard to provide acceptable response times.	Medium	Marginal	The design goals for the data access layer include support for future denormalisation that is transparent to the applciation layers. The QA team will study the performance of the custom UI facilities.	Green	QA lead
Science	If there is are major technological developments in protein production the the development effort may not be able to keep up.	Low	Catastrophic	Indicator: compare cost of change to new development.	Green	Project Steering Board
Correctness	The system as delivered may have low take-up because of a lack of confidence in its correctness.	Low	Catastrophic	State of the art QA activity. Contingency: stop development of new facilities until the quality of the existing code is assured.	Green	QA Lead
Process	Some developers may not cooperate in common standards and processes.	Low	Critical	QA to check conformance, then discussions in development team meetings to change the standard or the actual practice as appropriate.	Amber	QA lead
Usability	The system as delivered may have low take-up because of poor usability.	Low	Critical	We will have a UI style guide. Most of the development of the front end will be in close contact with scientists. We will review usability later in the project.	Green	UI design lead
Desire	The stated requirements might not match the customers' desires and ambitions for PIMS.	Low	Critical	Incremental delivery of versions will provide experience of using PIMS, which will help the customers to identify the real requirements. Indicator: a developer saying "I think they mean ...", a customer saying "They know what I mean". Contingency: request customer review of requirements.	Green	Project Steering Board
Changes	After requirements have been documented and agreed, development activities begin to based on them, first design them implementation. If the features the users want change later then effort is wasted.	Low	Critical	A change control procedure is required, so changes are only made when the cost is worthwhile. Mitigation: invest less development effort on areas where the science is believed to be volatile. Indicator: compare cost of change to new development. Contingency: request customer review of requirements.	Green	Project Steering Board
Time to Market	The system may be delivered only after a rival project has delivered.	Low	Critical	This risk is accepted.	Green	Project Steering Board
Maintainability	The system as delivered might be hard to maintain or extend, resulting in a reduced lifetime for the product.	Low	Marginal	The design will be documented. The build procedure will check the code is documented to javadoc standards. CCP4 to decide acceptance criteria, and to review the code at 3 years into the project.	Green	CCP4
Scheduler	The requirement for a facility to efficiently schedule laboratory work requires a difficult algorithm: in fact an exact solution is NP-Complete. It may be difficult to find a satisfactory compromise.	Medium	Negligible	The project manager will review the CS literature for algorithms. The OPPF will clarify requirements. The selection process should check for relevant skills in the developer appointed.	Green	OPPF
Other Risk	TBD	Low/ Medium/ High	Negligible/ Marginal/ Critical/ Catastrophic	TBD	Red/ Amber/ Green	Project Manager

Risk status:

Red: Active & impacting project
Amber: Active but contained without impact to scope.
Green: not yet active

Risk Checklist

Do the plans provide an indicator to detect each of the risks becoming active, and for each indicator is someone assigned to monitor it?: Yes, if all activies are carried out as planned, we will know if any of the risks is becoming troublesome.
Does each risk have a mitigation strategy, or is the risk acceptable?: Yes, we have plans to control each risk.
Does each risk have a contingency plan?: Yes.
Has this Risk Control Plan been communicated to the development team and other stakeholders?: Yes, this document is being posted to the project website. It will also be discussed at an early team meeting, and at the first Project Steering Board meeting. Comments are welcome.
Is there a procedure in place for identifying new risks and reviewing the existing ones?: TBD
In the light of these risks, is the project worth carrying out?: Yes. It is an unusually risky project by commercial standards, but we believe we have adequate plans here, considering the value that the project could deliver.

Company Proprietary