Gabriel Morgan

Business Performance Management, the next big thing…again

2012-11-18T18:00:00Z

We all possess the gene to want to solve problems when faced with them. It’s human nature. People form organizations and this gene sometimes manifests itself in organizational titles and roles invented to address organizational challenges. This is natural too. For example, when support organizations face the challenge of aligning to business organizations, we see them create new job titles like Business Architect or Enterprise Architect. When business organizations face challenges to influence support organizations to align to their business strategy, we see them create new titles like Operations Manager, or Development Operations Manager or Systems Support Manager. These are strong signals that organizations are investing to improve alignment, which is great however without a common process model for these titles to engage in, progress is limited.

Enter the Business Performance Management (BPM) process. BPM is a process designed to bring alignment across all organizations in a company, regardless of size, in terms of business strategy and project portfolios. For this reason, I believe BPM is one of the most important processes out there for folks interested in achieving ‘alignment’. Interestingly, I come across many people unfamiliar with Business Performance Management so I thought I’d take the opportunity to provide an overview of BPM and help bridge some gaps.

Let’s start with a definition. Wikipedia’s current definition is a good place to start (see here); “Business performance management is a set of management and analytic processes that enable the management of an organization's performance to achieve one or more pre-selected goals. Business performance management has three main activities:

selection of goals
consolidation of measurement information relevant to an organization’s progress against these goals, and
interventions made by managers in light of this information with a view to improving future performance against these goals.

… balanced scorecard is often used as the basis for business performance management activity with organizations.”

To execute a world-class implementation of BPM that resonates with business organizations and support organizations, that isn’t too complex, that can directly manage project portfolios, and resonates with people, we need to be a bit more specific. Here’s a diagram I’ve used to describe BPM in a bit more detail.

The key takeaway message of my diagram above is that BPM is a synchronization mechanism between business strategies and portfolios across a company. BPM processes deliberately ensure the business strategy reflects what business success looks like and is responsive to market forces and internal forces (by the way, “forces” refers to concepts from PESTEL and Michael Porter’s 5-forces model.) BPM processes also ensure project portfolios are responsive to business strategy changes as well as are optimizing portfolio delivery health.

It’s no coincidence that Business Strategy Management and Portfolio Management processes directly relate to BPM. Business Strategy relies on execution through projects because projects equate to strategy execution. Portfolio Management require objectives to be reached, hence the need to tie project achievement to business objectives. BPM ties these two together.

Now, imagine having implemented BPM processes in your organization, the perfect planning meeting staffed by the organization’s leadership might have the following agenda:

Review Business Performance. The chair of the meeting would pull up their handy-dandy organizational scorecard and review any changes in their scorecard as a result of market changes or changes in measures of success for their internal stakeholders. Then, manage-by-exception by reviewing any missed targets. The results of this review would result in adding line items to the meeting’s Action Plan normally related to updating business objectives or KPI Targets and/or shifting project scope to ensure execution adopts these changes.
Review Portfolio Performance. The chair of the meeting would then pull up their project portfolio health report to take note of any in-flight projects that have missed their targets in terms of on-time projections, on-budget projections, delivery quality, or risk. The discussion would also include a scan of any downstream dependency projects that have failed and impact their project’s ability to deliver. And finally, the meeting attendees would discuss any budget loss or favorability changes to drive a conversation of what to cut or fund as a result. The results of this review would be adding line items to the meeting’s Action Plan related to changes in the project portfolio.
Process New Demand. To ensure continuous improvement, the last agenda item of the meeting would be to process new project proposals that promise to deliver greater business value, faster and at a lower cost than the current funded projects. The chair of the meeting would review new business cases per their demand management process and if any new project proposal is approved, the portfolio is reshuffled and the Action Plan is updated.

Here’s a diagram I’ve used to describe such a planning meeting.

The outcome of such a meeting is an up-to-date business strategy connected to all relevant support organizations with optimized project portfolios to achieve it. That’s business performance management.

The Planning Paradox

2012-11-14T22:39:10Z

One of my uncle’s favorite jokes goes like this:

Greg: “Hey Gabriel, say to me ‘what’s the most important thing about humor?’”

Gabriel: “Okay Greg, what’s the mo-“

Greg: “Timing.”

[At this point, you’re supposed to laugh]

“Timing” is the most important thing to business strategy planning

As it turns out, timing is also the most important thing to support business performance management in terms of managing scorecards and synchronizing them with their project portfolios across a company.

Organizational Hierarchy Strategy Alignment. Organizational Hierarchy Strategy Alignment is the linkage between organization’s scorecards and budgets based on an organization’s hierarchy. The head of an organization’s scorecard and budget links to its children’s organizational scorecards and budgets forming a pyramid-like structure of strategy alignment like the illustration below.

Value Stream Strategy Alignment. From a business strategy perspective, there are two types of organizations in a company; Business Organizations and Support Organizations. A Business Organization is an organization that is responsible for a product with scorecard KPIs related to market share, revenue and customer satisfaction.. All other organizations in a company are Support Organizations with scorecard KPIs related to cost, productivity, quality and risk. Business Strategy is set by the Business Organizations and Support Organizations mobilize to enable them, ideally in a sequential flow based on the Product’s value stream (aka core value stream, value chain and operating model). That is, organizations that deliver a product define their scorecards to express what success look like normally using KPIs like “units delivered”, “revenue received”, “customer satisfaction”. Then, working back up the value stream, Support Organizations determine how to sell the product to hit the desired success targets set by the deliver organization. Then, Support Organizations that market the product define KPIs on their scorecards to express what success looks like to hit the sale’s organization’s KPI Targets. Of course, not all processes are directly involved in the core value stream. Support Organizations that support customers, invoice/bill customers, hire people, manage partners, etc all have an enabling/support role and should work back from the core value stream process to determine what their success looks like based on the organization’s processes that they support. Here’s an illustration of a business strategy cascaded via value streams.

The Planning Paradox

More common than you think, organization’s use a planning schedule to arrive at organizational scorecards and budgets that starts at the top of an organizational hierarchy and flows down from there. The problem is that organizations are rarely organized by value streams. In situations where the Business Organization is a sibling organization to Support Organizations, they both have to produce their scorecards and budgets at the same time forcing Support Organizations to scramble to discover the Business Organization’s strategy to then set their own scorecard for success and the budget necessary to achieve it. Even further, there are times when Business Organization functions report to Support Organizations forcing the Support Organization scorecards and budgets to be set before the Business Organization can declare what they need to be successful. In my experience, this situation causes several intense activities in brief stints that ultimately result in a undocumented alignment of business strategy leaving open the possibility of gaps, overlaps and conflicts in plans to execute the business’ strategy.

To add to the problem, it’s also worth mentioning these challenges posed when business strategy is poorly aligned:

Lack of ability to perform impact analysis to make upstream groups aware of dependent projects slipping/failing to set expectations
60% of Organizations don’t map Organizational Scorecard KPIs to funded projects *
66% of HR and IT organizations have no link to the business strategy *
70% of middle manager’s and 90% front-line employee’s compensation not linked to the business’ strategy *
95% of employees in most organizations do not understand their business’ strategy *

* Harvard Business School, 2006, “The Office of Strategy Management”, http://hbswk.hbs.edu/item/5269.html

Business Architect Skills Assessment

2012-11-13T03:37:29Z

