11

We haven't upgraded our RDBMS or server OS for nearly a decade. Another mission-critical software package is nearing two decades old and has been unsupported by its vendor for much of that time. Some among our management seem to think that this is a good thing--we saved tons of money by not buying the upgrades! Now a critical piece of software needs an upgrade, but the new version will not support the decade-old stuff. Now a handful of us are losing our hair trying to figure out how to upgrade everything at once with minimal down time.

In an effort to avoid this in the future, a few of us are considering the creation of an IT strategic plan document (which will fit into the org's strat plan, fleshing out the items in the larger doc related to IT ... maybe that makes the IT doc a tactical plan?) in the hopes that we can get it adopted as part of the agency's overall strategic plan. I've volunteered to try and assemble the "Software Lifecycle Management" (or something like that) section to address the problem noted above (with the brass tacks likely in a separate document from the strategic plan). Nearly all software vendors publish life cycles and deprecation plans for their products, and it's easy enough to determine a "sweet spot" for each piece of software considering that info along with our organization's needs. The tricky part (for me anyway) is putting the plan for each piece together into something more cohesive.

How can I document that desktop clients A,B,C... are dependent upon desktop OS X and RDBMS Y, which in turn depends on server OS Z, and then here's how we keep all of them in their "sweet spots"? There must be books out there, but all my googling has only led me to stuff about the tactics of upgrading a single piece of software rather than the strategy for determining when to implement those tactics.

Fing Lixon
  • 211
  • 1
  • 5
  • 7
    Someone will be along soon to make a go at this, I'm sure, but one point I think shouldn't be missed is that while the company didn't spend money on upgrades, it _put the business at risk_. One of the things we have to do is to make management aware of the risks of not upgrading. – Michael Hampton Nov 14 '18 at 21:13
  • 3
    A jargon term for postponing upgrades is that you build up “technological debt” ; by postponing regular maintenance and upgrades you appear to save some money on the short term, but when eventually you do need to perform maintenance after years of neglect you will still need to pay the piper: often the timing will be unfortunate, vendors won’t have a supported immediate upgrade path from `$CURRENT-version minus 20 years` to `$CURRENT-version` etc. and you will probably reach the conclusion: Those were NOT actual savings but **EXPENSES** that will have to **paid at a future date**. – HBruijn Nov 14 '18 at 22:41
  • 1
    Life cycle management is an ungrateful necessity in any mature environment and a PITA to organize. Good luck! – HBruijn Nov 14 '18 at 22:44

1 Answers1

7

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?

Fiisch
  • 193
  • 6
  • I still have to read your answer more carefully, but first . . . Re "Creating a strategic plan will not help you now": The story of the current poopstorm was only intended to be illustrative of the problem. We're treating it as water under the bridge and trying to get a strat plan together to prevent ***future*** fecal precipitation. I need to edit my question to make this more clear. – Fing Lixon Nov 27 '18 at 23:43
  • 1
    Yeah, I know what you mean. But I think if you cut out that particular sentence, rest of the answer still remains valid. :) – Fiisch Nov 28 '18 at 08:04