When an executive "assigns" a task to a department, does that change it's purpose?

This one is fun.  It comes up in EA because we deal with change... a lot.  Frequently, we are in the unenviable position of driving business teams to change the way they do things, and that means reprioritizing some things. 

Business teams like consistency.  They often shelter themselves from the negative effects of ad-hoc change by creating a group of project managers and analysts who cope, specifically, with change.  They are the policy planning group (many different names).  They plan every little detail from the readiness of the employees to perform their duties, to the testing of systems and paper processes to deliver, to policy changes and approval on their implications through executives and legal. 

These groups become the engine of change in an organization.  They are a small but key player in the way change occurs.

The key to change is to get to the head of the overall organization and convince him or her to let you in the room.  This 'head' is usually a mid-level executive.  On rare occasion, but often enough to drive the business teams crazy, the EA is allowed in.

Then the fun begins.  Assume the best case scenario... EA gets in the room where strategy is discussed.  EA brings some technical ideas, constraints, and solutions to the table based on principles and alignment with IT strategy.  That 'policy planning group' is now upset because all their plans have to be altered to allow for the change. 

In the best of all possible worlds, it would be good to get the 'policy planning group' to bring the changes to the executive on your behalf, but that usually doesn't work.  It's more of a multi-phased thing... with the EA having to create a compelling vision and then sell it alternately to the policy planning group, the executive, and back to the policy planning group, repeatedly, until the ideas start showing up in projects.

So, back to our sunny-day scenario: the executive agrees with your change and asks for the policy planning group to follow up.  Now, the planning group needs to allocate resources to support a business change that was not predicted.  If it is a 'rule change' like the other changes they have dealt with, it is not a problem. But what if it isn't. 

What if it is a scope change?  What if the executive has asked them to align with corporate strategy in an entirely different way, changing their own processes, not just the ones of the department they do planning for.  What if the change is fundamental to the planning team itself?  In effect, the executive has asked them to do something that he knows they CAN do, but they have never DONE before.

Now comes the interesting part... the manager of that planning group faces a challenge.  He or She has made a point of clearly describing the purpose, scope, and mission of their department to all the other stakeholders in the company.  The executive has just changed that scope.  Will they

1. Accept the authority of the executive to request that change, and thus have to recraft their mission statement, reexamine their priorities, and go back to their stakeholders and announce that their committments, made as recently as a week ago, are not worth the paper they are printed on?
2. Attempt to convince the executive that he or shoe is wrong by making a case for their current mission, and its greater importance over the new assignment,
3. Hit the executive with costs needed to hire outside help because their current mission consumes all their resources, and the new item is just not important enough to supercede existing committments, or
4. Stall, changing nothing in the hope that the executive will forget all about his or her directive and will walk away?

Tough one.  I've seen all four behaviors.  Have you seen others? 

As an EA, I can do very little at this point.  The only one I can prevent is #4 by making sure that the requested changes continue to appear on the executive's radar so that he or she notices when their department isn't following up.  Other than that, I'm at the mercy of professionalism, respect, and politics. 

Interesting note: These same choices are sometimes faced by the EA team itself.  Has your EA team faced this kind of re-assignment from above?  Have they reacted better than the business teams they are trying to change?

Bottom line: we are agents of change.  Change is not comfortable, even for change agents.  We are no different than the planning teams.  They, too, are agents of change.  Failure to change sometimes comes when you ask a team that is used to changing others to take on change themselves.

So, a warning to executives: know which teams are responsible for driving change in your organization, and when you ask them to change their internal processes... ask repeatedly and follow the changes closely.  This is where a slip in oversight can be costly.

Comments

• Anonymous
  July 24, 2006
  Great post!
  
  You should consider writing a book. Seriously. Practical architecture, unlikely all the other weighty tomes on enterprise and software architecture, yours would read with ease and clarity if written they way you blog.