Application Lifecycle Management (“ALM”) is the term that describes product lifecycle management of software. It differs from the Software Development Lifecycle (“SDLC”) primarily because of the governance aspect. In ALM, the purpose of governance is to make sure the application always provides what the business needs. For example, if you were going to attempt to be a major force in the document or content management marketplace, apart from seeking to differentiate yourself from your competitors, understanding what your potential clients and their clients truly need could make or break your success. Even though the focus may be on a particular application, because that is what your clients have expressed a need for, a successful approach is to expose them to and raise their awareness of other integrated or integral solutions, whether that company provides those solutions or not. Typical stages in the application lifecycle include planning and design, development, testing, deployment, maintenance, upgrades, and decommissioning, with governance as the overarching driver. 

Gartner defines Enterprise Content Management (“ECM”) as the creation, storage, distribution, discovery, archiving and management of unstructured content and the ability to ultimately analyze usage to enable organizations to deliver relevant content to users, where and when they need it. Defining what an ECM system really needs in terms of lifecycle management starts with the creation of a governance framework. Governance is especially crucial in today’s typical commercial environments, which usually involve multiple product areas and multiple jurisdictions, as well as many different stakeholders and established methods of product development, sales and support. This article highlights how classic project management methodology can facilitate the stages of ALM and also provide five key takeaways for use in ECM implementation in any vertical.

Driving the Development and Design with Possible Future Uses in Mind:

As an example, when rolling out new ECM systems a few years ago, rarely was access to the content from a mobile device, a consideration for the solutions that were bought or built even though at the time, plenty of end users were using mobile devices to manage their own personal content: emails, photos, contacts, and more. Now, end users and customers expect to be able to access and manage their professional content the same way as they access and manage their personal content, and we need to ensure that solutions we develop and implement meet not only the needs of today, but also the potential needs of tomorrow due to evolving technology and how end users use and consume data. We already have a generation of employees who want to, and in many cases can, work from anywhere with an internet connection. Are the solutions you are implementing addressing that? What is the next smart phone or remote working trend that will impact how you deliver your solutions?

Determine Key Stakeholders in The Planning and Design:

In any application roll out, ensuring a comprehensive design based on stakeholder requirements is key to not only a successful implementation but also to ensuring the application delivers on planned benefits throughout its lifetime. Involving the appropriate stakeholders and interested parties in the development cycle, ensures that optimal platforms are being developed and that they will be used. Remember that stakeholders include not only the business department and their subject matter experts but also the end users, clients, and other business departments who will be impacted by a new or upgraded application. Too often, implementations fail because the business department buys or builds an application without asking the technology department—how it fits into the overall scheme of solutions provided across the company. On the other hand, too many solutions are implemented and barely used because the technology department did not adequately appreciate what the businesses and end users’ true needs were. When starting down the path of implementing any new application, make sure one of the first questions you ask is “Who needs to be included in planning and design because they will use the solution, support the solution or be impacted by the solution?” (i.e., Who are my stakeholders and how can their involvement and feedback be managed properly?).

Design Taxonomy:

What this means is, first understanding what the business drivers and their practical markers are before creating a taxonomy for the data that will be stored and used within the system, while making sure that there is enough flexibility in design to accommodate future business markers. Having indexed fields that allow linkage with other data sources used within the enterprise directly addresses this need. For example, in the law firm world, ensuring that all of your information applications incorporate the client, matter and fee earner number fields is an integral part of ECM system design and development. Another example: Making an accommodation for additional possible levels of classification within the current schema or recognizing that asymmetrical categorization is a possibility for the future would be good principles to incorporate into taxonomic planning.

Deploy Application Changes Reasonably:

For example, if a version change is only pertinent to a sector of the user population, limiting the exposure to that sector would be ideal. While making changes to an application, remember that these changes should be treated like a mini project with its own requirements and design. Again ask, “Who needs to be included in planning and design because they will use the solution, support the solution or be impacted by the solution?” Then we can consider the impact of this change to the end user population. The lesson here is that just because a change may be beneficial for a portion of the population does not mean that you should disrupt your entire end user base unnecessarily.

As an example, while fee earners, consultants or sales reps may need mobile access to their applications and data to support their extensive travel, this does not mean that the human resources team or secretaries and assistants should sit through training and installations for a feature that they will not likely use. Change for change’s sake without added benefit will create a negative user experience that you do not want associated with your application. Plus, you lose the goodwill of the end users that you will need the next time a change or upgrade is announced.

Evaluate the Application’s Utility on an Ongoing Basis:

The evaluation needs to be periodic and needs to ask the question given the business area(s) this was designed to support: Is it still meeting business needs? If not, why not? Can the application be improved to do so or does it need to be replaced? If the need no longer exists, does it need to be decommissioned? Both the business and technology stakeholders need to be very involved in this periodic evaluation.

A cornerstone of project management in relation to ALM is planning. Planning to the appropriate level, with the appropriate stakeholders, for both current and future business and end user needs. Using the takeaways above will allow you to create the ALM methodology for your organization that marries governance and project management principles for successful application implementation, adoption, improvement and eventual retirement.