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!