EAP 2.0 - Twenty Years of Dr. Steven Spewak's Enterprise Architecture Planning

Practicing for twenty years Dr. Spewak’s “Enterprise Architecture Planning” methodology, published in 1992, we got ample experience of what worked well and didn’t work so well. Nonetheless, with each project we learned, with each project the method evolved. This article provides a brief description of the current state in this evolution; the story of the journey up to this state is a much longer one. One day, I hope to find the time to write that story, the long-awaited sequel to EAP perhaps. Yes, this evolution was shaped by project experiences, but even more so by the people with whom I shared these experiences, who’ve given me feedback and have let me benefit from their insights. I’d like to mention them and credit them for their particular contributions.

First among them, of course, is the late Dr.Steven Spewak himself, a dear friend and mentor for so many years. It is said that you haven’t really listened to an idea or haven’t understood an idea until you’ve fought it. I can say, with fond memories of our many night-long discussions in which I did the fighting, and in which I (almost) always lost, that I’ve mastered Steve’s EAP. Thoroughly. I will call his seminal work “Classic EAP.”

There is Richard Yockman, then CIO of DOE’s Office of Science, who taught me that the purpose of conducting EAP projects is not to give the Client a plan but to fix the client’s IT’ planning process. There is some significance here, because it was the first time that I concluded that as consultants we are there at the Client’s to deliver a product. We’re there to change a process. Nothing wrong with being a hired hand and helping out in an FTE shortage. Just don’t confuse the two.
There is David Walker, then CIO at Aera Energy in Bakersfield, CA, who engineered probably the most successful EAP implementation project ever.

At the end of an EAP project, people often asked us “Will this plan work?” to which Dr. Spewak just as often repeated the blunt warning he gave management at the start of any EAP: “The majority of EAPs fail.” Yet, Aera’s EAP (1999) succeeded in a spectacular way. I thus spent numerous hours with Mr. Walker and his staff, in Bakersfield, in Moscow and The Hague to discover the secret sauce of Aera’s success. I have to credit Mr. Walker for the guidance and insights about the Aera business transformation, which enabled me to put the two main concepts of EAP 2.0 on the map: Breakthrough and Accountability. (more below)

Finally there is my friend Stuart Scott, with whom I worked on Information Engineering projects in the early 90ies, and who later specialized in BPR projects. Independently from each other we arrived at “accountability” as key ingredient for the secret sauce of success. Projects fail when they are underfunded in the dollar sense, but just as often they fail when not enough political capital is brought to bear on the project. Mr. Scott provided the “key stone” for making the secret sauce, what I now call Seeking Accountability. His techniques enable EAP 2.0 to generate that capital.

Classic EAP and EAP 2.0
The fundamental difference between Classic EAP and EAP 2.0 is that Classic EAP is about defining a solution for a known technology problem and planning the implementation of that solution through a series of well sequenced technology projects, whereas EAP 2.0 is about understanding a business problem, amassing the political capital to transform the business, and ensuring that business transformation projects indeed deliver business benefit.

In EAP 2.0 we shifted our emphasis from assisting the CIO with, “What capability are they missing?” to assisting the CEO with, “How should we be doing this differently?”

Classic EAP
Classic EAP is a culmination of Dr. Spewak’s analysis of failed IT projects. In 1992 he published his seminal work Enterprise Architecture Planning in which he provided a better methodology for planning IT projects. He improved on the budget-based methods of those days in which projects that were independently approved and business-case justified competed to stay above “the cut-off line”. In addition, he identified a more fundamental problem: the complexity of the IT infrastructure. As the existing infrastructure had grown more complex over time, the IT organization was no longer capable of providing quality information to the people who needed it in a timely fashion. As a result, the potential of new technology could no longer be exploited.

