Flow: The missing tenant in the Traditional Project Management

Although traditional project management provides tools for data and flow, however, the main focus is extensive upfront planning. The process flow is not an indication of the value generated for the stakeholders. Agile project management focuses more on the flow of value generated for the stakeholders than the process itself. Due to the flow of the value and adaptability, there is a higher success rate of the projects.

Project Management Institute was founded in 1969 and created a body of knowledge for project management. In 1996 they published the first version of Project Management Body of Knowledge. Even in the first edition of the PMBOK there are 9 knowledge areas and 37 processes and 9 processes are related to a different type of planning (PMI 1996), which is almost 25% of all the processes defined. Over time, they keep updating this body of knowledge-based and the latest edition published in 2017, which contains 49 processes, and 11 out of them are related to planning (PMI 2017).

There is one big problem in this approach when the nature of the project is complex, such as software development. The problem is all the upfront planning is almost wrong all the time. There are lots of tools for doing extensive planning, such as the Gantt Chart. Teams spend lots of time creating colorful, fancy, and complex Gantt charts with only one problem that they are wrong all the time (Sutherland 2014). I even observe teams created Gannt Chart after completing the project for documentation purposes.

In traditional project management, if the project is under budget, on schedule, and covers the full scope, it is considered a success. However, there is a problem in it that it doesn’t mean that it provides value to the customers. It is possible that even if the project is completed on budget, on schedule, and covers the full scope, it doesn’t generate the value because the market condition may be changed. The initial scope may not be applicable anymore.

Eliyahu Goldratt introduced the “Theory of constraints” in his famous business novel “The Goal (Goldratt 1986), which focuses on improving the flow of the system. He describes five steps model to enhance the flow of the system to generate value continuously. The steps are to identify the constraints, then exploit it, followed by subordinate everything else, and alleviate the system constraints and repeat the process. Karen Martin explains the visualization tools Value Stream Mapping in detail with measurement to find the bottleneck to improve the flow (Martin 2013).

Gene Kim re-enforces the concept of flow, not only his two novels Phonex Project (Gene 2018) and Unicorn Project (Gene 2019), influences by “The Goal” as well as DevOps Handbook (Gene 2016). He proposed three ways to the DevOps, and the first one related to improving the flow of the value creation similar to the concept of flow defined by Eliyahu Goldratt. There is one main problem in the theory of constraint that it didn’t discuss anything related to the batch size. David Anderson uses these concepts in his famous Kanban blue book (Anderson 2013) to introduce work in progress limits to improve the flow. Jeffrey Liker explains the 14 principles to explain the Toyota Way, latter known as Lean, and the second principle of it is creating a continuous process flow (Liker 2003).

Donald Reinertsen explains the concept of flow in detail and explains 175 principles to explain the flow concepts with mathematical background whenever necessary (Reinertsen 2012). Oosterwal narrates the real story of Harley Davidson to improve the overall flow of the process. (Oosterwal 2010). Dean Leffingwell introduced the Scaled Agile Frameworks and created principles of SAFe from Reinertsn and Oosterwal work, explained by him and Richard Knaster (Knaser 2020). One more important work in that area is by Allen Ward, which was published sadly after his tragic death (Ward 2014). Jim Highsmith also discusses the importance of value over the constraints and continuously creating value (Highsmith 2003).

Jorgan Hesselberg (Hesselberg 2018) discusses the concept of flow in his famous book “Unlocking Agility,” where he discussed three critical levers to balancing business agility. These are “Build the right thing (value),” “Build the thing right (quality)” and “Building at the right speed (flow).”

All of these examples of work explained the importance of the flow of value creation from different angles. One of the advantages of creating a continuous flow of value is to get constant feedback and take corrective action if necessary to avoid further deviation. Gunther Verheyen explains the importance of empiricism and feedback loop in his famous small book on Scrum named Scrum Pocket Guide (Verheyen 2019). Every event in Scrum is an opportunity to inspect and adapt.

On the other hand, if we take a look at traditional project management, although they have defined lots of processes, the primary intention is to create a plan and execute it as closely as possible. To make it even more realistic, there is even a concept of Earn Value Management, in which the project manager first creates a baseline. At regular intervals, try to determine how much variance is from planned worked to completed one and planned cost to the reality. In my experience, it is nothing more than some fancy reports, charts, and graphs. The main reason behind that is work complete is not equal to the value. Only the customer can tell if the completed work has any value of the finished work or not. In other words, all the calculations, data, reports, charts, and graphs are based on our assumption that completed work is equal to the value, even it is not ready to be delivered to the customer’s hands. The closest tool I can find in traditional project management is “Rolling wave planning,” although better than significant upfront planning; however, it is not easy to use it with EVM.

For the sake of argument, even if we assumed that work completed is equal to the value and we always able to predict, infer or calculate the correct value generated by the finished work, if it is not delivered, then there is no feedback loop. There are documented examples of the completed project as planned, but no more required by the customer or may not have the same value it was when the project was in the planning stage. If the nature of the project is complex, and the duration or scope of the project is huge, then it is especially true.

References

• Anderson D (2013) Kanban
• Gene K (2016) The DevOps Hands book: How to create world-class agility, reliability, and security in Technology Organization
• Gene K (2018) The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
• Gene K (219) The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data
• Goldratt E (1986) The Goal: A Process of Ongoing Improvement.
• Highsmith J (2003) Agile Project Management: Creating Innovative Products
• Hesselberg J (2018) Unlocking Agility: An Insider’s Guide to Agile Enterprise.
• Liker J (2003) The Toyota Way: 14 Management Principles From the World’s Greatest Manufacturer
• Martin K (2013) Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation
• Oosterwal D (2010) The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development
• Project Management Institute. (1996). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute.
• Project Management Institute. (2017). A guide to the project management body of knowledge 6th edition (PMBOK guide). Newtown Square, Pa: Project Management Ins
• Reinertsen D (2012) The Principles of Product Development Flow:
• Richard K (2020) SAFe 5.0 Distilled
• Sutherland J (2014) Scum: The Art of Doing Twice the work in Half the Time.
• Verheyen G (2019) Scrum — A Pocket Guide: A Small Travel Companion
• Ward A (2014) Lean Product and Process Development