Six years ago I posted a blog article called Solution Architect Skills Idea. At the time, I was a practicing Solution Architect pushing the boundaries to mature the Solution Architect discipline. I built the Solution Architect Skills Assessment to help organize the skills I felt were necessary to be a world class Solution Architect and used it to mentor folks interested in growing their Solution Architect skills. The skills taxonomy was later used to help form IASA’s Solution Architecture skills profile which, I think, is still used today. Funny, I still get contacted regarding help with Solution Architecture skills because the Excel workbook I used to store the skill information was passed around with my name still in the document author properties. Because of the viral use of the skills taxonomy and feedback from folks tell me how useful it was, I consider it a pretty good success.

Anyway, a few years ago, I shifted professions into a Business Architect role and have learned tons. I now know enough through learning from business management experts and through my own practical experience that I feel comfortable helping others in the area of Business Architecture. I’ve even begun to accept a few mentees and am using the Business Architect Skills Assessment to shape their learning roadmap. The feedback is very positive so I thought I’d share it on my blog. Keep in mind that it is only a start that needs maturing. I’ll try to keep it current with my personal copy as time goes on.

I hope the Business Architect Skills Assessment proves useful to you too: Gabriel’s Business Architect Skills Assessment workbook

How do you reward failure?

2012-07-24T03:51:00Z

I was a participant in a recent survey facilitated by the Corporate Executive Board’s Enterprise Architect community forum regarding “How do you reward failure?” My response to the survey triggered a bunch of emails from other members to me noting how much they liked my response so I thought it might be worthy to share on my blog.

I've played various portfolio management roles here in Microsoft ranging from portfolio management to project delivery in Business organizations and Business Support organizations. The roles I’ve performed are Portfolio Manager, Business Architect, Enterprise Solution Architect, Solution Architect, Program Manager, and Project Manager. Each of these roles have responsibilities to encourage/reward failure early in the lifecycle of any project. The assumption I have for rewarding failure is to encourage canceling in-flight projects that won’t deliver the intended business value and save the organization time and money to re-invest in projects that deliver greater business value. Here’s how I’ve done it:

As a Portfolio Manager: Every portfolio has project failures. The trick is to find them and kill them early. I only measure failure if a project team failed to meet defined KPI Targets once they have passed a Baseline milestone. The assumption here is that post a Baseline milestone, the project’s Steering Committee and project team have accepted all risks and committed to moving forward to deliver a solution to the defined project KPI Targets normally captured in the project charter. I celebrate project cancellations by communicating to the team and to the steering committee via a 'thank you' note describing how the team made one of the most difficult decisions possible and for all the right reasons. I usually tailor an email describing how the cancelation saved the organization time and money by not moving forward with a solution that wouldn't deliver to use the maximum business value and that we can now re-focus our efforts on a more ‘strategic’ solution opportunity. By the way, ‘strategy’ refers the project charter’s defined KPI Targets that directly associate to a Business Organizations or Business Support Organization managed by business performance management processes. See here for details. Another important point in this role is constantly prioritizing the project portfolio based on business strategy (ie prioritized business objectives) and canceling projects that now fall below another project investment that delivers greater business value within a given budget. So, even in the situation where an in-flight project that is on-time, on-budget and poised to hit all critical business requirements but won’t deliver more business value than another un-resourced project, its time to serious consider divesting in the in-flight project and routing those resources to the higher priority project. Of course, don’t do this without careful thought to the people dynamic; most folks may not want to shift focus to a business domain they don’t have expertise on, people have an innate need to finish what they start to feel and achieve the sense of accomplishment, and constant change can begin to frustrate project teams.NOTE: In the situation of a Business Support organization’s project portfolio, frequent redirection of resources can lead to chaos quickly due to the bullwhip effect. To avoid this, the project portfolio must be integrated into business performance management processes directly connected to the Business Organization’s business strategy.
As a Program Manager and Project Manager. Implement Agile concepts into the project delivery lifecycle. This allows teams to plan early, plat often, and conversely fail early by recognizing signals of failure then course-correcting. As a Program Manager and Project Manager, I frequently step back and assess progress toward our defined objectives in our charter. When progress isn’t being made fast enough in terms due to over-budget, slippage or simply not meeting the critical business requirements, it’s time to re-plan the project that sometimes results in canceling the project altogether. When this happens, I like to take the team out for a celebratory event (dinner, drinks, whatever) for successfully making the decision to cancel a project that was doomed to fail.
As a Solution Architect. Do the background analysis to help justify why cancelling a project early or retiring a failed solution helps the business in terms of describing how the solution simply won’t meet the business requirements and targeted system quality targets. This can happen via causes such as; technology non-fit, poor software design, misalignment to the Enterprise Solution Architecture, or highly complex business requirements. This analysis normally feeds into the Project Manager or Program Manager project team roles. Anyway, help the team celebrate making the right decision to cancel or retire solutions based on the analysis.
As a Enterprise Solution Architect. Do the background analysis to help justify to the project Solution Architect why cancelling a project early or retiring a failed solution helps the business in terms of describing how the solution is not aligned to business strategy in regards to misalignment to Architecture Principles and Standards (think application integration patterns, information mastering policy, vendor product policies, etc) that are founded on business strategy expressed in Principle Justifications. One important piece of advice when playing the Enterprise Solution Architect role in this situation, participate in the failure as a project team member. Do not take an “outsiders position”. That leads to ivory tower syndrome and distrust. The fact is that everyone is on the same team when it comes to project failure and success. We are all aimed at improving business performance.
As a Business Architect. Do the analysis and help justify why cancelling a project early or retiring a failed solution helps avoid an underperforming business in terms of reducing costs, improving productivity, simplifies strategy execution, etc. Always paint the picture in a positive light based on engineering rigor tracing back to defined business objectives. See here for details. Again, participate in the failure as a project team member. Do not take an “outsiders position”. That leads to ivory tower syndrome and distrust. The fact is that everyone is on the same team when it comes to project failure and success. We are all aimed at improving business performance.

I’d like to add something here. I don’t think that every org should have a standard set of roles that are copy’n pasted from some industry team model. Each company and organization within a company will have a very different situation than another. For example, one company may be in the throes of economic turmoil and require a focus on scaling down the infrastructure to reduce costs. In this example situation, an EA team may not need to have a dedicated title of “Enterprise Solution Architect”, “Solution Architect” or “Business Architect” but rather have the titles necessary to focus on the discipline that relates closest to the area being addressed; “Infrastructure Architect” in this example. Of course, all scale-down situations like this need a dash of the other Architecture disciplines to build out the related artifacts to ensure engineering rigor is performed. For example, a situation may not require a full-time Information Architect. Fine, however, the Architect roles that are full-time must perform a bit of information architecture rigor to build their artifacts. I suppose I’m just highlighting this to you so as not to fall into the trap of assuming each named architecture skill or discipline requires a dedicated architect title in an arch team or that if there isn’t a titled architect in the team, none of related artifacts are necessary.

Enterprise Architecture: First stop, Building Architecture, then on to a Science!

2012-07-16T03:58:00Z

The Building Architecture industry is frustrated with IT Architecture. There is so much interest among IT Architecture forums to mature to the level of Building Architecture that many in the world are very confused. Building Architects looking for resources on the internet for Building Architecture resources now have to sift through tons of IT Architecture and Enterprise Architecture forums and content to find what they are looking for. Building Architects looking for an Architect job have to filter out all the IT job postings and politely explain to recruiters that they are not IT Architects and to stop calling! I’ve actually been asked by folks to help change the Architect role title and description away from Building Architecture via my blog and speaking engagements so as to differentiate it from Building Architecture to help the world stop mixing the two.

