Change management process
Submit and receive change requests |
Req for change can come from anyone, all are passed to the change requestor (CR) |
CR consults colleagues, and decides if change is desirable for user |
If there is a need a Request for Change is submitted to change manager (CM). RFC includes: |
Description, reasons, benefits and supporting docs |
Review and log change requests |
CM reviews RFC and decides nature and scope of feasibility / impact analysis |
Log request |
Determine feasibility of change |
Assess change feasibility and impact upon project in terms of time, cost and quality |
For small changes this may be informal |
Large could take a while and involve several people |
Investigate different options and report on: change request, options, costs and benefits, risks and issues, impact, recommendations and plan |
A quality review is then done on feasibility study |
Change doc collated by CM and submitted to CCB for final review |
Study carries a cost, cost is recorded in the change register by the PM. If its an external project the client will have to pay |
Approve or reject change requests |
Team leaders can approve if no extra costs. PM can approve small changes. CCB larger changes. Very large need an exception report and go to approval by steering committee / project board |
Change needs to be recorded and reported |
CCB may: |
Reject, req more info, approve, approve with conditions, put on hold |
CCB: |
Needs to consider overall profile. of possible changes. Lots of little changes can have a big effect. Prioritise changes so essential are done first. Delay non-essential until least amount of impact |
Approved change need revision to schedule and cost plan |
Implement and close change requests |
Implement change. Additional testing. Signed off in the change register. Invoices for additional work. Payments. |
CM = Change manager
CR = Change requestor
RFC = Request for change
|
|
Definition of change
Before you take a baseline the interface designs may change rapidly as designers test with users. No change management needed here |
Once decided that ready to start the design needs to be baselined |
After baseline rigorous change control required because of potential impact on subsequent phases |
Project baselines include (these tend to be interdependent) |
- |
Agreed scope and quality of work |
- |
Agreed schedule |
- |
Agreed cost |
Variations on the above include |
- |
Changes of scope. Originates outside project, usually the user changing requirements or by cost or time constraints changing |
- |
Development changes. Originates within the project and includes routine changes during developing and refining a product |
- |
Faults. Originates within, caused by team making an error |
Discretion can be exercised for accepting scope and dev changes, but error changes are obligatory |
Configuration management
Lots of docs in a project, so you need a central project library where project master copies are stored, with version numbers |
To do this you need a project config librarian |
Make sure all project products are controlled |
Config management elements |
Config item ID: Items subject to the config management system need to be identified |
Docs include: |
Baseline specs, Design docs, Software components, Operational and support doc, Key planning docs (budgets, schedules), Maybe also IT equipment |
All items defined as config items and details will be recorded in config management database. Details: |
CI ref #, Current status, Version #, Any larger configs for which it is a part, Components it has, Other products it is derived from, |
Config status accounting |
After a change to CI agreed, project librarian sets status of CI accordingly and Maintains continual record of statuses of items that make up the system |
Config control |
The librarian reviews to make sure no problems with statuses |
CI = Configuration item ID
|
|
Change management roles and responsibilities
Project manager |
Oversees process |
Limited responsibility |
Ensures Requests For Change (RFC) are handled appropriately |
Usually also the change manager |
Have user reps agree to changes to requirements |
Control scope. Aware additional features increase costs. Adjusts contract as required |
Change requestor |
Recognises need for change |
Formally requests change via RFC |
Change manager |
Often project manager |
Lodges RFC in the change register |
Decides whether feasibility study required for change |
Appoints feasibility group |
Change feasibility group |
If you use project team members here you may further delay the project |
Investigates feasibility of req change |
Research how to implement |
Research costs, benefits and impact of options |
Document findings in a feasibility study report |
Change control board |
Decides whether to accept or reject the RFC |
Resolves change conflict where changes overlap |
Resolves problems caused by change |
Approves change implementation timetable |
Change implementation group |
Carries out the change |
Usually the project team |
Change mgmt: major concern
Impacts on staff levels, skill retention, and responsibilities |
Procedures for managing change should be established at the beginning of project |
Need to keep track of changes to systems |
Change control system needs to be devised and implemented, especially if outside contractors are doing the work |
Allowances need to be made in project for any additional work needed due to changes |
|
Created By
https://www.speedwell.com.au
Metadata
Favourited By
Comments
No comments yet. Add yours below!
Add a Comment
Related Cheat Sheets
More Cheat Sheets by NatalieMoore