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.
Comments