For the last 10 years, better strategic alignment has been either the first or second most important goal of CIOs in all industries, according to a variety of IT publications. In my experience, if a particular issue doesn't get resolved in a reasonable period of time, then it might be time to question what problem we as an IT community are really trying to solve. With regard to strategy alignment, I would suggest that "what we have here is a failure to communicate" -- a failure that is so deep-seated that neither side even realizes exactly what is going wrong (hence the same issue topping a list for 10 years).

I have been struggling with this exact problem as the director of a project management office (PMO) in an IT organization committed to providing excellent value to the business units of the Massachusetts Medical Society (the Society). When we initially formed the PMO 10 years ago, its primary focus was on consistent and repeatable execution of projects. It concerned itself with project health, project results, and resource management. It provided what we hoped would be right-sized methodology to ensure project execution was as efficient as possible. The PMO also trained project managers to understand the business goals that set their projects in motion and to focus on creating the plan and facilitating the actions that would achieve those results.

I believe we made great progress toward achieving our initial objectives, but like the CIOs polled in the surveys mentioned above, we weren't really sure if this was enough to satisfy the business. In 2006, we began asking ourselves not whether we were doing projects right but whether we were doing the right projects. What we found was that ensuring we were doing the right projects was a little more complex than we originally thought, because "right" is such a nebulous term. Is a project right if it aligns to strategy but is a hard-to-maintain point solution? Is it right if it's congruent with our enterprise architecture but isn't spot-on with exactly what the business originally asked for?

Our second significant realization was that just aligning with the business wasn't enough. To make sure IT was delivering the highest possible value to the Society, we needed to be contributing innovative ideas as to how the business could accomplish some of its objectives -- not just executing what we'd been handed.

A FOUR-PHASED APPROACH TO ALIGNMENT

Based on these realizations, we began to rethink our relationship with the business as well as our own expectations of ourselves. With the help of Knowth Consulting, we initiated a strategic planning effort based on the Four-Phase Strategy Cycle (see Figure 1) that lays out our current view of how we should be interacting with the business and what we should be concentrating on inside IT with reference to maintaining excellent strategic alignment.

Figure 1 -- The Four-Phase Strategy Cycle.

The cycle begins with business strategy, which in turn informs the IT strategy, which then reinforces new business development. We developed our strategy with the assumption that the internal business units were the customers to whom we needed to sell our product. This approach enabled us to close the cycle loop and envision the new platforms necessary to drive the future business.

The fact that we recognized the importance of creating a strategy says a lot about our desire to move from basic service delivery to business partnership. We were committed to shifting from application-specific solution delivery to enterprise-focused solution delivery that leveraged reusability, flexibility, and capacity for future innovation. We were also determined to complete the handshake with the business by more effectively reflecting back to them what we understood of their requirements -- not only the technology delivery, but also the information needs and work process changes that might be generated by a new business initiative.

Business Strategy

Scanning the Business and IT Landscapes

To better decipher business strategy in IT, we adopted two techniques. The first technique we used was to develop a Business Fitness Landscape model (see Figure 2) for each of the business units and for IT itself. This technique (based on the Porter Five Forces Analysis [1]) offered us a way to show our business colleagues that we understood the pressures they were under. It also served as an easy way for us to more widely disseminate this information back into the various areas within IT. Development of this model was also a critical step in giving voice to the IT relationship managers who struggle to keep the priorities of their products and business units at the forefront of IT resource and portfolio management.

Figure 2 -- The Business Fitness Landscape model.

For IT, the Technology Fitness Landscape (see Figure 3), created by completing an industry scanning exercise, revealed for us just how important this kind of research and discussion is for keeping up on key technology factors that will impact business outcomes. Industry scanning was not a consistent habit for us, but now it is an imperative part of our standard operating procedure. We must devote the time and leverage our research services in order to stay abreast of:

• Our partners and their roadmaps
   
• Regulatory issues, such as those governing security and credit-card processing
   
• The sociocultural issues facing our external and internal constituents
   
• Business trends for medical societies and Web publishers
   
• The newer technologies for content delivery that can enable future business outcomes
   

Figure 3 -- The Technology Fitness Landscape.

This knowledge puts us in a much better position to translate business strategy into technical roadmaps that are clear in their connection and relevance.

Well-Formed Strategy Statements

The second technique we adopted is the development of well-formed strategy statements (WEFORSS; pronounced "we-force").¹ The purpose of a WEFORSS is to ensure alignment. Strategies do not need to contain numbers; they need action sequences in which the output of action 1 is the input of action 2. In addition, a WEFORSS contains a specific action and relatively specific resources, but not a specific occurrence of that action or a named resource. For example, a strategic objective of the Society is to:

