Keynote from the Nov 2011 Government EA Conference - Part 4 - "Planning for Yellow"

This is Part 4 of the 8 November Keynote.

Please read Part 1, "Solving for Blue" here.

Part 2, "Solving for Yellow" here

Part 3, "Accountability" here

When I arrived in Salym Petroleum Development, an oil operator in Western Siberia, Russia 50/50 owned by SHELL/Gazpromneft, I received my instructions from Joe Diamond, the program manager for Well and Reservoir Management. I remember his instructions to the letter.

Mission Impossible? Really? This should be a walk in the park. After all, I arrived in Moscow, to repeat an EAP for a company that, if not an identical twin, at least was a sister company to one with a proven success story. Salym Petroleum Development’s management had visited Bakersfield and they had liked what they saw. Salym was clearly not suffering from a Not Invented Here Syndrome and wanted what Aera had. And if an EAP was the way Aera got started, then Salym was quite prepared to do an EAP too.

Moscow and Bakersfield had gotten together, and the consensus was that we ought to be able to do this quickly: Salym’s Business Model was the same as Aera’s, and they wanted their architectures: Data, Applications and Technology to be identical too. No need to waste time on reinventing that wheel. We still had all of Aera’s models.

The icing on the speed cake however would be Randy Reagan. Mr. Reagan was responsible for Business Systems in Aera, and would become the program manager responsible for Moscow’s EAP implementation. Randy had agreed to be on the Moscow team for the duration of the implementation (two years.) I stayed for one year. In his kit bag he brought not only ten years of project management experience in SAP optimization and the development of the CIF, but the entire CIF itself: its models, its designs, its code, its methodology: Salym Petroleum Development had agreed to purchase Aera’s Intellectual Property. The only thing I needed to do was to put a plan together to build a CIF. Joe Diamond’s request for speed seemed entirely reasonable.

However, the year-long collaboration with Randy also confirmed, again, that Aera’s EAP had led to a business transformation and not just to a technology implementation, and therefore I would need to Solve for Yellow.

Thus, in Moscow EAP 2.0 was born and it made its first steps: Three new tasks were added to EAP to enable this Planning for Yellow:

1. ConOps or Concept of Operations,
2. Benefits Realization and
3. Trailblazer.

In general, a Concept of Operations describes how we might organize people and processes to solve a problem. In Moscow the ConOps was a statement of how the company ought to be operating in the future, say five to seven years from now, to be true to its mission statement and to be the best local operator.

In EAP 2.0 we write a ConOps in the past tense, as if we are already there, as if the benefits of working the new way have already been realized.

The Salym Petroleum ConOps served several purposes:

1. Owning the problem: Discuss and achieve consensus on how we ought to do things, how business organizations and processes ought to interact.
2. Quantifying Benefits: The contrast between future operations and current operations reveals the benefit of working the new way and provides information to prioritize process change initiatives..
3. Identifying a “Capability Gap” Identify capabilities required to realize said benefit.
4. Identifying an “Accountability Gap” Is there any consensus that we indeed ought to change things

Why a ConOPs? The short answer is to be able to plan for Yellow. To plan for changing the way they work, business leaders need an agreement on some desired way of working, an agreed to end-state for operational processes. The ConOps is that agreement on the desired future behavior.

In Classic EAP, the architectures play the role of such an agreement. The architectures are indeed a description of a systems capability end-state -- infrastructure and applications -- that we plan to acquire.

Rather than Architectures, I now prefer a ConOps – provided it’s developed by business managers instead of IT people -- as the better way for company managers build consensus on what they want to change, and how they want to propose change to the senior leadership. It’s a better way for them to agree on obstacles that, ultimately, they will have to overcome.

When developing a ConOps for a client, we identify likely IPOs first, and then, together with the people who will eventually own the problem, we facilitate the debate about the future way of working and about the obstacles, perceived or real, that have kept the company stuck in the current way of working. We facilitate an approach to process change, how much change and how fast. ConOps helps surface a gap in behavior, in the way we work, and this gap is more meaningful for planning process change than the gap in tools and systems.

ConOps in EAP 2.0 is thus the first step to Achieving Breakthrough.

Solving for Yellow also requires getting serious on holding managers accountable for Benefits Realization.

Benefits Realization (BR)

I didn’t invent Benefits Realization. I found it. And in good Steve Jobs fashion, I picked it up and co-opted it.

BR has its origin in the realization that IT projects, if they succeed at all, in 80% of the cases still do not produce that business benefit that 12 months earlier provided the business justification for the project in the first place. There are number of techniques to BR, and I will not discuss them all here, but you can imagine they include: identifying final and interim benefits, quantifying them, determining how to measure them, and identifying a task plan. In short launching a portfolio of projects that, combined, achieve the benefit.

