The reasons vary, including poor strategic fit, paying too much, culture clashes, poor communication, lack of executive leadership, technology infrastructure mismatches, lack of the right people and skills and poor project and change management capabilities. Martin adds another cause: “Companies that focus on what they are going to get from an acquisition are less likely to succeed than those that focus on what they have to give it.” I think the real cause of failure is wishful thinking, where the leaders spend all their time on the exciting, upfront stuff and expect the value to flow once the deal is done. In reality, that’s when the hard work begins.
Related Article: From the Sponsor's Desk: The Lessons of Heroic Projects
In this post, we’ll look at a company whose efforts to integrate an acquisition were severely hampered by a number of these factors. Failure to address these gaps upfront generated inter-departmental hostilities, caused their newly acquired customers considerable angst and damaged their relationship for a number of years.
Thanks to P.M. for providing the details on this case.
This facilities management organization had recently acquired a smaller competitor. The CEO decreed that the operations of the acquired company should be fully integrated into their own operations by January 1 of the upcoming new year. The integration mandate included customer service functions, engineering, finance, marketing and sales, human resources, and information technology. The organization had a little over nine months to implement the change.
The CEO appointed James, a soon to be retired executive, as the VP Integration and told him to go ahead and make the change happen. Accompanying the appointment, the CEO announced the plans to the organization and to all their customers, old and new.
The CEO challenged his new VP Integration to ensure all aspects of the acquired company were assimilated into their organization’s operations by January 1. The CEO set a budget of $250,000 for the project.
Now James, the new VP Integration, was a nice guy. He had been the Director of Sales for the organization. He was good with people. He had a great relationship with the customer base and his sales team. But, he had no prior project or change management experience.
The other VPs waited for James to put a plan together and get the project underway. Nothing much happened. The VPs started calling and emailing him to get going on the project. So James set up meetings with each of the VPs to talk about what had to happen in each of their departments to make the integration work. At least those discussions got the VPs thinking about the impact of the integration on their operations and staff.
But still, not much happened. Now six weeks into the project, the VPs started hammering James about putting a plan together and assigning staff to work the plan. So, James booked a series of one-hour, bi-weekly meetings to “review progress”. At the first meeting, he discovered that it’s difficult to review progress when there’s no plan in place. He was looking to the VPs to provide the plan. The VPs were looking to him. Because of the planning vacuum, and recognizing that James didn’t have the inclination or the capability to develop the plan himself, the VPs agreed to develop plans to address the work that needed to be done in their own organizations. James agreed to pull the pieces together into an overall plan.
At the next bi-weekly meeting, James went around the table and asked each VP to review their plan and progress against it. The VPs were aghast! They thought it was James’ job to manage and report on progress. James assumed it was the other VPs job. The situation reminds one of that old tongue twister – “The skunk sat on a stump. The skunk thought the stump stunk. The stump thought the skunk stunk.”
As a result of that meeting, the VPs started taking matters into their own hands. The VP Customer Service contracted with the organization that provided their customer management software to convert the acquired company’s customer records. The VP Engineering contacted their telecom provider to convert the communications technology in the acquired company’s vehicles. The CFO contracted with the accounting software vendor to convert the acquired company’s financial records. And so it went. As the individual VPs started taking matters into their own hands, they perceived there was little need to attend James’ bi-weekly meetings. The attendance dropped off and so James cancelled the meetings.
The company was creating a number of silos, focused on a single outcome, without regard to any interactions and interdependencies between and among them. They were about to discover the vagaries of vertical projects and the wonders of wishful thinking! Self-delusion only works for so long!
About fourteen weeks into the integration effort, the CIO started to get concerned. No one was talking to him or his staff about the need for additional software development support or computer operations capacity and services. He contacted each of the VPs to find out what their plans were and how they were progressing and discovered a quagmire of half-baked plans, projects, and expectations. It was a disaster!
He met with the CEO and suggested they bring in a senior project manager to pull the mess together and direct the work until it was finished. The CEO balked. He had already appointed James as the VP Integration. It was his job. The CIO persisted. He recognized that the CEO’s credibility was on the line with James’ appointment and the January 1 announcement. So he proposed that the new project manager is officially hired by and report directly to James but have a dotted line relationship to the CIO. The CEO didn’t buy it and the fumbling went on as before.
As each department proceeded with their own plans, they had to communicate with the new customers about changes to their services brought about by the integration effort. That meant that each new customer was getting multiple communications from the different departments, often with significant change challenges and conflicting messages. Senior management from the new customers started venting their frustrations with the organization’s senior management, including the CEO.
At an executive committee meeting almost six months into the integration effort, the CEO complained about the flack he was getting from his new customers. He challenged the VPs to fix the problem. The CIO took the opportunity to present his project manager proposal again. The other VPs supported the idea. The next day, the CEO called the CIO and told him to make it happen.
The new project manager was selected by the CIO and officially hired by James to run the integration effort. Announcements went out, the PM got to work, pulled a plan together and brought in the necessary resources including previously contracted vendors. He then pushed the VPs and their staff for the key decisions to get the work done. The new PM discovered that almost forty percent of the total effort lay outside of the previously defined verticals. Additional work was needed to add and revise interfaces and absorb functions and technologies from the acquired company that the organization didn’t support.
The project that was originally allocated $250,000 and nine months took over $700,000 and sixteen months to complete. It was completed in July of the following year versus the planned January 1. The project manager took a phased approach to the implementation and was able to deliver some components prior to year end, which helped take some of the sting out of the later delivery. James, the erstwhile VP Integration, officially retired on January 1. The project manager continued through to implementation reporting to the CIO.
A post audit of the project found that almost $200,000 of the cost was attributable to rework from the “silo” mindset originally adopted. In addition, many of the new customers from the acquired company were so frustrated with the broken promises and miscommunications that they moved their business to competitors. That negatively impacted the bottom line. The planned ROI was not realized.
How Great Leaders Could Have Delivered
This case is a wonderful example of wishful thinking. All the executives were infected with the bug. Here are some things they could have done to deliver a different result.
• Appoint based on skills and capabilities
The CEO picked James to lead the integration effort because “he was available”. James’ plan to retire on January 1 was a perfect fit with the CEO’s desire to finish the work by January 1. What could be better? Selecting someone based on the skills needed to do the job would be a good start! In my post, Ten Winning Project Management Practices, #5 is most relevant to this case: “The project teams were a combination of internal and external resources. The teams were ‘A’ players with the right skills. A recurring theme was that ‘Availability is not a skill.’” That mindset was one of the reasons that team delivered successfully.
• Provide meaningful financial boundaries
Where did the $250,000 budget come from? It was, in fact, completely arbitrary. The CEO said it seemed about right when asked during the post audit. The problem with a wild ass guess like this is that it sets an expectation. In this case, it was a dangerous message: the project isn’t very big, and it won’t take very long, so I don’t have to worry about it.
If the CEO needed a financial target before enough information was available to estimate accurately, he could have used the approach outlined in my post, Avoiding New Technology Risks. In that post, the sponsor worked out a realistic figure of how much she could afford (it’s called ‘Worth’ in Project Pre-Check’s Decision Framework) which informed her project decision-making through to implementation.
• Collaborate widely
This organization had a very strong, department-centric culture. The VPs focused vertically. There was minimal cross-functional collaboration beyond the few touch points needed to get operational data to and fro. Under duress, the VPs opted for their natural operating style – silos.
Think of the potential they were leaving on the table; more informed strategic planning (currently the domain of the CEO and his favorite consultant) and a more ingrained strategic plan, cross-organization process improvements to improve service, reduce costs, improve quality and grow the bottom line and a much more robust capability to handle major business change.
• Build a project/change management culture
Most of the changes this organization had implemented in the past were focused within a vertical silo – customer service changes in Customer Service, engineering changes in Engineering. They didn’t have a cross-organization project/change management capability. They didn’t typically use project managers. Their knee-jerk reaction, when faced with the integration challenge, was to look internally for an executive to make it happen. At least they recognized that this undertaking was a bit different and would require a different approach.
Unfortunately, the CEO and the VPs didn’t pursue the issue further. They all knew their organizations were impacted, but they left it up to James to lead the way. In a vibrant project and change management culture, the affected executives learn to step up, take accountability and work with others to take an holistic view of the change. That’s the power of a project/change management mindset – pulling those diverse interests together to develop and follow a roadmap to success.
As illustrated by this case, wishful thinking is a dangerous approach to managing change. The launch of a project should be a clear signal that things need to be different from normal operational practices; new people, new skills, new relationships, new accountabilities, new questions, new decisions, new processes and practices, new technologies, etc. Certainly, many of the traditional causes of acquisition failure outlined up front were present here. Organizations that have a strong project culture have a clear advantage.
So, if you find yourself in a similar situation, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.
Finally, thanks to everyone who has willingly shared your experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks