Dave Gordon at The Practicing IT Project Manager lists a number of factors that define IT project success. Among these is “Organizational change management efforts were sufficient to meet adoption goals.” This is an issue that I am grappling with now on many fronts.
The initial question that comes to mind is which comes first–the need for organizational improvement or the transformation that comes results as a result of the introduction of new technology? “Why does this matter?” one may ask. The answer is that it defines how things are perceived by those that are being affected (or victimized) by the new technology. This will then translate into various behaviors. (Note that I did not say that “Perception is reality.” For the reason why please consult the Devil’s Phraseology.)
This is important because the groundwork laid (or not laid) for the change that is to come will then translate into sub-factors (accepting Dave’s taxonomy of factors for success) that will have a large impact on the project, and whether it is defined as a success. In getting something done the most overriding priority is not just “Gettin’ ‘Er Done.” The manner in which our projects, particularly in IT, are executed and the technology introduced and implemented will determine the success of a number of major factors that contribute to overall project success.
Much has been written lately about “disruptive” change, and that can be a useful analogy when applied to new technologies that transform a market by providing something that is cheaper, better, and faster (with more functionality) than the market norm. I am driving that type of change in my own target markets. But that is in a competitive environment. Judgement–and good judgement–requires that we not inflict this cultural approach on the customer.
The key, I think, is bringing back a concept and approach that seems to have been lost in the shuffle: systems analysis and engineering that works hand-in-hand with the deployment of the technological improvement. There was a reason for asking for the technology in the first place, whether it be improved communications, improved productivity, or qualitative factors. Going in willy-nilly with a new technology that provides unexpected benefits–even if those benefits are both useful and will improve the work process–can often be greeted with fear, sabotage, and obstruction.
When those of us who work with digital systems encounter someone challenged by the new introduction of technology or fear that “robots are taking our jobs,” our reaction is often an eye-roll, treating these individuals as modern Luddites. But that is a dangerous stereotype. Our industry is rife with stories of individuals who fall into this category. Many of them are our most experienced middle managers and specialists who predate the technology being introduced. How long does it take to develop the expertise to fill these positions? What is the cost to the organization if their corporate knowledge and expertise is lost? Given that they have probably experienced multiple reorganizations and technology improvements, their skepticism is probably warranted.
I am not speaking of the exception–the individual who would be opposed to any change. Dave gives a head nod to the CHAOS report, but we also know that we come upon these reactions often enough to be documented from a variety of sources. So how to we handle these?
There are two approaches. One is to rely upon the resources and management of the acquiring organization to properly prepare the organization for the change to come, and to handle the job of determining the expected end state of the processes, and the personnel implications that are anticipated. Another is for the technology provider to offer this service.
From my own direct experience, what I see is a lack of systems analysis expertise that is designed to work hand-in-hand with the technology being introduced. For example, systems analysis is a skill that is all but gone in government agencies and large companies, which rely more and more on outsourcing for IT support. Oftentimes the IT services consultant has its own agenda, which oftentimes conflicts with the goals of both the manager acquiring the technology and the technology provider. Few outsourced IT services contracts anticipate that the consultant must act as an enthusiastic–as opposed to tepid (at best) willing–partner in these efforts. Some agencies lately have tasked the outsourced IT consultant to act as honest broker to choose the technology, mindless of the strategic partnering and informal relationships that will result in a conflict of interest.
Thus, technology providers must be mindful of their target markets and design solutions to meet the typical process improvement requirements of the industry. In order to do this the individuals involved must have a unique set of skills that combines a knowledge of the goals of the market actors, their processes, and how the technology will improve those processes. Given this expertise, technology providers must then prepare the organizational environment to set expectations and to advance the vision of the end state–and to ensure that the customer accepts that end state. It is then up to the customer’s management, once the terms of expectations and end-state have been agreed, to effectively communicate them to those personnel affected, and to do so in a way to eliminate fear and to generate enthusiasm that will ensure that the change is embraced and not resisted.
Life, Project Management, and Everything 
Hi Nick,
You pose an interesting chicken/egg question at the beginning: whether the need for organizational change drove approval of the project, or whether the project needs organizational change to be successful. From my experience, it’s both. I’ve spent the last two decades on enterprise projects, almost entirely in the HR / payroll domain, mostly for global organizations. Generally, by the time the project is actually funded, the need for change is almost universally agreed to; the specifics, not so much. This is why the people leading the initiative tend to get what they want, and many others end up feeling slighted.
Recent example: when the HR business partners used the introduction of the shiny, new manager self-service capabilities to shift some of (what was previously) their work to the managers, reactions varied, based on culture (both corporate and national). In some cases, it was seen as a welcome change, needed to get response time down. In other cases, it was one more straw on an over-loaded camel. I’ve seen it called “package-enabled change,” where the message is that the new system requires we do things this way (usually a bald-faced lie). I’ve also seen it couched as “empowering” the managers (sometimes true), and as a way to cut costs (although no jobs were actually eliminated). In any case, anticipating and managing the response in advance of the actual experience is what’s required.
Good change management is essentially managing expectations, channeling resentment, and heading off rejection. When it is successful, it results in desired behavioral changes and new capabilities being exercised by the right people. When it fails, productivity drops, resentment grows, and ROI drops to zero. And whether the project was on time and on budget is immaterial.
LikeLike