I'm not a fan of PMI or the PMBOK. I believe the fundamental premises behind PMI and PMBOK are honorable and correct in terms of work breakdown structures, dependencies, planned versus actuals, critical paths, and risk mitigation and issue resolution. The problem I have is with people who, having no experience in a particular industry, show up and apply what they believe to be universal laws of work, team organization, management and delivery without context of the unique elements of this industry over that. For example, the required behaviors of urban and regional planning require different behaviors and decisions than moving software to market, or even managing manufacturing assembly lines and production declaration through a plant. Context-driven decisioning is imperative. However, while there are some elements that are the same regardless industry and product, there is one in particular that I believe to be so important it transcends industry, product, practice, team and culture -- planned versus actual tracking and reporting.
What did you say you would do, what actually happened, and what is the delta?
Assembly line #12 is configured to construct one sub-assembly -- 50 units per hour, 24 hours per day. The math used to arrive at this goal and then used for baseline is built upon a series of assumptions and dependencies including sub-assembly availability, line staff availability across three shifts, power, mechanical availability and service frequency/responsiveness and so on. After arriving at the plan which includes what is needed to run and what will be the by-product of the run, we have a plan. What happens across a 24h shift and per hour within the 24h shift is the actual. If there is a delta greater than the planned and acceptable deviation percentage, there is a gap that impacts the entire supply chain and all ripples thereafter.
Software product #13 is expected to have 5 widgets planned to be delivered in AB time at XY cost. The math used for this experience is similar to that of Assembly line #13 in that there are presumptive dependencies to even start, let alone continue and resultantly deliver. There is technical and business design (plan) and then delivery (actual) where the delta is measured by business stakeholders, but primarily customers. Above this, there is overall project plan and actual with expected and manageable deviation; but deviation greater than plan is a gap actual therein unacceptable and requiring attention.
Both scenarios, and there are more examples in more industries for sure including financials, urban and regional planning, transportation logistics, etc., suggest the pertinence of knowing the plan versus the actual in order to manage the gap. No plan, no gap acknowledgment making actuals less relevant and/or meaningful. No documented actuals, and deviation from plan is unrecognized until funding is depleted. Sounds familiar in the 2008 US financial market, yes? We have a litany of Wall Street examples teaching us this concept very well right now. Even if there is a plan, an actual and an acceptable deviation margin -- there must surely be calculated probability suggesting an ability to deliver within margin.
If there is one and only concept from PMI and PMBOK for anyone, educated or otherwise, to take away and use for life in any industry and in any situation, I argue it is understanding plan versus actual versus acceptable deviation and probability of delivery within this framework. Ironically then, in order to understand and apply these concepts, one additionally needs to understand work decomposition (aka work-breakdown structure), time and dependencies, staffing, critical pathing and cost.
Seems like fundamental concepts of the PMI PMBOK just transcended industry, service and product. Now if we can just get the majority to understand context-driven application.