Enhance strategic branding to promote the effectiveness of the MMS image through internal and external marketing and advocacy.

Following the rules of a WEFORSS, a clearer way to look at this statement might be:

Create a consistent brand to allow for easier and faster identification of the work done by the MMS in whatever format a member physician might encounter it.

By restating the strategy in this fashion for IT, it's possible to begin to ensure that the right work (brand visibility) is done for the right audience (member physicians) in all areas of the business (on the Web and in print). It also has the advantage of making it much easier for the business and IT to refine the alignment if for some reason the strategy as defined isn't quite what the business unit had in mind.

Referring back to Figure 1, it is in the space between creating the business strategy and supporting business point solutions that the PMO took a lead role in the development of well-formed IT strategy statements, strategy maps, and themes. Even a strategy exercise can be treated as a project with a series of workshops, deliverables, a timeline, stakeholder management, strong sponsorship, and a well-executed communication plan. A successful outcome for a strategy exercise would be a reusable framework, a published document or communication portal, and a series of supporting mechanisms to ensure the strategy is being executed at a portfolio, project, and staff level.

One approach we took before crafting the WEFORSSes was to first develop a theme-based strategy map (see Figure 4) across two dimensions:

1. The popular balanced scorecard categories (cost savings, customer focus, operational excellence, and knowledge capital)

2. The IT performance themes we identified as critical to our decision making for resource and portfolio allocation (nimble, focused, collaborative, reliable)

Figure 4 -- A theme-based strategy map.

Taken individually, each theme can become a liability if pursued too aggressively at the expense of another. Together, they become a balanced approach to managing our operations and staffs. For instance, one of our strategy statements identifies the need for a stable and secure infrastructure to ensure business continuity. This strategy was generated by the balanced scorecard theme of operational excellence and our performance theme of reliable.

The resulting strategy map does not necessarily communicate our strategy well or do justice to the up-front research and exhausting facilitation required to collect our thoughts and think at a level above tactical planning. But it does serve to illustrate how we generated the themes that formed the core of our WEFORSSes and performance objectives in IT.

Other workshops in support of strategy definition included a discussion on tactics. What specifically was required to support the strategy? Did we have all the necessary roles, skills, people, processes, and tools? Were organizational changes required? In our case, two new departments were born in IT -- Web user interface engineering and enterprise content delivery -- to support the business shift from a print-based to a Web-based publishing enterprise. We needed to identify the projects and budgets required to implement our strategy, create an integrated business and IT portfolio, vet the portfolio, and define how we would track and measure the success of our IT portfolio. We needed to agree on the reinforcing feedback loops; that is, the mechanisms for reviewing our strategy and its execution.

Point Solutions

Once there is general agreement as to what the strategy is intended to accomplish and what resources will be used for that purpose, it makes sense to further flesh out the inputs and the outputs, or to develop what is generally known as a high-level requirements/design document. We attempt to keep this step fairly short, since we do not want to get wedded to a solution that no one has the will to change. Our goal is to understand the specifics of each new project well enough that they can be evaluated against our enterprise planning strategy to see whether the point solution should be done as a one-off or whether it can be more tightly integrated with our existing EA approach.

System Solutions

Talking with peers and consultants, we realized that we had to add a step at this point. We needed to take the requirements as the business and IT understood them and then stand back from the problem and the proposed solution to see if there was a higher-level, more systemic solution possible. As an example of what I mean by system solutions versus point solutions, one comment we heard repeatedly from the business was that it was impossible for IT to provide a unified view of our customer behavior. Like many other IT groups, we had solved one problem for one group and another problem for another group, and so on. Consequently, our customer data was contained in four systems, none of which talked to each other. We knew that we needed to solve the problem and keep it from happening again with other systems. The trick, however, is figuring out how to best link the enterprise planning to the point solutions so you can meet the specific requirements of the business unit or product without sacrificing future flexibility.

To illustrate, a project we are working on now to enhance our customer service department's operations screen (customer information lookup) is going to meet that department's specifications, but the services being created will have the ability to look up data from all four customer systems even though only two might be required to meet the specific needs of this application. Now we have services that are built for future customer lookup requirements and are able to serve other applications. The outcome of this analysis is a system solution that should decrease the cost of operations in the future and keep the investment going into a sustainable infrastructure.

Innovative Solutions

IT is the one place where all systems requirements and desires are consolidated throughout the organization. Therefore, IT has the unique opportunity of looking beyond the immediate needs to completely new solutions that only emerge when all the pieces of the system are looked at as a whole. Results from this step won't be instantaneous for those of us playing catch-up, but we are confident that as we move into a more robust enterprise application architecture approach, new possibilities will emerge.

