Is IT agility the new synergy? A tired catchphrase bandied about the industry with reckless abandon?
Yes and no.
Yes, IT agility as a weak conceptual phrase is overused and only loosely understood. Beyond a buzzword, however, becoming IT agile can be an ethos with substance.
Regardless of size, your organization can benefit from the principles of becoming more IT agile as long as the concept is readily understood and consciously implemented with clear goals in mind.
What Is IT Agility?
Simply put, IT agility is the ability to maintain your systems (replacing equipment, adding or subtracting equipment, updating subsystems and methodologies) in response to market realities. As the market changes, the way one does business changes—and as the way one does business changes, IT systems have to adapt.
To be IT agile means having the systems, personnel, and tools in place to change your infrastructure, development process, and IT offerings quick, as the market changes demand.
At its very core, being agile is not only about being able to effectively, efficiently, and quickly implement changes as the market dictates, but also about implementing an organizational ethos that values and prioritizes adaptability.
Any business, big or small, will see dividends as they become more agile—whether as a result of Time to Value (a leaner, more efficient infrastructure means quicker iterations) or increased opportunity (an up-to-date system means up-to-date business).
However, before you dive right into shaking up your organizational culture and ripping out aging servers, it’s important to understand what kind of agility you want: range-agility or time-agility.
Range-agility is about expanding or shrinking your organization’s capabilities and services tendered. Getting rid of underutilized hardware, software, products, and/or techniques to make way for in-demand services (or simply to streamline your process) is the very definition of range-agility.
Retooling for range agility can be internal (an evaluation of your systems and your capabilities) or external (partnerships and alliances). Either way, your organization needs to be ready—and equipped—to react to market changes quickly.
Simply put, range-agility is having the systems in place to quickly augment your organization’s services (either more or less) on-demand as the market(s) dictate(s).
Ok, what about time-agility? Are your routines and subsystems lean and quick? Can your organization go from inception to production in the blink of an eye? Well, that’s one half of time-agility.
The other half is being able (having the system and personnel in place) to tweak, adjust, or otherwise retool your infrastructure just as quick.
As trends rise and fall faster and faster (fidget spinners anyone?) businesses need to get to market quicker than ever. Can your team adapt your IT systems quick enough to cash in on the ground floor of the next fidget spinner?
If you have time-agility you’re likely to get in the right position at the right times. Your IT systems need to be flexible enough to react to incoming opportunities. If your organization is time-agile, it’s better equipped to act in smaller windows of opportunity.
Regardless of the type of agility you’re after, you need the personnel, tools, and mindset in place to react, and react quickly.
Implemented in similar ways, range-agility and time-agility lead to drastically divergent outcomes. Seeking to have both in the same system is a net negative. As such, it’s important to pursue (driven by organizational structure and market realities) one kind of IT agility over the other, not both.
How does one become agile then?
Well, there are things you can do right away, but don’t expect your organization to become agile overnight. Implementing changes aimed at making your business more IT agile should be approached as a long-term/iterative process.
First and foremost, your organizational ethos needs to be bent towards effecting change and embracing agility. Once everyone is onboard and ready to make changes, an incremental strategy that has both short-term and long-term goals is key—a deep, explorative conversation to ascertain what is driving the desire to change will help teams identify specific, realistic goals.
For both range-agility and time-agility, implementations should focus on not only physical implementations (hardware, software, etc.) but also project management, enterprise architecture, portfolio management, the rapid adoption of new platforms, change management and the continuous deployment of platforms.
Making It All Work
While most measures of success are going to be personalized (identifying goals to become more IT agile will—in part—determine your metric for successful implementation), your agility should be graded on three separate, but interrelated, criteria:
- Elapsed time
Maybe the most obvious of the three key measurements (especially when it comes to time-agility) is elapsed time. Are your efforts at improving time-agility in your organization speeding up your iterations? Measuring each step in the entire chain will give you better insight into where you can make improvements, increasing your overall agility.
However, exorbitant spending on improving elapsed time (becoming more IT agile) can be counterintuitive—it’s up to your organization to balance speed with spending. If the cost to become more IT agile is not met on the other side of the equation, it may not be worth it.
Elapsed time and cost can be measured internally, but you’re going to need customer/client feedback to measure quality, especially when you’re trying to improve range-agility. Are your services/products as good or better as you reduce elapsed time? Is the quality of your offerings suffering as a result of an increase in range-agility? These are questions that need to be answered by the end user and your organization should take steps toward gathering such data.
In the end, measuring the success of your IT agility efforts will come down to an acceptable (or intended) balance of all three criteria—time, cost, and quality. Your organization needs to achieve a balance that is acceptable to both the system, the market, and the end user.
About the AuthorMore Content by Jake Fellows