Monitoring Business Plan: Part Two

You’ve prepared and know the answer to, “Why do you need extra money for something you’re already doing?” (If you’re a little rusty, be sure to read part one.) But now you need to know how to answer in a way that makes sense to management. Various elements will help in preventing downtime. There are architectural decisions like redundancy, resilient designs, and disaster recovery plans. Don’t forget to test your design. Intentionally breaking it in a controlled environment can be fun. Reactive firefighting… not so much. Another thing we often ignore is user education. Make sure your end users don’t click each cat pic they see, and don’t store important documents on a local drive, and finally have someone watching what Dev is doing on production systems all day. And why. And who gave them permission in the first place. But that’s a different topic. An IT monitoring system will help you forecast situations based on resource utilization trends and will warn if a component in a resilient design begins to fail. So, take a step back and think about how you deal with extraordinary challenges of outages/slowness, and how you’re fixing those right now. Next; imagine how a monitoring solution will help and put it into a short and simple example. “Last month, we experienced an outage that took us 16 minutes to identify, plus another two hours to fix. With a feature like intelligent alerts, we should have known it in just over a minute, and the ability to put the finger on the broken layer would have saved us 110 minutes in fixing it.” This is what you want; to spark an idea that leads to spending budget without becoming a salesperson. There’s one more thing left: “I agree, we need a solution, but your proposal is a bit out of budget.” In the worst case, this requires a time-consuming response, but still an easy one. First, you have already won, as the need for a new tool has been agreed on. Congratulations! Going back to the beginning: “…you already decided on a specific product…” One approach would be to create a spreadsheet showing three different products, with different features and, more importantly, different prices. The features will mean something to you, but not to the CFO. He doesn’t care if a product supports IPv6 or not, so you need to translate it into money (read: time-saving) again. The secret is to put your favorite in the middle, as human nature will more likely agree on a compromise between ability and cost. If your preferred solution is the most expensive one, good luck! But you could try adding a subscription-based product at the column to the right and only say, “No one likes high OpEx.” But a better idea would be to talk to the vendor again and see if there’s some wiggle room for negotiation. Another approach could be a SWOT analysis and repeating your findings from above, displaying expenses vs. cost savings in a simple chart. I can give you one more card to play: slow is the new down and if you can explain the benefits in day-to-day activities, not even considering outages, you’ll gain bonus points. So, as soon as a discussion involves money, the guys in the corner offices are interested in three simple things: Increasing revenue, decreasing cost, or removing/minimizing risk. Using your expertise with IT and translating your request into a language to be understood by your boss is the best possible preparation, and will elevate your chances for approval. Return on investment is, unfortunately, a topic that you’ll need to deal with regarding explaining the outcome of your product evaluation. But that’s not rocket science. If you can deal with route redistribution or ever set up a VDS, ROI is a piece of cake. This whole process comes with another benefit for yourself. When you’ve successfully defended the spending, and received your budget, you’ve learned at least one important soft skill to help you grow further in your personal career. Well done.