Dr. Spewak identified the absence of a single blueprint for IT as the root cause of this complexity. And as applications and infrastructure were being built redundantly, with poor coordination, by each of the divisions of the enterprise, over time this gave rise to a “Winchester House” of systems. Evidently, what was meant to work together could no longer be made to work together. Managers would say “our systems don’t talk to each other”.

The solution Classic EAP proposes for this problem is developing a single blueprint for data, applications, and technology and developing a migration strategy to bridge the gap between the legacy infrastructure and an architected infrastructure. To execute the strategy, Classic EAP a) defines a comprehensive set of applications necessary to support the functions of the enterprise, b) sequences those applications for optimal benefit, and c) schedules their roll-out in a long-term application implementation plan, over a period of five or six years.

It should be noted that the scope of an EAP strategy is massive. In one program, functional area by functional area, application by application, redundant functional applications are consolidated, technology is homogenized across the enterprise, and data can be shared among people who need it. To quote from Salym Petroleum’s internal corporate magazine, “…when business needed additional systems support for a certain function, Aera’s IT department did not build or install another computer system. Instead it removed two or three of the existing ones. In fact, since Aera started EAP in 2000, they had removed 50,000 spreadsheets, 4,000 Access databases and replaced 500 other systems with just a few data capture systems and a single Enterprise Reporting Warehouse…”

In summary, Classic EAP defines technology and automation we don’t have (the gap) and schedules projects to acquire it.


EAP 2.0

EAP 2.0 starts from a different position on the nature of the problem, perhaps best said in the words of Simon Durkin, CEO of Salym Petroleum in Moscow, Russia:

“… in the face of increasing complexity and costs, and decreasing yields, we need to change the way we work. …” If we are to improve our business we need to transform its processes.

Process change then – in contrast to technology acquisition – is what the EAP 2.0 methodology defines and schedules. That is, the meaningful unit of work scheduled in an EAP 2.0 plan is a process modernization or business transformation project. The key outcome of a business transformation project is delivering a predetermined business benefit, and integral to doing this is modifying traditional project controls so that we manage for process outcome -- as opposed to managing for project deliverables.

Of course, we are not the first ones to address process improvement. Toyota has turned relentless focus on driving out process waste into a culture, very well described in Jeffrey Liker’s The Toyota Way, 14 Management Principles. But driving out waste is only part of it; the commitment to discuss process problems and solutions, not just with the process owner but with all those who are affected, is just as much part of their culture. This discussion of the wider context is what we spend significant time on in EAP 2.0 (the 55 minutes of Einstein’s hour) as we build up an extensive body of knowledge concerning the subject process. We’ll call this Process in Context.

In Classic EAP, this body of knowledge is the enterprise architecture. It is a knowledge base of the solution objects in the form of data, applications, and technology. It describes dependencies between the objects of the solution, provides context for the analysis of alternate solutions, and enables project definition and project prioritization. Given a certain benefit, in Classic EAP solutions compete with each other on cost.

In contrast, EAP 2.0 builds the knowledge base of (all) the processes that make up the relevant context of the subject process. It helps understanding Processes in Context better if at first we allow two types of processes. Ultimately though, 5 years from now, we recommend treating processes uniformly.

The first type are Value (or Value Stream) processes. They are the upstream and downstream processes that figure in the subject process’ value stream. They may also include what Michael Porter’s Value Chain labels as support process: Purchasing, HR, IT Delivery, etc …

The second type are “alignment” processes. These processes have to do with the root cause of the subject process’ inefficiency. By seeking answers, five "why"s-deep into a root cause, we observe facts about the history and culture that gave rise to the process' current performance. Except, each such fact is expressed as an outcome of a process. Once we are able to express the "bad" outcome, we can also express the desired outcome, identify the process that produces that and find the process owner. We call them alignment processes, because our position is that the root cause of inefficiency is poor alignment.

EAP 2.0 thus expresses the results of its research as Processes in Context of the subject process. There’s always three questions to ask: what is the desired outcome, what process produces that outcome, who owns that process. To modernize the subject process, most processes in context are going to be affected, and the issue the process owner needs to deal with is whether he has the tools to change the process. The answer is almost always no. This is fundamentally different from answering the question whether we have the tools to acquire/build the technology. The answer to that question is almost always yes.

