Hacking Change Management: Part 3
Article Summary:
-
Failed Transformation Red Flag #1: Project team does not embed the OCM team with the delivery team
-
Failed Transformation Red Flag #2: Project team fails to create an end-to-end view of the value stream
-
Physical visualizations create transparency on the timing and impact of OCM activities, allowing non-OCM team members to easily provide inputs
[If you already read Hacking OCM Part 1 or Part 2, you can skip to the Common Problem]
What is your reaction when you hear about a hack? Maybe “hacker” elicits thoughts of a sinister group of computer experts in a fortified basement committing acts of espionage and cyberwarfare. Hacking is frequently associated with illegally gaining access to critical personal, organizational, or government information. Oh yes, and of course, dark hoodies. It’s obviously very cold in the basement.
It is not surprising that the term “hacker” often creates a feeling of apprehension. After all, we’ve recently seen some nefarious hacking hit quite close to home. Personal information of nearly 44% of the U.S. population was illegally obtained in May to July of 2017 when criminal hackers infiltrated the servers of Equifax, a consumer credit reporting agency1. The hackers gained access to data that enabled them to conduct identify theft on 145.5 million Americans.
Not all hackers, however, aim to steal data or create chaos. Many hackers leverage a hacking methodology to solve healthcare problems or cure diseases (biohacking), and improve environmental quality or rapidly innovate, test, and deploy new technology. These helpful hackers have also been called “hactivists.”
We are not here to argue the merit of hacking necessarily, but rather to consider that there are many times in life and business, especially when undergoing big change, when traditional methods no longer cut the mustard. All hackers, whether sinister or benevolent, are after rapid and disruptive results. In organizational change management, rapid and disruptive are the names of the game.
For the sake of this paper, we define hacking as solving complex, yet very common problems by leveraging nontraditional methods.
This is the first of a short series of articles in which we look at some examples of when my teams embedded “hacking” techniques into a transformation or project as part of our Organizational Change Management (OCM) processes. We see that, when the transformation, or OCM, leader becomes the lead hacker and champions the use of nontraditional techniques to lead change, we were able to rapidly pivot, overcome volatile challenges, and reach the desired state of operations more quickly.
Common Problem # 3: Treating OCM as a Disparate Methodology
Problem Overview
Many companies have evolved their delivery methodology from traditional, or waterfall, to Agile. In such cases, stakeholder engagement changes, as does the timing of stakeholder impacts. Despite a change in delivery of projects that introduce change (sometimes significant), the process that focuses on the people side of change (OCM) has not evolved at the same pace.
When the OCM work stream does not align to the delivery work stream, stakeholders do not receive the right information or engagement at the right time, leading to increased resistance and slower speed to benefits.
In a traditional, or Waterfall delivery model, a business case and a bulk of the specifications (aka requirements) for a solution are documented up front, resulting in a timeline of months or years for the delivery team to produce a working solution. The OCM teams’ roles include heavy, up-front interaction with the project teams and then follow a predefined path that aligns with the waterfall delivery.
As more companies have embraced the philosophy that speed wins and we are in a constant state of change, they have moved to an Agile delivery model. In this model, a requestor provides a problem statement and enough specifications for a development team to produce a working solution in a short period of time. Importantly, the requestor stays very involved, sometimes daily, with the delivery team to answer questions about certain features of the solution. The requestor then gets to test a basic working solution (sometimes called a Minimal Viable Product, or MVP) within, for example, four weeks. Additionally, the requestor can provide more specifications for the next iteration of the solution, aligning the specifications to real-time conditions within their operational environment and systems. This method obviously has implications for end users with respect to the timing and complexity of impacts.
Real World Example
A financial services organization with 2.5k employees wanted to move away from manual processes in their project and portfolio management. I was hired to assist in this transformation with respect to the process for budgeting and the supporting technology. The new processes and collaborative, cloud-based tools were a complete deviation from the manual processes in place. Working with the client as part of the discovery effort, we chose to use an Agile methodology to achieve quick, iterative results with a Minimum Viable Product (MVP) while creating a culture of collaboration that was not present at this organization.
Importantly, this organization experienced a failed transformation of the same tool and similar processes for the same end users just a few years prior. Not only did the project team fail to create an end-to-end view of the value stream, they did not closely embed the OCM team with the delivery team.
At the time of my engagement, the culture of the organization did not seem ready to embrace the close collaboration required by Agile delivery. Teams were siloed and did not often communicate or agree on methods for problem resolution.
The combination of a culture that did not support collaboration and the history of a failed change with the same solution created a situation in which stakeholders did not believe we would successfully implement the new tool. They believed their current processes would not change. This led to a very difficult project initiation in which we had little engagement.
A Hacker’s Approach
Being nimble is paramount to hackers. This requires constant collaboration and accepting a bi-product of high speed and agility: failure. The important thing to hackers is to fail fast. Valuing fast failure for its lessons is a mindset that fuels the Agile methodology, as well as Change Management, but it does not always work out that way in the real world. Ironically, not valuing fast failure could lead to more complete and irrevocable failure.
Applying Hacks to our Real-World Example
For this implementation, I embedded the OCM team within the delivery team. Our Change Team participated in the delivery team’s Agile Ceremonies (aka meetings) in which we discussed daily progress, impediments, and had frequent demos and planning (daily stand-ups, biweekly demos, retrospectives, and sprint planning). For additional methodology alignment, I conducted daily stand-ups with the OCM team and several Change Agents to discuss near term impacts based on the evolving transformation roadmap.
Mashing the OCM approach with the Agile delivery approach created a stronger sense of collaboration and accountability among business subject matter experts, developers, testers, and OCM participants. There was a spirit of one team with a unified mission. We used shorter duration, but more periodic Hackathons to crowdsource ideas to resolve impediments, improve end user engagement, and reduce resistance.
We further strengthened the culture of collaboration and trust required in an Agile environment by leveraging a multi-dimensional physical storyboard to create visualization (and transparency) into our activities and progress. Having this visual radiation allowed not only the OCM team to track our progress, but also IT and Business stakeholders to easily see our work. This often helped us identify activities that should be reprioritized based on the changing roadmap of the delivery effort.
We enabled our team members and stakeholders that were not co-located to track the activities and update story cards by including the OCM user story cards on the project team’s digital storyboard – a tool called Rally (I have also found value in similar online tools like Trello, Jira, Team Foundation Server, and VersionOne). For our non-technical stakeholders, I sent out a picture via email each week with a note that focused on progress updates, key wins, and upcoming activities.
Lessons Learned
The key to all this is that we increased the company’s “speed to benefits” from the transformation. This was a result of enmeshing the OCM and delivery teams, which improved the timing of stakeholder communications and engagement activities. We not only achieved a successful implementation of the transformation on time and within budget, but with adoption rates that beat all forecasts. We felt strongly that this was all due to a renewed culture of collaboration.
In view of the bigger picture of any transformation or change, it’s important to keep in mind that a linear approach to OCM may not align well with the rest of the transformation team’s roadmap. Enable the OCM team to be Agile and leverage the processes, and tools, that come with the Agile methodology. Create activity transparency and broader collaboration beyond the OCM team to ensure an end-to-end view and real-time updates via daily stand-ups with the project team.
Takeaways: Hacking Disparate Methodologies
-
Mash your OCM Team with the Delivery Team to enable alignment of methodologies
-
Use physical visualization to create transparency on the timing and impact of OCM activities, allowing non-OCM team members to easily provide inputs
About the Author
Kevin Smith is a Lead Consultant with Impact Makers. He has a proven track record of successfully creating and implementing governance structures related to Transformation, Project/Program Management, and Organizational Change Management. Kevin has robust experience in managing multimillion dollar transformational and core programs while managing resources across multiple disciplines and geographic proximities.
Kevin has an insatiable desire to learn and continuously improve.
Knowing that the world is not static, and that every barrier can be penetrated, Kevin embraces opportunities to bring together a confluence of forces to seek out better ways of doing things. Kevin strives to create meritocratic cultures where competence is key, and the risk of failure does not impede innovation.
References
Weise, E. 2017, September 26. A Timeline of Events Surrounding the Equifax Data Breach. Retrieved from https://www.usatoday.com/story/tech/2017/09/26/timeline-events-surrounding-equifax-data-breach/703691001/