I was chatting to my wife today (btw, my wife is a Registered Architect) about the comparison between Building Architecture and Enterprise Architecture. In these discussions, she often channels the frustration from the Building Architect community towards me, which makes for some lively dialog over a glass of Riesling on the back porch on a Sunday afternoon. Even with my sparse knowledge of Building Architecture, I agree with my wife that the comparison between Building Architecture and IT Architecture is a little naive. However, after today’s chat we feel it’s inevitable, and expanding. Today, “Architecture” is defined as Building Architecture. We observe, however, that building architecture is at a point of maturity where it is being abstracted to a supertype for other Architect domains to be formed within. In a sense, Building Architecture is being promoted to Architecture for its success.

An analogy is science. Science is essentially a domain supertype abstracted to simply mean ‘the scientific method’ and has numerous Sciences (eg chemistry, botany, psychology) grouped by scientific categories (eg physical science, social science) to further distinguish them. By simply prefixing Science with a qualifier representative of the subtype, specializations are immediately understood by inheriting the properties of the supertype science.

Anyway, we’re noticing that other domains are now referencing Building Architecture concepts to describe their domain, simultaneously abstracting Building Architecture to Architecture defined as ‘the study of structures’ and creating a new sub-domain/subtype of Architecture within. IT Architecture and Enterprise Architecture are examples of this evolution and I’m noticing other domains do this too; do a search on Human Resource Architects or Financial Architects and you’ll notice other non-IT related domains innovating their domain by attempting to apply ‘building architecture’ concepts to them.

Interestingly, we Enterprise Architects often think that aligning to Building Architecture is the most precise or mature state of clarity to describe the Enterprise Architecture domain. Actually, it’s only a milestone and the next point of maturity is becoming a science. To be at the level of maturity science is at, practitioners and theorists must agree that the entire domain could be explained, predicted and calculated based on a set of formulas founded on the scientific method.

Enterprise Architecture strives to be like Building Architecture, Building Architecture strives to be a science

My wife explained to me where Building Architecture is currently at in terms of its readiness to claim a new science “Building Science” subtype. They are very close and a few thought leaders are claiming they are already there. The concept of Building Science is already an accepted term amongst Building Architects but is generally scoped to the part of Building Architecture related to sustaining the building and not the part about designing a building within its environment.

Can you imagine one day where Building Architects will pull out their scientific calculator, set it to Building Architecture, then calculate the perfect building based on questions like; “what sort of reaction do you wish the building to have on casual observers?“, “what location are we using?”, “how many occupants?”, “what’s the expected tenant revenue?”

Calculate the Perfect Enterprise

If the above theory is right, then we could conceivably do the same for Enterprise Architecture. That is, imagine one day where an Enterprise Architect pulls out their scientific calculator, sets it to ‘Enterprise Architecture’, then calculates the perfect enterprise by entering in answers from questions like “What’s the market position of the product lines?”, “What are the competitive advantages?”, “What are the business processes and their peak thresholds?”, “What are the measurable business objectives?”, “What is the as-is IT Architecture?” Press ‘Enter’ and voila, the perfect enterprise!

I know, this post is a little wacky and farfetched. I just thought it was an interesting conversation to share. Thanks for listening.

IT Organizations, like any Business Support Organization, Deliver Business Value

2012-07-09T21:06:00Z

As one traverses organizations in a company, the further you get from a business group responsible for producing products and services that generate revenue, the more difficult it is to describe the business value delivered. Among all the Business Support organizations in a company (eg Sales, Support, HR, Finance, IT, etc) IT is probably the most challenged because not only is IT a Business Support organization positioned deep within the company, IT is also a very complicated subject area that most normal business-minded folk prefer not to burden themselves to try to understand. So, it’s often up to IT to put the hard work in to build the necessary business acumen to resonate with their business partners. It’s no surprise “Business and IT Alignment” is one of the most popular topics in IT forums for the past decade.

Sidebar: How complex can business alignment be? According to the article How to Align a Business With Its Strategies from eHow, it’s a 6-step process. Hm. I like eHow.com - they helped me understand how to navigate Facebook’s new UI to update my account settings once. Regarding the topic of aligning a business with its strategies, however, um, how should I put this? I think my daughter’s favorite comment these days puts it beautifully “OMG” followed by “LOL”. On a serious note, aligning IT to the business is no different for alignment of any Business Support organization. I’ve described how this is done via the use of Business Performance Management processes here.

For the remainder of this blog post, I’ll focus on understanding Business Value and posit how to think of it in terms of alignment between IT or any other Business Support organization.

What is Business Value? Wikipedia’s definition of Business Value is very good but very lengthy. In my travels, I use a more simple definition, “Business Value is any perceived value of an organization by its stakeholders”. The point being only folks outside an organization can claim another organization delivered business value. The question now becomes “How should an organization measure business value?” The solution must be flexible to support all quantitative, qualitative, and probabilistic expressions of business value an organization’s stakeholders care about inclusive of informal expressions like “Good job!” statements from stakeholder organizations to the more formal expressions like Return on Investment, Net Present Value, or Key Performance Indicators like Contribution Margin, GMROII, Units Shipped, or % Risk Avoidance. In addition, the solution can’t require PhDs in advanced mathematics. The solution has to be simple, accurate and obvious to stakeholders.

Business Value measures success via KPIs

As it turns out, over the past 20+ years the top-rated business management schools in the world like Harvard Business School and Stanford University in collaboration with numerous business management groups (eg Bain and Company, Balanced Scorecard Institute) and thought leaders in the private sector (eg Southwest Airlines, Volkswagen and Cisco) have matured a powerful solution called the Balanced Scorecard methodology. The Balanced Scorecard is used in over 60% of Fortune 1000 companies with benchmarked case studies averaging 30%+ CAGR for organizations who adopted the methodology. The Balanced Scorecard methodology is considered the de fact standard for measuring and managing business value and it is done through a carefully managed scorecard of key performance indicators (KPI).

Sidebar: Balanced Scorecards aren’t only for STRATEX. Although many balanced scorecard methodologies out there focus on its use for STRATEX, I’ve successfully used balanced scorecards for managing Business and Business Support organization’s portfolio spend. For Business Support organizations, using the basic balanced scorecard technique can be a particular challenge because there is little guidance how to account for typical operating performance. Drs. Kaplan and Norton published the article Aligning Support Functions and introduced the themes “Business Effectiveness” and “Operational Efficiency” as means of prescribing how to do this. I highly recommend it.

What is a KPI? A KPI is a performance indicator used to express a project’s success or an organization’s success. KPIs make strategic objectives quantifiable. But, what makes a performance indicator ‘key’? The answer is perspective. That is, if an organization or a project team feel a performance indicator represents it’s measurement of success, then that performance indicator is a ‘key’ performance indicator for that project or organization. An often overlooked property of KPIs, and I’d argue the most important property, is the KPI’s date-bound KPI Target. KPI Targets provide the explicit expectation what success looks like and when. By subtracting the KPI’s Baseline from the KPI Target, one can calculate how much business value was realized.

The KPI is the canonical representation of Business Value

