Language is our most important tool as human beings. It is essential to our interactions and has the ability to bridge gaps created by space, time, and culture. Unfortunately, in our organizations, language can be a burden, exacerbating those gaps and even widening the chasms that have formed organically between lines of business, teams, and functions over time.
Today, we face market conditions that change by the month, by the hour, or even by the second. In order to remain agile and shift our strategies in response to this dizzying pace, it is critical to correlate strategy and investment in a way that every function, product, line of business, and leader can understand. To do this, language matters.
Seems easy, so what’s the problem?
In most companies, investment decisions are evaluated on an annual basis providing guidance on what should be done and what value will be achieved. As part of this financial planning process, strategies get divided up among business units and functions. Isolated lists of projects are created to support those disaggregated objectives, vying for limited funding. These project lists contain line items that may be recognizable to the individual teams, but are meaningless to other areas, e.g., Phoenix, Eagle, CRM, SAP (which parts of SAP?). This “Inexorable March Toward Projects” (Figure 1) fosters the false sense of security that the sum of the projects will achieve the desired goals in a fiscally responsible and timely way.
Figure 1. Inexorable March Toward Projects ©The Feld Group Institute 2021
Project lists mask important information.
Teams spend so much time getting their project on the list, that once approved, they are already behind on delivery. There is little time left to coordinate or share their plans with other groups for broader awareness and typically few, if any, resources are dedicated to identifying the patterns (for integration, resource leverage, acceleration) that exist across projects and across the company. These disconnected project lists and cryptic project names diffuse any possibility of common understanding of what the company is marching towards. Leaders may know what’s going on in their own area, but it’s hard to know if other business units are building the same functionality (e.g., how many eSignature apps do you need). In addition, what functionality could be reused or leveraged to speed delivery and increase quality. In the project-centric operating model, there is a deadly one-two punch: limited visibility of the whole and virtually no incentive, nor appetite, to plan beyond your silo.
And as soon as the annual project lists are finalized, they are quickly unfinalized. Late breaking changes to goals and objectives lead to constant revisioning of what is “in” and what is “out”. With these adjustments masked by project jargon, the company may achieve annual budget targets but may fall short of the desired business goals. The sum of the projects becomes blurry and blind spots are formed between business vision and delivery execution, between business units and functions, and between business and technology. To make matters worse, this never ending process is resource intensive, mentally exhausting, and creates devastating cracks in investment plans where value leaks out.
This convoluted project-centric modus operandi undermines our ability to dynamically align business value with the change required to achieve it. At best, you achieve the business outcomes (good) but it costs more and/or takes longer (bad). In the worst case, business outcomes are not even achieved (very bad).
If the “Inexorable March Toward Projects” is costly, risky, and time consuming, why do we still do it? The answer is simple: that’s the way we have done it. But if you press leaders, they will readily admit that the current way is neither efficient nor effective.
We need to do something different.
We need to remove the jargon and miscommunication that is inherent with project lists and project names. We need a common language across the organization which can align business value with the change required to be successful. We need to shift toward a “capability” mindset.
A capability is simply the ability to do something. For a business, a capability is what a business does (or should be able to do), defined in the same language executives use when describing strategy. No acronyms. No code words. No application names. It’s “Generate Service Recovery Options” not “Falcon 2.0”. It’s “Administer Benefits” not “Workday-HCM”.
Having this common language of capabilities allows us to:
- Integrate strategies across business units and functions
- Identify redundant needs and opportunities to build once and reuse
- Leverage existing building blocks to gain speed to market on new capabilities
- See patterns that are unfolding that require runway to address collectively and effectively
Leveraging a common language, we can converge, rationalize, and integrate the needs of various teams (Figure 2). Capabilities allows us to zoom out and look across the entire organization to see the synergies and opportunities.
Figure 2. Converge, Rationalize, and Integrate through a Common Language ©The Feld Group Institute 2021
Whether you know it or not, this common language of capabilities is the foundation of the “Business Architecture” discipline. Don’t be scared, “Business Architecture” is not as complicated or esoteric as you might think. Business Architecture simply provides the connective tissue you need to link the value you want to achieve to the capabilities needed. (Figure 3).
Figure 3. Connecting the Dots ©The Feld Group Institute 2021
So, how do you shift to a “capability” mindset?
The dialogue will need to change as capabilities become the lens through which you will talk about the current and future state. Start conversations with your partners in terms of what you need the “ability to” do instead of what system you want to upgrade/replace. Listen to and learn from other areas of the business; what capabilities have they developed that you could connect to, reuse or repurpose?
It’s not easy, but you may be closer than you think. In many cases, you will be surprised to find that you already have key elements of Business Architecture, somewhere in your company; you can dust off those insights and connect the dots between key strategies, capabilities, and a business capability model.
Remember: the current “March Toward Projects” is not working and it’s exhausting. While a shift towards a “capability” mindset takes time, the effort to find a common language is a necessary investment, and will pay off almost immediately, in terms of speed and productivity. Make the investment. Language matters and will allow you to truly be agile and keep up in our ever changing world!
Author: Meredith Sasser, Affiliate, The Feld Group Institute
Connect with Meredith Sasser on LinkedIn
Author: Kenny Feld, Principal, The Feld Group Institute
Connect with Kenny Feld on LinkedIn
__________________________________________________________________________________________________________________
FURTHER LEARNING:
Many of these concepts are covered in depth in The Feld Group Institute’s Operationalizing Business Architecture class. If you are interested in learning more about this important topic, additional resources can be found on this site, including: Aligning Strategy To Business Capabilities , Business Architecture – Linking Strategic Themes To Tactical Demand, Alignment Is Critical In Times Of Uncertainty, and in this short video with Charlie Feld Back To The Future Series – Alignment
__________________________________________________________________________________________________________________
