The PPPM Roadmap: What is a Deliverable-Centered PM?

By PH Lohnes, PMP

While many project managers (PM) know that a project has deliverables, many do not understand their importance and central preeminence. Deliverables are the only reason for a project to be chartered or brought into existence. Without deliverables, there is no project – it is that simple.

Therefore, since project deliverables are the reason for projects in the first place, how is it that some project teams do not know what are the deliverables of the project to which they are assigned? The PM is the lead on each project, and he/she must demand that every team member know definitely what the deliverables are that will direct their time and effort on the project. The first action taken when a project is in trouble, and a project whisperer is called in, should be to discover and understand the project’s deliverables. In many cases, the team members and even the PM cannot articulate the deliverables and their “fit-for-use” performance metrics.

While this may sound somewhat odd, many of us at the Post-Gazette have experienced this precise condition when being called in to support a troubled or soon-to-be troubled project. So getting back to the point of the article, what is a deliverables-centered PM? And what are these “fit-for-use” metrics or performance measurements so often bespoken of at the Post-Gazette?

The first question needs to give way to the second since understanding what “fit-for-use” means is just as important as knowing what your deliverables are for each project. So, “fit-for-use” is the condition or status of the project deliverables whereupon the customer, client, or business sponsor is willing to sign off on the completion of the project’s activities as having produced the deliverables of value to their (the customer, client, or sponsor) business purposes. In other words, “fit-for-use” deliverables are outcomes that can be immediately and purposefully put to valuable utilization in the satisfaction of the project’s business case.

What this means in clear and concise words is that “fit-for-use” deliverables are:

  1. Defined by the customer, client, or business sponsor,
  2. The purpose for which the project is instantiated, and
  3. The business baseline against which the project is compared and measured for success.

Therefore, if you have not already figured it out, the definition of “fit-for-use” deliverables is the specification of quality to which the project outcomes must adhere! “Fit-for-use” is the precise definition of project deliverable quality – nothing more, and nothing less.

While this flies in the face of all the Six Sigma, Lean, and other types of very complex quality definitions and machinations, for a project, this definition of quality is all there needs to be. The customer who pays for the project’s budget defines what they are expecting, at what status of completion, and the value or “fit-for-use” condition which will meet their needs. This should make perfect sense in that if the project is on-time, and on-budget, but fails to produce “fit-for-use” deliverables, it is a failed project while going over-budget, or behind schedule is problematic, but producing “fit-for-use” deliverables could, I say could, render the project a success in the eyes of the only person that matters – the customer.

So what does it mean to be a Deliverables-Centered PM? This question should begin to make sense now that the concept of “fit-for-use” deliverables has been conquered. A Deliverables-Centered PM is one that ensures every action, activity or task is one that moves the project closer to the production of the defined “fit-for-use” deliverables as specified by the customer.

This produces a very stark and rigid code, but one that can mean the difference between just managing an unrelated stream of activities and tasks day after day, and truly understanding the purpose for each action that you take as a PM is for the sole purpose of increasing the probability towards producing deliverables accepted to the customer.

To be specific, every artifact or action from the WBS work packages, to the plans, to the tasks, activities, meetings, reports, audits, gateway reviews, schedules, executions, monitoring, and remediation is undertaken purposefully towards the production of “fit-for-use” deliverables. Each planning item has to therefore be tied back to a specifically identified project deliverable: each WBS work package, each risk, issue, each requirement, each task, each control action, everything and this means EVERYTHING must be tied back to a specific deliverable for the entire life cycle of the project.

Deliverable-Centered Project Management (DCPM) is not just a nice sounding idea or concept, it is a powerful project management philosophy or mindset as we call it at the Post-Gazette and MCLMG. We created this concept when many of our potential clients were floundering in a sea of poor project successes floating on the raft of over-detailed MS Project schedules without even having the map of a sound WBS. This sounds like a cliché, but it is so true for so many project executing firms and government agencies. The current liturgy of the project management discipline has become so complex, so convoluted, so over-governed, and weighed down with increasing regulations and processes, that the simple truth of project management has gotten lost, which is:

