Doug Reynolds, CIO, SMB Executive
Who of us hasn't fallen for the promise of a "bright, shiny object" that didn't meet expectations? Remember that product we bought, or the solution we built, that was going to solve a big problem. Not the type of product that just replaced the old laptops with the new or the old spreadsheet with the new. It was the type of solution that was going to provide new capabilities and make work life better. And then it happened.
Maybe it's more accurate to say "it didn't happen". It went live, but why didn't we get real business results? What went wrong? As people who work with technology, we have learned how to run quality projects and have shaped our approaches over time leveraging things like Agile and DevOps and more. So why didn't our solution make life in the business better? We understood the functional requirements, we executed a well-run project, we had a quality development process, we even ran all the users through training. But why didn't anything really change?
You know where this is going, don't you? There is this saying that each of us knows and has used at some point: "a good solution must address People, Process and Technology". Unfortunately, when it comes down to it, we find people and process to be the hardest part; usually because we don't have the competencies, the budget or the perceived time to address them. Additionally, the effort and activities involved in changing process and dealing with people come off as "soft and fuzzy"; far less tangible than developing and implementing technology into production.
1.Acknowledge the problem: real results will not be achieved by simply enablingnew process and new behaviors with technology; providing the solution is the easiest part but may represent money down the drain if people and process are not successfully addressed.
2.Define success, not by "going live", but by the desired business results; then identify the changes that must take place to achieve those results. The solution should be expected to enable those changes, but what process changes and changes to people's behavior must also take place?
3.Acknowledge that changing process is not complete by defining a new process on paper or even implementing process steps into a system. Every process step where a person is involved in the current or future versions of the process must be identified and all that "change must be managed".
4.Make the people and process change a tangible part of the project; get rid of the soft and fuzzy. Ensure that Process Change and People/Behavior Change each have their own tracks or workstreams in your project plans and are owned.
5.Establish some competence and a methodology for operational change management. One that leads people to be "willing" to change, one that helps them be "able" to change, and one that ensures change is "sustained" well after a solution is implemented.
Sound hard? Maybe it is. But every study I've ever seen, and my own experience, shows that the majority of technology projects fail to achieve desired results; even when a solution is delivered on-time and on-budget. So, if given the choice, I would choose "hard" over "failure"; I bet your business would too. If we want to bring about real change, we must get as good at managing change to our people and process as we are at delivering technology.