As significant an improvement as we think more systemic systems will be, we know that we can always do better. A review of classic IT strategic planning literature often shows IT and business planning moving in parallel directions [2] with regard to the strategy process. Based on our experience, we've found that this really only applies when it comes to innovation. Individual business units will always be the first to come up with new ways to enchant their customers, but IT, because of its unique knowledge of technology, should be the first to recognize new ways to innovate with regard to information. (After all, the initials do stand for "information technology.")

Our first attempt at this was to bring our best technical people together in a room and ask them to discuss emerging technologies and any all-around "better mousetraps" they saw coming in the future. To be honest, our first attempt was a little frustrating because the conversation kept coming back to current tactical problems. Nevertheless, to our complete surprise, the concept of scanning and assessing emerging opportunities eventually took root -- it just needed time. IT management is now investing more aggressively in research services and taking advantage of automated scanning on trends we identify. We are driving down through our IT functional areas the habit of staying on top of trends. We are also utilizing this research and engaging industry analysts on a case-by-case basis, specifically to validate and inform our enterprise planning for services, content, and business intelligence. The final step in this process is to offer innovative ideas and to help the business brainstorm how it might use the technology. IT in this situation can serve as a catalyst for new business strategies by sharing technological innovation back with the business.

The impact of innovative thinking won't be immediate for us, given that our concentration for the coming year will be on developing and delivering technical roadmaps in support of the needs of the various business units. But we are committed to innovation, and once we've begun to move further into the step of developing integrated and congruent applications that can serve multiple purposes, we believe that innovative opportunities will naturally begin to emerge.

MOVING FROM THEORY TO PRACTICE

All too often in articles like these, everything sounds so simple. The authors always make it seem as though if you just do what they suggest, you'll be met with instant success. I'm here to tell you it isn't true. As I stated in the first paragraph with regard to strategy alignment, "what we have here is a failure to communicate." No matter how good the strategy, if the business isn't hearing IT or IT isn't hearing the business, there will be bumps in the road. What I'd like to do in the rest of the article is to provide mini-lessons learned based on our experience of actually conducting the strategy process outlined above. Needless to say, we experienced some significant communication breakdowns that underscored just how difficult alignment is to create.

The Dialogue Breakdown as It Relates to Solution Delivery

In this scenario, the business unit leads and product managers want their specific requirements met just as they've articulated them. IT wants to leverage reusability. Business unit leads and product managers typically don't want to play with each other, and they certainly will object on general principle if they feel they are being made to conform to an enterprise solution. Some of their objections are based on a deep-seated fear that IT will once again fail to solve their problems in the rush to standardize. They are also justifiably worried that even if IT has the right of it with regard to the technology, opting for an enterprise solution will end up taking a long time and will distract from the business unit's or product's immediate needs.

How Does IT Facilitate a Solution?

Don't espouse in meetings with business folk the benefits of enterprise solutions, enterprise applications, enterprise services, enterprise anything on its own merits.

Do create mechanisms for a project linkup between the solution architect and the enterprise IT function to ensure that high-level, organizational requirements (services, systems, technology, data) are considered or built in conjunction with the application-specific requirements. It is better to have the enterprise discussion in concert with how it solves a business problem, or how it creates future business opportunity, than in a vacuum. It's better to get a little bit of the enterprise-strategic goals met in every project than to impose a big-bang enterprise solution that doesn't look as if it maps to any specific business outcome.

The Dialogue Breakdown as It Relates to Overall Relationship Management

The business wants to work with people it trusts. Trustworthiness is defined as knowing the business, speaking the language of the business, understanding the technology that drives the business and being able to explain it clearly, and, most importantly, being someone who is adept at creating options (not obstacles) for moving the business needs forward.

Business leads and product managers don't want to explain their business over and over again. They only want their trusted IT partners in meetings discussing their ideas and helping them make decisions, and in an ideal world, these individuals would be sourced to their every project. IT, on the other hand, wants to be able to leverage all its personnel, creating as much overlap as possible to efficiently balance operational and project needs across the enterprise.

How Does IT Facilitate a Solution?

Don't ignore the relationship problem. This is one of the most critical mechanisms for communicating business concerns and priorities in IT and for fostering IT-business alignment. Also don't assume anyone in IT can be the relationship manager. It is great if someone with a strong technical background can play this role, but more often the key is the soft skills: strong facilitation, negotiation, influencing, communicating, business orientation, and proactive management for results.

Do create the relationship manager role and a mechanism for this person to advance his or her relationship with the business. In our case, we assign the relationship manager to one or several of the business units in the organization. The relationship manager establishes a regular meeting (usually monthly) with his or her key business leads to review the business/technical project portfolio and address any concerns or needs. The relationship manager also helps initiate technical projects or programs for the business. All this information is brought back into IT via weekly meetings that help us identify how our portfolio, staff, and operations planning should be calibrated.

