PERT -> see also ->
"Project network" https://en.wikipedia.org/wiki/Project_network :
> Other techniques: The condition for a valid project network is that it doesn't contain any circular references.*
> Project dependencies can also be depicted by a predecessor table. Although such a form is very inconvenient for human analysis, project management software often offers such a view for data entry.
> An alternative way of showing and analyzing the sequence of project work is the design structure matrix or dependency structure matrix.
design structure matrix or dependency structure matrix: https://en.wikipedia.org/wiki/Design_structure_matrix
READMEs, Issues, Pull Requests, and Project Board Cards may contain Nested Markdown Task Lists with Issue (and actual Pull Request) # references:
- [ ] Objective
- [x] Task 1 +tag
- [ ] #237 (GitHub fills in the Title and Open/Closed/Merged state and adds a *hover card*)
- [x] Multiline Markdown list item indentation
<URL|text|>
- ID#:
- Title:
- Labels: [ ]
- Description: |
- htps://URL#yaml-yamlld
- [x] Multiline Markdown list item indentation w/ --- YAML front matter delimiters
---
- id:
- title:
- labels: [ ]
---
- htps://URL#yaml-yamlld
| | Important | Not important
| Urgent |
| Not Urgent |
> https://en.wikipedia.org/wiki/Strategic_alignment ... "Schema.org: Mission, Project, Goal, Objective, Task" https://news.ycombinator.com/item?id=12525141
When you really need it (like in the case of tens of thousands of people trying to build and ship a single project at lighting speed) PERT is extremely powerful and effective. If, on the other hand, your "project management division" is you, it's a dangerously seductive time sink that will consume huge amounts of your time building and tuning and gathering data and information and understanding, for arbitrarily close to zero direct real benefit and huge net negative benefit. The increase in effectiveness you gain from all that modeling is, in software development projects, negligible and the cost of doing all that modeling is much higher than you think it will be if you've never done it. As with any approach to planning, PERT works best at a particular scale, and it's a very large scale.
In my personal opinion, from a software development standpoint, the valuable part of building a PERT chart is doing the work and thinking to draw a dependency map for your tasks. Drawing all those lines to show what has to be done before what is an incredibly effective tool for helping you flesh out and find the dependencies (tasks) you hadn't realized were going to be on your list. My view is use something like Project to build that dependency diagram, then force yourself to stop using Project because it's too seductive at making you feel like the data is giving you power when it's really just consuming your brainpower in effectively. Use dependency mapping to build a waterfall caliber understanding of what you need to build, then set it aside and use more appropriate agile style approaches to actually work through the project in an optimum manner (which often means not building it in exactly the way you mapped out originally).
[0]https://en.m.wikipedia.org/wiki/Program_evaluation_and_revie...