In the last 5 years I as Product Manager, I often found myself disliking the common ways on how to express project status and deadlines. They’d either hide important complexity or are a mess to keep up to date. Over time have grown a visualizations technique and meeting format I call the Weekly Dependency Chart. This helped me get structure and overview in projects I inherited, that were complex, late or required reliable schedules. I applied this in several private and professional contexts successfully. It was originally inspired by the Puzzle Dependency Charts used by Ron Gilbert in his adventure games.
The idea is to have a quick high level overview of timelines, to-dos, blockers all lined up in a weekly calendar view. Each item connected to the items it’s dependent upon.
Over time this graph evolved into a meeting structure, you can use to keep the overview up to date while synchronizing the status with the people involved.
Setup
My setup is usually in Miro, Mural or any similar whiteboard software.
It builds on a simple table: week number and staring date in the column head and a lot of free space below. Within each columns are the items containing the actual to-dos. Ownership is communicated by color (or texture if the software allows which is better for color blind people). A Todo-Note is to be put into week, when it should be finished. Finished todos are made 50% transparent and remain in their week. This way it’s easy to see what was accomplished each week and what is in the weeks ahead.
Todo-Notes are then connected with each other reflecting their dependencies. These connections show the dependencies.
This follows these simple rules:
- Any to-do can be required by multiple other to-do.
- Any to-do can be dependent on multiple other to-dos.
- A todo-note can only be finished if all it’s predecessors have been finished.
- No to-do can have a predecessor in the future.
- Any to-do has one ultimate owner.
- The current week is highlighted.
- Past weeks may only contain finished to-dos.
Additional I like to add notes to the chart to provide context. For example marking deadlines, vacation times, holidays or milestones.
On a complex project, with many dependencies, this can become crowded, in which case I started splitting the week columns into multiple rows reflecting main workstreams or departments.
This chart is with projects in mind who have a clear end. As such you could have a final end card, that is only finished, once all dependent to-dos are done. Realistically, in my projects, in the final phase, as to-dos moved from the project scope into continuous development, the Weekly Dependency Chart (and its meetings) just end as it outlived its usefulness.
Meeting flow
Originally, I only used this chart for myself to get structure and overview into complex projects. As I showed and discussed this with colleagues, we began to integrate it into our weekly Jour fixes. Everyone having tasks in the Dependency Chart would participate in this weekly update meeting, together we’d maintain it and use it as the jumping off point for discussions.
As moderator, in the first half, I’d update the current week and ask every participant about their updates. Either they already have their to-do cards up to date, or this is their chance to update it life quickly, before giving a short progress report. No open to-do cards should remain in past weeks. If the to-do is not finished its card either has to be moved to the current or a future week. Dependencies on the card will have to move accordingly, and prompt a discussion, what the consequences to the project down the line are. This way you have a very easy tripwire to recognize upcoming issues in your project plan early.
At the end of this half, all todos of the past week have been marked as done or have been moved.
In the second half, we look at the current week with the question “With all the tasks, that have been moved, is this realistic to finish this week?” Todos tend to bunch up in the current week and this is a great visual indicator to see, how a project is lacking behind. In this discussion everyone can reflect, if the expected tasks are realistic to finish. Ideally the moderator learns over several weeks, how reliable the participants are in terms of delivering their todos and how well they’re time estimations are.
If the bunch-up can only be resolved by moving tickets to the future or removing tasks. This may result in discussions outside the meetings about the project plan. This meeting format is for identifying risks early. Only in small scopes, it is the right place to also resolve these.
By the end of the second half, you have all the tasks for the upcoming weeks moved ahead reflecting an ideal implementation path.
- A To-do cards being required dependency of many other to-dos indicates a high importance to the project, a bottleneck and is a natural candidate for a milestone.
- To-dos bunching up in one week are a an indicator that a review of the projects timeline or scope may be required soon.
- Having many to-dos in a week that are dependent on each other indicates, that this week is very risky as interruptions can lead to re-scheduling easily.
- If most to-dos are of the same color, it means one person is responsible for all. Maybe split the work in your team better?
- Cards without dependencies are great as jumpers who can be moved ahead if people are blocked by other to-dos.
After the meeting, I like to do a screenshot of the visualization. This is not mandatory, but allows later comparisons between the current document and earlier expectations. This can be used as evidence for a later retrospective to discuss on why certain tasks took different times to finish than expected.
I made good experience of this meeting format with 2-6 participants.
Limitations
I regards this visualzation as one more option in your toolbox, it certainly does not fit every occasion. It’s an opinionated simplification focusing on delivering reliability and synchronization.
There are several things, this does not do. First and foremost, it does not indicate how long a task would take. It only shows by what time it will be done.
While similar in approach to Gantt charts, the level of detail in both visualizations is very different. Gantt is more detailed, but takes much more effort to setup and maintain. The Weekly Dependency Chart makes it easy to shift to-dos and dependencies – something often a pain in Gantt, discouraging changes.
To people looking at Gantt charts, the rigor of the project plan may suggest a maturity/stability, that is often not true (in software projects anyway). It is easy to interpret the given time estimations as promises. The Dependency Chart simplifies to the most important steps and highlights the agility of the plan.
Lastly, the chart is best for a project with defined end over a span below 9 months with below 8 managing people. For bigger projects, it could be worth trying to break the project into smaller parts, that could fit the format again, but I haven’t tried that yet.
This is best used in a waterfall project, but can also applied iterative projects.
I wouldn’t use it for Agile projects or in combination with Scrum.
TLDR
The Weekly Dependency Chart is a cheap visualization of tasks and their dependencies in a project. It’s best for projects of 6 people over up to 6 months. The chart offers a great basis for weekly jour fixes on the projects and gives a great basis for timeline discussions in risky projects.
- Meeting format offers structured way to request weekly updates
- Tripwires to discover when projects plans are at risk of running late
- Easy updates encourage more reliable project status