Category Archives: Project Management

Small pieces (yaks) (very) loosely joined

My concept of the value and power of the internet rests largely on the idea that it is basically many small pieces loosely joined. That idea embraces the use of small, single-purpose widgets that can stand alone, which makes it easy to build and test the widgets. Then it combines them by being joined, but they are loosely joined– there are not lots of dependencies on other included pieces.

The joining makes the overall result very robust and powerful. The small pieces make it very flexible and easy to manage.

That works for the internet itself, and works very well.

But we seem to have major difficulty making the same model work for other systems. I used to think it was just me and my own limited skills at programming and system design. (The “pieces+joined” is almost the antithesis of “system design” but that’s another story….)

And then I came across this gem on today’s O’Reilly’s “Four Short Links.”  Jeffries’ experience struck me as my life on a pretty much daily basis.

So why does the internet work but when Jeffries– or poor slobs like me– try to work with the same model, we end up neck deep in yaks?  I don’t have a ready answer for that but one possibility that immediately comes to mind is the use of standards.  The internet, and it’s child the web, work because there are clearly articulated and enforced standards that you have to follow, else your application won’t work.

But the likes of Google App Engine and python (substitute your favorite environment tools here), don’t follow the same clear articulation of standards.  Depending on what gib repository you use or what options you use when installing python and it’s many libraries or your own development structure, using someone else’s sample code may or may not work right.  You are just as likely to end up with a room full of yaks as a working tool.

Just an early morning thought dump…


Ever trying to simplify processes and ideas, I have a new notion of how projects/life/evolution flows– kind of a “process of everything.” Four simple stages:

  1. Start
  2. Plan
  3. Act
  4. Stop

The Plan and Act stages are recursive.

Project Management Summary

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.

PMBoK = Waterfall?

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


Simplify 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