Salym Petroleum Development’s projects were explicit in assigning accountability for realizing business benefits to business people.

Yet, two things were missing, I later realized.

BR relied on the program manager to assign accountability to business people. It was only later that I realized that this was, like, adding yet another blue job (circle) to the blue triangle. You remember that earlier I added Communications and Change Management as circles to the Blue Project. And again I’m not disputing the reality of resistance to change, or the reality of management’s fleeting attention, but I am wondering whether a PM who’s reporting to the CIO, and who’s measured on completion, is the person with the right authority to tell business managers what they are accountable for.

Second, although in Moscow we identified all the dots, and although we created tasks in the project plan for each of the dots (interim benefits), if those dots didn’t represent a business benefit then we didn’t assign business accountability for delivering. I now think that was not sufficient. Connecting the dots means “delivering on all the interim outcomes.” It means creating accountability everywhere..

So, with EAP 2.0 I take the position that process improvement benefits will be realized only when all the dots are connected. Each dot in our breakthrough diagram represents a needed outcome, an interim benefit, to be achieved as part of our journey towards the final process. And each of those outcomes is the outcome of some other process, each of which having an owner. Those process owners and the project sponsor will have to negotiate an agreement on accountability for reaching each interim benefit.

We understand that this accountability initially will not be there, and that it is our task, in EAP 2.0, to find it. Therefore we call it Seeking Accountability.

Lets go back to our Yellow-Blue triangles to make the point. Yellow is Business. Blue is IT, and the intersection middle triangle represents the project.

On the left you see how we normally do it, a blue project led by a PM, measured on project completion, with talented technicians, with involvement from SMEs, and “repaired” to solve for yellow. You’ll note that Benefits Realization was added as yet another responsibility of the PM.

On the right you see a yellow project, with a PM who works for the sponsor, and who is incentivized by the sponsor, thus focused on business benefit. You’ll notice -- and forgive ;) -- the sleight of hand here, but I replaced the talented IPT team on the left with The Dots on the right, the tasks that need to be accomplished. This is clearly beyond a single team, but what matters is that all tasks are achieved; what matters is finding talent that solves for all the dots, and not just the systems dots. And what matters is that all this talent is aligned with the process owner.

This picture, a project triangle that is yellow, containing tasks representing all the dots, with people on task who are all aligned with the process owner shows the essence of how I want to change EAP 2.0.

Just to be clear. This is not gospel, thatI have found. It’s a position that I take. It is something that you will need to think about. In future engagements, we will seek to surface divided accountability for business processes, and we will try for the real owner of such process to accept accountability for results..

In Moscow I didn’t get this far on the journey. It took me a year of struggling with process, process ownership and divided accountability to get this right; Having to prepare for this keynote, thankfully, forced me to condense the thoughts faster, but this is still not settled and more will change.

The Trailblazer

The last significant change that I made in Salym’s EAP was introducing a Trailblazer as the means to jump start the modernization of the IT Delivery Process.

At the end of every Classic EAP, and Aera was no exception, CIOs realize that their organization is in no shape to execute the EAP Plan. They need new processes, new skills, new tools, in short a new Best IM Practice, suited to build the target Infrastructure. For Aera this infrastructure was CIF and the new best practice would be a system development methodology suitable to maintaining and operating a CIF. Aera did indeed invent this method, and perfected it over a number of years.

Salym Petroleum Development had its own set of best practices in the form of a comprehensive project delivery framework, that in my view was nothing short of amazing. Except that, again in my view, it was “best” at developing systems on demand. Switching to methods suitable to maintain and operate a CIF model would be hard. A lot of people would need to change from doing what they were good at to using untested models and untested processes:

1. Aera’s CIF models would be valid at the conceptual and logical levels, but at the design level, the CIF would need to be redesigned to incorporate systems already running in Moscow.

2. And as far as Information Management processes were concerned, Salym Petroleum planned to adopt the Aera processes wholesale. Again, an excellent Idea at the conceptual and logical level, but from the design level down, these processes would require integrating into, and displacing some of, SPD’s already outstanding project delivery framework.

This is all too complex a design for there to be any hope of getting it right the first time. We would have to learn by doing. We would learn by sending a trailblazer project through the system; an end-to-end project that would build infrastructure and deliver business benefit., and that would lay bare all sorts of bottlenecks.

The trailblazer application was microscopic in functionality. It managed one data item, but the Trailblazer Project was all encompassing. The tiny application was to go through all phases and gates of the Project Delivery Framework and it was to deliver all components of the CIF. The objective was for the program manager to observe first hand what obstacles he’d encounter before he’d schedule EAP projects.

