Change management processSubmit 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 changeBefore 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 managementLots 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 responsibilitiesProject 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 concernImpacts 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