Douglas Hubbard proved that “if a thing can be observed in any way at all, it lends itself to some type of measurement method” (see How To Measure Anything). KPIs support any expression so they are innately compatible with every known expression of business value known to man. In a sense, the KPI is the canonical representation of Business Value. Because the balanced scorecard is widely used to represent business strategy, not only do KPIs allow us to express any type of business value, but when KPIs are used in the balanced scorecard methodology, they also express strategic value by definition.

Another important use of KPIs is their use by leadership to incent change in an organization. I’ve witnessed KPIs and KPI Targets used to make an organization snap to attention and focus on improving important areas of the business. For example, I worked for a Business Support organization where the leadership wanted to improve stakeholder satisfaction from the stakeholder organizations they partnered with. Their scorecard already monitored the “Stakeholder NSAT” KPI. The leadership simply cranked up the KPI’s Target from the previous year’s KPI Target value by 25%. The organization definitely felt the pressure. They quickly organized themselves and brainstormed ideas how to achieve the new, and fairly daunting, KPI Target. After several sessions honing ideas, the organization decided to make a project investment scoped to increase the formality of their account management engage processes from the first point of contact, to project delivery, then sustainment. It also included a closed-loop feedback management process to capture and disposition all stakeholder feedback. The project was successful and the organization realized greater satisfaction with their stakeholders than ever recorded.

Good and bad quality KPIs. Let’s take a moment and talk about what a good KPI is. First of all, any KPI that a direct stakeholder considers ‘good’ is good. We always strive for perfection however when it comes to using KPIs as a measure of business value an organization must first start with what their stakeholders offer to us as our measure of success no matter how imperfect it may be. So, if a stakeholder prefers to provide the feedback of business value delivered via a “Thumbs Up” then that’s the measure of business value to start with, regardless how crude the expression is. Ideally, we wish to monitor more objective KPIs so we can be a bit more scientific and begin to classify them (eg leading and lagging) to mitigate risk of not achieving lagging indicators. Here is a set of simple guidelines for defining KPIs that I use:

High correlation to Objectives. Ultimately, a KPI’s purpose is to quantify a strategic objective so choose KPIs that are directly related to them.
Attributable to one or more Value Streams. Knowing which value streams are accountable for a given KPI makes it simple to focus a process improvement project when change is necessary to hit a KPI Target.
Alignment to Performance Review meetings. KPI measurement periods should coincide with scorecard review meetings to optimize the timeliness of corrective action by decision makers.
Have date-bound Targets. A KPI should be chosen such that a Target can be defined. KPI Targets set expectations that drive performance change in an organization. Simply monitoring an indicator without knowledge of the intended target can make decision-making difficult.
Easy to understand. KPIs will gain greater use if it is easy to understand by all relevant stakeholders.
Readily available. KPI measurement process should be cost-effective and readily available. The best situation is where the KPI measures are automated.

Now that we’ve landed on using KPIs as a solid expression how to express business value that’s simple, obvious and accurate, let’s test the theory by applying it to two test cases below; IT project alignment and IT organization alignment.

Test Case #1: “How to measure the business value of a project”

Core to the balanced scorecard methodology is the ‘action plan’. The action plan is simply the set of projects accountable to make the necessary change in an organization to achieve one or more date-bound KPI Targets. A best practice is to require each project charter to include KPI Targets that the immediate organization has and/or its partners use to measure success. In addition, each project should require typical project ‘leading indicators’ to monitor delivery health such as on-time, on-budget and high-quality. A well-formed set of KPIs for any project include two dimensions of success; the immediate organization’s success as well as the stakeholder’s success. The result is a direct connection of business value delivered by the project as measured by the immediate organization and/or its stakeholder’s scorecard.

Here are examples of high-quality KPIs from a project’s perspective:

Project	Strategic Objective	KPI Name	Baseline Value	Target	Date	Value
Launch New Software	Grow Product Lines	# Software Units Sold	0	1,000,000	12/25/2011	1,429,921
New Order Management process	Provide Reliable Business Systems	Order Management Service Performance	N/A	1 sec	11/2/2011	<1 sec
Enable Self-Service Order Submission	Provide Reliable Business Systems	% of Orders Completed Online	0	35%	18/2/2011	13%
Automate Support	Provide Reliable Business Systems	$ Support Cost per Order	$35,000	$10,000	12/15/2011	$9,332
Partner Account Management	Improve Customer Satisfaction	Stakeholder Satisfaction Rating	140	175	12/6/31	170

Note: The “Target” and “Date” columns are super important to get right in that the KPI Targets and dates are set by the Business organization. That is, the KPI Target and the dates are scoped by the Business organizatoin's success. The “Value” column is the measure captured on the “Date” date. The principle here is that the Business Support organization’s success is defined by its own organization’s scorecard and the sucees of the Business organization’s they serve.

A best practice method I’ve implemented here within Microsoft for Business Support organizations to monitor business value realized is to include a single KPI on the Business Support organization’s scorecard such as “% Business Value Realized”. This KPI is defined as the percentage of KPI Targets achieved or underperformed by all projects delivered by the organization. Because this is a lagging performance indicator that is incredibly important to the organization, we added a leading indicator “% Charters with Organization KPIs” to ensure project teams include the immediate organization and/or Stakeholder KPIs, and their targets, on the project charter, in addition to the typical project health indicators, at time of being funded.

Test Case #2: “How to measure the business value of an IT organization”

Again, we call upon the balanced scorecard methodology. Using the balanced scorecard methodology, we leverage the concepts of themes to group objectives and KPIs and the concept of cascading to link them to stakeholder organization scorecards. Here’s an example balanced scorecard for a Business Support organization.

In the above example, scorecard cascading is done via either mirroring stakeholder Objectives (ie rounded boxes) or KPIs. Cascading is the business management term for traceability between scorecards. A well-defined scorecard results a complete balanced scorecard used to measure the success of any organization as a reflection of self-defined success as well as stakeholders organization’s success in an enterprise.

Business Value Measurement Process fuels Continuous Improvement processes

To help simplify how to ensure business value realized, I’ve helped some organizations implement a process for defining, delivering and monitoring business value. The process model is no different from the closed-loop process prescribed by business performance management but filtered to the perspective of project delivery. Here’s an example of business value measurement process I’ve used.

Note: The above Business Value Measurement process assumes that the KPIs defined in project charters are of high-quality and refer to KPIs on organization scorecards. Also note that the process steps follow Dr. Edwards Deming’s Plan, Do, Check, Act method to make the connection to continuous improvement process popular in business management practices.

Using KPIs makes it simple to monitor and track business value realized

With the foundation set for understanding how a Business Support organization contributes to business value, tracking and monitoring business value realized is simple. Assuming that all project teams enter project KPIs, KPI Baselines, KPI Targets and capture actuals at the predefined KPI Target dates, an organization can produce views of business value achieved, exceeded or underperformed pivoting organization, and project portfolio. I’ve built such views but cannot show them to do confidentiality of the information. I will share with you that the views produced are very interesting to senior leadership primarily in the situations a dispute arises or a statement is made regarding the business value of a particular project or organization is made. The views are undisputable.

When associating business value information to financial information, one can view the financial comparison of cost versus business value realized. When associating it to Value Streams, one can view where business value is focused and which product lines and customers are positively impacted and by how much. When associating business value information to IT data (application portfolio management, incident management, configuration management data) one can view and compare business value realized per application, value stream, incidents, etc. This is why having a common reference data model articulating how all these concepts (Organization, Objective, KPI, Process, Project, Application w/Cost, Incident with/Cost, People with Cost, Asset with/Cost, etc) relate becomes incredibly powerful.

