Chapter 16
Controlling Change and Versions
In This Chapter
Controlling change and stopping scope creep in its tracks
Getting to grips with the different types of project Issue
Dealing with Issues and changes
Tracking change with version control – configuration management
If someone wants a change to a building, a computer system, a business procedure – anything at all in fact – they nearly always start with ‘just’: ‘We just want one extra power socket by the door’; ‘We just need an extra report from the system’; ‘We just need . . .’.
One major project killer is scope creep – uncontrolled change where people add very small things to a project, one thing at a time, small item by small item: a 10-minute job here, a 20-minute job there, just a 5-minute job after that. And the project is a year long and costs £20 million, so surely you can accommodate a five-minute job? But the small changes build up, and of course you aren’t given any extra time, staff resources, or budget for them. Eventually, the cumulative effect is so great that it kills the project because the changes now represent substantial extra work.
In PRINCE2 scope creep can’t happen – well, almost. After you set up and agree the project, all changes come under change control. The response to the request may well be to say ‘yes’, but then the Project Board gives the time, budget, and staff hours to do the extra work. The project isn’t supposed to somehow absorb all this unplanned work with no impact.
What may seem a bit strange is that the handling of all project Issues comes under change control in PRINCE2. This is odd, because an Issue can be about anything at all; it doesn’t have to be a change. But either way, this is where Issues come in the method. This chapter covers controlling change, Issues and two special types of Issue, which are Requests for Change and Off-Specifications, usually referred to as RFCs and Off-Specs. The chapter also covers controlling versions of things or, to use the up-market name, configuration management.
Allowing Change, but Not Scope Creep
People often assume that change control is all about preventing change but that simply isn’t true in PRINCE2. If someone has a good idea that may help run the project faster, better and cheaper, you may well want to implement it. The emphasis is on controlling change and that includes accommodating and resourcing it.
Taking control
Scope creep or incremental change can be very damaging and is often high up on lists of causes of project failure. Many projects barely have time to achieve what they plan to do. Imagining that they can take on a whole heap of extra work and still stay within the original bounds of scope, quality, budget, and time is illogical and entirely unrealistic.
Avoiding a change freeze
Apart from killing the project, uncontrolled change or scope creep can have another really bad effect on the project – a change freeze. Scope creep happens until someone realises that the project is getting overwhelmed and is in danger of not delivering anything at all. So the Project Manager makes an announcement that after the end of this week the project won’t accept any more changes – none at all: there’s a change freeze. Oh, great. Up to now all sorts of minor and unnecessary changes were accepted without question, but after the end of this week all changes will be turned down, no matter how beneficial or how important.
Most projects happen in a dynamic business environment and unfortunately that environment doesn’t have the good manners to stay still while the project runs. If the project implements a change freeze, it inevitably gets more and more out of step with the business environment.
The answer is not scope creep and then a change freeze – the answer is change control. That means that you can accept a change even very late into the project if you can justify and resource it, but you turn down a change that you can’t justify, even in the early days of the project.
Defining a Project Issue
In the PRINCE2 method, change control covers all Issues in the project.
Categorising Issues
PRINCE2 has three sub-types of Issue, but you process them in exactly the same way in terms of recording them, tracking their progress, and noting how you resolve them.
General Issue or ‘Problem/concern’
The 2009 edition of the PRINCE2 manual has gone back to giving this first sub-type of Issue the name of ‘Problem/concern’. That name is a bit misleading because just about everyone thinks of ‘a concern’ as being something bad. If someone says something is a ‘cause for concern’ you aren’t expecting good news. But as the manual itself points out in the text, an Issue can be about anything at all and it doesn’t have to be bad stuff. Issues can also be good ideas or questions – anything at all, in fact.
Request for Change (RFC)
An RFC is a special type of Project Issue where someone wants a change to a product that has already been ‘baselined’.
An RFC can be submitted for a specialist product (something that a team built) or a management product (something like the Project Initiation Document that you use to help manage the project).
Off-Specification (Off-Spec)
You declare something Off-Specification if it fails to meet its quality criteria during testing and you can’t easily correct the problem. You can sometimes submit the Off-Spec even before the test, because the team can see that the product is never going to meet its quality criteria.
Normally, if something isn’t up to standard and it fails the test you just take it away and work on it until it does meet the standard and passes the test. But doing that may not always be so easy. Perhaps, for example, some components are now obsolete. Or maybe the correction would take so long that it would threaten the project as a whole.
An Off-Spec is usually for a product that’s below its quality criteria – it’s sub-standard. But occasionally an Off-Spec can be because a product exceeds its specification. That can also cause a problem.
Conceding a concession
When you find that a product is Off-Spec, you may be better off just accepting it as it is. Bearing in mind that Off-Specs usually relate to things that are below standard, this may sound a bit odd. But if the project can live with the item being below standard and time is short, accepting it (which PRINCE2 calls making a concession) may be better than losing the whole project because you can’t correct it in time.
The PRINCE2 manual says that only the Project Board can make a concession, and for the vast majority of projects that’s fine. However, in technically complex projects you may want to think about delegating decision making on concessions to the Team Manager or even team specialist level. In such projects the board are often only able to ask, ‘What does the Chief Engineer say?’, and rubber stamp that evaluation. The board members are often unable to validate the technical evaluation in either direction.
Handling an Issue
The flow of control for an Issue goes through five simple steps and the next sections in this chapter work through the sequence.
Step 1 – capturing the Issue
When the issue is received the Project Manager has a decision to make. Should this Issue be handled formally and tracked, or can it be handled informally? If the answer is that the Project Manager can handle it informally then she makes a note of it in the Daily Log. If the Issue needs formal handling, then she records the full detail on an Issue Report and then records the tracking information (who sent it in, current status and so on) in the Issue Register.
As with all of the PRINCE2 logs and registers, think of the Issue Register as a control document and then you can see how it’s used. The Issue Register provides an overview of all of the current Issues showing when each was received, what action is being taken on it and whether or not it’s been resolved. Well, actually a bit more than that as the panel shows. The Issue Report records the full detail of a single Issue.
Where you have project staff such as Team Managers who are very familiar with PRINCE2, you have the option of asking them to submit any Issues in Issue Report format, completing the sections that they can. Nothing is lost if the Project Manager decides to handle the Issue informally as much the same information is needed whether the matter is handled formally or informally.
The Issue Report then, covers the full information on a single Issue, including all the action taken on it. A summary of the control information is duplicated in the Issue Register, but slightly modified, as set down in the next panel.
As part of capturing the Issue the Project Manager allocates the severity and priority ratings. However, the appropriate rating may not be clear until after the next step of examining the Issue. In that case you can set a provisional rating and modify it when things are clearer. For example, a team member may have reported a severe problem, but after investigation it’s found that this young and inexperienced team member got a bit over-excited and, although there is indeed a problem, it’s been very much exaggerated.
Step 2 – examining the Issue
If the Issue is significant, other people as well as the Project Manager, may need to help analyse it. You may need to involve Team Managers, team specialists, and external supplier companies. The PRINCE2 manual also suggests that you involve Project Assurance to help assess matters like impact on the Business Case, but that may detract from their impartial position as the project audit function that’s independent of the Project Manager. How can assurance staff check whether an Issue was handled correctly if they themselves helped decide what to do?
Step 3 – proposing action
Deciding what to do about an Issue potentially involves three levels of decision-making authority: the Project Manager, a Change Authority and the Project Board. If something requires action that is beyond the Project Manager’s delegated authority, it needs to be ‘proposed’ to whoever is authorised to approve that action. You can find an explanation of the three levels of responsibility later in the chapter in the section ‘Understanding Authority Levels’.
Step 4 – deciding action
If the Issue is being handled informally, the Project Manager just notes her decided action in the Daily Log. If it’s being formally handled that detail goes in the Issue Register and on the relevant Issue Report. If the Issue has been escalated to a Change Authority or to the Project Board then the decision is taken at that level.
It’s tempting to just think of decisions as ‘yes’ or ‘no’ but you have some other possibilities, so do stay flexible. First, the board or Change Authority may hold off a decision because they want more information. In that case the Project Manager goes away and finds it and then brings the matter back a second time for a decision. The decision itself provides a range of possible outcomes. Taking a requested change as an example the response could be:
Yes, we’ll do it.
No, we won’t do it.
Perhaps we’ll do it later in the stage. If it’s early in the stage and the change isn’t high priority, the Project Manager can put the request on hold. If some change budget is left at the end of the stage, the change will be done then. If the budget is exhausted at the end of the stage then this particular change won’t be done. It would be bad management of a change budget to agree all sorts of trivial changes at the front end of a stage and then find that there’s no money or time for more significant changes later.
Perhaps we’ll do it in a later stage. Because of a fixed deadline, there may be no capacity to carry out this change in the current stage, but it’s a good idea and the work can be added to at a later stage in the project.
Perhaps, but not in this project. It may be that the proposed change is a great idea, but there just isn’t time or budget to carry it out in this project, which is up against a fixed deadline. It may then be recommended back to the organisation as a Follow-on Action. If organisational managers agree it’s a good idea, they can get the work done in another way; perhaps by including it in a future project.
Step 5 – implementing any work
If the decision is to go ahead, then the Project Manager puts the work in hand. That may involve some re-planning. When the work is complete, the Issue is closed down in the Issue Register, on any Issue Report or in the Daily Log.
Going into exception deliberately
An exception occurs when something goes significantly off plan. If you have to run the stage differently from this point because of a problem, you can’t go on using the existing Stage Plan because that won’t reflect how you will intend to complete the stage. So you draw up an Exception Plan that replaces the rest of the current Stage Plan. You can find more about this in Chapter 17.
You can use exactly the same mechanism to resource a significant change. For example, if a team member comes up with a great idea that may save a huge amount of money, but requires additional work to implement, then the board may agree it in principle and ask for an Exception Plan. The Project Manager produces a new plan showing all the work to accommodate the change and presents this to the Project Board for approval.
Understanding Authority Levels
Deciding how to handle Issues, including change requests, is a matter for the Project Board as ‘the boss’. Board members must decide how much authority they’re willing to delegate to the Project Manager and at what point they require the Project Manager to come back to them for a decision. One obvious threshold is budget. They may be happy for the Project Manager to authorise something costing £1 but not so happy at the idea of the Project Manager quietly committing the project to an extra £5 million.
But authorising changes isn’t just about money. Even though the Project Manager has a change budget, she may not be able to make decisions that affect the operation of the whole organisation, for example, no matter how cheap and fast this is. Even the Project Board probably have to get other authority for changes of that kind. Please see Chapter 5 for more about where levels of authority and the control mechanisms are set up and recorded.
Setting up a change budget
Giving the Project Manager a change budget makes sense. This can be set up and authorised stage by stage, or for the whole project. Having a change budget to accommodate unforeseen changes avoids the Project Manager constantly calling in the Project Board to approve every single change, no matter how small. If the board doesn’t authorise a budget and only authorises the Stage Plan, then every change has to be escalated because, by definition, a change isn’t on the plan and so the work isn’t authorised.
Paying for Off-Specs and RFCs
The cost of an Off-Spec often, though not always, falls to a supplier because the supplier hasn’t delivered to the customer’s specification. Often, the cost of an RFC falls to the customer, because it’s a change from what the customer originally agreed.
Setting up a Change Authority
If the Project Board doesn’t want to be involved in all changes that are beyond the authority it’s willing to give to the Project Manager, then it has the option of setting up a Change Authority between the board and the Project Manager and with an intermediate level of authority. If cold fear has now gripped you and visions of long forms and endless committees are rushing before your eyes, you have good reason; but more of the downside in a moment.
A Change Authority can actually be quite a good thing – sometimes. In fast-moving projects but where the Project Board is very senior or geographically spread out, the delay in getting change approval from the Project Board can be problematical. If the board has set up a Change Authority that can react very quickly to change requests, perhaps even the same day, that can be very practical. The Change Authority can make a rapid decision and clear its lines with the Project Board later as necessary.
Okay, on to the nightmares and the downside. Some organisations set up the Change Authority in a very bad way. If a Change Authority is used it should not slow things down, and preferably should speed things up.
Controlling Versions – Configuration Management
PRINCE2 uses some really unfortunate language. Unfortunate, that is, if you happen to be a business user of the method rather than a career project specialist. ‘Configuration management’ is one of the worst terms if the objective is to make the method readily understandable. Configuration management (CM) is basically version control; you may know it as ‘versioning’. Actually, CM is slightly more than that, but not much more, and certainly not enough to worry about.
You can’t escape CM in any project, and won’t want to after you’ve read this section. To give a simple example of why you need it, say I have two different documents, one called ‘Revised Project Plan’ and the other ‘Project Plan – Revised’. Now, which one do I use? Clearly, the document needs something like a version number on the bottom or perhaps a date, so that I can see which one is more recent. But actually neither of the documents may be the latest version and there’s another one, more recent still, that I don’t know about. A central record would tell me that both of the ones I have are now superseded. That’s a simple example but it shows the need for configuration management and also how CM can help avoid problems and confusion. The rest of this chapter covers how, who, and also what you may and may not want to control.
Deciding How Much CM to Do
How much CM do you need in your particular project? You can choose one of two opinions:
You only configuration manage what you may change. If you’re not going to change something after you deliver it, you don’t need version control. For example, do you want to roll back the foundations of the building to an earlier version? Unlikely, to say the least.
You configuration manage just about everything. Even if the product isn’t likely to change after you complete it, you still want to know how far through it is in its development. So, you’re not going to change the foundations, but are they finished and signed off? This is status accounting, which can be useful not only for checking progress during stages but also as a double check at the end of a stage to make sure that you’ve done everything.
The trouble with CM is that you can tend to focus just on the specialist products – the specifications, new business procedures, brick walls, and computer programs that the teams are busy building. But you have to think about management products as well – such as the plans that you use to manage the project. These change and you need to know which is the latest one. Some of the PRINCE2 management products are classified as Baseline Management Products and it’s expected that you’ll configuration manage these.
Writing the Configuration Management Strategy
How are you going to do CM on this particular project is decided in Initiation and set down in the Configuration Management Strategy along with the other change management decisions. In that strategy you set down your objectives for change and CM and details such as what procedures you have and who runs them. The PRINCE2 manual defines the CM Strategy, but as always, don’t let that put you off if it looks too detailed, because you can always adapt the headings if you want to hold slightly different information.
Keeping CM Information on Products
You need to hold information on each item being managed. In PRINCE2 this information is held on something called a Configuration Item (CI) Record. The CI Record content contains very relevant information. Some of it may be excessive for your project but, as always, reduce the headings where you can to keep the record as simple as possible. Don’t hold information you don’t need.
Additional CI Information
Please sit down before reading this section: the author of PRINCE2 for Dummies is about to break with his usual practice and suggest adding things to a PRINCE2 product instead of taking things out! You may like to include the following items in the CI Record as and when you need them. The first two are from the previous edition of the PRINCE2 manual but they’ve been mysteriously dropped in the 2009 edition, and the third goes back even further. They’re mentioned here, because the information can be valuable
Lifecycle steps for the product
To help with status accounting, you may like to record the lifecycle steps so that you can compare this with the current status to know where the product is in its development. To give a simple example, the lifecycle steps of a report might be ‘draft’, ‘final’ and ‘approved’.
Knowledgeable person
The previous meaning of the term ‘owner’ related to recording the name of a person or team that understands a particular product, such as a technical specialist. Often this would be the person who built or installed it in the first place, but remember that CM goes on into the working life of products and so perhaps for many years. The person who built the product may have long since moved on, but you still need to know who to consult if you’re thinking of changing the product.
Security requirements
This heading was dropped some two editions of the PRINCE2 manual ago, but it’s actually rather useful. I suspect it was taken out because PRINCE2 was seen as being something for business, not just for government users, so readers were unlikely to be dealing with classified information. However, remarkably often this information is needed, even outside of government. Commercial information often needs to be handled with care, such as customer records. In a medical environment, confidentiality of patient information is clearly vital. If your project is dealing with information and any of it is confidential, you may like to think of adding this heading in to your CI Record to indicate what security is needed to look after it.
Construction location
You may also want to add even more elements to your record such as a location code for where the team builds a product, as distinct from the ‘location’ heading, which says where the product is at the moment, and even a country code with international projects. Such information can be very useful in problem solving and problem avoidance too, such as when things go wrong with measurements and you can see immediately that some products were built in a country using imperial measurements while other interfacing ones were built in a country using metric.
Change history
Usually, recording information on change history is also useful. The record then not only shows that something has been changed, but also why. If the change looks a bit odd, knowing why the change was made in the first place may prevent someone being tempted to reverse it.
Seeing that CM Is a Different Control
CM is inherently different from the rest of PRINCE2 controls (with the possible exception of part of risk management) because CM carries on when the project, and PRINCE2, stops. You need CM in the working life of products.
At the end of the project, you need to pass information on versions and possibly the procedures back into the organisation as a Follow-on Action Recommendation.