Adaptive Project Management is, at it’s core, the art and science of solving complex problems by getting the right people talking about the right things at the right time.
There is more to Adaptive Project Management than this statement suggests of course. Adaptive Project Management is built on the foundations of good project management as compiled and documented in the 497 pages of the Project Management Institute (PMI) Guide to the Project Management Body of Knowledge (PMBOK Guide). It includes planing, work breakdown structures, scheduling, risk assessment and most of the other components of good project management. But Adaptive Project Management then goes beyond traditional PMI practices by incorporating concepts of empirical process control, concepts which have been used in continuous process manufacturing for decades.
Empirical process control utilizes short delay feedback loops, monitoring data to adjust the process in near real time. From a project management perspective, particularly in complex domains, that feedback loop almost always involves people. As the linguist Dr. Deborah Tannen says, “Talking is how business gets done.”(1) But while talking is something most of us have learned by age 3, communicating is far more challenging, something which challenges most of us throughout our lives. This is why empiricism is important, as is a structure within which to have those important conversations. Which is where that first statement about the core of Adaptive Project Management comes from.
This need for structured conversation is particularly true in the case of complex problems, because complex problems are specifically identified by the existence of feedback loops, and often feedback loops which are fed by autonomous agents outside the control of a project. Complex problems defy more traditional project management approaches because, for example, the nodes in a work breakdown structure often interact with other components in other work breakdown trees. This is illustrated in the diagram to the right.
In the top diagram, we show a typical a work breakdown structure. The top level node represents the overall problem statement, for example, build a house. That high level task is then broken down to the financing, foundation, framing, plumbing, electrical, sheet rock, and finishing. The foundation in this example, can be further broken down to surveying and staking, trench digging, concrete form setting, concrete pour, form removal and back fill. The work breakdown is an effective means of breaking the larger problem into a set of manageable tasks, which can be sequenced, costed, and possibly subcontracted. This allow mere mortals to manage complicated projects.
Complex projects introduce an additional dimension to the problem space. As shown in the second image, the nodes lower in the work breakdown structure may have a relationship with one or more nodes somewhere else in the work breakdown. Often these can be recursive relationships. For example, the movement of the pen set in an inkjet printer is limited by the current capability of the servo system, and subsequently, the mass of the pen carriage. But the mass of the pen carriage is a function of the rigidity required to handle the forces applied to the pens, which are, among other things, dependent on the expected acceleration. So the acceleration of the carriage is dependent on the mass of the carriage, which is dependent on the acceleration.
The design has to occur based on assumptions, which are later refined through iteration, to converge on an optimum design. There are several causes for this need to converge on solution. Often you are working new new realms, where there is no prior knowledge to tap into. Tyson R. Browning describes this phenomenon in product development in his paper on Design Structure Matrices.
The phenomena also appears in situations where requirements are hard to elicit at the beginning of a project. Your customer has a vague idea what they need, but won’t really know until they see it, but they cannot see it until you develop it. External changes can also lead feedback which is detrimental to deterministic project management approaches. The Los Angles class submarine, fairly new during my Navy tenure, was originally designed with ample berthing (sleeping) space, however as new weapon system technology became available, it was incorporate in to the ship design late in the development process. Since changing a submarine hull is a non-trivial task, that new technology was placed in the one spot which was adaptable, and sleeping arrangements became much more cozy.
What this is all getting to is that, especially in in a complex project, your project is going to change, either because you are going through a learning process, or because the world in which you designed your original project has changed, often significantly and sometimes rapidly. This is where traditional PMBOK style project management and Adaptive Project management go separate ways philosophically.
The PMBOK refers to “Change Control” while adaptive project management refers to “change management.” The PMBOK refers to “change control boards,” while adaptive program management refers to “planning iterations.” The PMBOK refers to “managing communications,” adaptive project management refers to “facilitating communication.”
Adaptive Project Management is built on sound PMI practice, but extends that by incorporating queuing, information, systems and organizational development theory. The art of Adaptive Project Management is knowing which theories (the science) best guide the principles and practices within a particular context to deliver optimal value value. It is the art and science of getting the right people talking about the right things at the right time.
- Quote from Deborah Tannen, Talking 9 to 5: Women and Men in the Workplace training video, Charthouse Learning.