PLM & Semantics Part 3 - Requirements Taxonomies

One of the most obvious and easiest ways to see how Semantics or Semantic Integration drives Program Lifecycle Management (PLM) is through Requirements Management or Engineering and the development of taxonomies. It is often more likely that you will be faced with immediate project support tasks than a more global enterprise definition effort (either as part of a data standardization, COI or MDM initiative).

Every project though must have some level of requirements vetting in order to satisfy expectations for potential return on investment or affordability. These types of efforts are generally manual although some folks use models to help with cost estimation. At some point though, the high level or functional Requirements and Work Breakdown Structure (WBS) must be defined in order to set up project schedules.

With PLM, we can tackle this by developing a Semantic blueprint or foundation. The way I've approached this before is to use preliminary visualization tool (mind map or concept) to illustrate the functional requirements and the relationships between them. I then designate that as a Domain Taxonomy (or ontology depending on how detailed the relationship information is). The Domain Taxonomy then represents the pool of available terms groups and sub-groups with which to build logically relevant WBS segments. Then I build requirements taxonomy within my automation environment and extract the WBS from it. Thus I have elements of EA design, semantic correlation and project coordination all wrapped up within one activity. This makes it possible to track from:

• Strategy to EA
• EA to Functional Requirements (the 1st level or elementary taxonomy)
  
• Functional Requirements to WBS (abstraction of 1st level taxonomy)
  
• WBS to Technical Requirements (the 2nd level or detailed taxonomy)
• Technical Requirements (precise) to Project Schedules (schedule & detailed requirements taxonomy should map nearly one to one)
  
• Project Schedules to Roadmaps & What if Alternatives
• and everything back to Strategy
  

Understanding functional requirements implies domain knowledge, both in terms of domain entities and relationships.

Copyright 2008, Semantech Inc.

PLM & Semantics - Part 2: Ontologies

What are Ontologies and What do they have to do with Program Management? Well, they are the hidden 'maps' that link together all aspects of process, data and system architecture. An Ontology in our context, refers to characterization of conceptual hierarchies and their relationships within the enterprise. ITIL for example is an Ontology.

An Ontology fits within a spectrum of terms used to define various levels within a Semantic framework. Many people consider the Ontology or a Shared Upper Level Ontology to represent the pinnacle of Semantic constructs, however this is not the case. As we have experienced in many enterprises 'forced to integrate,' many Ontologies from diverse communities often come together in "Sets."




The Semantic Hierarchy or "Spectrum" - Most of us don't realize when we're viewing these...

So, what can organizing our information within these "spectra" do for us as managers? The 1st thing it will do is to abstract your program information from the systems and sources where it currently resides. This is a much bigger issue than it seems - if your framework for running a complex enterprise is dependent on a set of unreconciled COTs tools and MS Office documents, it is hardly likely that your enterprise can ever be truly run through unified Lifecycle Management approach. The Semantic layer that you develop serves as a foundation for both solution design and oversight thereby unifying them from the start. This is a powerful bit of synergy.

In the Department of Defense, many programs have used something referred to as a Community of Interest (COI) for the last few years to help define the data paradigms behind each "functional" area of their programs. At first, these were viewed more like traditional data standardization efforts but increasingly they are being managed using Semantic technologies and integrated with Enterprise Architecture initiatives.



This example illustrates how various taxonomies are typically mapped together in an EA -like analysis.


Copyright 2008, Semantech Inc.

Program Lifecycle Management (PLM) & Semantics, part 1

We have discussed at some length that Program Lifecycle Management (PLM) is empowered by the ability to merge or otherwise integrate all program related data within a single instance database built atop a single schema that reflects the full spectrum of business processes present in most PMOs. It is important however to make a distinction between the technical implementation of such a solution and the underlying architecture premise. In this case, the true power of PLM is not in any one proprietary database but rather in the ability to define and merge the management of IT within a fluid, evolutionary set of definitions. This is semantics; semantics not as an arbitrary concept referring to the validation of symbolic meaning, but semantics as a facilitating technological medium, allowing for correlation between processes, data sets and application logic – all modifiable without development by end users.

In many ways, the notion of PLM is dependent upon Semantics and PLM can be considered one of a new family of practices that are “Semantically enabled” or empowered.” The amount of value inherent in these practices will become even more apparent as the amount or level of support for semantic interoperability increases. As PLM platforms extend feature-sets to include RDF and OWL transfer as well as visual mapping of taxonomies or Ontologies, the integration of program management with the projects entrusted to it will begin to occur in earnest for the first time. This includes and extends to enterprise architecture as well (including complex application design). Some PLM platforms already support UML Use Cases which can be used to help derive requirements taxonomies, project schedules test plans and so forth. There is also an initial level of integration occurring between PLM and EA tools. I see the eventual relationship as being a dependent one, i.e. the use of EA will be viewed as most relevant within the context of program oversight and management, thus EA artifacts or products will become part of a variety of PLM processes and made available through the PLM interfaces to all participations and stakeholders related within the context of an enterprise program (or programs).

I’ll try to provide a real-world example of what all of this means. Starting two years ago, I began evaluating a variety of requirements management and EA platforms to assess how well they might support a project of the scale say of the ECSS program. ECSS is the USAF’s logistics modernization effort and consists of a migration from several legacy systems to an Oracle ERP platform. Based on my previous experience as an AF IL (Logistics) PMO Chief Engineer, I estimated that there were perhaps several thousand ‘modernized’ or consolidated requirements to deal with and as many as 50,000 legacy requirements that still needed to managed and / or reconciled.

I focused on one product, Accept 360, because it had the most flexible database and web architecture, but soon noticed that was an interesting and unexpected capability in the tool. The software allowed me the opportunity to change all of the core definitions of various application modules within it as well other definitions, labels and data properties. I soon found that I was able to take an application that was developed for the commercial market and tailor it completed to a federal PMO. It also allowed me to adapt development lifecycles for the requirements by defining those lifecycles in the tool. None of this required development or scripting. I soon realized that many of the mostly costly aspects of systems I had previously managed was the relative inability for non-developers to make simple changes like this. Simple, yet in some cases sweeping changes in the significance for how the tools might be used.

Part 2 of this discussion will cover how PLM functions a semantic practice and part 3 will discuss how other PLM applications can become more “semantically enabled.”

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.

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:

• 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

Because of these and other related issues, PMOs are the places charged with supporting or conducting risk management or risk assurance processes. These processes though are only as effective as the data which support them. Risk Management is one of the sub-processes supported by the PLM “meta-process,” the idea being that all risks are related to tangible requirements and all requirements are then related to projects, programs and portfolios. So, PLM is both an enabling technology as well as a way to help place issues in their proper context within the larger enterprise picture. Given its focus, there could be potentially significant liability issues associated with PLM as a solution.

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.

Copyright 2008, Semantech Inc.

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.

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.

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:

• 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.

PLM Overview presentation

This following presentation serves as our introduction to the topic:

| View | Upload your own

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…