The PMBOK Is A Menu…Not An End-to-End Process


I’ll never forget the training class I took to begin my preparations to pass the PMP exam (can it be eleven years already?!)  The instructor was a burly man, whose experience with project management included the NASA space program, two high-rise construction projects in downtown Chicago, and a massive, cross-country data center move for a Fortune 10 organization, among other “trivial” project work.  He walked to the front, empty table in the hotel conference room and dropped a copy of the 3rd Edition of “A Guide to the Project Management Body of Knowledge,” better known as the PMBOK Guide, down on the table.  After a long pause, he said the following in a loud, booming voice that needed no amplification, “This…is a copy of the PMBOK Guide, which, collectively, contains everything you need to know to successfully manage a project and pass the PMP exam.  If you take the initiative to follow it from end-to-end, your project will be a complete and utter…….FAILURE!”

You can imagine the thoughts running through our heads.  Most of us had managed projects before.  Most had heard of the PMBOK, and some had even consulted it for best practices prior to the training.  I know that my assumption of the PMBOK at the time was that it was THE guide, from beginning to end, for managing projects.  Little did I know that I was both right, and wrong!

As we spent the next few days walking through the project management framework, life cycle, process groups and knowledge areas, it became clear that the PMBOK was really a massive “menu” of tools, techniques, processes and exercises to leverage during the course of the project.  There is a life cycle, yes, and a logical flow from initiation to closing.  But within each project phase, process group and knowledge area there are upwards of thirty different tools, techniques, exercises, meetings, document artifacts and other suggested activities or deliverables.  Multiply that times five phase/process groups and nine knowledge areas and you can see the sheer magnitude of available systems.  Quite honestly, you couldn’t possibly implement each and every artifact contained within the Guide and still manage to deliver the project on time or budget.  Purists will scoff…but they know I’m right.

Does every project need a Histogram?  Or a Stakeholder Power/Interest Grid?  What about a Quantitative Probability Distribution chart?  Every project needs a Requirements Traceability Matrix right?  You consciously decide among Analogous or Parametric estimating on every project, don’t you?  Really?  Be honest, you’ve never even heard of at least one of those artifacts or tools have you?

The Project Management Life Cycle is a tried and true, end-to-end process that, more often than not, results in a successful project outcome.  The PMBOK expounds upon that life cycle by providing proven, best practice tools, processes, techniques and other systems to either effectively and efficiently move the project forward or deal with special issues that arise during the initiative.  In essence, the PMBOK is a massive menu.  It contains thousands, maybe millions, of unique combinations to lead, manage and deliver a project-based work effort.

Some organizations dictate that a certain number of artifacts be required to assure proper project management protocol is followed.  For example, each project must produce at least a Charter, a requirements document, a budget worksheet, a task list, etc.  Beyond those minimum requirements, the Project Manager is free to choose the tools and techniques contained either in the PMBOK, or based on professional experience, needed to manage that specific project.  Some projects will need a formal issues log, some can be handled less formally.  Some projects will need a full work breakdown structure to identify and organize the work, while others can be set up with a simple task list.  By definition, each project is unique.  The method to manage each project should be just as unique.

There are also some organizations that require junior Project Managers to follow more prescriptive processes and leverage a longer list of tools/techniques both to boost the odds for success and to expose the resources available to them.  More senior Project Managers are given further latitude regarding what is, or is not, required for each work effort.  The best Project Managers have developed their own list of artifacts and systems that are “required” by them, and then add to that list as each situation arises.

The key point to remember is that the PMBOK is a menu, and *NOT* and end-to-end process map.  Lean on it to provide you with guidance and options.  Keep what you need or works and toss the rest.  Each project is a “Build-Your-Own” management effort.  Your project management rigor should resemble a modern freeway.  The centerline is the ideal path.  The ditches and guide rails are the limits of how far you can stray.  Apply just enough discipline, including the resources available in the PMBOK, to keep the car on the road!

Answering Project Stakeholder Questions



As a project manager, one of the most important skills you need to master is effective communication.  Being able to communicate with a wide range of people, using their own sub-language (IT-ese, Finance-ese, Engineer-ese, etc), is critical during the entire course of a project initiative.  Perhaps one of the most important groups you will interact with frequently as you traverse the various project phases are the key stakeholders, without whom you wouldn’t have the funding or resources necessary to execute on your effort.  Stakeholders will have many questions during the lifecycle of the project and it is your primary responsibility to be in a position to answer those questions.

