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