The sole purpose of any project, and that means any project regardless of size or complexity, is the production of “fit-for-use” deliverables within the time, cost, quality, and risk constraints of the instantiated project.

Anything beyond the production of such outcomes is truly off-point or “out-of-scope” as it is called in the project management world. For example, while the use of earned value management (EVM) concepts has all the right intentions, if it detracts from the production of “fit-for-use” deliverables then its use is counterproductive to the success of the project. Nothing is as sacred in project management as the production of the project’s deliverables. Nothing!

While this article may appear at first to be a tirade against the current project management status quo, nothing could be closer to the truth. It is! The rank and file project managers need to take back their profession and discipline, reduce the complexity imposed by self-aggrandizing so-called standards bodies both in the US and European Union, and return to the basics of sound project management whereby the deliverables are the only important focus and measurement yardstick for project success.

Just because an organization produces a series of books called standards, or produces a program of minimum knowledge certification, it cannot be granted the sole purveyor of a discipline’s body of knowledge. There is no such thing as “best practices,” only “your practices” that should be based on experienced successful production of “fit-for-use” deliverables.

Moving back to the basics of simple project management will reduce your stress, increase your success rates, and make life more enjoyable as a project manager. Come back in May and June when we at the Project Post-Gazette really stir up the pot with discussions on why the project management discipline is in need of life support and resuscitation.

The PPPM Roadmap: The Insanity Continues

By PH Lohnes, PMP

Before I move into my column this month, I must clarify an issue that landed me in hot water with some readers of last month’s topic. When I said that the best candidate to be a portfolio manager is a member of the Senior Leadership Team (SLT), I did not mean to imply that this was their own duty. The chosen member of the SLT could in fact delegate most of the actual portfolio effort to a working manager. However, I stand by the need to ensure the portfolio manager, director, chair (use your own title) is both privy to and a participant of the enterprise strategic landscape design. Without this connection, well, read this month’s front page for the consequences of such lack of strategic awareness for the portfolio manager.

Onward now. After spending over three years working as a project, program, and portfolio manager/consultant in support of a research endeavor at over 7 government agencies, 3 healthcare companies, and for 5 small-medium government contractors, I have come to the conclusion that the project management state of the practice is disoriented and in chaos. I say this only because over the past 20 years the number of certified project managers has increased by well over 100 times (4,000 to over 400,000) while the project success rates have not shown any material improvement with the small exception of Agile-type projects in the IT world.

What could be the cause of this disconnect? Here is my story, and it is only mine. I do not blame anyone or any institution – they are doing what they think is best to protect their own turf or philosophies. However, I bring up Albert Einstein’s definition of insanity:

“Doing the same thing over and over, but expecting different results.”

By this definition, the current state of project management is decidedly crazy. We are continuing to do the same things over and over, but expecting that somehow the results will be marginally different. I point to the fact that next version of what is called the industry project management body of knowledge by its creators is fundamentally the same as the previous versions especially in the risk discipline. Project management is not the same as it was 20 years ago or even 5 years ago. We need to be dynamic and adaptive; flexible and applicable.

Therefore, what in the current state of the practice is limiting our profession from achieving the results that our employers, clients, or customers desire?

Simply, we have become stifled in a liturgy of project management processes that look good on paper, but do not work in the real world. The profession is more interested in protecting its brand than protecting the best interests of those that procure its services. With a comparison to history, the project management profession is at the same point in time as the Western religions were at the beginning of the Reformation – processes are more important than production, form is more important than function, and ostentatiousness than outcomes.

The practice of project management is professionally bankrupt! Those of us that see this need to begin the steps of retaking the profession from those that have put us into this “process limiting” perspective, and rebuild it along the lines that provide value for our employers and clients. We need to show value for our mostly very expensive services – not continued low project success rates.

