Avoid the PowerPoint-to-Execution Gap: Strategists as Operators

by

Reading a point-of-view piece by Cynthia Montgomery in Rotman Magazine reminded me of a soapbox tweet of mine: “we need to value execution on par with creation”.

That tweet was inspired by a consultation I did on a critical project that had fallen into the PowerPoint-to-Execution Gap.

This project made all the right upfront moves: defined a bold, yet attainable business vision, rallied executive support, hired a top talent technology consultancy, and hand-picked a skunkworks team.

Upon completion of the upfront, they had a well-defined business problem (process, requirements, data, roles), which would be supported by a state-of-art technology architecture. The creation portion was top-notch. 

The problem was that company and project executives assumed that execution would take care of itself. They didn’t recognize that there is a strategic element to execution, involving not just scheduling, but careful packaging and orchestration of development, delivery, acceptance and business transformation activities.

In her Rotman piece, The Role of the Strategic Leader, Montgomery speaks to the often missed leadership component in strategic work, the “ongoing responsibility of leading strategy”.

“A great strategy, in short, is not a dream or a lofty idea, but rather the bridge between the economics of a market, the ideas at the core of a business, and action. To be sound, that bridge must rest on a foundation of clarity and realism, and it also needs a real operating sensibility.”

To illustrate her point, Montgomery — a Harvard Professor — describes how her MBA and Executive Education students inevitably debate the importance of strategy versus execution:

“Every year, early in the term, someone in class always wants to engage the group in a discussion about what’s more important: strategy or execution. In my view, this is a false dichotomy and a wrongheaded debate that the students themselves have to resolve, and I let them have a go at it.”

Montgomery revisits that early term debate with a real-world case on Gucci:

“I always bring that discussion up again at the end of my course, when we talk about Domenico De Sole’s tenure at Italian fashion eminence Gucci Group. De Sole, a tax attorney, was tapped for the company’s top job in 1995, following years of plummeting sales and mounting losses in the aftermath of unbridled licensing that had plastered Gucci’s name and distinctive red-and-green logo on everything from sneakers to whiskey — in fact, on 22,000 different products — making Gucci a cheapened and overexposed brand.

De Sole started by summoning every Gucci manager worldwide to a meeting in Florence. Instead of telling managers what he thought Gucci should be, De Sole asked them to look closely at the business and tell him what was selling and what wasn’t. He wanted to tackle the question “not by philosophy, but by data” — bringing strategy in line with experience rather than relying on intuition. The data were eye opening. Some of Gucci’s greatest recent successes had come from its few trendier, seasonal fashion items, and the traditional customer — the woman who cherished style, not fashion, and who wanted a classic item she would buy once and keep for a lifetime — had not come back to Gucci.

De Sole and his team, especially lead designer Tom Ford, weighed the evidence and concluded that they would follow the data and position the company in the upper middle of the designer market: luxury aimed at the masses. To complement its leather goods, Ford designed original, trendy — and, above all, exciting — ready-to-wear clothing each year, not as the company’s mainstay, but as its draw. The increased focus on fashion would help the world forget all those counterfeit bags and the Gucci toilet paper. It would propel the company toward a new brand identity, generating the kind of excitement that would bring new customers into Gucci stores, where they would also buy high-margin handbags and accessories.

To support the new fashion and brand strategies, De Sole and his team doubled advertising spending, modernized stores, and upgraded customer support. Unseen but no less important to the strategy’s success was Gucci’s supply chain. De Sole personally drove the back roads of Tuscany to pick the best 25 suppliers, and the company provided them with financial and technical support while simultaneously boosting the efficiency of its logistics. Costs fell and flexibility rose.”

The lesson from the Gucci case, according to Montgomery is clear:

“The only way a company will deliver on its promises, is if its strategists can think like operators.”

Montgomery continues:

“In effect, everything De Sole and Ford did — in design, product lineup, pricing, marketing, distribution, manufacturing, and logistics, not to mention organizational culture and management — was tightly coordinated, internally consistent, and interlocking. This was a system of resources and activities that worked together and reinforced each other, all aimed at producing products that were fashion forward, high quality, and good value.

It is easy to see the beauty of such a system of value creation once it is constructed, but constructing it isn’t often an easy or a beautiful process. The decisions embedded in such systems are often gutsy choices. For every moving part in the Gucci universe, De Sole faced a strictly binary decision: either it advanced the cause of fashion-forwardness, high quality, and good value — or it did not and was rebuilt. Strategists call such choices ‘identity-conferring commitments’, and they are central to what an organization is or wants to be and reflect what it stands for.”

