Sunday, January 18, 2015

Which PPFM Skills to Implement First: The Spaghetti Axiom

People get all wrapped around the axle about how to implement PPFM.  Most of the methodologies have very structured prescriptions for doing this, not only at different "levels of maturity" but also detailed steps within a level.

For the most part, reality doesn't work that way.

Implementing PPFM in an organization for the first time (or worse, for the nth time) requires culture change, and it is quite a substantial one.  That's true even if the organization has at least the required degree of maturity to begin contemplating such an effort in the first place.  See Kik Piney's not-so-comedic article on the Anti-Maturity Model.

Think of PPFM as a nice steaming bowl of yummy spaghetti with equally yummy sauce that will, if mishandled, make some spectacularly messy and probably permanent stains on your best business suit. Obviously it must be handled with care.

Given enough time yo could probably come up with an optimal way to eat this delicious mess.  The third strand from the middle is the one hanging everything up, if you can just get to that one ... your lunch companions are not going to wait for this sort of nonsense.  So you stick your fork in there, twiddle it, and get what you can.  It may not be ideal, but it works well enough to keep everyone satisfied and the bowl gets eaten in a reasonably timely and tidy manner.

PPFM is like that.  Because of the interconnectedness of the iron triangle, any positive traction on managing scope, schedule or cost is going to have an immediate effect on the other two legs, and likely will impact the other PM areas also.

Are we having difficulty getting people to define the scope of their projects?  Move on, move on!  Get them to agree to making a list of the projects and committing to some due dates.  As the due dates get loser, the project teams will suddenly develop intense interest in the meaning of "done", and in order to avoid such misunderstandings in future the PMO will be required to write down that X is all that was agreed to.

"Stupid PMO, why didn't they think of that before?  Making us look bad."  Stupid like a fox.  Now the PMO is "forced" to implement proactive status reporting, scope management, schedule management, and quality management.   All the things people said there was no way they were going to do that.  Keep applying the Spaghetti Axiom - don't try to force people to eat the whole bowl, just pick a few things that will be productive and accepted, and will have a lot of knock-on effects. Sooner or later, and much sooner than anyone would have thought possible, you'll be at maturity level 2 or 3.

The Spaghetti Axiom: eat it or wear it.

Sunday, January 11, 2015

Program management cannot mean just anything

Program management is a term used so much that it has taken on a wide range of meanings, which is to say that effectively it doesn't really mean anything. Oh dear.

Definitions are pretty boring and tend to invite the word-lawyers into the picture, but sometimes you just have to decide what the heck you are talking about. Otherwise your efforts to make improvements fall prey to arguments about who is right when in fact you are talking about totally different things.

So, what do I mean by program management?

Let's not agitate too much over the "management" part. The important part is that it means that the undertaking is too much for one person to overcome by brute force, or even by brilliance. Managers set the stage so that the elements within their system (and, principally, the people who are working on those elements) can succeed.

What about the "program" part?

PMI has expanded its definition over the years. The Project Management Body of Knowledge (PMBOK)(R) used to insist that a program was a collection of related projects, but could only be composed of projects, that is, no operational activities. That flew so obviously in the face of the experience of so many PM professionals that over the years the definition was expanded to include "some" operational component and eventually PMI published a Practice Standard for Program Management in which the operational-to-project mix was no longer relevant.

PMI's current (Dec 2014) definition is "A group of related projects, sub-programs and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually".

Well, yes. And of course "program management" is the "application of knowledge, skills, tools and techniques to a program to meet the program requirements and to obtain benefits not available from managing them individually". Well, it isn't wrong, but it does seem trite. It would be pretty hard for the average person to tell whether they are a program manger or not, given that definition. And so the debates begin.

And, before that starts, let's be clear that a program is not a portfolio, at least not in my musings - there's a separate post on portfolios. A portfolio is used for broad-based analysis, but it is not (usually) an actual decision process. Portfolio managers make recommendations (some may even have a veto), but it is the program managers who get to make decisions.

