This post answers point 4 from Part1, which was:

4. Many organisations have interdepartmental issues, every group needs to be involved and bought into (committed) to consolidation   

How many times during my life as a consultant has lack of cooperation or interdepartmental issues been a problem, unfortunately more often than not!  For a typical project whilst this will have an impact, many organisations are formed in silos and projects are delivered that way…you only get an issue when the boundaries are crossed!  If you are lucky there will be a sponsor or enabler who can manage the various departments/teams for you – if not this can cause delays or at worst failures.  Most of us should be aware of the importance of having a project sponsor, they must be senior enough to drive the various groups for you (leadership is another essential attribute; the worst case is a sponsor who fails to understand, act or have an interest beyond the sponsorship).
Server consolidation (true in fact for most if not all consolidation exercises) touches all layers of IT and architecture.  So it’s especially critical that all groups (by groups I mean your IT departments including appropriate user representation) are bought into the consolidation strategy, are willing and able to participate and will take ownership for their part of the work, and key understand the benefits.  Many times the biggest battle can be getting all the important people in a room together, politics can be tough to address.   As I mentioned also involve the user community (or representatives of) as the transformation affects them – do this early, I know this is simple advice but it’s still not always done.  One other vital check as many of you may have outsourced parts of your organisation, is to make sure any third party vendor is happy with your plans and they will assist, also remember this could involve contractual issues…so this is best tackled early.
Also consider that consolidation may change current standards as well as working practise, for instance your security model may need updating to encompass shared services on a single host or new operational procedures may be needed to transition the applications from development to production.  Backup and disaster recovery policy may also need to be changed; in fact consolidation is often an enabler to improve these areas.  I’m sure you can think of other examples?
My final piece of advice is, not only to ask the departments to help you (and capture the issues they may have) but to ask an important question which is “Will you be happy to consolidate if all your documented objections are met”?  Believe me having defined criteria of acceptance is key but having the commitment is crucial, people may be happy to assist in the project but they must want to run the system afterwards.

 

 

Help - I’m puzzled by my blog stats as it seems that nearly 60% more people read Part 2 of this series than Part1.  I guess it means that after reading part2 you didn’t see the point of reading part1, but it doesn’t explain why you started to read a series beginning with Part2 (unless I suddenly got a lot of brand new readers from a referral when part 2 was posted).  So if you decided not to read part 1 then you won’t be reading this (Part3) so … you won’t comment as to why…oh well.  It could also be the blog statistics are messed up and so none of this paragraph is therefore relevant.   Talk to you again soon in Part 4.