Project Portfolio Management (PPM) Today

Blog Consolidation

In the fine tradition of process and data consolidation, I am narrowing my focus down to one blog, and the the community dialog is excellent - click here to read about PPM.

PPM without Automation?

With or without automation, there's plenty of process work that goes into setting up a Project Portfolio Management implementation. There are several key components required:

- End-to-end project life cycle
- Stage-gate project approval process
- Project methodologies
- Resource approval processes

The question then becomes, Can an organization pull off a PPM implementation without PPM software to support it? To provide a full and complete answer to that question, we would have to define what "pull off" implies and that would require more space that I'm prepared to use here. So for the moment, let's just jump in and explore what I will call the "Manual Approach."

To be sure, in the Manual Approach you can educate all stakeholders and team members on the bigger picture. You can define the swim-lane process for how projects get initiated, approved, planned, staffed, executed, etc. You can train all the players on how the various processes are supposed to be followed. You can define reporting standards and implement methodologies. And you can schedule the regular meetings that are required to move things along.

This work will help get the ball rolling. But the challenge of keeping the ball rolling in a Manual Approach becomes overwhelming. With a Manual Approach to PPM, key resources will spend hours and hours pulling together status reports. Managing the stage-gate approval process will become so onerous that it will not be followed. Creating a view of resource allocation will not accurately reflect what people are actually doing. All project reporting data is suspect. Earned value calculations, for example, are hard to trust in the Manual Approach.

In short, a Manual Approach to PPM will burden the leaders who are trying to implement the process and it will not scale. Furthermore, a Manual Approach will create so much overhead as to become a formidable barrier-to-success to the leadership team. There's no doubt that process is critical to success, but to realize the full benefits of Project Portfolio Management, organizations need a single system to maintain standards, establish visibility, produce reports, provide metrics, and enforce process work flows.

Without PPM automation, you may end up feeling like you're sweeping the ocean floor with a broom.

Revolution or Evolution

As Project Portfolio Management continues to gain momentum in all sectors of the economy, one question that continues to plague my thoughts is whether PPM represents a significant departure from traditional management techniques, or does it reflect an evolutionary step, a natural addition to traditional project management techniques?

This is perhaps too simple a dichotomy, and I have pointed out false dichotomies in the arguments of other writers. But still the question continues to stand unanswered. On the one hand, PPM builds on traditional project management techniques and so it is tempting to see PPM as evolutionary, a mere ratcheting up of a discipline. And yet on the other hand I continue to see traditional Project Management cultures struggle to get their arms around how PPM changes the entire notion of why a project exists and what it's supposed to accomplish.

One significant difference is transparency. Many project management driven cultures are fearful of transparency. They prefer the relative darkness of projects that are managed by legions of inscrutable gantt charts and spread sheets. Subjective assessments. Guesswork. They like the ability to manipulate the actual progress of any project or initiative though creative interpretation. This may also reflect the sense of power, however small, of being the Project Manager. The belief that they are at the helm and can steer the ship like a captain at sea.

Another major change comes in the form of project approval. Projects will no longer be initiated because someone decided on their own that it seemed like a fun thing to do. Project initiation and approval will become more standardized, just like the procurement-to-payment process. You can't just wing it.

But are the talents and values of the traditional Project Manager actually at risk in a PPM environment? Certainly they will be forced to align themselves with the organization with greater accountability. But are they somehow less valuable to the organization? Based on observed experience, I would argue that, in sum, they are in fact much more potent and thus much more valuable.

Another major departure from traditional project management arises as senior management has greater visibility and responsibility for the performance of the project portfolio. This appears to be a significant adjustment, and one of the reasons some PPM implementations stutter several times before they hit their stride. Conflicting agendas, uncertainty, new obligations, all of these changes confront the leadership team and they struggle to get on the same page.

But like it or not, PPM has arrived and it now appears inevitable. Visibility, transparency, accountability, measurement, these things are significant competitive advantages and those organizations that figure it out first get the proverbial brass ring. And so have I answered the question? Yes and no.

For my part, I see PPM as a transformational shift, and it will bring across whatever project management disciplines will continue to add value in the new model. It will also leave behind those that don't.

Portfolio Metrics

As a followup to my previous post on IT Toolbox, Measuring Health, I would like to explore the question of performance statistics in a bit more detail.

Now that we've been applying quantified measurements internally for a few weeks, we are starting to notice a few things:

1. When you pick a standard profile for quantifying performance metrics, you accelerate the notion of "working together" versus "working on your own." In other words, a performance standard applied across projects in a portfolio leads to a shared understanding of performance and health, rather than an individualistic approach. These are not "my projects" but rather they are "our projects."

2. Applying a scorecard to a portfolio of projects immediately forces everyone to make sure that the data is in fact accurate. If a project shows up as "red" then everyone associated with the project immediately wants to know why. Is it actually red? What is making it red? Is the data accurate? These are all good questions.

3. As anticipated, a color coded Health Indicator immediately trains the eyes on what needs attention. Once the project data has been updated and is accurate, then folks want to drill into what is "red." Next, they want to drill into what is "yellow." The good news is that the purpose of Health Indicators is to focus team members on what needs attention, to simplify the effort to evaluate "how we are doing."

