What is misalignment?

In order to solve a problem, you have to know the problem you are solving.  In a growing number of organizations, Enterprise Architecture is responsible for insuring the alignment of business change programs (including but not limited to programs that impact computing systems).  But what does a misaligned program look like?  How would you know one when you saw it, and what would you do when you do recognize one?

Until you can answer these questions, your EA program may be “a dog chasing a car.”  What will you do when you catch it?

A definition of alignment

Alignment is the condition where your vision, your goals, and your actions are oriented produce the same effect.  Alternatively, alignment means that you do what you say you will do.  It means you are moving with intent.  How do you know if you are aligned?  When a company is aligned, the investments that the company is making in the future serve to fulfill their strategies, and the strategies move the company towards their goals, and their goals are likely to help deliver their vision.  Alignment means that you stop doing the things that delay the delivery of your strategies.  It means you remove focus from actions that distract, and add focus to actions that enhance.  It means you cut the funding from things that don’t matter. 

Alignment is a personal goal as well as a corporate goal.  If you are personally aligned, it means that your vision guides your actions and that you are true to that vision.  It means you do the things necessary to bring that vision about, in accordance with your values.  Great men and women, whose accomplishments live on in history, are the most aligned people.

Alignment, in the corporate sense, is difficult.  It is not possible to be an aligned company if the people in the company do not understand the vision, embrace the goals, support the strategies, and act in a manner that delivers on them.  Alignment is end-to-end.  It is not a training program with posters extolling the virtues of the company’s core values.  It is made up of a thousand business decisions, each independent, made by different people, in which the SUM of the decisions produces the effect of moving the company, its people, and its resources in the direction dictated by the company’s vision.  Alignment occurs only when the culture, the values, the executive staff, and the entire workforce support alignment. 

How to recognize a misaligned program

Alignment is a distributed idea.  It takes an army to change the course of a company.  Individual people need to be encouraged and reminded of what the strategies of the company are.  The existence of a misaligned program does not indicate bad people or even bad performance.  It indicates that a good people came up with a good idea that the company simply should not follow up with, because the company needs the resources to move in a different direction.

First off, alignment is the art of taking “words” and insuring that “actions” actually match them.  The motto is “do what you say you will do.”  First thing: know what you said.  Second thing, do what you said.  First say, then do. 

Unfortunately, this order is very often reversed.  We like the idea of incremental improvement.  A team will decide to improve something, create a program that will change processes and systems in order to have that effect, (the “do” part), and then we look at the strategies of the company and we justify the program by associating it to one of the company strategies (the “say” part).  That is not how to get alignment.

Let’s be clear about what an aligned program gives us.  An aligned program gives us movement in the right direction.  Not just any movement.  Specific movement.  Other movement can exist. 

A misaligned program may produce business value.  In fact, it might produce immediate, tangible, and important business value.  That’s what it might do.  Here’s what it will do: A misaligned program will consume resources (people, money, time, bandwidth).  There is a limit on the amount of change that an organization can accept in a year. 

Example: How ROI works against alignment

The challenge of misalignment is that you have to say “no” to valuable programs!  On a strict ROI basis, alignment is insane.

For example, let’s look at a strategy and, skipping a few steps for the sake of discussion, two programs that have been suggested. 

Situation: Fabrikam is a $200M manufacturing company that makes orthopedic items that doctors offices fit onto patients.  The patients arrive in pain, leave with the item and pay the doctor for it.  They don’t really go “shopping.”  It’s a confined market.  Fabrikam has built their business on excellent relationships with doctors offices, selling the medical benefits of their orthopedic devices directly to practitioners.  This has been done through a dedicated sales force that negotiates agreements with large hospitals and physician groups.  Fabrikam’s web site is primarily used to allow existing customers to replenish their inventory at the prices negotiated in that agreement. 

Their competition, Orthomarket, traditionally sends out a catalog to smaller practitioners.  They moved to eCommerce about five years ago.  Their business model yields a lower margin but reasonable sales.  Their products are less expensive and lower quality.  They have no complex large-volume purchase agreements.  It’s a fairly simple retail operation.