Using Business Performance Management to climb the ‘Strategic Alignment’ maturity curve

Because alignment is so incredibly important I thought I’d build a graph to help explain what it means to be aligned. In the context of business strategy, alignment is a word describing an organizational design resulting in some level of responsiveness to changing business needs. I’m sure there are better definitions out there; this is just one that I made up and makes sense to me. Anyway, assuming the intent in my definition above, I’ve built a graph illustrating the typical organizational states resulting in different levels of responsiveness ultimately measured by business performance. The assumption is that the highest form of alignment is convergence expressed by Business Support organizations adopting a Business’ scorecard wholesale with no modifications. And conversely, the less aligned a Business Support organization ultimately results in divergence resulting in a lesser performing business.

Strategic Alignment Maturity Spectrum:

Business Irrelevant: The ‘Business Irrelevant’ state represents the situation where a Support Organization’s scorecard or set of projects have no scope to address one or more specific requirements from a Business organization. We’ve all witnessed IT projects spin up to build something without actually deriving the solution from the business needs provided by stakeholder organizations. The result of these ‘build it and they will come’ projects all too often result in a bunch of wasted time and money due to no adoption. No business value realized.
Loosely Relevant: The ‘Loosely Relevant’ state represents the situation where a project has some level of mapping to business needs. For example, projects scoped by simple business requirements (eg one-liners, scenarios, use cases, processes, etc) stated in a business requirement document provided by a Business organization
Business Responsive: The ‘Business Responsive’ state represents the situation where a project is included in a business’ action plan attached to a scorecard that is used as the tool for business performance management process. Therefore, the project is directly accountable to achieving one or more business’s scorecard KPI Targets and assigned a set of value streams/processes as the starting points of a project’s scope. Btw, although this type of situation is extremely efficient, it also implies that projects that are part of a business’ action plan are de-scoped or re-scoped regularly as changes in business direction are reflected in the business’ scorecard.

Holding all Business Support organizations and projects accountable to achieving KPI Targets managed by a business performance management process is a streamlined method to ensuring business value. In a sense, business performance management processes break down the organizational reporting lines that all too often encourage silo-like behavior, and allow project portfolios to be directly responsive to changing business needs.

World Class Business Support Organizations

Although business performance management processes are well-known in Business organizations, adoption by Business Support organizations is slow and often non-existent. Through the adoption of the balanced scorecard methodology to track and manage an organizations performance arguably propels itself among the leading world-class organizations in the world in terms of strategic alignment focused on delivering business value.

Business Architecture is Business Performance Management with Engineering Rigor

2012-06-27T02:11:00Z

I’ve been performing a Business Architect role within the Enterprise Architecture function over the past few years and wanted to share some opinions I’ve formed to help jog, and possibly advance, the thinking in the space of Business Architecture by colliding Traditional Business Architecture with business management processes like Business Performance Management.

Traditional Business Architecture needs refinement to drive business success

After using some of what I call ‘Traditional Business Architecture’, I found that teams are at high risk of failure toward helping companies achieve success. I’ve been part of, and witnessed other groups, implement Traditional Business Architecture concepts that over-simplify “the business” and result in analysis paralysis from focusing on the wrong things and/or getting caught in trying to manage unbelievable amounts of information that quickly turns into a non-sustainable investment. In my opinion, Business Architecture is foundational to the success of any company in a competitive market and a vital part of a successful Enterprise Architecture function so I’ve taken the time to write down some observations as a means of making a pass at refining the concept of Business Architecture and help folks sift through and apply what’s already there.

Let’s start with a simple overview of what I’ll term ‘Traditional Business Architecture’ in this article. I see Traditional Business Architecture as the collection of the popular methods and models describing Business Architecture such as Gartner EAF, TOGAF standard, ArchiMate, FEAF, Zachman, Total Quality Management, Six Sigma, LEAN and CMMI. I know what you are thinking “did he just say that those incredibly popular Architecture industry frameworks are ingredients for a failed Business Architecture function?” Well, yes, I am saying that. Don’t get me wrong, these are all useful to some degree if applied appropriately. However, by themselves either individually or collectively they are fraught with high risk of failure assuming success of Business Architecture as part of an Enterprise Architecture function is defined as the company’s success. I’m carefully choosing my words here because I realize how my message could be misinterpreted. Let me say it again to avoid misinterpretation, “Implementing Traditional Business Architecture is at high risk of failure toward helping companies achieve success “.

Reader:	“Oh, no he didn’t!”
Gabriel:	“Well, yes, I did.”
Reader:	“Ohhh myyyy.”

Instead of critiquing each Traditional Business Architecture model and techniques and highlight the risks to driving a company’s success, I’ll describe how adoption of a few business management concepts with a dash of engineering rigor get us a refined description of Business Architecture. From there, you can do the math to compare to the industry frameworks and highlight the risks for yourself.

Business Architecture engineers the business for Success

Business Management is essentially about defining what business success looks like and lining up the organization to execute it. Business Architecture is about applying engineering to business concepts to capture the definition of business success in a well-defined model and providing analysis to shape and optimize the project portfolio to achieve it. In a sense, Business Architecture is simply applying engineering to the Business Management discipline.

Sidebar: What is a Business?

From a Business Management perspective, all organizations within a company are classified into two types; Business and Business Support . If an organization builds a product or service which generates revenue, it is a Business organization. All other organizations are Business Support organizations. A ‘Line of Business’ is a synonym for a Business organization. Examples of Business organizations are Product Teams and Business Services. Examples of Business Support organizations are Marketing, Sales, Support, Human Resources, Operations, Legal, Finance and IT.

Focus on Success via Business Performance Management

In Business Management, Business Performance Management is the most effective process for delivering business performance. There are several variations of business performance management processes out there and the balanced scorecard is by far the most widely successful method.

Sidebar: What is Business performance management?

Business Performance Management is a set of management and analytic processes that enable the management of an organization's performance to achieve one or more pre-selected goals .

In a single business, the balanced scorecard provides a thorough means of articulating success to achieve the business organization’s Vision and the necessary project investments to achieve success. The balanced scorecard takes into account the causal nature of defining success for the organization’s people, then process, then customer perceptions as well as the broader organization’s stakeholders. The business’ balanced scorecard is used by the relative Business Support organizations to derive their own balanced scorecard via a process called cascading. From a Business Architecture perspective, the balanced scorecard provides a clear definition of success via date-bound Key Performance Indicator (KPI) Targets. The KPI Targets, in combination with an architecturally sound solution expressed in terms of process, information and system architectures, describe the project’s scope. The end result is a business strategy and subsequent Business Support strategies inclusive of well-defined KPI Targets mapped to a project portfolio where each project in the portfolio is accountable to deliver to the specific KPI Targets found in balanced scorecards. Business Architecture enables this by ensuring traceability from the balanced scorecard to the project portfolio and making sure that rigorous engineering was involved to describe the project scope to be delivered; KPIs, process, information and system architecture together. In summary, the balanced scorecard and Business Architecture discipline provide a well-engineered closed-loop business performance management process entirely focused on the business’ success.

