How to document a strategy for upgrading commercial software?

Solution 1:

It looks like you are trying to solve many problems at once (and it does not look like a good idea).

From what I read:

• outdated OS and applications
• no long-term strategy
• problems documenting your infrastructure
• urgent need to upgrade critical piece of infrastructure

Upgrading "critical piece of software"

Your infrastructure being out of date due to somebody's decision is easy to understand. It probably seemed like good idea at some time in the past. This boils down to what Michael Hampton wrote in comments: For management, you are talking about pros and cons (risks). So if management is willing to take a risk, then ok (whatever you personally think about it), and it is their responsibility from now on. But somebody from the IT guys has to tell them what the risks are.

So first thing I would look for is: Did managers know about risks of outdated software? Were they told?

Honestly, I feel that you probably won't find anything useful about it, so I wouldn't spend too much time on it. It is just something that can help you along the lines of "we were telling you for the last five years".

I would simply do analysis of what performing that upgrade really means. Prepare simple spreadsheet with activities and how long they will take (if you do not know, give you best guess and explicitly stress out that you do not know for sure). But remember this "upgrade task" is not well specified, it is impossible to do it as fix-time/fix-price.

Making such lists will also help you to drill down whole problem. Next thing is to create risk log and list of resources you need.

At the end, you should have list of activities, list of risks, list material/people you need. In a word, do not handle the upgrade as an everyday problem, do it as a PROJECT. This will enable you to have at least some control over the acute need of your company.

If you have problems with analyzing what activities need to be done, you can try some mind map (my favourite sw is xMind) and then convert it to more formal document.

Note that whe you have some options of how to do the upgrade, you should give your managers a writeup of possible solutions (if there are more), summed up in a few sentences, including cost, outcome and risk; ideally mentioning the option you recommend and why. Because the final choice is theirs to make - they are managers after all.

Maybe in this particular case: Mention that the upgrade may not be possible at all.

No long-term strategy

Creating a strategic plan will not help you now. It will not help you at all if it is a document brewed inside your IT department. Strategic plan is something that needs to be tied to the business needs.

Example business need: In two years we will be opening new offices in China and Australia.

IT tasks derived: Be prepared to get new employees their worstations, create infrastructure in foreign offices, provide training for new employees (possibly using their native language), provide secure connectivity from those offices to the central, ...

If things go well, you can have a strategy maybe... in a few months? So about half a year until everything is agreed upon?

Maintaining and documenting your infrastructure

This is heritage from the past and now you have to change things. Prioritize. Make a list of things you want to/have to do now to bring most thing up to date. Choose which can wait, make a crude roadmap. (This roadmap should be part of your IT strategy when you have one.)

If you are updating something that went well, handle it as everyday business. If you are handling something that can go bad (is "big" in terms of spent time, allocated people, etc.), handle it as a project.

There are tools that can help you with documentation and service dependencies - CMDBs (iTop for instance). But getting it to work can take some time and you still need some documentation tool. The best idea is to setup a wiki for the documentation where everybody can start documenting/making notes from now on. You can set up a wiki in half an hour, so it is a very effective way to get things started.

Personal note: Upgrading OS that old would be huge PITA, not mentioning the (probably bad/missing) documentation. Isn't it easier to install servers anew, migrate apps and document everything from the start?