As a technology team member of any enterprise environment, our goal is to meet the needs of our customers. Our customers being the organization’s business community. These are our stakeholders and it is whom we serve. We consider ourselves successful when we meet the needs of the business and automate and maintain their processes to the best of our ability with the resources made available to us. But when we think about IT intake, do we try to do too much?
The business challenge for the IT department is that we tend to take on all tech projects within the enterprise and some external ones as well. We work so hard to ensure our stakeholders’ needs are met that we do not always perform due diligence to ensure each project meets specific criteria that warrant the utilization of our often-limited resources.
Ideally, we should run all projects through a series of tests to ensure that it makes sense to implement those that make it through some kind of a funnel. These are the projects that should be taken to leadership to be prioritized. Fortunately, there are a number of strategies, or methodologies if you prefer, that are mature, accepted as a best practice, and which can help to understand which initiatives align with the strategic plan and in which we should invest our time and resources.
Before devising an IT intake strategy, understand the strategic business plan
In a perfect world, every project, task, initiative, and operational process we invest time in, would align with the strategic business plan. And ideally, we would know how it aligns if someone should just happen to stop by and ask. It is the objective of our executives, and often a board of directors, to determine the organizational strategic plan. Each strategy then spills down throughout the organization and gets further defined by each organizational level that touches it. Everything should align with the strategic plan. Keep this in mind as you build your IT intake strategy.
Risk and opportunity matrix
While the creation of a risk and opportunity matrix can be labor-intensive, it can provide a very effective representation of alignment within the business. The first step is to create a list of risks that align to categories that have filtered down from the strategic plan. Because financial risk is inherent to most organizations, the image below is an example of some better-known financial risks. Note that each risk needs to be ranked by likelihood (or probability) and impact. In other words, what are the chances that the risk will actually occur? If it does occur, what is the impact on the organization?
Other risk categories are regulatory compliance, corporate reputation, customer satisfaction, operational, or strategic.
Sticking with financial as the example, opportunities to the organization should also be documented and aligned with categories. The table below shows an example of possible financial opportunities that could be associated with an initiative. Other potential opportunity categories could include safety, environmental, or customer satisfaction.
Once plotted, the resulting matrix can show the intersection of risk and opportunity. In the example below, the result is that this particular initiative would best be deferred to another time when either the risk is reduced, the opportunity is stronger, or both.
Return on investment (ROI)
Every steering committee I have ever worked with loves ROI. Which makes perfect sense in our current environment of profit maximization. The challenge is that we often have non-financial types calculating this rather financial formula. In addition, the data we use can be rather subjective. That said, ROI can be an effective tool when the formula is well-defined. Boiled down, the formula for ROI is as follows:
ROI = (Gain from the investment–Cost of the investment)/Cost of the investment
While the gain from the investment is more straightforward in the world of retail, for internal technology initiatives, it can be a bit more complex. What I have used in the past is a calculation that uses the current cost of a process, since this cost should disappear once the initiative is implemented. The investment cost should include the cost for any internal and external resources required, including backup resources that would be required to backfill operational resources for the duration of the project. Also, include costs for any required hardware and software.
Ultimately, you want a positive ROI. However, few projects show a positive ROI within the first year. Show how long it will take for the ROI to become a positive number. While that could potentially take a few years, if the lifetime of the process is 10 years or more, the benefit is real.
Maturity value is my favorite IT intake strategy. I love standardized and repeatable processes, and I contribute to them any chance that I get. Maturity value refers to how mature the organization's business processes are today and what we wish them to be tomorrow. A mature business process is well-documented. It is an organizational standard for which resources have been trained, and it is repeatable.
Along with proof of documentation, in an audit situation, we can show proof of implementation. Ultimately, we want to get to a place where any deviations from the process are detectable and traceable. That would be a high level of maturity, which few organizations achieve. However, one does not have to be at the highest level to appreciate the gains from mature business processes. While most maturity value methodologies would indicate that the lowest level of maturity would be level 0, to use calculations, it works better, to begin with level 1 to avoid divide by 0 errors. Who says we can’t take some liberties with our IT intake strategy? Below are some examples of what defined maturity levels can look like. Note that these can be refined to fit with the specific business in question.
- Level 1 would be when there is no process in place. Basically, everyone does whatever they need to do to get the job done. There is a lot of information in people’s heads that has never been written down.
- Level 2 is more ad-hoc. It is recognized that there should be a process, and often there are people who do use the same process. But still, nothing has been formalized.
- Level 3 is when someone has actually taken the time to write down the process, but it has not been formally rolled out to the organization. It is repeatable, but there are deviations from the process and usually some workarounds.
- At level 4, the process has been formally rolled out, and people have been trained.
- Nirvana is level 5. The process is followed by everyone, and deviations can be traced and tracked. There should also be a formal change process with governance in place.
Maturity value can be used to identify a business process that will move an organization higher along the scale of process maturity.
Whatever IT intake strategy you choose… choose
Note that you can choose whatever IT intake strategy or combination of strategies suits your organization and best aligns with the strategic plan. However, the one thing we do know for sure is that resources are limited, and we cannot continue to take on every initiative that is presented to us. If we continue to do so, we run the risk of incomplete or poorly developed initiatives, replicating work between departments, and the one we should avoid at all costs… burning out our resources.
Featured image: Shutterstock