How to fix Your IT Department
IT (Information Technology) is a diverse department. It includes desktop support, network and server infrastructure, software development and acquisition, and various other jobs. Those activities are unique, yet they are unified under a single banner. That flag's components are eclectic, and they are frequently a source of pain.
Many projects under that heading fail. They are late, over budget, and/or fail to meet their goals. When your organization installed/upgraded servers or network infrastructure, did that endeavor complete on schedule and within its allowance? Did the enterprise system you built meet its expectations, costs, and timeline? Did a new ERP system match its promises and its expected price tag? Frequently, the answer is no. Many IT projects are failures on at least one dimension.
Those defeats undoubtedly frustrate and confuse you. Their costs in extra man-hours and financial outlays have an impact. Missed due dates might lead to productivity losses or forgone business. The targets you missed might cause people to doubt the IT department's capabilities. This state of affairs upsets you. Yet, you do not know how to fix it, but you have to do something.
Certain corrections are recommended by smart people. You implement those adjustments, through hiring changes, technology alterations, and/or process shifts. Those fixes are promoted by other organizations. Many people consider them the latest and greatest way of operating. You are doing something, and you are doing the right things.
Yet, your organization continues to experience failed IT projects. Your institution hires new people, invests in the latest technology, and uses latest approaches, yet it continues to experience undertakings that are late, over budget, and/or off target. Those actions have made no tangible change to your situation. Your company still experiences defeats. You are a mixture of angry, confused, and sad.
You wish there was a way to mitigate those shortfalls, yet you know that any organization will experience its share of losses. Yet, you wonder why IT seems to have more than its fair share of them. Your organization has tried to correct that situation, and it has fallen short. You want a way to modify the current state of your institution's IT department.
That approach exists. Your IT department can be fixed. However, the method for doing so is different from the ones you have currently tried. The necessary technique might not seem clear, yet it has a higher probability of reducing the magnitude and frequency of project failures than the approaches you have tried previously. A way to fix your IT department exists, but it is nonobvious.
Before describing that adjustment, the situation surrounding the problem must be highlighted. A repair can become clearer, when an issue's circumstances are well understood. These conditions are illustrated to underscore why the proposed approach is inconspicuous yet effective in ways the others are not. This fix is contextualized first, then described.
Impact of IT on Your Work Life and Organization
Your institution invests in IT. A company typically spends 4% to 6% of its budget, on technology. The global aggregate of that cost was $4 trillion, in 2019. Companies worldwide are spending the GDP of a country. They are investing in their IT departments.
Your organization's contributions are woven into your work life. How many activities do you engage in that do not use a computer or software? Not very many, if you do office work. Virtually every office task interacts with technology, on some level. You could not do very many of them, if you did not have access to email, a web browser, or a phone. IT is tightly integrated into your work life.
That existence is harmed, when that department experiences problems. For example, email outages or systems crashes hinder your ability to do work. When such issues occur, you stop working or find time-consuming workarounds. That situation makes you angry, if it persists for a significant period. When IT experiences a problem, that difficulty hampers your productivity and worsens your mood.
Those struggles cost your organization money. When the work rate is reduced for any significant activity for any significant period, costs go up, revenues go down, or both. An institution's bottom line is hurt, when issues in the IT department lead to disruptions. Technology problems damage a company financially.
When those headaches are fixed, an organization's losses fade away. That institution is back to normal operation. Any reductions in revenue or increases in cost slip into the past. Your mood returns to its standard state.
When IT is functioning, an organization and your work life operate normally. Your institution's IT department affects both your company and you.
|
||
|
||
|
||
|
||
|
IT Project Failures
The shortfalls of your organization's IT department probably influence you. You are likely aware of this, yet, you might not have given much thought to categorizing those defeats.
Not every failure is the same. Some defeats look and feel like a space shuttle exploding just off the launchpad. Others slowly march along as a man with a boulder on his back does. The explosions never complete. The painful marches do, but they are late and over budget. The two failures are different.
They have distinct frequencies too. Implosions are rare, while ploddingly slow walks are quite common. Few projects fail to meet objectives completely. Many meet them slowly and expensively.
The opposite of failures are also rare. Few projects go so well that they proceed without a single hiccup. Those endeavors are as infrequent as the explosions are. Yet, they do not have same mindshare. You do not remember the rare IT venture that executes according to plan.
Most undertakings and failures lumber along. They never completely collapse or fall down. They simply fall behind. As they lag, they demand more resources. When they fail, they slip their schedule or exceed their budget. Yet, many projects eventually accomplish much of what they set out to do. They just do it is slowly and inefficiently. Those are the ones you remember.
|
|
|
|
Outside Influences on IT
Those plodding projects are the ones that annoy you, because they seem inevitable. You avoid trying to thread too narrow a needle, but you cannot seem to sidestep endeavors that slowly march along. Regardless of what you do, those undertakings continue to exist. That situation bothers you.
When you are upset, your focus narrows. You look only at the IT department. You hire new people, including a new CTO or CIO. You invest in new technology, and you try different approaches. Yet, some projects continue to crawl along. You become even more annoyed.
Your feelings are completely understandable. No one likes a problem he feels helpless to solve. Yet, you do have a path to a solution. You just have to look a little wider than you otherwise would. Expand your gaze beyond a single department.
Endeavors in IT are affected by actors outside that unit. You might intuitively know this, but you are frustrated. When you are annoyed, you get tunnel vision. That condition is natural. Yet, you need to expand your field of vision anyway.
Look beyond your IT department. Think about all the mediating layers that influence a project. Do any of those levels have an impact on the actions of an endeavor's team? Yes. Sales people or middle managers commit to a schedule. Project managers demand resources and plan to meet that timetable. If those mediating layers would have picked different due dates or not chosen one at all, an undertaking's manager undoubtedly behaves differently. Endeavors in your IT department are affected by decisions made outside its borders.
When you analyze those plodding ventures that annoy you, consider the external influences that might affect them. Various sales people, middle managers, and executives could derive benefits from various IT projects. Those parties will make commitments that help them acquire those advantages. Those promises might not be particularly beneficial to the IT department. When that unit struggles, its difficulties might have been influenced by promises made beyond its borders. Some of IT's failures might be the effect of external forces.
|
|||
|
|||
|
|||
|
To Fix IT, Address the System Instead of the Component
You are likely aware, on some level, of the impact of external pushes and pulls. Yet, you are still wondering how to address that situation. There is a way forward.
The path towards a solution starts by looking at the interaction between your organization's parts. Each department is not an isolated island. Units in an institution ping off one another, so they affect each other. You cannot understand the actions of a company's component, in isolation. You must examine the interactions amongst its parts.
A study of those linkages will likely reveal some commonalities in the failures. A pattern will probably emerge, regarding expectations, goals, and even execution. Each defeat is not likely to be a one-off.
Those regularities are a sign of a design issue. Repeatable problems are an indicator of an architectural problem, in machines and organizations. You might not know what the difficulty is, but you know it exists. If you have a pattern in your institution's failures, you have a design defect.
That blemish is what you need to address, to fix the problem of persistent IT defeats. Those losses are the result of an issue at the system level. Therefore, you need to focus on the organization and not its components. Correcting any singular piece will not fix difficulties with your IT department.
|
|||
|
|||
|
|||
|
When Correcting the System, Apply Previous Experience
You know what you have to fix, yet, you might be a little annoyed that you have no solution. No one likes the person who drones on about a problem, without eventually providing a way to deal with it. Yet, there is a path forward.
Contextualize your IT issue in terms of other systemic problems you solved. You might have experienced shipments consistently arriving late or frequent discrepancies in financial reporting. You corrected those difficulties. Those struggles were organizational, just as your IT problem is. Use the former to understand how to deal with the latter.
Think about how you wrangled with them. There are probably some common steps you took. You might have learned some lessons. Use your previous experience.
Apply that expertise to your IT department. Network infrastructure, desktop support, and software development are different from finance or logistics, but they are still bound by the same basic rules. The techniques you use everywhere else should be deployed in information technology. Leverage your accumulated knowledge to mitigate your IT department's issues.
|
|||
|
|||
|
Where to Start Fixing the System?
You have experience doing audits. Think about that process. Follow the template you use to examine any other area.
Yet, reviews are daunting. Their required procedure seems so massive that you cannot decide what to do first. You might feel a little bit stuck.
That is completely understandable, given the enormity of this task. A first step would be extremely helpful. Well, there is one. Start the audit process by doing an inspection of the fundamentals of managing an IT department.
Review those basics. Determine which ones your organization is doing and which ones it is not. Implement the tactics that are currently not being done. Once your institution has the fundamentals in place, conduct a wider audit.
The Fundamentals of a Well-Functioning IT Department
This section describes the elements on which the first stage of the review should focus. The areas below describe those basics.
This inspection needs only to assure that those minimal elements exist, not that they are done well, let alone executed optimally. The next phase in the audit concentrates on improving the components of your IT department. Yet, certain pieces must exist, before you can make broader fixes. This step ensures that those parts are in place.
Remember, all of these elements involve an organization-wide inspection, not one localized to IT.
Priorities
Assign priorities to tasks and projects: They allow an organization to manage scarce resources, at the micro (tasks) and macro (projects) levels. An institution cannot hire an infinite number of people. Those individuals only have so many hours in the day. A company has to make choices. Priorities tell it how to do that. Macro-level decisions determine what projects are given what resources. Micro-level choices regulate where individual endeavors utilize their resources and where specific people are deployed in situations of the multiple tasks assigned at a given time. The priorities that govern those selections should be transparent and widely accessible, and they must be selected by an organization.
Give projects and tasks resources, based on them : Broadcasting a desire does not guarantee that people will act on it. An institution must assure that individuals carry out its wishes. Priorities must not only be assigned but also followed. For a company, this means that resources must be given to projects and tasks, according to their preferences. A high priority project is given support before a low one. On a given endeavor, tasks with higher preferences are given material, before lower ones. For a given person, he works on more highly desired tasks before lesser ones, when he is assigned more than one. Individuals must carry out an organization's wishes.
Be capable of handling fluctuating priorities: Events can cause them to change. An institution must be able to adjust the deployment of its resources accordingly. For example, an emergency makes a low-priority task an extremely high one. Yet, supplies have already been marshalled to other jobs. For an institution to adapt, it must be able to reallocate those capabilities, to match the current landscape. Similarly, a company can also see projects rise from unimportant to crucial, as business opportunities emerge. Those endeavors prompt an adjustment at the macro-level, just as an emergency prompts one at the micro-level. Your organization cannot be so locked in to any particular decision that it can never move away from that choice.
Risks
Identify risks for undertakings: Find dangers. Determine their probabilities and costs. Use those factors to choose which hazards are worth addressing for a given venture. Remember, an environment with uncertain aspects of risks, shifting priorities, and/or volatile constraints is itself a danger. That environmental threat should factor into this process, if it exists.
Develop ways to mitigate them: For each liability, create an approach to lessen its impact. That method could eliminate the danger, it could reduce its cost or probability, or it could decrease both. You have a number of avenues to address a risk, and you need to pick at least one, for each threat. For example, a risk exists that a person might select an option that is destructive, in certain scenarios. One way to mitigate that danger is to eliminate that choice. Another method allows rollbacks, making a given situation less costly. Many ways typically exist to address a threat. Pick at least one of them.
Use those approaches: Developing means of mitigation is not sufficient. You must also use them. If your IT department develops methods but does not deploy them, you need to investigate and make adjustments. You cannot check this item off, until mitigation measures are consistently utilized. For example, projects develop extensive plans to handle their risks, yet they rarely use any aspect of their strategies. Their organization needs to investigate its entire system, to understand why this consistently occurs. However, regular utilization of hazard management plans does not demand a head-to-toe examination. Rather, individual projects can be studied instead. An institution must reach a point where failure to use a risk management plan is the exception rather than the norm, to check off this box.
Be able to adjust the risks you address and the methods you deploy: The list of threats and their details are not static. New hazards can emerge, and some can even disappear. For example, a business environment might change, creating a penalty for not being the first mover or removing the benefit of being one. Similarly, the probability and impact of a risk can be altered. The likelihood that you will be first-to-market could increase or decrease, depending upon externals forces. Yet, new approaches for handling a particular risk can also arise. An emerging technology or design technique could greatly reduce or even eliminate a particular hazard. Threats, their details, and the ways you handle them can shift. You must be able to deal with that.
Adjusting for Scale Differences
Scale down for small and/or simple projects: Endeavors of vastly different sizes require distinct processes. For example, the creation of an excel macro or the installation of software on work laptop demand different procedures from a customized enterprise-software-system or an overhaul of network infrastructure. The former needs light oversight, while latter needs extensive supervision. An Excel macro might require some sandboxing in terms of IT resources or light reviews but not much more than that. Anything beyond that level makes such an undertaking slow and costly. Its organization must be able to scale its process down, to avoid such outcomes, for small endeavors.
Scale up for large and/or complex projects: Some undertakings are quite sizeable and/or complicated. For example, customized enterprise-systems can take years to crystalize fully. Wholesale IT upgrades are on a similar scale. Those ventures are not only costly but also prone to scope creep. If they are not managed, their finances can easily go sideways. For example, the breadth of a custom-software project begins to expand, stretching existing resources and threatening its release date. As that sphere widens, the undertaking's managers begin to panic, causing them to pull in more capabilities. Yet, that endeavor still ends up late, and it costs much more than its organization projected. An institution must be able to scale its processes up to handle the unique challenges of large ventures, to avoid turning them into money pits.
Be able to adjust, if scale changes: The scope of a venture can evolve in a way that affects how a company should manage it. For example, a massive upgrade might require much smaller changes, after a closer examination. An Excel macro might become an essential part of a business's process. An organization's IT department should be able to adjust how it handles such projects. The venture that looks tinier after inspection should be given less supervision, while the one that expands into a central part your business must be reexamined. In the case of expansion, your institution should probably develop a more robust replacement for it. Regardless, a company must be able to adjust its management of an undertaking, if that endeavor's scale changes dramatically.
Constraints
Select constraints judiciously, not arbitrarily or unnecessarily: A restriction is a non-negotiable. It is a date that cannot be passed, a budget that cannot be exceed, or goal that must be met. Such restraints affect how a project behaves. When an organization imposes a constraint, it is choosing to direct actions in particular way. If it chooses restrictions arbitrarily or unnecessarily, it incentivizes behavior unpredictably and without reason, creating a multitude of opportunity costs. For example, a capriciously chosen due might lead managers to demand more resources than they otherwise would have, moving those capabilities away from other projects and productive uses. That opportunity cost might not be visible, but it does contribute to the dysfunction of your IT department. Avoid them by selecting constraints judiciously and only when necessary.
Shape non-constrained aspects, around restricted elements: A non-negotiable must be met. Yet, not every element of a project is in that category. Those pieces can be shaped by an organization, to meet an endeavor's constraints. For example, a venture's scope or resources can be adjusted, if a due date exists. An institution must mold the negotiable elements of its undertakings, around the non-negotiable ones.
Avoid projects with too many, unless you absolutely cannot do so: An undertaking with more constraints is more likely to fail, and it should be avoided, unless necessary. A fixed due-date can be handled by adjusting scope and/or adding resources. An undertaking with an absolute due-date and scope can be managed only by adding capabilities. If all three are locked in, then an organization better hope that a project's restrictions are in line with one another. If they are not, then it will experience defeat. You should not rely on hope or luck, when you can choose to avoid a scenario. Sidestep undertakings with restrictions that are so tight they scream failure from the outset, unless you have a good reason for doing them.
Use constraints to send signals, not to achieve other goals: A non-negotiable sends a cue to people working on a project. That beacon alters their behavior. If you do not intend to modify actions in a particular way, do not send out indicators to individuals that they should do so. Only send signals, when you want to provide cues. Using beacons in situations where you do not intend people to adjust their behavior creates opportunity costs. For example, setting a due date indicates time sensitivity, modifying how people allocate resources. That signal creates a foregone benefit. If you did not intend to communicate a time restriction, then do no set a due date. Doing so creates an unnecessary opportunity cost that contributes to the dysfunction of your IT department. To mitigate that malfunction, only use constraints to send signals, not to do other things. If you need to achieve a different goal, use another tool.
Be able to adjust to a fluid set of constraints: A project's restrictions might change. A venture with a fixed due date might end up not having one, as the undertaking progresses. An endeavor without one might acquire one, down the line. You must be able to adjust, to a changing collection of restraints. Your organization's IT department cannot effectively manage its projects, if it is unable to do so. ( Note: This one is intertwined with risk management.)
When the IT Basics are Done, Audit all Aspects of Your IT Department
The fundamentals are in place. Yet, you are not done. Your organization has only removed elements that impede improvement and obscure other problems. To correct the remaining issues, your institution must take other steps.
An audit must be conducted on all aspects of IT and its interactions. The previous phase assured that your company is in position to examine and correct all its issues. Now, you can begin studying your IT department and its connections to every part of your organization, in a comprehensive way.
To conduct that investigation, use the same process deployed everywhere else. You gather information and analyze it. You develop strategies, select them, and implement them. This procedure is done continually, until your IT department reaches an acceptable state of affairs. The audit process deployed here is no different from the one used in other areas.
That method examines how your IT unit operates as well as how it is affected by other areas of your organization. For example, this process studies what project managers, architects, coders, and even CTOs/CIOs do. Yet, it also inspects external inputs and directives and their impact on the actions of those parties. The audit process for your IT department is a wholistic one, just as it is everywhere else.
That procedure can improve the fundamentals you investigated in the previous step. For example, your organization might assign priorities, and it commits resources based on them. Yet, those preferences might be determined by whoever the squeakiest wheel is. That person could be putting his own interests ahead of his institution's concerns, creating opportunity costs. Those expenditures can be discovered and mitigated through a wholistic audit process.
That procedure also corrects elements beyond the basic ones. For example, an institution might not commit itself to overly tight goals. Yet, the targets it passes on to its IT department could still be quite self-interested. An obligation to add particular functionality might stem from the advocacy of a particular person. That individual's insistence might stem more from his self-interest than a desire to further your organization's success. For example, the inclusion of certain capabilities pleases a customer whose happiness advances that person's career. That employee's insistence on the inclusion of that functionality creates opportunity costs that could be damaging. An institution can sniff out and mitigate those expenses, through an audit of its IT department.
That process aims to lessen the risk of failures, in a durable fashion. For example, the danger of losing frequently might disappear for a while, yet it reemerges later. That threat has not been handled in an enduring way. For example, you put out a fire, when a building is burning. If you are wise, you pivot to ways to lower the risk of future fires, after the initial one is extinguished, if you want a stable situation. If you do not take such measures, the fire keeps coming back. To provide a stable environment, you must seek out measures that reduce threats, in a durable fashion. The audit procedure aims to deliver those means.
Remember, you can come back to this process, if you find your organization backsliding.
Endnotes
This article's goal is to provide guidance, for those who feel confusion and a sense of being overwhelmed. Frequently, what you need to alleviate those emotions is an idea what of the right direction is. You feel better, when you have a plan.
The details of that strategy are more involved than what this articled provides. Moreover, you still have to execute the audit process diligently and in good faith. The specifics of doing that are also beyond this piece's scope.
However, the mechanics of conducting an investigation are likely familiar to you. Use that previous experience as your guide. Apply what you already know to improve your IT department and implement what is recommended here.