From the early 1990’s until now, there has been a 100 fold increase in the number of certified project managers just from the PMI – not counting the other PM organizations overseas. If the value of the certification was correlated to the success ratios of project completions, one would expect the ratios to have taken a significant increase over these past two decades. This is far from the reality as has been shown in several studies of project success ratios from the Standish Group, Computerworld, InfoWorld, and authors: Martin Cobb, Kirk Kirksey, Bob Lewis, Thomas Hoffman, Julia King, and many others.

Consequently, if the large increase in certified project managers has not advantaged the project success ratios, the problem must lie elsewhere. In some blogs, the fault is levied at the increase in project complexities, lack of senior management support, lack of defined goals, requirements, etc. However, it would seem that most likely culprit is the methods, processes, and perspectives in use over the past two decades. What I am speaking about is the industry best practices or bodies of knowledge in use. These components of project management are largely unchanged from the 1950’s – 1960’s where they were born of the construction industry. One notable exception is the advent of the Agile methodology in use for the development of software applications.

I maintain that the project management profession MUST come to grips that it is not serving its customers, stakeholders, or clients by continuing to demand wages in the low six figures, but not delivering business value for those high compensatory pay-outs. The US Government has already begun the process of altering their perception of what a project manager is by defining, creating, and instituting their own project management certification program: the FAC-P/PM (Federal Acquisition Certification for Program and Project Managers) from the OFPP (Office of Federal Procurement Policy).

The policy letter of April 25, 2007 states that “the certification shall be accepted by, at a minimum, all civilian agencies as evidence that an employee meets core training and experience requirement for general program and project management.” This should have rocked the PMI and APM to its core; however, nothing appears to have been done about this lack of acceptance of the commercial certifications by the US Government. We are seemingly going quietly into the good night. Sooner or later, the industry must come back from the over complication of its practices towards the concept that in project management it is all about the deliverables – pure and simple – the production of “fit-for-use” deliverables.




The PPPM Roadmap: Linking it Together

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

Having the roadmap details behind us, we now have to put the final piece into the jigsaw to crystallize the entire concept. In this post we will discuss the interrelationships between the PPPM vision, the goals, direction, roadmap, and outcomes. Let’s first start with the organizational prerequisites. These are the conditions that I have discovered are conducive to the benefits a vibrant PPPM environment can provide to a project management organization. These prerequisites are:

  • A Senior Leadership Team (SLT) willing to discuss a PPPM vision, if not already in place,
  • The designation of a member of the SLT as the portfolio manager,
  • Willingness to apply organizational resources to the creation of a PPPM environment, and finally,
  • A SLT member as the champion of the PPPM effort (not the same as the portfolio manager)

An organization lacking these prerequisites are less likely to be successful in their establishment of a PPPM environment, so the first step would be to determine if your organization has these conditions in place ready to support the PPPM establishment. Save yourself a significant level of frustration and wasted energy by postponing your PPPM activities until these conditions are mostly in place. You can assist with the creation of these conditions, but unless you are one of the very senior SLT members, you might not have the authority to condition your organization for this path.

With the assumption that you have the prerequisites in place, it is time to setup a regular, periodic time to meet with both the PPPM champion and potential portfolio manager for the purpose of establishing your organization’s PPPM vision. This vision needs to specifically define the PPPM To-Be conditions that the PPPM roadmap will implement. These vision statements will define the environment as it will exist once the PPPM roadmap has been completed. You will be describing the desired landscape your organizational project management discipline will take as the roadmap activities are scheduled and accomplished.

With the vision statements defined, and approved by the entire SLT, the next step is to begin the development of the PPPM roadmap. This involves all of the details discussed in the previous postings on the roadmap components so you have your work cut out for you and your organization. If you have any questions or comments, please feel free to contact me here at

