OSS implementations / transformations are always challenging. Stakeholders seem to easily get their heads around the fact that there will be technical challenges (even if they / we can’t always get their head around the actual changes initially).
When a vendor / integrator is charged with doing an OSS implementation, the client (perhaps rightly) expects the vendor / SI to lead the technical implementation and guide the client through any challenges. It’s the, “Over to you!” client mentality at times.
However, it’s the change management challenges that are often overlooked and/or underestimated (by client and vendor / integrator alike). It’s far less realistic for a client to delegate these activities and challenges to the vendor / SI. The vendor / SI simply doesn’t have the reach or influence within the client’s organisation (unless they’re long-term trusted partners). Just doing a 2 week training course at the end of the implementation rarely works.
Now, if you do represent the client, change management starts all the way back at the start of the project – from the time we start to gather current and desired future state, including process and persona mappings.
At that time we can put ourselves in the shoes of each person impacted by OSS change and consider, “If your current normal is exactly what you need, then different isn’t worth exploring” (a Seth Godin quote).
How many times have you heard about operators bypassing their sophisticated new OSS and reverting back to their old spreadsheets (thus keeping an offline store of data that would be valuable to be stored in the OSS)?
Interestingly though, if you approach those same people before the OSS implementation and ask them whether their as-is spreadsheet model gives them exactly what they need, you will undoubtedly get some great insights (either yes it is and here’s why or no it’s not because…).
You have a stronger position of influence with these operators if you involve and listen pre-implementation than enforcing change afterwards.
To again quote Seth, they’re not always, “hesitant about this new idea because it’s a risky, problematic, defective idea… [but] because it’s simply different than [they’re] used to.”