Firstly, let's be clear, fixing a broken IT department is not for the faint hearted. You will need a mixture of planning, drive, people skills, IT & technology capability, lots of communication and a hefty dose of luck.
Every IT turnaround situation is different but here are some general guidelines that I have used with great success, and I consider to be vital in this high pressure, often crisis, situation.
1. Get the support from your sponsor at the outset. This is absolutely essential. In effect, this means agreeing a "contract" whereby you agree to turnaround the department in return for getting the necessary resources (provided, of course, that they are reasonable requests). Those resources can be any or all of expenditure, staff, political support/air cover or strategic direction.
The first 30 days plan
2. The plan built in your first 30 days needs to identify the major components of your strategy for next 2-3 years so you need to have looked under as many stones as possible. I tend to call this plan the "get-well" plan and I talk about it in more detail in my The first 30 days blog post.
Timescales and Assessing the Technology team
3. Part of that 30 day plan needs to be a honest assessment of the timescales for the IT turnaround. Generally, it takes 6-9 months to "stabilise the patient" with the following 18-24 months to complete the IT turnaround and carry out some limited future-proofing. An essential part of that assessment is understanding the capability of the technology team that is in place. In my blog post titled Reviewing the Technology team during an IT Due Diligence assessment, I delve into how I assess a technology team. Although the post considers the assessment from an IT Due Diligence perspective, much of what I discuss is valid in this scenario and serves as a good starting point for considering the quality of the team(s).
How much change is too much?
4. You should expect the 30 day plan to evolve over time as actions get completed and new actions get added. However it is a great starting point and I find that I still have a "get-well" plan at the end of the IT turnaround even though it is very likely to have none of the original actions on it. It is worth noting that if you are finding that the 30 day plan is still changing considerably towards the end of the initial 30 day period then it is worth going back and double checking your initial assumptions. There is a good chance that one or more of those assumptions is incorrect and as a result, the shape of the 30 day plan is changing so much that it is not settling on an achievable set of easily understood, realistic actions.
People, Processes and Technology
5. The core of the plan and the thinking that goes into it, is based on a very simple methodology. Look at the People first, then the Processes and finally the Technology. If you have looked at the first two in depth then there is often little that needs to be done in terms of the technology. For example, lets say that an organization is having a problem with its firewalls as they are quite unreliable. The root cause could be that the staff are poorly trained or motivated or that the change management processes are poor, or it could be that the firewalls are old and unreliable. The point is that it is easy to assume that a technical problem requires a technical answer and often it doesn't.
Listen to the staff
6. It is extremely important to listen to the staff. You may have seen particular actions work well in other organizations but the staff are usually the closest to the problems, and often have some excellent ideas on how to solve them. By considering carefully their ideas, you gain their loyalty and their motivation to make things work as well a head start on which "rocks" to look under first.
7. Everyone has their own management style. Mine is what you might call "firm but fair", so I will absolutely drive the teams to hit deadlines but also appreciate when, through no fault of their own, they are unable to deliver bang on time. Generally, if you do have to have a firm word with some one then the word gets around and you don't need to do it any more. I find that this style binds the staff and I together, so that we jointly turnaround the IT department.
Standard questions for initial interviews
8. It can sometimes be helpful to use a standard set of questions (at least, initially) when communicating with the wider organisation. This allows me to compare answers and identify consistent areas of concern or opportunities. In my post on 10 questions to help you know if your IT department needs some help ,I describe a set of such questions. However, I also tailor them (and may add a couple of supplementary ones) to the organisation and the situation, in order to get the maximum amount of information and insight.
9. Although I get asked many questions during this process, there are two that are worth considering in advance of any interaction with the organisation. That is not to say that I will not change my starting position based on the information I receive but it is good to have a view and a ready answer, if only to gauge the reaction. The first of those questions is about the importance (or otherwise) of IT architecture. My initial view walking into an organisation is that while it is an essential part of the IT function, it also needs to be pragmatic. There are a couple of ways of achieving this: firstly, selecting people carefully who have that mind set ingrained in them or secondly, rotate the architects through the operational teams on a regular basis (including on call). If IT architecture is not a separate team/people from the rest of the IT department then find another way (usually via a process) to ensure that designs are signed off and communicated widely. In this way, there is an element of checks and balances as this is an area where many brains (providing that they can arrive at a conclusion) makes a lot of sense. In fact, in my experience, this area as well as operational troubleshooting significantly benefit from as much diversity as possible. This is because each individual brings a unique way of thinking, experience and set of skills to bear and as result, designs become much more rugged, long before they are actually built.
10. The second question is about my approach to outsourcing. Personally, I am a fan of tactical outsourcing but only in situations where it makes sense. I never it do it purely for cost reasons as it almost always end in tears. Nonetheless, I do consider it where the function or activities are not the "crown jewels" i.e. they are not core to the IT department or the wider organisation. This often means that if a function has or needs significant business knowledge and relationships then it is unlikely to be a good candidate for outsourcing. However, if there are "commodity" areas then it can be a great way to resolve staff retention challenges, as long as the processes around it are bullet proof. If there is an option to do so then I do look closely at whether I can keep a mixture of internal and outsourced staff, in order to mitigate any potential risk.
11. Finally, it is worth identifying how best to communicate with both the wider organisation and the IT department. Streamlining these processes is important so that it is easy to have a consistent message in every interaction. For example, using standard language, KPIs and business acronyms is essential to ensuring that any potential confusion is minimised. In fact, I go further by re-using standard charts, slides and outputs whenever possible. It is not unusual for those same materials to be used in Board reports, IT department town halls/all hands and weekly reports. Clearly whilst regular (ideally weekly) 1-2-1s with key stakeholders and directs (as well as management meetings) are vital, it is also important to reach the wider IT department on an equally regular basis. I prefer not to be a faceless boss but someone that the IT department understands and feels comfortable interacting with. For example, an email to all of the IT department on a Friday night entitled "Pete's Friday thoughts" seems to go down well. In it, I describe what is on my mind (in terms of the IT department obviously), any upcoming major projects and finish with what I am going to be doing at the weekend or something equally personal. It allows the IT department to have something to talk to me about when meeting socially and it brings down any barriers that might be in place.
Clearly this is an enormous area to cover and there are many nuances to each of the decisions, required to execute a successful IT turnaround. Nonetheless, I hope that this gives a flavour of where I would start and, of course, if I can help in any way then do please get in touch, even if it is just so that you can bounce some ideas off of someone over coffee.