PLM and the PMO

Program Lifecycle Management is the recognition that specialization is not the only or even the best answer towards managing complexity. Often times, an excessive focus on specializing specific areas of expertise merely adds 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 that parade constantly changes as the industry rapidly evolves.

The key to PLM is understanding that the PMO runs on information. That information must be easily accessible, transportable, translatable and must be available directly to the decision makers without going through layers of expert interpretation first. This doesn’t mean that other folks don’t add value to the information, there will always be a need for diverse skills in the PMO, however it means that EVMS analyst is no longer 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 then allow us to provide a holistic view of what’s happening in the PMO and more importantly illustrate why it is happening.

The PMO is the entity charged with what Gartner describes as "Integrating Eosystems."

So, What is an PMO
A Program Management Office, or PMO, is an entity charged with management of one or more programs and portfolio of systems or perhaps specifically with the integration of those 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 haven't progresses much beyond the original PMO paradigms.

In other words, the true potential of the PMO has yet to be fully realized but for 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 are charged to be accomplished. It might be considered dangerous or out of scope to try to plan for or manage relationships and interactions that occur around the PMO rather than within it.

The problem with this thinking though, 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 in common - 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 that is 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.

Copyright 2012, Semantech Inc. All rights Reserved

Read More

Introducing Program Lifecycle Management

Lifecycle Management is more than a buzzword, it is the central organizing principle of all Information Technology (IT) effort. 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
So why is PLM important, why is it necessary? The motivation behind PLM has been with us for decades and despite many attempts it 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 this trend and has been developed to attack them in a comprehensive fashion. Those root causes for this IT complexity syndrome include:

• System / Service / Solution sophistication continue 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 (this covers storage management, virtualization, security, wireless connectivity etc.)

• The pent-up expectations for data exploitation are only now beginning to be realized (after 10 years of evolution, BI tools and data warehouse capabilities are finally cost effective and now integration with unstructured sources through ECM, collaboration or Web 2.0 has begun).

There are a number of different places where we could tackle this growing complexity, but one place stands out – at the beginning. The beginning of most things IT tends to be the office or group charged with making projects happen and funded to manage them. Whatever else we do elsewhere with the myriad of Lifecycle issues that exist in most enterprises, if we don’t tackle the management office first our efforts will likely be somewhat frustrated.

PLM is quite literally a Lifecycle of Lifecycles...

How Many PLMs are There ?

Some of you might be familiar with the acronym “PLM” as representing Product Lifecycle Management. So how does these variations on PLM relate to one another? There are in fact five PLMs that are closely related:

• Program Lifecycle Management
• Portfolio Lifecycle Management
• Project Lifecycle Management
• Product Lifecycle Management
• Process Lifecycle Management

These PLM variations can be viewed as a hierarchy within a single, unified enterprise context. More importantly, this unified context allows us to apply a common semantic foundation which in turns allows us to coordinate all of the related data within a single PLM data repository. This is not a Master Data Management solution although it does help greatly in establishing enterprise-wide MDM governance. Program Lifecycle Management supports active working processes and capabilities already familiar to those practitioners of the five PLMs.

There are a few organizations, IBM for example, who refer to something similar called Enterprise Lifecycle Management. However, the PLM described here is meant to serve a more specific purpose, namely the unification of the Program Management Office (PMO) efforts. The PMO is ultimately responsible for all IT program success or failure, but there are some enterprise details or processes that fall somewhat outside their normal management scope. PLM as a unified practice has been designed to optimize a consolidation of significant number of essentially related processes and capabilities. PLM does not integrate all IT activities though.       

Copyright 2012, Semantech Inc. All rights Reserved 

Read More

Process Management & Process Fusion

Innovation and Technology both require comprehensive management - while there are quite a few paradigms out there already in regards to assuring best practices in program/project or portfolio management, none of them seems to have yet been able to wrap everything together seamlessly.  We are going to examine this problem space in the context of something we refer to as Program Lifecycle Management (PLM), which we will define in a future post. Today we're going to look at one part of the program management equation - Process.

Since the late 1990’s, there has been a certain level of obsessive focus on process management as a cure to the ills of program management. The basic premise is that any process paradigm is better than none at all. A variety of organizations including the Software Engineering Institute (SEI) and International Standards Organization (ISO) have produced massive quantities of literature on the subject along with a variety of process management guidelines design to help PMOs develop new processes or improve existing ones. More often than not however, larger organizations are finding that they have to deal with multiple types or levels of process management. For example, an organization may employ one or more SDLCs (Software Development Lifecycles) as well as a variety of solutions that manage workflows and business rules. The government considers Lifecycle Management so important that it is restructuring various DoD commands as "Lifecycle Management Centers."

One of the better known examples of an SDLC* is CMMI (Capability Maturity Model Integration). In the federal government, CMMI certification is often used as a criterion for awarding IT contracts (i.e. a contract must demonstrate that they have achieved a certain CMMI level of competence through a formal accredited certification). The problem that many have found when relying on process management and / or such certifications is that they are not accurate indicators of the organizations performance in specific project scenarios. So, while the fact that an organization does have some repeatable or mature processes it doesn’t necessarily prepare them to solve problems any better than before. This may sound counter-intuitive but it is has been proven by a rather larger backlash in the software industry where complex process paradigms are now being replaced by new ‘Agile’ methodologies.

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 becomes a bureaucracy or ideology more than a facilitation medium. PLM views process management as it views all other elements of PMO business – all are aspects within a larger whole and cannot be easily separated from one another without losing the relationships and contexts necessary to make the larger organism work. Product Lifecycle Management (which is what most people view as PLM today) is becoming especially dependent upon the successful implementation of Agile processes, given the ever-decreasing sales and product development lifecycles.

Process Fusion, defined
Process Fusion is a realization that processes or process families do not occur in exclusion to one another - all of the processes inherent within a typical PMO serve the same overall set of goals & objectives. This can be applied in the context of a single solution lifecycle or hundreds depending upon the scope of the organization involved. Process Fusion requires mapping of key elements of process with one another to ensure that all aspects of complex programs remain coordinated.

Process Fusion requires automation and a comprehensive management paradigm...

* some would contend that CMMI is used for more than software development, however it is still a software development lifecycle approach at its core. 

Copyright 2012, Semantech Inc. All rights Reserved 

Read More