In the US Government the idea of programs has been around for along time, as have processes for managing them. The Defense Department's program management practices amount in essence to project management for very large projects. Although they are very complex, they do not begin until the "program" has been approved for funding and they end when the product reaches Full Operational Capability and can be handed off to the military services to conduct operations and support. (Yes, true, there are follow-on modifications and versions over a product life-cycle, and at that point one moves towards managing a program instead of a really large project, although I would contend that not having responsibility for support relieves the manager of such a product from one of the key responsibilities of a program manager, which is to balance the resources needed to sustain operations with those needed for innovation).

If you're part of the Washington sub-culture then you also know from the Programming, Planning, Budgeting and Execution System (PPBES) process that there are major programs and appropriated programs. On the other hand, companies talk about the Human Relations program. Schools talk about their sports programs. And the third grade music recital has a program. Are these all really the same thing?

Our musician son puts together musical events. A typical event consists of a variety of different contributions, with the genre and performers selected to balance different goals. The acts are not really dependent on one another, except to the extent that one must follow another in some sort of sequence. Why is this not a portfolio? First, because that industry doesn't think in those terms. But in any case, all of the acts do depend on the program manager to furnish some common infrastructure and some definitive guidance. He gets to decide who is in and who is not (while in some cases having to persuade people to get in). He provides the venue and makes sure that the logistics are adequate. He arranges for someone to collect the money, which is later shared along some formula that he has orchestrated among them.

Now one such event on its own is really a project, perhaps with several sub-projects needed to get all the pieces to fall into place. But there is also an ongoing capability beyond the execution of the immediate event: it will be back next year, hopefully. So there is are ongoing activities, such as fund-raising, venue planning, and a general (if limited) management and governance process. It's a program! So is a football program: it goes on well beyond one event or even one season, and it definitely goes on longer than the career expectancy of anyone involved with it.

The program creates the environment in which a capability is sustained: the environment and the necessary processes must be there before the projects have a beginning, and they are there after the projects come to an end. Sounds somewhat like the Book of Genesis. Well, in a way it is like that. Whether it is a massive appropriation of funds to a government agency, or dad or mom's paycheck that enable junior to acquire a means of transportation, there is a finite limit to the resources and there must be a means of balancing them between competing priorities. The program managers focuses less on the week-to-week outputs of the projects or the operational activities than on the long-term building and sustainment of a capability to do work. In doing so, the program manager focuses on what DOD likes to call "Big A" acquisition (little A meaning just contracting actions). "Big A" does include contracting, but also skill sets such as planning, budgeting, financial management, human resources management, facility planning etc.: all the skill sets required to make sure that resources are in place when the work needs to be done.

Seems pretty obvious. Yet it is surprising how few organizations actually do this. Enormous expenditures are made to implement project management, but over years and years not much difference is seen. Why? Because the environment has not been conditioned by program management to make project management successful. No matter how hard they try, project managers cannot seem to bring projects in on time, on budget, with the desired capabilities, because the leadership, planning, guidance and coordination are not in place. Projects are under-resourced to the point that they cannot accomplish their aims, or, just as bad, over-resourced to the point that they are bloated, lose sight of their original aim, and crowd out all the other work that could have been done. Deliveries from one project to another are defined only by trial and error. Staffing begins only after the project is underway, guided by the untrained personnel who were the only ones on hand at the time: go, go, go! Nobody really knows who is working on what, except that everyone is sure that nobody is working on the Top Ten list. If any of this sounds familiar - you need to focus on program management before your project managers can be successful.

One hardly ever hears of an organization saying "gee, what we need here is to institute program management". Much more common is to hear that it has symptoms of issues in multiple areas at the same time. It is quite impossible to to fix project management and financial accountability and resource prioritization and effective planning and, and, and, all at the same time. In such a situation - and they are more common than you might think - the organization needs to get its act together from the top down and start managing holistically. That will mean making progress in small enough increments that they can be digested, even though each step will not move the needle much on anybody's Maturity Model. Of course, our objective is not to get a good score on someone's model, it is to make a positive difference in our organization. Besides, real life is not quite like the regular-looking steps on most maturity models: it's more like a critical mass thing (The Spaghetti Axiom).

So what do I mean by program management?

Program management is a method of applying a multidisciplinary approach to establish, maintain, and improve a complex capability over an extensive period of time, by establishing the environment in which the program activities can be successful, by defining and approving solution components, and by coordinating smooth transitions between existing and emerging solutions repeatedly through the life of the program.

Please feel free to enrich this understanding with your comments!