5-Minute Tools for Product Leaders: Managing Bottlenecks Using the PERT Chart
Tamás Varga
Senior Growth & Product Manager | Creating Strategy & Leading on Execution | Building High-Performing Teams | eCommerce, SaaS, Online Travel
If you have ever watched the series Salvation on Netflix, you may have heard the term ‘First things first’ occasionally. In the fast-paced sci-fi genius entrepreneur Darius Tanz often needs to make decisions that could alter the fate of the planet. It is in these high-stakes moments when, as a sign of intense concentration, he starts to roll his eyes, runs through possible various courses of action, and finally concludes which step to take that would prove to be more influential than others.
While as product leaders we rarely need to save the world, we do need to set direction on how we grow products, teams, and eventually ourselves. And just like Mr. Tanz, we often face multiple possible options to choose from.
A bottleneck is the single most important element that constrains a system - like the neck of a bottle limits the amount of water that flows through. And as Eliyahu M. Goldratt argues in his book The Goal: A Process of Ongoing Improvement, the ability to consistently identify and lift bottlenecks is a fundamental management competence.
In this article I will describe a practical application for project delivery, the PERT chart.
PERT stands for Program Evaluation and Review Technique. It is a tool to facilitate planning by mapping and visualizing dependencies between deliverables and resources. It is also the single most useful tool I have found to help planning and keeping track of more complex projects. Miro and Lucidchart have built-in PERT chart templates.
I have been using the Miro template and like to apply it in a slightly adjusted way. By adding responsible teams, members, and coloured status indicators to each of the deliverables, you can get a single overview of (1) what should be done, (2) by who, (3) by when, (4) what the dependencies are, (5) and their statuses.
By then grouping the individual deliverables, you can visualize the higher-level building blocks of the project and their lower-level content. This is like adding an epic level on top of stories, in traditional development terms.
Once you have the mapped chart, you can also identify the longest series of interdependent steps in the project: the critical chain. Eliyahu M. Goldratt points out in this subsequent book, Critical Chain, that as project manager you need to pay particular attention to the progress on this chain. You should focus on removing any blockers or taking use of any early deliveries in this thread, as the length of the critical chain directly defines the length of the project. In our example I have highlighted it using the green boxes below.
I have been using the adjusted PERT chart for mapping more complex development projects at their start, and then updating it occasionally as needed. Creating the chart in advance does not mean you need to know everything in advance. But you need to understand the backbone of the project and be able to adjust as you progress – which for me is precisely the purpose of it. It takes you through an exercise of thinking in and mapping the subsequent bottlenecks of the project for unlocking the intended value, and refining these as you learn along the way. Using it can be beneficial primarily for product leaders who assume a project manager role.
The chart has helped increase my ownership over projects, reduce my cognitive load, drive discussion on the project structure with the development team, create transparency and trust towards stakeholders, and to generally track and manage progress. I usually create it at the beginning once, and then update a few times when I feel it is useful, without sticking to any very rigorous schedule.
I have found that the PERT chart is primarily for the PM and the close team. It is complicated to use as a regular progress reporting tool towards stakeholders - I usually use a regular text or table format for this purpose.
This article is the first part of a series with the goal to help product leaders grow, by describing practical tools I have found useful throughout my career. The articles will aim to find a sweet spot between being short enough to read in 5 minutes and long enough to inspire to try or initiate discussions on them. Stay tuned for the next one.
Principal Product Manager at GoTo
7 个月Very interesting article indeed, raises several thought-provoking points especially prioritization. I found the parallel between Darius Tanz's high-stakes decision-making and the role of product leaders particularly compelling.? When applying the PERT chart, I would be further interested how do you handle situations where deliverables are heavily interdependent, but different teams have conflicting priorities? Do you have any strategies for aligning these priorities without compromising the critical chain? The critical chain concept is another intriguing aspect. Given that early deliveries on this chain can impact the overall project length, how do you balance the need for flexibility with the pressures of adhering to strict timelines? Have you encountered instances where adjusting the critical chain significantly altered project outcomes? Lastly, your point about the PERT chart being mainly for internal use resonates with the need for simplicity in stakeholder communication. What criteria do you use to decide when an update to the PERT chart is necessary, and how do you ensure that these updates remain beneficial rather than becoming burdensome? Looking forward to the next part of this series and more practical insights!
Crowdfunding-Pionier seit 15 Jahren mit über 280 Mio. € für mehr als 32.000 Projekte.
8 个月Great insights! I've never heard about it before, but I can see it that it makes totally sense. We only worked with Gantt charts so far and managing all user stories and epics in gitlab. Do you see any good way to visualize and also put the dependencies of customers in there when doing software projects for other companies? We often face the challenge that customers take their time for decision making, contract and internal deliveries but still think that this will not change the deadline.