I don’t fully know the results of Salym’s trailblazer in terms of a formal “Here’s what we Learned” report. But from what I understand, the project over time morphed into a real business project -- yes that one data element -- and what was at first designed to fail, and to fail fast, was later managed to avoid failure. I think that’s probably OK, provided the old expectation about learning can be brought to a close, and we can all get aboard the new expectation about benefit.

What I didn’t realize in Moscow, at the time I proposed the Trailblazer was the magnitude of the transformation required in IT. To convey that I’ll go back to an insight I got from Aera’s Randy Reagan “Business people stopped asking for systems and asked for information instead.” To achieve such a change in interaction between IT and business, much more is required than for IT to adopt some different SDLC. A totally new way of interaction, of understanding each other’s responsibilities, is required. This is where the ConOps comes in. Because when you do it right, the initial dialog on this new way of interacting will be recorded right there.

But for this initial dialog to develop into a full blown agreement, for IT and business to really change the way they work together, they will have to Learn by Doing.

In EAP 2.0 the purpose of the Trailblazer then is to start that Transformation of what I now call, for lack of a better term -- I’ll take suggestions -- the IT Delivery Process Modernization. It’s just too complex to invent a suitable CIF AND a process to maintain it AND a new interaction with business in one project. Trailblazer in EAP 2.0 thus helps the CIO office to evolve a CIF design by doing, and to evolve the new interaction with business by doing. In short, Trailblazer experience helps settle the ConOps.

Business process owners too should learn by doing. They should get comfortable with trying and failing, and failing fast. But they cannot and should not be expected to carry the IT burden in doing so. The environment to experiment in, a version of a CIF, must be ready for them. We in IT must learn to change the way we work first, and do so in a hurry.

At the risk of repeating myself, I’m going to repeat myself because I’m asking to consider something that is anathema to our culture, which is that it is better to thoroughly design first, and avoid costly fixes when we are in implementation. I’m suggesting that designing a CIF, designing the process to build a CIF, and designing the new interaction between itself and the business, all three, is too complex to hope getting it right the first time, once and for all. I’m asking to stop changing IT by first designing the new IT processes, but by trying it and failing fast first instead.

The graph below shows the Trailblazer project on an EAP 2.0 timeline, and spread over the components of a CIF. I’m making the following points.

1. Start the Trailblazer early in the EAP 2.0 project. There’s no justification to delay the learning.
2. Observe the project’s processes: Ensure the trailblazer project goes through all the SDLC phases from feasibility study, to analysis, through design, construction, deployment, as well as through all project control gates that may be prescribed byyour company’s program delivery framework, inclusive of scheduling Investment Review Board or Architecture Review Boards sessions.

Focus on completion of the project. Observe processes that create bottlenecks or that break down altogether. Do not fix. But understand the failure.

3. Build all components of a proposed CIF. Chewing gum and bailing wire are acceptable building tools. The issue is to observe the construction of the CIF, the consolidation of existing applications, the installation of Middleware to keep data synchronized across multiple systems, the development of ETLs to populate the ERW

Since the objective is to learn, the selection of the data item is not important. In fact it’s important that the data item IS NOT important, otherwise it will prove difficult to keep the purpose of the project on learning versus delivering business benefit. As always with mixed objectives you run the risk of delivering on neither.

Focus on understanding the future cost to IT of operating a CIF

Designing the interaction between IT and the business (the second rectangle that stretches into the yellow)

1. This iteration of a Trailblazer includes interacting with the business. This will provide insight on how to write the Business-IT interaction sections of the ConOps. Focus on gaining experience on changing the culture towards rapid change.

In summary,

The Trailblazer in Moscow gave us experience integrating CIF development methods into the project delivery framework that was already in place

The Trailblazer in EAP 2.0 brings speed and experience to a CIO shop that wants to modernize its internal processes and its interaction with its customers. The primary rationale for learning by doing is that the new infrastructure design, the new SDLCs, the new interaction with the business is all too complex to expect to do it right without learning first.

Watch this very interesting Marshmallow challenge video by TED. And please pay special attention when Tom Wujec says that teams with facilitators do better. Teams with facilitators do better!

Keynote from the Nov 2011 Government EA Conference - Part 3 - "Accountability"

This is Part 3 of the 8 November Keynote.

Please read Part 1 here. and Part 2 here

There is another company, also founded by two Steve’s, that is known for focus on accountability: Apple Computer.

In the May Issue of Fortune Magazine, the article “Inside Apple” illustrates Apple’s approach to accountability. And I’m mentioning just one line:

“ … Apple also is a brutal and unforgiving place, where accountability is strictly enforced, decisions are swift, and communication is articulated clearly from the top.”
http://tech.fortune.cnn.com/2011/08/25/how-apple-works-inside-the-worlds-biggest-startup/

