PRINCE2
In the PRINCE2 methodology this stage is represented by the following elements:
- Capturing Project Issues (CS3)
- Examining Project Issues (CS4)
- Escalating Project Issues (CS8)
- Authorising a Stage or Exception Plan (DP3)
- Giving Ad Hoc Direction (DP4)
- OGC PRINCE2 website
Managing Scope
In any project there are likely to be changes to the original plan during the course of the project. The changes may arise due to:
- The business case altering
- The need to find a way round a problem
- Identifying a better way to meet your objectives
- The scope of the project altering
- Somebody thinking the change is a good idea
A Change Control mechanism is necessary to ensure that such changes are handled in a managed and controlled way in order to keep the project on track. Without formal procedures in place the project runs the risk of 'Scope Creep'.
Scope creep is an ever present risk in most projects. It is a particular issue in software development projects where it is always tempting to add a few extra changes as benefits become clear during the progress of the project. It can often prove quite difficult to keep within scope given that additional suggestions can be closely linked to the original initiative. Changing the scope of the project frequently poses risks in terms of keeping to budget and deadlines but it is important to realise that scope change may also offer opportunities to derive previously unforeseen benefits. Conversely you may also need to 'de-scope' items from time to time in order to keep within project tolerance limits.
Any proposed change to the agreed deliverables of your project should be subject to an impact analysis. Key to any approach is to consider the impact in terms of:
- Time
- Cost
- Quality
By this stage in the project you already have an agreed plan and deliverables and an agreed budget. By considering the proposed change under the above headings you should be able to establish whether the change is within acceptable 'tolerance limits' or whether it has a significant impact on any of these areas.
Is It Worth Doing?
A university has chosen to purchase a course timetabling system but has excluded examination timetabling. Ideally the project would have consulted all relevant stakeholders before getting the project underway but in this scenario the Registrar suddenly thinks it would be a good idea to include exam timetabling. If they make this change it will set the deadlines back and result in additional cost. They must make a business case for why the change (in this case an improvement in quality) is worth doing.
If you are not using the concept of tolerances as previously described, then the definition of 'within tolerance limits' is usually that the change can be implemented:
- without affecting achievement of major milestones in the plan and
- within the overall existing budget
Generally a Project Manager may approve changes that are within tolerance but will refer to a higher authority such as a Project Board where the proposal amounts to a significant scope change. To help the Project Board make a decision the Project Manager may prioritise the issue using ratings such as:
- must do - the project cannot complete successfully without this change
- important - functionality would be impacted without the change, although it is not vital to the success of the project
- nice to have - an enhancement to agreed scope and quality
- cosmetic - no functional improvement
Change controls are particularly important where a contractual relationship exists. Where you are working with a third party supplier or consultants you need to be particularly careful about correctly defining your original scope and managing changes or you could suddenly find costs spiralling out of control.
Good project management is a careful balancing act and handling change is a key element of that act. It is not good management to 'freeze' a specification and plan on day one of the project and stick rigidly to it, nor is it good practice to change so often that the project never comes to an end. In the words of Turner (Turner, 1999), 'changing is something you must do sparingly and with great ceremony'.
Change control mechanisms usually involve some form of Change Request form that records:
- Details of the proposed change
- Analysis of the likely impact and
- Agreed actions
JISC infoNet's set of Project Management templates include a Change Request Form which can be used in conjunction with the Project Controls Database.
Resources
