Many IT departments function along the lines of, "I've got that,' where somebody who's experienced in tech "does their thing." That works, until your organization grows and can no longer function without formal processes. It's a difficult transition and not everyone will be on board with it. You'll require the right team members, doing the appropriate things. Checklists are important activity that will assist with ensuring IT quality through documenting solutions and documenting what happened (and when).
My previous company was able to operate by the seat of its pants, but process change and well-defined roles became necessary over time. For instance, an IT admin loved to solve problems and quickly responded to complaints from accounting that the ERP system wasn't emailing invoices to customers after we'd migrated from Exchange to M365. Accounts Receivable is an important corporate function, so he was correct to prioritize that problem (plus nobody messed with Edna in accounting ... haha just kidding, Edna).
However, his response was seat of the pants: setting up an SMTP server in Windows Server as a bridge. It worked, but he didn't think through the solution and external parties began using it also. Guess what happened next? Our IPs were blacklisted, so legitimate email invoices ended up in customers' spam inboxes. There was also the potential exposure of our systems to the open web to consider.
It was a parade of "terribles" that interfered with our cashflow and aggravated accounting over a week or so. They lost trust in the IT department and we lost credibility. That's where checklists come in. Taking a little more time to document a well-defined solution would have avoided that difficulty. IT people sometimes *hate* taking the time to create and maintain checklists, but it's important for several practical reasons.
- Keeping auditors happy if you're dealing with compliance (ISO in my case)
- Making it easier to onboard new team members
- Overall quality and metrics that an IT director can examine to understand what's going on within their organization
- Avoiding the "too smart for my own good" IT guru solution discussed above
It's ideal to have a small team of rockstars that just solves problems, but maturing organizations can't accept that level of risk. The lesson I learned was not to place too much trust into individuals, even if they're "awesome." My advice is to skate to where the puck is going next and begin to produce checklists, even before your organization grows. It's not micromanagement, it's process.
