One of my colleagues used to explain to me that there are three kinds of people that attend any meeting:
- There are those who feel an emotional need to share how they’re feeling about the topic.
- There are those who need a specific list of assigned tasks to come out of the meeting.
- And lastly, there are those people who don’t feel the meeting is complete until they’ve walked up to the white board and drawn a couple of circles and squares and have put an intellectual framework around the topic at hand.
This post is for the latter group. It comes out of some recent discussions I’ve had where we’ve stepped back and taken a more macro view of the current enterprise work management system. In fact, the diagrams below grew out of a couple of doodles I ended up drawing in my notes after a recent discussion.
Before going much further, let’s borrow a couple of terms from the ITIL lexicon. Love it or hate it, at least it does provide us with some commonly accepted terminology. The first day of ITIL training usually begins with the definition of these two terms (from the official ITIL glossary):
- Function: A team or group of people and the tools they use to carry out one or more Processes or Activities.
- Process: A structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs.
I’ll add my own term to this:
- Work Types– A specific type of work that shares a common lifecycle and set of processes. (Yes, I know it kind of sounds like PMI’s definition of a portfolio, but since a work portfolio comprises multiple work types, I figured this would be less confusing. In technical terms, think Enterprise Project Types.)
So we’ve got functions that utilize multiple processes. Hence one of the goals of process definition is to define the outputs required to support the functions. At the enterprise level, we’re talking about the outputs required from local processes to support enterprise functions – such as resource management and allocation.
So far so good, but how does that apply to the EPM context? Typically, you take the project lifecycle, break it down into processes, and then map the output of the processes to the required functions. Most often, those outputs take the form of reports on process data.
Applying this to the enterprise as a whole, here’s a simple three(ish) step process to perform analysis on an existing or nascent PPM system*:
- Identify the inventory of work types within the system.
- Identify the processes required to support each work type.
- Identify the required enterprise functions to support governance.
- Map the outputs of the processes to the required inputs of the enterprise functions.
At the end, it should look something like this – with each line representing an organizational control process, data flow, or report.
…and since the data all needs to be pulled from the processes, this can be turned around as input into the process design to ensure that the appropriate control points have been inserted into the process to ensure the function has what it needs to, well, function.
*Not to be confused with my patented 3 step process to implement portfolio management tools:
- Identify all of the work in the organization.
- Identify the total work capacity of the organization.
- Identify how the organization makes decisions and codify this into a set of automated rules.
See, it’s actually quite easy to implement PPM tools…