Architecting Value

Go Local! Making Capabilities Relevant to Your Line of Business

The challenge of an enterprise capability taxonomy is that it usually doesn't resonate with the lines of business. When I first took Microsoft IT's capability framework to our sales businesses, I got fairly direct feedback that the taxonomy didn't resonate. (I believe the technical term of art is "they puked all over it.")

Their issue was that within the enterprise capability taxonomy (internally referred to as the Business Capability Hiearchy (BCH)) wasn't organized in the way that they thought about their business. They had a framework in place already that organized their processes into three major areas - none of which were really reflected in the BCH. These three areas were what they considered their L1 capabilities.

When you clicked down from the L1 into the L2 and L3 capabilities, then you started to see a lot of similar taxonomy - pipeline forecasting, customer segmentation, etc. From the perspective of the business stakeholders, however, this detailed view was irrelevant. Their assumption was because I didn't have a capability framework that was organized in the same way that they viewed their business, they assumed that I didn't understand their business. This was a non-starter as far as they were concerned. It probably goes without saying that it's difficult to gain any traction as an architect (or nearly any profession) if your customers don't think you understand their situation. 

When you think about it, having a hierarchy is not all that important. Hierarchies - certainly at the topmost levels - are just ways to organize or classify things that are further below. There are lots of ways to organize things. For example, if I took a set of Legos, there are at least two ways of organizing it - by color or by the type of block. Neither organizing structure fundamentally changes the block itself.

The capabilities - which I think are at the L3 or L4 level - are the Lego blocks. They can be organized in lots of different ways. So there's no point really in trying to enforce an enterprise way of organizing these blocks on your business unless a) you enjoy irrelevance; or b) the enterprise view actually resonates for your line of business.

Instead, you want to "Think Local" - present the capabilities in the frameworks that are going to resonate with your business stakeholders. Generally, at the capability level - which is fairly discrete and defined - there won't be too much disagreement that those are the right capabilities. In fact, this is what I did. I took the framework our sales business had, took a subset of relevant L3 capabilities from the enterprise framework, and recast them in the sales framework. Didn't change the naming of any of the L3 capabilities and ended up getting validation that this was, in fact, the right model. A colleague who'd started out as a strong opponent became an advocate.

In general, I try to ensure capabilities are articulated in the business language so that there's no confusion. When there's a conflict between multiple lines of business, the best thing to do is to be sure that the capabilities are clearly defined.

