How is the PMBOK like Wikipedia?

When you are stuck in traffic, you have free time — just kidding — for random thoughts to bubble up into your conscious mind. On one such occasion, I found myself considering the similarities between the construction of articles on Wikipedia and PMI’s Guide to the Project Management Body of Knowledge (PMBoK).

At first, these two entities may not seem to have much in common, but bear with me. A wiki is a Web site developed collaboratively by a community of users, allowing any user to add and edit content. The best-known wiki is Wikipedia, formally launched on 15 January 2001 by Jimmy Wales and Larry Sanger, using concepts pioneered by Ward Cunningham. The idea behind a wiki was to create an information repository where anyone — hopefully with domain expertise — could add topic content, which could in turn be edited or commented on by others. The result of the collaborative input should provide useful and valid content on a wide range of topics. Today, Wikipedia has over four million articles.  And Wikipedia is also has an administration and governance model for administration, oversight and management of the content.

Wikis are not limited to Wikipedia. Projects use wiki tools to build a reservoir of project documents and facilitate collaboration among project staff, especially when they work in separate locations. The Twiki Workspace project, for example, provides a set of tools to manage projects, facilitate collaboration, and maintain project documents, forms and policies as well as supporting social networking on the project. The core software can be downloaded using open sources and the tools are available for purchase in bundles for 5 users or 25 users.

So, what does this have to do with PMBOK?

From its beginnings in 1981 when the PMI Board of Directors approved the development of a book detailing procedures and concepts necessary to support the profession of project management, the effort was a “collaboration”. Twenty-five volunteers from local PMI chapters wrote the sections of the report. Review and comment on the evolving standards was solicited from organization membership through a series of circulated working drafts and workshops. The process to reach “A Guide to the Project Management Book of Knowledge” took several years. I wonder if they could have finished more quickly if they had had a wiki.

So the bottom line is – many executives who think the PMI PMBOK is a standard for Project Management do not realize that it is just a book of best practices that is put together by a group of PMs.  Remember that when you are implementing your processes on your project – you always need to apply the right processes to the type of project you are managing!

The Importance of Project Planning – PMBOK Chapter 3

OK, it has been a while since I talked about the PMBOK and I wanted to continue a series of posts on PMI PMBOK areas (started with “What is the PMBOK all about”.  This week we look at one of the critical areas that many PMs shortchange in managing projects – planning

“No battle plan survives contact with the enemy” is a bit of wisdom about the world alternately attributed to Helmuth von Moltke the Elder, Erwin Rommel, Carl von Clausewitz, Colin Powell and Murphy’s Laws of War. Yet, military leaders continue to develop plans for every imaginable contingency. If plans are destined to fail in the real world, why should we as project managers bother with planning?

Plans rarely fail entirely. Rather, details of a plan require changes as factors outside the control of the PM require responses that deviate from the original plan. However, a project plan provides a roadmap of key destinations (milestones) and a timeline to reach those locations, even when detours become necessary.

Of course, the PMBOK addresses project planning in detail beginning in Section 3.4. It suggests that a project plan encompass:

  • Scope
  • Activities
  • Resources
  • Schedule
  • Quality assurance
  • Risk analysis

In the discussion, PMBOK acknowledges that, “as more information is gathered and understood – which is their way of saying contact with the enemy — additional planning may be required.”

Types of Plans
Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

  • Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
  • Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
  • Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan
Here are a few tips to help you make a better project plan:

  • Cover all the bases listed in PMBOK
  • Clearly defines the scope of the project
  • Show dependencies between tasks as part of risk management
  • Comprehend resource loading and realistic levels of effort
  • Reflect awareness of project risks and allow time to understand and mitigate them
  • Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
  • Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
  • Help developers, team leaders and users understand the project and their role in its success
  • Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)
The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site