1300 130 447
make a knowledge base
available to end users
Source - HDI Report
About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , technology , business value
No Result Found
Once I was having coffee with a group of neighbors, one of whom happened to be a retired professor of economics. Since my degree was in political science, I engaged him on which economic philosophies he thought were most effective. Instead of throwing out the usual names like Hayek or Keynes, he responded, “The totality of economics can be boiled down to one question: What are the opportunity costs of doing something else?” At first, I thought he was being somewhat flippant, but as the conversation wore on, it became apparent that he wasn’t. This, for him, was a fundamental issue.
This equation also rears its head in IT, particularly when evaluating new software implementations and proof-of-concept projects. Perhaps because of the speed of change, or maybe in spite of it though, this gets morphed into a slightly different statement: “If it ain’t broke, don’t fix it.” “If it ain’t broke, don’t fix it” is a fallacy in technology. Let me show you why, how not to fall victim to it, and the best ways to self-correct if you are.
“If it ain’t broke, don’t fix it” only works if you’re in a closed system. IT is not a closed system. Even if your budgets are set, processes efficient, and ROI acceptable,if you’re not getting better, you’re getting worse. Why? Because, again, IT is not a closed system; the cloud is constantly driving agility and efficiencies, costs are routinely being driven down, new and more capable technologies are being developed every day, and, perhaps most importantly, new vulnerabilities are constantly being discovered. Believing that not switching out that mainframe in the back room running AS/400 because it has always run well is to compound risk. Now perhaps that’s acceptable risk. But that is a different question. Regulatory or audit requirements aside, the cost of consistently doing “nothing” will eventually have a trail of diminishing returns, after which stagnation will lead to negative results.
Now, let me state for the record: I am not saying run to the nearest software vendor and sign that PO. Proof-of-concept projects—even “free” ones—have a cost (time, effort), and the cost of poorly researched or implemented software purchases can often be worse than having done nothing at all. Technologies are also not a closed system; they’re (hopefully) constantly receiving updates, bug fixes, and new features. But understanding this pretty much invalidates the “If it ain’t broke, don’t fix it” line of logic. The very vendors you’re partnering with know that’s not the case, otherwise why would they ever push an update? There’s also end-of-life sunsetting to worry about. Adobe Flash is going away in 2020. A number of Microsoft products will lose their support in 2020. Early versions of TLS went out of PCI compliance in 2018. So if you’re thinking that doing nothing is “better” than doing something, remember that this tradeoff is not just a business decision (“We’ve always done it that way, and it works.”), but also a technological one (“You mean to say the cloud may actually be more secure than on premises?” Yes...and this article is two years old).
To cover your bases, I would argue there are four key areas of evaluation—each with their own requirements and processes—that happen in an effective review process. To evaluate effectively, you need to know:
Your mileage will vary on how often you need to review these, and there will be some cross pollination between inputs and outputs. But these are good swim lanes to operate from. Let’s look at each in a little more detail.
What do you have? No, really. If you re-read that question does your mind immediately go to technology? If so, why? Why there versus headcount, or expertise, or budget, or processes in use? Surely all of these are interconnected. But when you read that sentence, your brain naturally went to one area above all others, and so first and foremost it’s important to understand that what you have is a bias, or at least an intuition. You need to be cognizant of this, because it is influencing your evaluation. Basic areas you should be looking at here are:
Knowing what you have will quickly identify gaps and let you transition to the next stage, determining what you need.
What you need is not what you can get (that comes next). It’s the process of identifying the gaps (based off your inventory), determining which ones need to be filled and which ones are acceptable risk. Questions you should ask here are:
Now that you know what you have and what you need, you can move on to evaluating what you can get.
What you can get is a matter of constraints. Every business will have different constraints, but the most common are things we’re aware of: budget, timing, resources. You should understand these, but I would also argue that you should spend at least some time actively researching new hardware and/or updates to your existing infrastructure. This process will of course be a cost, but how else would you even know that now cloud databases can do XYZ, or the application you previously bought now has a vulnerability? What you can get should not only be a resource and opportunity review, but also a conversation. Increase your skills at learning how to ask, and you’ll increase the probabilities that you’ll receive what you’re asking for.
Evaluating software versus processes versus other gaps all require different questions. You need to understand what these differences are before you start your process. But once you choose to start, keep the following in mind:
Sometimes the status quo works. Processes and standards wouldn’t have a chance to be effective if we were constantly changing them. But instead of thinking that just because they are working, doesn’t mean that they’re delivering the same value year over year or that your competitors are keeping the status quo, too. There is a cost for doing anything, including “nothing.” So take advantage of what you have, but also make sure you have the tools to identify when change is needed and the resources to implement it.
Adam Rauh has been working in IT since 2005. Currently in the business intelligence and analytics space at Tableau, he spent over a decade working in IT operations focusing on ITSM, leadership, and infrastructure support. He is passionate about data analytics, security, and process frameworks and methodologies. He has spoken at, contributed to, or authored articles for a number of conferences, seminars, and user-groups across the US on a variety of subjects related to IT, data analytics, and public policy. He currently lives in Georgia. Connect with Adam on LinkedIn.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: email@example.com W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCS℠ is a Service Mark of the Consortium for Service Innovation™.
SIAM™ is a registered trademark of EXIN.