Out with Deterministic Project Planning

5 Responses to “Out with Deterministic Project Planning”

1. Phil Wolff Says:
   November 12th, 2008 at 2:17 am

   project management came from codifying common mental models. deconstruction from goals into chunks of work. relationships among the chunks. using attributes of the nodes and edges to do a little math, even probabilistic math. it’s powerful stuff.

   but i wonder about other ways of thinking about a big thing many people do (not calling it a project). like a political campaign, which is so amorphous and organic and emergent and social. or iterative creative works like filmmaking and software design, where the goals are approximate at best and the methods for doing work are adapted and improvised.

   has the PMBoK met its natural limits? or do we want to enjoy some of PM’s benefits in areas of work where reductionist models never took hold?

2. Dr Phil Rutherford Says:
   November 12th, 2008 at 5:42 am

   At last! More people who are starting to ‘get’ it. The PMBoK is not ‘the’ guide, it is ‘a’ guide to what most people are doing. Furthermore, it is not a methodology, simply a collection of knowledge areas which are investigated and acknowledged to one extent or another by effective and successful managers of projects.

   Project management is environmentally specific - that is, the more complex, asymmetric and chaotic the environment the greater is the need for lean project management techniques. It is only in the very stable environments that rigorous project planning is possible - and how often do we come across them?

   At its best the PMBoK defines those elements which must be considered, either briefly but concisely (in complex environments) or rigorously and with great detail (in stable environments). At its worst the PMBoK is a danger because some people regard it as a book of rules and procedures which must be slavishly followed. Sadly, too many of our formal education and training institutions fall into this latter category.

3. Robert Ferguson Says:
   November 12th, 2008 at 6:52 am

   Hal,
   Interesting to hear that from PMI. I’ve been telling people that you have to plan for change for some time. We know from decades of research, that requirements change during product development. The rate of change is usually in the neighborhood of 25% per year. How many projects cook that number into the plan?

   Planning for change means that we plan interventions to discover what the change needs to be. The problem with requirements is not unstable requirements. It is that we fail to stabilize the requirements before the end of the work. If we have not received any product changes for 6 months, we need to assume we have not looked!

   All product development work involves learning. Perfect planning assumes we already know the solution. It simply is not true. Where is the learning, research, etc. in your project plan? How is that built into the needed replanning?

   Bob Ferguson

4. Glen B. Alleman Says:
   November 12th, 2008 at 10:34 am

   Greg, while I admire and respect him, should catch up with how programs are planned and managed in defense and space. Probabilistic cost and schedule has been mandated through DID 81650 since Jume 2005. Incorporating IMP/IMS (Integrated Master Plan / Inegrated Master Schedule) and your’re the 21st century. Heavy construction does the same using in many firms.
   The next step is Earned Schedule integrated with Eraned Value. See PMI College of Performance Management’s, Measurement News for a detailed set of papers. Add to that probabilistic portfolio management of projects inside programs, Markov Chains using Monte Carlo forecasting of future performance, and you’ll be caught up with the current state of the art for cost modeling and schedule impact analsyis.

   Glen B. Alleman
   VP, Program Planning and Control
   Aerospace and Defense
   Denver, Colorado

5. Dennis Stevens Says:
   November 23rd, 2008 at 11:00 pm

   Hal, I thought having drinks with me in Denver was the highlight of your conference.

   PMBoK has a set of process groups that are addressed in every project, intentionally or not. The Program and Portfolio Standards have related and interdependent process groups as well. Each project, like Glen’s development of a missle system, or the evolving creation of a web based business application address these process groups. I just don’t think we are going to get away from the capabilities of planning, communicating, staffing, procurement, quality, etc.

   The issue is to figure out the appropriate trade-off between perfect planning versus organizational learning and progressive elaboration. The process groups may not even be all inclusive. In OPM3 we included a set of Organizational Enablers that could be addressed as well. But it is unreasonable to purposefully address all of these processes for many projects, so how do we limit our focus and investment into the project delivery capability to the smallest amount of effort neccessary to optimize the delivery of the project?

   We keep getting caught up in the “How Trap” of historical implementations of these processes and not addressing the outcome gaps. Where we need to innovate is to figure out for each project how we implement the best practices to achieve the outcomes for that particular project. How do we bring in new practices and organizational/social constructs to continue to improve our ability to deliver projects? None of these questions are outside of the scope the PMI standards. In fact, if we can raise the conversation above the historical implementation of the process groups the standards provide a robust structure for the conversation.

Comment On This