Following on from her popular series, “Extending PLM”, this week sees business process expert Kilara Le examining the human side of PLM implementation – managing people’s intrinsic resistance to change, and learning how best to mitigate the impact of enterprise-level projects.
As human beings, we’re accustomed to making small or incremental changes every minute of every day, but larger ones that impact on our daily routines – such as the implementation of a new PLM or business system – can prove an impassable barrier, impossible to get our heads around due to their sheer magnitude.
To add to that intrinsic fear of big change, many of us have personally been involved with or heard horror stories about companies who have had disastrous, sometimes failed, implementations of systems of this magnitude. After all, any change that affects a business in its entirety (as PLM must) will be felt not just by those leading the implementation, but also by everybody who works alongside them, no matter what their role may be in the product lifecycle.
It almost goes without saying that detailed preparation is absolutely vital to minimising the impact of change across all levels of the organisation where these large-scale projects are concerned. The implementation itself will disrupt existing processes even before it begins to transform them, and stress will be felt far beyond the executive level, cascading down to those for whom PLM may not necessarily feel like a business imperative.
That preparation will also take in more and more varied aspects of the business than we might initially think: everything from IT infrastructure to individual personalities need to be considered and catered for if the organisation as a whole is to have any hope of successfully managing a tectonic change.
This may sound like doom-mongering, but we should remember there are also a host of extremely successful implementation stories to counterbalance these worrying tales of mismanaged change and failed installations. The unfortunate fact is that these successes tend not to be talked about as much as failures, as they seem to blend into the background noise of work life with minimal disruption – becoming part of the furniture despite the considerable work it almost certainly took to get them to run so smoothly. But unless you are filming a dramatic reality TV show (one with an already less-than-exciting premise in software implementation, I’ll admit) you will certainly want to make sure your next implementation succeeds.
So, with so little attention dedicated to these successes, how should you go about managing change in such a way that your project ends up a quiet success rather than a prominent failure?
The catalyst for change is always motivation – the desire to get from “what is” to what will be, driven by a knowledge that the future destination is better than the current status quo.
For an executive, with unfettered access to the bottom line, and a real understanding of what makes the business tick at the highest level, it can be difficult to realise that the actual purpose of changing – the value of moving from where you are to where you want to be – may not be clear to those end users who will live the incremental steps day in and day out.
And the importance of documenting change goes beyond transparency. I’ve found in many implementations, even those where companies had a very good idea of what the steps were in their product development, there were still further processes or exceptions that simply were not documented in either their prior or post-change states, making it incredibly difficult to define or quantify the value of change at any stage.
More specifically, it’s only by documenting and understanding every process that an organisation can understand whether these processes need to change in the first place, and how they will fit into the overall vision for the future.
The optimum way to conduct this kind of detailed process audit is to consult with those who are actually responsible for the given processes at the earliest possible stage. When key stakeholders are involved from the beginning, they have more time to get accustomed to the idea of change, as well more opportunities to voice their concerns and suggestions before the change process begins, rather than afterwards. We mustn’t forget, of course, that in order for any implementation to be successful, the change it brings must be beneficial to individuals as well as to the company as a whole.
At this point in prior implementations (with change fully documented and described) I’ve undertaken a preliminary mapping, looking at which of these business processes can be potentially streamlined by the solutions available in the marketplace at the time. Weighing these specific needs against the core capabilities of a typical solution then helps to identify those points that are important to include in a request for proposals (RFP) document, which will now essentially serve as a personalised map of the change proposed to your business – described, circumscribed, and understood.
And once you have a map that shows your destination (with a legend everybody can understand), it will be considerably easier to get there.
After consulting with the entire business, you’ll no doubt find that you have more change on your hands than you can possibly manage, and the time will come to begin formal discussions on which processes deserve priority, how substantially things will change, and how quickly.
Business leaders, IT and user stakeholders should all be a part of these discussions, and their input should be used to define the scope of change, and to map that against required software functionality.
It’s important to approach these discussions with caution, however, as stakeholders who are now invested in change may suddenly find themselves eager to change everything. In reality it’s neither practical nor necessary to give everyone everything he or she desires. Several infamous implementations have dragged on for years (and to the tune of millions in their local currency) because of their desire to do everything, for everybody, all at once.
A big dose of pragmatism is called for at this stage – and a concrete list of “must change” processes versus “nice to change” equivalents should be established as soon as possible, otherwise the sheer scope of change may become too cumbersome to manage effectively, despite the best intentions.
Selecting a core, cross-functional group of these interested parties is the best way to keep a project focused, since designated champions can represent the interests of their teams without necessarily being beholden to their every whim, as well as developing a valuable understanding of the processes that matter outside their own area of expertise.
[quote]Unsurprisingly, people tend to get stressed, angry and deploy office-inappropriate language when they can’t get their existing work done.[/quote]
For example, I was recently involved in a process-mapping project where an IT team leader was asked to sit in on the discussion to provide his own perspective. Whilst this gentleman was an expert in the IT world, he, like many others in comparably large companies, wasn’t exposed to the everyday activities of product development.
After a week of participating in interviews and discussions with the product development team, he came to realise that Excel was the most widely used tool in the company, despite ongoing discussions within his own realm that were leading the company towards replacing Excel entirely with Google spreadsheets. We all, he included, had a good chuckle at the upheaval that decision would have caused – all due to a simple misunderstanding of the kind that originate routinely when people get stuck in a “silo” mentality.
This cross-domain expertise and mutual understanding then truly comes to bear, as the project team have the unenviable task of using their new process understanding and priority list to shortlist and select a PLM solution. With more than fifty catering to our industry alone, this is a contentious topic, and one on which volumes have been written elsewhere on WhichPLM. It’s a topic I don’t intend to cover here, except to say that once this coven of internal stakeholders has chosen the right vendor and nailed down the scope of the change they find themselves managing, the real “fun” can begin.
Thinking ahead, in our terms, means defining an implementation plan since, as we’ve seen, you can’t change everything at once.
A good implementation plan should encompass multiple phases: the first based on immediate needs (the “low-hanging fruit” identified in your process discussions), the second on near-future requirements, and the third (and possibly fourth, fifth, sixth and beyond) on the long-term strategic vision that galvanised the entire change process to begin with.
This is a tall order, to be sure, and is the most likely stage for your internal project team to begin questioning whether they have bitten off more than they can chew. Like it or not, they will now be the “go to” group for questions, for final decisions on configuration, for training requests, and for user support.
In short, your internal project team are going to be busy!
One of the most vital change management responsibilities (and one that, much to their chagrin, will be delegated to the project team) is ensuring adherence to the immediate phases of the implementation plan, all the while building in logical supports for the phases that will follow.
Finding a suitable system administrator to act as a single point of contact for user queries can help to funnel the workload as the implementation moves forward, but the project team itself must remain active in the decision-making process where implementation phases and scope are concerned. While it’s clearly important to define a scope early on – and stick to it – to avoid “scope creep” and “budget blowout”, the project team must retain some degree of flexibility. As software capabilities become better known, and the true impacts of changing processes become more apparent, it may be that additional process transformations belong in a particular stage, or that others can be postponed until later.
After all, another important part of managing change lies in knowing when to stop changing things.
[quote]…how should you go about managing change in such a way that your project ends up a quiet success rather than a prominent failure?[/quote]
Minimising the disruption of change also has a technological as well as a personal aspect, and adequate preparation also means working with the chosen vendor to configure the software correctly, and making sure internal IT infrastructure can support it.
Much as you wouldn’t put a team of your best drivers in a fleet of untested cars, the next important step is the ensure that the configured software is installed in a test environment, where the impact of bugs and fix requested will not be felt on your live production environment. Although PLM in particular is a proven technology, even its best solutions can encounter unexpected hiccups, and no business is in a hurry to halt production because an unforeseeable error took the system offline for a day.
In another implementation example, I know of an IT systems administrator who chose to take his vacation the week the new solution was to go live. Needless to say, he scored no points with the business systems administrator, who was plagued by user requests and bug reports, despite having no access to actually make fixes. Unsurprisingly, people tend to get stressed, angry and deploy office-inappropriate language when they can’t get their existing work done, let alone seamlessly change over to new ways of working..
Remember, this is what change management aims to avoid. Disruption needn’t be inevitable, and stress headaches and product delays don’t necessarily have to follow as a consequence of an implementation.
Changes in daily tasks will be the most significant concern for the vast majority of your end users. They learned to do their jobs, the reasoning goes, so where’s their incentive to learn to do them all over again? More importantly, how are they to learn the ropes of a new system without support?
As you might imagine, training is absolutely vital for any successful implementation. In the days (and perhaps weeks) before the “go live” date, users should be trained in the specific areas of the new system that will directly impact their day-to-day work, and shown how other parts of their role will change.
At this point, the system should be thoroughly tested by the project team or pilot users before letting those general users loose. Any bugs should have been fixed and/or reported to the software provider – who is (hopefully) working to get them fixed as a matter of urgency. There would be little point in sitting an end user down with a list of things not to touch yet, or with promises of added functionality in the near future.
And although these users are trained on the test server (keeping the inevitable mistakes away from the production environment) they should approach the training exercise as they would any other day in their jobs – adhering to the same standards as they would in a live environment, and putting the system through its paces in the way they will once it goes live.
As a cautionary tale, I once worked on a implementation where a group of ladies were training on what they thought was a sandboxed environment, only to find that the profanity they’d filled the comments section with was being entered into a live environment, and stored in perpetuity under their usernames.
Sometimes these wind up being called “legacy” systems for slightly unexpected reasons!
Whatever form it takes, this training should emphasise above all else that the change being brought about by the new system will make lives easier, rather than the opposite. And by all means allow the user to try and break your system; better now than in several weeks’ time when everything has gone live.
Throughout any phase of any project, there are things that could be done better or that you might do differently in the phases that follow. Change is by its very nature unpredictable, and so even the best-prepared amongst us can benefit from recording their experiences to learn from, and to help mitigate the impact of comparable change in the future.
Communicating with colleagues and managers, and reaching out to peers who have “been there; done that” is a great way to glean knowledge and anticipate ways to manage similar or even wildly different changes that might come your way in the future. Even though large-scale change can be scary, it’s also often the only way to advance – so I wish you the best of luck in managing it gracefully.
I’ll leave you with one of my favourite quotes, by Zen master Thich Nhat Hanh:
“Because of change, everything is possible.”