Examples of context processes,

1. If the company is transforming a sales process with a goal of greater market share but the VP of sales, the process owner, is incentivized for increasing profitability instead, -- basically, we want a certain outcome but pay for another --it is clear that the compensation process needs fixing and thus belongs in the context of the sales modernization project. The Compensation process is of the Alignment type.
2. If the VP of sales is modernizing the sales process and his bonus depends on increasing sales, but the project manager gets a bonus for on-time delivery of the project, then goals are not aligned, i.e. the project manager is not incentivized for increasing sales. In this case the Project Management Process or the PMO process belong in the context of the sales modernization project.
3. If the project requires certain technology or automation delivered better, faster and cheaper than the IT department has been able to so far, then the IT Delivery Process itself may have to be modernized. In this case, the IT Deliver Process belongs in the context of the sales modernization project. The IT Delivery Process is of the Valuetype.

This process context analysis will lay bare any business transformation problems and it is this clear definition of the problem that holds within it the description of the solution. The majority of our effort is thus spent in building this knowledge base, (In full agreement with Einstein “spend fifty-five minutes defining the problem and only five minutes finding the solution.”)

This simultaneous understanding of the problem, in context, and of the solution, in context, is the EAP 2.0 Breakthrough.

How is this done practically?
The first step towards breakthrough insight is developing the enterprise’s Concept of Operations (ConOps). The ConOps is a comprehensive and detailed (50+ pages) vision of how future enterprise processes are conducted and how they interact, with particular emphasis on those processes that either are the biggest constraint to 100% efficiency or hold the greatest opportunity for improvement. The ConOps also estimates a quantitative change, expressed in dollars over time, in outcomes of the envisioned process compared to the current process. That is, constraints and opportunities are translated in hard quantifiable benefits, which later on will figure in prioritizing business transformation projects.

Notice how the Classic EAP “Business Model” is different in content and purpose from the EAP 2.0 “ConOps”. The Business Model describes what “activities” take place now -- remember, in Classic EAP processes are verboten -- and serves to establish consensus on which business activities need automation support. The ConOps expounds the company’s vision and builds consensus on how the business will operate differently in the near future, say five years from now, and thus on processes that need modernizing.

The second step towards Breakthrough is the analysis of the Alignment type processes.

“Projectizing” the Solution. EAP 2.0 adds Benefit Realization tasks to a process transformation project’s work breakdown structure (WBS). In essence, Benefits Realization’s main concern is ensuring that anticipated benefits are indeed realized. To that end, it does three things. - It adds tasks to the project, like define and measure benefits (for a complete task list, read here), so that a clear path towards reaching process outcome is defined. - It modifies project controls to manage for business outcome rather than for project milestones. - It assigns accountability for each of the outcomes. Clarity on accountability and assigning the “correct” accountability avoids instances of “doing someone else’s work”. Benefits Realization seeks to tie the accountability for benefits delivery back to the various owner of the processes in context.

Benefits Realization thus connects the dots between the full understanding of the solution and “projectizing” an implementation of the solution which ensures achieving the desired outcome.

We are not there yet!
Breakthrough is not enough. Having a clear understanding how each of the processes in context need to be modernized themselves AND having a clear agreement on who their process owners are, does not yet guarantee that these same process owners will spend political capital and deliver. Understanding the task at hand does not yet commit the capital to see the project through. And without agreement to spend capital, political or other, the project has little chance of succeeding and should not be started.

Sometimes this hard-to-come-by capital is simply a manager’s time. The time necessary to keep the business going at full speed while at the same time changing the way the they work. Lke changing a flat tire while driving at sixty miles an hour.

