Prioritizing value

It is one of my strongly held beliefs that what we do must provide some customer value. If it doesn’t, we probably shouldn’t be doing it. I don’t mean that we necessarily do something we can charge for (the goodwill we get by NOT charging for it can be benefit enough to do it), but rather that we inspect what we do to identify whether or not the customer benefits from it. Here are some examples:

• Upgrading a legacy system
  • Legacy systems are a common source of security issues. Keeping them upgraded helps both with security and with patching issues in previous versions. It has clear value to the customer, and as such should be prioritized.
• Security patching systems
  • Like upgrading legacy systems, keeping production systems patched is key to keeping them secure. So much so that we will often bypass the maintenance schedule in order to install critical security patches. Again, there is clear customer value.
• Making a major architecture change
  • This one is different. Whereas the previous two examples offer clear value, one has to make the business case to show value here. If the current architecture works, does not block future development, and is secure, the value proposition may be dubious. On the other hand, if you can show that one (or, likely, more) of those three is NOT true, you may be onto something.
• Assembling and disseminating lists
  • As a MSP, we are often tasked with assembling and disseminating lists. Be it lists of changes, incidents, computers, users, or any of a hundred other things, reporting is something that commonly takes up a fair amount of time. You should ask “do we really need to do this”, “could this be achieved more easily”, and “who, if anyone, benefits from this work”.

Those were just a handful of examples from my own experience. I’m sure you have many more, too. I’d like to add that this all also tracks well with the ideals of DevOps. Re-architecting your systems should also encompass the first ideal of locality and simplicity, and questioning the need to assemble lists and how you go about doing it is readily covered by the second ideal of focus, flow, and joy. Upgrading and patching will oftenmost serve to improve daily work, and prioritizing value is entirely in keeping with the fifth ideal of DevOps; customer focus.