Definitions & Semantics - changing what?
|The word "change"
leads to many misunderstandings. It is used in different
contexts depending upon what is being changed. In Project
Management, there tend to be differing understandings of
expressions like "Change Management" and "Change
Control". The problems are compounded where
participants are unfamiliar with project work and do not
recognise the implicit context.
Here are some of the more common usages:
|Scope Change||Where a request is considered to change the agreed scope and objectives of the project to accommodate a need not originally defined to be part of the project.|
|Change Control (sometimes referred to as "Change Management")||The management process for requesting reviewing, approving, carrying out and controlling changes to the project's deliverables. Change Control is usually applied once the first version of a deliverable has been completed and agreed.|
|Configuration Management or Version Control (sometimes also called "Change Control")||Technical and administrative control of the multiple versions or editions of a specific deliverable, particularly where the component has been changed after it was initially completed. Most typically this applies to objects, modules, data definitions and documentation.|
|Change Management||Normally used to mean the achievement of change in human behaviour as part of an overall business solution.|
|Change Programme||Usually used to mean a large, multi-faceted business solution (not just the human behavioural element).|
In the ePMbook, we will try to use these definitions consistently. Remember that other people may be using them differently and that your team participants may be unfamiliar with the meanings. Try to make the context clear when you speak of "change".
Change is inevitable. During a project there will be many good reasons why things need to change. There will also be a few bad reasons - bad, but unavoidable. But there will also be many requests where the right answer is "no".
Let's consider some of those reasons...
|The business needs have changed||Business needs are changing ever more rapidly, particularly as competitors explore the new business models of eCommerce. All businesses must be willing to change if they are to remain competitive.|
|The organisation has changed||It is surprisingly common to find that the organisation undergoes some form of restructuring during the life of a project. This could involve mergers, acquisitions, being taken over, new departments, new business leaders, new products, new accounting structures, new locations etc.|
|Exploit technology improvements||The available technology improves constantly. All the time your Project Team are trying to exploit the various technology components, each of those components has a large team of people working to create a better version - and thus to make your version obsolete.|
|The organisation's priorities have changed||Although the scope and objectives of your project remain valid, the organisation may decide that there are other business needs that have high priority and should be addressed.|
|New business partners and channels||Organisations are responding to the rapidly changing marketplace by forming new business partnerships and alliances. New business channels are becoming available through those relationships, eg using industry hub portals and intermediaries.|
|New legislation and regulations||There may be unavoidable external requirements over which you have no control, such as new regulations for data privacy, changed regulatory reporting requirements etc.|
|Globalisation, standards etc||The organisation is making progress in presenting and managing itself as a global entity and, hence, there are new or revised standards for such things as website design, database definitions, corporate knowledge sharing, data warehouses etc.|
|Affect of other projects and initiatives||Other initiatives within the organisation result in revised needs for this project, eg there is a new accounting system so the interface from our new system will have to be changed.|
|We messed up||Or, to put it more discreetly, elements of the project's design and deliverables do not fully meet the defined need and will need to be re-worked.|
Why is there a distinction between scope change and other changes? In general, Project Managers should pay a great deal of attention to managing scope. Allowing the project's scope to change mid-course usually means added costs, greater risks and longer duration. Many projects fail due to poor scope management. Very often it is a large number of small scope changes that do the damage, rather than the big, obvious ones. The successful Project Manager has learned that rigorous scope control is essential to deliver projects on time and on budget.
The world-class Project Manager would not express this imperative in the same terms. The prime focus for the Project Manager should not be to deliver the agreed scope on time and on budget, but to optimise the benefit that is generated by the project. If that means allowing the scope to change then that scope change is a good thing, not a bad thing. It is wrong to resist all scope change. Where a scope change generates improved benefit, it should be proposed to the project's decision making body. Make clear the positive and negative impacts of allowing the change. Make sure the impact is fully reflected in the project's definition and performance criteria.
Watch out for the use of "scope change" as a defensive behaviour. In many cases, people will discuss scope changes in the context that a scope change is not the project's fault and must therefore be the business's fault. This is particularly important if the work is being performed by a different organisation under contract.
Watch out for the use of "scope change" as an aggressive behaviour. Sub-contractors may intentionally try to expand the size of their contract by establishing scope changes that lead them to do additional work outside the original agreement. Some contractors under-bid the cost of the work to gain the contract, in the belief that they will be able to make their profit out of scope changes.
There are many similarities and much overlap between Issue Management and Change Control. A large percentage of "issues" will directly or indirectly being asking for something to change. Conversely, most changes reflect and generate issues.
Some Project Management approaches combine these into a single process, which can scare people away from communicating issues. Some others treat them as separate processes, which can cause practical difficulties, inefficiency and misunderstandings. Clearly there needs to be some linkage. The best scenario is to present Issues Management as separate but related processes whereby an issue can evolve into a change request where appropriate.
|The decision whether
to accept or reject a change would be based on a number
of rules. The fundamental logic should be:
Scope should be clearly defined as part of the Project Definition. Much of the work at that time is directed at agreeing the optimum definition of the project - both in terms of its deliverables and in terms of how it will operate. This scope definition will form the baseline against which potential changes are assessed and against which the project's performance is measured.
In defining how the project will operate, the Project Manager should try to influence those factors that could lead to subsequent scope change. The importance of a sound Project Definition should be emphasised. Make clear the dangers and potential costs of subsequent changes of direction, but, equally, encourage the leadership to allow change where that would be beneficial. In the dynamic world of eBusiness, rapid change is the norm.
All participants should understand that the later in the project that a change is addressed, the greater the likely impact in terms of costs, risks, and timescale. It is wise to surface potential changes as early as possible. The change control process should make it easy to do so.
An efficient Scope & Change Control process should be defined. There needs to be a balance between flexibility and control. If the process is too onerous, either valuable changes will be lost or the participants will ignore the rules - leading to uncontrolled scope and configuration. If the process is too easy, then many changes may be applied with insufficient thought given to their merits and consequences.
It is common to define various responsibilities and authority levels so that routine changes can be dealt with efficiently but significant changes receive due management attention. Where a proposed change affects the scope of the project it should be seen as a business decision requiring approval from the business owners of the project (eg Project Sponsor, senior leadership, Steering Committee). Where scope is not affected, it may be agreed that the Project Manager has the power to approve the change within certain authority limits. In some projects, Change Control Boards are defined and convened to consider and approve change requests on a regular basis, say every two to four weeks. Different panels might be appropriate for handling different types of change request. For example, a technical panel might look at technology issues, departmental leaders might look at the business processes, and the HR managers might examine organisational issues. Above a certain level of impact, the request would normally be referred to the overall Steering Committee.
The basis of decision for Change Requests should be agreed as part of the Project Definition work. It should define how the Project Manager is allowed to exercise the power to approve minor changes, and should provide guidance for the decisions of the Change Control Board(s) and Steering Committee.
Particular considerations occur where the change impacts the relationship with an external sub-contractor. Each time the work content increases the contractor might reasonably demand further time, resources and fees. If the change is due to the contractor's own fault, then, arguably, there should be no allowance made.
|A European public sector organisation had
sub-contracted the development of a major new system to a
software house. Progress was slow and both sides were
raising many concerns. We were asked to investigate
various problems that had been building up.
One area of concern was raised by the sub-contracting software house:
The client organisation had a different view:
To the client organisation, a change meant, in effect, a formal re-negotiation of the contract - subject to the same extensive procedures as the original procurement contract. It would take months to approve a change request. To the software house, a change meant every instance where they were forced to change any completed element of the work due to some unavoidable problem with the original specifications. Given the enormous weight of the formal change approval process, it would be unrealistic to wait for formal approval except in the largest cases. What is worse, they probably would not get paid for those thousands of minor but essential changes.
Although it is not required for the Project Definition, this is a good time to establish the mechanism that will be used, particularly if it involves a system that needs to be selected, acquired and implemented. The Change Control system would normally be part of the same overall set of procedures and tools that will be used to support the other project management activities. A number of commercial software tools are available. It would also be straightforward to set up your own local system using client server or web technology. In relatively simple projects, the needs could be met by standard tools such as EMail and spreadsheets.
The Change Control process will involve a combination of procedures, responsibilities and systems. The key to success is to have a well-controlled but efficient process. Define and agree:
Here is an example process for dealing with issues:
Any participant or other concerned party may raise Change Requests. The Project Office team and Project Manager will ensure they are captured and proactively manage them to conclusion.
An initial review should be made to examine the need for the change, how it could be achieved and what the consequences would be. The most appropriate member of the Project Team would normally perform this review. Based on those conclusions, the recommended action would be proposed.
In this example, there are three possible courses for the approval of the change:
In making the decision, the Project Manager, Change Control Board or Steering Committee would be guided by the pre-established principles for making change decisions.
After the action is agreed the work is assigned for action by the Project Team and/or the external sub-contractor. When complete, the action would be reviewed and the Change Request closed. It is possible that the agreed action could have more than one stage. For example, it might be better to introduce a temporary solution so that the overall benefit from the project can be delivered, and then build a permanent solution after the system is live.
Not all changes follow the approved process. Often team members will be persuaded to make a change without using the approved procedure where it seems necessary but minor. Although this can seem practical to those concerned, it represents a risk to the project. The Project Manager and Project Office team should be alert for uncontrolled changes. Where necessary, changes should be painlessly re-directed into the correct procedure.
The Change Control process will run continuously during the project, and potentially beyond that into live running. The Project Office team and the Project Manager will administer and control the process.
Here is an example Change Request Form. Take a look at it as a web page.
In many ways it is similar to the Issue Submission Form. The difference is that the Change Request addresses specific changes to be reviewed, authorised and made, whereas the Issue Submission Form captures less-well-defined information. In the Change Request there is more attention to the exact nature of the changes, whether they are scope changes, where they lie in the project lifecycle, which specific document or deliverable references need attention, etc.
Specific attention is paid to the cost and implications, identifying where work will be required and what its impact will be in terms of cost, risk and timescale. In particular, a benefit case will be prepared to summarise why the change should be made.
The Project Manager, Change Control Board or Steering Committee will use this Benefit Case in making a decision, in line with the pre-established guiding principles.
The status of the Change Request and its approval level should be tracked. In addition to the database of Change Requests, there would be logs and various management reports to allow the project leadership to track and control the changes. The Technical and administrative tracking of the actual changes would normally be made using the Configuration Management process.
The Change Control process continues throughout the project, so no specific action is necessarily required at the end of each phase. Nevertheless, phase end is a good time to review the status of Change Requests, ensuring requests have been actioned in a timely fashion within the phase, and, in particular, allowing for their impact in the detailed planning for the following phase.
Some Change Requests may have been deferred for processing after the project is complete. This can be an easier option than disrupting the interrelated development and testing during the initial project. It might also be non-beneficial to delay the entire project to accommodate a change that could wait until benefit from the main functionality has been generated. At the end of the project, it is important that any outstanding actions are reviewed and the appropriate procedure is initiated to get them addressed. (It is easy to forget those promises after the project has finished.)
The Project Office should ensure all changes have been properly finalised. All Change Requests should either have been completed or passed onwards for subsequent processing. The permanent documentation and other deliverables (eg training) should have been updated to reflect the changes.
Change Requests may often reflect lessons to be learned for future projects. It is always worthwhile reviewing what can be learned and submitting any new knowledge or wisdom into the various knowledge repositories. Note, in particular, any situations where existing approaches or sample plans should be updated.