Sticky ToolLook: What are some of the obstacles organizations encounter when deliberating about whether or not to incorporate an application lifecycle management (ALM) solution? What do you suggest to these organizations?
Matthew Klassen: There are several common obstacles as organizations deliberate about investing in ALM. The following are the issues most often cited:
- They are not sure that an ALM solution will provide enough value to the organization to warrant the investment. I recommend that organizations evaluate the total value as well as the cost of ownership over a multi-year period. Gartner suggests that a good ALM solution should provide benefit in productivity, quality, auditability, predictability, and agility. Any reputable ALM vendor should propose a solution that includes clearly defined objectives (issues being solved and improvements), a phased plan to get there, the value of achieving those objectives, and a framework to measure progress towards those goals.
- They have existing tools in place and are concerned about replacing them because of the amount of investment they have in them, political reasons, or simply the pain of change. I suggest that these organizations first assess their overall capability in software development across the ALM spectrum and, as part of that, assess the value of these existing tools. Once they understand what is working and what is not, they can better assess where to begin. Implementing ALM is not an overnight process, and many times there are other areas of improvement that could provide more value. In addition, they should look to a solution that will integrate and adapt to some existing tools and process that are truly lending value to the organization.
- They have organizational constraints that are unique to their organization and they feel will impede their ability to successfully deploy a "generic" ALM solution. These concerns range from regulatory concerns to industry-specific processes. I recommend as they look at potential ALM solutions--that they evaluate not only the vendor's tool or platform capabilities, but also the vendor's approach to assessing needs and tailoring the solution to adapt to their specific organization. It is also helpful if the vendor can give references of similar organizations and the solutions that worked for them.
- One group within the organization (PMO, business analysts, QA, developers/engineers, etc.) is motivated to make the change without getting the buy-in of the rest of the group. This one is tricky, because although there might be more value to the organization to adopt an ALM solution, many times, the interested organization does not have the power to actually put one in place. So, many times, it makes sense for the interested group to put in place a solution that serves their needs and has the potential to serve the needs of the other groups in the future.
STL: What differentiates what MKS refers to as "Intelligent ALM" from what most people think of as ALM?
MK: Intelligent ALM builds on the common notion of ALM and the analyst definitions of ALM. It moves beyond a competent set of integrated tools that cover the breadth of the disciplines of ALM and passes the notion of a coherent platform where artifacts are linked, workflow is automated, and cross-ALM visibility allows for better management and ultimately improved project outcomes. Intelligent ALM encompasses those qualities and mixes in the notion of adaptability, such that a coherent and competent ALM solution can adapt to highly varied enterprise environments (platforms, technologies, processes, etc.), scale to the enterprise beyond a single project or division, and maybe most importantly connect software development with business processes, business stakeholders, and business problems to truly impact the business.