ServiceExperts™ is a series of contributing articles from recognized industry professionals offering their thoughts, viewpoints and opinions on the latest trends impacting the service industry. Jim Bohn, PhD is an author and researcher-practitioner focused on improving organizational performance one person at a time. Dr. Bohn has decades of on-the-job experience in addition to a strong foundation of academic research. Dr. Bohn has organizational expertise and insight stemming from decades of successfully leading leaders. His business insight derives from observing the organizational behavior of multiple Fortune 500 organizations, ranging from hospitals and healthcare to retail and finance, service, manufacturing and telecoms.
He served in a variety of roles in the corporate world beginning in 1973, personally leading the transformation of multiple underperforming teams to achieve award-winning levels of success. Retiring after 33 years with Johnson Controls, Dr. Bohn launched his own Change Management and Organizational Transformation Practice, PRO/AXIOS LLC. Dr. Bohn has a unique blend of hands-on, in-the-trenches experience in addition to a rich pedigree of research from his Ph.D. studies. In addition to lecturing at local universities, he is the author of several books, including “Architects of Change: Practical Tools for Executives to Build, Lead and Sustain Organizational Initiatives,” as well as his latest work, “People Development: The Best Part of Leading a Team”.
This article outlines the risks inherent in introducing new technology to your organization. Read each of these risks carefully, and ask yourself whether you, your leadership team or executives have succumbed to the risk. Review the actions and determine whether you have effectively managed this risk.
Risk 1: ROI Blindness
Perceived ROI sometimes makes rational people irrational. Rare is the organization that goes back to check the original ROI to determine if it achieved the financial benefits it promised. Executives must be brutally honest about the true financial and human toll required. As a leader, you may be infected with this malady. Understand that the PowerPoint slides of consultants are long gone and forgotten once the project picks up speed (and the consultants are gone too! I often have thought we shouldn’t pay a consultant their final 1/3 until the project has demonstrated results). Beware the big numbers consultants sell you. The consultant won’t be around to pick up the pieces.
Action: Bring data. Ask a lot of questions from the consultant, including references and evidence of past stories of success. Raise issues about participation and effort. Who is doing what?
Risk 2: Your organization is not prepared for the change
The old gospel song asks “Are you ready?” Have you thought through how, where and when this implementation will affect your organization? Do you have the capacity for this change? (In terms of resources, which must be moved or added? Are there any projects that must be put on hold? Opportunity costs?)
Have you conducted organizational diagnostics in the context of the IT change? (In other words, what OTHER projects are happening at the same time?) Is your organization ready to work together to accomplish this change? Does the organization understand the ‘why’? Can the organization ‘stay the course’? Are the leaders in place to manage the scope of the change? You must conduct in-depth preparatory analyses of these questions to ensure a comprehensive understanding of all aspects of the IT scope.
Action: Answer the questions raised in the paragraph above. Take the time to effectively evaluate organizational capacity for the technology change.
Risk 3: Using the “B” Team when only the “A” team will do
Are you fooling yourself into thinking that those with spare time on their hands are the right people for the job, simply because they are available? Think again. B team members know why they are being selected, and they will mark time until something else comes up. It is tempting to throw B team members at a project, but it is not wise. Put the B team players into a maintenance project. Top talent is critical for the success of these projects.
Action: Raise the issue. Remind the organization about the long-term impact of the project on funding, productivity, customer satisfaction, employee motivation and project credibility. Parenthetically – using the A players means you provide them with incentives for being part of this incredibly complex project.
Risk 4: Denying the business impact of the change
Some revenue loss will occur.
Research by Gartner and others shows your organization will not perform at the same level during the introduction of a new system. There are revenue and profit implications to adding a new system. What is your plan? Ignoring this issue will not make it go away. Manage it by assessing the risk and developing alternate streams of revenue.
Action: Raise the issue. Plan for one division to pull weight to adjust for the change. Make appropriate financial adjustments in advance of the change during the time period in which you will GO LIVE.
Risk 5: The wheels on the bus go round and round
Your organization needs to continue to serve customers and care for employees during the change. You are changing a tire on a moving vehicle—what are your contingency plans to manage the business while its moving?
Action: TEST, TEST, TEST and then TEST again! Ensure a back-up plan is in place during ‘GO-LIVE’ in the event of a disaster or hiccup so business can go back to the old way momentarily (not permanently) while fixes are put in place.
Risk 6: The Jimmy Hoffa syndrome—where are the bodies buried?
Your system analysts will discover unexpected software patches that must be integrated with the new system, some built in COBOL = $$$$. Uncover those pitfalls early in your due diligence! They are expensive discoveries to make after the fact.
Action: Due diligence for all interfaces must be a priority at the very beginning of the project. Ensure someone’s feet are held to the fire to do an outstanding job of detective work. This is a non-negotiable element of the project. Put your best people in this role, and have them articulate precisely what the cost will be to integrate the system with these old feeds.
Risk 7: You’ve miscalculated the impact
Your implementation is going to impact a lot of unforeseen individuals and teams. Discover who will be impacted. I can assure you: The impact matters to them! Working with those who are impacted dramatically increases your chances of a successful launch.
Action: Determine all groups who will be impacted—even those on the periphery of the project. This work can be done in concert with the due diligence for system interfaces.
Risk 8: Ado Annie syndrome (“I can’t say ‘No’”)
Ado Annie was a character in the musical Oklahoma who constantly said: “I can’t say ‘No’”. Without discipline, projects grow into monstrosities, becoming impossible to implement. Scope creep happens. Do not allow ‘customization’ to creep in!
Action: Executive leadership must set and HOLD the articulated boundaries of the project.
Risk 9: Automating bad processes
Do not write technical design documents without first having gone through process redesign. Resist this impulse or you’ll automate a bad process. Process Redesign is arduous, exhausting, painstaking work, but it must be done.
Action: Assemble the process redesign team early in the project plan and ensure a complete set of processes has been analyzed before the tech design documents are written.
Risk 10: Not “counting the cost” of what it will take to complete the project
The Biblical adage about ensuring you can finish what you start is wonderful ancient wisdom. Consider the whole cost—people, process, and finances. Are you really determined to complete the project?
ACTION: Ask yourself and your executive team if you are truly committed to getting this thing done.
Risk 11: Ignoring the details
In global projects, the meaning of terms is crucial, so define terms. Develop standard revision controls, and agree upon project disciplines…this is painstaking work but worth the time and effort.
Action: Ensure you have revision levels, contract agreement details, a clear understanding of what a ‘change request’ means, and on and on. The Devil is truly in these details, which can be exceptionally costly.
Risk 12: Developing an adversarial relationship with your vendors
It’s easy to fall into this trap, arguing over contract details from the very beginning of the project until the last line of code is completed. This trap causes an excessive expenditure of precious energy you will need for the implementation of your system.
Action: Set the stage up front with clear expectations about how you will work together, who is responsible for what, and timelines, costs and agreements on contact points in the organization. These are areas where thing can go awry from the outset, so take the time to effectively develop the relationship from the beginning. Once it becomes adversarial, the project is in bigger trouble, because that’s when the ‘blame game’ sets in.
Don’t forget to check out Dr. Bohn’s latest book, “People Development: The Best Part of Leading a Team.” If you’d like to hear more about change management strategies to ensure long-term success, listen to our InService™ Podcast with Dr. Bohn, “Becoming an Architect of Change.“