We believe that one factor, above all, lies at the root of successful business transformation. In the successes we’ve seen, the people accountable for running the business were also accountable for the transformation. They did not create a separation between doing business and improving how they did business. The person “driving the car” was also in charge of “changing the tire.”

In the Seeking Accountability phase of EAP 2.0 we facilitate the conversations that need to happen to ensure that accountability rests where it belongs. Part of our challenge is that most companies have a seemingly logical division of labor:.Accountability for transformation lies with the PMO and not with the manager who’s accountable for running the business. That is, the business “driver” supposes his job is merely to drive the “car,” and leave the “repair job” to the “transformation mechanics.”

The first visible result of Seeking Accountability is a manager who takes accountability both for the daily operations of a business process and for its continual improvement. The second visible result is a cross-functional transformation team that functions as a collective “we.”

Conclusion
As laid out above, there is a meaningful difference between Classic EAP and EAP 2.0. I have sketched that difference perhaps in terms that were too black and white such that it will lead to a polemic. I hope not. Classic EAP was loved, it is tried and proven, and I enjoyed conducting them. Steve Spewak’s EAP will forever stand alone.

In the end I feel EAP 2.0 is not so much an evolution of Dr. Spewak’s EAP. EAP 2.0 is not an accumulation of evolutionary steps on top of Classic EAP. I think it was I who accumulated small insights that made me make a clear, clarifying, exhilarating 180 degree change. With apologies to Mr. Carville “It’s about the process, stupid”
.
The power of EAP 2.0 lies not in erecting architectures or planning technology acquisitions, but in helping transform business by Achieving Breakthrough with Accountability.

Benefits Realization

Successful on-spec, on-time and under budget project completion is poorly correlated with achieving that business benefit, which, earlier, provided the project’s justification. Any two-minute Google search on success of IT projects will confirm that only half of them are even completed and that of those only 30% realize any business benefit.

Benefits Realization (BR), as part of our EAP 2.0 methodology, seeks to ensure – yes, ensure – that anticipated business benefits are indeed realized. To that end, BR inserts additional benefit measuring and monitoring tasks into the project‘s work breakdown structure (WBS), and modifies project control tasks, enabling the project manager (PM) to manage for business outcome rather than for project milestones.

There is some variability in the nature and number of task that are added or modified in the WBS. This primarily depending on the stature of the project sponsor and to whom the PM reports. This is intuitively obvious considering the different levels of authority vested in the CEO versus, say, the CIO

When managing a CEO-led business transformation project, ensuring success follows from holding process owners accountable for delivering. The PM, acting on behalf of the CEO, benefits from a “naturally” delegated authority. The additional BR steps the PM must insert into the WBS then simply amount to enumerating benefits and Assigning Accountability (AA) to business managers.

The additional benefit definition and benefit monitoring tasks to be included in the WBS are

1. Develop a strategy of intermediate benefits that builds up step-wise to a final benefit. Define each benefit in terms of process outcomes and quantify each benefit in meaningful business-like key performance indicators (KPI).
2. Implement processes to measure benefits; define measurement data to be collected and schedule implementation of suitable measurement processes; develop automation support where necessary;
3. Execute: Define a clear path (i.e. a set of projects) to achieving benefits; define a project for each intermediary benefit;
4. Identify process owners (by name); assign accountability for intermediary and final benefits; transfer accountability for monitoring benefits (from PM) to process owners
5. Publish: go on-record with accepted accountability;

The purpose of modifying project control tasks is to expand the analysis of project risk beyond the IT component of the risk, i.e. the risk of not delivering capability on-spec, on-time, on-budget, and to integrate into a single analysis, the risk that any other process in context may not produce the anticipated outcome. This integrated analysis assesses the impact on benefits realization and adjust the business transformation program accordingly. This ensures that all processes (or sub-projects) of a business transformation are aligned with the same pay plan. In the absence of this alignment, an IT capability may continue to be pursued at pace with 100% on-spec, etc while the analysis shows that the benefit can not be achieved for 100%; the IT capability is therefore over-engineered, mis-matched relative to the business change need, and at a cost that cannot be recuperated;

