1. Risk management plan:
Since all projects involve some degree of risk, a project risk management plan is necessary to define and document those procedures that will be used to manage risk throughout the life of the project. Risk can be understood as any factor that may potentially interfere with successful completion of the project. Therefore, it follows that by recognizing potential problems the project manager and core team members can avoid most, if not all, of these problems through proper actions.

2. Scope change control:
A scope change occurs when there is a significant modification to the project plan. Typically these changes impact the cost, schedule, or deliverables. Significant scope change and scope creep (numerous small changes) are a major cause of project failure. Allowing the project's scope to change mid-course usually means added costs, greater risks and longer duration. Many projects fail due to poor scope management. Very often it is a large number of small scope changes that do the damage, rather than the big, obvious ones. The successful Project Manager has learned that rigorous scope control is essential to deliver projects on time and on budget. By making a rigorous scope change control plan, the impact of the change of the scope on the project can be reduced to the minimum.

3. Communication plan:
Constant, effective communication among all project stakeholders ranks high among the factors leading to the success of a project. It is a key prerequisite of getting the right things done in the right way. As knowledge is power, sharing knowledge empowering every project stakeholder.

A project communication plan is the written strategy for getting the right information to the right project stakeholders at the right time. Each stakeholder has different requirements for information as they participate in the project in different ways. It is used to achieve the maximum knowledge sharing among project stakeholders. It identifies people with an interest in the project (stakeholders), communication needs, and methods of communication. Communication planning helps to ensure that everyone who needs to be informed about project activities and results gets the needed information.

4. Support systems and mechanisms:
A project is always faced with various constraints, such as time, cost , people skills and other hardware conditions.
An effective support system and mechanism can help reduce the impact of these constraints on the project to the minimum. It also can help reduce the impact various changes may impose on the project and thus ensure the project can be finished successfully.

5. Change management procedure
1). Request for Change:
The request may be initiated by the customer or by the project team. In either case, Part A of the Change Request (CR) Form is completed by a project member.

This project member is deemed to be the Originator of the CR and is responsible for ensuring adequate information is provided in the CR.

Where possible, the Originator provides a preferred solution, e.g. by marking up documentation.

The Originator submits the CR to the Change Administrator, who enters it into the Change Request Register with a status of "raised" and passes it to the Change Authority for authorization.

The Change Authority checks that the request is understandable and contains all relevant information for the request to be evaluated.

If authorization is given, the Change Authority passes the CR to the relevant team member for evaluation.

If authorization is refused, the Change Authority documents the reason, marks the CR as "refused" and passes the CR to the Change Administrator. The Change Administrator updates the Change status and returns it to the Originator. No further action is taken on this Change Request.

2). Evaluation

The team member assesses the changes to be made, the affected configuration items and the impact of the change. Using information stored in the configuration library, any affected variants are also identified. Additional Requests for Change may be raised and cross-referenced to. He/she completes Part C of the CR, detailing impact on timescales, costs, and any other areas.

The team member then returns the CR to the Change Authority, who determines any action to be taken, with, for example, groups external to the project.

If the CR is for an Enhancement Request, the Change Authority submits a quotation to the Customer Change Authority for evaluation and approval by the customer.

If the change is major, there may be time and cost associated with merely evaluating the change. In this case the CR will be completed showing the duration and cost of the evaluation only.

The CR is then passed to the Change Administrator who updates its status to "evaluated".

3). Agreement

The Change Authorities may accept or reject the proposed change.

If the change is rejected, the reasons for the rejection are recorded on the CR. Rejected CRs are returned to the Change Administrator, with a status of "rejected".

Prior to authorizing any changes, the Change Authority ensures that any necessary contractual amendments and/or costs to the customer have been approved by the Customer Change Authority. The Change Authority then completes Part D of the CR and returns the form to the Change Administrator with a status of "accepted".

In all cases, whether accepted or rejected, the Change Administrator updates the records and forwards a copy of the CR to the Originator.

If the CR was rejected, then no further action is taken.

4). Implementation

The Change Authority obtains resources and a change schedule.

The team member responsible then obtains a copy of the configuration item, as per the Configuration Management Procedure.

The change is performed, by the team member, with due attention to the Life Cycle Standard. The review and testing (if required) performed is recorded on the CR. Change History is recorded, as defined in the section below.

The team member obtains approval from the Change Authority that the change has been successfully completed and returns the updated CR to the Change Administrator with a status of "verified".

The team member deposits the updated (and/or new) configuration items (CIs) into the Configuration Library.

The Configuration Librarian records his/her receipt in Part E of the CR and updates its status to "deposited".

The Change Administrator updates the records and informs the Originator.

5). Release

The Change Administrator lists those CRs which are released. This information is passed to the Project Manager and the Support Manager.

All such CRs are then marked as "closed".

No further action is taken on these CRs.

6). Change Request Register

A Change Request Register is maintained by the Change Administrator, containing a copy of every submitted CR. (The Change Administrator may archive "dead" CRs as required to optimize storage requirements).

CRs are numbered consecutively from one. When a change request is added to the register, it is allocated the next available number by the Change Administrator. Whenever an CR is returned to the Change Administrator, the existing copy is discarded, and the latest copy inserted in the register.

CR numbers are not allocated by the customer. Where the customer wishes to maintain a separate register, the customer number may be recorded by the Change Administrator in addition to the project-allocated CR.

The status of CRs is maintained by the Change Authority in line with the paragraph below.

Reports on the status of CRs, reflecting longevity, status, category, etc., are produced by the Change Authority as required by the Project Manager.