25% of technology projects fail, plain and simple. And that’s before we account for the projects that “succeed” without showing a return on investment, or that need to be reworked or redone shortly after completion. At Forbes, they have a few theories as to some of the common reasons for these failures, and two of those reasons really resonate with us: poorly defined outcomes and solving the wrong problems.
Obviously, there’s a lot more to managing a technology or IT project than defining the right KPIs. You need to wrangle stakeholder buy-in from across your operation, you need to devote the right resources to the task, and you need to manage to a clear timeline. But establishing measurable KPIs is a necessary prerequisite to doing any of the above successfully.
Again, if you’re updating your email infrastructure to the cloud, or maybe rolling out a new order fulfillment infrastructure, your odds of success go way up if you choose the right KPIs. This is for a few reasons:
All of this is to say that defining your KPIs from the outset can be a big help in terms of addressing the two pitfalls we brought up above. It gives definition to your outcomes in a way that improves project guidance; at the same time, it centers your IT project around specific business goals, thus ensuring that your project doesn’t solve a problem that your business doesn’t have.
Okay, we’ve made a case for the importance of setting the right KPIs, but how do you actually do it? Step one is to create alignment between your project and larger operational goals. If, for instance, your company is seeking to decrease your customer churn rate, any technology project should be framed around directly improving churn or giving employees the tools to do so more easily. In this case, you would set churn as a KPI, yes—but you would also narrow down some more platform-specific goals. If your project involved improvements to your customer support infrastructure, you might track customer ratings of service interactions and ratio of help desk tickets closed (total or within a particular timeline). By contrast, if you’re building out an internal tool that your HR department is going to use to increase employee satisfaction, your target KPIs might revolve around employee usage—how often employees sign on to the platform, the average session length, etc.
In creating this kind of alignment, you can strengthen your vision for the future of the project. This will, naturally, help you track implementation milestones as well. If you’re expecting a beta rollout of an employee engagement tool that has a 20% use rate in its first week and 10% use rate in the second, you know that you still have room to improve on the offerings. Better yet, you know what to ask your users about when you send them a follow-up survey about the beta.
In other words, your KPIs should be derived from your company’s CSFs, i.e. critical success factors. These are the events or goals that define a successful project, and as such that should remain in view throughout the length of your process.
Once you’ve gotten a sense of how your IT project fits in with your larger business goals, it’s time to get a little bit more granular regarding the KPIs themselves. Specifically, it’s time to divide up your potential metrics into lagging indicators and leading indicators:
Regardless of what are your IT project is in, you’ll want to have a mix of lagging and leading indicators if possible. Why? Because combining these different KPIs gives you a quicker view of the processes that are being impacted, such that you can begin to understand what the potential results might be even before they’ve been translated into dollars and cents. As a result, you can maintain support and buy-in for the project before it’s directly impacted your ROI—meaning there’s less of a chance the C-suite pulls the plug on something that’s actually poised to show results.
So, let’s say your big project for the immediate future involves modernizing your ERP (enterprise resource planning) system in such a way as to reduce data silos and thereby speed up order fulfillment through decreased stockouts. For a lagging indicator, you might be looking at order cycle time (i.e. average time from an order being placed to the order being fulfilled) and similar metrics. For a leading indicator, you might measure the aggregate amount of data being uploaded to the ERP every week—with the assumption that if data usage is increasing, that suggests that data silos are decreasing, and you would expect some operational improvements to be on the way. By the same token, you might track the stockouts themselves—if they’re going down, it could suggest that your order fulfillment and inventory management teams are working with enough information to keep inventory levels responsive to orders.
Above, we said it was important to get fairly granular about your KPIs in order to get both descriptive and predictive about what’s happening with your new technology. It’s possible that you read this advice and immediately thought of 100 different metrics you could track to get the most comprehensive possible view of the project. Don’t. Tracking too many KPIs can quickly become counterproductive. Why? Because developers or other IT staff can get overwhelmed by all of the things that they have to keep track of, and it can become difficult to know where the project’s true priorities lie. If you’re tracking a server migration project aimed at speeding up processing times, tracking and reporting on dozens of different metrics during your migration will only muddle the picture you’re trying to paint for your stakeholders, while potentially slowing down work.
For marketing projects, HubSpot suggests tracking something like 4-10 KPIs. For IT and technology, there’s no reason not to choose a similar number. At the end of the day, you’ll want to be able to present a clear picture of the success of your IT project to your stakeholders, and that’ll be particularly difficult to do if they have to wade through dozens of numbers just to get to the ones that really tell your story.
Let’s say you’ve aligned your KPIs with your CSFs, you’ve chosen lagging and leading indicators, and you’ve whittled down your most important KPIs to a select few that will paint a clear picture of how the project is going. Well done! Does that mean you’re done? Not quite. As your project evolves and enters new phases, your KPIs will need to do the same.
At the outset of a project, before you’re even remotely close to having something to show for your work, your top KPIs might be quantities of data migrated and person-hours reserved for the project. Once your migration has reached the point of usability, you might switch to tracking data usage and network availability. After the initial rollout, you might add in some new KPIs that account for the ways that users are actually engaging with the migrated network or service and how that’s impacting your longer-term goals, e.g. user participation and productivity. By staying agile and adjusting the metrics you’re focusing on, you can shepherd your IT project through each phase with confidence—setting yourself up not just for immediate success, but for avoiding the lengthy rework that so often results from hasty IT project deployments.
Intertec offers a wide spectrum of options in infrastructure management. We perform end-to-end outsourcing of specific infrastructure functions and develop strategies to construct and integrate technology architecture. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!