Lifecycle management is more than a buzzword, it is the central organizing principle of all IT efforts. Understanding how to differentiate or coordinate Lifecycle processes is perhaps the key challenge in IT today. Program lifecycle management (PLM) represents a deliberate attempt to reconcile and combine multiple lifecycle management tasks within a single, unified approach.


The Problem


Why is PLM important and necessary? The motivation behind PLM has been present for decades, and despite many attempts, the problem remains largely unresolved. IT projects are getting more complicated, not less; and this trend is accelerating, not decelerating. PLM directly addresses the root causes of “IT complexity syndrome” in a comprehensive fashion. Those root causes for this complexity include:


  • System/service/solution sophistication continues to increase as the pace of technological change accelerates, thereby driving new and more demanding expectations from end users and stakeholders.
  • Interoperability expectations have increased exponentially both within the enterprise and externally between enterprises and stakeholders.
  • Bandwidth and resource exploitation expectations have become much more complicated, including storage management, virtualization, security and wireless connectivity.
  • The pent-up expectations for data exploitation are only now beginning to be realized. After 10 years of evolution, business intelligence tools and data warehouse capabilities are finally cost-effective and integration with unstructured sources through enterprise content management (ECM), collaboration or Web 2.0 has begun.

Most IT projects begin with the office or group charged with making projects happen and funded to manage them. Efforts to tackle lifecycle issues within most enterprises are likely to be frustrating if the management office is not addressed first. Despite improvements in technology, program efficiency still eludes our industry


How Many PLMs are There?


Some might be familiar with the acronym “PLM” as representing product lifecycle management. So how do variations on PLM relate to one another? There are five PLMs that are closely related:


  1. Program lifecycle management,
  2. Portfolio lifecycle management,
  3. Project lifecycle management,
  4. Product lifecycle management and
  5. Process lifecycle management.

These PLM variations can be viewed as a hierarchy within a single, unified enterprise context. More importantly, this unified context allows the application of a common semantic foundation which in turn allows the coordination of all related data within a single PLM data repository. This is not a master data management (MDM) solution although it does help in establishing enterprise-wide MDM governance. Program lifecycle management supports active working processes and capabilities already familiar to those practitioners of the five PLMs. (Throughout the remainder of this article, PLM will refer to program lifecycle management.)


A few organizations refer to a similar concept called enterprise lifecycle management. However, the PLM described here is meant to serve a more specific purpose, namely the unification of program management office (PMO) efforts. The PMO is ultimately responsible for all IT program successes and failures, but there are some enterprise details or processes that fall outside their normal management scope. PLM as a unified practice has been designed to optimize the consolidation of a significant number of essentially related processes and capabilities. PLM does not integrate all IT activities though.



So, the hierarchy is examined a little closer, some obvious conclusions arise. Products, systems or even services can be viewed more or less synonymously as capabilities. A project might consist of one or more capabilities (or capability modules). A portfolio might consist of multiple projects, multiple products/systems or a mix of both. Not everyone follows this strict hierarchy, and they don’t have to. The key thing to keep in mind is the ability to group all of these elements together and maintain the relationships between them (either through reporting chains, requirements or parent-child organization).


PLM, a Vision


All work in IT and particularly in enterprise integration, derives from written, verbal or assumed requirements. Requirements represent the information nexus between consumer and producer, between management and developers, and between planning and execution. Begin building a lifecycle framework that integrates all of those interests and participants? PLM is the a requirements-focused methodology and practice for facilitating enterprise solutions, designed specifically for use by PMOs.


Another way to think about PLM is as a total program visibility (TPV) mechanism. TPV represents the ability to instantly correlate and reconcile the many seemingly diverse program elements that exist across a complex enterprise. This usually occurs through visual tracking and automated reports, which illustrate the issues and relationships between requirements and other program elements. No matter how many systems or component/partner organizations are involved, if there is a centralized single-instance PLM framework, then the various processes and lifecycles associated with an enterprise can be holistically tracked and managed. The mere act of consolidating all of these processes and data centrally eliminates the single most critical problem facing PMOs today - the ability to both see the big picture and drill down to specific details in an automated fashion. Today’s PMOs are essentially integrated on the fly and are top heavy with manual processes.