External Influence: Orthomarket has made headway into Fabrikam’s market share through their e-Commerce web site.  The competition added features to their site allowing large hospitals to pre-select specific products for their doctors to buy.  As a result, Orthomarket has been chipping away at some large accounts and have expanded their reach by creating special purchase relationships.  If they are successful, Fabrikam’s sales will suffer.

Strategy: strike back.  Go after Orthomarket’s base through an aggressive new, low cost line of products marketed through direct mail advertising and ordered from a new web site. Goal: put the business together this year.  Hit 2M in sales by year end.  Target 20M in sales in two years, with a ramp to 100M in sales in four years. 

You are an Enterprise Architect working for Fabrikam.  You see the following two programs come up for funding review.  The company will only fund one of them.  Which one should they choose?

If you look at ROI alone, you should pick the first on.  If you look at alignment, you should pick the second.  Yet, in our scenario, if the company does not fund the second of these two programs, then the strategy will fail.  Using ROI to decide on funding decisions will produce misalignment.

Misalignment is the penalty for success  

My prior example was unfair, at best.  The choice is not frequently clear cut.  What if Fabrikam has two strategies: increase sales from the existing channel while building the new eCommerce channel.  Sounds typical.  But the devil is in the details. 

If there is only enough money to deliver one of those strategies at a time, then the decision is difficult but fairly clear.  But what if there is enough money for one initiative to be successful, and the other to limp along?  Then what?  Which one will be fully funded and which one will limp along?  Typical answer: the HiPPo decides!  Who is the HiPPo?  The Highest Paid Person of course.  The most senior person in the room, when a decision is made, will make the decision.  That is not a rational method, but it is a typical one.

Back to our example: Who will be the highest paid person: the sales executive whose business unit brings in $200M in sales every year, or the eCommerce guy who (presently) runs a cost-recovery operation?  I bet I can guess.  Given that approach, which of these two initiatives will limp along?  Will the strategy ever be delivered? 

Enterprises pay a price for success.  Successful programs will bring in revenue.  Therefore, in the battle for internal enterprise resources, successful (existing) programs will frequently win over innovative new programs, regardless of their relative strategic importance to the enterprise.  One reason is that decisions are often made by the HiPPo, and the Highest Paid Person is nearly always tied to the most successful programs.

Someone has to come down on the side of innovation and business strategy.  That is the job for Enterprise Architecture.  When resource distribution decisions are made, EA must be there to help insure that the most strategic program is given proper support.   Enterprise Architect insures that the company will “do what they say they will do?”

How to recognize alignment

I’ve seen countless attempts to create “traceability” as a mechanism to illustrate alignment.  Most of these attempts fail to deliver on the promise of alignment.  The most obvious reason: it is easy to create bogus traceability.  In other words, it is fairly easy for a person seeking funding for a really good idea to claim that the idea is aligned to a corporate strategy. 

Why is it so easy to create bogus traceability?  Because alignment is found after a chain of steps: strategy development, prioritization, initiative generation, and then funding.  A mistake anywhere along the way can appear as misalignment.  Conversely, an intentional bit of misdirection anywhere along the way can mimic alignment.   (For example, if a business wants a program to be put into play, then a business leader can create a “subgoal” specifically for the purpose of justifying that program, even if the subgoal is a poor fit to any of the organizational goals above it.  Business architects rarely wander up the entire tree.) 

To know if a funding request is aligned, use the acronym INStEP: Impactful, Necessary, Sufficient, Explicit, and Prioritized.  A funding request should meet all five criteria in order to be considered to be aligned. 

