The inaugural Group IT Infrastructure Day

Today my team met up away from our usual home (it was one of our other offices, nothing too exotic!) for our inaugural Group IT Infrastructure Day. We took the opportunity to think about how our infrastructure needs to change over the next 12 months, and began the very high-level planning of a programme of 53 projects ranging from improvements to our existing guest Wi-Fi access and changes to our MPLS/SD-WAN topology all the way through to the rebuilding of over 90 virtual machines.

It is so important to consider the direction of travel of your business when planning IT projects. We used a simple method of scoring each project with a “Business Need” and an “IT Need” – we multiplied both scores together to come up with an arbitrary scale of importance, then worked through to plan the most important projects first. We realised fairly swiftly that some of the projects we considered important from an IT perspective didn’t necessarily match up with the projects that the business considered important. We also found that some projects we had deemed to be “urgent” were, in fact, slow burners.

When planning workload, I find it important to remember a few golden rules. As an example, I’ll use a project to upgrade 50 Windows Server 2019 VMs to Windows Server 2022.

• A project or task can be important, without being urgent. We call a project “important” if there would be a big impact to normal operations by not completing the project or not delivering the intended result. It’s important to make sure that we upgrade our Windows Server 2019 servers to Windows Server 2022 – at some point, Windows Server 2019 will no longer be provided with updates by Microsoft, and we would leave ourselves with an increased risk of a security event or incident if a vulnerable version of the OS runs on our network.

• A project or task can be urgent, without being important. This seems counter-intuitive because we naturally equate urgency and importance. We call a project or task “urgent” when its deadline is close. In my example, Windows Server 2019 mainstream support still has another 18 months to run, and extended support runs for another 6 and a bit years. This project is definitely not urgent!

• The level of importance of a project or task probably shouldn’t be governed by a single person or group of people. As the Group IT Infrastructure team our primary role is to deliver an IT infrastructure that supports the plans of the business; the plans might incorporate organic growth or acquisitions (or both), the introduction of new software or services to support the workforce, or even the integration of lots of different networks into one joined up network to drive productivity and collaboration. The business probably doesn’t have any plans to upgrade to Windows Server 2022. However, as IT professionals, we need to plan that upgrade to ensure we can continue to deliver a robust and secure infrastructure. In this case, the business’ perception of importance is very different to that of the infrastructure team.

• A project or task is likely to change in urgency over time. Unless the team has the ability to deliver projects a long time ahead of their due dates, urgency for long running projects might start low and increase as the deadline approaches. Urgency is fluid – it’s a way to make sure that we work on the right projects at the right time. As the Windows Server 2019 end of support deadline approaches, the task of upgrading our VMs will become more urgent.

• A project or task is unlikely to change in importance over time. It is important we upgrade our VMs whether we think about doing it today, or in 5 years’ time. Of course, importance can increase due to other factors; for example, if the business needs to adopt a new piece of software that only runs on Windows Server 2022 or newer, the importance of the project (as seen by the business) would increase because the consequences of failing to deliver the project would lead to the new software not working. Equally, if the upgrade had only been planned to support this new piece of software at some point in the future, and the business decided not to use the new software any more, the business’ perception of the importance of the project might decrease.

• The duration of a project is not necessarily the same as the amount of time required to complete it. For example, we might aim to have upgraded all 50 VMs within the next 24 months. That doesn’t automatically mean that we need 24 months’ worth of effort to complete the work, particularly if multiple projects are being run in parallel, or the people working on the project are not dedicated to it.

• It’s OK to not be able to estimate effort for a project in its early days. We could, for example, assume that each VM we need to upgrade is going to require 10 days worth of effort. Without knowing what those servers are running, how they’re configured, or how we’re actually going to perform the upgrade on each machine, it feels somewhat meaningless to pluck a figure from thin air and hope for the best. Only after careful discovery and planning can we make a reasonable estimate of the total effort required to deliver the project. Does that mean we shouldn’t guess? I’m not convinced…

When we started to consider our list of projects with all those rules and considerations in mind, we found it much easier to prioritise the projects and pencil in some proposed start dates. We built a list in Microsoft Lists, containing a brief title, the scores for “business need” and “IT need”, the estimated amount of effort required for the project, and the name of the project owner – we then pinned this list in our Infrastructure channel in Teams – where everyone in the team can see and edit it.

We avoided using Microsoft Planner, Project, or any of the hundreds of other project management and task tracking tools at this stage for a couple of reasons:

• Planner wasn’t suitable immediately because we wanted to track more than just the task, some dates, and the owner. We wanted to build a structured list of our projects that we could search, filter, and add colours to. Lists is really good at this.
• Project requires a little too much effort to get started when all you want is a simple list of deliverables. That said, we project that we will write project plans in Project for each of the projects we deliver. (Sorry, I couldn’t resist using the word ‘project’ as many times as I could just there…)

So how was our inaugural Infrastructure Day?

• We found a lovely place to get breakfast rolls and coffee, within 2 or 3 minutes of the office.
• We guesstimated that we have 1,869 days worth of work to do in the next year. Assuming we work an average of 220 days per year, that’s around 8.5 years worth of effort.
• We started to discover all the impediments and dependencies that our projects have on one another. Some of the chains of dependencies got quite complicated.
• We avoided talking in too much technical detail – the time for thinking about technical detail is in the planning stage of individual projects, not the project planning day!
• We managed to categorise all our upcoming projects into five broad “buckets”. We then ended up assigning some projects to all five of those buckets…
• We found that the place that sells the nice breakfast rolls also sells a decent toastie.

In short, it went well – we still have some things to discover about how we plan our workload for the next year, but we’ve made a start and we’ve committed to hold Group IT Infrastructure Day in 2023!