To take the above to the next level of sophistication and address external and internal triggers to change the business, a business management process called strategy formulation is required. Strategy formulation processes like Porter’s 5-Forces, Blue Ocean and SWOT are designed to analyze an organization’s environment with the intention of mitigating risk and leverage competitive advantage. Business Architecture enables strategy formulation again by providing a structured model to capture external and internal signals and perform traceability from external and internal signals to the balanced scorecard’s KPI Targets. A typical example of an external signal triggering a change in a business’ balanced scorecard would be the observation of a competitor gaining market share. An example of an internal signal would be the observation of internal systems that continue to breach availability or performance Service Level Agreement thresholds. Business Architecture enables this broadened closed-loop system by mapping project investments to achieve KPI Targets that are traced to to external or internal signals.

Sidebar: Balanced Scorecards aren’t only for STRATEX.

Although some balanced scorecard methodologies focus on its use for STRATEX, I’ve successfully used balanced scorecards for managing Business and Business Support organization’s portfolio spend. For Business Support organizations, using the basic balanced scorecard technique can be a particular challenge because there is little guidance how to account for typical operating performance (ie CAPEX and OPEX) as well. Drs. Kaplan and Norton published the article Aligning Support Functions and introduced the themes “Business Effectiveness” and “Operational Efficiency” as means of prescribing how to balance a strategy of a Business Support organization with the Business(es) they serve. I’ve taken the concept to manage entire portfolios and highly recommend it.

We need to augment Business Performance Management and

Business Architecture techniques to support an enterprise

Up to now, I’ve highlighted business performance techniques for a single business (and enabling Business Support organizations). The moment we broaden the scope to a large enterprise with several businesses, what’s been described so far won’t scale and we need to augment our techniques to make business performance management work. To avoid confusing customers with the various products and services offered as well as provide a logical method to optimize each business’ customer value stream, we group products and services via business models based on the Customer Value Proposition the company’s products and services provide. The most proven business management technique for doing this is Alex Osterwalder’s Business Model Canvas. From a business management perspective, the Business Model Canvas provides a technique for a company to organize businesses and form partnerships to collaborate and exploit their competitive advantages to outperform the competition through maximizing Customer Value and reducing operating costs. From a Business Architecture perspective, the Business Model Canvas provides a simple classification structure to organize business architecture elements; Partners, Activities (think process), Value Propositions, Customer Relationships, Channels, Customer Segments etc. From my experience, understanding a single business’ business model is important but not critical. In the situation of a large enterprise with several businesses, understanding the companies business’ business models is very important to get right. To be honest, I’m still learning how to do this scientifically because it’s not obvious where business model lines are drawn as the number of combinations of Business Model Canvas elements is extremely high. I tend to focus on businesses in sets framed by commonalities in Customer Value, Channel and Customer Segment then work with businesses directly to refine as appropriate. In my experience, I’ve observed about 4 business model distinctions that seem to be useful for Business Architecture work; Service Provider, Physical Product, Keystone, and Enterprise Partner. Anyway, once businesses are grouped by business models, simply apply business performance management and business architecture techniques like we would for a single business with the exception that we need to add horizontal balanced scorecard cascading between the businesses. The result is synergy of business strategic targets and project alignment across business boundaries down through their Business Support organizations. What doesn’t get covered is a layer of refinement to identify opportunities for optimizing project spend by avoiding project redundancies in terms of projects delivering solutions to the same process space. To optimize the project portfolio and avoid project overlaps, the Business Architecture technique of cross-portfolio analysis by grouping projects based on a common process framework (aka business capability model and business process models) is used. Also note that Business Architecture intersects the Solution Architecture discipline at this point to identify further opportunities to reduce project spend by reuse of enterprise platforms through system dependency analysis. The result is an enterprise-wide model describing interconnected business strategies per business model where business KPI Targets are directly mapped to project portfolios that have been optimized to avoid gaps and overlaps as well as leveraging enterprise platforms.

Here’s a heavily cleansed example of a Balanced Scorecard for an IT organization here within Microsoft. Note that I’ve modified it to be more illustrative of the concepts in this blog post. Just drop me a comment if you’d like me to add clarity. Note that I combine the Strategy Map and Balanced Scorecard KPI data together as it makes it easier for the information to be on a single view. Also, I made some modifications to suit the organization I served. For example, I changed the perspective names a bit as well as the theme “Partner Effectiveness” to better align to terminology used in the organization.

For those new to the concept of Strategy Map, essentially a Strategy Map is a set of Objectives organized by the four balanced scorecard perspectives. The way to think about the relationship between Objective and KPI Targets is assume the KPI Targets a measurable proof the organization has achieved the Objective.

Here’s another illustrative example of a project portfolio anchored in the context of a balanced scorecard to help with the analysis of project-to-strategy alignment. This view is something I use internally to help identify misalignments or other anomalies that trigger conversations about whether we’ve got the right set of projects defined to achieve our objectives.

Strategically Federating IT

2011-06-09T14:47:00Z

IT must rethink how to deliver on its promise to enable the business. IT-centric efforts are falling short and IT experts seem to be stumped what to do about it. This is why a few years ago in search of a solution I turned my attention from mainstream ‘IT thought leadership’ and toward ‘business management best practices’. I literally avoided IT conferences and unplugged from IT industry framework communities because I figure asking IT experts how to shape IT to better support the business is sort of a ‘blind leading the blind’ situation. Instead, I turned my attention toward business schools, business forums, customer-advocacy communities, and business strategists to carefully listen. I’ve finished my first leg of adopting some interesting business practices in a career-long journey aimed to course-correct IT and bring it to its full potential. I’d like to share with you one of the ideas aimed at structuring IT organizations based on business strategy.

Strategically Federating IT

The notion that IT be distributed isn’t new, in fact, it’s probably the current-state situation in most large enterprises today. The notion of Federated IT isn’t new either. When it was introduced in the early 2000’s it was narrowly scoped to define IT with collaborative functions to work with other IT organizations. This is a great start by describing the basic IT functions to collaborate between Federated IT organizations but it left out an important guideline where to place IT organizations and how businesses were to integrate with them based on the company’s business strategy. The resulting situation is what we see today; in one extreme we have central IT organizations that want to control and manage all IT assets and on the other extreme we have numerous IT organizations spinning up all over the place.



	*Sidebar: “Strategic Functions Within A Federated IT Organization”, Forrester, Cecer, 2004* “The federated IT structure was designed to reduce the costs of IT, while remaining responsive to business needs. To do this, several strategic functions that are common to a centralized IT shop must be implemented differently within federated IT organizations. Planning and architecture, for example, at times must use a facilitative approach and encourage the business units and lines of business to recommend and agree to standards. At other times, they will need to force decisions without reaching consensus. Other groups such as vendor management and the project office must take a harder line. The project office must track the progress of all enterprise projects and those past a certain size. Similarly the vendor management function must at a minimum be aware of all significant contracts and, in many cases, manage those vendors that the enterprise feels are strategic. Federated IT functions: Shared Accountability Within Federated IT Strategic Functions Within Federated IT Architecture Planning Program Office/Project Office Relationship Management Technology Research Vendor Management”

