19 signs that your project’s Change Management is in danger!By John Fatkin on
During the negotiations, the business functionality is frequently discussed, prioritised and sometimes, items are set adrift from the project’s scope. The project is nonetheless, launched.
The aspect of Change Management however, is not subject to the same scrutiny. In fact, Change Management can tend to be depicted as a handful of points that appear towards the bottom of the Project Plan, somewhere between the final cycle of ‘Integration Testing’ and ‘Go-Live’.
Further, the focus of the Project Plan can be dominated by the path to complete the project ‘deliverables’ which entails the provision of a tested software solution that has had sign-off by a senior manager of the business.
It is at Go-live however, that the result of the Project Team’s effort is presented to the business requiring not only their acceptance, but their readiness, understanding and willingness to use the new solution day-in, and day-out into the months and years ahead.
This is the major handover point of the project.
The effectiveness of the project’s Change Management work is suddenly revealed within the first few days of Go-live.
Successes might pass unnoticed because people know what to do, and they just get on with it. Failures are not so kind - processes can unravel, oversights emerge, an air of disbelief and confusion can pervade through the organisation.
Change Management is not well understood. The business know their own physical processes but not the details of how the new solution will change their jobs – the Project Team know the ERP processes, the data structures, the configuration, but not how individuals will need to apply the solution in their particular office or plant.
We’re about to find out 19 signs that show when your project’s Change Management is in danger !
Leaving it too late
The battle can seem to be lost before it has started. The Project Team and business sponsors need to identify those impacts of Change Management that require long-range preparation and include items into the Project Plan to assure time and responsibility to cover them. Such tasks could involve changing the shape or operation of the enterprise. If new roles are to be introduced, it could require cost/benefit analysis, ratification by senior management and board approval. Then there’s job descriptions, candidate selection, the recruitment process and knowledge ramp up of new individuals in the basic physical processes and products of the enterprise.
But there’s more. To avoid ‘leaving it too late’, infers that the Project Team is aware of what needs to be done in Change Management. They need to know the sequence of planning corporate strategic tasks, site-based strategic tasks, 3rd party impacts, operational planning and responsibilities, job assessments, role allocations to individuals, training needs assessment, training material development and delivery, communication management, Go-live preparation and sustainment management etc.
All these tasks should appear in a Change Management Strategy document that is signed off by the Project Team and business sponsors no later than Blueprint Sign-off.
‘Change Management’ is the same as ‘User Training’
This is probably the largest misnomer to thwart Change Management programs. We need to remember that a large ERP project presents a large cultural change to an organisation, let alone the new whiz-bangery that needs to be tested, taught and maintained.
The cultural change needs to be analysed, planned, and carefully executed. Parochial and political attitudes need to be identified and resolved. The organisation is made up of individuals with different skillsets, strengths, experiences and preferences and any expectation to underplay the importance of these details can jeopardise the adoption of the new solution.
This misconception of Change Management can also be manifest in the content of the Change Management Strategy document. If the document is largely a User Training Plan then it’s likely that the thinking has been underdone. What about user competency ? the ‘AS-IS’ >> ‘TO-BE’ journey that reveals what will change, where it will change and who is most exposed to make the change successfully ?
Clearly, Change Management steps must start months before Go-live and doesn’t finish until some monthly cycles have completed successfully in the Post Go-live period.
A lack of understanding about the depth of Change Management leads to many risks – inadequate representation of tasks on the Project Plan, poor selection of candidates for roles, insufficient time allocated for the business to prepare themselves for the forthcoming changes etc.
Who’s responsible ?
Who are the Process Owners ? There is a difficulty is getting names of people to take responsibility for not only approval of the design, but the ongoing management of the final solution. This could be due to the nature of an integrated ERP design that cuts across functional boundaries and so no single manager feels comfortable with the responsibility of the overall process. It could be that senior managers don’t understand the new processes and that they are mentally occupied on other projects. The business people who have been involved in the topic workshops however, don’t hold positions of sufficient authority to deploy actions in the post Go-live operation. Capping it off, there’s a lack of recognition that this is actually a business project.
Further, the allocation and positive acknowledgement from individuals for all other Change Management responsibilities must be obtained as soon as possible. Any cloudiness on responsibilities is likely to lead to a flat-footedness when delivery of tasks is required.
How hard can it be ?
The view from the outside the Project Team can seem simple, but clearly, the devil’s in the detail.
Regarding processes, until the topics are work-shopped, many challenges and constraints remain hidden. Even when some topics are eventually ‘nutted out’, further complications arise when the dependencies of the integrated environment are considered ~ who would have thought that one field on the Purchase Order form is vital for the success of a supplier’s processes.
Regarding internal business units, even those that are not central to the project, can still be affected by low level detail ~ even if they receive one report per month, the information might now need to be sourced from another place.
Regarding people, the simple allocation of names to training sessions won’t cut it. The ‘fit’ of people to new or modified roles must be assessed on an individual basis. Some people will make it and some people won’t. The sooner the result of this analysis is known, the quicker the project can get on with preparing the right people for the right roles.
The scrutiny on process and user competency is further affected by the choice of implementation strategy ~ a ‘Big-Bang’ implementation demands the highest attention-to-detail on project tasks as there is no full rehearsal before Go-live.
What’s in the Project Plan ?
A template document is often used as the backbone of the Project Plan. The template provides ostensibly a method to construct a sound software solution with touchpoints from the business to confirm requirements, review proof-of-concept presentations and to be involved in sanity checks during testing. Strangely, the template can be light on topics relating to Change Management.
Why does this happen ? often it seems that Change Management carries many unknowns that are dependent on how the design turns out. It’s true that the Change Management details are dependent on outcomes from many areas, but unless there is an informed inclusion of the indicative Change Management tasks, timings and responsibilities in the Project Plan, the needs of Change Management are likely to be overlooked.
It is far better for the Project to have an estimate of Change Management effort from the outset of the project that will be progressively reviewed, than to provide little information at the start of the project and later, when Change Management tasks have become glaringly obvious, to be forced to work with whatever time and resources are available.
Early warning signs can occur to indicate if late inclusions of Change Management tasks are needed. For example, if functional streams are getting behind the schedule of the training and development effort, it can be anticipated that rework on training material will be increased.
In addition to the project tasks, there must be a contingency for the unforeseeable events - not a contingency for the foreseeable events that were not scrutinised sufficiently.
We don’t need site co-ordinators !
In the weeks approaching Go-live, there is an increased need to ask and resolve questions between the Project Team and sites; these are questions relating to detailed design, data, authorisations etc. Unfortunately, the questions are not liberally distributed to available people, rather, they need to be addressed by a small number of key individuals. Further, the key individuals typically hold business critical roles at sites and cannot afford time for indiscriminate sojourns on numerous topics. There is also a need to rally the people at sites to complete their required preparation tasks for Go-live. It is for these reasons, that the role of a temporary Site Co-ordinator must be installed as a key Change Management figure for the period leading up to, and shortly after, Go-live. The Site Co-ordinator will work onsite and organise the flow of information and ensure that tasks are being completed. They will also be sensitive to any local issues and although not needing to be an IT guru, will have authority to resolve general management issues.
The emu might fly
Sometimes, individuals are named for tasks within Change Management without an honest assessment of the likelihood of success. Names are simply assigned to tasks because the person is ‘available’ without considering the individual’s aptitude and circumstances to achieve success. Alternatively, an overly optimistic ( or careless) manager describes the task as a ’growth opportunity’ for the individual but without providing adequate support to make the decision work. Clearly, the sooner these situations are resolved, the better for all concerned.
You can do that in your spare time !
Every site seems to have the ‘go-to’ person on many topics. These individuals get snapped up as a subject matter expert for design purposes. They are also sought after for user acceptance testing as they know what will and won’t work at the site. Their level of knowledge starts growing further in the new design and the training team spot the person as a credible trainer for the site. In addition, they already have their day job too. This snow-balling effect occurs on the individual and unless effort is placed diligently on managing resource loading (a view of the Project Plan), the inevitable delays will start to occur as the person is overcommitted. It will result in missing project deadlines or worse still, burn-out of the individual.
Has the Change Management Strategy been signed off yet ?
Not a good sign. It might not get much attention at first, but the inability for the Change Management Strategy to be written and signed off by the key project sponsors is indicative that Change Management has not been resolved and is at risk of different expectations prevailing in the minds of the Project Team to that of the business.
A point of misalignment is likely to be exposed midway through the project that could involve prickly discussions, compromises, scope change, inadequate resourcing alternatives and suboptimal actions to be drafted hastily.
Adjustments on the feedback loop
Training material development needs to be kicked off (according to the Project Plan) when the design is determined, but the outcomes of integration testing and some detailed design decisions can come thick and fast in the final weeks before go-live. The user documentation including e-learning tools, need to be refined according to the test and design feedback, despite how many documents are affected or how many manuals have been produced. The larger the slippage in design completion and process testing, the greater exposure for training material to need revision.
Further complications affecting documentation can occur when late decisions are made to jettison functionality and revert to workarounds to meet project budget and deadlines.
The functional expert is too busy
Typically the project team members responsible for design are fully occupied on configuration, developments and the curly aspects of detailed design. Their involvement to ensure that Change Management tasks are accurate or even just kept relevant at all, is crucial to ensure that the solution is represented correctly in Change Management activities.
Changes in the team line up
It can be expected that some staff turnover could occur during a project implementation. This can have a visible effect on Change Management and must be handled well.
The development and delivery of training material needs to be consistent and pitched appropriately for the audience ~ the level of technical detail and language needs to be carefully determined and maintained. A new writer on the team needs to be attuned to the style of communication and endeavour to continue it. Continuity in all Change Management activities is important and gives signals to the audience of the decisiveness and confidence of the project leadership.
Also, just as the functional design needs an overall solution architect, the Change Management strategy and deployment needs a single management oversight to ensure coverage of Change Management tasks and to help manage changes to the team line up when they might occur.
Lack of discipline in management
Change Management suffers from it’s own mismanagement and the mismanagement of the project as a whole.
Scope Changes : As soon as changes to scope occur by way of added (or removed) functionality, there is a mandate to check and adjust Change Management activities (role definitions, process approvals, training materials, course agendas, allocation of training activities to individuals etc.) . It is important that there is adequate management rigour placed over scope changes to ensure that their approval, communication and corrective actions are managed tightly.
Slippage on project task completion : Slippage in the completion of many tasks on the Project Plan could impact the stream of Change Management that dominates the latter stages of the Project life cycle. Design adjustments that occur after Change Management activities have started must be identified overtly and assessed for impacts to Change Management. Usually Change management tasks are ramping up as other areas are tapering off.
The trainer’s a rookie !
The role of a trainer carries much influence. For many people in the business, the trainer might be the first face that they see representing the project team. First impressions count. At a training session, knowledge of the new processes and business requirements and the attitudes of the trainer, will be evident to the audience and they will make assessments of the project based on this encounter.
The selection of trainers cannot be an afterthought.
Whilst freshness is a good attribute, any externally-sourced trainer must get street credibility by being afforded the time to learn the products and physical processes of the enterprise. Shortcomings in this area will be quickly identified and reflect badly on the project. Trainers should also have experience in holding people’s attention through long training days as is typically required in the window of opportunity made available for user training.
The best model has trainer involvement in project design stages, process testing and training material development. This enables the trainer to ‘walk the talk’ and transfer knowledge to the audience effectively.
Managers don't need to be trained !
There can be a reluctance of managers to get their hands dirty with the new system. It can come through a lack of confidence with technology, not having time to dedicate to the project, fear of change etc.. Some managers feel comfortable with the knowledge and skills of the new solution resting with one or more of their team members. ERP systems however, are pervasive. A lack of direct involvement from the manager will eventually diminish their effectiveness. Even a cursory understanding of the new solution through attendance at training sessions, will allow a manager to better manage their own team, let alone allow them to use reporting tools and understand better the information that they view.
Our trainees haven't been employed yet
Resource management in a large ERP project is not easy. The business will probably not have many people with surplus time to devote to the project. It is quite possible that temporary (or permanent) resources could be needed to fulfill roles to allow Go-live to occur successfully. If the planning and deployment of steps to accomplish this task are not completed well in advance, the Change Management activities could be delayed or compromised.
No time to think
The Project Plan might present the Change Management activities as a tight sequence of tasks to be performed in a carefully scheduled period of time. It might imply that key people run headlong from one workshop to the next and sit through consecutive days of long training sessions.
People need time to digest new concepts. People also need time to ‘unlearn’ their former job routine. People need time to practice in the sandbox environment and see something of the bigger picture that justifies the new solution, otherwise, when an unexpected event happens in the workplace or a new error is encountered, they might not have the sensitivity to know the significance of the impact.
The implementation strategy also has a bearing on how much understanding of the new solution must crystallise in the new user’s mind BEFORE the Go-live date. Clearly, a Big-bang implementation requires, that the user is confident and knows the what, how and the why of the new solution BEFORE Go-live.
The pilot site was shaky
Change Management will be affected by the results of the first site. Word of mouth will travel quicker than any formal announcements that are distributed from the Project Office. People from other sites will want to know the outcome of the pilot site as it will be seen to have a bearing on their forthcoming events. What was the experience ? were they ready ? does the system work ? what is the relative change compared to the old system ? is the project a success ?
The Project leadership must anticipate the communication requirements and be quick to provide positive messages, despite the actual outcome of the pilot site. The absence of communication can allow any negative messages to propagate informally through the organisation, despite their actual veracity.
Didn't I tell you - I'm on holidays next week !
Simple, simple, simple and yet often poorly managed.
Every team member is due their holidays and especially over the long haul of an extended implementation. The provision for Annual Leave must, and can, be managed well. The Project Plan, especially the Resource Loading view, must accommodate when team members are available and due planning must be managed to process leave requests.
Projects that have difficulty in grappling with the execution of project tasks, will also struggle with managing holidays as they lack confidence to assure people of specific dates when their absence can be accommodated. The tighter the management style , the more comfortable the leadership team will be with team member leave periods.
Also, the specific work arrangements of some people (e.g. part time work to allow kids to be picked up from school) should be recognised in Project Plan activities.