• Impactful: The funding request will clearly produce measurable impacts on the same metrics as a strategic goal for the enterprise.  For example, if the enterprise sets a goal of “increasing the average order value by 12% for existing Widget customers in the next six months” then an aligned program will either improve the ability to reach Widget customers, appeal to Widget customers, or encourage larger orders by Widget customers.  
   
  To be valid, this criteria cannot be indirect.  In other words, a funding request that builds a data warehouse so that Widget customer purchase history can be studied will be considered to be “somewhat less aligned” than a funding request for automatically presenting upsell information to Widget customers in the eCommerce store. 
   
  A funding request to install an ESB (Enterprise Service Bus) to handle online transactions would be “poorly aligned” and a funding request for “SOA certification for IT staff” would be “misaligned.”  Of course, this means that strategic goals for the enterprise have identifiable metrics associated with them.  Creating goals with no metrics is another way to create bogus traceability.  That’s a different problem (discussed below).
   
• Necessary: While the funding request may impact a metric that is strategic, alignment requires more than the potential for impact.  An aligned funding request is necessary in order for that metric or measurable impact to occur.  In other words, the request needs to be funded in order to get the metric to change.  Note that this doesn’t mean that the request represents the ONLY way to impact the metric.  It just means that it is a good way and if we want to impact the metric, we need to fund this request. 
   
• Sufficient: The funding request is complete.  There are no additional steps needed in order to complete the objective or to realize some kind of measurable value.  This one is not a simple criteria, because agile funding may drive very short projects (one-to-two months in duration) while some organizations may prefer long funding cycles (one-to-two years).  You will need to clarify what it means to be “sufficient” in your organization.
   
• Explicit: An explicit funding request includes specific statements about how the strategy will be impacted if the funding request is approved.  It will also include specific statements about the impact on the strategy if the funding request is denied.  In other words, the consequences of funding, or not funding, are explicit.  The goal is to make sure that the decision makers can see what will happen if this funding request is not funded.  This bit of practice also forces the team to consider the possibility that the funding request may not actually be necessary, and potentially withdraw the request before they embarrass themselves in front of the decision makers. 
   
• Prioritized: For a funding request to be aligned, it has to serve the needs of a prioritized business goal.  A prioritized business goal is one that is considered to be a high priority relative to other business goals in the same time frame.  For example, if the business has 30 business goals for the coming year, but only five of them are considered to be “high priority,” then a funding request against one of the high priorities should be considered “more aligned” than a funding request that serves the needs of one of the remaining items.

When the dog catches the car… How to handle misalignment

On the surface, the principle looks easy:  “Don’t fund it unless it is aligned to a strategy.” 

In practice, handling a misaligned program is not so simple. There are some key aspects to consider.

1. The decision makers in the funding process have to care about alignment. 
2. Your enterprise has to have an accurate way of describing or even quantifying alignment for each funding request
3. There has to be a way to alter a funding request to improve the alignment score
4. There has to be a reasonable way to restrict the funds that can be spent on misaligned programs
5. The selections, at the end of the day, have to be demonstrably aligned in order to permit credibility to the whole notion of alignment

One at a time, let’s look at these aspects:

Decision makers have to care about alignment: As I demonstrated above, it is possible for a funding request to have a “high” return on investment, and yet not be aligned to business strategies.  In that case, the question is simple: will the fact of poor alignment actually be considered as a criteria for decision making?

Quantifiable alignment score:  Alignment is not boolean (True/ False).  Alignment is a spectrum.  A funding request may be well aligned to one strategy while being partly aligned to another. Another request may only be poorly aligned to any strategy at all.  I encourage you to create a formula of some kind that helps your enterprise architects or business analysts come up with a number (between 1 and 100, perhaps) that represents “how far” the funding request goes toward being “very well aligned” to enterprise strategy

Altering funding requests: if there is a way to create a “score” for alignment, then the folks who create these funding requests will quickly learn how to create funding requests that produce high values on that scale.  This is the healthy and correct behavior. Encourage it.  The net effect will be that the scope of specific funding requests will be modified to order to produce a better number, and, in doing so, we will have produced the intended effect of insuring that funded programs will do the work that Enterprise Architecture wants to see get done.