PLM Defined


PLM is the recognition that specialization is not the only or even the best answer for managing complexity. Often, an excessive focus on specializing specific areas of expertise merely add to the level of complexity and confusion that typical PMOs face every day. The truth is that many, if not most, of the people who support PMOs need to be generalists to fully grasp the breadth of topics that they are expected to deal with. It is very difficult to get work done if a parade of experts is required to fulfill everyday tasks and, worse yet, if those experts constantly change as the industry evolves.

The key to PLM is understanding that the PMO runs on information. That information must be easily accessible, transportable, translatable and available directly to the decision-makers without going through layers of expert interpretation first. This doesn’t mean that other people don’t add value to the information, there will always be a need for diverse skills in the PMO. However, it means that enterprise volume management system (EVMS) analyst is no longer the primary interpreter of financial data and that the requirements analyst is not the only person who can produce requirements reports. The reality is that no matter how many specializations are created, the core processes are still all related within specific contexts. Those contexts provide a holistic view of what’s happening in the PMO and more importantly illustrate why it is happening.


What is a PMO?


The entity is charged with management of one or more programs and portfolio of systems or specifically the integration of systems. The enterprise PMO concept or title began appearing in print about five years ago, but despite the amount of time that's passed since then, the practice of enterprise PMOs hasn’t progressed much beyond the original PMO paradigm. In other words, the true potential of the PMO has yet to be fully realized, with a few exceptions. The obvious question is why isn't this occurring more rapidly? Some might feel that the charter for an enterprise PMO is beyond the scope of what most PMOs should accomplish. It might be considered dangerous or out of scope to plan for or manage relationships and interactions that occur around the PMO rather than within it. The problem with this thinking however, is that nearly every IT-focused PMO is now expected to integrate within the larger context of their enterprise. Even non-IT PMOs feel the pressure for increased oversight and accountability, and all PMOs share one characteristic - complexity.

The complexity that must be managed in order to successfully execute a program is perhaps the single greatest challenge facing leadership today. The advantage with a PMO designed to be an enterprise PMO from the ground up is that complexity is tackled directly, with mitigation built into a set of fused processes.


The most basic premise of the agile movement is that trying to over-regulate processes subverts the core goals of innovative and rapid development, thus the process paradigm becomes a bureaucracy or ideology more than a facilitation medium. PLM views process management as it views all other elements of PMO business - elements within a larger whole that cannot be easily separated from one another without losing the relationships and contexts necessary to make the larger organism work. Product lifecycle management, for example, is becoming especially dependent upon the successful implementation of agile processes, given the ever-decreasing sales and product development lifecycles. In many ways, program lifecycle management represents a compromise between agile development or deployment concerns and more extensive or complicated oversight capabilities.


Related PLM Processes


While there are five key elements or PLMs embedded within program lifecycle management, there are also a number of related corollary processes, whic include:


  • Enterprise strategy,
  • Configuration management,
  • Change management,
  • Earned value management (EVM),
  • Risk management,
  • Requirements management,
  • Enterprise architecture,
  • Enterprise governance,
  • Acquisition management and
  • Compliance management.

The exact mix of which of these processes will be employed and blended within PLM in any individual enterprise is dependent on the nature of those organizations. For example, Department of Defense (DoD) PMOs will be much more likely to focus on EVM, given the trend toward greater oversight and regulation being tied to EVM systems. Financial organizations or health care enterprises may be more focused on various privacy and compliance issues. All of these concerns will likely show up in three places: strategy, requirements and governance.



PLM is poised to make a radical impact on the nature of IT projects. It represents one of the best hopes of not only combating the decades old disconnect between performance and expectations, but also of preparing us for next generation IT solutions. A lot of catching up must be done in order to fully realize industry potential; PLM puts us squarely on the right path.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access