Elaborating on business vs technology driven change
This topic has generated an interesting discussion in the LinkedIn Change Consulting Group. Generally speaking, most people favor a business driven change over technology driven. I would agree, 80% of the time. My experience is that the business needs to prioritize the change. From the strategic blueprint for change the portfolio of activities (process, technology, structure, culture, etc.) can be defined, prioritized and delivered. The blueprint for change is critical to enable the business driven change. It serves as the target, objectives, or set of goals that transformation initiatives are aligned against to achieve. When these goals and initiatives contain metrics they are even more powerful and compelling.
Even with the benefit of the blueprint to align the change initiatives, resistance to change will occur. As the initiatives are launched and begin delivering, resistance to the change could and most likely will increase for many reasons (culture, organization, political, skills, etc.). When this happens, I have witnessed business driven changes stall eventhough technology delivery commitments have been made. It is in these cases, that a technology driven approach can be applied. The needs of the business could be met by the technology, but resistance to change has increased and is jeopardizing the change progress. In these situations, leveraging the available technology and driving through the resistance by combining the business and technical drivers helps to burst through the atmosphere of resistance. “We agreed we have a business imperitive to implement ‘x’. We have delivered the capability to implement ‘x’, and now we are not doing it?” By meeting delivery commitments on the technology, change teams position themselves to drive the change by making the technology available. Questions like “why would we not deploy the results of the project team’s efforts of 10+ people over 3, 6, 9 months?” become difficult to answer and can positively impact resistance. In these cases, I can see a reason to apply a more technology driven aproach.
In this discussion, I have purposefully ignored the softer domains of transformation (e.g. culture, skills, structure, etc.) to isolate and describe how business and technology can be combined to drive change. Several other techniques exist and should be used to make change happen (e.g. deployment plans, organizational readiness plans, migration plans, etc.). Hopefully, by comparing and contrasting busines vs technolgy driven approaches, we have shed some interesting light on critical moments in the lifecycle of a transformation program.