4. There appears to be a desire to create personal/private health profiles, which at this point I would judge to be a bad idea. This is a natural desire to anticipate a visible poor score. My view as of now is that the performance measures that produce the scorecard (aka red-green-yellow indicators) must behave consistently or you have confusion. If something is green at one level, but red at a lower level because of different criteria, that will lead to inconsistent communication and misleading indicators.

5. There also appears to be a tendency to say "but I know it says that the task is red, but I know it's green." Well, this is exactly what a quantitative approach is intended to address. If we use quantified methods, the health of a project or task is what it is. If it's 25% late, then it's 25% late. If we agree to change the target date for any reason at all, we can make it green again, but at least we all saw the evidence of trouble and made a clear decision together.

Clearly, this is an important shift away from traditional project assessments, which tend to be subjective and murky. It may take some time to get used to such a clear picture of performance health, but it is inevitable.

Any other observations on experiences with quantified scorecards for projects, portfolios and tasks?

Portfolio Steering Committee

Project Portfolios require direction, and whether you have a formal process or an informal process, the shape and trajectory of the portfolio is driven by the steering committee.  The committee may have one person on it, or representatives from several departments.  It may have 3 members and it may have 30.  No matter how the committee is composed, it serves a purpose.  The questions are, What purpose should it serve? and How should it function?  This is where things get a little tricky.

The challenges appear immediately upon understanding one key fact: the steering committee is composed of human beings.  For those of us who like the predictability and consistency of machines or formulas, people present a peculiar challenge.  They are not predictable.  When you get several people together at the same time, the predictability worsens.  When you call them the members of a committee, things can get downright weird.  If you have diligently read your Kafka and your Orwell, you will at least have a literary sense of what I'm talking about.

In a Project Portfolio Management (PPM) context, one of the key aspects of managing the portfolio is the composition and role of the steering committee.  Who is on it?  What does it do?  What is its scope?  Does it make decisions or only recommendations?  If it doesn't make decisions, who does?  Who has the titular power?  Who has the real power?  Who knows what they're talking about?  Who just knows the acronyms?  Does the committee have access to the right information?  Are the members clear about their role?  Are they resumé stuffers or are they problem solvers?  The answers to these questions are not easy nor are they obvious.

But there is a role that precedes the steering committee.  That role is the role of the person (or the persons) who establish the committee.  Who are those folks and what are they trying to accomplish?  You see, that is where it starts - someone forms the committee.  I have written consistently over the years that the key to any technology solution is People, Process and Solution Design in that order.  You start with the key people, and usually their job requires picking the rest of the people. This is where the proverbial game is won or lost.

Which brings us back to the steering committee.  Let me give the term its proper formatting: the Steering Committee.  Someone, or some small team, will establish the Steering Committee and will create the rules, expectations, guidelines, etc.  At that point, everything changes.  Power and authority will have been given names and roles and a place-and-time to meet.  I certainly don't want to say that there is no going back, because there is, but I will say that the formation of the Steering Committee sets certain things in motion that are difficult to stop.

More on this to come...

The Project Concept

The concept of the "project" is so pervasive in our minds that we no longer understand what the term "project" actually means.  We use the term "project" for so many activities that there are almost no common boundaries to the definition.  The PMI has certainly tried to nail it down, but their efforts have been only marginally effective.

I've written about this topic before, but I want to return to it.  My intention is to breathe new life into the idea of a "project" so we can reclaim it and make it useful.  For now, let's take a fresh look at how the "project" operates in an IT context.

For starters, let's use the "project" concept to break down the work that IT workers do.  Just like a data modeler who decomposes entities into a powerful normal form, we must understand IT work.  At the highest level, all work in IT is either project-work or other-work.  If the work is project work, then the effort should be planned and accounted for as part of a program or initiative that contributes to the larger overall set of goals. That seems pretty straightforward on the face of it, but it doesn't tell much of a story.

Digging a bit deeper, you have different kinds of project work.  You have strategic projects, you have tactical projects, and you have maintenance projects.  You may also have bet-the-business projects. There are many different variations within these designations, but for the most part, this appears to be a meaningful breakdown for most IT departments. The projects themselves function as management vehicles to guide how IT will help move the organization forward.

This breakdown (Strategic, Tactical, Maintenance) begs some important questions: How many of each kind of project do we have?  How many should we have?  How are they all performing?  What's coming up next?  Where do we typically perform well?  Where do we fail?  What do we want to change?

The "project" concept gives us tools for allocating resources, coordinating schedules, managing investments and achieving the desired outcomes.  It also gives us a <i>shared</i> management discipline to work on, a <i>collective</i> skillset to develop, a technique to define and refine and improve.  The "project" concept gives us the framework for navigating from our Current State to our Desired State.  It helps us create the future. 

