BY Mahesh Singh | January 21, 2011 | Agile ALM

Someone recently asked that question in a community forum. Their own answer was – ‘Never’. There are 3 aspects of this question that I can think of and respond with while agreeing fully with their answer.

Application Lifecycle Management (ALM) is an Activity

To my mind the phrase Application Lifecycle Management naturally means managing the lifecycle of an application. An application’s life begins humbly – with a request from a user or a customer, which fights for its survival amongst scores of similar requests.  Once it wins, an application – however small or large – gets implemented/ developed to meet that request.  Once deployed, an application has a life, the length of which is determined by a number of factors such as TCO and conformance to changing business requirements.  The moment these factors weigh against the application, out it goes, upended by another request to replace that application!

A specific project which deals with an application – its selection/ prioritization, its development or implementation, or a making an incremental maintenance release of that application – is inherently ‘part of’ that application’s lifecycle management, however short or small. So, the question itself becomes redundant from that perspective. Organizations are executing projects (that deal with applications) as part of that application’s lifecycle, whether they realize it or not!

ALM is a category of Tool(s)

From an Application Lifecycle Management tools perspective, different vendors have taken a different tack. While some have focused on purely the development or software engineering aspects of it, others have taken a broader meaning which includes the portfolio and project management aspects of managing an application’s lifecycle. Still others have included a process-management aspect as well, that allows organizations to define processes for different aspects of the application lifecycle management, and use those processes in an integrated and standardized manner throughout the application lifecycle. Depending on the nature of the project, it will consume some or all of these aspects of ALM tools.

Various analysts such as Gartner, Forrester and IDC see it similarly; IDC actually has graphic that defines ALM as a combination of all three areas identified above.  At Digité, we believe in that same vision.  Thus, Digité provides a set of tools that allows our customers to manage the entire lifecycle on Digité or using a combination of ALM tools that Digité integrates with.

ALM is (part of) Organization Culture

A lot depends on an organization’s culture, their approach to workforce productivity and quality, and what some of their key performance parameters are. Organizations focused on multi-geography/ department workforce productivity, Total Cost of Ownership of an application, and quality will typically consider any project to be part of ALM rather than see it in isolation.  Every organization that understands the true nature and breadth of application lifecycle management will agree.

It would be great to hear some more perspectives!

Mahesh Singh
Sr. Vice President – Product

4 thoughts on “When is a project too small or too short for ALM?

  1. I might add that the exception swallows the rule. If you make exceptions to the ALM process management by exclusion, then you do not follow an ALM process. Every change, small or large, can have extreme consequences if not documented properly for later consideration.

    Well done on the three points!

  2. I think there is another aspect of organization culture. Some organizations are inherently process centric, metric centric (not just for the show of it). Some organizations tend to be individual centric where they depend on maverick leaders, individual heroism. ALM tools will add immense value to former category of organizations. To the other group, it will keep questioning the value of such a tool but still do continue to use it. They find it politically incorrect to say that they are not process and data centric.

  3. Sudi, yes. You are correct. I would even state it more bluntly and expand it a bit. An ALM solution that is put in place for all to use will make everyone better by consolidation of knowledge and efforts. Thus, avoiding gaps and overlaps. Whether they are good, or not so good, they will be better as a team by adherance to the process. Even a poorly thought out process that is followed is better than a good process that is not followed. The organizations who are individual centric do not get the most out of their teams if that means a concession to the ALM process. Look at the Yankees… Great individual contributors, but they do not play well as a team and therefore fall short of their goals. You can have great talent, but if they do not work as a shared knowledge unit – following an ALM process, they will not reach their ultimate team potential.

  4. To the extent that one is looking at purely a tool usage perspective, the use of ANY tool may be considered essential vs. an overhead depending on a number of factors – culture, size of project, grographical spread of the team, etc. If you consider the current situation of many collocated teams doing Scrum or Kanban projects, they are very happy with simply the physical Story/ Kanban board and have zero interest in any electronic tool. However, from the “application’s” perspective, whatever work they do would still be a part of that application’s lifecycle management. The point I was making is that an “ALM” discussion is not and should not just be an “ALM tool” discussion.

Leave a Reply

Your email address will not be published. Required fields are marked *

Top