Create a Master Schedule
|
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.
|
|
|
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
|
|
|
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
|
|
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
|
|
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
|
No comments yet.
Cheatography n. The art of mapping complex subjects into clear, instantly navigable reference guides.
