Project Management

Project Management for Life(cycle)

Andy Jordan is President of Roffensian Consulting S.A., a Roatan, Honduras-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at [email protected]. Andy's new book Risk Management for Project Driven Organizations is now available.


Topics: Applications Delivery, Governance, Information Technology

Application lifecycle management has the potential to fundamentally change the way that we look at software applications, but from my perspective I’m not sure that we are maximizing the opportunity. At the risk of unfairly generalizing, there seem to be two types of reactions when it comes to ALM: People will either go “Huh?” or they will think that you want to talk about a suite of software products--Visual Studio Team System, StarTeam, Serena Dimensions, etc. Taking the generalization further, business people generally aren’t familiar with the concept and IT professionals are focused on the technology tools.

If we step back though, ALM should not be about ALM software--those are simply support tools. ALM should be a way to look at the management of an application from vision to retirement. Software tools can help support that management, but with ALM it often seems to drive the process, not support it. In this article I want to explore a possible way for an implementation of ALM to be more successful. There are some similarities with project management approaches and I’ve tried to flag those, but this is not simply a project management article--this is a request that you focus your ALM efforts on the business first and the software second.

Putting the management back into ALM
I can’t help thinking that the fundamentals of application lifecycle management fit well within the models of projects and programs. If we think about a traditional software development project then we cover a lot of the elements there as “snapshots”: one-off instances of managing requirements, design, development, testing, release, etc. If we then extend that model into a program, then we can handle different releases—full-version upgrades and then smaller maintenance releases.

There are elements that don’t fit so nicely into this model--issues management, governance, etc. are ongoing operational processes and if we try to “projectize” those, then we are betraying the concept of a project as a temporary endeavor. I am not trying to suggest that ALM should be considered just an extension of project management, but I can’t help thinking that the two are closely linked--especially from the PMO’s perspective.

If you are trying to map out an application’s lifecycle--whether it’s a product that you sell, an application that you have built for use within your organization or even the customization of a COTS product--then you can provide extremely valuable insight into the project planning process. Your application roadmap should immediately have major releases identified on it, and those can clearly be scheduled as projects within the application program. When it comes to minor/maintenance releases, these two may be able to be scheduled as projects--although there may need to be a little more flexibility here depending on how your organization sees patches/hot fixes, etc.

ADVERTISEMENT

Trending Articles

Is Project Management a Career? Should It Be?

by Mark Mullaly, Ph.D., PMP

Depending on your perspective, project management is a calling. It can also be a point of departure. An intermission. An accidental interregnum. A stop on the way to somewhere else. For some, it’s something to be avoided. Is it a career?

Please Learn and Understand AI

by Andy Jordan

Just like in any other aspect of life, AI is rapidly becoming mainstream in project management. Sometimes, too rapidly. Do you truly understand the capabilities, limitations and implications of the tools at your disposal?

Continual Project Management: Adaptability and Resiliency

by Michael Huber

When a PM awoke to his motorcycle and everything he owned stolen, he was forced to face the harsh reality that all of his plans were no longer feasible. Learn how he designed a positive outcome from this major setback.

From a governance or control standpoint, your project processes may not be able to dovetail quite so smoothly into ALM, although there are some similarities (and it is most definitely a business-focused exercise). We are dealing at this stage with the management and expansion of feature sets, integrations, performance, etc, and ultimately that will need to be elaborated into requirements documents for one of the releases that you have planned in your product lifecycle. The ability to map high-level features to specific releases early on allows for the development of a release feature set, for the provision of detailed requirements and for earlier development effort. If you are dealing with a customer-facing product, it also allows for earlier promotion and marketing.

Establishing ALM within organizations
I’m not sure how many organizations consider their implementations of ALM to be successful, and of course everyone’s definition of “successful” is different. In talking to a number of people when researching this article, those that felt it had helped talked about more efficient software development--they pointed to a closer tie-in between software issues and bug fixes/release features, or about a more integrated process from design all the way through release. What I didn’t get was evidence that the business and IT functions of those organizations had worked together on ALM, and perhaps most telling of all was a comment from a business owner who was skeptical of any benefits from an ALM implementation: “It’s just an excuse for IT to buy more software.”

The underlying message here for me was that business owners didn’t see that they had a role to play in the ALM space--they saw it as an exclusively IT arena, and truth be told, I suspect that some of the IT managers that I spoke to felt the same way. Before ever deciding to implement an application lifecycle management approach, you need to make sure that all stakeholders understand that they have a part to play in the solution.

The very definition of the term implies the management of the applications entire life--and that has to include the business management, the tactical operations and the application development. Just like a project that is implemented without the involvement of a group of stakeholders is unlikely to be welcomed by that group, so an ALM implementation is unlikely to be embraced by a group that had no say in its development. In order to maximize the benefit, I strongly feel that the decision to implement ALM--whether it is simply a set of processes or also software tools to support those processes--has to be made jointly between the business and IT functions (and I would most certainly include the PMO in that set of stakeholders).

I also feel that ALM has to start with the processes before ever we start worrying about which software suite to buy. Like any set of processes, a formal lifecycle management methodology needs time to settle in and become accepted--especially as many organizations will simply expand upon those processes that they already have in place (effectively “filling in the gaps”). In order to maximize the likelihood of choosing the right support tools for your organization, you need to ensure that the processes are fairly stable and then look for the suite that is most likely to fit within the way that your organization operates. Then of course you need to decide whether you are going to use all of the elements of those tools or try to integrate some elements with other pre-existing tools within your organization (it may take a while to replace or enhance your MS Project usage, for example).

Conclusion
One of the things that really struck me when I spoke to people about ALM before writing this article is that the concept is not broadly understood. If you ask Google to tell you all about it then the focus is very clearly on software rather than process, and if you speak to people who have implemented it they are thinking the same thing.

I suspect that part of this is that ALM is something that most companies do to some extent anyway--if you build software products, then you likely have a product roadmap (as would any other product) and the need to expand on the processes that support the roadmap into a more formal ALM approach is not readily understood. Similarly, most organizations these days understand the relationships between help desk logs and the need to address issues in applications and they don’t automatically see the need for a big software investment to more formally tie those and other elements together.

Perhaps the biggest challenge that ALM faces is simply that it is not yet well understood by all of the people that it is aimed to help--until both business and IT groups understand what ALM offers and the tangible benefits that it can bring, them there is the danger that ALM will continue to generate either a blank look or images of expensive software suites.

Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at [email protected]. Additionally, Andy is Vice President of a new Canadian professional project management body--the Project Management Association of Canada. Learn more about them at www.pmac-ampc.ca.




Comments (2)

Login/join to subscribe
ADVERTISEMENTS

I saw someone on the street eating M&M's with a spoon.

- Jerry Seinfeld

ADVERTISEMENT

Sponsors