CHAPTER 8: CHANGE
Agile says:
Agile expects changes and is geared to accept them where they have sufficient impact or benefit, until late in the development cycle.
PM4A says:
PM4A regards change as a problem and builds a big procedure to review them, involving the client in decisions about change.
The difference matters because …
If requirements are not fully known at the outset, a lot of time and effort can be used up by PM4A going through formal procedures. The less well-defined the requirements, the greater the threat of bringing a PM4A project to its knees.
PM4A’s Change chapter also covers version control, a subject not touched by Agile. Without version control, a project will soon get into serious problems, such as ‘Who has what?’, ‘Are we working on the right version?’, ‘Why did we create this version?’, ‘Someone has made a change to this version, but I don’t know what it is’ and many more.
Here is what APM should do:
APM is designed to start projects and start delivering working products and benefits when the full requirements may still be pretty fluid. We need to move towards the Agile way of easy entry of changes, while having a backstop for changes that are so big in size or impact that they need a decision at client level.
We need to include version control. If APM doesn’t do it, something else will have to. You can’t just ignore it.
8.1 Philosophy
Change consists of two closely linked activities, change control and version control. Neither can function effectively without the other. Change directly supports the principles of ‘focus on products’ and ‘manage by exception’, and indirectly the ‘continued project justification’ principle.
8.2 Overview of issue and change control
8.2.1 Change control
In any project there will be changes for many reasons:
•Government legislation changes, and this must be reflected in the product specification.
•The users change their mind on what is wanted.
•Because the development cycle is making the product owner think more and more about the product, extra features suggest themselves for inclusion.
•There is a merge of departments, change of responsibility, company merger or takeover that radically alters the project definition.
•A supplier cannot meet an acceptance criterion, such as performance.
•A product delivered by an outside contractor or another project fails to meet its specification.
•All of these need a procedure to control them and their effect on the project. This procedure must make sure they are not ignored, and that nothing is implemented of which the appropriate level of management is unaware. This includes the client.
•An issue is the formal way into a project of any inquiry, complaint or request (outside the scope of a quality review question list). It can be raised by anyone associated with the project. Issues fall into three groups:
1.A desired new or changed function.
2.A failure of a product in meeting some aspect of the user requirements or development time limit. In such cases, the report should be accompanied by evidence of the failure and, where appropriate, sufficient material to allow someone to recreate the failure for assessment purposes.
3.A problem or concern.
In other words, there is no limit to the content of an issue beyond the fact that it should be about the project.
•Any error found during a quality review normally goes on an action list. There are two exceptions to this:
1.Where an error is found during quality review that belongs to a different product from the one under review.
2.Where work to correct an error found during quality review cannot be done during the agreed follow-up period.
Such errors are put onto an issue as a way of getting them into the change control system.
When considering the procedures for handling issues, there is the possibility that the subject will be outside the scope of the project. An example might be a fault in a component that is used in many products across the department or business. Although it is being used in the project, it clearly has a wider implication. There should be a procedure to close the issue off as far as the project is concerned and transfer it to the relevant higher level. The same approach applies if the project is part of a programme and an error is found in a quality review that affects other projects in the programme.
All possible changes should be handled by the same issue and change control procedure. Apart from controlling possible changes, this procedure should provide a formal entry point through which questions or suggestions can also be raised and answered.
8.3 Issue and change control procedure
The procedure has five steps:
1.Capture
2.Examine
3.Propose
4.Decide
5.Implement
Figure 8.1: Change control steps
8.3.1 Capture
Issues should be handled formally. A project issue should be raised, preferably by the originator, and this should be entered on the action log by the version controller, who will allocate the unique identifier to the issue and pass one copy back to the originator and another to the team. The issue is now classed as ‘Open’.
The first step is to carry out a brief analysis, just enough to decide what type of issue it is. The outcome is normally one of the following:
The issue is proposing a change to a baselined configuration item. The issue is a request for change and the decision can only be made by the client (or change authority if one has been appointed).
The issue requests a change to the agreed user specification, acceptance criterion or a product description. The issue is a request for change and should be added to the PRL for prioritisation with the other remaining work.
A product does not meet its specification. The issue is an off-specification.
The issue asks a question or voices a concern but will not lead to a product change.
8.3.2 Examine
The team allocates the issue to the person or persons on the development team best suited to perform a full impact analysis. The issues are evaluated in terms of their impact on:
•Time;
•Cost;
•Scope;
•Benefits; or
•Risks.
The aim is to make recommendations on their resolution. The analysis should cover all aspects, business, user and supplier.
If the request is a change to a current work package, it can be discussed by the team at the next stand-up meeting to decide if it should be added to the current work package or sent to the PRL.
All project issues must be closed by the end of the project or transferred to follow-on actions, part of the end project report. The transfer of an issue to these recommendations can only be done with the approval of the client.
8.3.2.1 Request for change
A request for change records a proposed modification to the user requirements.
The request for change requires analysis to see how much work is involved. The version control records hold information that will help to identify what other products will be affected.
It is particularly important that any baselined products that will need to change are identified because the client has already been told of the completion of those items. The client must therefore approve any change to such items.
8.3.2.2 Off--specification
An off-specification is used to document any situation where the product is failing to meet its specification in some respect.
The next unique issue identifier from the register is allocated and a copy of the issue is sent to its author. Development team members carry out an impact analysis to discover which products are affected by the off-specification. They then assess the effort needed.
8.3.3 Propose
With the results of the impact analysis available, the next step is to look at alternative actions and propose the best response.
In APM, the best response is noted on the project issue. A decision is made on whether the change can be made within the current work package. If not, the issue is added to the PRL, where it will take its turn in the next re-prioritisation of requirements.
To help in the prioritisation of an issue, it should be awarded a priority rating based on MoSCoW. This can be one of four:
•Must have.
•Should have.
•Could have.
•Won’t have.
8.3.4 Decide
8.3.4.1 Request for change
For the request for change to be implemented, it must be approved by the appropriate level in the severity table. Whose decision it is will be documented in the change control approach.
The decision must be made by the client if the change is to one or more configuration items that the client has already been told are complete (to any baseline, not necessarily the final one). More than anything, this is to retain the client’s confidence level. If the client has been told that something is finished and later finds out that it has been changed without consultation, their sense of being in control evaporates. The matter is referred to the client by means of a problem report (see appendix A.4).
The client is the key role in any request to implement any major changes. All those requests for change that have not been decided by the development team are passed to the client. It should be the client’s job to put them in order of priority for a decision.
The client's decision may be to:
•Implement the change;
•Delay the change to an enhancement project after the current one is finished;
•Defer a decision until a later meeting;
•Ask for more information; or
•Cancel the request.
If the client has delegated the responsibility for a decision on problem reports to the development team, then the team will play the role described above. The decision should be documented on the problem report and in the action log.
Whenever its status changes, a copy of the issue report should be sent to the originator.
8.3.4.2 Off-specification
As with requests for change, the decision on action is taken by either the development team or the client. If the error is because of a failure within the development team’s responsibility, the onus is on the team to correct the problem within the work package. If this cannot be done, rather than extend the allowed time for the work package, lower-level requirements should be omitted and returned to the PRL for future consideration.
If the off-specification requires changes to one or more configuration items that the client has already been told are complete (to any baseline, not necessarily the final one), the client must make the decision based on a problem report.
The client's decision may be to:
•Correct the fault – this means putting the issue on the PRL;
•Delay correction of the fault to an enhancement project after the current one is finished;
•Defer a decision until a later meeting; or
•Ask for more information.
The decision should be documented on the problem report and the action log, and an updated copy filed. Whenever its status changes, a copy should be sent to the originator.
8.3.5 Implement
The development team is responsible for scheduling any approved changes. This work will possibly involve the issue of a new version of one or more products by the version controller.
On receipt of a completed request for change or off-specification, the version controller should ensure that any amended products have been re-submitted to the configuration library. The finalised request should be stored and the originator advised. The action log should be updated with the final details and the originator advised.
8.4 Version control overview
If your project creates or changes more than one product, or you have more than one person working on the same or different versions of the same product, then you already are dealing with some form of version control. It’s just a question of whether you are doing it in a controlled manner and can track what’s going on.
No organisation can be fully efficient or effective unless it manages its assets, particularly if the assets are vital to the running of the organisation’s business. A project's assets likewise must be managed. The assets of the project are the products that it develops.
Within the context of project management, the purpose of version control is to identify, track and protect the project's products as they are developed.
In APM, the norm is for someone in the development team to do the version control job in addition to their normal work. It is better to have one person responsible, rather than attempt to share this work.
The objective of version control is to achieve a controlled and traceable product evolution through properly authorised specifications, design, development and testing.
This objective is met by defining and ensuring:
•The issue and control of properly authorised specifications;
•The issue and control of properly authorised design documents;
•The issue and control of properly authorised changes to the specification or design documents; and
•The control of the various versions of a product and their relationship with its current state.
Version control is also the process of managing change to the elements that comprise a product. It implies that any version of the product and any revision of the chapters that make up the product can be retrieved at any time, and that the resulting product will always be built in an identical manner. Product enhancements and special variants (such as foreign language documentation) create the need to control multiple versions and releases of the product. All these must be handled by version control.
Version control is a discipline that:
•Records what components or products are required in order to build a product;
•Provides identifiers and version numbers to all products;
•Controls access and change to components of a product once they have been declared complete by the developer;
•Provides information on the impact of possible changes;
•Keeps information on the links between the various parts of a product, for example, what items comprise a product, where is component X used, or what does the ‘full product’ consist of;
•Provides information on the status of products (configuration items) being developed, including who is responsible for the development;
•Is the sensible storage place for product descriptions; and
•Gives a project team the assurance that products are being developed in the correct sequence.
Version control holds a central position in project work. Product breakdown structures used in planning provide the identification information for the configuration items. The links allow the construction of the product flow diagrams. They offer input and verification of the products required for a plan. You cannot adequately do change control without version control. It provides product copies and product descriptions for quality checks and keeps track of the status of the product. It provides the information to construct a release package, either a complete one or a partial one, and then records the issue of a release.
Version control records are valuable assets in themselves. Version control helps a business know what its assets are supposed to be, who is responsible for their safekeeping and whether the actual inventory matches the official one.
Version control gives control over the versions of products in use, identifies products affected by any problems and makes it easier to assess the impact of changes.
Version control supports the production of information on problem trends, such as which products are being changed regularly or frequently, thereby assisting in the proactive prevention of problems.
Where the end product is to be used in more than one place, version control helps organisations to control the distribution of changes to these operational sites. Where there is any volume of changes, there will be the need to decide between putting together a ‘release package’ of several changes or issuing a complete new product. The latter may be a more controlled and cost-effective means of updating an operational product than sending out one changed product at a time. The decision and control mechanisms for this are part of version control.
Version control supports the maintenance of information on proven reliable releases to which products can revert in case of problems.
Because all products are under the control of version control once they have been developed, it makes it more difficult for them to be changed maliciously, thus improving security.
The data held in the version control library helps to recreate a release after any disaster by identifying the products required and their storage place.
8.4.1 Version control detail
Version control covers all the technical products of a project. It should also be used to record and store management and quality products, such as plans, quality check details and approvals to proceed.
8.4.1.1 Costs
There are the expected costs of training a team member in version control. There may be a central office (say part of a central project support office) that provides version control functions to several projects. If so, liaison must be set up to work with this role.
It is very difficult to keep the comprehensive records required to do a complete job of version control in a medium to large project without a computer database and software. The costs here are far outweighed by the increase in speed, capacity and detail of information. The increase in speed of reaction by the version controller probably reduces the number of version controllers needed to cover all the site’s products.
The need to go through the version control tasks may slow down slightly the handover of a finished item or the implementation of a change. However, this penalty is very small when weighed against the risk and impact of operationally using a product that is from an incorrect release or has not been checked out. Without it there is also the risk of more than one person changing a product simultaneously, resulting in all but the final change being lost.
8.4.1.2 Possible problems
If products are defined at too low a level, the version controller may be overwhelmed by the amount of data to be fed into the library. This is a particular problem when no version control software is being used.
If products are defined at too high a level, the information for impact analysis may be too vague and result in a larger than necessary product change being indicated, e.g. altering a whole set of sub-products when only one sub-product is affected.
Procedures must cater for emergency changes, where an emergency change is required in order to let the operational product continue.
Where version control is new, development staff may be tempted to view its controls as bottlenecks and bureaucracy. However, it has been used in engineering for many years and is regarded in those circles as essential. It is also regarded as an essential part of any quality product, should you be looking for accreditation under such standards as ISO 9001. It is regarded as essential because of the control it gives and experience over many years, which has shown its value and the cost of problems arising when it is not used.
8.4.1.3 When is it done?
A version control approach is required as part of the Propose phase. This should state:
•What method is to be used;
•Who has the responsibility for version control;
•What naming convention will be used to identify products of this project;
•What types of product are to be covered; and
•What types of status are to be used (e.g. ‘allocated’, ‘draft available’, ‘quality checked’)?
Once a product has been identified as required, it should receive an identifier from the version control method. Sensibly, this should coincide with the creation of a draft product description.
Among the version control planning activities required are those to identify what baselines will be required (baselines are explained later in this chapter) and for what purpose, which baselines exist concurrently, and which cannot, and when baselines will be taken.
The status of a product should be tracked from the moment the product description is created.
8.4.1.4 Version control records
The detail to be kept about the products will depend to some extent on the complexity of the end product, the number of products, the resources available to keep the records and the information demanded by the maintenance and support groups. Table 8.1 shows a list of potential information about a product that should be considered against the needs of the project.
It should be noted that the first three pieces of information uniquely identify the configuration item.
Table 8.1: Assessing the Needs of the Project
8.4.1.5 Baselines
Baselines are moments in a product’s evolution when it and all its components have reached an acceptable state, such that they can be ‘frozen’ and used as a base for the next step. The next step may be to release the product to the customer, or it may be that you have ‘frozen’ a design and will now construct the products.
Products constantly evolve and are subject to change as a project moves through its life cycle and, later, in the operational life of the product. A development team will need to know the answer to many questions, such as:
•What is the latest agreed level of specification to which we are working?
•What exact design are we implementing?
•What did we release to site X last January?
In other words, a baseline is a frozen picture of what products and what versions of them constituted a certain situation. A baseline may be defined as a set of known and agreed configuration items under change control from which further progress can be charted. This description indicates that you will only baseline products that represent either the entire product or at least a significant product.
A baseline is created for one of several reasons:
•To provide a sound base for future work.
•As a point to which you can retreat if development goes wrong.
•As an indication of the component and version numbers of a release.
•As a bill of material showing the variants released to a specific site.
•To copy the products and documentation at the current baseline to all remote sites.
•To represent a standard configuration (e.g. product description) against which supplies can be obtained (e.g. purchase of personal computers for a group).
•To indicate the state the product must reach before it can be released or upgraded.
•As a comparison of one baseline against another in terms of the products contained and their versions.
•To transfer configuration items to another library, e.g. from development to production, from the supplier to the customer at the end of the project.
The baseline record itself should be a product so that it can be controlled in the same way as other products. It is a baseline identifier, date, reason and list of all the products and their version numbers that comprise that baseline. Because of its different format it is often held in a separate file.
8.4.1.6 Version auditing
Version auditing checks whether the recorded description of products matches their physical representation and whether items have been built to specification. There are two purposes of version auditing. The first is to confirm that the version control records match reality. In other words, if my version control record shows that we are developing version 3 of a product, I want to be sure that the developer has not moved on to version 5 without my knowing and without any linking documentation to say why versions 4 and 5 have been created. The second purpose is to account for any differences between a delivered product and its original agreed specification. In other words, can the version control records trace a path from the original specification through any approved changes to what a product looks like now? These audits should verify that:
•All authorised versions of items exist;
•Only authorised items exist;
•All change records and release records have been properly authorised by the development team; and
•Implemented changes are as authorised.
Version auditing is defined as an inspection of the recorded version control description and the current representation of that item to ensure that the latter matches its current specification. The inspection also checks that the specification of each item is consistent with that of its parent in the structure. In a sense, it can be regarded as similar to stock control. Does the book description match with what we have on the shelf? In addition, the audit should ensure that documentation is complete and that project standards have been met.
In engineering establishments, the aim of version auditing is to check that, in spite of changes that may have taken place in requirements and design, the items produced conform to the latest agreed specification and that quality review procedures have been performed satisfactorily. This verifies at successive baselines that the item produced at each baseline conforms to the specification produced for it in the previous baseline, plus any approved changes does this.
Version audits should be done:
•Shortly after implementation of a new version control system;
•Before and after major changes to the structure of the project’s end product;
•After disasters, such as the loss of records;
•On detection of any ‘rash’ of unauthorised products; and
•Randomly.
8.4.1.7 Version audit checklist
Here is an example audit checklist. The following items should be examined:
•Do the version records match the physical items?
•Are (randomly tested) approved changes recorded in the action log? Are they linked to the appropriate products? Is their implementation controlled by the version control method?
•Does the version library accurately reflect the inclusion of any random products? Are there links to relevant project issues?
•Are regular version audits carried out? Are the results recorded? Have follow-on actions been performed?
•Are (randomly tested) archived and backup versions of products retained and recorded in the correct manner?
•Are the recorded versions of products used in multiple locations correct?
•Do product names and version numbers meet naming conventions?
•Is version library housekeeping carried out in accordance with defined procedures?
•Are staff adequately trained?
•Can baselines be easily and accurately created, re-created and used?
8.5 Links
There is a very strong link between change control and version control. They are inseparable. You can’t have one without the other. It is sensible to give the same person or group responsibility for both elements.
Version control links to quality. If you lose control over which versions should be used, release old versions of components or allow the release of an untested change, the quality of the product will suffer.
8.6 Dos and don’ts
•Do relate the complexity of the version control method to the needs of the project.
•Don’t underestimate the importance of version control. As said at the beginning of the chapter, if there is more than one person working on the project, if there will be more than one version of a product, you need version control. Make sure it is adequate for the job.
•Do think about the stability of the customer’s specification before you dive into a project. The less stable it is, the more change control will be required and the higher the cost of authorised change is likely to be.
•Don’t underestimate the importance of change control. There is no project control without it.
8.7 If it’s a large project
APM is intended to accommodate changes smoothly and until late in the development cycle. Any change requests are noted on a project issue and added to the PRL for prioritisation. In the Plan phase there is a point where the client is asked if they wish to put any limit on the size of change that can be allowed without reference to the board.
8.8 If it’s a small project
Members of the team can probably do version control. I looked at a feasibility study where one of the analysts performed the version controller’s job. It took about two hours each week. There was a lockable filing cabinet in which the various versions of sections of the report were kept. Team members were responsible for telling the version controller when they wanted to move to a new version. The version controller checked the log and allocated the next version number, having first logged the reason for the change, i.e. a reference to the issue. These reasons had to be documented. Once a fortnight the analyst would take the configuration records round the office and check that there was a match between the records and the version numbers being used (version audit).
Change control will still be important.