Re: From Decentralized to Centralized

[Allison Dolan <adolan () MIT EDU>]

This could be a really good time to find out if your HR/Org Dev group  
has any good 'change management' folks who can help you.   Read/re- 
read Managing Transitions by William Bridges. The key issue is always  
the people/individuals involved, what they think they will gain or  
lose, what are the perceived power shifts, etc.   There is a change  
management line something like:  change will not occur until the pain  
of the current state is greater than the anticipated pain of the  
change/future state.  Make the future appealing (i.e. not simply a  
cost cutting mandate), and the present unappealing ('if you want to  
keep this group locally, you have 50% less funding/staff")

Some of things that could make centralization sound good
-- more pay  (central groups sometimes can pay more; at a minimum,  
there is probably more awareness of 'market')
-- career advancement (more opportunities in a group of dozens/ 
hundreds, vs in a 1 or 2 person shop)
-- more flexibility (in decentralized shops, sometimes people can't  
take vacation, are on-call longer, can't go to training etc, because  
they are needed 24x7)
-- greater responsibility/resume enhancement (being part of a central  
group may mean supporting more users/servers, or more complex  
systems, or more mission critical work.

Realize that even if you can offer all of the above, there are  
individuals that REALLY like being the local hero, and they will not  
see any of the above as pluses. Which further argues for trying to  
understand the motivations of all the players involved.

If at all possible, offer positions to all the folks in the  
decentralized staff that want to move, and use the normal performance  
review process over the next 12 months to reduce staff based on  
performance. [A caveat - if an individual is a known performance  
issue, make sure they have an exit path - you will lose credibility  
if you bring in individuals that 'everyone knows' is not competent or  
doesn't fit the norms/values of the organization]  If you can offer  
pay or title enrichments to some of the key folks from the  
decentralized areas, all the better.

Brush up on your customer service orientation and pull out/develop a  
service level template, so you can codify what, if any, services will  
change as a result of the move, BEFORE the changes are effective.  
Think about office locations, regular review/'check in' meetings.   
(If people stay in the same physical space, but simply have a new  
org. reporting relationship, that can ease the changes.)  Make sure  
managers of the central group meet with the clients early and fairly  
often through the process - you don't necessarily want the  
decentralized staff having to relay messages

(Disclaimer:  most of my experience re: this type of scenario was  
prior to coming to MIT)


Allison F. Dolan




On Mar 19, 2009, at 10:11 AM, Sarazen, Daniel wrote:

> Hi All,
>
> I’m wondering if anybody out there has been involved with a project  
> to centralize previously decentralized IT functions/departments and  
> whether you could share you planning and any post-mortem that you  
> may have available.
>
> Many Thanks,
>
> <image001.gif>
> :: Daniel Sarazen, Information Technology Auditor
> :: University Internal Audit
> :: University of Massachusetts President's Office
> :: 508-856-2443
> :: 781-724-3377 Cell
> :: 508-856-8824 Fax
> :: Dsarazen () umassp edu
>
> University of Massachusetts : 333 South St. : Suite 450 :  
> Shrewsbury, MA 01545 : www.massachusetts.edu