Chris Crawford and Bob Kress of Accenture recently published an interesting interview in which they discussed the benefits, requirements and challenges associated with rationalizing an organization’s application portfolio. That got me to thinking about my experiences in this area over the years, and some of the lessons learned. These may seem like they should go without saying, but given number of failed, late, over-budget, and/or under-delivered IT projects that are still occurring, that’s apparently not the case
6 Opportunities and Risks of Application Portfolio Rationalization
Look at Opportunities to Rationalize Infrastructure, not Just Applications
This was a great point raised in the above interview. Application rationalization is frequently an important and worthwhile task to tackle, but it’s invariably very difficult. Typically, most applications get deeply embedded in an organization’s processes, often in subtle and difficult to identify ways. Infrastructure rationalization isn’t easy, but it does tend to be a little more transparent in its risks and potential impacts.
Have Executive-Level Buy-In, Understanding, Sponsorship and Trust
This is really critical. It’s imperative that IT have the backing and sponsorship of the business, at an executive level, before engaging in any large-scale rationalization project. In my experience, rationalization projects of any kind are difficult, high-impact and high-visibility. To succeed, the business, at an executive level, has to understand this, to understand the benefits, but also the risks, so they can provide the necessary input and support to deal with the inevitable conflicts and issues that arise over the course of these projects.
Start Small to Establish A Track Record
This is another important point. If your IT organization has a good and trusting relationship with the business, and there’s a commonly understood mission and set of objectives, then you can tackle the big projects. If not, find try to find something small, with a high probability of success, and work to establish a track record of delivering value to the business (this may not be a rationalization project, but if it is, make it a small one). By way of analogy, if you’ve been sitting on the couch for 10 years, and decide you’d like to run a marathon, then rather than putting on the shoes and hitting the start line, maybe start with some brisk walking and work up to the longer distances.
Be Pragmatic When Establishing Scope and Objectives
This point was also alluded to in the podcast – it’s important to be pragmatic when determining the scope and end objectives of your plan. It might be nice to have a single system for accomplishing task ‘X’ but if the business currently has 20 systems, and you’re able to reduce that to 3, but not 1, then this is still a significant improvement. Be willing to compromise to achieve realized successes rather than aiming for perfection and failing to achieve anything.
Demonstrate Progress, and Early Wins
Wherever possible, avoid big-bang style projects that require extended periods without visible, tangible progress and results. Try to identify milestones that are visible and meaningful to the business, and make sure that at least some of these milestones are delivered early in the project. Keep the business engaged in the process throughout. This is essential to maintaining the morale and commitment of both the business and IT project members over the course of what are often long and difficult projects.
Be Able to Demonstrate and Document the Value of the Project
As with the other items, this may seem obvious, but make sure there is shared agreement among all stakeholders and involved parties (business and IT) about the benefits that are expected from the rationalization project. Then make sure that you establish some quantifiable measurements of the ‘before’ state, so you’ll have something to compare the ‘after’ state to. This is very valuable in terms of both demonstrating the value achieved when the project is completed, as well as providing input for subsequent projects and increasing the organizational discipline in terms of being able to establish and measure the return on investment in IT projects. I know this is often difficult, but demonstrating an understanding of cost-benefit to the business, and a commitment to delivering tangible, quantifiable value wherever possible goes a long way toward establishing and maintaining a high-trust relationship with the business.
Rationalization projects – application and technical infrastructure, are almost never easy, but they can often generate significant immediate and ongoing improvements to the organizational bottom line. And since technology and the business environment is constantly, and ever more rapidly changing, these types of projects are likely to be with us for the foreseeable future. So make sure you know how to tackle them successfully, and maximize your chances of delivering positive benefit to the business bottom line.
Are there any other opportunites or risks that you see for application portfolio rationalization? Share your thoughts in the comments below.
Image Credit: Justin Ornellas