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 nature of the industry expertise 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 EVM 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 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.
Copyright 2008, Semantech Inc.
Thursday, March 27, 2008
Monday, March 24, 2008
Complexity & PLM
As one might imagine, this is a difficult philosophical question. According to Hayenga (2008), there is a significant lexical difference between what is ‘complex’ and what is ‘complicated.’ He posits that complex systems are not merely those with many moving parts but rather complexity is inherent in systems and scenarios that are dynamic in nature or difficult to predict. This is a reasonable and pragmatic way of viewing the terminology and thus also tends to imply that systems which are highly dependent upon human interactions are necessarily more complex in nature. Humans, being the irrational creatures that we are, often interject a high level of subjectivity into the mix.
There is no better illustration of the dynamic interaction of many subjective individuals than a typical PMO. This of course becomes even more fascinating if their scope of interaction is elevated to the enterprise level. This becomes somewhat ironic when one considers that the PMOs have been created and chartered to correct perceived issues of system complexity which must be better managed. The reality is that much of what we consider to be “IT” problems are not technical in nature at all.
Recognizing a problem or a challenge is not enough. Many folks have hit the nail on the head in being able to identify the PMO or its associated management processes as the likely culprit of much of the related failures of IT projects / programs; however to date, no one has presented a comprehensive solution for this seemingly obvious problem area. There is recognition now though that such problems are solvable using new enterprise integration technology and techniques.
Complexity is implicit within each element of PLM (the other mini-PLMs or Ps). Over the years, the notion of “Portfolio Management” migrated over from the financial world to IT and has now become a new process discipline. As noted previously, Project Portfolio Management (PPM) popped up about ten years ago to address the obvious need to consolidate PMO processes. Product Lifecycle Management emerged over the last decade as an IT practice to address the very tactical aspects of design and innovation. Process management has been interpreted many ways – some schools of thought have advocated fairly sophisticated methodologies such as CMMi , others are adopting an “Agile” more flexible approach.
Copyright 2008, Semantech Inc.
There is no better illustration of the dynamic interaction of many subjective individuals than a typical PMO. This of course becomes even more fascinating if their scope of interaction is elevated to the enterprise level. This becomes somewhat ironic when one considers that the PMOs have been created and chartered to correct perceived issues of system complexity which must be better managed. The reality is that much of what we consider to be “IT” problems are not technical in nature at all.
Recognizing a problem or a challenge is not enough. Many folks have hit the nail on the head in being able to identify the PMO or its associated management processes as the likely culprit of much of the related failures of IT projects / programs; however to date, no one has presented a comprehensive solution for this seemingly obvious problem area. There is recognition now though that such problems are solvable using new enterprise integration technology and techniques.
Complexity is implicit within each element of PLM (the other mini-PLMs or Ps). Over the years, the notion of “Portfolio Management” migrated over from the financial world to IT and has now become a new process discipline. As noted previously, Project Portfolio Management (PPM) popped up about ten years ago to address the obvious need to consolidate PMO processes. Product Lifecycle Management emerged over the last decade as an IT practice to address the very tactical aspects of design and innovation. Process management has been interpreted many ways – some schools of thought have advocated fairly sophisticated methodologies such as CMMi , others are adopting an “Agile” more flexible approach.
Copyright 2008, Semantech Inc.
Saturday, March 22, 2008
A Troubling Trend
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. PPM or Project Portfolio Management was an early attempt to resolve the matter but it only addresses 2 of the 5 “P’s ” and only about half of the associated PMO processes.
Copyright 2008, Semantech Inc.
Only 34 percent of IT projects are considered to be truly successful, according to the Standish Group. Project Portfolio Management (PPM), which came on the scene in the late 1990s to help IT projects become more successful, has not measured up to its promise to solve the problem. Without a suitable alternative to PPM, should we be resigned to IT mediocrity? Carlson (2007)
IT projects have become more complex & difficult to manage
PLM directly addresses the root causes of this trend and has been developed to attack them in a comprehensive fashion. PPM or Project Portfolio Management was an early attempt to resolve the matter but it only addresses 2 of the 5 “P’s ” and only about half of the associated PMO processes.
Copyright 2008, Semantech Inc.
Thursday, March 20, 2008
Program Lifecycle Management - Vision Statement
All work in IT and in enterprise integration in particular, derives from written, verbal or assumed requirements. Requirements represent the information nexus between consumer and producer, between management and developers, between planning and execution. What better place to begin building a lifecycle framework that integrates all of those interests and participants? Program Lifecycle Management (PLM) is a requirements-focused methodology for facilitating enterprise integration solutions, designed specifically for Enterprise Program Management Offices (ePMOs).
This focus on requirements allows PLM to facilitate Total Program Visibility (TPV) instantly through tracking and reports that 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.
copyright 2008, Semantech Inc.
Wednesday, March 19, 2008
Linkedin.com Response: PMbok Error ?
Error in Glossary of PMBOK 3rd Edition? - I have observed that the definitions of Verification and Validation are vice-versa at Pages 328 & 329 in PMBOK, 3rd Edition. I know and I have learned that Verification is been done with the requirements in each phase of the project life cycle and validation is been done to validate the project execution in the user environment after implementing the project.
I hate to sound like I'm quoting quantuum theory here but the reality is that neither one of these groups have presented a definitive basis for their terminology. CMMi and PMBOK are merely efforts by professionals in similar fields to characterize aspects of information technology related methodologies.
There are many more methodologies beyond these two and I'm quite certain that you'll find further variation in the terms. You've run across the one truly great unsolved dilemma of IT - semantics.
One easy way to conceptually bypass PMBOK's confusion here is to consider that validation is actually "acceptance" if viewed from the end user or functional advocate's perspective.
Monday, March 17, 2008
What is an ePMO?
An Enterprise Program Management Office, or ePMO, 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 ePMO concept or title began appearing in print about 5 years ago, but despite the amount of time that's passed since then, the practice of ePMOs haven't progresses much beyond the original PMO paradigms.
In other words, the ePMO 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 ePMO is beyond the scope of what most PMOs are charged to accomplished. It might be considered dangerous or out of scope to try to plan for ore 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 an ePMO 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 2008, Semantech Inc.
In other words, the ePMO 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 ePMO is beyond the scope of what most PMOs are charged to accomplished. It might be considered dangerous or out of scope to try to plan for ore 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 an ePMO 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 2008, Semantech Inc.
Friday, March 14, 2008
Legal & Ethical Implications of PLM
There are actually quite a few fascinating legal and ethical implications surrounding the practice construct for PLM. The reason for this is simple; Program Management Offices (PMOs) are the places which control funding, contracts and oversight for almost all IT projects and many other types of projects as well. Thus, PMOs by nature are the organizations charged with managing legal or liability issues. Liability issues encompass a wide spectrum of topics including, but not limited to:
IT and ethics are generally not discussed in the same context. The reason for this is simple, people who work with data understand how easily it can be manipulated and in many cases clients are specifically interested in seeing data manipulated to suit various agendas. The introduction of the ethics discussion can often become very uncomfortable for the many folks who aren’t aware that this is happening and this is perhaps the main reason it so seldom occurs.
The management of organizations is an extremely subjective exercise, there isn’t a clearly defined comprehensive canon of ethics per se, just specific legislation here and there to prohibit or restrict certain practices that have been found to be problematic. From a service provider perspective, the key thing to keep in mind for PLM is that any set of decisions will be better served if the right data is available to the right stakeholders at the right time. Ultimately, the folks running the ePMO will determine the rules that focus on issues and data important to them. If an organization chooses to ignore critical data or attempt to change the nature of data provided to them then that clearly falls outside of the boundaries of liability for the PLM service provider.
Copyright 2008, Semantech Inc.
- Financial liability due to non-performance
- Financial liability due to negligence
- Legal liability due to contract disputes
- Legal liability due to product failure or non-compliance
- Legal liability due to security breaches, information privacy failure
- Legal liability due to information freedom of speech related issues
IT and ethics are generally not discussed in the same context. The reason for this is simple, people who work with data understand how easily it can be manipulated and in many cases clients are specifically interested in seeing data manipulated to suit various agendas. The introduction of the ethics discussion can often become very uncomfortable for the many folks who aren’t aware that this is happening and this is perhaps the main reason it so seldom occurs.
The management of organizations is an extremely subjective exercise, there isn’t a clearly defined comprehensive canon of ethics per se, just specific legislation here and there to prohibit or restrict certain practices that have been found to be problematic. From a service provider perspective, the key thing to keep in mind for PLM is that any set of decisions will be better served if the right data is available to the right stakeholders at the right time. Ultimately, the folks running the ePMO will determine the rules that focus on issues and data important to them. If an organization chooses to ignore critical data or attempt to change the nature of data provided to them then that clearly falls outside of the boundaries of liability for the PLM service provider.
Copyright 2008, Semantech Inc.
What About Product Lifecycle Management?
Product Lifecycle Management is a relatively new discipline for IT although it has been around for decades in the manufacturing arena. The product focus tends to be a narrow view, not taking in account any factors outside of the context of the product being managed. There is no ‘enterprise’ in this perspective. However within that product view the depth of insight is generally much greater as the goal of this process is the successful design and development of new products. Not surprisingly, this discipline is highly dependent upon detailed requirements data.
PLM views every system, every datacenter component, every SOA service as a product to some extent. Each of these elements has its own unique lifecycle and configuration and all of the information now is tracked used a variety of different tools and processes. For example, system configurations are often tracked using asset management tools or configuration management software such as Microsoft’s System Management Server. There are quite a few software products now that manage SOA service configurations rule or governance. PLM is premised that all of those approaches can to a certain extent be combined.
PLM views every system, every datacenter component, every SOA service as a product to some extent. Each of these elements has its own unique lifecycle and configuration and all of the information now is tracked used a variety of different tools and processes. For example, system configurations are often tracked using asset management tools or configuration management software such as Microsoft’s System Management Server. There are quite a few software products now that manage SOA service configurations rule or governance. PLM is premised that all of those approaches can to a certain extent be combined.
Copyright 2008, Semantech Inc.
Wednesday, March 12, 2008
Process Management & Process Fusion
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.
One of the more notable examples of this is CMMi. 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 counterintuitive 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 is becoming especially dependent upon the successful implementation of Agile processes, given the ever-decreasing sales and product development lifecycles.
Process Fusion
Process Fusion is a realization that processes 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...
Copyright 2008, Semantech Inc.
What is Project Management ?
Project management is generally viewed as a methodology primarily designed to manage (human) resources and schedules. As evidenced by the PMbok, project management is often extended to cover much more than that. However even if Project Management is extended in this fashion it still relies primarily on the data sets inherent within any typical Project Management software packages. That data is constructed around task definition, timelines, resource data and other variables or flags such as what might represent a critical path. The term ‘Critical Path’ refers to that set of tasks which is deemed (by someone) to be crucial to the overall success of the project. Anyone who has worked in a PMO and sat through some sort of status meeting can attest though, the problem with this data comes into play whenever the question “why” is asked. Why is the project running behind schedule, what is the problem that has led to the overrun?
There is no project management methodology or software that sufficiently prepares a manager to answer those questions. That manager is wholly at the mercy of someone else to explain the cause of the problem as none of that information will be accessible (by design) within the project management software. PLM recognizes that half of a picture is not 50% good, it can be 100% worthless as often times the poor data that we do have may indicate success when in fact the project is failing. Determinations of progress are extremely difficult to make in most situations using only project management software as there is no tangible method for assessing the true complexity of any given task if that task is essence only a placeholder representing a larger set of requirements data not available.
Copyright 2008, Semantech Inc.
There is no project management methodology or software that sufficiently prepares a manager to answer those questions. That manager is wholly at the mercy of someone else to explain the cause of the problem as none of that information will be accessible (by design) within the project management software. PLM recognizes that half of a picture is not 50% good, it can be 100% worthless as often times the poor data that we do have may indicate success when in fact the project is failing. Determinations of progress are extremely difficult to make in most situations using only project management software as there is no tangible method for assessing the true complexity of any given task if that task is essence only a placeholder representing a larger set of requirements data not available.
Copyright 2008, Semantech Inc.
Monday, March 10, 2008
What is Portfolio Management ?
Portfolio Management follows a simple metaphor borrowed from financial management – the ability to view or illustrate the “health” of something using a dashboard based upon a number of key indicators. Those indicators are typically focused upon or around cost, schedule and risks. Unfortunately, those indicators are generally somewhat subjective perhaps with the exception of the budgets which are being tracked. Schedules often don’t reflect the real work going on or can be completely rebaselined to make them look better / more successful. Risks and other project or program issues can be interpreted in just about any fashion, so if one is depending on stoplight charts generally the only indicator worth following is the one tracking the financial burn rate.
Portfolio Management if viewed from its traditional investment origins was never meant to provide substantial insights into the why behind financial trends – it is merely a mechanism to illustrate general movement or trends. IT Portfolio Management is used as a way to roll up multiple projects into a set of unified stoplight indicators to show how entire organizations or programs may be performing. Even though there are tools that are considered combinations of project and portfolio management even these seldom do more than provide drill down on resource and tasking issues (focusing on the primary schemas of most Project Management software products).
Copyright 2008, Semantech Inc.
Sunday, March 9, 2008
Understanding the Five P's - Part 1
I recently tried to engage the folks at the Project Management Institute (PMI) to discuss with them the efficacy of formalizing new standards that further specialization aspects of program management from one another. It occurred to me though that this is a good place to begin explaining what PLM is and why it is needed. There are essentially as many as five "PLMs" associated with what I'm describing as the new PLMs, these five Ps are:
Some may argue that these are all radically different from one another, I don't think so. We'll take a few posts here to review them one by one:
Program Management is generally considered a general category of practice or related practice areas. While sometimes software itself is referred to as programming, what programs are in our context is the coordination of people, organizations, technology and materials to achieve specific or well-defined goals. A program office may be responsible for one or more programs. An example of a real PMO that is charged to manage just one program is ELSG/EC. This office was created to support the Air Force’s Logistics ERP initiative, also known as the Expeditionary Combat Support System (ECSS). But even the EC has developed other related programs as issues have arisen, for example one dedicated to developing a legacy system migration strategy and another dedicated to developing a unified data architecture to support both Logistics or Finance ERP solutions.
Copyright 2008, Semantech Inc.
- Program Management
- Portfolio Management
- Project Management
- Product Management
- Process Management
Some may argue that these are all radically different from one another, I don't think so. We'll take a few posts here to review them one by one:
Program Management is generally considered a general category of practice or related practice areas. While sometimes software itself is referred to as programming, what programs are in our context is the coordination of people, organizations, technology and materials to achieve specific or well-defined goals. A program office may be responsible for one or more programs. An example of a real PMO that is charged to manage just one program is ELSG/EC. This office was created to support the Air Force’s Logistics ERP initiative, also known as the Expeditionary Combat Support System (ECSS). But even the EC has developed other related programs as issues have arisen, for example one dedicated to developing a legacy system migration strategy and another dedicated to developing a unified data architecture to support both Logistics or Finance ERP solutions.
Copyright 2008, Semantech Inc.
Saturday, March 1, 2008
Welcome to the PLM Blog
Hello and welcome to the Program Lifecycle Management – “PLM” Blog.
This Blog is dedicated to examining the concept, methodology and practice of PLM. Program Lifecycle Management is an innovative new approach to supporting the Enterprise Program Management Office (ePMO). While PLM was designed with IT projects in mind it is equally applicable to any other type of program office as well.
On this site we will provide presentations, case studies, tips and open discussion on issues related to this new field. Thanks for stopping by and we hope you enjoy your visits here…
This Blog is dedicated to examining the concept, methodology and practice of PLM. Program Lifecycle Management is an innovative new approach to supporting the Enterprise Program Management Office (ePMO). While PLM was designed with IT projects in mind it is equally applicable to any other type of program office as well.
On this site we will provide presentations, case studies, tips and open discussion on issues related to this new field. Thanks for stopping by and we hope you enjoy your visits here…
Subscribe to:
Posts (Atom)
Posts
