Reactive project change management
The ability to cope successfully with project uncertainty is important towards the survival of an organisation within any competitive environment. Although uncertainty is always present in all aspects of projects, the worst effects can often be avoided by the anticipation and development of strategies to deal with it.
The prevention and management of uncertainty is built into all projects. This indicates that present-day change management models are proactive rather than reactive. Current research is working towards the identification and utilisation of proactive project tools and techniques with a large amount of literature available on planning and behavioural techniques. If the conventional linear project management techniques of project plans, milestones and tasks are established and adhered to, proactive change management is satisfactory. The majority of models may be termed as proactive; however, given the presence of uncertainty, there is sometimes a need to react in a positive and systematic manner to the unplanned.
As the competitive world does not allow any project to run without change, there is a need to be able to deal reactively and systematically with it. The objective is to allow projects to succeed by minimising the impact that the management of unforeseen change can have on the quality of deliverables and team behaviour.
This study concentrates on the analysis and development of a reactive change management model to deal with unforeseen changes. The model is developed to compliment proactive project management tools and provide a systematic way that projects can evaluate and react to evolving uncertainty while managing stakeholder's expectations.
Research and Findings
Within any project lifecycle, there is a requirement to continually manage changing requirements, objectives and goals. However, there is a critical phase where the management of change can impact on project success. For the purposes of this study, this phase is referred to as the ‘latter stage of a project’. On the examination of the Waterfall Model (Hammer, 1990; Morton, 1991), this study deduces that this critical point occurs between the end of implementation phase and the start of the integration test phase.
Proactive change management is well researched within both the organisational and project context, with models such as the Capability Maturity Model (CMM) and established methods associated with project control and tracking evident (Paulk, 1993). These models provide a basis whereby projects are geared to deal with uncertainty and manage its consequences.
However, the systematic evaluation of ad-hoc changing project requirements is often an afterthought. As deviations are identified and interpreted, unforeseen project changes are addressed on a ‘need-to-do-basis’. As a sound project basis is established, a systematic evaluation of changing project requirements should be considered.
A solid method on how projects can tackle change reactively, to compliment the proactive planning, is an essential tool and is often missing. This is not to say that present research does not deal with reactive management, in fact it does so at organisational level (Perkins, 1999). It realises that if change is apparent, it is to be managed within the organisation at large rather than the project itself. Leading from this is the principle that reactive project change management is very much on an ad-hoc basis as the project elements that lead to the change are not uniform (Scacchi, 1995). While this may be a generalisation, there is a model developed by Haines which gives a very good insight into how change should be dealt with and implemented (Haines, 1998). The model, known as the Roller Coaster Model, is shown in Exhibit 1.
Exhibit 1: Roller Coaster Model of Change.
Exhibit 1 may be summarised as follows by looking at the psychological or behavioural elements: -
Stage 1: Shock and denial
As a project manager, one must be extremely well prepared to accommodate or expect change in the latter stages of a project. The guidance that must be given to the project team in order to overcome the change scenario is essential.
Stage 2: Depression and anger
The fact of change is that when you identify and accept the elements of change and begin the method of resolution, and then there is little a project manager can do to reverse the nature of the work. This can be looked as the acceptance of the problem.
Stage 3: Adjustment
The team and management alike must adapt and commit to the change and work in tandem to deliver the required solution as indicated in the previous steps.
Stage 4: Rebuild and Implement
This is the stage where the delivery and implementation of the change resolution becomes a reality. The empowerment that is bestowed upon the team comes to fruition and the deliverables are seen.
Haines discusses the soft issues regarding project team members ‘hanging in’ and adapting to the change. (Haines, 1998) This Roller Coaster Model (Exhibit 1) is particularly applicable to the emotions that are used when attempting to address and implement elements of change.
Industrial research with respect to the implementation of change has been studied with the discovery of some interesting results (Stallworthy, 2001). The research indicates that for those involved in projects, they are keen on limiting (or even eliminating) change from the project lifecycle. The research continues to point out the disastrous effects that change has had on projects in general with an emphasis on the following solutions: -
• Pilot phase: This is not unusual for any project and many research authors have advocated strongly the use of the pilot phase prior to any design been commenced (Nolan, 1979).
• Magnitude of the step: Prior to commitment, both the organisation and management must analyse the magnitude of the change and hence the magnitude of the step the organisation needs to take to complete the project.
• Approval: Work must have full ‘buy in’ from all involved if the project is going to be successful. This consent is generally given based on estimation of costs, quality and time. Without such approval, the project is likely to fail.
This view is supported by various researches (Standish Group, 2001). However, the key to this approval is that realistic estimates need to be provided
These elements, while not guaranteeing total elimination, contribute to project implementation being successful and allow for the factors of the Roller Coaster Model being coped with. These indicate steps that must be adhered to when contemplating the introduction of change in a project ranging from the soft elements to the practical steps that should be followed.
Reactive Project Change Management
How to Deal with Reactive Change within Projects
This study concentrates on the assessment of changing requirements with emphasis on software development projects. Evaluation questions are presented in Exhibit 2 to investigate current industry practice and validate the action that is taken when managing change in the latter stages of the project cycle.
Two large-scale software development projects are assessed which offer different characteristics. The project manager, in each case, was interviewed to determine how change was reacted to (Exhibit 2). The objective of the investigation is to determine if change, when introduced late in the project lifecycle, is managed in a systematic manner without impact on the project objective.
Exhibit 2: Analysis of Software Development Projects Concenring the Principles of Change.
Using the investigation as a base, it shows that projects react to change in the following ways (Exhibit 3): -
Exhibit 3: Current Method to Reacting to Project Change
The model in Exhibit 3 displays the following characteristics:
• All projects should be aligned strategically at the initial conception of the project.
• Projects need to be aligned with customer expectations, stakeholder's needs and organisation strategy. Changes within the project should ideally be strategically aligned with these same variables.
• Reactive change management techniques are not established in a way that allows adoption from one project to another. In essence the reactive project change management techniques are ad-hoc and are not suitable when circumstance changes.
• There is no evidence to suggest that project change is prioritised or balanced against on-going work. No approach or technique is used to determine how such changes rank against current or on-going project development work.
Reactive Change Management Framework
To comprehensively evaluate changing requirements, this study proposes that this model be developed to the extent of where it can represent a complete reactive project change model. With this, there is a need to examine the entire project from initial conception right through to closeout. Two elements are highlighted that are applicable to change management and hence they can be identified as two discrete models within the one reactive change management model:
- Strategic model: Such a model is necessary for all project organisations to plan and assess the impact of the project upon its goals and objectives. Strategic alignment incorporates such issues as agreement of strategy, determination of risk, agreement of project plan, etc.
- Value model: -This study proposes that the evaluation of the change should be with respect to the functionality and value it can deliver to the current project requirements.
Strategy can be defined as a mixture of knowledge and assumptions about the organisation, goals, objectives, actions, milestones, budgets and plans that are all based on a foundation of knowledge of customers, suppliers and the general environment (The Corporation Management, 1990). A strategic model is made up of the following characteristics:
• Organisation Strategy: - Strategic intent should build on core competencies and things that the organisation can do well. It should be reflected at the project level and adhered to during the management of project change.
• Alliances: - The joining together of complementary assets, where needed, allow the use of knowledge and resource pools. Where shortfalls exist in the skills or knowledge that is required to carry out change, appropriate alliances are needed.
• Project Analysis: - Changing project requirements need to be aligned with organisation and project strategic objectives. Analysis is performed with such objectives so as to validate that the change to be implemented is in line with marketplace, organisation and overall project objectives.
• Strategic Leader and Team: - Research continually indicates that for projects to be a success, strong committed leadership is required. This ensures that both projects and change management are well supported from top management and are performed with direction and purpose:
• Based on the type of project, the project team-type and size should be selected accordingly. The general rule of thumb is that for small to mid-sized projects, the use of a functional team is considered, for larger projects a dedicated project team is required.
• Project manager skills and desires must match the type of team. As leadership is a strong attribute for a dynamic team, it is essential that the qualities that the manager brings to the team be aligned with the type of team and the type of product to be delivered.
• Project Balancing: - Project effort must be balanced with respect to current work. Project team must gauge the competencies that are required with respect to the advanced nature of technical project and these competencies must be balanced with existing work.
• Plan the Project: - As easy as it may sound, the project change needs to be fully planned from a resource, cost, time, control and quality viewpoint with the aim of supplying a plan that can be executed and adhered to.
• Involve Customers in Development: - Many projects fail to meet market place expectations because they fail to meet customer requirements. This fact is emphasised by the Standish Group's assessment of why projects fail (Standish Group, 1995). By involving the customer in the design and development stages of a project, the end product will more consistently fit with the intended project purpose.
A strong and focused team with a strategically focused leader is of the utmost importance when reacting to change. This may be further improved by the full involvement of the customer.
The elements of the strategy that are incorporated into the reactive change management framework (Exhibit 4) are: -
• Project Plan: - The project plan should be viewed as a guideline or tracking system to indicate where the project currently stands. Such a plan constitutes the basis on which the current status of deliverables can be gauged with respect to costing, time and quality. The inclusion of the project plan module identifies where the project currently stands before even considering the changing project requirements.
• Strategy Checklist: An analysis of the changing project requirements with respect to the strategic objectives of the organisation is included as part of the strategy checklist. It presents a method for the project stakeholders to determine if all factors are included when the project change is aligned.
If the project change does not meet the strategic goals of the organisation it should not be considered as part of the project (see the summary and methodology section for an outline on the criteria).
This study argues that a key element to reactively managing change is a model that can highlight the function of the changing requirements with respect to the project and indicate the value that such changes have on the project. Such a methodology of functional analysis combined with value is described and presented through the concept of value management and value engineering (Sievert, 1991).Two areas are used in order to provide a systematic method evaluating changing project requirements and are presented in Exhibit 4.
• Functional Analysis: - The main concept behind value engineering is functional analysis and is the distinguishing trademark of managing value within a product. This allows changing requirements to be broken into a number of prioritised functions.
• Value: - With value, the balancing of cost versus performance is sought in order to determine what the changing project requirements can contribute to the existing project deliverables. This is a balance between what is in existence and what is changing in order to gauge if the changing project requirements contribute and are of value to the developing product.
Reactive Change Management Model
Combining these two factors (in Exhibit 4) of strategy and value allows for a systematic method of understanding what is involved in the change prior to committing to its undertaking. The shaded areas represent the changes between Exhibit 3 and Exhibit 4)
Summary and Methodology
As the project change is introduced, late in the project cycle, it needs to be aligned with the strategic and functional goals of the organisation. If the change requirements do not align, they should be dismissed as not being of value to the organisation. Such a ‘go’ or ‘no-go’ decision needs to be communicated to the external environment. This study identifies the following appropriate guidelines: -
• If there is a 100% match between the change and the strategy then the change should be accepted and proceed to the next stage of functional and value analysis
• If there is an 80% - 99% match between the change and the strategy then the change should be accepted and a risk identified. This risk should be communicated and controlled with respect to the implementation of the change.
• If there is a 0 – 80% match between the change and the strategy then the change should be rejected, as it does not contribute to the organisational objectives. This decision needs to be fed back to the source of the change (i.e. external environment).
Exhibit 4: Proposed Method to Reacting to Project Change
Byrne, J.A. (1990, Feb. 12th) How Don Sheelen made a mess that Regina couldn't clean up. Business Week, 3145. 46-48.
Haines, S. G. (1998) Leading and mastering strategic change to create and sustain your competitive edge. Center for Strategic Management, San Diego.
Hammer, M. (1990, July – August) Reengineering work: Don't automate, obliterate. Harvard Business Review,68(4) 104-112.
Nolan, R. (1979, March - April) Managing the crises in data processing. Harvard Business Review,57(2) 115-126.
Paulk, M. C., Curtis, B., Chrissis, M. B., Weber, C. V. (1993, July). The capability maturity model, Version 1.1. IEEE Software, 10, (4), 18 – 27.
Perkins, A. (1999) Change management, A strategic, information-center approach. Visible System Corporation.
Scacchi, W. (1995) Understanding software productivity. Advances in Software Engineering and Knowledge Engineering, 2(4), 37-70.
Scott-Morton, M. (1991) The corporation of the 1990's: Information, technology and organisational transformation; Oxford, UK: Oxford University Press.
Sievert, R. (1991, March) A review of the value engineering as an effective system for planning building project. Project Management Journal, 22I(1), 31 – 38,.
Stallworthy, E.A. (2001) The impact of design changes; International Journal of Construction Management and Technology,16 (2), 37 – 47.
The Standish Group Report (2001), Extreme chaos; The Standish Group.
The Standish Group Report (1995), Chaos; The Standish Group.
© 2005, Liam Dillon
Originally published as a part of 2005 PMI Global Congress Proceedings – Edinburgh, Scotland