Dependency Flow Planning Methodology

[tu2-atmanand]

Hello everyone !

While working on the map view feature for the past few months I have been able to develop a new task management and planning methodology : Dependency Flow Planning (DFP).

This methodology is not entirely new, but a combination of multiple other methodologies with its own twist to manage small to large projects without any large learning curve.

Initially it has been developed for a specific type of project management but I believe with time this can be enhanced further and it can have a great potential for managing lot of different task and this methodology can be generalized for all kinds of projects.

Summary

DFP methodology is mainly a revolution in bringing the power of digital canvas for planning, mapping and creating a flow of continuous work for your sequential projects. Additionally, as its highlighting feature, DFP helps in live tracking your project workflow while working in huge teams. Its advantages like, finding the hurdles and bottlenecks inside your projects, live canvas and easy organizing the workflow map makes it unique in today autonomous world to manage a large variety of projects.

Read the research paper or watch to demo in the YouTube video to understand the true potential of DFP methodology.

Research paper

• Published in JDUT journal : https://jdut.net/volume-32-issue-10-page-2/
• Preprint : https://doi.org/10.5281/zenodo.17264606

Discussions

• Another discussion topic on Obsidian forum : https://forum.obsidian.md/t/dependency-flow-planning-dfp-methodology-a-research/108048?u=tu2_atmanand

Articles and other resources

Here are some of my early articles on this methodology :

• Dependency Flow Planning (DFP) Methodology

• DPF x Kanban - Synergy of the two methodologies

• A detailed YouTube video on DFP methodology and map view feature demonstration : https://youtu.be/mWfbDTO5pyw

Keep an eye on the YouTube channel and this post for more updates.

[tu2-atmanand]

I introduce Dependency Flow Planning (DFP), a bottom-up methodology that redefines project management by emphasizing child-to-parent task flows and strict dependencies. My findings suggest that DFP not only complements existing frameworks but also enhances efficiency and communication in managing complex, sequential projects.

The paper has been finally published. Have a look and share your thoughts : https://doi.org/10.5281/zenodo.17264606

[tu2-atmanand]

Paper published in Journal

Exciting news! My paper introducing Dependency Flow Planning (DFP)—a new bottom-up approach to project management that guarantees sequential logic and dependencies—is now officially published in the Journal of Dalian University of Technology!

This work shows how to combine the best of Agile/Kanban with strict dependency planning.

Check it out: https://jdut.net/volume-32-issue-10-page-2/

#DFP #ProjectManagement #Research

[tu2-atmanand]

Full Citation in BibTeX Format

Please use the below BibTex format to cite this paper using LaTeX or standard citation management software.

