Show Menu
Cheatography

Project change control and management Cheat Sheet by

Create a Master Schedule

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 collea­gues, 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:
Descri­ption, reasons, benefits and supporting docs
Review and log change requests
CM reviews RFC and decides nature and scope of feasib­ility / impact analysis
Log request
Determine feasib­ility of change
Assess change feasib­ility 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
Invest­igate different options and report on: change request, options, costs and benefits, risks and issues, impact, recomm­end­ations and plan
A quality review is then done on feasib­ility 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 condit­ions, 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-es­sential 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 interd­epe­ndent)
-
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 requir­ements or by cost or time constr­aints changing
-
Develo­pment 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

Config­uration 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 compon­ents, Operat­ional and support doc, Key planning docs (budgets, schedu­les), 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 accord­ingly 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 = Config­uration item ID
 

Change management roles and respon­sib­ilities

Project manager
Oversees process
Limited respon­sib­ility
Ensures Requests For Change (RFC) are handled approp­riately
Usually also the change manager
Have user reps agree to changes to requir­ements
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 feasib­ility study required for change
Appoints feasib­ility group
Change feasib­ility group
If you use project team members here you may further delay the project
Invest­igates feasib­ility of req change
Research how to implement
Research costs, benefits and impact of options
Document findings in a feasib­ility 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 implem­ent­ation timetable
Change implem­ent­ation group
Carries out the change
Usually the project team

Change mgmt: major concern

Impacts on staff levels, skill retention, and respon­sib­ilities
Procedures for managing change should be establ­ished at the beginning of project
Need to keep track of changes to systems
Change control system needs to be devised and implem­ented, especially if outside contra­ctors are doing the work
Allowances need to be made in project for any additional work needed due to changes
                                               
 

Comments

No comments yet. Add yours below!

Add a Comment

Your Comment

Please enter your name.

    Please enter your email address

      Please enter your Comment.

          Related Cheat Sheets

          Innovative strategies for change Cheat Sheet
          Project Management Cheat Sheet

          More Cheat Sheets by NatalieMoore