What you don't want to have are two capabilities that mean the same thing; in this case you want to get to one. If the two groups can't agree on which (assuming that you've already tried to get them to align), pick the best (or make up a better one) and maintain a mapped view for the business(es) that don't have their own. It's not worth anyone's time to have a long taxonomy debate. It's largely academic and the ROI on everyone's time is pretty low. 

You also don't want a capability that has two meanings. Divide that one up into something more discrete. If a line of business groups two things together, try to make the case for being more precise. Failing that, maintain a mapped taxonomy. Again, there's not enough ROI to have a debate and all it does is convince your business that you're not interested in providing value.

I won't say there isn't a downside - depending on the flexibility of your tools, manual management  can get tedious - especially if you want to roll up attributes captured at the capability level and show them at a higher level of abstraction. In my view, that manual effort is worth the credibility gained with your business stakeholder.

Beware of Watermelons

Microsoft is a company that heavily leverages scorecards for managing performance. Our CIO's scorecard has nearly 100 separate metrics that are used to evaluate his performance - indicated by green, yellow, or red.  Recently, he cautioned us about scorecard "watermelons," that is, items that appear green on the scorecard but are actually significantly underperforming and should be red. This happens when the scorecard fails to capture the right measure.

 

I recently had a "watermelon" experience that should be a standard risk to look out for on business architecture engagements, especially if you suspect that the organization is not strategically mature. I had an executive sponsor insist that we conduct an engagement for his organization as they were undergoing a major strategic shift. He made available some of his managers who committed nearly 20% of their time to helping us create the strategy deliverables.

 

This engagement appeared green on our scorecard since we had executive sponsorship, commitment from the client, and were making progress on the deliverables. The only problem was that the people we were working with didn't really know what the strategy was. The executives had kept the strategy close to the vest and the managers we were working with were taking their best guess.

 

This internal disconnect with the client wasn't discovered until the end of the engagement when the SOAP was presented for validation. The executives were expecting something that articulated their transformational strategy and instead something that showed incremental improvements. We were green when it came to the engagement but bright red when it came to the actual content .

 

It was a terrific lesson - I had allowed the fact that I had engagement from the client obscure the fact that I didn't have the right level of engagement. In retrospect, I should have structured more frequent and earlier reviews with the sponsor to ensure that we were going in the right direction. The deliverables that I'm prescribing are primarily listening devices - they should be used often to validate whether you are on the right track to avoid watermelons.

Using SOAPs to Gauge Strategic Maturity

Many people who work in IT organizations labor under the assumption that their business clients have a clear understanding of their strategy - it is simply waiting on a shelf for someone to ask for it. The reality, of course, is that maturity varies from truly visionary organizations to the constant fire drill teams. I've found that the development of the SOAP can be a good indicator of my clients' strategic maturity which is why the process is just as important as the end deliverable.

 

For an organization that is mature in it's strategic discipline, the SOAP is a painless exercise. They can articulate their vision and mission; they have clear understanding of their priorities and the outcomes they're driving and the actions they need to take to get there. This is - at most - a 2-3 hour workshop with a week to tweak over email and perhaps a follow-on meeting for validation.

 

Immature organizations struggle with SOAPs. They may question the value of the activity, since the organization's strategy should already be obvious to everyone who's involved. Their strategic priorities will read like motherhood and apple pie -  "Beat the competition," "Grow Revenue" and "Satisfy Customers."  I had a client once that even articulated that their strategic priority was to "Win Everywhere."

 

(A priority should be more specific and actionable. A simple test I use is to ask myself - if I were a general (or a VP), could I use the priority  to answer credibly what my strategy is? Example: "General, what is your strategy to win the battle?" "My strategy is to 'Win Everywhere.'")

 

A key indicator of low strategic maturity can be gleaned from how the SOAPs are constructed. If the construction is generally top-down, the maturity is tends to be higher than when the activity is bottom-up. Low maturity organizations will begin with a focus on the imperatives which amounts to documenting their current and near-term initiatives. They will then articulate priorities by categorizing the imperatives.

An organization with a strong understanding of its strategy, however, does not need to categorize imperatives to identify priorities. It can easily define the priorities and organize imperatives which fit the priority.

 

Knowing the strategic maturity of the organization won't directly benefit the organization - it's really helpful for you to know how to handle the organization throughout the engagement. The value of the work will be obvious to the strategically mature organization; you will spend much more time explaining the value to organizations that are less mature. Managing those expectations will be critical to your success. 

 

Succeeding in the "New Normal"

The McKinsey Quarterly published an article (registration may be required) last month about the need for CIOs to adapt to the “new normal.” The term, coined by McKinsey worldwide managing director Ian Davis, refers to their prognosis that recovery from the recent economic downturn will not follow a traditional pattern. The economy will fundamentally restructure – a “new normal,’ marked by persistent uncertainty, tighter credit, lower consumer spending, and greater government involvement in business.”

The implications for CIOs, argue the authors, is that IT must play a much larger role in delivering on broader company goals and providing competitive advantage in the marketplace.  The authors specify three key imperatives for IT:

1.    IT must be more closely aligned with business, ideally through organization models that promote joint decision-making. Having stronger business understanding and skills will be a critical success factor for IT.

2.    IT will have to deliver more than marginal improvements in productivity and cost cutting. The goal for IT is to deliver transformational technology that radically improves the cost structure or operating model of the business.

3.    Business and IT both need to look for technology innovations that drive competitive advantage in order to adapt to the new normal.

The article does a better job of articulating the point I was making in an earlier post about IT delivering greater business value instead of focusing on marginal gains in labor productivity. I see business architecture and the role of business architects as a key accelerator of the IT-Business alignment.

There are not many functions within IT whose job is to understand the business. Business analysts, to some extent, have to understand the business processes and the business users of IT systems in order to translate business requirements into IT requirements but the altitude at which they operate not to mention their function may preclude them from having visibility into the larger business direction.

IT account mangers – to the extent that they exist – should have better visibility of business strategy and priorities, however, they may lack specific insights into the business processes and information flows that might inform their recommendations. The IT account managers I’ve worked with tend to be very senior people since they are relationship owners with the business. Typically, they aren’t going to conduct the in-depth analysis to inform  business priorities and their teams – generally made up of IT solution owners and business analysts – may not be able to fill that gap due to their functional focus.

Enter the business architect – a role whose purpose is to understand the business strategy, priorities, and operations and develop high level plans to orchestrate business and IT investment in order to enable the strategy. While this may sound like the role of account managers, the business architect is focused on how to execute the strategy while account management is focused on building and maintaining the business-IT relationship. Another way to think of it is that while the account manager is accountable for the work that the business architect is responsible for developing.

A well-developed business architecture function can bridge the gap between business and IT, providing IT with a comprehensible perspective into the business goals, priorities, and operations to inform IT investments. Moreover, this perspective can enable the opportunity to discuss how information technology can create transformational opportunities and competitive advantage for the business.

If McKinsey’s recommendation that adapting to the “new normal” requires a stronger linkages between business and IT, then business architecture is a vital enabler to make it happen.

Rethinking Business Value

In my first post, I asked the question – “what constitutes business value?” I argued that it’s not simply delivering what the client asks because sometimes the client doesn’t have the right perspective. Most of my clients begin their conversation with me by talking about their IT problems. These conversations are typically characterized by the focus on IT systems and the immediacy of the need - they need better functionality from their CRM solution to remove some manual step or they need a specific report. In an order-taking IT organization, we might promptly write down the requirement and try to figure out when we will slot it into a release calendar. The customer’s requirement is heard, understood, and a plan is presented for meeting the requirement. This provides the customer with the value they’re looking for, right?

What’s missing from this conversation, in my mind, is context. Why do they need this particular report or functionality? What is the business goal that they are ultimately driving towards? If we have a good relationship with our clients, we may already know the answer to this question. There are others, though, that we need to have good answers for such as what are the other goals that the business is driving? Over what time horizon? How does this goal or requirement stack up against the others?

Absent a strong understanding of the business goals, strategies, and priorities, information technology organizations risk limiting the value they bring to their business clients.  Deloitte’s Center for the Edge recently published results from their “Shift Index” which found that while labor productivity has more than doubled in the past forty years, return-on-assets have declined by 75%. The researchers point out that much of the capital investment made by companies in the past forty years has been in information technology leading them to the conclusion that IT has failed to deliver significant value. Deloitte hypothesizes that "technology investment... has been overly focused on an industrial-era model. 'It’s been all about standardization and automation of business processes... Until and unless companies learn how to harness knowledge flows, the impact of the technology will mainly be continuing competitive pressure.”

Anecdotally, I have found this to be true. Many IT planning meetings with business clients amount to identifying manual processes and targeting them for automation, irrespective of the value that such automation might bring. The key success measure for one of Microsoft IT’s major strategic programs is being measured in labor productivity. While this isn’t inherently wrong, the question remains, can IT deliver greater value to its customers?

Most non-IT senior executives believe so. A McKinsey & Company survey (registration required) found that while most were satisfied with the ability of their IT divisions to provide basic IT services such as email, workstations, office productivity software, etc., what they found lacking was IT’s ability to provide transformative new business capabilities and innovation. These executives believed that IT was overly focused on creating greater efficiency – a view echoed by many IT executives who were also surveyed by McKinsey.

I am suggesting that IT leaders set a high bar for delivering business value – not just incremental improvements in productivity, cost reduction, and efficiency but significant, transformative changes that leverage the full potential of IT as an engine of the business to achieve its goals and objectives. IT organizations that can accomplish this are ones that have strong understanding of how the business functions and visibility into their clients’ strategy and goals.

This is no short-term journey for most IT organizations. This can involve a major paradigm shift in how we think about the relationship between IT and our business clients; it means changing how we think about the process by which we engage the business in strategic and investment planning; it involves skill sets that are not traditionally found in IT organizations.  In my next post, I will describe a planning framework that can be used to translate business strategies into investment plans.

First, Some Context

Before digging in, I think it’s important to set context. I am a business architect for Microsoft’s internal IT organization, also known as MSIT. MSIT is made up of three key organizations- the solution delivery group, the engineering group, and a services/operations group.

I work in the solution delivery organization, whose function is to provide account management between the business and IT, to facilitate and drive the planning of the IT investment portfolio, to gather business requirements and deliver them to our engineering group, and to otherwise ensure successful delivery of IT to our clients. The engineering organization, which is made up of both business aligned and non-business aligned teams, is responsible for the system development and enhancement while the services/operations group is responsible for running the infrastructure, handling service requests. The shorthand understanding of the difference between groups is Plan, Deliver, Operate.

The solution delivery groups are aligned to particular businesses or business areas; my solution delivery organization supports five sales and marketing lines of business. As with most large, global businesses, their business maturity and the relationship our IT group has with them is varied. While most of our group is focused on account management and business analysis functions, I work on a team whose responsibility is to develop strategic and investment plans for all of our business clients.

How Microsoft funds IT has a significant impact on my role and the dynamics of the business-IT relationship.  IT’s budget is set at the corporate level and doled out across several funding governance bodies. The governance bodies are made up of senior leaders from business and IT organizations. These committees are chaired by the solution delivery leader – my general manager. Although all of our business clients are represented on the governance committee, not all of them have a seat at the table when decisions are made about how funds get allocated. As you might imagine, this can cause some friction in an environment where IT budgets are static or shrinking and there is more demand than investment dollars for supply.

My organization and the governance body that we facilitate operate from the premise that there is enough similarity in IT needs of our clients that we can create systems that are shared by two or more businesses. My team is focused on answering the question – how can we drive the most value from our IT portfolio? Where should we build for economies of scale versus creating capabilities that are specific to the needs of a particular client?  How do we decide which investments will deliver the best results? Hopefully these are questions that resonate with you – how we tackle this question is the subject of this blog.