Returning to the student debate (and the PowerPoint-to-Execution Gap):

“When I ask executives at the end of this class, “Where does strategy end and execution begin?” there isn’t a clear answer — and that’s as it should be. What could be more desirable than a well-conceived strategy that flows without a ripple into execution? Yet I know from working with thousands of organizations just how rare it is to find a carefully honed system that really delivers. You and every leader of a company must ask yourself whether you have one — and if you don’t, take the responsibility to build it. The only way a company will deliver on its promises, in short, is if its strategists can think like operators.”

Successful strategy demands execution excellence, which starts with an execution strategist. Or, if you are lucky, with one of the rare strategists who think like operators.

Beautiful things happen when we work together #openwork

by

So why do we allow our the organisations we create to stifle collaboration, communication and openness with silos, politics and poor communication?

A few weeks ago i blogged the seeds of some thinking around the concept i’m referring to as #openwork In a series of upcoming blog posts i’ll be breaking these thoughts down into something more concrete, a manifesto for openness at work.

If this is an area that resonates with you i’d love to comment on my tumblr or @bakedidea

Bye for now

Categories Uncategorized

What is Business Architecture?

by

By Allen Brown, President and CEO, The Open Group I have heard and read the opinions of a number of people about what is Business Architecture, as I am sure many of us have but I wanted to understand it from the perspective of people who actually had Business Architect in their job title.  So … … Continue reading →

The “Right” Representation of the EA Value Cycle

by

In the world of Enterprise Architecture, we are still creating “shared” understanding of how to tell our stakeholders what we do.  There is no consistency in our diagrams or our descriptions just yet.  This post will discuss the different ways we present the value stream of Enterprise Architecture and will attempt to select a particular viewpoint that can be useful for the majority of situations.

First, let’s address the most commonly shared representation: TOGAF.  The TOGAF ADM model illustrates a sequence of activities that starts with a preliminary phase and works its way through each of the levels of architecture.  Basically, TOGAF illustrates a straight-through process from phase A through phase H to develop and use architecture. 

 image

First off, I’m no huge fan of this illustration.  I always wondered how you get to an architectural vision prior to considering the architecture of the business.  Also, the notion of a center point focused around requirements management feels weirdly tactical.  At the level of an Enterprise Architect, I’m dealing with strategies and measures of success.  At the level of a technical architecture, the word “requirements” has an altogether different meaning.  Grouping together the notion of “strategic needs” with “technical requirements” may make sense to a technologist, but I don’t know a single business stakeholder of EA that would agree with grouping those two rather distinct things. 

Who is our audience?

These observations bring me to my first key consideration: If we want to communicate the value stream of Enterprise Architecture, we first should consider the audience, “who are we communicating to?”  If we are communicating to a stakeholder of EA, we should show them the bits of EA that are relevant to them, and we should not show them the bits that are not. 

It is not cynical to gloss over the complex bits of EA when talking to a business stakeholder… it is practical.  In fact, we do it all the time.  If you buy cable TV services, a person from the cable company may come to your house and install a coax cable to your home.  He will mess around with a cable box for a few minutes, and then, if you are lucky, he will show you how to do simple things like changing channels and recording your favorite shows.  Then, he’s off.  He does NOT spend an hour describing the various technical aspects of signal transmission and digital carrier signals.  Why should he?  You don’t care.  You want to watch TV, not get a degree in electrical engineering.  And the same applies to EA.

Secondly, if we want to communicate EA, let’s recognize that different people interact with Enterprise Architecture in different ways.  Business stakeholders will interact with Enterprise Architecture to ensure that their strategies are being executed effectively, with minimal interference, and producing a result that considers things like security, cost of ownership, and the ability to cope with rapid changes in the marketplace.

Recap:

  1. We have to care who we are speaking to, and we have to reflect the things that they care about.
  2. We have to show them the details that matter to them and obscure the details that don’t.
  3. We should illustrate the activities in the context of the processes that they understand, and not at a conceptual level that may be difficult to relate to their daily experience.

 

The ADM from TOGAF is an odd bird, because it attempts to be all things to all people.  It represents EA in a way that every stakeholder can use, but honestly, no stakeholder can use it.  It is not wrong.  Far from it.  But it is not useful because it violates every single one of the rules above.  The ADM reflects the EA viewpoint, but not the viewpoint of the customers of EA at a level that they can grasp, understand, and most importantly, use.  So let’s keep the ADM in our court, and create a view of the EA process that is relevant to our stakeholders.