Turning our attention to the so called "other-work," what exactly does that include? Email? HR? Staff meetings? Education? Support?  When we dig deeper into the nature of "other-work" (non-project work), the picture gets murky quickly.  What is a project and what is not a project?  What are the benefits of managing other-work as a project?  Should employee education, for example, fit within a larger program for staff excellence relative to services rendered?  What work do we do simply because it's part of day-to-day operations?

For my part, I  argue that the more "other-work" we move in to "project-work," the better off we are for the simple reason that was stated above: "The projects themselves serve as management vehicles to guide how IT will help to move the organization forward."  Otherwise, how exactly do we know if the work we do makes any difference?

The challenge before us is perhaps this simple: we must revitalize our understanding of project-work and clarify our desire to "move the organization forward."  And when we must manage tens, hundreds, even thousands of concurrent projects, we encounter a whole new level of challenge and opportunity.  At the moment we realize how critical our portfolio of projects is to our overall mission, then Project Portfolio Management (PPM) becomes an unquestioned management necessity.

Characteristics of PPM Success

What are the characteristics of an organization that is ready for Project Portfolio Management (PPM)?  What are the traits that indicate a successful PPM implementation?

Visibility: Organizations that understand the value of transparency are well positioned to take on a PPM initiative.  If visibility causes anxiety and doubt, then the organization is less likely to embrace a PPM solution.

Standardization: An operating bias toward standarized process means that an organization no longer wants to re-invent the wheel with every project.  Standard process creates predictability of execution, and if it's done well standardization can even inspire creativity.  If you follow the hero approch to projects, you may not be a good candidate for PPM.

Process Improvement: When you can define the steps to accomplish a job in a repeatable way, you have a defined process.  PPM greatly enhances the ability to improve the Project Life-cycle process, which in turn enhances project outcomes.  Some organizations do not define their processes, making it hard to achieve repeatability and process improvement.

Measurement: Organizations that measure how they are performing will find a significant improvement in their ability to measure how they are doing.  The saying goes, if you can't measure it, you can't manage it.  If you can't see it, however, you can't measure it.  See Visibility & Process Improvement.

Accountability: In many ways, you've already partly achieved accountability with visibility.  Once you can see who owns what, you immediately have better accountability.  In the public sector, this term gets thrown around to the point of becoming meaningless.  If your organization wants to achieve greater accountability, PPM will provide several ways to do just that.  See Visibility and Measurement.

Focus: Organizations that want to focus their precious resources on high impact activities are well positioned for a PPM implementation.  You must be ready and willing to define your priorities and make trade-offs.  But if you want to get the most from your people and not burn them out, PPM will give you a framework for focus.

Change: The willingness and the ability to manage change is relevant to PPM for at least two reasons.  1. Establishing a PPM management framework will likely require some change management; 2. A PPM framework will significantly improve an organization's ability to manage change.

There are other characteristics that are indicators of PPM readiness.  There are also different ways to define the points outlined above.  It comes down to this: are you ready to manage your project investments like investments?  Are you ready?

Process Gumbo

The library of processes and approaches and "standards" for managing project portfolios is simply overwhelming.  Here is a brief list of the available process models that are used today.  I'm leaving a bunch out just to save space.

• •PMI – Project Management Body of Knowledge
• PLM – Product Lifecycle Management
• ALM – Application Lifecycle Management
• SDLC – Software Development Lifecycle
• ITIL – IT Infrastructure Library
• ITG – Information Technology Governance
• COBIT – Control Objectives for IT
• •PRINCE2 – Projects in Controlled Environments
• Six Sigma – Quality Control Methodology
• MAMA – Mixture of All Methods Above

How do we sort though these?  How do we know which one will work for us?  What is the right combination of various processes? 

My take is that all of this stuff has to get a hell of a lot simpler.  It needs to be easily understood by everyone.  When the process gurus require a translator, you have a problem before you start.

The Simplest Model

I think I may have finally figured out the simplest possible model for PPM:

 

All projects follow a flow that works something like this model.  Someone decides they need something.  The Need either gets approved and becomes a project or it does not get approved and it sits on the Need stack.  If it gets approved, then a project gets Executed.  Sounds simple, right?

Unfortunately, things start to get a bit more complex.  A few quick questions:

• How do we define the need?
• What are the criteria for approval?
• How do we know if it's a good idea?
• Who will approve it?
• Do we have the resources to do it?
• What will we choose not to do as a result?
• If we decide to do it, who will do it?
• What conflicts will happen as a result?
• Who will get overloaded?
• How do we monitor progress?
• Who is responsible for realization?
• How do we know if we hit the target?
• What happens if the goals change mid stream?

I could go on.  You get the picture.  But at least this is a starting point for agreement.  From here, we need to go a bit deeper into where this model begins to fall apart and why

Wikipedia Definition

I took the opportunity to create a definition of Project Portfolio Management on Wikipedia.  I was somewhat surprised that there was no definition for PPM there already, but I was pleased to see how easy it was to create one.

Dis-intermediation continues to build more and more momentum.  We appear to be moving steadily toward a collective approach to developing knowledge and understanding.  We don't need to wait for the traditional powers-that-be to arbitrate what to discuss and how to discuss it.

If you want to take a crack at my definition, have at it: Project Portfolio Management.