The PM has additional challenges, however, when reporting to, say, the CIO. The office of the CIO typically has no authority over process owners, and cannot “naturally” delegate any such authority to the PM. The PM thus has no official standing upon which to assign tasks to process owners, let alone to hold them accountable for outcome.

Most process redesign projects do not have that CEO-level of corporate sponsorship, and the PMs elect to invest in a formal communication plan and in change management to keep management commitment and to overcome resistance to change. Of course, management commitment and resistance to change are but two of the challenges faced by the PM when he manages for outcome.

EAP 2.0 aids the PM in two ways in planning a project for Benefits Realization. The majority of our effort in EAP 2.0 is spent in building a knowledge base, a simultaneous understanding of the problem, in context, and of the solution, in context. This process context analysis lays bare the business transformation problem and this clear definition of the problem, holds within it the description of the solution. When the project team crates this insight, we have Breakthrough.

Breakthrough provides insight how the PM might deal with the following issues.

• The PM does not control the business rationale for the project, yet as the business case evolves and ROI changes, in his role of portfolio manager, he must decide the fate of projects as part of periodic reprioritization of the portfolio.
• The PM may not have a full understanding of the “reach” of the business transformation, yet to effectively manage the project for outcome, he needs to control the impact on the existing organisation, and he needs to “settle” expectations on outcomes.
• The PM does not control the program structure, yet Business Transformation projects almost always involve some form of organizational change; to allocate resources properly he needs authority to make organisation changes.
• The PM may not be a financial expert, yet allocating Economic Value Added (EVA) to processes and organizations are essential to aligning process owners in the project.
• The PM has little control IT organization’s turf wars and the confusion about who owns what processes.
• The PM does not control the message content, which is the responsibility of the process owners, yet often the PM is in charge of the communications plan.
• The PM does not control incentives and pay plans, yet alignment or lack thereof is the single-most important contributor to process inefficiency. In addition, he may have limited power to counter management’s tendency to switch back to old habits of rewarding project completion rather than benefits realisation.
• But perhaps most difficult to overcome is that the process owners do not report to the PM; he has thus no standing in the organisation to hold process owners accountable for tasks in the project.

The list above is an illustration, be it far from complete, of the kinds of roadblocks standing in the way of fully realizing the transformation’s benefits. This fact base includes an analysis of the subject process’ inefficiencies; its root cause and effect in the context of upstream and downstream processes, in the context of corporate culture and organization, in the context of other change initiatives, It may include data on conflicting demands placed on workers and organizations, and of whatever stands in the way of an effective business transformation.

But more important for the PM is the format in which every issue’s solution is documented.

• What is the desired outcome? (turn the problem around)
• what is the process that produces that outcome? (include this task in the project plan)
• Who owns that process? (assign accountability)

This format of Outcome-Process-Owner enables the PM to insert sub-projects and assign accountability for each of the project’s Critical Success Factors.

Accountability
However, knowledge of the road forward does not yet mean corporate agreement to taking that first step and executing the strategy. This is our segue-way into the second way we aid the PM in planning a project for Benefits Realization.

In the Seeking Accountability phase of EAP 2.0 we facilitate the conversations that need to happen to ensure that accountability rests where it belongs. We engage with the owners, individually and collectively, of all activities in the strategy and establish where possible clear ownership and accountability

The first visible result of Seeking Accountability is a manager who takes accountability both for the daily operations of a business process and for its continual improvement. The second visible result is a cross-functional transformation team that functions as a collective “we.”

Our role in Benefits Realization is to facilitate the IPT Team engaging with the business community and to create room to have the conversations – conversations that were perhaps avoided until today –that, in the end, help process owners realize that the business benefits are realized through tasks that they must step up to.

Breakthrough + Accountability = Benefits

The Role of Governance in Achieving Operational Excellence

