Musings on personal and enterprise technology (of potential interest to professional technoids and others)

Wednesday, August 22, 2007

Nice PPM Summary by D. Entrekin: "Operations or Alterations?"

I especially like the acknowledgment of a "grey area", this is what I have heard called "stratactical" [combo of strategy and tactics, not purely 1 or the other]:

Operations or Alterations?:

"Some organizations have begun to split their portfolio into some fundamental dualistic categories. One such breakdown might be described as Operations versus Alterations. By Operations, we mean "keep the lights on" type work. By Alterations, we mean "change the business" type work. The notion here is that a two-pronged fork can inform the leadership team about how they are spending their resources in "stay the course" work versus "change the course" work.

I'd like to spend a minute on some implications of this split. First of all, from a very simple set theory standpoint, this split assumes that all work can be covered by those two categories. Let's take an IT department for example. Does all the work that IT performs fall into those two categories? How do we break down the work that needs to get done? If we break it down into change-the-course versus continue-the-course, then the first question to ask is, Does that leave anything out?

The easy answer is that we don't allow anything to be left out. We decide in advance that everything we are doing falls into one of those two buckets, and we force work into either one or the other. This forcing action in and of itself may prove to be useful.

A quick thought experiment might help. Some requests for work are clearly requests that alter the course, such as replacing our ERP. Some are clearly operational, such as a request to add new recipients to an existing report. But some requests are a bit more gray. Let's say that there is a request for new functionality in an existing system. You might call it an enhancement. You might call it a change request. Some folks might call it a system defect. And now we are already in a gray zone.

This small dilemma brings up one of the central issues in a portfolio approach to managing a project-driven organization. How do we evaluate requests for work in terms of their value? How do we compare their value to other work requests in the queue? How do we compare their value to work that is already being worked on? And finally, how do we make the tradeoffs?

In fact, once we have created the categories of stay-the-course and change-the-course, we have already created the decision-making framework for prioritizing and tradeoffs..."

No comments: