A few weeks back I was speaking with a colleague who expressed challenges with some applications she had. Her frustration was that this legacy application was not scalable, and it was this way because of change management. I admit at first when I heard legacy app and issues my mind was drifting a bit. But when they said it was the fault of the Change Manager my ears perked up a bit.
“I’ll bite, what did the Change Manager do? I asked, even if I was a bit skeptical.
The background was this…
It turns out that the original component of the application was built in house to allow the warehouse manager to report on performance metrics and then take that data to schedule the next weeks forecasted staffing requirements. Sounds simple enough, right? As things tend to do there was a requirements change as the organization grew. The Warehouse Manager (WM) no longer was going to shoulder the responsibilities of metrics and scheduling. It was put onto 2 leads, one for each. We’ll call them Metrics Lead (ML) and Schedule Lead (SL). After the two were shown what to do they were off until….
The Warehouse bought a nice new off the shelf inventory tool. The salesman, who worked the room like a Kennedy, sold them on the idea that without cost they could have a tie in for the Scheduling and later maybe something for Metrics. Things were working fairly smoothly at first. There were a few hiccups but for the most part the scheduling was well driven from the output inventory app provided. After several months ML approached SL to see about tying in all 3. They contacted the vendor and an integration point was established. There was only one challenge; they required a manual intervention for information to be dumped from the Scheduling files to the Metrics files each day. An automated solution could be created but the professional services associated with this was determined “not worth it” from the business perspective. Without this file dump the piece count for each warehouse employee would not be accurate. It also included a file for cases which were returned to the warehouse in error
There was a downturn in the economy and WM had to let go of middle management (SL and ML) while he didn’t want to lose them, he was assured that the suite of applications would help him to cover the function (he once did by himself) quite well. There was nothing physically documented about how the applications worked together, and in his “brain dump” was explained that these files should be moved each day.
The application was still pretty solid for a few more months. It was at this point that the VP of the company decided to have a “pay by performance” initiative. This was not formally discussed with any IT stakeholders.
“We have a tool that tells us how many cases each staff selects a day, and we can incent them on their performance” There was quite the buzz on this.
The company was quite large now and the application was starting to have some challenges with the file capacity during the transfer during the day. A change was created to automate the file transfers to the inventory application at night. There was only one challenge. The returns file could not be automated due to other process constraints
…see, it’s the Change Managers fault…she said. I was a bit puzzled. “It was because of them that the process had to change and then the pay for performance wasn’t accurate, the warehouse workers were not getting paid properly. “
I could see where she of any of the stakeholders in her company would get that. To me It looked like there was a gap in the review of this change. What was missed for sure was:
· The lack of knowledge captured about the application and how it works (and integrates with other components) – Knowledge Management is important
· That the business drove this decision, risks should have been discussed and had sign off before proceeding. Did they know what they were approving?
· A risk mitigation plan should have been included outlining what to do should issues arise.
· An understanding that this process at its core was a workaround.
The company had to terminate the pay for performance program. Despite its potential, the organization was not in a position to leverage its data to accurately pay staff on the information captured
What was learned?
· There was not a project to implement this Pay for Performance. Simply the change. many important requirements were missed
· Had the architecture, process and limitations of the tool be documented they may have been in a better position to discuss what the tool was actually capable of
· That while this change did not go as planned, it does not fall solely on the change manager, and there were several stakeholders who were not aware of the challenges associated with this tool and allowed this to proceed.
· That this shortcoming should be documented, did I mention Knowledge Management
· That a workaround, like a bandage can sting if it gets ripped off before its time
Follow us on Twitter @ryanrogilvie