During my almost two decades of managing project, programs and portfolios, I’ve amassed a set of critical questions that come up (or should be asked) during the course of almost every project.  To help you think about and prepare honest, accurate and coherent responses as they related to your project, I’m giving you some advanced warning on what to expect.

If you can answer all of these questions during the project effort, you’ll have demonstrated that you are an effective, efficient and trust-worthy project manager:

Stakeholder Questions At Project Planning Launch:

  1. What do we want to accomplish?
  2. What…specifically…are we delivering at the end of this effort?  (What does “Done” look like?…thx Glen Alleman! @galleman)
  3. Who will take responsibility for what we are delivering once this effort is over?
  4. What are the key deliverables that we need to accomplish to reach our end goal?
  5. Who do we need to help us define and sequence the tasks needed to meet those key deliverables?
  6. Who do we need to complete the tasks needed to meet those key deliverables?
  7. How much time do we need to meet those key deliverables?
  8. How much money do we need to meet those key deliverables?
  9. What are the risks we can anticipate that might keep us from meeting those key deliverables?
  10. How will we react to the aforementioned risks if they occur?

Stakeholder Questions At Project Execution Launch:

  1. What are we tracking to know we are on schedule?
  2. What are we tracking to know we are on budget?
  3. What are we tracking to know we are making progress on completing our key deliverables?
  4. How will we identify risks and/or issues?
  5. What will be our responses to the previously identified risks and/or issues?
  6. Who else needs to know the answers to these questions and what is their preferred communication channel?
  7. Do we have the appropriate amount of resources (human, budget, space, etc) necessary to execute the estimated work effort?
  8. Do we have the appropriate amount of leadership commitment and oversight to ensure a quality project delivery?
  9. Does our effort have any dependencies or conflicts with any other efforts currently being conducted within the organization?
  10. Have we identified any other “part-time” or transient resources required for project delivery?

Stakeholder Questions At Regularly Scheduled Project Status Meetings:

  1. Are we on schedule?
  2. Are we on budget?
  3. Are we making progress on completing our key deliverables?
  4. Are we confident the key deliverables meet our quality standards?
  5. Are there any risks and/or issues that have come up since the last time we met?
  6. What is our response to the risks and/or issues?
  7. Do we still have enough time, money and resources to complete our key deliverables?
  8. Are there any changes required to ensure we have enough time, money and resources to complete our key deliverables?
  9. Is there any opportunity to speed up the schedule, reduce cost, free-up resources or deliver additional tasks without negative impact?
  10. Are the right people being informed of our progress and status?

Stakeholder Questions at Project Closure:

  1. Did we accomplish what we promised at the beginning of the project, plus or minus any changes handled via the approved change management process?
  2. Did we successfully complete the key deliverables promised at the beginning of the project?
  3. Did the person tasked with the responsibility for receiving of work product agree to accept the deliverables without the need for additional effort, time, money or other resources?
  4. Did we deliver our effort on time (within acceptable variance)?
  5. Did we deliver our effort on budget (within acceptable variance)?
  6. Were the deliverables of acceptable quality?
  7. Were there any significant risks and/or issues that caused us stray outside the acceptable variance limits set for the effort?
  8. Were the right people communicated with regarding the completion of the effort and the results?
  9. Have the resources (human, remaining budget, space, etc.) been released for other use?
  10. What are the lessons learned from this effort that may benefit future project teams?

Be proactive.  If these questions don’t come up, ask them yourself.  Remember, stakeholders come in all different levels of project management maturity.  Those new to the concept will appreciate your guidance and coaching on what is important to ask and consider when moving through the methodology.  This is in no way a complete list.  Each individual project will have unique questions that arise and need to be understood and addressed.  But what’s listed above represents a solid foundation of project management specific questions that, when answered, will give the key stakeholders of your project confidence that the person managing their effort (ahem…you!) is skilled, competent and fully capable of managing the work.


What Ever Happened to the Concept of Contingency Planning?