Good luck, and while it may appear to be long and complex, the benefits are worth the effort.


The PPPM Roadmap Components: Goals

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

This will be a short post about the importance of setting the right goals for each of the PPPM roadmap periods which you have designed to implement your PPPM vision. First there is a concept going around that goals should be SMART, SMARTER or something similar. If you are not familiar with the acronym SMART, I would suggest that you look it up on the Wikipedia web site. However, be careful, while the definitions of the acronyms is defined correctly, the web site posting is confused and does exactly what was discussed in a previous post about mixing up the differences between goals and objectives. The web site begins speaking about setting SMART objectives and then in a subsequent paragraph it fluidly begins discussing SMART goals as if goals and objectives are the same thing.

As we know, goals and objectives are different in their makeup and application, and thus posses different levels of these characteristics. While it appears that the SMART characteristics can apply to both, the application of these is best applied towards goals and not objectives. The reasoning behind this is that goals are horizons and thus need to be specific, measurable, attainable, relevant (I use the term realistic), and timely. Objectives must, by their very nature of being the “how to obtain a goal,” are already SMART since one cannot express the how of an accomplishment without many of these characteristics. It is the definition of SMART goals that alludes many organizations.

There are other “googlized” searches on goals and objectives where many say that goals cannot be measured or are not to be specific. Goals need to be SMART or they are of little value. Many times I have had to discuss this point with the Senior Leadership Team (SLT) members of my clients when I find their goals to be such trivia such as:

  • We want to the best in category,
  • We want to beat our competition,
  • We want to increase market share,
  • We want to be more profitable,
  • We want to have more clients,
  • We want……

you get the picture. These goals are simply mush and fluff. Goal setting by those that are successful are specific. For example, setting a goal to be in Vienna, Austria is not mushy or fluff. It is very specific, it can be measured since one would know if they are in Vienna or not. It is attainable, realistic, and by the setting of a time frame, can be timely. So please excuse the mush that passes for knowledge on the Internet sites, and think about the value of setting SMART goals versus the mushy and fluffy ones you have probably seen being passed off as viable goals.

Without goals for each period of the PPPM roadmap, the PPPM vision has very little chance of being successfully implemented. It is the goals of each period that when paired with the period’s other components that breaks the overall vision into obtainable “chucks of action.” Each period’s goals should be also compared in one other characteristic: compatibility. The goals of each period must provide a link from one to the other and without being compatible, this is not possible.

We have finally completed the entire discussion of the PPPM roadmap components for implementing your organization’s PPPM vision. We will “gift wrap” the concepts in the next post by detailing all the linkages between the roadmap components.

The PPPM Roadmap Components: Direction

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

The direction component of a PPPM roadmap period is the heading that the organizational’s Senior Leadership Team (SLT) takes in order to implement the period’s objectives and therefore the goals of the PPPM vision. The linkage between a period’s objectives and goals is that the objectives are the how of the roadmap’s implementations while the goals are the what. Many people confuse goals and objectives and often use them in the same phrase with many believing that they are the same. Let’s look at an example to clarify their differences.

Using our current example, in the first PPPM roadmap period (Period A – first 6 months time frame) the goal maybe the measurable condition of improving financial budgeting to the point of meeting the defined budget point within +10%, and -15% range. Remember, goals are the horizon while objectives are the manner in which we achieve that condition of horizon. In this example, the goal of improving the financial budget targeting is supported by the objectives of process improvement, principal training, and performance tracking via newly implemented software applications. We will discuss this important topic in a later post.

So with the difference of goals and objectives in hand, what is the direction component? A direction with respect to a goal and objective is the overall direction in which the goal is to be obtained. For our example, to achieve the goal of improved financial budgeting practice, an organization could either do it internally with existing staff and processes, or by having an external contractor such as a Big Five Accounting Firm come on-board to implement our goal of improving our budgetary obtainment. How we move forward to our goal given our direction will alter the objectives, achievements, and implementations. All are interlinked — almost to a level of becoming a Gordian knot.