So who are our stakeholders?  For the sake of this post, I’m going to select one set of stakeholders and ignore the rest.  Is that correct?  Nope, but it is practical for a blog post.  What this means is that the rest of this post produces an answer of the “right” representation only for one class of stakeholders… another representation would likely be needed for different people.  That is the nature of EA.  Let’s not fret it.

Stakeholders: Non-technologists

There is a widely held view in Enterprise Architecture that an EA must be technically savvy in order to be effective.  There are certainly business architects who are quite effective who are not technologists, but in order to move UP to the notion of an EA (which includes business architecture, information architecture, solution or application architecture, AND technology architecture), you would need to be technically capable. 

I won’t belabor the point about whether it is correct to view Business Architecture as a subset of Enterprise Architecture.  It is the wildly predominant view.  (A poll that I put on LinkedIn that asked this question found that well over 80% of EA respondents agree that EA generally includes every aspect of business architecture.  That’s pretty overwhelming.)

That said, our biggest struggles in EA rarely involve conversations with other architects.  While there may be a great deal of confusion, there is rarely a lack of buy-in for architecture among architects, or even technologists.  Our key challenge, when it comes to communication, comes when we are talking to non-technologists.  In other words, the proverbial “business” stakeholders of EA.  (Please don’t flame me about whether IT is part of the business or not. That is a useful conversation, but it is outside the scope of this post).

Therefore, for the rest of this post, I will focus on the non-technology stakeholders of Enterprise Architecture.  These are people whose chief concerns are not technical concerns.  We could say that they care about financial performance, role clarity, cycle time, cost effectiveness, market position, revenue growth, opportunity costs, business drivers, and many other factors outside the realm of technology concerns.  People in this category include senior business leaders (CEO, COO, CFO, CIO, CMO, etc), as well as business unit leaders (General Managers, Sales Division Leaders, Product Development and Marketing, Customer Service, Online Services, etc). 

In order to communicate directly and well to these folks, lets recognize that they don’t care about the aspects of architecture that are technology focused.  While the WANT good technology, and will BENEFIT from good technology, they will assume that the technology issues can be handled effectively without bothering them with details.  To refer to our previous metaphor, they want the cable company to handle the technology, so that they can deal with changing channels.

So, let’s take the ADM, and trim out the stuff that non technologists rely on, but don’t need to have a conversation about.  They assume it is there.  That includes the preliminary stage, as well as architectural vision, requirements management, information systems architecture, technology architecture, and architecture change management.

The ADM now looks a bit different.  In fact, we can put it in a single row with a looping arrow.  Note that, in TOGAF, the Business architecture phase includes both current state assessment and future state modeling.

image

Representing the processes of the non-technical stakeholder

We have removed the confusing bits from the view of the non-technical stakeholder, but it is tough to say that we are at the point where we are relevant.  After all, the non technical stakeholder has a business process that he uses when working with changes to his or her business.  We are not representing that process. 

The process, frequently described in dozens of bits of EA literature, starts with an understanding of the current situation within the business.  Then, when the business creates a strategy, we bring these two bits of information together (current state and strategy) to create a vision for the future.  This is the order that the non technical stakeholder may recognize… not the generalized view of the ADM.  So it is time to break apart and rearrange the bits a little bit.  I will now step away from the “crop circles” representation since it is so far out of the experience of people who describe business processes.

image

In this view, we can begin to see the steps that an Enterprise Architect would perform that are visible to a non-technical stakeholder.  Just for the sake of clarity, this doesn’t mean that the technical steps are absent… it just means that our technical efforts don’t have to be paraded around in front of our non-technical stakeholders. 

Note that I relabeled the ADM steps. 

  • Business Architecture becomes Current State Evaluation, and Strategy Development
  • Opportunities and Solutions becomes Future State Modeling
  • Migration Planning becomes Roadmap Development
  • Implementation Governance becomes two things: Funding and Initiation (the Project Portfolio Management aspects) and Oversight and Governance (the governance of ongoing activities).
  • Architecture Vision is cut down to only the elements relevant to the non-technical stakeholders: the evaluation of the current state of the enterprise.

 

Let me point out that the TOGAF process assumes a different order of activities than the diagram above.  From the standpoint of the stakeholder, this is what makes sense, regardless of how TOGAF describes the stages.  This is why I’m no big fan of TOGAF as a methodology.  It doesn’t reflect reality.  On the other hand, the elements above are fairly well understood. 

Also note that I’m not saying that the substitutions listed above are equivalent.  In fact, I’d argue violently that Business Architecture is far more than Current state evaluation and Strategy Development.  However, from the viewpoint of the non-architect, business architecture is a process that is involved with the development of business models (current and future), and that’s about it.  There is a great deal of effort that is not seen by the stakeholders.

