Deep project management

We’ve seen the emergence of all things deep: deep learning, deep AI, deep semantics, even “deep fake.” Some disciplines have been quick to hop aboard this trend, others more slow.

One discipline firmly entrenched in the slow category is project management, where mainstream approaches are struggling to keep up with the rapid pace of change and increasing complexity in the global marketplace. Here’s a quick look at its century-long history. Keep in mind that each new generation doesn’t replace the previous. Rather, it builds upon and improves it.

Traditional project management (rearview mirror-oriented)

The theme here is “plan the work; work the plan.” This mature discipline evolved slowly over the course of the last century, from the introduction of the Gantt chart in 1917 to PERT/CPM (Program Evaluation Review Technique/Critical Path Method) in the 1950s and the Work Breakdown Structure (WBS) in the 1960s. Interestingly, KM has played a major role in recent decades. A large Project Management Body of Knowledge (PMBOK) has been built up, which is currently maintained by the Project Management Institute.

The problem is that reported data is highly summarized and time-lagged and gives little insight into the many small events at the activity level which collectively impact overall project performance. As such, alerts are often generated far downstream from root causes and conditions. Problems that could be quickly and easily addressed are allowed to grow, sometimes until it’s too late. This problem is made worse by the fact that systems engineering, HR, supply chain logistics, and other key support functions are often disconnected from project management activities.

Agile project management (just in time-oriented)

Agile project management emerged in the early 2000s, beginning with the publication of the “Agile Manifesto” in response to growing frustration over the shortfalls associated with traditional project management. This was also in response to increased demand for more rapid concept-to-deployment cycles in an environment characterized by unrelenting change and uncertainty. Although agile approaches come in several different “flavors,” all focus on getting a working product out the door “early and often” through rapid iterations and adjustments, rather than holding back release until all requirements are satisfied.

The problem with this approach is that being agile requires a major shift in mindset. People have a difficult time getting used to not really knowing how the final product will look until it’s actually finished. The good news is that agile requires working in small, preferably co-located teams, which results in close communication and greatly improves capturing, sharing, and applying critical knowledge. The bad news is that knowledge rarely gets transferred to other agile development teams, which often end up rediscovering the same knowledge from scratch. Which brings us to …