A few years back, I was attending an executive presentation of project findings and recommendations for an outdoor products manufacturing company. The project remit was defining the future state digital architecture and a high-level plan to support the organization’s transformation of the customer experience. Our engagement lead had vetted the findings and recommendations with the client’s core team. The core team was excited about the level of detail, the plan’s comprehensiveness, and the consistent architecture across multiple tools that would enable an outstanding customer experience.
The plan included enough detail for the organization to begin to lay the foundation immediately and achieve several quick wins to build support from a range of skeptical stakeholders. The timelines were realistic based on the company’s current capabilities. There was a very positive, even ebullient feeling on the part of the client core team going into the presentation with executives. We had been to lunch with the CEO and a few members of his team, and there was a professionally respectful, friendly rapport.
I was particularly proud of a new methodology we created to deal with the client’s particularly complex issues, the structure of deliverables, and the phased roadmap tied to measurable business outcomes and milestones. I liked how we tied the timeline to a maturity model that built supporting processes and alignment with program needs. It was a great piece of work all around, and it seemed to me that we were going to knock this out of the park.
The engagement lead was confident. The client core team was smiling and everyone anticipated a great reception. The CEO walked in with the COO and the room fell silent. The client project leader opened with a few words about the engagement and turned the floor over to our engagement lead. As he began the presentation, he noticed the body language of the execs – folded arms and frowns on faces. After a few minutes, the CEO had started to become more visibly impatient, even upset in some way. Folded arms, shifting in his chair, a glower on his face. The engagement lead stopped the presentation and said “I have a feeling this is not on target. Can we talk about that?”
The CEO let loose. He lambasted the project deliverables and details that he did not care about. He wanted to know how much it was going to cost to “Just make it work.” He didn’t care about what needed to happen to get there.
How much detail is necessary?
The project objective (and the topic of our presentation) was to lay out a plan and a future state architecture. Developing program costs and budgets was not in the scope of the short 4-week engagement – it was not possible to provide a price tag without more detailed discovery and exploration. This begs the question of how such a stark misalignment could happen.
Several fundamental breakdowns occurred during this incident. The CEO was known as having a typical executive attention span and little patience for details. There was no CIO, so the program lead played the intermediary between our firm and the company’s leadership. His approach was to limit direct communication between business leaders and the tech team, which included our consultants. He acted as a proxy for the needs of the business and believed he understood what the CEO and his leadership wanted. However, he had not had an explicit discussion of their expected outcomes within the scope of the initial short engagement. Even though the results, the findings, and the recommendations were spot on, the CEO did not get what he was looking for. But was he looking for the right information? Imagine if we had said, “It’s going to be $20 million over the next 3 years,” What insight value would that provide?
More important than the number is the value of the initiative and the path to success. How would funds be spent and how will the project align with current capabilities, processes, maturity, technology stack, employee bandwidth, skill sets, ongoing resource requirements, governance, and so on. Programs that span multiple years, and involve stakeholders from across the organization are complex, contain multiple dependencies, require in-depth knowledge of existing processes and extensive change management. They require weeks or months of planning and requirements gathering to correctly define functionality and the internal and external costs for software, services, architecture, data remediation, process change, culture change, governance, analytics, and more.
Executives cannot make informed decisions without getting into the weeds about not just the nature and severity of the challenges but the business decisions that need to be made as part of any technology effort. Those decisions require that business stakeholders – process owners, department head marketing teams – be engaged at the right time and the correct level. Business leaders prefer to respond to options rather than being presented with open-ended questions. Provide design and process choices with pros and cons. Asking what the process should be is less effective than saying “here are three process models, the advantages of the first are…” Rather than asking about their business objectives, assume the motherhood and apple pie of better customer experience, improved revenue, reduced costs and ask “Which are most important?” and then dig into the various issues and obstacles. List the typical obstacles to strategic objectives and follow up with the question: “Which of these most resonate?”
The most important program parameters include expected outcomes, proof points to support the investment, a realistic plan, ongoing measures of success, and long-term program ownership and governance. These can be summarized in the following four questions:
- What is the project going to cost?
- What do we get in terms of capabilities and outcomes?
- How do we make sure we are on track to get it?
- Who bears responsibility if we don’t get what we expect?
Building up versus breaking down
The mistake that both the client team at the manufacturing company and the team from my firm made was to start at a granular level. We explained the obstacles, issues, and remediation approaches for addressing each of the components of the overall expected capability – product data, customer information, supporting content, and insights from analytics and experts. For example, a 30-factor heuristic evaluation of digital asset management showed they had a lot of work to fix their digital asset system. They had to integrate multiple systems, clean up content, secure rights to images, refactor and retag assets, consolidate processes, and so on.
The required investment was several hundred thousand dollars, which is a lot of money, although the value of the quick wins would offset a portion of the investment. The company’s use of an outsourced e-commerce vendor significantly limited what could be done to support a dealer and direct-to-customer hybrid sales model. (The model which they were moving toward) Product data was a mess, and analytics were performed in siloes using different tools, inconsistent naming conventions causing wasted time, and inefficient manual steps, all of which would lead to significant delays in acting on the insights.
All these issues were included in the presentation and were meant to provide the specific building blocks of a plan that could be executed to achieve corporate goals for the digital transformation. What was missing was the level of effort required for each phase that could be totaled into overall program investment. The overall program investment was not in scope for our initial engagement but would be part of the next engagement. We had done only the first phase at that point, which was to evaluate the current situation and lay out a plan for beginning the journey. More steps would need to take place to define a detailed course and provide estimated costs
Seeing is believing
One way to engage the executives who may not initially want to deal with details is to present a visual plan that provides an overview and the full scope of the plan. It should have multiple tracks of work broken down into phases with specific milestones that can be graphically presented in a way that communicates a lot of complex program detail simply. The graphic below illustrates this approach and had worked well with an executive audience in a previous presentation. They wanted to see timelines and projects that comprised the workstreams and know who was responsible. (The terms may not make sense to an outside audience – this illustration was adapted from a program with any client info removed). This graphic started at the macro level and then broke the big picture down to specific phases, workstreams, and ultimately to 60 discrete projects that had to be completed as part of the program.
This approach may have been what the exec was looking for. It should end up breaking down into the same issues and challenges. But the original scope of this engagement was not all-encompassing and could not provide more than order-of-magnitude estimates for what it would take to provide a full solution. This could be something like a Heisenberg uncertainty principle for large technology programs – the bigger the scope, the less precise the estimate of level of effort. (Kind of like in physics where it is possible to know the position or velocity of a particle but not both[1].) This may be the correct level of detail for execs, but teams that need to execute will need more. Further granularity is defined at the project level. This example engagement in the graphic broke down to more than 60 projects that would need to be executed to meet goals and timelines. Those projects were further defined at an even more granular level with work breakdown structures, task assignments, resource requirements, and interdependencies.
Expectation management and confirmation
The disconnect was the lack of understanding that the client core team and our team had of the expectations for the deliverables. The client core team (comprised entirely of technical people) acted as an intermediary, providing us with an interpretation of the exec’s needs. To a degree, the exec was shielded from direct inquiry from us or a validation of our approach. The lunch with execs may have been an opportunity to do so but was carefully choreographed by the customer’s team leader, who clearly outlined the topics that should not be addressed – which included questions about the project expectations! The tech lead wanted an architecture and detailed remediation roadmap. However, the exec wanted the big picture program costs to bring to the board.
The crucial question of “What will you do with the results of the project?” often produces different answers from the business and technical perspectives. The business wants to know where the project is going, what it will cost to get there, and what the payback will be. The technical side wants to know how to get started, what the technical details look like, and how to begin to address the challenges of implementing the project.
But wait… there’s more
While all this makes sense, that was not the entire picture. It appeared that another completely different dynamic was also at work. The executive later confided in our engagement lead that “that was for them.” Meaning that his tirade was meant to shake up his team, who he felt was not bold enough with their asks and ambitions. They were not taking risks and moving things forward. He actually liked the plan we presented, despite the over-emphasis on detail, but he did not like that his team was too timid to take a stand on it and recommend that this was the approach they would get behind. Instead, they were putting up our firm as the sacrificial lamb to see how the CEO would respond. If he liked what he saw, they would be behind it, if not, they had a convenient target.
What they did not realize is that the CEO saw through this and interpreted it as a lack of the confidence to take a stand and defend it. When he criticized the plan, no one on the team, who had been such staunch supporters a couple of hours ago, said anything to defend or support the approach. The CEO may have had some legitimate issues, but his team did not stand up to the criticism. The team could simply blame the CEO for poor behavior, but standing up to a strong-minded, impatient, opinionated exec is less difficult if one believes firmly in the work and believes it is the best approach for the organization. In that case, it would have been easier for the team to articulate the risks and benefits of different alternatives, and to withstand a challenge to their line of thinking.
Lessons Learned
Several lessons can be learned from our experience with this interaction. Although the scenario here was digital transformation, the lessons can be applied to many types of projects. The primary lesson is that communication is paramount. The core team did not understand what the CEO and other executives needed to hear to get on board with the project. Therefore, they could not communicate it to us. Moreover, execs often lack enough understanding of the reality on the ground to believe in the proposed budgets and timelines or understand the nature of the work. But why are they disconnected from this reality? Are they getting the right level of detail and answers to the questions they care about through members of the team that they trust or are they just not communicating their questions well?
In this case, the exec did not have patience for the details because as it turned out, he saw that his team did not stand firmly behind the plan. That dynamic was more important than the specifics of the project. In his mind, if things went south, the team would immediately look to place blame rather than owning and standing behind their plan. That left him with little confidence that the numbers would be real and the project practical.
Regardless of the politics and gamesmanship, it is essential to ensure honest communication, questioning of assumptions, and validation of expectations across different levels of the organization. Keep the following in mind:
- Confirm expectations – ask what the decision-maker will do with the results of the project. If your team is not in direct touch with the decision-maker, provide a checklist for the intermediary that helps clarify what will define a successful project. What outcome does the organization need? Is it to:
- Understand order of magnitude investments required for digital transformation, to begin to socialize this with other execs
- Propose budgets for approval
- Allocate resources from budgets
- Determine accounting treatment (what costs can be capitalized versus costs that will be an operating expense)
- Approve new or continued investments in an initiative
- Justify past and ongoing investments
- Plan project phases
- Develop governance and accountabilities necessary for long term management
- … and so on
Here are some additional best practices:
- Identify short-term benefits and quick wins during the presentation
- Convey complex programs visually to avoid getting bogged down in details. If the executives want to delve deeper, the graphics can provide that option.
- Explain the projected impact of improvements and ROI as well as the opportunity costs of not acting.
- Let the client know that you will capture baseline metrics on target processes so that they can compare the previous metrics to the evolved state
- Explain how the program will stay on track and which milestones will be communicated.
- Keep corporate culture in mind.
The fact that the customer team leader did not want us to discuss project expectations at our lunch should have been a red flag, indicating the suppression of an open flow of communication. It is also possible that the CEO had created a culture where people were fearful of failure or criticism, and that prevented the team from affirming a belief in the plan we presented.
Knowing what is most important to your executive audience will tell you what messaging to emphasize. Always ask “What’s next? What will you do with this answer?” The answer to that question will help keep the program aligned with the needs of executive sponsors and help them pay attention to and understand what is important for the success of the program.
Notes:
[1]https://www.britannica.com/science/uncertainty-principle
***
A version of this article appeared on CustomerThink.