Project Portfolio Management (PPM) Today

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.