When advising my clients on these concepts, I use the following flow of actions:

First goals are defined for the period as they are part of the larger PPPM vision. From the goals the direction can be chosen for which the objectives, achievements, and finally the implementations quickly follow suit from the goals and direction. To keep this all organized and clear, you might want to use the analogy of a journey. The goal is condition of being in Vienna, Austria. The direction would be the choice of taking the Eurorail system as opposed to driving ourselves or having someone drive us. The objectives would how we use the Eurorail system to achieve our condition of being in Vienna. Do we travel during the day, or use the overnight trains and sleep on the train? Do we get off at stops for sightseeing, or do we have a timetable or schedule to keep? The achievements would be the obtainment of the desired outcomes of arriving in Vienna at a certain time at a certain place using the train system given our implementation constraints of time, budget, and even risk.

Hopefully this post will assist in understanding these components of each roadmap’s period, and what you will need to define for that period in order to implement the PPPM vision.

The PPPM Roadmap Components: Achievements

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

While the implementations or tools are the physical realities utilized in each period, they differ from the achievements since the implementations are not production or development of the period while the achievements are. Think of the achievements as the deliverables that each period will produce on the path towards completing the PPPM roadmap and ultimately the PPPM vision.

For any project, the most important component is the deliverables for which the project has contracted to produce at the quality level defined by the customer of the project. Quality, defined for projects, is the production of deliverables at a level of “fit-for-use” completion. While I know that there are many that will disagree with this definition, and would then take three pages in which to define quality; be aware, that the increasing complexity surrounding quality in project deliverables is one of the issues I have discovered as a major issue in project failure. Team members, key stakeholders, and even the customers are having a more difficult time in defining and understanding just what quality means. A later post will delve into this definition of project quality.

Thus with quality understood and as it should be applied to project deliverables, the achievements of a PPPM roadmap period are those outcomes that the period must produce within the quality defined by customers or key stakeholders of the PPPM roadmap — the senior leadership team (SLT). The SLT must adequately define each period’s achievements and the necessary quality metrics which will define the “fit-for-use” condition of the produced deliverables.

For our example, the achievements for this first period (first 6 months) of the PPPM roadmap could be the following:

  • An ideation development, vetting, and prioritization process,
  • A KPI definition and alignment process for use with project justification activities

While these are examples of process deliverables, they could just have easily have been software tools, applications, or training activities. The achievements are different than the tools or implementations used during the PPPM period. Tools are used to assist with the production of the period achievements. An example would be the difference between the woodworking tools such as a bandsaw or router and the cabinet the tools help a carpenter to produce under the contract and quality defined by the customer.

Achievements for any period of the PPPM roadmap must be aligned with the overall PPPM vision in that the achievements when taken together in totality will produce the goals of the PPPM vision as produced through the PPPM roadmap. Again, another bit of linkage between the PPPM components.

The direction of each period will be the final component discussed.

The PPPM Roadmap Components: Implementations

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

The components easiest to understand and activate are the period’s implementations. Implementations are usually the physical manifestations that support the accomplishment of the other components. Later in this post, I will use our example to show how each period’s implementations provide a physical foundation for the focus, direction, and training components already discussed.

Implementations can take the form of software applications, processes, procedures, or even new methodologies aimed at achieving the roadmap’s current period components. These physical representations or solutions parallel the direction the PPPM vision used to help define the roadmap initially for without implementations the roadmap becomes so much talk and cerebral activity — no substance or form.

In our example from previous posts, the PPPM vision and roadmap is mainly oriented towards implementing the portfolio-level portion of the PPPM environment as projects and programs have already been articulated over the past 7 years. The period’s focus is the towards the implementation of KPIs and PPPM processes using a top-down approach.