Many IT organizations are confused to what their purpose is and find it difficult to provide a simple plan for where it is today and where it should go tomorrow in language that both the business understands and the IT organizations can deliver to. I’m currently thinking of an approach to avoid that situation which leverages the Federated IT concept and adds a deliberate set of new characteristics tethering the Federated IT concept to business strategy. Strategically Federated IT organizations abide by a federated model to share a common mission, professional management goals, strategy management and program portfolio management processes, technology management, information management/stewardship, and architecture models. Over time we’ll refine these but to start the ball rolling, the rest of this blog post begins to describe some of the big rocks for consideration; IT’s Purpose, Deliver to Business Strategy, Strategy Management and Program Portfolio Planning, Cascading Balanced Scorecards, and Shared IT.

Here are two fundamentals of Federated IT organizations to help describe their mission:

Remember IT’s Mission/Purpose. IT’s purpose in the company is to do three things; a) automate business processes, b) manage information used in the automated business processes, and c) professionally manage IT resources. There are schools of thought that suggest IT should do more than this such as offer business innovation and achieve high rankings in industry benchmarks. I disagree. Those are not the primary mission of IT. They are nice-to-haves and if they become as important to the IT organization as the first three points, they often distract IT organizations from delivering on its primary purpose of existence.
Deliver to Business Strategy. Deliberately manage IT to contribute to business strategy while being responsible for its mission (see point above). There are likely many businesses within an enterprise, so for each Business there should be an adjoining Federated IT organization to support the business via technology investments. From a purist perspective, program portfolios should intentionally combine business program and IT program investments as much as possible to hold IT investments accountable to business objectives. Where combining programs is too difficult, at least ensure that the IT program’s success metrics are those directly associated to business objective targets they intend to support.



	*Sidebar: “Run IT in the business”* I hear that IT needs to run as a business a lot so I thought I’d take a moment to comment on it here. We need to encourage IT to move away from the concept of ‘Run IT as a* business’. Instead, we need to encourage ‘Run IT in the business*’. IT is not a business. In fact, thinking that IT is a business actually hurts IT’s ability to better integrate with the business. Bob Lewis wrote an article published in InfoWorld titled “Run IT as a business – why that’s a train wreck waiting to happen” that does a fantastic job explaining the disruptive concept. I agree with Mr. Lews and think it’s caused a lot of distraction to IT organizations focusing on their primary mission. The appropriate approach is to remember IT’s Purpose of ‘professionally managing IT resources’ noted above and build competencies for professionally managing IT resources such as; reducing exposure to corporate risk, optimize financial investment portfolios, secure corporate and customer information, manage IT people careers, and deliver systems on-time/on-budget/on-expectation. Every organization must strive for professional excellence. IT Organizations are no different. That doesn’t mean IT should run ‘as a business’, just run it professionally. The article also supports IT-and-biz-integration ideas which I consider Federated IT to be one. Here’s a quote from the article worth calling out “The alternatives begin with a radically different model of the relationship between IT and the rest of the business -- that IT must be integrated into the heart of the enterprise, and everyone in IT must collaborate as a peer with those in the business who need what they do.”

To help make Federated IT operate more efficiently, we need a few constructs:

Cascading Balanced Scorecards. For those unfamiliar with Balanced Scorecards (BSC) and how cascading is used to connect organizations together to streamline strategy execution, read The Execution Premium by Kaplan and Norton. You can get the basics from Kaplan and Norton but to apply it to align IT to the rest of the company, you’ll need to step onto the bleeding edge of industry knowledge on the topic of how to align operations to business strategy. I think one way to do this is to break away from traditional Big IT thinking and incorporate IT in the lines of business. A natural result is the existence of Federated CIOs to manage each Federated IT organization within each LoB organization.
- Below are two very simple diagrams to roughly explain how I use cascading BSCs in the enterprise.

The diagram attempts to illustrate two views of cascaded BSCs:
- Strategy to Organizational Alignment. This is relatively straight-forward use of the BSC, however, I like to call it out to emphasize that primary purpose of that view which is to show a more ‘operational alignment’ rather than a ‘customer value proposition’ alignment. That is, when we cascade BSC up and down an organization’s structure, we are typically looking at operational or internal-focused metrics such as Contribution Margin, Time To Market, Cost, Defects, etc. This is where the point in IT’s Mission of professionally managing IT resources is directly supported.
- Strategy to Value Stream Alignment. This is a more important view for the purposes of this blog post because it illustrates how processes align to business strategy. This is critical to understanding how Federated IT works. IT underpins the processes in the value stream managed by a Line of Business. If IT optimizes for delivery to each Value Stream, then IT is directly contributing to business strategy via the processes required to achieve business strategy managed by the Line of Business.

Although the resulting IT organizations would be completely focused on contributing to business strategy, we need teams distributed to each LoB equipped with a common set of program investment decision-rights and processes as a means of federating IT responsibilities to program investments across the enterprise to avoid huge problems such as information management nightmares and out-of-control technology redundancies across the enterprise. I extend Kaplan and Norton’s concept of Office of Strategy Management to do this, however, I’ve observed others shape their Program Management Offices to do the same thing. Whatever concept works for you, go for it, just make sure you include these fundamental strategy and program planning processes together because one without the other is a waste of time:

Strategy Management. The process for managing business strategy from strategy ideation to strategy rationalization/cascading including stuff like; define business mission and vision, define business objectives, identify business model gaps, define program investments, manage strategy gaps, overlaps, dependencies, conflicts, and model strategies across the enterprise.
Program Portfolio Management. The process of managing Programs as an investment portfolio including stuff like; prioritize business objectives, model and manage program dependencies, identify reuse opportunities, prioritize programs, and identify program consolidation opportunities.

Shared IT

There is certainly opportunity for a Shared IT organization to centrally manage IT assets that are reused across the enterprise. To do this, Shared IT must carefully plan and govern the shareable IT assets that are not already managed by Federated IT organizations. Managing Shared IT to support several Lines of Business is no simple feat. Successful implementations require more than building processes and underlying software and hardware to be reused. The far greater challenge is for Shared IT to include stewardship processes to manage the shared IT assets so that changes don’t disrupt all the LoBs using them, and the shared asset can deliver quickly to the needs of the businesses. The result might look something like this diagram below:

The principles and concepts above define foundational elements for supporting Federated IT in the enterprise. They support Federated IT organizations to manage their segment of IT assets which support business processes streamlined to optimize Value Streams for all Lines of Business. The enterprise-wide result is IT and the business partnering together to execute business strategy through shared program investments targeting shared business objectives.

Not only is IT sick, but much of the business is too

Some Lines of Business have challenges too and need help communicating and executing their business strategy, discovering new innovations that bring competitive advantage, and enabling scalability. The concepts of Strategy Management and Program Portfolio Management that are born from business thought leadership are a natural concept to uplift maturity and help the business manage themselves. For Lines of Business unfamiliar with strategy management and program portfolio planning best practice processes, IT folks can bring these concepts to the business to help them solve business challenges in addition to bringing forth a critical mechanism to integrate IT into the business.

I used many terms in this article that may be unfamiliar to many IT folk so here are terms and definitions:

Business: An organization responsible for building and selling a customer value proposition. I know ‘Business’ sounds a lot like a Product Offering. The difference is that a Product Offering is a specific expression based on a product specification where a Business is the logical expression of a Product Offering from the perspective of the organization responsible for delivering the Product Offering to customers.
Line of Business: An organization responsible for one or more customer value propositions. Lines of Business are primarily measured by Customer Value, as in Osterwalder’s Business Model Canvas or Value Stream concepts and is measured on Customer Value.
Business Strategy: An outside-in method to manage business investments to achieve business objectives. Example Business Strategy methods include; Porter’s 5-Forces, Collins’ Hedgehog, SWOT Analysis, and PEST. Note that Business Strategy is federated via an Office of Strategy Management or PMO function across Businesses in the enterprise.
Cascading Balanced Scorecards: A method to align organizations to Business Strategies. By definition, Business Strategy is distributed and held together by Strategic Themes and Business Objectives documented in Cascading Balanced Scorecards.
Strategic Theme: A set of Business Objectives grouped by a common stakeholder objective
Support Organizations: Organizations responsible for supporting Lines of Businesses. Supporting Organizations should measure themselves on Business Value.
Business Strategy Execution: The efficient planning and delivery from Lines of Business and Support Organizations deliberately collaborating to achieve Business Strategies.

Strategy and Planning Service as an Enterprise Architecture Offering

2011-02-03T16:25:55Z

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:

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.
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.

Effective Enterprise Roadmaps are designed to make change and track ‘effect’

2011-02-01T19:17:00Z

I’ve come to some interesting conclusions regarding Roadmaps that I thought might be interesting to others. About two years ago, I was given responsibility on behalf of the Enterprise Architecture team to provide Roadmaps on behalf of MSFT’s CIO that address 3 CIO concerns to all of Microsoft and they are; IT’s alignment to the business, Gaps and Overlaps in our portfolios, and Key Technology Investments. This responsibility came to our Enterprise Architecture team as a result of a less-than-successful attempt of an ask by our CIO to all groups of our IT organization for their roadmaps. The plan was to simply collect them all together and have an aggregated Roadmap that addresses the 3 CIO concerns. Unfortunately, the roadmaps returned from our IT organization were a collection of documents that no system or human could rationalize together to claim “across MSIT, here is how we are aligned to the business, here is where our gaps and overlaps are, and here are our key technologies to invest in”. When I looked at the roadmaps I learned that each of them were correct to varying levels but only the author could explain how it address the 3 concerns noted above – they didn’t stand on their own nor could they be aggregated to represent all of IT’s view. I discovered that the root cause was based on these problems:

Multiple Unmanaged Taxonomies: We had a litany of disparate and unmanaged taxonomies (Strategy, Platform, Program, Project, Business Process, Application)
Taxonomy Relationships are undefined and unmanaged (Process to Application, Program to Platform, etc)
Data Quality: Different terms with the same meaning as well as different meanings for the same term.
Lack of Analytics Ability: Analyzing the data sets is a manual, subjective and intensive activity. At the size of Microsoft, being able to scale quickly becomes an issue.
Local Data Not Centralized: Most taxonomies used in the roadmaps were generated from local data stores.
Lack of Unified Process: Manual process do not scale at the current level of data complexity and local processes for creating data sets are not coordinated. Depending on the time of the year asked, you may get different results.
Lack of Role Clarity: Several individuals claimed accountability for identifying Strategy, Platform, Application, Program et al. Some accountabilities not claimed by anyone.

Six months later I gained support to build a team with tool support to be the official provider of Roadmaps called Enterprise Strategic Planning (ESP) that has the mission statement “Enterprise Strategic Planning is a ‘Service’ provided by the Enterprise Architecture team. We provide a consistent, unified, rational, and collaborative planning capability within MSIT via Service Offerings based on people, process and tools.” The scope of our first release was to provide the foundational processes, role definitions and data to generate roadmaps that illustrate how IT addresses each of the three CIO concerns.

My ESP team built a data model that supports the 3 CIO concerns and we addressed each of the 7 problems above over the course of a about a year. We made major headway to delivering Roadmaps that address the 3 CIO concerns. I can generate roadmaps that show how IT things like IT Projects, Applications, Managed Information, etc associate to business things like Business Strategy, Business Process, Business People/Role, etc over time. I can generate roadmaps that show gaps and overlaps exist in our IT Project portfolio, Process portfolio and Application and Platform portfolios over time. I can show roadmaps that show which Technologies we will migrate to over time too. I wanted to share my learnings regarding roadmaps with you all about a year ago but I didn’t feel I could speak with confidence on them at the time because although I’ve addressed the 7 problems listed above, I discovered more challenges with the roadmaps that made me fear I might propose ideas that produce more bad ideas to the industry. (For those of you that follow my writing and presentations, I maintain an important principle in that I only share my experience and stay away from communicating theory. This is because the Enterprise Architecture discipline is so immature I think too much theory actually causes more damage than good sometimes.)

After producing those roadmaps I learned that they weren’t particularly effective in driving change, which I think is the purpose of Enterprise Architect’s existence…which is to drive change across the enterprise to help accelerate the company to achieve its strategy. This was both disappointing and ironic. The roadmaps communicated current state well but the future state was treated as more speculative rather than course-setting. So change, as it turns out in my experience, wasn’t driven by these roadmaps. This caused me to rethink how to drive change and then how should I position roadmaps to contribute to driving change.

In Microsoft, change happens via programs/projects/initiatives. Therefore, to drive change as an Enterprise Architect, we must influence decisions which projects to fund as well as set the scope of the project. The challenge is to know what influence should an Enterprise Architect provide to project portfolio managers so that they fund the right projects and define the scope to hold the projects accountable for. And on top of that, how to monitor change to track progress. So, to make the roadmaps more effective at driving change, we need roadmaps to have two fundamental principles:

Focus the information on roadmaps to be directly pertinent to making project funding decisions. That is, make sure that roadmaps include information that is used to drive project funding decisions. For our planning process here in Microsoft to make project funding decisions, its information like Strategy Alignment, Risk Avoidance, Cost Reduction, etc. Programs that offer the optimum spend to those areas are more likely to be funded. So, our roadmaps need to include which projects make the greatest change in those areas. This helps ease the pain for funding decision makers to make decisions that drive change that impacts IT’s ability to achieve our company strategy.
Focus the information on roadmaps to track the effect you wish to see. If we are to use roadmaps to track the progress, then the information on the roadmap must represent the change we are looking for so as change happens we can claim that the Program is on or off the roadmap to trigger a conversation. For example, the type of changes us Enterprise Architects wish to see at the moment are major shifts in IT’s ability to be more aligned to business strategy, security compliance, application and platform portfolio simplification, application and platform quality, data quality and availability, process reuse, information reuse, improved business continuity and disaster recovery, etc.

We will generate several types of roadmaps this year including Program Roadmap, Strategy Roadmaps, Application and Platform Roadmaps. One that is relatively new is the Program Roadmap and is based on the two principals above. That is, the information on the Program Roadmap is mostly the ‘affect’ of the Program rather than traditional stuff like features or functions delivered, or showing program milestone dates. Instead, it includes specifics like which business strategies will be enabled and when, which organizations will be supported and when, which processes will be automated and when, which applications and platforms will be created, modified, or retired and when, which corporate risks and issues will be addressed and when, which business information facets will be created/updated/deleted/used/published and when, etc.

The Program Roadmap is a bold step in a new genre of roadmaps referred to as ‘affected architecture’ (the good people from alfabet.com coined this I think.) What I really like about the concept of ‘affected architecture’ is that it incents the right behavior. It holds projects accountable to make certain changes. Therefore, it’s not about releasing code, delivering features, spending time and money. To track change at the enterprise level, it’s entirely about tracking changes to the enterprise architecture.