In Spite of ... Change

 

Have you ever seen or perhaps sent the following email?

 

 “Congrats on the implementation of the New Cool System or NCS that the IT team and select business users have [implemented;delivered;built].  The Old Decrepit System or ODS has been shut off and the majority of your data has been transferred.  Please contact the Help Desk if you experience any issues.  The NCS will allow us to better: [increase shareholder value; realize operational efficiencies; increase top-line sales].  Training will be scheduled soon.

 

Thanks,

The Management”

 

Technology change reflects a significant portion of the change employees experience.  Unfortunately poorly managed technological change has resulted in a cynical attitude by the end users.  The above letter will often result in open revolt or a grassroots movement attempts to identify various ways to work-around the new system.  In Spite of Change, the organization continues to function; albeit hobbled by the NCS.  The prevailing feeling “In spite of the NCS, we are able to deliver our product or service” when the feeling should be “Because of the NCS, we are better able to deliver our product or service”.

 

How can a change agent effectively ensure a proper technology innovation? 

 

Recognizing the guardrails of OD in IT are vital.  First, I posit that the majority Software Development Life Cycles (SDLC) models that exist today are effective at creating a realistic solution.  The effectiveness of each methodology is outside the scope of this article.  Secondly, the solution delivered will result in a change to an organization or subset of the organization in a significant way.  A “significant” change being defined as a change that results in the altering of current or expected behavior to accomplish a process or series of processes. Additionally, the team will create a business process document outlining the as-is versus the to-be process.  Most software requires input from a specific subset of the affected team.  This subset of business users is expected to sufficiently represent the business needs to influence the solution.    Finally, the organization is sufficient in size so that the technology development team is external to the affected organizational subset. 

It is within these guardrails that the change agent must act.  Change management is often defined as “Training” within the project plan, usually towards the end of a project.  Sometimes this occurs after the project is completed.  Effective technology change management means ensuring the user is meaningfully engaged throughout the entire SDLC.  Adoption velocity is an important measure of the success of an implementation.  The quantity of individuals who are effectively using the new tool will help leadership understand, reactively, how effective the change is be embracing.

The following table outline the primary phases that occur throughout a project;  SCRUM will occur iteratively and Waterfall will be sequentially. 

Project Phase	When OD / Change Management is “Training”	End User’s Perspective
Pre-Scoping
Analysis
Design
Construction
Test & Validation	Training – ready set go.	“Another change? How will the new system affect me?  I don’t remember being asked for my input.”
Implementation	Keep Training	“It has been released?”
Post Implementation	Even More Training	“Why am I learning about this the hard way? Grrrrrrrrrr.”

 

The process in the table above will not result in the most effective adoption of the new system.

 

 

The optimal OD & Change Management process in IT projects is below.

 

Project Phase	Effective OD in IT steps	End User’s Perspective
Pre-Scoping	Identify affected user groups.
Analysis	Create ownership within affected user groups. Ensure visible leadership support.	“I’m engaged to help define the optimal solution.”
Design	Engage affected user groups to communicate changes and value. Ensure visible leadership support.	“I realize there are other stake holders who have inputs.  I need to be flexible.”
Construction	Create transition plan. Identify barriers to transition. Ensure visible leadership support.	“Knowing the changes and how I can embrace them allows me to plan appropriately.”
Test & Validation	Engage the user groups to ensure transparency and validation of transition plan. Intervene as necessary. Ensure visible leadership support.	“My feedback is valued since I will be working directly with the new system.  The transition plan ensures efficient steps towards the new state.”
Implementation	Monitor change after implementation. Ensure positive change is encouraged and negative change or backsliding is discouraged.	“I expected and planned for this change since I knew what to expect.  Here we go!”
Post Implementation	Follow up on change.  Incorporate recommendations in future changes.	“Here is what works, here is what didn’t.”

 

 

The second process will increase adoption velocity, adoption coverage and build trust between the technology and business teams.

The reality is that most organizations cannot immediately adopt the a stringent OD approach.  If the teams are willing to engage this change management process over time until the full process is utilized then the incremental success will be readily recognized.

 

Help move the organization perspective from “In spite of change we are generating revenue” to “Because of change we are better able to generate revenue”.