The implementations for this period would take the shape of applications or processes supporting the use of ideation for new projects focused on the key performance indicators (KPI), or processes at the portfolio level to prioritize investments towards the defined KPIs. Linking the implementations to the period’s focus and direction is key to keeping the progress of the roadmap sound and significant. Without implementations on which to hang physical reality, an organization’s PPPM vision can become simply another management apparition that come and go without leaving a trace of value.

These implementations link the components of focus, discipline, training, and direction with physical manifestations towards the production of the period’s achievements — the topic for our next post. The focus of the period along with the management direction shows the need for particular disciplines to be enforced using training as leverage for producing appropriate achievements. This is the linkage of the components for each period.

Implementations are also very useful in the training component since they provide a more “hands-on” anchor for education as opposed to just having seminars for discussion of thoughts or ideas.

Our next post will cover the PPPM roadmap component of achievements — the production of the desired outcomes from implementations we just discussed. Achievements could be seen as the deliverables of the period’s activities.

The PPPM Roadmap Components: Training

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

Dealing with discipline was a large hurdle especially if you have found that you are working for an organization that does not enforce discipline. When asked about what one can do in such a situation, I gave the only answer I have given over the years — find another organization! While this may be drastic in nature, unless one is a member of the Senior Leadership Team (SLT) it is very difficult if not nigh impossible to deploy discipline as a management priority. You will save more time and much of your emotional well-being by simply realizing that your current association is not going to see the value of discipline or they would have done it before now.

The PPPM component of discussion in this post is a simple one, one that we can handle after the previous post’s more arduous journey: training. While I say simple, training is none the less important in order to provide the educational and understanding foundation on which the entire PPPM vision and roadmap will rest. Project managers are not taught PPPM principles of any value in either their formal education or during their path towards certification. It is not a context that many find of value to teach beginning project managers. So we will discuss it here.

Training is necessary at all levels of the organization regardless of title or position — a fact that is lost on many in the SLT. Many believe that once you are a member of that rarified team (the C* team), you know everything or else you would not be in those positions. This is a very debilitating position and often leads to ignorant or worse, weak SLT members. The venue of training must fit the audiences’ time and demeanor meaning that training for the SLT team cannot take the form of full day seminars, but must be done in smaller bits and pieces. My favorite training for senior types is the “brown bag lunch” type seminar where the STL members are able to interact in a setting that does not resemble a training session which might have dissuaded some of the team from attending.

The content of the training should match the components of that period’s PPPM roadmap. The training sessions should be short and offered at the same time each week or every other week. There should be exercises, case studies, and group discussions. If you have full teams attending, providing group exercises would be very appropriate for roadmap contexts as well as supporting team building. A seasoned facilitator familiar with the needed learning objectives should be utilized to constitute the most benefits from the events.

Finally, the training should be recorded for use in later time periods and different audiences in addition to being digitally archived for access via internal data nets. Also, the training attendance and completion should be maintained in personnel records for reporting and tracking efforts.

In the next post, the PPPM component of implementations will be detailed and placed in context with the other components.

The PPPM Roadmap Components: Discipline

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

I have taken a bit more time to prepare this post since it involves an area that I have seen contribute to  most of the problems in project management — enforcing or enacting professional discipline (PD).

What do I mean by professional discipline (PD)?

PD is the enforcement of organizational policies, rules, regulations, processes, procedures and activities (PD standards) that implement the PPPM vision and mandate. Now this may sound like high school recriminations, but when organizational management does not hold its project management staff to PD standards than the entire project management environment suffers.

Working as a portfolio consultant at a client recently (no, I am no going to give away anything that will identify the client or industry), I wrote, spoke, emailed, discussed, and even did a little begging in an attempt to get the senior project management team and even the SLT to understand that enforcing PD was paramount if they wanted to correct the current set of problems they were experiencing with their PPPM implementation. They looked at me as if I was asking them beat their employees — not just hold them accountable to do their jobs.