This article states our position that operational excellence in large enterprises cannot be achieved under a governance practice that allows divided authority and accountability. This is no surprise since the concept of Unity of Command is long known throughout history and is well documented. Rather, our point is that the transformation towards the right governance requires a deliberate “seeking of accountability” by leaders and process owners throughout the corporation, and that this process of Seeking Accountability ought to be guided by experienced facilitators.

In a world of large or critical business transformation programs, a world of complexity, of high cost -- staff and consultants -- and of high risk of failure, we’ve often heard clients say they feel as if they are trying to change a flat tire while still driving just as fast as they can. They have to keep the business going at full speed while at the same time changing the way the business works. Leaders of these programs strive constantly to balance competing agendas and incentives, to keep an eye on too many moving parts, and to keep everyone - including senior management - committed until success is achieved. Few succeed.

Such transformational programs don’t lend themselves to the usual process of defining the problem, envisioning a solution, creating a business case, then launching the project. Getting to the root of big, long-standing, intractable problems, requires a willingness to engage senior and junior people to define the problem from all sides, to understand why previous efforts failed to solve it, and ultimately have the breakthrough that re-frames the problem at the root causes level.

The majority of these projects fail. A 2007 IBM study showed that number to be sixty percent. Only 40% of the projects realize some benefit, although some do so spectacularly. Why? Accountability!

In the successes we’ve seen first-hand, a critical enabling factor was that the people accountable for running the business were also accountable for the transformation. They had changed the governance of their processes, such that only process owners had the authority, and the budget, to invest in processes and process changes, including process automation. There was no separation between doing business and improving how they did business. The person “driving the car” was also in charge of “changing the tire.” This is in contrast to the more typical split of those responsibilities between the COO and the CIO. This Unity of Command is a concept very familiar to the military, to captains of ships and pilots of airplanes, and in those settings, it is well understood that it is essential for their mission to succeed.

Yet in many businesses, accountability for transforming the business does not lie with the manager who’s accountable for running the business. As a result, transformation efforts are done for and to the business, not for and by the business. We are so used to this division of labor that at first glance this seems logical. But in practice, it creates an “us versus them” culture that becomes increasingly divisive, and that division comes at a cost in the form of excessive bureaucracy, governing standards, managing interdepartmental contracts (SLAs), monitoring compliance, and the list goes on. And worse, because it became the culture, it is the way we work. It will be difficult and failure-prone to extract ourselves from an accepted but dysfunctional work process.

Our point: large transformational programs with divided accountability are unlikely to succeed.

However, we foresee that more and more CEOs will adopt the model of holding one person accountable for both “driving” a business process and continually improving it. We believe that they will want to emulate the Toyotas and the Apples of the world, and seek managers with the dual experience of operating and of improving their process to lead their departments. And, we believe, facilitation will play the catalytic role – the ingredient without which the required “chemical reactions” cannot occur -- in bringing this change about.

To give shape to this transformation, CEOs cannot but rely, we feel, on the company’s own employees and process owners to architect a gradual and deliberate transfer of responsibility back to process owners. Picture workshops and off-sites where people can have the conversations that need to happen to ensure that accountability transfers are thought-through, methodical, and supportable.

Our business is ensuring that such transformational programs actually realize their intended benefit, i.e. operational excellence, and do not collapse with a bang or peter out with a whimper. Our particular contribution to achieving these results is through facilitation. With high-productivity teams, our techniques deliver breakthrough, new insights in how to operate differently from today, and our techniques “seek accountability” for delivering on projected business benefits.

Breakthrough
Einstein once said, “A problem well-defined is a problem half solved,” and we are committed to creating shared understanding of the problem from all relevant perspectives. At the start of large transformation initiatives, this level of shared understanding seldom exists. To create it, we step teams through a rigorous problem-definition process. Forced to check their facts and test their assumptions, teams almost invariably have a breakthrough that opens the way to a solution that addresses and eliminates root causes.