I love attending status meetings where a Project Manager has to explain why his or her project went from Green to Red.  Yes, you read that correctly…Green to RED!  Whoa!  Something really serious must have happened to go from “everything is right on the line” to “full stop!”  Discussion usually ensues about how everything on the project was going along swimmingly until suddenly, a piece of technical hardware that was supposed to ship last Tuesday won’t ship until a month from Tuesday.  And, since every task on the project schedule is on the critical path, there’s no way to recover from this event so the project is going to be delivered late unless drastic measures, like cutting scope or pushing out the date, are immediately executed.

This is where I shake my head and wonder…what ever happened the concept of project contingency planning?  Why are projects being scheduled so tightly?  Why do project budgets have no reserve funding for unexpected events?  Don’t they teach this stuff anymore?

So what is project contingency planning?  A contingency plan is a risk management tool devised to account for an outcome that is other than the usual or expected plan.  In project management, typical contingency planning efforts revolve around a couple of concepts, Schedule Slack (or Float) and Financial Reserve Funds.

Schedule Slack is the amount of time that a task can slip before it affects another task or the project’s finish date.  There are actually two different types of slack:

  • Free slack, or how much a task can slip before it delays another task; and
  • Total slack, or how much a task can slip before it delays the entire project

Many projects have natural slack within their schedule based on the way the tasks and sequencing fall according to the work breakdown, resource availability, product delivery lags, etc.  In order to find that slack, you’ll need to know how to develop a task network diagram, identify the critical path of your project and identify non-critical task chains.  The Project Management Body of Knowledge (PMBOK) or many online resources can help you map that diagram if you are unfamiliar with the concept.

Smart project managers, however, build a small amount of artificial slack into their schedules.  Nothing ridiculous obviously, but spacing some tasks out a few days here and a week there allows the PM with some maneuverability and options if and when issues or risks pop up that will affect the overall schedule.  Be very careful with this approach so that resources are not unnecessarily sitting idle just to build in a bit of float for your schedule.  Depending on the size of the project, I’ll typically build in at least one segment of float within each phase of the project and then collapse the schedule if I don’t actually need the time.  Being up front and openly communicating this approach with stakeholders and team members is a must!

Financial Reserves are funds set aside for a “rainy day” that may occur on the project.  These also come in a couple of different types:

  • Contingency Reserve, which is an amount of money set aside in the event that identified and quantifiable risks are encountered during the course of the project.  The Project Manager will typically have the authority over this reserve and will include it within the overall project budgetary accounts.
  • Management Reserve, or money that is set aside by the project sponsors or leadership team as an insurance policy against the “unknowns” that may arise during the project.  The Project Manager does not have authority over these funds and, if needed, must request them from the project leadership team.  These funds are may or may not be included within the overall project budget.

Let’s be honest, there are many project managers and stakeholder teams that “round up” the amount of CapEx (Capital Expenses) and OpEx (Operational Expenses) needed for a project.  Building in a just a bit of extra budget, up to five percent or so, is a sensible, and sometimes responsible, action depending on the uncertainty of the overall costs.  The financial reserve funds referenced above, however, are NOT project budget “padding.”  They are designed to cover known risks or unknown environmental factors.  Some project leadership teams expect a certain amount of scope change during the project and use the Management Reserve to fund these changes.  Best practice dictates that accessing any of these reserved funds must follow strict change management protocol.

Effective use of contingency planning in project management allows the Project Manager with more palatable options beyond the reactionary approaches of crashing the schedule (adding more resources to tasks so they finish sooner) or fast-tracking (running tasks previously scheduled in sequence to be run in parallel).  Some projects may never need the extra calendar time or the additional funds needed to get across the finish line.  Honestly, I’d much rather facilitate a project closing meeting with the Project Sponsor where I was giving back money set aside for a rainy day and/or ending the project a bit early by collapsing the available slack, than going, hat-in-hand, begging for more money or time based on having the project go from Green to Red!

Ten Things Walt Disney Taught Me About Project Management


Often times, the study of project management concept and practice concentrates primarily on the academic, filled with complex charts, graphs, formulas, and page after page of bibliographic reference.  What if, instead, the focus was on the most simplistic definition of a project?  Better yet, what if that definition was one a dreamer like Walt Disney could wrap his creative mind around?  At its heart, a project is a new or unique undertaking, which meets a business need, is temporary in nature, and is structured in such a way as to ensure delivery of the goal within the targeted time, budget and quality constraints.  Put even more simply by Walt Disney himself, “If we can dream it, we can do it.”