Limits on budget for misaligned programs: We want to rig the system so that funding requests that are well aligned are going to be more likely to get funding than funding requests that are poorly aligned.  This has the healthy effect of producing a focus on alignment when these ideas are hatched.  On the other hand, a strategy usually describes a change to the enterprise.  In most cases, there are metrics that just as important, but don’t show up in a strategy.  Those metrics may have a lot to do with maintaining the status quo or making minor improvements.   For example, let’s say that Fabrikam has an excellent reputation with its customers.  Survey after survey comes back with a 90% customer satisfaction.  It is possible that there is no strategy, this year, for improving customer satisfaction.  That doesn’t mean that the business would be happy if customer satisfaction starts to drop. 

Demonstrable use of alignment score:  This aspect is related to the first aspect above: caring.  Do the decision makers care about the effort needed to produce that application score?  The proof is in the pudding.  After all the dust is settled, and a final list of funded programs can be produced, it would be important to show that the alignment score was actually considered and found useful in negotiating the scope, timing, and level of funding for a particular program. 

Moving to Mature: Steps to building a better alignment program 

The following section discusses some ideas for addressing the misalignment problem that I’ve outlined above.  There are a couple of steps needed to address misalignment.  They are not in specific order, but all have to be done. 

Addressing Misalignment, Part 1: Prioritized Strategies

Now we get to the core of the issue.  We can understand what misalignment is, and how misaligned programs get funded.  It is time to discuss mechanisms to address the issue. 

The first thing to realize is that misalignment is caused by a lack of clarity.  When a business leader creates a business goal, the best advice we give is to be SMART (Specific, Measurable, Achievable, Realistic, and Time-Based).  We ask for five things, yet we don’t ask for the most important thing: prioritized!  If there is only one business goal, that makes sense, but I’ve NEVER seen a business create a strategy that can be expressed in only one business goal.  I’ve never seen an organization (of more than 30 people) with only one business strategy.

In order for alignment to be executed, a model must be created to allow for resources to be allocated to enterprise strategies according to their relative priority.  But this is difficult because, especially in very large organizations, there can be an entire “tree” of strategies and goals.  To be accurate, it isn’t a tree, but rather a “directed acyclic graph” because each of the lowest level goals can be aligned to many goals at the next higher level.  I didn’t draw the alignment links on the diagram, as a result.

There are two approaches to insuring that priority is understood.  One is to remove emotion by examining the goals using mathematical models, and the other is to include the leaders directly in the decision making.

• Method 1: write down all the goals (all layers of the tree above) and create a model showing alignment.  Create a mathematical model for calculating the relative priority of those goals with respect to one another.  Calculate answers and present the results back to the leadership.  Present those results when making resource decisions.  Potentially drive program budgets from that relative prioritization.  
   
• Method 2: Write down only the high level strategies/goals and get the leaders to discuss relative priority.  (There should be no more than 20 items on the list).  Then, include those leaders in the decision making process.  Get the full leadership team together at the beginning (to decide priority) and at the end (to discuss all controversial decisions).   Any one leader can make a decision.  However, if an individual leader goes against the recommendation of an empowered team (like the EA team), then the decision is considered controversial and is escalated up for review by the full leadership team.  Full team review should be done a couple of times per year in a rhythm.  Every leader is required to attend. 
   

I believe that Method 2 (direct involvement) is far superior. 

At Microsoft, we put together a project, as an experiment, to gather all of the goals for a single line of business and create that hierarchy.  We collected one year’s worth of goals, and then spent 15 months analyzing the list before they could be presented to leadership.  By then, the goals were obsolete.  Clearly, there were no useful results from that exercise.  Why didn’t the idea work?  Because we tried to solve a “human” problem with “mathematics.”  It’s a bit like writing an algorithm to decide who you should marry.  Lesson learned: comprehensive goal mapping can be too slow of a process to be useful.

Addressing Misalignment, Part 2: Clear Accountability

In the section above, I discussed “how priority is created.”  In this section, I will discuss “who makes the decision.” 

In the war to combat HiPPo, there are a couple of different approaches that an enterprise can use, each with their own advantages and disadvantages.  (In the list below, I’ve included a few high level alternatives.  If, dear reader, you’d like me to include more options, send that option to me, along with perceived pros and cons, and I’ll update this table.)