The breakthrough in problem-definition sets the stage for breakthroughs in problem-solving. Once the team deeply understands the problem and its root causes, preconceived solutions no longer fit, and simpler solutions become visible.

Accountability
Breakthrough thinking isn’t enough. That’s why we also facilitate the commitments and accountability agreements that will carry the breakthrough from concept to implementation to measurable business benefits.

The more complex a process or a project, the less clear what it means to be accountable. People make commitments, then discover they can’t keep their commitments because of some inter-dependency they had not fully understood. Instead of holding themselves accountable for results that serve the common good, people fall back to “doing their best”. Over time, more and more promises get broken, and commitments cease to have much meaning. Accountability has broken down.

This is a foreseeable risk, and like most problems, it is much easier to prevent than to cure. That’s why our teams take great care to create an environment of accountability that will survive the challenges ahead, so that they will know how to rely on one another through thick and thin.

In summary: We have illustrated the correlation between successful transformational process improvement projects and a transfer of accountability back to process owners, and our belief that this transformation will happen through deliberate, facilitated change projects.

Please note that we do not, and cannot, take credit for the breakthrough that the teams we facilitated achieve. That credit goes entirely to them and only to them. They know their industry and their domain of expertise. Our deep domain experience is people.

What We Do

For most of my career I've had trouble giving a simple, clear answer to the question "What do you do?" A few years ago I came up with the answer "I create powerful conversations that allow people to address what matters most." Not bad, but it makes me sound a bit like a therapist, which I'm not. Over the last few weeks, Stefan and I have revisited this question, and here's what we've come up with. Your feedback would be appreciated.

---

We work for leaders of large or critical business transformation programs. Complex projects. Projects where you have to keep the business going at full speed while at the same time changing the way the business works. Kind of like changing a flat tire while driving at sixty miles an hour.

Leaders of these programs strive constantly to balance competing agendas and incentives, to keep an eye on too many moving parts, and to keep everyone - including senior management - committed until success is achieved. That’s a tall order. No wonder most business transformation efforts don’t meet their goals.

But some succeed, a few spectacularly. We believe that one factor, above all, lies at the root of successful business transformation. In the successes we’ve seen, the people accountable for running the business were also accountable for the transformation. They did not create a separation between doing business and improving how they did business. The person “driving the car” was also in charge of “changing the tire.”

In our experience, many business transformation efforts are done for and to the business, not for and by the business. Accountability for transformation lies with someone other than the manager who’s accountable for the running the business that’s to be transformed. In these situations, the business “driver” supposes his job is merely to drive the “car,” and leave the “repair job” to the “transformation mechanics.”

At first glance, this seems a logical division of labor. But in practice, it creates an “us versus them” culture that becomes increasingly divisive over time. This “us versus them” mindset can -- and does -- undermine even the best laid plans.

We foresee that more and more companies will adopt the successful model of holding one person accountable both for “driving” a business process and for continually improving it. Managers will no longer be stuck with the ineffective practice of delegating process improvement to others.  

How can you decide if you want to make this kind of shift in managing change? And how would you actually execute such without creating chaos?

That’s where we come in. We facilitate the conversations that need to happen to ensure that accountability rests where it belongs. The first visible result of this process is a manager who takes accountability both for the daily operations of a business process and for its continual improvement. The second visible result is a cross-functional transformation team that functions as a collective “we.”

We bring deep domain experience in facilitating those conversations. Sometimes people get stuck in adversarial relationships, think they know a better way, avoid responsibility so as to avoid failure, or seek scapegoats to deflect blame. These are all symptoms, in our view, of avoiding essential conversations. We create the “missing” conversations. Through that process people gain confidence that they are capable of breaking through the seemingly intractable issues they face.

In short, as facilitators of conversations, we serve as catalysts for accountability for total ownership of processes: to running it and continually improving it at the same time. That’s a recipe for real progress.