Strategy and Planning Service as an Enterprise Architecture Offering

As mentioned in a previous post, I announced that our Enterprise Architecture team has made some very interesting investments in the area of Strategy Management and Portfolio Management in the last year via an Enterprise Architecture offering called “Strategy and Planning Service”. It’s very interesting and we’ve gathered enough experience through our mistakes and successes that I think I’m ready to share more on it to the broader community to help others. Keep in mind that we are relatively new to this area and learning more every day so I might change my opinion on some things. Here’s what I currently think.

As a bit of background, our investment in Strategy Management and Portfolio Planning is a result of our team’s need to understand Microsoft’s business strategy and connect it to changes in our enterprise architecture to inform project portfolio managers to fund the right projects and include the right scope in the funded projects. The result is an accelerated change in our architecture streamlined to achieve our corporate strategy.

We’ve decided to provide an offering from Enterprise Architecture team that essentially is a template to implement an Office of Strategy Management concept at particular areas in our enterprise. The template heavily leverages Kaplan and Norton’s Office of Strategy Management concept but is enhanced to include bits to support Strategy Formulation and Portfolio Optimization to bring an end-to-end offering for Strategy Management and Portfolio Management - one without the other is a waste of time in my opinion. We also embedded into the offering concepts to help derive platform strategy and other important Enterprise Architecture concerns like Strategy Formulation, Business Model, Operating Model, Core and Context Processes, etc. Anyway, I wanted to share with you some important details we’ve learned so far:

1. Be able to model business strategy to span the enterprise. It’s common practice to consider business strategy as scoped to a particular revenue-generating business (for not-for-profit businesses, the scope of a business strategy is often the ‘services’ they offer.) This is an awfully narrow portion of any enterprise because it doesn’t include operational businesses like Finance, HR, Sales, Support and IT. For example, Microsoft Office has a business strategy but IT wouldn’t according to common practice. With a couple of tweaks to the discipline of documenting a Business Strategy as well as make the assumption a Business is equivalent to an organization responsible for a P&L, we can connect all organizations to a cascaded business strategy that spans all organizations in an enterprise. Of course, there are several methods out there to do this. We have chosen Balanced Scorecard as a format to capture a business’ strategy in my group for a number of factors. I don’t presume this is the right choice for everyone. Anyway, using the Balanced Scorecard, we’ve implemented a process discipline of connecting Business Objectives in the Customer Perspective to a supporting organization’s Stakeholder Perspective’s Business Objectives, we get a natural cascade model that connects organization’s business strategy together. This is a rule of thumb to start with – it doesn’t always work. We sometimes have to apply some human review to modify a child’s business strategy to make it more complete while always keeping an association to the parent Business Strategy as a matter of principle.
2. Provide value-add support to Portfolio Planning to gain adoption. In order to be involved in the planning process, Enterprise Architects need to come with some sort of value proposition. We’ve built a data model to help provide the following value propositions to our planning process:
   • Data Quality. We provide quality data to the planning process facilitators that offers the following value propositions:
     • Strategy gaps, overlaps, dependencies and conflicts. This is my favorite value proposition because it was fun to formulate the data model to deliver on the promise. I also like it because having the ability to maturing strategy to the point where we can manage across the enterprise is a direct hit to being able to drive the necessary changes in our enterprise architecture to accelerate the company’s ability to deliver on strategy.
     • Providing a system with an implicit data model that forces data-entry to be consistent and of high-quality. This is important to those who are responsible for quality of the information managed in the planning process. For example, we can monitor the completeness of a Balanced Scorecard to ensure Goals exist with Objectives for all Perspectives.
   • Portfolio Prioritization. We provide guidance how portfolio managers can identify criteria to prioritize their portfolios. Essentially it’s advice how to choose business objectives from the business strategies,  how to weight them, how to associate new program demand to weighted criteria, how to analyze the results and compare against industry benchmarks, and, most interestingly, how to evaluate the prioritization criteria to effectively represent the charter of the portfolio itself.
   • Portfolio Optimization. We provide enterprise architecture analysis to look for possible portfolio optimizations such as;
     • Roadmap alignment. this is where traditional enterprise architecture work is leveraged. That is, many enterprise architecture teams develop plans for how to build out platforms, competencies, capabilities, processes, etc. Assuming those roadmaps are ‘effective’, we plug them into the planning process’s optimization activities. This is one simple way of gaining adoption of these types of enterprise architecture deliverables.
     • Strategy alignment proof through traceability of Programs to business objectives of the various business strategies.
     • Program rationalization through redundancies discovered via common processes being produced by different Programs.
     • Program dependency analysis based on shared application, platform and information to help ensure we fund all dependent Programs for other priority Programs.
     • Reuse of standard applications and platforms to ensure are in scope for programs to avoid building redundant apps and plats.
     • Possible organization adoption for program building solutions that might be useful by other organizations not currently in scope.

One really important note is that we heavily rely on our information model to deliver the above points. Getting this right is the secret sauce, the science if you will, to delivering on the above value propositions.

I’d like to tell you more about the Strategy Management and Portfolio Planning architecture work we are doing such as our Organizational Alignment, Team Model, Process Model, EA reference models, multitude of business concepts, etc but I’m not entirely confident we’ve cracked the nut on them just yet. Sharing what we have today may cause more confusion than value so I’ll wait until they are a bit more refined before sharing.

Comments

• Anonymous
  February 03, 2011
  good article.  thanks

• Anonymous
  February 04, 2011
  I like this direction a lot. I've experienced many benefits combining EA with Balanced Scorecard, especially in traceability. I've shared some findings two years ago, published by ISACA - http://bit.ly/c9nfne (my framework evolved since then but the basic tenets are the same) Apart from traceability, there is a good way to calculated KPI's from the structures of the EA repository. I believe the next step is to go beyond bridging the Business-IT gap: www.strategicstructures.com I'm looking forward to see the results of your work when you find it refined enough to share. (Well, I'd prefer it in an earlier stage, but... :) )

• Anonymous
  February 08, 2011
  @ Ivo, Thank you for your comments. I've ready your ISACA article and, in fact, it helped inspire me to continue my learning of the BSC and it's usefulness to help aligne IT to the business a year or so ago. I think you are a thought leader in this space and I appreciate your sharing your ideas with the rest of us. :) Regarding the strategic structures article, I haven't read that one before but just did due to your reference. I think the topic is very interesting but I'm not sure it's as accurate and precise as it needs to be in order to be ready for implementation. It could use a bit of the science (like you provided in your ISACA article for example) as well as a dose of adopting business strategy management for large enterprises taken from business management disciplines so that it can be ready to help IT change at the rate it needs to in order to mature from 'relating it to the business' to a stronger alignment of IT to the business specifically where much of what is IT of today is actually embedded into the business of tomorrow. Anyway, I commented on the article to explain more of what I'm talking about. Perhaps, we can all share our thoughts on that topic some more. Thanks again. Gabriel