Submitted by 7666 on

WARNING: It's time for BORING BUSINESS TALK. Run away all ye who don't care about megacorp politics, big enterprises, or me griping about how companies prefer to feel good about getting things done more than just getting things done.

Today I write this article from about a thousand miles away from the datacenter, killing time while on a business trip. Since I don't really have an outlet at work to fire off my jaded remarks without getting shuffled out the door, what better place than here, in the Infrablog! Project management is an important component of infrastructure, because usually when you're ripping and replacing things, adding new capabilities, or scaling your systems, that ends up being a project. When you get lots of these projects going in parallel, and management is breathing down your neck about them all, that's when project management comes into play.

Side note: I picked this image because this lady appears to be suffering from severe cancerous growths. Project management will do that to you.

Section 1: Applying Agile to IT Project Management is a Recipe for Disaster

Note: We define "IT" here as corporate IT / infrastructure, specifically geared towards systems administration. Agile does work for software development or even "DevOps" style infrastructure or CI/CD management, but for traditional IT project management roles focused on keeping the lights on vs shipping products, this section will explain why it's a big fuck up to try to implement it.

I have many gripes with Agile applied to IT:

  • Projects for IT infrastructure do not move in "Sprints". We don't collect "Epics". "Stories" are for children. These projects move when they can and when resources are available and that's it. If you're lucky, your "keeping the lights on" to "working on new and interesting things" ratio is 80/20 in favor of keeping the lights on. If you're unlucky, you're just a glorified firefighter (which isn't great but sometimes that's how it goes). 
  • IT's core mission is to enable the business to function efficiently and consistently, in a secure manner. This can mean preventative maintenance, hardware refresh cycles, automation development, redundant systems testing, writing documentation, capacity planning, tabletop exercises, research and development tasks, security monitoring, and so on. None of these particular duties fit well into an Agile project as they're an ongoing, continuous task stream, better suited to a ticket system where they can be assigned and tracked as their own little things.
  • Daily standups WILL eventually make someone shoot up the office.
  • Just because you saw Agile on some MBA webinar doesn't suddenly make you a project manager, let alone a trusted member of IT, and unfortunately this is how Agile gets implemented more often than not.

When you try to treat your admins or engineers like developers (even if they are able to program or make internal "products") and shove Agile onto them, you'll find that it's very difficult to figure out where the hell all their time goes, because not all of their time goes to discrete tasks in a project. Do you track time spent reading emails? Improving your internal scripts? Working on certifications? Working on tickets that came from L2/L3 support? Chasing down who the hell just pegged the CPU on a server? Deciphering what management really actually wants when they say "We need reports on the infrastructure status"? Probably not - and since the only customer is the business for internal IT, you can't pretend to be an MSP and bill time against a specific customer either to work around the issue.

Section 2: What is the Role of a Project Manager?

Be a meat shield for management's wrath. Make pretty charts and cheerlead the team. Tell people to fuck off because the team is busy. Yep - that's it. If you can do those three things as a project manager, you've got the job. Details:

  • Project Managers that bend over to management's wrath have failed you as a team because they cannot promise resources that don't exist, and if they do, who do you think is picking up the slack? Not the project manager, that's for sure.
  • Pretty charts on progress, metrics, data, etc. are critical, especially when the charts make the team look superb. A lot of admins and developers suck when it comes to visualizing metrics in a way that management can parse. Having a cheerleader on your team doing flashy things is invaluable to keeping IT's perception in the business positive.
  • Keeping other departments at bay is important. I'm not saying to axe every useful project that comes the PM's way, but instead, the PM needs to set expectations on what the priority of the project is based on its cost/benefit ratio to the business, stacked up against the rest of the projects in the pipeline, and ensure it's something the IT department should be doing in the first place. Betty from Accounting might think that having IT install the new fridge she ordered is top priority, but the PM should know better than entertain such nonsense.

Section 3: Don't Tell the Team What to do and When to do it

If a PM is reading this, they're probably cringing right now. "But I manage the project, I have to tell the team what to do! There are open items man! OPEN ITEMS!" Generally, the team is going to tell you what needs to be done and why. They know the systems, the hardware, the flaws, the roadblocks, and so on. Let them communicate this to you and you organize that into something digestible for management. They'll likely even tell you the order of operations and maybe even the estimated time for each step if you're lucky. And yes, management is free to request things as part of business initiatives - that's normal - but they had better not be picking which way to skin the cat.

While we're talking about estimated time, pad every single item by 2x what the team says it will take. SOMETHING will go wrong or get in the way, and the last thing you want is a disappointed manager staring at an overdue project. They won't care if there was a solar flare and it fried all the gear - they're going to want their projects on time because they also have someone breathing down their neck doing the same thing. Also - give way to the whole "keeping the lights on" thing. Your project is great and all, but project #1 is always to keep the business operational. Everything else is secondary.

Section 4: Anecdotal Advice

I have found that projects move quickly when the following things occur:

  • Your infrastructure is in excellent shape, reducing your day-to-day overhead, giving every admin/engineer more project time.
  • Optional: Perhaps your admins aren't involved in projects at all and you have separate engineers dedicated to project work, constituting a clear separation of duties (don't worry - they can still work together, but their PRIMARY FOCUS is swapped).
  • Distractions from other stakeholders are kept to a minimum.
  • Scope creep is kept as close to "zero" as possible. Save additional requirements for a "phase 2". Don't let perfect be the enemy of good.
  • The right people are involved from the start, and their opinions on project direction are listened to.
  • Documentation and training is available for the various components in which the project/projects interact with, and there are owners and experts on said systems available (example: a project to move compute loads to the cloud will involve a LOT of cross-functional expertise ranging from systems, security, networking, and so on).
  • Ample time is available to handle technical debt that may be left behind by the completion of a project, preventing the need to sweep it up later as a separate project or time-sink.
  • The people doing the project aren't hung up trying to report project status over and over, wasting their time.
  • The people doing the project aren't hung up trying to scope out how long the project will take because management wants a hard completion date and getting that date takes time that could have been spent just doing the damn project. (You can work around this by just saying "next year" on every project. For the large ones, say "in three years". Call it a day after that. They won't like it, but you won't ever be wrong, and they'll be pleasantly surprised if it goes faster, and if they complain, ask to hire people in exchange for faster turnaround times!)

Note: I chose this image because this woman's arms have been turned into noodles. This is a serious and rare deformity and should be studied further.

Conclusion

I understand that my views on this subject are clearly not from a management perspective. That's generally because I have been an admin/engineer for the duration of my career so far, and I'm stating what I've seen works best, especially for me. Larger companies get paralyzed by this whole project management nightmare because they try to shoehorn concepts where they don't belong, thinking they know better than the people who built the systems they use every day. The overhead from doing so, and the apathy it generates among the team, leads to a unfulfilling workspace and a consistently disappointed management (even though it's their own damn fault.)

I hope this article wasn't too dry. I tried to be a bit scathing to keep the casual reader entertained.

With love,

-7666