In one very perplexing case, I was told that we were to put out reports with “bad or missing” data as this would show the users of the reports how their lack of data input discipline (a large part of PD) was evident in the poor quality of the report. The SLT member that told me that this would cause them to improve their data discipline and over time the reports would be more useful!!! After picking my jaw off the floor, I mentioned that I had to respectfully disagree with him — always a dangerous position for a consultant to take. I stood my ground, but was overruled.

My guess is that this now ex-client’s poor reports will continue long into the future without cure or remediation. One of the issues that I have found plaguing many organizations from the US Government, healthcare, defense, intelligence, manufacturing, retail, education to small-to-medium (SMB) businesses is the lack of the SLT members to enforce appropriate PD! Project managers seem to think that they can get by with just “talking” their team members into compliance — it “don’t” (sic) work that way, folks!!

Enforcing PD is a component of the PPPM roadmap as much as the component of focus, training, and the setting of goals and objectives. It is the primary function of management to enforce standards and compliancy. It is the nature of the employee to resist. Why? Simple inertia! A body stays at rest unless acted upon by an external force. This is a physical world axiom and it is true in the management world. The SLT members must enforce their PD standards for without which the rest of the PPPM roadmap components will have little foundational support.

Next post will deal with the next PPPM component: implementations. Continue to develop your own PPPM vision and roadmap as we work through these issues.

The PPPM Roadmap Components: Focus

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

When developing the PPPM roadmap from your PPPM vision, the aggressiveness of your implementation or the roadmap time frame will need to be settled with your Senior Leadership Team (SLT). Understand that being overly temporally aggressive may impact your organization to the point of the roadmap not being supported by those you will need. Implementing a PPPM vision through a roadmap will be viewed by many as “extra-curricular” work — taking resources from normal operations or projects. The time frame must match with both your organizational strategic goals and available resources.

Once the time frame is decided upon, dividing the time frame into manageable periods will then require that you define components for each of the periods. The first roadmap component is that of FOCUS:

Focus is the concept of fixation on one’s direction towards a defined horizon. In business or project management, focus is the totem against which activities, decisions, and events are matched to ensure the period’s outcomes are met. Focus keeps one from veering off-track or from “bird-dogging” into areas not aligned with the period’s defined goals.

An example might assist with your understanding of these concepts. For the example, you are part of an organization tasked with provided a series of software applications stemming from user interfaces to customer database operations. You have several large clients in a single industry that all use the same basic applications with a bit of customization for each client. The organization has been doing project management for 7 years, and just implemented a program management environment about 2 years ago in order to achieve a level of efficiency in your project management activities. One of the SLT members recently attended one of my portfolio management seminars and is now sensitive towards implementing a full PPPM solution in your organization.

The following parameters have been decided upon by the SLT:

  • PPPM vision implementation time frame is for 2 years using 4 – 6 month periods
  • The PPPM vision is to have a closed-system implemented from the top-down perspective – meaning the PPPM environment will manage from the general to the specific or portfolio to project level.
  • The portfolio manager will be the Chief Financial Officer (CFO)

With this scenario in place, we can now begin to discuss the components defined in each period that when taken in their totality will implement the PPPM roadmap from the organization’s PPPM vision. Keep these associations in mind: the PPPM vision and its time frame segmented into the desired number of periods over which the roadmap will be promulgated.

For each of the four periods, Period A through D, the components must be defined beginning with the focus for each of the periods. The focus series could be as follows:

  1. Period A focus: Key Performance Indicators (KPI) development, PPPM organizational structure, processes
  2. Period B focus: PPPM performance metrics definition and gathering
  3. Period C focus: Configuration management, investment ideation, and termination processes
  4. Period D focus: Completion of a closed-loop PPPM solution including tooling and training

These are only examples that an organization under the above conditions might define as each period’s focus. You can now begin with your exercise.