In other words, the blue model above is only showing the tip of the iceberg, and relabeling the phases according to what is (approximately) visible, not what is actually there. 

This is an important part of explaining an activity to a stakeholder, and it is a skill that every Enterprise Architect must get good at.  You have to explain your activities in the context of what a stakeholder understand and recognizes… not in the context of all your work.  It’s not about you. It’s about the stakeholder.

 

The Rules of Value Streams

There are a few problems with the view above.  In order to understand the problems with that view, let’s mention a couple of rules for representing a value stream.  We will use these concepts because the ability to describe EA in terms of a value stream is important.  Value streams are sticky… they are easy to remember and easy to relate to.  If we want to remove the barriers to adoption of EA, we could do far worse than using this technique.  That said, there are some rules that we have to keep in mind:

  1. A value stream does not illustrate dependencies that are not really there.  Parallel efforts should be represented as parallel if that would improve understanding of how value is created.
     
  2. The value stream is illustrated as a sequence of high level processes in a straight line from left to right.  That said, a value stream must start with an event that is relevant to the customer who gets value.  It must end with the deliver of that value.  Any activity that is not part of that flow (from relevant starting point to value) should be represented “above” or “below” the value stream.  
     
  3. A value stream should be illustrated in its fully operational state.  In other words, it should describe a process that is running, not one that hasn’t been created yet.  Events that are relevant only for “start-up” activities can be included, but should not be the primary focus of a value stream.

 

So let’s apply rule #1.  Is it true that the current state of the organization actually feeds the development of strategy?  No.  In fact, the evaluation of the current state can happen completely in parallel to the development of business strategy. 

So the diagram could look like this one.

image

Here, we can see that there are, in fact, parallel activities for the understanding of the current state of the enterprise, and for the development of business strategy.  Where they first intersect is in the development of the future state (the opportunities and solutions phase from the ADM model).  You need both an understanding of the current situation and the needs of the future in order to describe where the organization should move towards. 

Now, let’s apply rule #2.  What is the event that the business considers to be relevant to start the value stream of Enterprise Architecture?  The Development of Business Strategy, of course.  So the flow should perhaps look more like the diagram below… (note, the arrows and activities are identical to the one above… the only thing different is the order on the page).

image

Now, let’s apply rule #3… that one is easy.  The arrow at the bottom that says “First TIme EA” can simply be dropped.  After all, the first time a process is run, it starts from somewhere.  It is simply irrelevant to the non-technical stakeholder to point out where that starting position is. 

Exception: if you run Enterprise Architecture as a consulting arrangement, you may want to leave that arrow in there.  After all, you will need to illustrate where the consulting arrangement will start.  That said, I have found that fewer and fewer EA initiatives begin with the hiring of a consulting firm. 

Providing context

When we started with the ADM, we assumed that there was a 700+ page methodology and framework behind the image, describing each step and what is included.  However, your stakeholder will not read the TOGAF or any other 700+ page body of information.  That would be absurd.  You need to add a little detail to the image to describe what is in each of these stages.

It’s also a good idea to “clean up” the diagram a little so that we use less space on the “arrows and boxes” and more engagement on the ideas of what is going on.  So the next modification of the process looks like this:

image

This diagram is a better one for informing the non-technical stakeholders of your Enterprise Architecture program about what it is that you do.  We remove a little of the “accuracy” about where an arrow starts and ends, but we add a great deal of context about what is happening along the way.

The “backward” arrow along the bottom clearly indicates that there are activities that flow outside the value stream but which are needed for each repeat of the cycle. 

Final words

Is this a perfect representation of the EA process?  I don’t believe in perfect things… just useful things.  But it is better, in my opinion, than showing a non-technical stakeholder the ADM or one of the “box and arrow” models above.  It uses the visual language of value streams and business process models, both widely recognized and used in business interactions.  It explains itself without going into a lot of detail.  And it clearly describes the end to end flow without restricting or dictating where Enterprise Architects start and stop (an important requirement, since maturing EA programs will change their scope as they mature).

I have shown this view to others, and some have wondered about the “backward flowing” process along the  bottom.  The alternative to showing something as “backward flowing” would be to illustrate it as a cycle (with arrows feeding “in” from the right and “out” from the left).  If it is a challenge for you to view the diagram without those arrows, I apologize.  I’d love to see other view of this model that illustrate the “cycle” in a way that still meets the “rules of the value stream” as discussed above.

I’d love to get feedback and insight from the community.  What do you think?  Does the last image above resonate?  What would you do differently?