Conformance & Expection Problems

Conformance problems consist of situations where system performance (process, inputs or outputs) does not match user expectations. In this context I refer to ‘system’ loosely as being any set of systems or organizational processes working in unison. I think that IT is perhaps the most problematic arena for dealing with conformance related issues. The reason for this is due to the tendency for user or sponsor expectations to become radically divergent from system capability or development outputs.

The critical factors surrounding why IT suffers more in this respect than other industry sectors includes but is not limited to:

• The pace of technological change
• The increasing level of complexity in IT solutions
• The increasing number of variables (or supporting data)
• The trend towards geographical distribution of workforce
• The expectations for interoperability across radically different segments of IT

The example that comes to mind immediately is the set of conformance disappointments and expectations surrounding Services Oriented Architecture (SOA). There are many aspects of SOA viewed as a facilitating mechanism for enterprise integration that simply haven’t been worked out yet by anyone, yet leadership in many organizations seem to think that the solutions are mature and are surprised that their SOA initiatives aren’t producing the anticipated results. Some of this can be attributed to the typical technology ‘Hype Cycle.’ However, more it has to do with the ability to exploit new capabilities in existing IT environments.

The way I address these situations is the same or at least very similar to most other efforts I support in IT. I view it as a problem-solving exercise, and as such try to first diagnose what went wrong and work forward from there. What we’ve discovered in these types of investigations regarding SOA is that the definitions of interoperability built into the standards and vendors stacks don’t yet map to the interoperability expectations of most complex enterprises. The question is whether to build the remaining bridge between those expectations in any one enterprise or wait for industry to bridge that gap.

Copyright 2008, Semantech Inc.

PLM Defined

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.

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.

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.

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.

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.

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.

Copyright 2008, Semantech Inc.

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.