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.

I was talking to a group of managers in a multinational company, including a senior manager with a great deal of project experience, Paul Beaton. We were discussing the need for contingency time in Project Plans and I used the analogy of going to the airport. In the UK, getting to London Heathrow can be a huge problem and delays are very common. Nobody in their right mind allows only the minimum travel time in order to get to the airport at the last possible moment for check-in, with no contingency allowance for travel delay. If you need contingency just for a flight, I said, how much more do you need it for a project? Paul added to that thinking: You’re rushing to the airport with barely enough time to catch the flight when you get a call telling you to divert and pick up a package from Gatwick airport, some 40 miles away, before going back to catch the flight at Heathrow. That’s exactly what scope creep is. You only had just enough time to get to the airport in the first place, but now you have an extra 80 miles on a congested London motorway and a pick-up to do as well. And you still expect to make the flight?

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.

Issue, Issue Report and Issue Register. A project Issue is a communication from anyone in the project (or if you prefer, anyone at all with an interest in the project – see the next tip) direct to the Project Manager. An Issue can be sent at any time during the project and it can be about anything – it doesn’t have to relate to change. As soon as the Issue is received it’s logged in the Issue Register so it can be tracked or, if the Project Manager decides that the matter can be handled informally, into the Daily Log. If it goes into the Issue Register, the Project Manager first records the full detail of the Issue on an Issue Report.

The PRINCE2 manual says that anyone with an interest in the project can send in an Issue. You may want to think about that. I’ve worked in organisations with a few control freaks who want to try to influence everything, whether in their area or not. If project Issues are wide open, people like that are likely to bombard the Project Manager with lots of Issues in an attempt to swing the project the way they want it to go. An alternative is to restrict Issues to people inside the project. If a person outside wants something, then he can talk to the Senior User on the Project Board. If he convinces the Senior User, then the Senior User can put in the Issue.

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’.

Baselined. This means a product has been quality checked and signed off. This is a configuration management term.

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).

After a product has been baselined, any change always goes through the change control procedure. Not to do this means that quality is abandoned. There’s no point in quality control staff carefully checking a product against set criteria and signing it off as compliant if a junior team member can walk in five minutes later and completely change it. After something is quality checked and signed off, nobody must touch it except under change control. Even if someone has a really good idea for an improvement and it may not take long to do, this may not be the right time to do it – such as the night before an important demonstration in front of customers.

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.

A company wanted a new software package written to transmit data to handheld computers used by their field staff. The company agreed the requirement with the supplier and said what handheld computers it was using. However, the supplier gave the company an adapted version of their very latest software package to give really good value and give additional functionality – in excess of the specification agreed. It worked fine in testing with the supplier’s handhelds. However it failed at the customer site because the customer company’s handheld computers were older and didn’t support the technical requirements of the new system. The new software was Off-Specification because it was too good. In the end the supplier company bought new handheld computers for the customer, at the supplier’s expense, because the original specification was clear and it was cheaper to buy new kit for the customer than to start all over and re-configure the software package. Lesson One in ‘How to wipe out your profits’.

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.

You can combine a concession with a Follow-On Action to create, effectively, a temporary concession. If something is substandard but you don’t have time to correct it without missing the fixed project delivery date, you can make a concession and accept the product, but only temporarily. You require the supplier to provide a new product that’s up to standard and come back some time after the project to install it. You pass a Follow-On Action to a manager in the organisation, who takes responsibility for it after the project closes down and makes quite sure that the supplier provides the improved product. Chapter 9 has more on Follow-On Action Recommendations.

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.

Don’t confuse the Issue Register with the Risk Register. People commonly mix these two up, and some even try to combine them. Remember that the information in these two registers is very different, and the way you handle them is very different as well. Some people argue that a risk is an Issue that hasn’t happened yet and an Issue is a risk that has. Not true, because an Issue can be about anything, such as a question or a good idea; it doesn’t have to be risk-related at all.

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?

When planning the project and especially the stages, think what the level of Project Issue-related work is likely to be – in terms of the likely number and the likely complexity. You need to include resources and time in your plans for the impact analysis, which in some projects can be substantial.

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.

If you’re changing a product – deliverable –, don’t forget that you also need to change its Product Description. Chapter 14 on planning explains the nature and use of Product Descriptions.

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.

For a finer degree of control, a change budget can specify individual change amounts and a cumulative amount. For example, the Project Manager may have a change budget of £60,000, but no one change can cost more than £10,000. If she needs to make a change that costs £15,000, or costs £10 but takes the total change for the stage over the £60,000 limit, then the Project Manager has to take the change to the Project Board.

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.

If a decision is within the Project Manager’s authority but she wants to talk to one or more board members in any case, she can always do that using the facility in PRINCE2 for getting ad hoc direction – in other words, ‘running it past the boss’. One time you may need to do this is in the case of priorities for RFCs. Imagine that the Project Manager has 20 RFCs from different junior members of staff in the business area. Guess what priority every single person put on their RFC? Yes – number one, top priority. So in this situation the Project Manager may go to the Senior User, explain that she has time to do only five of the RFCs, and ask the Senior User to reassess the priorities and tell her which RFCs are really useful.

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.

One large company has centralised the Change Authority: it’s a committee that meets once a month. Any project that wants any change, no matter how small, has to write a paper and put it to the Change Authority. The committee reviews all of the changes and decides which to allow and which not to. That means that any change in a project can take up to a month to get to a decision point. Where changes can involve knock-on effects to other projects and operational areas such a mechanism may be justified as part of a change management procedure. But to apply it to all change?

In a fast-moving project, the Project Board could decide that the Executive will be the Change Authority for urgent changes. Changes beyond the Project Manager’s authority go to the whole board, but where an urgent reply is needed, the Executive will give a same-day decision and sort things out later with the other board members.

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.

Status Account. This is a report in PRINCE2 and is a snapshot of a set of products at a particular point in time to know what state they are in.

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.

If you use a CM computer tool you may have little or no choice about how you identify products, as the tool may have an inbuilt coding system. You may also have organisational standards that dictate how you identify products, particularly if the organisation is experienced in this area and has to control a large number of products in their working life, such as with IT products and computer departments.

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.

Copenhagen Airport in Denmark owns Tyne Tees Airport in the UK. Some of its projects involve work in both countries and its project staff need to be able to identify what products teams are building and where. In circumstances like this a country code can be very useful.

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.

If you want a new oil filter for a car, you go into a motor spares shop and look at the reference card for the make, model, and year of the car. The card tells you what version of oil filter you need from the wide range on the shelf below. That’s CM, but in the working life of the product. The project to design the car may have finished a number of years before.

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.

Follow-on Action Recommendation. This is something the project recommends that the organisation does after the end of the project. In the case of CM, that action is ongoing control of the versions.