What to do when your company goes shopping?
January 19, 2012
Someone on Reddit asked a great question…
Their company just purchased another corporation, and the submitter has been tasked with creating a “State of IT” report. When I originally read the question, I thought that his current company’s president wanted an overview of the new company. As it turns out, the president of his company is actually from his NEW company and wants an overview of the existing IT infrastructure!
That’s ok, I answered the question that I thought I read, because I find it interesting.
If your president or CEO tasked you with creating an executive-level report of a company that they had bought, or had considered buying, how would you do it? Here’s the advice that I came up with…
- Finances / Tax information
- Broad overview of their infrastructure
- Upcoming problems
- Remediation of problems
- Time Line
If you haven’t, yet, you need to perform an audit of the hardware and software assets of the acquired company. Report on the value of the hardware and software that’s usable. Indicate how many pounds or tonnes of hardware will need to be recycled through an approved firm, and what the estimated cost will be.
This should be a high level, 10,000ft view of their network highlighting what it does to help the business, not what it does from a technical standpoint. If it’s a manufacturing company, sentences should sound something like…
IT in $U company supports the business by enabling communication throughout the enterprise via (internal email/instant messaging/internal documentation sites/etc), and empowers clients to share data via (whatever). The IT department consists of $X number of personnel, $N being senior with at least $A years of experience, $M number being junior. Last year, they had $Y business-impacting failures, with a mean time to repair of $L minutes.
This should be a list of the major systems that need repaired or replaced, plus any grievous issues with the number or constitution of employees (i.e. massively under or over stocked).
Should consist of a report of everything you foresee needing to do to bring the company’s IT up to your level of operations, with particular emphasis on the monetary element (i.e. an aggregate cost of software licenses, a per-major-system breakdown of new hardware (a new storage infrastructure, or new server replacements if they’re still running on pentium 2s), or “we’re going to need to hire three new junior level admins” or whatever).
Make sure to provide a time frame of when you believe you’ll be ready to spend money (estimate it on a quarterly basis, such as “we’ll need a new storage infrastructure with a likely cost of $$$,000 in Q3 of 2012). It should go through the issues brought up at the previous, matching one to one.
Also, assuming you have MTTR numbers in that company that aren’t where you’d like them to be, now is the time to list the plans you have to implement improvements, such as “Begin transitioning $NewCompany to our QA department test processes in order to improve MTTR”, and so on.
Unless the president plans on operating the purchased company as a standalone entity, he’ll probably want to have their services integrated with yours (and if you value your sanity, so will you). Here’s where it gets hard, because you have to account for a LOT of variables, and estimate how long it will take you to make adjustments to both your and their infrastructure (both will probably end up changing, unless you just completely dwarf them). Increase the amount of time that you think it will take, because it almost certainly will take longer, but establish a time line with the major events between now (completely disparate infrastructures) and full integration, and assign quarterly dates to those events.
I’m sure there’s more, though. What advice would you give to someone in this situation?
Posted in System Administration
Email me
content rss
January 21st, 2012 at 5:42 pm
This seems pretty simple to me… The conclusion of the report should implicitly be what to do with the two groups. The upshot may read something like one of the following two extremes:
- Their IT department spends twice as much money and accomplishes the exact same things as your IT department, using the same technologies.
- Their entire IT department is fully occupied supporting money-making products, which use technologies that your own IT department doesn’t (currently) have any expreience with, and does practically nothing which overlaps your own IT group’s responsibilities.
It’s likely your report will be somewhere in-between those two extremes, specifying what is valuable and worth keeping, what is on the fence, and what is a cost sink that should be eliminated. And that likely includes listing thing each group does better, and how they can be merged.
You really can’t do that while avoiding technical details… Team X is a bunch of Unix admins, and Team Y is a bunch of Windows admins… even if they’re supporting infrastructure that does exactly the same thing, your bosses are going to need to know why they can’t just up and merge the two companies’ systems, and eliminate half of IT personell.
If that is the case, that dictates the two groups probably shouldn’t be merged at all… in the other extreme, unifying should include placing both groups under single management as low-level as possible, and merging the groups quickly, eliminating a few in the process.
There should still be a very high-level, completely non-technical overview of all this in the write-up, but ignoring the details will kill you, and lead management to make isane decisions with their imprecise information.