And after I read that story I met a Apple finance manager in a social setting and we got to talk. I was dying to know if Apple was really all that special. What struck me in the conversation was that he was tasked to focus only on his job, to focus only on doing his job better. He gave an example of how far Apple goes in this, and to help make sense of what he said I put that in a drawing.

In this graph you see him as Fin Mgr circle in the middle triangle, and that middle triangle represents meetings or workshops on a Yellow Subject Matter. He explained to me that in such a meeting he was not allowed to speak on yellow matters, he was not there to advance the yellow cause, he was there to advance finance. To learn and to become better at finance.

The Fin Mgr was not working for the Yellow Guy. He was not ever going to work for the Yellow Guy. Apple does not use matrixed organizations.

I going to use this triangle combination three more times: Yellow for Business - Blue for IT

1. To show why, as I see it, IT projects fail. They fail because of divided accountability.
2. To illustrate that it is difficult to fix divided accountability. For cultural reasons.
3. To show how EAP 2.0’s Benefits Realization removes divided accountability.

What we are looking at is two spheres (triangles?) of influence. Yellow represents a process owner, say the VP of Sales and Blue is the CIO. And the problem at hand is to improve sales.

The middle triangle represents the “Sales Improvement” program. In charge of the project, at the top, is the BPM manager, “located” within the Office of the CIO (OCIO), but reporting to the Project Sponsor: the VP of Sales. Also shown is the Integrated Productivity Team, the IPT

The graph illustrates two reasons projects fail to deliver business benefit:

1. We do not deliver business benefit because we don’t manage for delivering benefits. Sales Improvement is a blue project, an IT project, and successful IT projects are managed for project completion instead of being managed for process effectiveness. Although they finished on-time and on-spec, they may not provide any business benefit.
2. The middle triangle also shows my attempts to solve the failure problem. Each time I, in the role of a technician, diagnosed a failure, I would add more tasks to the project. Tasks that I believed would solve the problem. For instance, I might have failed in managing expectations, so I added the responsibility for a Communications Plan to the project; or I might have failed overcoming resistance to change well enough, so we added the responsibility for Change Management. (SP) and so on.
   
   I’m not suggesting, at this time, that Communication and Change Management are not legitimate concerns, but I am suggesting that each time I increased the reach of the project, I as a technician took on more responsibility without having any matching accountability for delivery.

When I use the term accountability I use it in a rather in-your-face wow-this-will-hurt fashion;
Accountability in its simplest form, really, is when you want to be held accountable for what you do; when you walk up to your boss and say, “I’m going to pull this off for you.” “You can count on me to get it done.” “I will not fail you. If I do fail you, I will accept accountability and I will tender my resignation” This may make you feel uncomfortable; but anything less than that and you are basically just deflecting blame: “Well, I did my best, didn’t I? I didn’t make any promises, did I?

Accountability really matters. Let’s reuse the comms plan example to make the point. If I truly accepted accountability for retaining senior management’s attention on the Sales Improvement project, so that the VP of Sales could increase sales and make his bonus, I would have to walk up the CEO and say: “Sorry sir, I failed to keep your attention on the VP of Sales’ improvement project. I’m really sorry she missed her bonus. I tender my resignation.“ Clearly, I wouldn’t be fired. So, what was the desired outcome of my task? Just do my best?

So if a Blue Sales Improvement project does not guarantee a better sales process, , can we make it a Yellow Sales Improvement Project? As in this picture?

Turning the Sales Improvement project into a yellow project, means that it is actually led by the process owner, the VP of Sales. And “actually led” means that the intensity of his involvement in Improving Sales is at least as great as his focus on Running Sales. Put differently, the VP of Sales considers himself the owner of the process, the owner of the program. Improving Sales is his main responsibility, and along with that he accepts real accountability.

But assigning accountability for process change to the process owner is a very difficult thing to do. I see at least three kinds of problems : Cultural, Custom and counter-intuitive

First of all, culturally speaking, we are comfortable with divided accountability. We truly are.

1. The VP of sales doesn’t think modernizing the sales process is his job. His real job is Sales. He was hired to do Sales. He will “be” the sponsor of the project and give as much time to the PM as his “real job” allows, and he will assign some disposable resource to the program, and, yes, he will liaise with the program manager, and so on. Maybe, I’m exaggerating, but Sales Modernization doesn’t get the same intensity as his “real” job.
2. The CEO doesn’t think modernizing the sales process is the job of the VP of Sales. He hired him to do sales; in fact the CEO just hired a director of BPM, to sit at the intersection of function and technology, to report to the CIO and to liaise with the business, to streamline their processes. . The idea of “working with them and fixing their processes”, I believe is deeply ingrained.
3. The Program Manager doesn’t think modernizing the sales process is the job of the VP of Sales. He was just hired to run the BPM program and to fix the Sales Process. And both the CEO and the VP of Sales believe that’s what he is there for: To fix someone else’s process.
   
   So, culturally, I think it’s an up-hill battle to Change Governance (take away authority from the CIO) and Establish Accountability (place the entire problem at the feet of the VP of Sales)