@article{YourName2025DFP,
  author  = {Atmanand M. Gauns},
  title   = {Dependency Flow Planning (DFP): A Novel Bottom-Up Methodology for Sequential Project Management},
  journal = {Journal of Dalian University of Technology},
  volume  = {32},
  issue   = {10},
  pages   = {1005--1014},
  year    = {2025},
  issn    = {1000-8608},
  url     = {https://jdut.net/volume-32-issue-10-page-2/}
}

[tu2-atmanand]

YouTube video

A new YouTube video has been published which explains this methodology and also demostrates this methodology and the map view feature using a real example project.

YouTube vide link : https://youtu.be/mWfbDTO5pyw

[tu2-atmanand]

An analysis by a fellow reddit user

This is interesting work from a plugin/dev point of view, but the “journal article” framing really deserves some side-eye.

A few things worth being transparent about:

• The “Journal of Dalian University of Technology | ISSN: 1000-8608” you cite has a well-documented hijacked/clone version (jdut.net) that operates as a predatory front. It’s not the legitimate Chinese engineering journal that the ISSN belongs to. That doesn’t make you malicious, but it does mean the publication venue isn’t real peer review. Functionally, it’s a pay-to-host blog post under a borrowed label.

• Conceptually, “Dependency Flow Planning” is mostly a rebranding of well-established project-management ideas.

• Bottom-up planning / progressive elaboration comes straight out of PMBOK and decades of systems engineering.

• Strict finish-to-start dependencies are the default in CPM, PERT, and essentially every scheduling tool since the 1950s.

• Node-and-arrow dependency mapping is standard in activity-on-node (AON) diagrams, dependency maps, and even modern tools like ClickUp, Jira, and Miro.

• What you’ve done is package these together under a new label and integrate them nicely with Task Board’s Map view, which is totally fine, but not a “novel methodology” in the academic sense.

• The paper frames itself like it’s filling a research gap, but there’s no empirical validation, no case studies, no performance comparison, and no formal argument for novelty. That makes it read less like peer-reviewed research and more like a conceptual whitepaper or an extended guide to using your plugin.

That said, credit where it’s due:

• The Task Board plugin and the Map view are genuinely useful additions to the Obsidian ecosystem, especially for people who prefer spatial workflow planning.

• The write-up is clear and does a good job giving people a mental model for dependency-driven planning inside Obsidian. Even if the academic framing is overstated, the actual content helps users understand how to structure work visually.

TL;DR: solid plugin work and a helpful workflow explanation. The “published novel methodology” vibe oversells what is essentially a thoughtful repackaging of existing project-management concepts tailored to Obsidian’s Task Board.

[tu2-atmanand]

Thank you for sharing so much detailed information on my work. The comments you have mentioned on the literature research are very nice. Although I was aware of few of the things from my research. But few of the things, I got know for the first time from your comment.

Yes, you are right, that this is not an entirely a new methodology. This has also been mentioned in the video as well as inside the GitHub post. And, also this paper is still in a pre-print state itself. I have published it the Journal, to get more peer review and suggestions on my work. To get a larger reach. Just like how you have shared your knowledge, I want to gain more such knowledge from other researchers. The idea behind the paper is to formulate a one globally known methodology which will have all the latest digital tool features for project management and planning.

I agree that DFP is an rebranding of well-established project-management ideas. But, it also has its unique features. Maybe not individually but when we combine all the bits and pieces together, thats when the true potential of DFP can be appreciated.

Let me first compare DFP on your points :

• Bottom-up planning / progressive elaboration : This is not the unique feature of DFP. I have mentioned it in paper title, to indicate that its different from other popular methodologies out there. (CPM and PERT are not so popular, as per my research).
• Strict finish-to-start dependencies : Here, you might have confused with Start to finish of the project with parent-child relationship. You see, the one disadvantage of CPM/PERT is that, you should know the start and end point of your project to use these methodologies. But DFP, dont have this restriction. You can simply just start your project with whatever information and tasks you have in hand and more tasks are being added as you proceed with the project. So, you may have realized that this kind of approach will be definitely not used in business project as their goals are fixed. But there are various other kinds of projects where DFP will shine. So, its not the start and end of the project here. But in-the-moment current-task and its parent-task relationship. The principle is "You cannot start working on the parent-task until all of its child-tasks are completed."
• Node-and-arrow dependency mapping is standard in activity-on-node (AON) diagrams : All these techniques/methodologies are mostly used for the "initial analysis" stage. That is mostly in PERT/CPM to find the "most critical path". They are entirely mathematical diagrams. The nodes which I am referring to are live-node. Which are basically UI engineered components, which contains a huge amount of vital information about the tasks in a more intuitive way instead of simple text (like color indicators and alerts, etc.). So, in this sense, the mentioned methodologies are very different from DFP, since DFP doesn't have any mathematical modeling in its map view.
  Also, I am aware of few organizations, which has modified the PERT methodologies to be used in the tracking phase of the project, which is the "live canvas" feature in DFP. Now, there is no globally accepted, and well-documented research paper which has stated these principles. So, technically, from the past globally accepted research material we have, PERT is only used for the "initial analysis" stage only using its complex mathematical model and not for the live tracking part. So, these are also very different from DFP. All the software which you have mentioned, are such organization which have modified and created their own flavor of task management but have not cited any globally accepted methodology which encompass all their important features, which their softwares provide.

What I am proposing through DFP, in simple words :

• A one single framework/methodology, which makes use of the latest digital tools and articulate strict principles which any team will use to plan, manage and track their project workflow.
• It should be usable for time constraint or non-time constraint projects.
• It cannot be used for finding the critical path. DFP should be used after finding the critical path.
• It can be used for projects with no end point set.
• Should make use of the live canvas, so it should be implemented inside a digital tool, to fetch the latest vital information about the tasks using the nodes.
• The map should be easy to break-and-make at any point during the project lifecycle easily without disturbing the overall map.
  So, DFP should articulate all the principles to have these above mentioned features. (Forgive me, I might be missing something here)

Let me know, if I have been wrong anywhere, due to my limited research knowledge. I would love to have a "prove-me-wrong" kind of friendly debate on any particular point where I have been wrong. These kinds of debate helps to make things more clear and to find a concise proof on those statements.

[macbikegeek]

I have to agree with the response to the methodology from the Reddit poster you quote. The thing I find strange and inconsistent with every other project methodology you reference, all of which I have used over a period of many years, is the choice of child-parent nomenclature. This is the reverse of every other methodology I know and for me is a total blocker to using your approach. I think it is valuable to synthesize the best features of multiple methodologies, and in the event, most projects I have worked on do that. But part of what makes that possible is the common nomenclature of child tasks being subtasks or dependencies of parents tasks, rather than the other way around.

[tu2-atmanand]

Hi @macbikegeek !

Thank you for joining in.

But part of what makes that possible is the common nomenclature of child tasks being subtasks or dependencies of parents tasks, rather than the other way around.

So, you are correct about this part. And I hope we are on the same page here with the following principle of DFP :

"You cannot start working on the parent-task until all of its child-tasks are completed."

Now, you mentioned that...

The thing I find strange and inconsistent with every other project methodology you reference, all of which I have used over a period of many years, is the choice of child-parent nomenclature

I think the confusion here is not due to the nomenclature, but may be how the DFP workflow works and due to the traditional methodologies nomenclature clashing.

I have already looked at DFP by using the nomenclature in other way around and after thorough consideration, I decided to proceed with the terms, DFP is using now. But, let me have some more thought on this, by looking at DFP from the traditional methodologies point of view.

Below are some pointers by AI, please note, this are only for collection of summarized information and doesnt indicate the true nature of its information. This is just for me to have a clear understanding and to refer it during my brainstorming stage. I am putting it here so that other viewers can also go through it and point out any mistakes or if they want to share any other suggestions.

[tu2-atmanand]

Summary by AI

1. The Standard Convention: "Parent = Container"

In traditional project management (and computer science trees), the relationship is defined by Hierarchy and Decomposition (breaking things down).

• The Parent (Goal/Summary): This is the larger objective or the "container." It represents the whole.
• The Child (Subtask): This is a smaller piece of the parent. It is a component required to complete the parent.
• The Logic: You break a Parent down into Children. When all Children are finished, the Parent is automatically considered finished.

Example in WBS:

• Parent: "Build Website"
  • Child 1: Design Homepage
  • Child 2: Write Code
  • Child 3: Set up Server

In this standard model, the Parent is the "boss" or the "folder" that holds the children.

2. The DFP Convention: "Parent = Consequence"

Your paper explicitly states that DFP reverses this dynamic. You are defining the relationship by Sequence and Flow (what happens next), using a biological/genealogical metaphor rather than a structural one.

• The Child (Input/Cause): The task you are working on now.
• The Parent (Output/Effect): The next stage that is unlocked by the child.
• The Logic: The paper states, "DFP fundamentally reverses the traditional top-down hierarchy... parent tasks are the logical next steps unlocked by the completion of their child tasks".

Example in DFP:

• Child: "Design Homepage" (Must be done first)
• Parent: "Write Code" (Cannot start until Design is done)

3. Why this is can be a "Blocker"

The main reason could be because it creates a cognitive conflict.

A "Parent" implies a Summary Task that encompasses the work. In DFP, you are using "Parent" to mean the Dependent Task (or Successor).

Feature	Standard Methodology (WBS/Gantt)	DFP Methodology
Relationship	Whole vs. Part	Cause vs. Effect
Direction	Top-Down (Decomposition)	Bottom-Up (Evolution)
"Parent" means	The Goal / The Container	The Consequence / The Next Step
"Child" means	The Sub-step / The Ingredient	The Prerequisite / The Trigger

The "Genealogy" Confusion

Your paper explains the logic as a generational flow: "The parent task, in turn, is a dependency for a 'grandparent task', and so on".

While this makes sense biologically (I am the child of my father, and I produce the next generation), in data structures (like trees in computer science), the "Root" or "Parent" is usually the top-level origin, and nodes branch out into children.

• Standard Tree: Roots (Parents) branch into Leaves (Children).
• DFP Flow: Leaves (Children) converge to create the Next Step (Parent).

Summary

While your mechanism (strict dependencies, bottom-up flow) is valid and useful, your vocabulary fights against the industry standard.

• Industry Standard: Child tasks support/complete the Parent.
• DFP: Child tasks unlock the Parent.

Next Step for you: You might consider if the terms "Predecessor" and "Successor" (standard CPM terms) or "Input" and "Output" would describe your flow more accurately without confusing users who are used to WBS hierarchies. Alternatively, you would need to heavily emphasize why you chose this metaphor (biological growth vs. structural breakdown) to justify the reversal.