Which accountability mechanism SHOULD you use?  The jury is out.  Each is good and bad. 

I’ve seen both mechanism 1 (strategy owners) and mechanism 2 (single executive) at play.  My current employer, Microsoft, has a strong preference for the second mechanism, with the “senior executive” being nowhere near senior enough to produce anything other than a silo in processes, information, and systems.  In some cases, we use Mechanism 3 (committee of executives) but the resulting funding processes are non-agile. 

Mechanism 4 (empowered team) is fact-based and thorough, but also risky and potentially bureaucratic.  I’ve only heard rumors of it being attempted.  If you have first hand knowledge of this mechanism, any other ones I didn’t mention, please let me know.

Addressing Misalignment, Part 3: Trusted Decision Process

Leadership is a challenge in any organization.  It is not easy to get a wide array of different people to come together to achieve a goal.  Books, seminars, training classes, and mentorships all focus on the issues surrounding leadership: recognizing, becoming, and encouraging leadership. 

One key facet to leadership is that the people cannot follow a leader whom they do not trust.  Yet, in corporate America (and I imagine in other parts of the world as well), companies frequently suffer from managers who make decisions and then simply assume that everyone below them will buy in “because they say so.”  That is not leadership.  That is dictatorship.

To build a trusting relationship is important, and each enterprise will address this issue in different ways, depending on their own culture.  Most will include some or all of the elements illustrated by Stephen M. R. Covey in his book “The Speed of Trust” (see this excellent article).  Taking this advice to heart, in an organization, means building trust into the decision making process itself.

Specifically, I would encourage organizations to focus on Honesty, Transparency, and Continuous Improvement in their decision making process.  These elements are key to building a process that allows decisions to be made, especially difficult decisions, in a way that encourages every stakeholder to execute on them.

Honesty – The funding process cannot make decisions without honest information applied in a fair and balanced way.  If the process requires that every project declare the goals that it supports, it is not honest to indicate a goal when the project will not actually deliver value in that way.  It is not honest to indicate a greater return on investment than would likely occur.  And it is not honest to indicate that value will be achieved more quickly than reality.  For example: if a project is designed to address some problem in determining sales force commissions, it is not honest to tie that project to a goal of “increasing sales.”  It is important to address that problem, but addressing the problem doesn’t increase sales… it lets you pay them fairly.  Different problem. 

Transparency – The funding process cannot make decisions in secret.  To be effective, alignment decisions will not always be easy.  Sometimes, good efforts must be halted, and sometimes good systems must be retired.  To people who see the value in an effort, the decision to halt it is counter-intuitive and suspect.  Team members will ask, “What were they thinking?”  It is absurd to expect that employees are not aware of company politics, and it is absurd to expect them to feel comfortable with counterintuitive decisions if they believe that politics may have played a role in making those decisions.  If you want a decision to be made, and then followed, it must be made in a transparent and fair manner.  Honest concerns must be given the opportunity to be aired, and fair representation and judging must be applied.  This is an important part of building trust, and when employees trust the decision process, they are far more likely to follow the results.

Continuous Improvement – The people involved in decision making are people.  They make decisions that won’t always be correct.  In order to build trust, you have to be willing to listen to people who tell you what went wrong, and then act to right the wrongs.  The process has to flex in a visible manner to address issues that have been raised and are widely held.  All processes, when created, are immature.  Only through self-improvement can those processes become mature.  Once a process is mature, it is difficult to find a flaw.  Mature processes build confidence and trust.

Addressing Misalignment, Part 4: Valued Data Collection

Every decision creates winners and losers.  One of the goals of alignment is to make sure that “explicitly prioritized business strategies” are the winners in those decisions.  Of course, there are folks who don’t like to lose, even if their loss is the company’s gain.  To win these people over, apply logic to real data.  Don’t just assume that everyone will “just trust” you.  Collect data and present it. 

