Best Practices – Application Rationalization Project

Before embarking on an Application Rationalization project, the team should establish some basic groundwork for a successful project. Ensuring that objectives and scope are clearly stated, executive sponsorship engaged, and communications among the stakeholders is open and frequent. Client teams must be experienced, have authority to make decisions and should be dedicated to the project. Decision processes and decision rights must be defined, and a reasonable timeline must be established, communicated and monitored.

  • It is crucial to identify the stakeholders and understand what they want most from an Application Rationalization effort. This can entail consolidation of data center, system software, communications networks, desk top computers, data center tools, end-user computing tools, and application software., as well as functional outsourcing of application development and/or maintenance and support activities.
  • Establish which organizational, functional and governance aspects of the current state support future goals and which do not. Focus on understanding the issues driving the assessment, the IT strategy and how well it aligns with the business strategy, and any constraints that exist, including regulatory, environmental, security or privacy issues.
  • A successful applications rationalization project includes both a functional approach and a technical approach.
  • The functional approach describes what business processes the applications actually automate, and the technical approach describes how the applications are configured and operated. If only one of these approaches is used, a narrow view of the application portfolio will be created, which can lead to decisions based on incomplete or missing information.
  • Assessment of enabling technologies will require a great deal of user interaction. It is critical to involve a multi-discipline team of stakeholders in the review of technologies, avoiding assumptions and recommendations made in a vacuum.
  • The system software track covers operating system software, networking software, systems management tools, storage software, database management ERPs and teleprocessing monitors, data dictionaries, reporting tools, web technologies, end-user tools, code libraries, compilers, productivity tools imaging and workflow management systems, etc. The emphasis is on how work comes into the IT organization and how it goes out.
  • The hardware track covers end user desktops, data center/hosting, storage devices and telecommunications equipment. We focus on traditional capacity performance, utilization and consumption patterns along with ability to scale up and down. This aspect is important because changes to applications usually drive changes to hardware.
  • Sometimes, making only those changes that are necessary to enable the Target Delivery Model may be most prudent. It is crucial to follow a theme, such as “greater centralization” or “more local control”, so that decisions follow a consistent goal set.
  • Since IT affects every area of the organization, it is wise to include the broadest practical definition of “users” and “stakeholders.” Too narrow a definition in early project phases is often a false economy that can result in critical delays and re-work in later project phases.
  • In every case where we have been consulted to remedy an unsatisfactory transformation outcome or outsourcing relationship, insufficient attention to and resourcing of governance has been a major contributing factor. Getting this right the first time is of critical importance to
    the chances of success.
  • Start out by assuming that the core governance roles are full-time commitments

TBI has the staff, the experience, the tools and the industry background to help you through all the phases of Application Rationalization.

Share Button