OCM Revisited – Part 2: Organizational and Individual Change Management

Per my previous post, there are a number of frameworks that may be used to transition a change strategy to a useful plan. It would be difficult to do them all justice without writing a book (which will not be happening here).

Fortunately, there is a wealth of change management information on the web that you may peruse at your leisure. Most often, search engines will find these frameworks:

•    ADKAR: Awareness, Desire, Knowledge, Ability, Re-enforcement
•    Lewin: Unfreeze, Transition, Refreeze
•    Kotter: 8-Step (Urgency, Coalition, Vision, Communication, Empowerment, Short-term Wins, Consolidation, Anchoring)
•    Kubler Ross: Transition Stages
•    McKinsey: 7-S (Strategy, Structure, Systems, Shared Values, Skills, Style, Staff)

All are worth understanding, however, as one of my mentors once told me, “Eric, all models are wrong, some models are useful.” The same wisdom applies here.

The change process cannot – and should not – be reduced to a simple formula. While each of these frameworks has its pros and cons, none is the magic silver bullet for change.

Each framework addresses the major transformational questions with a different perspective on the change process:

1.    Why do we need to change?
2.    What are we going to change?
3.    Where are we making the change?
4.    Who will be impacted by the change?
5.    When are we making the change?
6.    How are we making the change?

The Kotter model is closest to the method that I use. In practical application, I’ve found “Urgency” can be the most challenging for leadership to address, as the status quo may be well suited to current conditions and may well be one of the pillars of current business success. It takes particularly courageous, forward-looking leadership to sponsor or initiate change in a successful business environment.

These are my fundamentals of transformation:

•    Building a Vision (or Future State, if Vision seems too squishy) based on the needs of the business
•    Partnering with Stakeholders (to refine and describe the metrics and measures of success)
•    Communicating the Vision and Setting the Stage for Transformation (describing the plan and engaging change leadership)
•    Developing Communication and Feedback Mechanisms (setting expectations for regular dialogue and check-pointing progress)
•    Adapting Management Systems to Support the Transformation (rewarding new behaviors, enabling new capabilities)
•    Declaring Victories and Moving On (celebration and building on achievements)
•    Adaptation and Ongoing Continuous Improvement (the cycle of change really doesn’t end)

Hopefully, this post has shed some light on the process side of OCM and, along with the previous post, has successfully delineated between that and change strategy. The two are obviously related, but at the end of the day are both different, interdependent and both necessary for successful transformation.

OCM Revisited: Change Management Strategy

Whenever I’m consulting on IT Transformation, the topic of Organizational Change Management arises, either directly or indirectly. For folks who have read my blog for some time, it is a familiar topic, as it is a particular passion of mine.

In recent consulting engagements, some confusion has arisen between two elements of OCM:

•    Process of change at the individual level
•    Change strategy at the organizational level

This post will focus on the delineation between the two and briefly discuss change strategy.

For a transformation to be successful, it must have three characteristics, all of which require a robust OCM program. Let’s define success as follows:

1.    The Transformation has achieved the outcomes that it set out to accomplish. (ref. BCC #1).
2.    The Transformation has not done significant harm to the remaining transformed organization, to other functions, or to the business.
3.    The Transformation is sustainable and able to endure for a period of time that justifies the investment in the program.

The supporting OCM program deals with both the:

•    Needs of the individual in moving through the change process
•    Strategy that is used by leadership, which drive tactics at the organization level

There are four major change strategies defined in The Planning of Change by Bennis, Benne and Chin (Holt, 1969). They are quite useful in framing what different approaches look like and are very descriptive in their names:

1.    Rational-Empirical (people will act in their own self-interest, therefore key tactics are communication and incentive-based)
2.    Normative-Reeducative (people will follow the herd on redefined norms and values, therefore key tactics are participative and group-based)
3.    Power-Coercive (people will do what they are told to, therefore key tactics are authority and sanctions-based)
4.    Environmental-Adaptive (people will adjust to new situations, therefore land them in the new world and burn the ships)

It’s interesting information and I highly recommend reading the book. In real-life organizational transformations, however, it is not practical or advisable to use only one strategy. Each transformation will have a unique set of tactics from each strategy, depending on:

•    Scope and Scale
•    Degree of Resistance
•    Size of Organization
•    Degree of Risk
•    Time Frame
•    Internal Expertise
•    Current Staff Dependency

The “amount” of each of these considerations will drive the selection of strategies and tactics employed for the organizational transformation. There is no “one size fits all” strategy/solution set and getting it right will either position your transformation for success or doom it from the outset.

There are a number of change management frameworks that help transition the strategy to the tactical level. A discussion of these models will be the starting point for my next post on the process of change at the individual level.

Business-Centric Change #4 – Coda

After the last milestone of the transformation program, the IT Organization always has one question: “Are we done?”

The true and discomforting answer is “No.”

Despite the great effort expended in identifying “The Problem,” refining “The Solution,” and executing it with particular attention to Organizational Change Management and counsel, the change is not complete – simply because it never can be, as the transformed organization is always evolving.

The true and perhaps more comforting answer is “No, and here is why.”

•    “We will have Process, Technology and Organizational changes due to Service Delivery Failures and failing to meet Service Level Agreements brought about by Problem Management and Root Cause Analysis.”

•    “We will have improvements to our IT Services caused by the Continual Improvement Process led by our Service Managers.”

•    “We will have improvements to our IT Service Management Processes caused by the Continual Improvement Process led by our Process Managers.”

•    “We will have new IT Services demanded by the Customers of our Business and our Business Customers.”

•    “We will have changes to Technology as new technologies become available and other technologies mature.”

•    “We will change our Organization to reflect the changes in our Business Strategy, IT Services and Technology.”

These changes are on the surface smaller than the recent transformation, and can be every bit as full of impact on the organization, particularly if the change is in the sourcing of IT Services.

The Transformation Triangle can be used to assist in the explanation, as it has arrows indicating a cycle of impacts around the vectors of Process, Technology and Organization. None of them are static for long.

With all that said, do no forget to take the time to declare victory and celebrate the completion of a successful transformation with your organization. It’s been a tough road and you’ve all earned it. But you must also create an expectation that the process of change has not ended as the organization continues to evolve within the new paradigm.

Business-Centric Change #3 – Counsel

One of the greatest quotes on the frustration of executing a plan comes from a poem by Robert Burns called “To a Mouse.”

The line from the poem that most people are familiar with is

“The best laid schemes o’ Mice an’ Men,
Gang aft agley,”

The poem is about a farmer who turned up the nest of a field mouse with his spade during fall plowing. The mouse had built her nest and planned to spend a comfortable winter in it. Now, she would have a difficult time surviving the winter because there was no time or material for her to build a new shelter. The poem is an apology to the mouse and a display of empathy by Burns who compares his lot in life to that of the mouse.

The quote from the poem is generally thought of as a resigned recognition that with any plans, issues are inevitable. True enough, but in the context of the poem, I see the meaning somewhat differently.

People get sick and tasks get delayed; changes need to be made to the plan. This is work that good program and project managers handle all the time, no worries.

Getting whacked by the farmer because you built in a place that gets plowed every fall is another story. The revised moral of the story – don’t set yourself up for failure.

The remainder of this post is my “Top Ten” list of considerations to minimize the potential of “getting whacked” during program execution.

1.  Leadership Time Impact: Recognize that the transformation is a large amount of work and will require dedicated resources. It cannot be managed “off the side of the desk” in a part-time I-still-have-my-day-job fashion. The program team (including support resources from Finance, HR, Procurement, Legal, etc.) needs to have that as their only job, with ample time for your leadership team included as well – perhaps as much as 30-40%. Your time will also be in high demand – anticipate well over half of it being consumed by the transformation.

2.  Alignment of External Resources: If you opt for external help (consultants), make sure that they and their rewards structure are aligned with the results that you seek, and not only the process or other aspect of the solution executed in isolation (a sure recipe for an “extended engagement”).

3.  Communication Management: Understand that transformational change is hard. Your job is to lead the organization though it. If you have a capable program team, your best return on time invested is in Organizational Change Management and communication activities. Remember that if you are not managing the communication, it will very soon be managing you (which is a really bad place to be, trust me).

4.  Organizational Resistance: As the vision or end state is communicated, there will be perceived winners and losers. Those who believe that they are “losers” in the new world will resist the change and can be quite effective at it. Spend extra time and effort with this group to help them understand the future state and the opportunities that they will have there.

5.  Organizational Pulse: Remember that people move along the change curve at different rates. Have feedback loops built into the OCM process reflecting where the organization is so that the process can be adapted to the changing needs of the organization.

6.  Participative Change: There are different change management styles. The transformational change that you are bringing about almost always needs to be a collaborative style to be successful. More coercive approaches only usually work in the short run and almost never result in organizational buy-in to the change.

7.  Positive Confirmation: Make certain that there are detailed transition plans to the future state and that they are well communicated and understood. My simple rule for the organization during this time is that nobody can give up a job responsibility until the new-world recipient says affirmatively, “I have it.”

8.  Customer Service: Mechanisms for “Business as Usual” must be well known by both IT and by the customers of IT. If the customer is used to having a particular service provided by “Joe” and he is now part of the transformation program team, then the customer has to know now to go to “Rick” for that service. Perhaps there will be an entirely new method to get that service, like via an intranet form, and that needs to be understood as well.

9.  Face Time: There is no such thing as over-communication or too much contact with your organization during the transformation. You and your leadership team are the face of the change and need to be out and about, not sequestered in your offices or in back-to-back planning meetings all day.

10.  Cut the Cord: Once the transformation is in its final stages, find and complete any activities (usually projects in-flight and well-intentioned folks who want to do favors for friends) that are being done outside of the new model. There’s a reason that Cortez burned his old boats after landing in the New World; it greatly increased the commitment of his men to going forward and exploring. You’ve committed to the new model, now make it work.

There are probably a few more, but upon refection, these seem to be my most valuable experiential learnings on execution of a transformation program. As always, feel free to respond with any comments, additions or questions.

The final post in the series will be Business-Centric Change #4 – Coda.

Business-Centric Change #2 – The Solution

Let me begin by offering my apologies to those of you who may have been thinking that this post would contain the solution to a particular business-centric change problem.

This post is not so much about “the” solution to a particular business change problem as it is criteria for the solution.

From BCC-1, we have a crisply and clearly articulated business problem and constraints around the solution that have been bought into by executive leadership. Now all of our efforts will focus on development of potential solutions, so it is important to understand what characteristics a solution must have to be brought forward for successful approval.

Before we begin that effort, given the number of folks involved in developing “The Problem,” we have expectations to manage and stakeholder needs to consider. The solution will not be developed in a vacuum. As the effort will most likely result in a significant change program, a communications plan (as a part of a larger Organizational Change Management workstream) needs to be developed and implemented.

Executive stakeholders will want to have some knowledge of what solutions are being considered. Take the time to set up a formal or informal method to keep them informed at a level that makes each one comfortable with the solution process (having a few sounding boards will be invaluable in the socialization of the eventual solution).

Once that is done, our objective is now to develop and present a solution that executive leadership can understand, support and commit to (approve), and will be successful.

First, in the same way that we approached the development of the problem holistically, the solution must also be approached in the same comprehensive manner. Everything that has to change and what actions those changes will require must be identified and well understood. Every aspect of the solution must have a corresponding implementation plan. This will make executive leadership aware of the full scope of the change and give them the necessary information to make a decision to go forward with the strategy.

My suggestion is to use the Transformation Triangle to frame this information, with particular focus on the “Management Systems” changes that will need to take place outside of IT. Each executive stakeholder needs to understand what is happening and what he or she is signing up for within their own respective group.

Next, taking a page from Lesson 5 of Colin Powell’s Leadership Primer, the solution must be able to be implemented. A brilliantly conceived solution isn’t worth much if it cannot be implemented within the constraints discovered in the problem definition process or subsequently in the development of solution alternatives.

As solution component options are considered and modified, be sure to explore any potential secondary impacts on the other components and the overall solution to ensure that you remain within your solution boundaries (and the laws of physics). This will enable you to confidently check off against both the aligned objectives and constraints.

Finally, the solution must include an executive commitment to empowered leadership. An empowered change leader has responsibility for the end result and accountability for the outcome. They will have or have access to the skills, tools and resources needed for implementation and have the authority to do what is necessary to get the job done. This request for commitment must be made explicit in the presentation of the solution and made a part of the communications plan.

With those three criteria in place:

•    Full Disclosure of Scope (everything that needs to change and what those changes will require)
•    Ability to Implement (positive check off on both objectives and constraints)
•    Empowered Change Leadership (explicitly agreed to and communicated from executive leadership)

Our solution should be able to go forward with executive leadership support and stand a very high probability of successfully solving our problem.

But, as they say in the military, “The map is not the territory.” We now have a map that shows our destination and we have a plan to get there. Our success now depends on execution – on actually getting from here to there.

And that will be the subject of my next post.

Business-Centric Change #3 – Counsel

Business-Centric Change #1 – The Problem

From my previous post, the problem seems pretty straightforward: “IT isn’t delivering what the business wants or needs, or it is perceived that IT costs are not in line with the value being delivered”

Solve for that statement and we will fix the problem, correct?

It’s possible, but not likely. Jumping to a premature solution is like a doctor prescribing a cure for a serious ailment based on a symptom or two. If you want a cure that works (and doesn’t kill the patient) you must thoroughly understand the ailment, its history, and its symptoms.

Now back to our problem. Chances are that like a sickness, the problem didn’t appear overnight. Sufficient time must be spent gaining a comprehensive understanding of what has been happening from different perspectives. Business leadership, business customers, IT leadership, IT staff and perhaps key vendors will have a perspective to share that will contribute to the understanding of the problem.

Taking time to meet with these stakeholders and gain their perspectives is the first step in understanding the problem.

If the solution were simply to fix the articulated problems, then we would have a pretty good chance of being able to use the information received to put together piecemeal solutions. However, very little of that information is what IT needs to be, only what it shouldn’t be. Getting information from executive business leaders is the next step.

These conversations almost always begin with issues, which is fine for gaining additional perspective. The discussion must eventually turn to a positive statement of what the business seeks to do in the next 18 months (or pick a suitable length of time that is future-oriented enough for strategic purposes) and what contribution or capability IT will need to have in order to support the business objectives. Done well, that part of the discussion will be incredibly rich and will form most of the objectives for our solution.

But we’re not quite finished gathering information for our solution yet. Again, from executive business leadership, we’ll have to get some idea of any constraints for our solution. These usually take the form of budget, capital or time-to-results and may extend to dimensions of company values, strategic concerns, or “unwritten rules.”

For me, the most interesting part of the process is working with the executive business leadership and working through the “disconnects” between executive business leadership that inevitably arise in the discussions. Be prepared for several follow-up meetings for clarification and collaborative issue resolution before being able to create a first draft of the problem statement, with constraining parameters for the solution and what “success” looks like (complete with proposed top-level metrics and measures).

Usually, the document will need some tweaking before the executive leadership team fully buys into it. However long that takes, it is vital that this part of the process results in a very crisp and clear understanding by the executive team of the business problem that is being solved (actually now more appropriately phrased as what IT needs to do to support the business objectives) and what success looks like.

Next post: Business-Centric Change #2 – The Solution

Leaping Onto The Change Bandwagon

In most organizations where I have recently consulted, business executives are dissatisfied with IT. This dissatisfaction is usually because IT isn’t delivering what the business wants or needs, or it is perceived that IT costs are not in line with the value being delivered.

Last year’s BES posts expressed high expectations by executive leadership for IT to deliver on both critical business imperatives and cost improvements. Sadly, it would appear that this has not happened.

Whether real or perceived, this is an important problem to address because IT is now seen as contributing to the failure of achieving important business objectives and wasting significant budget dollars on low-value activities.

The size of the problem varies, and therefore the executive leadership appetite to address it does as well. But if it is a big problem, with critical business objectives missed and/or IT costs way out of proportion to the services provided, then why isn’t the problem being fixed?

The answer almost always can be classified as one of these three statements:

•    We are planning to fix the problem.
•    We are in the process of fixing the problem.
•    We have tried to fix the problem and it hasn’t worked.

When pressed for more detail about how the fix will be approached, or what actions are being taken, the response is usually an IT-centric one that focuses on process and organizational change.

Frankly, and from experience, I believe that an IT-centric approach to solving the problem is fundamentally flawed and will invariably lead to the result in the third statement.

Which brings us to the point of today’s post – the introduction of a new series.

Entitled “Business-Centric Change” this series will describe an approach to solving the problem (captioned in the first paragraph) of “IT isn’t delivering what the business wants or needs, or it is perceived that IT costs are not in line with the value being delivered” that is business-centric and IT-led.

Like BES, the BCC posts will appear weekly (or so, depending on my schedule). The first – entitled “The Problem” will be on the site next week. I hope that you enjoy the series and remember that your feedback and comments are always appreciated.

(From FAQ) Isn’t IT transformation to a managed services model a big deal – and what about the people in IT?

Before going further, let’s make an important distinction between transforming to the managed services model and outsourcing or multi-sourcing. One is not the other.

Implementing a managed services model gives you the tools to run IT like a business. That includes the ability to source services in different ways (insource, outsource, multi-source), but does not require it. The changes for IT people during the implementation of a managed services model are primarily in roles and responsibilities that correspond to new or modified service delivery processes. People’s jobs are changing. When implementing a multi-sourcing strategy, jobs are at stake.

The transformation to a managed services model is a big deal. It involves fundamental changes to processes, organization and technology. Extensive support is required from the Finance and HR functions. Customers of IT will interact differently with IT in procuring services. It’s a lot of change. In my experience, IT people can learn and operate successfully in the new paradigm fairly quickly – a matter of a few months – so long as the management team invests heavily in time to communicate the vision and value of the new managed services model (not just speeches, true interactive sessions) and provide training.

Implementing a multi-sourcing strategy is much more difficult to manage from a staff impact perspective. Presuming that you have already done the diligence and have a compelling case to pursue significant outsourcing of services, my advice is for full disclosure as soon as you have any sort of timeline for the process. If you are in an IT leadership role, you will soon find that your communications and staff interaction on this topic consume the lion’s share of your time. It’s time well spent, since you’ll want to minimize attrition – particularly of your best people, who know that they have options and can easily make a move.

Unfortunately, the answers that IT people most want to know (what happens to me, specifically) aren’t generally available until the end of the process. That is deeply unsatisfying to someone who is directly impacted. What I’ve found to be of value is to communicate throughout the process about what the various steps of the process are and will be known when.

The bottom line is that people will have choices to make and a time frame in which to make them. If someone is in the outsourced services scope, then the choices are generally pretty straightforward:

• A non-IT role at the current company
• An IT role that is not in-scope at the current company
• An IT role with the company that the services are sourced to
• Severance Package
• Retirement

The timing of when each of these will be known and available varies; so impacted staff will probably have multiple decisions to make. HR will be your best friend in helping to manage the information and processes for the various options.

Successful transformation programs invest heavily in an Organizational Change Management program of work that runs in parallel to the transformation workstream. These efforts are mostly communications-based and are vital in keeping the IT group informed and engaged during the transformation.

One of the most important points in these communications is that the transformation to a managed services model does not mean that IT jobs are being outsourced. In fact, unless both the goals of the business and IT transformation are best met by outsourcing as soon as possible, I would strongly suggest against the two efforts (IT transformation to a managed services model and IT outsourcing) being done as one – and then even so, I would caution that it will be a very bumpy ride for both the business and IT.

Again, the transformation to a managed services model positions IT to be able to source its services internally, externally or in any combination along the sourcing continuum. I believe that this multi-sourced model is the only way for IT to be competitive from cost, service quality and capability dimensions in today’s continuously changing global technology marketplace. However, it is highly advisable that the managed services structure first be in place and operational before implementing a multi-sourcing strategy.

Be prepared that no matter how well you communicate and execute this process, you will be the least popular person in IT for some time. Read Colin Powell’s Leadership Presentation – particularly the last page on “Command is Lonely.” It may help you though a difficult time.

The Missing Triangle – Framing the Transformation

One of my more astute readers has pointed out to me that all of the documents in the Library are referenced in a link from one of my posts except for one, the IT Transformation Triangle.

First, I’m flattered that anyone has read the blog that consistently and thoroughly to be able to notice that omission.

Second, I’m somewhat surprised to see that it is true. The materials in the Library are there to support the posts in some fashion. The post using the Transformation Triangle was edited a bit too severely and I ended up omitting the reference link. I’ll attempt to explain the use of the diagram outside of my originally intended reference.

To be successful, transformational programs of work must be defined along workstreams that are readily understood by, communicated to, and executed by IT folks. The triangle icon is the mechanism that I commonly use to help accomplish this.

Please note that it is far beyond the scope of this post to capture the entire body of work for an IT transformation. The intent of this post is to explain the Transformation Triangle and its use in framing, communicating and managing an IT transformation program.

The Transformation Triangle is comprised of four smaller triangles representing the various dimensions of the transformation: Process, Technology, Organization and Management Systems. The first three categories are for changes within IT. The fourth category is for changes that are external to IT and are done in cooperation with other staff departments, most commonly HR, Finance and Procurement.

The Process Triangle represents the changes to IT processes that will take place as part of the transformation. Presuming that the changes are to support a transformation to a services-based strategy, they are usually in the following IT functional or governance areas (in no particular order):

•    Portfolio & Demand Management
•    Solution Design & Delivery
•    Service Delivery & Support (Service Management)
•    Enterprise Architecture
•    Program/Project Management
•    Sourcing/Supply Management

Each of these areas will have a set of processes to be defined and matured within the overall transformation plan. Each of the work teams accountable for the definition and implementation of processes will have their work captured and reported in this category.

In a similar fashion, the Technology Triangle represents the changes to IT technology that will be needed to support the changes to process and architecture that will take place as part of the transformation. Initially these tend to be the implementation of software and support tools for program/project management and various service management functions (e.g. Service Desk). Later, they tend to be standardization efforts sponsored by Enterprise Architecture and additional tools for other areas as needed. Each of the work teams accountable for technology-related change will have their work captured and reported in this category.

The Organization Triangle represents the changes that will be made to the organization from staffing, skills, structure and sourcing dimensions during the transformation. These are discussed in BES-6. This category tends to be the one that is of most interest to the organization (as well as the one that causes the most angst) during this period. Each of the work teams (generally the IT leadership team) accountable for organization-related change will have their work captured and reported in this category.

The Management Systems Triangle represents the changes that will be made with the assistance of other staff functions to support the IT change agenda. For example, if there are new roles in IT that are defined by the transformation plan, HR will need to assist in the creation of  new job descriptions, slot the levels and define the compensation for these new roles. If a new service costing strategy is defined, Finance will need to assist in the modification of cost centers and create new mechanisms for assignment of cost to the new services. Each of the work teams accountable for changes to management support systems will have their work captured and reported in this category.

When embarking on an IT transformation journey, the Transformation Triangle is a great tool for the initial framing and ongoing communication and management of the IT Transformation for several reasons.

First, it provides a logical structure for categorizing the work that will be going on across the department, as well as other staff functions. It exposes the breadth and variety of the work on process, supporting technology and organizational elements of change needed to accomplish a successful transformation to the organization. This structure enables crisp, consistent communications to be developed during the transformation program.

Next, it fosters a common understanding and lexicon for the transformation program. As it becomes familiar and the transformation Vision is communicated, IT begins to see itself in a different way, as a service organization supported by process and technology, and is purpose-built for that mission.

Finally, the Transformation Triangle can be used to illustrate the continuous nature of change over time. It is an ongoing cycle that is responsive to the changing needs of the business and optimization of the IT function.

Focus and Change

Blog Query: From your previous post it appears that my IT will have to transform to successfully support my business change agenda. How can IT both support my critical business change objectives and transform itself at the same time?

A difficult challenge comes when the business has a critical need for the IT change enabling capability at the same time that IT is transforming itself. To be successful, IT needs clear focus on what needs to be delivered for the business, so that the IT transformation program can run in parallel and shape its deliverables to best support both business objectives and IT transformation objectives.

Similarly, I would suggest that one of the most important factors determining the success of the business transformation is the ability to focus on the investments necessary to achieve the business transformation goals across functions and business units.

For this, a new process is generally needed for the various business units to classify their investments in common categories aligned to strategic directions and financial goals. Then, standardized business cases can be developed and compared between initiatives within categories.

This process begins with bottoms-up identification of desired projects by business unit and the development of categories that will be used to group the investments. Next, a tops-down investment allocation by category is needed, with an eventual investment proposal created by category based on strategic focus, competitive analysis and operational readiness

Sound complex? Not really.

Let’s say that there are currently 400 business unit proposals, some requiring major IT investment, with a projected capital spend of $150M.

Our executive committee determines that given our strategic direction, all investments will be classified as Cost-Cased, Revenue-Based, Risk-based or Customer-based. The business cases will be built to reflect the goals for each category. The CFO informs us that due to current capital conditions that our total spend can only be $100M across all categories. After intense discussion about strategic direction and priorities, it is decided that the $100M will be initially allocated across categories as follows: 

• Cost – $50M
• Revenue – $25M
• Risk – $15M
• Customer – $10M

Each category now has an initial investment allocation, and each function and business unit is now accountable for classifying investments into these categories and creating corresponding business cases. Each investment should have an executive committee sponsor and a senior business leader accountable for the veracity of the business case (usually the function or SBU leader – remember these are business investments, some with an IT component).

Now that we have investments by category with comparable business cases, each category team (the full executive committee or a subset) can prioritize the investments as either above the funding line or below. Once that is accomplished the initial proposal for each category is submitted to the executive committee for review, discussion and approval to proceed. Once this approval is given, all functions and business units will be operating off of the same investment list, including IT.

The ongoing responsibility of the category teams is to track the progress of approved investment projects, review and prioritize new investment proposals, and report issues and opportunities back to the full executive committee.

Once this process is established, we can be reasonably certain that our investments are aligned with strategic direction and that we are all executing with the same priorities. 

Note that this, like any process will occur over multiple budgeting cycles, so at any point a category will have committed funds overhang from work in process as well as future year commitments. The $100M total and tops-down distribution are current year examples for discussion.