Data collection, in support of difficult decision making, is our fourth area of focus.  When making decisions, you frequently have to collect information from other parts of the company, from the marketplace, from partners, and even from competitors.  That requires impartial and trustworthy people who are responsible for collecting that data, using a simple, open, clear, and repeatable mechanism.  

I’ll list two examples of data collection, but I can think of many more. 

In these examples, your enterprise has two (or more) IT groups. Both need to send e-mail to customers (one for marketing purposes, and the other for transaction and incident support purposes):

• Example 1: Customers receiving the marketing mail are reporting that the mail is landing in spam filters over 40% of the time.  The business sets out to find an e-mail solution that can send e-mail without it being immediately marked as spam, and they find a service that charges 5 cents per 100 messages, and promises that it won’t be treated as spam.  The IT team wants to know if it makes sense to outsource this function.  Are there other groups with better success at sending e-mail without it hitting a spam filter?  Are there already other solutions in use in the enterprise for sending e-mail, and if so, can those systems be leveraged?  Does it make sense to invest in a new system that may duplicate existing functionality?  Better collect some data.
   
• Example 2: Your company decides that customer loyalty is a high priority, and to improve loyalty, the leaders have set a goal of insuring that out-bound e-mail is correctly managed.  You, as the enterprise architect, decide to focus on consolidating these overlapping systems so that new features can be added to one system instead of two.  Which system should be retired?  Will the losing system’s stakeholders be happy about it?  They may be if you can show, through valid data, that it makes sense to select “the other one.”  Better collect some data.

I’ve seen many situations where the collection of data is simply left up to an engineer or program manager.  This is ad-hoc and sloppy.  In order to address misalignment, there has to be a managed mechanism for people to store and retrieve information about their systems, as well as a person or team of people accountable for collecting information in a consistent, rapid, and trustworthy manner. 

It is difficult to base decisions on data, if the data cannot be trusted to be accurate and complete.

Addressing Misalignment, Part 5: Demonstrable Results

“Fool me once, shame on you.  Fool me twice, shame on me.”

It should be abundantly clear by now that alignment is going to require difficult decisions.  If your budget is shrinking while new strategies have to be funded, an existing program (or even a line of business) may need to be closed down.  That takes time and money.  Feelings can be hurt.  There can be a great deal of stress involved. 

Let’s say that I’m a stakeholder who ends up on the “losing” side of a governance decision.  I’ve heard the reasons for the tough decision, and while I may agree to do what is necessary for the good of the enterprise, I may not be happy about it.  In fact, I probably won’t be happy about it.  I may view alignment as “outside meddling” or worse. 

As an Enterprise Architect, you have to care about all of the stakeholders, especially the burned ones.  If you are to look at the list of stakeholders, and follow good old-fashioned stakeholder management principles, you will track whether your stakeholders have sufficient understanding, commitment, and support.  However, a stakeholder who ends up on the “losing” side of one alignment decision may become an opponent to alignment altogether unless you give him or her a reason not to regret their previous support.

That is where demonstrable results come to play.  It is difficult to get alignment on a single area of the business.  It is nearly impossible to get alignment across the breadth of a large and complex enterprise unless you can tout demonstrable results.  Each time you discuss alignment decisions, especially with the next stakeholder who may end up on the losing side, it is immeasurably helpful to cite a case study, from within your own organization, that illustrates how alignment provided benefits in the past. 

This is critical.  Your alignment program can get started without stakeholder management, but it will not sustain unless you can collect “Stories of Value” that are meaningful to both past and future stakeholders.  The stories have to be consistently collected, clearly described, and measurably accurate.  They have to be kept up to date.  You are only as good as your last success, and if your last success story is three years old, future stakeholders will start to doubt your ability to deliver.

Conclusion

Alignment is one of the key accountabilities of Enterprise Architecture.  To be able to deliver on the promise of alignment, it is imperative to understand what misalignment is, what to do when you find it, and what improvements to make in your EA program in order to be able to drive out misaligned program requests in an open, trustworthy, and repeatable fashion.