So I finished my first foray into learning the PMBoK approach to project management and have some more observations.  There’s a lot of detail in the PMBoK method:  4 phases of the life cycle (CDEF), 9 knowledge areas, 5 process groups, 42 distinct processes, 6 constraints.  It’s very complex and, to my simple mind, cumbersome. I prefer simplicity (who doesn’t?).

It seems to me that one way to simplify this beast is to think in terms of three major outputs or documents from the whole process:

1. Project Charter
2. Project Management Plan(s)
3. Project Closure Report

The Project Charter is, of course, the linchpin for the entire process. It defines the overall scope and justification for the project as well as the key players. It is sort of the Declaration of Independence for a project– “we hold these truths….” Without a solid Project Charter, the project will go no where.

Once a Project Charter has been developed and endorsed, all of the project effort is focused on the Project Management Plan (PMP).  First the PMP must be conceived and developed, activities that entail a lot of smaller tasks and processes. Depending on the nature and scope of the project, developing the PMP could be easy and of short duration or difficult involving lots of time and effort. Likewise the initial PMP could be short and simple or long and complex. But like the U.S. Constitution, the PMP provides detail and framework based on the Project Charter and it is subject to amendment and modification as the project proceeds.  When an initial PMP is ready, execution of its contents is conducted with “progressive elaboration.”  That execution ultimately leads to the project’s closure– whether it is successful or not.

Finally, once the project is completed (terminated), a Project Closure Report should be prepared that provides a summary of the project: successes and failures, outcomes achieved, outstanding issues, lessons learned, identified best practices.

It seems that the PMBoK method provides lots of detail on those major pieces of a project, but at heart I think that the Project Charter, the Project Management Plan, and the Project Closure Report represent the foundational structure of successful projects.

As I’ve been learning about project management, specifically the PMBoK approach, I keep thinking that it seems to describe what in the software world we call the “waterfall method” of software development.

There are lots of examples of the limitations or outright failures of projects following the waterfall method. And there is a healthy group of developers who have adopted alternative approaches such as “agile programming.”

So is there an PMBoK equivalent for agile project management?  One starting point is http://www.versionone.com/agile-project-management/.

Project management as structured through PMBoK is fairly complex. It involves four phases (concept, develop, execute, finish– CDEF); nine knowledge areas (integration, scope, time, cost, quality, human resources, procurement, communication, risk); forty-two processes broken into five process groups (initiating, planning, executing, monitoring and controlling, closing). Then for each of the 42 processes, detailed  inputs, tools & techniques, and outputs are defined.

Might it be possible to simplify all of that to something like this:

• Four phases and process groups
  • Concept (Discovery)
  • Develop (Plan, Blueprint)
  • Execute (Build, Test, Monitor)
  • Finish (Deploy, Implement)
• Six knowledge areas
  • Integration
  • Scope
  • Resources (including human resources, procurement, finances, time)
  • Communication
  • Risk
  • Quality

As I dig into formal project management and the whole PMBoK realm, there are several initial perspectives that have my attention.  First, it seems to me that the whole process is overly complex which makes it hard to easily grasp and follow.  More on that later.  Second, it seems that under PMBoK the very first task of a project is the creation of the Project Charter. I wonder if there aren’t some earlier steps that are necessary to, lead up to, and inform the Charter.

To my mind, a project’s genesis involves identifying the primary sponsor and top-level stakeholders.  This, of course, is usually a self-identification process– someone in a position of some authority identifies an itch they want scratched.  This sponsor group identifies the purpose of the project– what the project would do and accomplish.  To start, this purpose description is probably general in nature and will definitely get refined as the process advances. There will then need to be some description or understanding of the scope and resources for the project.  Another pre-charter element is a sense of who the stakeholders are and how project success will be identified.

Those preliminary steps are clearly a part of the concept phase of a project, but deserve recognition and attention in the formal project management cycle.  They are necessary to determining if the possible project is feasible and if the formal process should begin.