“When we consider a project, we really study it…not just the surface idea, but everything about it.  And when we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right…and we work hard to do the best possible job.” – Walt Disney

Lesson One: Pay fantastic attention to detail. 

Any project, as defined above, can not and should not be managed as a whole.  It is the sum of many small details across many distinct process groups.  Keeping track of these details makes the difference between a well managed project and a project managed by reactionary efforts.  Tracking the details, anticipating issues, responding to risk, and keeping watch over a myriad of other seemingly non-connective tasks are what keeps your project moving forward.  Don’t get too bogged down in the weeds with your team however, as your main role is to keep one eye on the end goal and keep the project moving in that direction.  Always know where your project is today, where its going tomorrow and what challenges your team is facing so you can effortlessly communicate these facts to key stakeholders.


“I happen to be an inquisitive guy and when I see things I don’t like, I start thinking, ‘Why do they have to be like this and how can I improve them?’” – Walt Disney

Lesson Two: Challenge the status quo.

How a project manager responds to issues and risk can make the difference between an “out of control” project and a project “within control limits.”  One of the major steps of the project management maturity model is recognizing and avoiding past mistakes.  When we ignore our project success/failure history, we are sadly doomed to repeat it.  Leading change within a project is occasionally necessary to correct inconsistencies, errors, omissions, and/or responses to new issues.  Project management methodology isn’t a “one size fits all” approach and existing business processes may not exactly mesh with what your project is expected to deliver.  Based on this, you’ll need to determine exceptions to both project management protocol and normal business operations.  Challenging the status quo and pushing the boundaries of accepted norms are occasionally required of a Project Manager to get the job done.


“I want a guest to walk into a five million dollar restaurant to buy a five cent hamburger.” – Walt Disney

Lesson Three: Don’t forget about the quality.

Project quality is tantamount to a successful deliverable.  Now, I will admit that the quote above seems a little extreme.  Walt Disney was trying to set the scene for a quality and enjoyable experience within his Disneyland theme park.  You likely wouldn’t want to set this lofty of a quality goal, but you must, as a Project Manager, ensure that every single deliverable of the project meets quality goals and expectations.  The Project Manager walks a very narrow tightrope here.  Exceeding expectations can bring claims of gold-plating, while cutting quality to meet budget, schedule or scope constraints can lead to very unhappy stakeholders.


“It’s kind of fun to do the impossible.” – Walt Disney

Lesson Four: People expect you to fail…prove them wrong. 

Based on the oft-quoted Standish CHAOS report of project success rates (or lack thereof), it is easy to see how some people, including your own project team members and stakeholders, can be skeptical of your ability to successfully deliver a project within budget, time and scope parameters.  Fair or not, the Project Manager is expected to re-direct accolades of project success back toward the team, while on the flip side, accept full accountability when the project fails to deliver on its promises.  How you manage the effort, including the team you are given, the communications you provide, the expectations you set and/or manage and the direct guidance you provide as you lead through issues, risks, milestone checkpoints and delivery acceptance are under your control.  Make informed decisions and direct rather react.


“You can design and create and build the most wonderful place in the world, but it takes people to make the dream a reality.” – Walt Disney

Lesson Five: Team members make the project a success, not the project manager. 

Putting together a top-notch project team is an essential ingredient to the success of a project.  Over time, project managers have put together teams of technical or subject matter genius, only to discover that these geniuses don’t always play well together.  Ensuring a proper blend of subject matter expertise and a good team dynamic can turn a sluggish project into a streamlined project.  By planning the team structure carefully, before the project is launched, future risk is reduced.  Publicizing reward and recognition programs to promote “above and beyond” effort before the project even begins promotes positive attitudes and fair leadership right from the start.  Equally important, having a plan already in place for correcting and/or negating the impact on the project of poor work or a discouraged and stressed out team saves valuable risk response time for other issues that may arise later during the project.


“The way to get started is to quit talking and begin doing.” – Walt Disney

Lesson Six: Make meetings more productive.