The second problem is the CIO’s tendency ((custom) to select for blue skills. The blue people were hired for skills relevant to the CIO’s office, that is, project success: They are used to work On-time, On-spec, On-Budget; I’m not suggesting that the CIO organization is the wrong place to house them. Housing them elsewhere, under the CFO, the CAO, even under the CEO, doesn’t change the criteria to select these people. As long as their hiring authority selects for project completion skills, their performance evaluation, their bonus, would remain aligned with project completion, and not aligned with the process effectiveness criterion of the process owner. Sure, the PM, and other Members of the IPT team, organizationally, have to be housed somewhere, but if projects were managed for benefits realization and IPT members were evaluated on their contribution to benefits realization, it would not matter that organizationally they report to the CIO.

And the last reason it’s difficult to assign accountability to the process owner is that it’s difficult to align incentives. We simply don’t have the economic tools to directly link the IPT Team’s performance evaluation with improvements in Sales. One way to do it would be to let the team share in improved sales. Nice principle, but how do you it?

I know I spent a lot of time on accountability; but seeking accountability it is the EAP 2.0 task that we need to succeed at. Remember, in Breakthrough we talked about Connecting the Dots. And what Connecting the Dots really means is identifying bridges that need building between silos, interim benefits that need to be achieved, and each of these interim benefits will have to have someone, in the business, who is going to be accountable for it.
No accountability, means no Benefits Realization, means another expensive paperweight.

So let me sum up what we want to achieve in EAP 2.0’s Seeking Accountability task

1. Ensure clarity on who will accept accountability for benefits realization.
2. Ensure that the project organization aligns the PM’s incentives with the process owner’s incentives. Project completion is a criterion that is not relevant.

But let’s get back to the Journey. Let’s leave Bakersfield and travel to Moscow.

To continue click here

Keynote from the Nov 2011 Government EA Conference - Part 2 - "Solving for Yellow"

This is Part 2 of the 8 November Keynote.

Please read Part 1 here.

THE JOURNEY - Aera Energy

One company we worked with, Aera Energy of Bakersfield, California, stands out as being successful with EAP, and spectacularly so. There are several places you can read up on Aera's story. Wikipedia has an article, and The Gartner Group also did a case study on Aera. Here’s a quick picture.

As you may know, Oil Exploration and Production companies organize themselves around exploitation opportunities: the oil and gas reservoirs, which are known as “assets”in industry parlance. Aera was a result of an M&A of nearly a dozen such assets from three different oil companies.

Here’s a schematic. It represents 11 oil fields. I think of them as fairly independent divisions or production centers, each with its own disciplines in engineering, run by its own managers, supported by its own systems and processes, and each of them having developed distinct cultures over time. I show only Well Management (above the ground) and Reservoir Management (under the ground) across all eleven. And, of course, they all have, to varying degrees, HR and Finance, and Equipment Maintenance and so forth.

Steve Spewak would have called this a true Winchester House of independently acquired infrastructure and plenty of redundant applications and systems. Their problem was clearly one of inefficiency. In 1999 Aera engaged EAI to come and help. The EAP was concluded in 2000 and below are a few excerpts from the public record on how Aera fared with their EAP Implementation.

In their March 2001 presentation to the Society of Petroleum Engineers Aera reported on its EAP project and they said that their project had delivered exactly what Classic EAP calls for: an Infrastructure Migration Plan and an Application Consolidation plan; and they said that they expected their biggest challenge to be change management.

In the ensuing years they continued implementing the plan. They stayed the EA course. In fact, in their May 2004 Presentation to DAMA, “A Strategic Approach to Improving Data Quality and Restructuring Information Management” Aera said that they had identified 61,000 Spreadsheets; 4,400 Access Databases, and 620 other systems, and that their Application Implementation plan -- consolidating all those into some 90 Architected Applications -- had achieved 36% of plan. They were behind schedule but overall they were doing fine and were staying the course. They also reported that the 2000 EAP plan had withstood the test of time..

In 2008 The Gartner Group did a case study: Aera Energy's Comprehensive Focus on Data Quality Generates Competitive Advantage

I’ll just mention a few of the things Gartner observed:

Aera Energy demonstrates many best practices in data quality improvement. By

embedding data quality deeply within business process, Aera has generated significant gains in productivity and improved its accuracy of decision making.

Key Findings

• Strong executive sponsorship is a critical success factor in data quality improvement

initiatives.

• Ongoing monitoring of data quality, rather than just focusing on data quality at the point

of new system implementation, yields the greatest benefits.

By 2009, Salym Petroleum Development, Aera’s sister company in Moscow, in their internal magazine HORIZON, reported that

“... Aera’s business people insist on quality data and they request from their IT department the “delivery of quality information” and not the “delivery of another computer system.”

“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 (ERW) from which all reporting and analysis is supported. “

Aera received visitors from oil companies all over world to see what hey had achieved, and how they had done it. As Aera likes to tell the story, by 3 PM in the afternoon the visitors were shown empty offices; everybody had gone home because the work scheduled for that day was done. Pretty unbelievable. Aera became the poster child of how to transform a business;

But, what should have caught your attention here is the timeline: A business transformation spanning a period from 1999 through 2009.

Aera never gave up!

That’s a nice thing to say of something abstract like a company but If I give credit where it’s due:

Aera’s Management Provided “Constancy of Purpose “

So, early 2009 I get this call from Lance Reed, Chief Enterprise Architect at Aera, except I didn’t catch his name or company name, so I wasn’t aware whom I was speaking with.

“Is this Stefan DeVocht, with EAI?”

Who is this guy? “Huh, Yeah”

Are you guys still in business?

Careful now, this could be the IRS, "Huh Yeah???"

Do you still do EAP?

It took a little longer before I said “Yes.” It’s always simplest to tell the truth.

“Well, we have this sister company in Russia. They came and visited us, they liked what they saw and want what we’ve got. And we told them that we did an EAP to plan our transformation. Can I give your contact info to the Russians?”

Two weeks later we received an email from the the Moscow program manager who said “I would be grateful to hear your views on how you could help us make this project a success.”

I was on my way to Moscow.

On my way to Moscow I just had to swing by Bakersfield first and see for myself what the Russians had seen in Bakersfield that they wanted to repeat in Moscow, and, more, I needed to figure out what the secret sauce was of the Bakersfield success.

So I met with the CIO, the Chief EA, Chief Data Architect, the programmers, the VP of Process Excellence, and the Head of DQM .

Aera’s Business Transformation

As I began to understand this success, it rapidly became clear to me that in their 1999 EAP planning effort Aera had not just defined architectures and had not just developed a plan to implement them. And in their 9 year EA Implementation, they had not just migrated their messy technology infrastructure to one clean integrated architected infrastructure, they had not just removed 50,000 spreadsheets and 2000 MS Access databases. They had done something much more profound.

To appreciate the magnitude of what they pulled off, imagine the EAP Team walking into the CEO’s office and saying:

“Sir, we got breakthrough, we had an epiphany of sorts. We have found a way for you to fly this baby on instruments rather than by, you know. We have devised dashboard with a single dial to steer this company towards operational excellence and this single dial is Data Quality. We know this will work because we have connected all the dots from idea to policy, from corporate principle to an individual’s pay plan, all the way to improved productivity. There’s one thing though. We need you to operate the company differently.”

Just stay with me now, you need to suspend disbelief just a little bit longer. So the EAP team leader continues his presentation to the CEO and says:

“Sir, we developed a vision of how you ought to operate the company. As part of that we are proposing new policy, new governance, new accountability, a new organization structure, new pay plans, new process managent and a new Information Management. The plan that we have covers pretty much everything that you would want, except if we could just ask for one thing, Sir.

“It would really be helpful, if at the senior leadership meetings that you show that you are behind this DQ thing, actually are leading it by requesting to be notified on DQ matters. And if we may, Sir, we’d like to suggest specific action from your part and that is that you want a report on your desk within 24 hours when any or our processes makes a step backwards in DQ. And that’s it. What do you think?”

It doesn’t matter how the presentation in the CEO’s office actually went at the time, what matters now is that it allows me two share with you two (of three) cornerstones of a successful EAP. Breakthrough and Accountability. (later I’ll discuss the third leg to that stool ;)

What the Aera EAP team proposed to senior management had gone beyond accepting that the IT infrastructure was a problem, that maintaining 11 different well management systems was sheer madness, or that they needed a plan to fix infrastructure and application duplication.
Instead of using the traditional “What Have we Got, What Have we Not Got, Bridge the (technology) Gap Approach,” the team had started solving for “Changing the Way We Work.’

Consistent with the colors of this picture, let’s call that “Solving for Yellow”I In this presentation I shall keep drawing that contrast between “Solving for Yellow” and solving for Blue.

What did that mean in Aera’s case, this “solving for yellow”

First, during their nine month EAP project, the team redefined the way they looked at their business. They saw, or they chose to see, that the major objects of their business, that they were dealing with on a day to day basis, like wells, pumps, pipelines, the oil itself, and so on, were all assets. And that the corporation’s major value-add processes were in fact the processes of managing those assets. The Team further realized that all asset management was basically the same, or could be “made” the same: Plan, Define, Acquire, Exploit, Maintain, Dispose, etc … The Team extended that asset-view of things to everything else that is managed in a business. People, real estate, spare parts, money, regulations, even data itself. This particular view on “work” provided, in essence, a standard approach to solving any (work) problem in their business, and it would ultimately provide a clear logic to develop systems solutions.

Second, Aera’s EAP team developed another breakthrough insight, and that was that a single measure: Data Quality, could drive all process improvement. The Team was convinced that improving data quality would require fixing poor processes, which would in turn lead to yet better data, which would lead to better decisions, which would ultimately lead to greater productivity. Data quality was to be measured and reported around the clock; and the success and failure of data quality improvement efforts were to be discussed at the highest levels in the company.

As a note on the side, Aera is not unique in selecting a single measure as the yardstick to transform a company Alcoa, the world’s leading producer of aluminum, used employee safety as the single measure to “change the way they work” and transformed itself into the world’s most profitable aluminum producer.

Thus, what the conversation in the CEO’s office amounted to, was the EAP team asking their boss to run the business based on a standard business processes, inclusive of the Information Management processes. By doing so, the EAP team created insight in a technological solution that would be required inside the context of conducting business differently. This is breakthrough, this is full insight into the technology problem, in full context.

So, I believe that successfully Solving for Yellow, must start with Achieving Breakthrough.

The best visualization of breakthrough ever, I think, is the famous 1984 Apple Macintosch Commercial. . In the 8 November keynote I used several screenshots from that commercial to simulate the dynamic of a breakthrough. You remember the woman athlete running and hurtling a sledge hammer at the Big Brother screen. For this blog, just picture the hammer shattering the screen and the light breaking through.

In EAP 2.0 we facilitate the development of two components in breakthrough: Research and Solution:

1. Research. A complete understanding of, and total insight in, the problem space. In the graph above research is represented by the Ishikawa diagram normally used in root cause analysis.
2. Solution. On the right in the graph you see a “connect the dots” game. It represents identifying what it will take to change . Dots represent desired outcomes, interim benefits, solutions for problems identified on the Ishikawa diagram, needed changes to deeply rooted, but counter productive practices, stifling customs and wasteful habits. The dots represent all the hurdles we’ll face in changing the culture. When we develop the plan, each such hurdle will need to be addressed explicitly in the project’s WBS.

Here’s an example of what I mean with connecting the dots.

Let’s say, for the sake of the example that we, like Aera commit to Data Quality. To provide users and processes with quality information, our workers, as part of their daily work, would need to record process outcomes in an unambiguous way. To suit our purpose, the data must be correct, and we must know or trust that it is correct. In short, our workers create data with standard definitions and standard measures of quality. One way to produce standard data is through standard processes. So, let’s say that our first goal, “Dot #1”, is achieving Standard Process

To that end, Aera’s EAP team created “process owners” or Integrated Process Owners (IPO), and they were ultimately responsible and accountable for deploying standard process across business units. Let’s say that we select the same approach, thus IPO’s become our Dot #2.

To make that task possible the EAP team proposed that the company change governance; and place the authority to invest in process automation and process changes solely in the hand of the process owner. Change Governance; Dot #3.

We all have seen this kind of recommendation before: Appoint Data Stewards and Process Owners. But without authority to invest and without being held accountable for a defined outcome, nothing much happens, nothing much can happen, really.

Aera however, fully connected to that dot, and actually transferred authority. This didn’t happen overnight or by fiat. It required Process Owners to work closely with operating unit managers, and to define standard process together, and to work out how pay-plans and incentive systems were going to be adjusted. But Aera worked the issue till they got it right.

In this simplified example, achieving quality data required three interim outcomes. Three different dots that we needed to connect to.

This brings us to the second aspect of “Solving for Yellow”. Accountability.

Aera was successful because it was clear on accountability.

First, the CEO was the ultimate driver of Aera’s transformation. He provided constancy of purpose, protected the transformation effort from business impatience, and connected the difficult dots, like taking budget authority away from “silo managers”.

Second, data quality and process improvement became the job of dedicated process owners, who had authority and were held accountable.

Third, IPOs were are also responsible for changing the way work was done in the field, for changing the data culture.

How does one change culture? This again required identifying a dots: Data Quality Principles, Policies that implement them, and Pay Plans to enforce them.

Aera developed 10 Data Quality Principles, and I’ll paraphrase two of them:

1. In doing work, I am not done until the information about the work is in the system.
2. In doing work, I realize that there are many users, or processes, downstream from my process that need my data, and I am not done unless I produce data of a quality that satisfies all of them.

In the picture below you see how these two principles were turned into posters and promulgated throughout the Moscow company.

Having principles in poster form is not enough, of course. Ken Rogers from “State” made that perfectly clear when he said in Monday’s panel discussion that “Culture will Eat Principles for Lunch.” Pride in culture, pride in the way we do things around here, is perhaps the greatest barrier to changing the way we work. You will need to identify AND connect the dots from the posters all the way through to a changed pride, and you’’ll have to be clear on accountability. In the case of Aera, Process Owners were accountable for making the Data Quality culture change happen.

So far, I have spoken about two important prerequisites for a successful business transformation . Breakthrough insight on how you want to operate differently, and clear accountability to push through change.

But there is a third change required, because a significant amount of technology support will be necessary to enable process owners to change their processes.

Aera created a Corporate Information Factory (CIF), represented by the 4 blue layers in the graph below.

The structure of the CIF itself is pretty standard and can be found in the literature. The technicians among us. I’m sure are very familiar with the layers.

1. DCS: This bottom layer holds the portfolio of systems that support standardized business processes; These are the data capture systems (DCS), or the transaction capture systems; that capture data about the outcomes of business processes.
2. ETL: Above that is an integration layer; it represents the middle-ware that synchronizes key data across the DCSs, and the ETLs that update the ERW layer above that.
3. ERW: The Enterprise Reporting Warehouse, the single – logical -- place that holds authoritative data on the operations of the enterprise;
4. BI: The ERW, of course, provides the source data for the Business Intelligence Layer which supports management decision making.

Here’s what’s important about the CIF -- and it’s not the technology; everybody can build technology.

1. Information Management Culture change in IT. Aera developed a methodology for, and became very proficient at, building out the CIF, piece by piece, data class by data class, over time, and according to plan. In effect, the IT development culture shifted away from stand-alone application development in favor of data management and systems integration through the CIF.

What this means is that Aera transformed its IT Delivery Process. It transformed the processes of the CIO

2. IM Culture Change in Business. Aera as a corporation succeeded in using the CIF as its corporate standard mechanism to share information. The CIF was a philosophy, a business philosophy, for information management and it was given shape in the form of a Technology Infrastructure. Its acceptance by business people, became standard practice then part of the fabric of the enterprise.

What this means is that the availability of the CIF, and the acceptance of the CIF became the practical enabler for people to change the way they work.

Remember that absent that acceptance and daily use, the company will continue to share data through a variety of means such as phone calls and emails, shared files and data bases, with content spread over copies of, again emails, documents, power points, spreadsheets, and so on. Non adherence leads to not knowing which information can be trusted, and the implicit IM process, carried out by each individual in pursuit of authoritative data, then remains the “invisible choke point of productivity.”

3. This is where the Aera Transformation achieved that business leaders stop asking for systems and ask for information instead

You may ask what the paperweight is doing next to the CIF. Nothing really, it’s just a reminder that if the CIF is not used to share information, it’s use is that of an expensive paperweight.

Anyway, that third change that I believe is necessary, is a change how the business sees IT, how IT itself sees its responsibilities, and new best practices that reflect that new view. Again, for lack of a better term, I called it IT Delivery Process Modernization. I’ll accept suggestions.

Let’s sum up what we learned from Aera.

If we review how Aera achieved its business transformation it’s clear that they went beyond Classic EAP: defining architectures and plans to implement them.

Aera achieved three things, and thereby “Solved for Yellow”

1. Breakthrough. Develop deep insight on how to operate the business differently.
2. Accountability: Identify what needs doing (connecting the dots) and hold people to it
3. The IT Delivery Process. Deliver integrated capability. Ensure the Business uses it

With respect to accountability, I believe that the Aera team had it easier than most CIO-managed IPT Teams. It’s clear that early on Aera realized that their EAP was beyond IT, that their’s was a business transformation effort: there would be business dots that would need connecting. The fact that the EAP Team got the CEO to lead, would mean that any two dots the team had difficulty connecting got rapidly attention from the boss. CIO led IT efforts, or even business transformation efforts, will not have it that easy, since the CIO’s authority stretches only so far.

Fundamentally, I think, there’s a mismatch between the CIO’s responsibilities and his accountability. Since accountability is so important to EAP 2.0, I want to share a few more thoughts on it before I continue the journey of EAP’s evolution.

There is another company, also founded by two Steve’s,

that is known for focus on accountability:

Apple Computer

To be continued