The relationship manager role is vital to our efforts to facilitate business collaboration, but we also rely on other roles to consistently manage business areas; namely, our project managers, Web producers, business analysts, and solution architects. The deep understanding these folks bring to the business and back into IT enables effective delivery of point solutions, efficient use of supporting IT functions, and critical input to EA planning.

The Dialogue Breakdown as It Relates to "Knowing the Business"

Business leads and product managers want an IT group that can anticipate where their business is heading and recommend how technology can help them get there.

IT does not have enough resources to embed someone into every business unit or product group and doesn't spend enough time keeping abreast of the business and technology landscape.

How Does IT Facilitate a Solution?

Don't assume that getting smarter can happen quickly, but don't give up on getting smarter.

Do consider an industry-scanning program in IT. For example, purchase access to analyst-type organizations for their research and industry experts. Exploit their services for topic-based scanning to address gaps identified in IT solution delivery. Encourage knowledge transfer (e.g., utilizing internal Web portals, informal lunch-and-learns) from the folks who are attending conferences and going to the business meetings.

Most importantly, support those folks who delve deeply into research by making sure that time spent on research is considered just as valuable as the operational work. Dispel within the IT family the notion that reading/scanning is not productive work. Instead, make it part of people's jobs. Expect it. Place performance goals around it and watch trust develop through relevant knowledge.

KEEPING STRATEGY ALIVE

The biggest concern I heard in conducting the IT strategy exercise was the not-unreasonable belief that the ensuing document would be produced and promptly ignored. Life would go on as before, and this energy would have been wasted. Based on these concerns, we've worked out a three-pronged mechanism for keeping strategy alive:

1. Publish it.

2. Track it.

3. Validate it through performance management.

Publishing our strategy was as critical as implementing it. It was important that we could describe, in business-speak, our thought process and that it existed as an artifact to distribute. So, yes, a document for the shelf is significant because we needed tangible evidence of our effort and understanding. But more valuable is the ongoing conversation that takes place when you utilize the online communication portal to further elaborate on ideas and do contextual reporting of progress.

With regard to tracking, we identified three major ways in which to track progress. First is our weekly IT staff planning meeting, where IT functional and relationship managers meet to review project activity tracking, discuss priorities, and highlight any concerns. The goal is to ensure our portfolio remains focused on the most critical business priorities. Second is our biweekly IT director meeting, where we discuss overall strategy and budget alignment, using the metrics identified in the strategy process. For example, building Web services is a key strategy: how many services have been built? Third is utilizing the project discovery stage to encourage the linkup between solution architects and PMs so as to feed back the point requirements to the enterprise team. In this way, the commonalities between efforts and the key business needs are illuminated, thus better informing our enterprise roadmaps.

Finally, we validate the importance of the strategy by linking it with our performance management system. We have enhanced our performance tracking system to include a strategy linkup. This is a list of the key objectives that will tie each individual in IT to the most critical business priorities. We believe that the goals we put into our performance management system reflect our contracts with each other and with the organization to deliver on the most important things.

In the final analysis, I certainly wouldn't say we're there yet, but we feel both excited and encouraged about the way things are going. We're hearing feedback from the business that "we're getting it," and we believe our new focus on enterprise technology -- and more specifically, service-oriented architecture -- will help us build a more efficient and flexible infrastructure. My hope in sharing our experiences is that others will investigate how the PMO can help improve the process of strategy alignment in their organizations. Perhaps now, we in IT can finally move "better strategic alignment" a few notches down on the CIO's priority list.

NOTES

¹ My thanks to Victor Rosenberg for the concept of well-formed strategy statements.

REFERENCES

1. Porter, Michael E. "How Competitive Forces Shape Strategy." Harvard Business Review, March-April 1979.

2. Venkatraman, N., J.C. Henderson, and S. Oldach. "Continuous Strategic Alignment: Exploiting Information Technology Capabilities for Competitive Success." European Management Journal, Vol. 11, No. 2, June 1993, pp. 139-149.

ABOUT THE AUTHOR

Bonnie Cooper is a 20-year IT professional and is currently Project Director of the Massachusetts Medical Society's IT Project Management Office. Early in her career, Ms. Cooper managed application and network migrations for Zayre Corp. and Dun and Bradstreet Software. In her tenure with the Massachusetts Medical Society, her project portfolio includes The New England Journal of Medicine's manuscript tracking, advertising management, and corporate enterprise resource planning systems. In her current role, Ms. Cooper is responsible for coordinating the efforts of project teams, overseeing the implementation of project standards, managing the portfolio and strategic planning exercise for IT, and leading the project to redesign the member Web site of the Massachusetts Medical Society. Ms. Cooper can be reached at BCooper@mms.org.