Project planning meetings, project status meetings, informal project discussions, and the dreaded elevator meeting.  For all of these forms of project communication, preparation and planning are key.  When project team members are sitting in a status meeting, they are not working on tasks needed to reach the next milestone.  Keep this in mind when you prepare your meeting agendas and participant lists.  Does the project team really need to sit through a recap of the tasks closed in the last thirty days?  Probably not, since they are the one’s who closed them!  An effective use of project resource time however, is a half-day workshop early in the project to define key project milestones, streams of work, tasks and time estimates.  Always ask yourself why a meeting is better than other forms of communication.


“Disneyland will never be completed.  It will continue to grow as long as there is imagination left in the world.” – Walt Disney

           Lesson Seven: Promote and champion change. 

As a project manager, you are, by default, an instrument of change.  Projects do not occur in a vacuum.  Projects are usually created to fix or improve something in the organization and they have stakeholders who are always either positively or negatively affected by the result of the project you are managing.  Simply starting a project can shake up the status quo and make people uncomfortable.  This can bring out the “corporate antibodies” who seek to destroy your project and the changes it may bring.  Change requires clear and effective communication about why the project improves the organization.  Change also requires a strategy for dealing with challenges to the project.


“I have been up against tough competition all my life.  I wouldn’t know how to get along without it.” – Walt Disney

Lesson Eight: Plan to defend your project.

One of the main responsibilities of a project manager is to defend the integrity of the key project control parameters…scope, schedule and budget.  That isn’t to say that the three tenets of the “project iron triangle” can never be changed.  With proper change management protocol in place, project leadership decisions andor the necessities of  project execution can dictate changes to the original plan.  However, one must always remain vigilant to the negative effects of scope creep, gold plating and risk, regardless of the source.  How many times have you been approached by a project sponsor or stakeholder who demands that you change the project without going through the bother of running the request through the integrated change control system.  If you’ve succumbed to this peer pressure and the project gets derailed, you’ll be the one left without a chair when the music stops!


“We keep moving forward, opening new doors, and doing new things, because we are curious and curiosity keeps leading us down new paths.” – Walt Disney

Lesson Nine: Innovation can come from inside the project team, not just from the stakeholders. 

Allow your team members to be an integral part of creative problem solving for the project.  By soliciting creative thought from your team members, you foster and atmosphere of innovation, stream-lined solutions, and increased team morale.  Early on in the project life cycle, challenge your team to think creatively about developing solutions to the problem being addressed by the project.  Be accepting to changing plans, approaches and solution ideas.  Run some “proof-of-concept” sessions or trial runs to validate the ideas.  Once the project team has landed on a particular approach however, that is the time to start bringing more control and managed change to the initiative.  Locking in on the tasks needed to deliver a specific approach ensures execution on the idea.  Allowing blue-sky thinking to continue without end causes uncontrollable work effort or worse, “analysis paralysis.”


 “You know, one day when a little boy asked, ‘Do you draw Mickey Mouse?’ And I had to admit I do not draw anymore.  ‘Well, then you think up all the jokes and ideas,’ he said.  ‘No,’ I said, ‘I don’t do that anymore either.’  Finally he looked at me and said, ‘Mr. Disney, just what do you do?’  ‘Well,’ I said, ‘sometimes I think of myself as a little bee.  I go from one area of the studio to another, and gather pollen, and sort of stimulate everybody.’  I guess that’s the job I do.” – Walt Disney

Lesson Ten: Know when to manage, and when to lead.

An effective project manager must know when in the project life cycle to manage, and when to lead.  Typically, management activities occur during the initiating and planning phases of the project.  The project manager must, by proper protocol, maintain a more “hands-on” approach to guiding the project through the initiating and planning processes.  Defining the project scope, building a charter, developing cost estimates to include with funding requests, preparing stage gate presentations and generating a work breakdown structure with the project team are all direct management activities for the Project Manager.  On the other hand, during the executing and controlling phases, the Project Manager should take a step away from the day-to-day operations of the project and transition into more of a leadership role.  By using a “management by walking around” approach, the Project Manager can allow the team to focus on executing the plan (completing the work) while he/she communicates updates on progress, provides steering/coaching where needed and deals with issues and/or risks that may be experienced.


