2003 has been an interesting year for me personally as well as professionally. I’ve come to understand better the market forces that drive project and program management – mostly that process and formality have little business value if the customer doesn’t care about such things. Only by delivering on the project can the we get the customers attention.
As well I’ve moved to what I would consider a broader view of project and program management and away from the “definitionist” based discussion of how many angels can dance on the head of a pin.
I’ve participated in several internal workshops on project management, spent long hours discussing the intricacies of project accounting methods, portfolio management tools and government contracting reporting processes. I can honestly say I now know more than I ever wanted to know about the management of fixed price incentive based IT contracts.
All this brings me to the position of reassessing the role of project and program management. This role moves from “managing projects” to “delivering projects” and “satisfying clients.”
Project Delivery versus Project Management
This “delivery” strategy goes beyond the planning and execution processes described in the typical project life cycle. The current PMBOK 2004 draft lays out a typical project life cycle in Chapter 2. “Projects are divided into phases to provide better management control… Collectively these phases are known as the project life cycle.” There are Five Process Groups in the PMBOK 2004:
| Initiating | Planning | Executing | Monitoring and Controlling |
Closing |
This set of processes seems to leave out some critical activities. The most important is the inclusion of the customer or client explicitly in the process. The “client satisfaction” based process groups could be:
| Plan Project During Procurement |
Charter the Team |
Plan the Work (in writing) |
Get Plan Endorsed |
Perform the Work and Manage Change |
Close the Project |
In the software development world many of the activities that occur in the first table are included in the “Perform the Work and Manage Change” activities in the second table. The motivation for putting emphasis on the software management activities external to the actual managing of the project includes:
Figure 3-3 in §3.2 of PMBOK 2004 Draft shows a picture of a high level project process group’s data flow. A critically missing piece – at least for managing software projects – is the continuous customer interaction. The PMI view of a project is process centric rather than customer centric.
Managing projects for “satisfying customers,” has been my epiphany this year (even though the epiphany doesn’t occur untilJanuary 6th). The underling process are interesting and are likely necessary, but they are far from sufficient to successfully deliver software development projects to real clients. This may not be the case in other disciplines, but certainly in software development , client satisfaction is the only true measure of project success.
PMI’s plan-driven, linearly structured, command-and-control process seems out of touch with the current software project management research and practice. Maybe this is the role of PMI, to maintain the old while others break their pick on the new.
What’s Next in 2004?
My role in the Program Management Office is changing. My staff is taking more responsibility in managing the daily activities of delivering software to paying customers. I’m spending more time “getting new business.” In the Department of Energy, “get new business” has many interesting twists. First the “customer” can’t be sold much of anything. They buy products and services from qualified suppliers. The customer controls all the levers. A fond memory from a Non-Profit law class in MBA school was that government contracting is about negotiating with a sovereign. It’s not about negotiating with a peer.
Since most of the Top 100 federal prime contractors are in the IT business, one approach to differentiating ourselves is through superior project and program management. Since IT services is pretty much a commodity these days – check out the outsource agreement IBM Global Services announced in mid December. Creating an “unfair competitive advantage,” is our goal. This will be done through the Program Management Office, Balanced Scorecard, Earned Value Management, project management tools, agile development processes, and finally team based development processes.
2004 will be a telling year for us, since our closure project ends in December of 2005. We’ll be on our way to other work long before then, so finding, winning, and executing new federal business will be critical to our team and larger company.
Project and Program Management processes will be a component of this success. I write about those successes as well as are tribulations along the way.
For those interested in the role of the PM in an agile software development environment. Here's a recent study done by DCAS.