So in a nutshell, what are the ten things Walt Disney has taught me about project management?  First, believe in the project one hundred percent.  Second, balance the constraints of time, quality and budget very carefully.  Third, set a positive environment for the project from the very beginning.  Fourth, pay extraordinary attention to detail.  Fifth, walk the project path before ever taking a step.  Sixth, assemble the best possible project team and plan for both achievement and challenge.  Seventh, maintain clear and consistent communications throughout the project and be aggressively proactive in communications with the team and the stakeholders.  Eighth, listen to and understand the unasked question.  Ninth, be certain of project completion criteria.  Tenth, learn from both successes and failures.

Just How, Exactly, Does A Project “Feel” Yellow?


I was attending a portfolio review meeting the other week where all of the organization’s project managers and IT business line managers are supposed to share project status and openly discuss any issues or concerns.  In reality, it’s a dysfunctional hot mess with sporadic attendance that seems to serve primarily as a forum for people with limited knowledge of project management discipline, or who have no real engagement with the projects, to publicly subject the PMs to a barrage of passive-aggressive questioning and pontification on “best practices.”  But I digress…(in fact, there will be a special post on how to structure effective project review meetings coming soon!)

Anyway, during the meeting, the following comment was voiced,

“I see the project is green across the board.  Based on our discussions here, it feels more like it should be yellow”

Excuse me?  It “feels” like the project should be yellow?  Just how, exactly, does a project “feel” yellow?

A project or key performance indicator either is or isn’t a certain status.  If you are going to use a “stoplight”-based health signalling system in your status reporting scheme, you need to establish EXACTLY what each light color indicates.

For example, here is what I typically use:

  • Overall Project
    • Red = One or more health indicators are Red
    • Yellow = Two or more health indicators are Yellow
    • Green = All health indicators are Green and/or no more than one health indicator is Yellow
  • Scope
    • Red = Unauthorized Scope Change Has or Is Occuring
    • Yellow = Scope change requests pending
    • Green = No scope changes pending
  • Schedule
    • Red = Project schedule variance equal to or higher than 15%
    • Yellow = Project schedule variance within 10% to 14% (+/-)
    • Green = Project schedule variance within 0% to 9% (+/-)
  • Budget
    • Red = Project budget variance equal to or higher than 15%
    • Yellow = Project budget variance within 10% to 14% (+/-)
    • Green = Project budget variance within 0% to 9% (+/-)
  • Issues/Risks:
    • Red = Project cannot proceed due to risk and/or Issue
    • Yellow = Project schedule, scope or budget has been measurably affected by risk and/or issue
    • Green = No issues/risks or issues/risks being managed/mitigated according to plan
  • Resources
    • Red = Project cannot meet schedule, scope or budget without resource(s)
    • Yellow = Requested project resources are unassigned, unallocated or unavailable
    • Green = All requested resources have been assigned and allocated

Project status and other key performance indicators are primarily quantitative in nature.  This is because people’s qualitative observations are subjective, hard to define and difficult to reach consensus.  I’m not trying to completely discount the importance of experience, intuition, reading body language and all of the other soft skills that successful project manager’s leverage when leading the project effort.  But when it comes to reporting, there should be zero confusion on where the facts of the project status rest.  Changing a project’s health indicator because it “feels” a certain way completely ignores the reality of the situation and invites confusion and unnecessary delay.

In fact, the entire concept of a stoplight-based reporting scheme is to:

  • Provide an “at-a-glance” visual of project health for stakeholders
  • Bring a heightened sense of awareness to stakeholders that certain conditions exist which may potentially impact the project delivery (typically for YELLOW status)
  • Call attention to critical issues, risks and/or conditions that have significantly impacted or stopped project execution (typically for RED status)

As a quick side note, a few project stakeholders have asked me over the years why I would flag a project that had a negative variance.  For example, if the project is forecasted to complete a month early, or say -17%, why would that be “bad” news?  Opportunity cost!  In our world of limited resources, people committed to a project cannot be fully utilized on other projects during the same timeframe.  If the project finishes early, what are those people going to do?  The same thing can be said with project financial investments.  Holding onto money that you know your project will never spend robs the organization of the ability to use it for other important efforts…including, perhaps, your raise!