Context
I am preparing a PMP certification, and, as a way of studying the (large) matter of the PMI, I transcribe part of it in an Obsidian Vault. My end goal is probably to keep that vault as a reference for future use, and being able to communicate with it to projects’ stakeholders later.
So here, we’re only dealing with the PG² (Process Groups : A Pratice Guide) and all 49 processes described in it. Each process has an individual Note with a #Process tag. Properties are basically only :
- ProcessGroupIdx to identify the Process Group it belongs to,
- ProcessIndex to be able to sort them in lists,
- A List of ProcessOutputs (the Assets produced or altered by the process, as defined below)
- A List of ProcessChildren (with links to any other Process that relies on this one to exist)
We’ve got assets that can be both Input or Output of one or many different processes (all declared as separate Notes with #InputOrOutput).
For some reason, part of these assets are considered as member of a family of similare assets, that I called myself InputOrOutputContainer (as a tag, with #InputOrOutputContainer).
Then, we have these ToolsAndTechniques (again, each one having an individual Note with a #ToolsandTechniques), and families of them, designed as #GroupOfToolsAndTechniques.
In order to get my arrows well oriented when using Graph View of these Processes, here are the type of links I have made :
- #InputOrOutput Notes have a List field called “UsedAsInputIn”, where I put a link towards each single Processes where this Asset is used as an Input
- There are several #InputOrOutputGroup Notes for each process, in order to define the relationships of every single Asset as an Input or an Output of the Process (sometimes it can be both), but also to which subgroups they belong (e.g., [[5.17 Inputs - Project documents]] or [[5.17 Outputs - Project management plan updates]])
- There is one Note with a #GroupOfToolsAndTechniques tag for each process, linking all sub GroupOfToolsAndTechniques and ToolsAndTechniques Notes used in this process
As an example, here is the representation in the PMI book of the process :
And now, this is the result I get with my Vault :
- As a Graph View for one process in particular
- And now the view I get from the Note itself :
Things I have tried
Right now, what is running and helps me already are the following :
- the data is well structured
- the graph view of a process is great and pretty accurate (even if it is a bit messy with the dynamic placement of nodes, but at least, you can navigate easily, or highlight part of it, what you cannot achieve with a harcover version of the process representation
What I’m trying to do
First improvement I seek
The one thing I miss and I cannot produce by myself, is a more condensed way of presenting the whole Inputs and Ouputs thing for a single process. Right above, I used the following codes to get the lists in the image :
# Inputs
``dataview
TABLE
FROM #InputsAndOutputs
WHERE contains(file.outlinks,this.file.link)
SORT file.name ASC
``
# Outputs
``dataview
TABLE
FROM #InputsAndOutputs AND outgoing([[5.17 Plan Communications Management]])
SORT file.name ASC
``
# Tools and Techniques
``dataview
TABLE
FROM #ToolsAndTechniques
WHERE contains(file.outlinks,this.file.link)
SORT file.name ASC
``
By doing this, I have the list of all Inputs and all Outputs, but on two different lists. I would really like to have them in the same list, as well as with additional data on them, like this :
| Asset | Belongs to Input subgroup ? | Input ? | Output ? | Belongs to Output subgroup ? |
|---|---|---|---|---|
| Stakeholder register | 5.17 Inputs - Project documents | Input | Ouput | 5.17 Outputs - Project documents updates |
| Stakeholder engagement plan | 5.17 Inputs - Project management plan | Input | 5.17 Outputs - Project management plan updates | |
| Resource management plan | 5.17 Inputs - Project management plan | Input | ||
| Requirements documentation | 5.17 Inputs - Project documents | Input | ||
| Project schedule | Ouput | 5.17 Outputs - Project documents updates | ||
| Project charter | Input | |||
| Organizational process assets | Input | |||
| Enterprise environmental factors | Input | |||
| Communications management plan | Ouput |
The fact that an Asset is part of a subgroup is supported by explicit link between the Asset Note and the Subgroup Note (from the Subgroup to the Asset).
The fact that an Asset is an Input for a specific Process is supported by a link from the Asset Note to the Process Note. And the same thing for a SubGroup of Assets as Inputs to a Process.
The fact that an Asset is an Ouput for a specific Process is supported by a link from the Process Note to the Asset Note. And the same thing for a given Process to all SubGroups of Assets as Outputs.
The intent here is to clarify which Assets are only consumed in the Process, which Assets are only created be the process, and which ones are altered (used as Inputs and as Outputs by the Process)
Second improvement I seek
I would love to be able to create automatically a “Life Cycle” for each one of the Asset.
These notes would have a Dataview code to gather three types of linked Processes :
- The only Proces that create the Asset : meaning that the Asset is only in the Process’ Outputs, but not in the Inputs (there should be only one, the Creator)
- All processes (#Process tag Notes) that alter the Asset (#InputOrOutput tag Notes) : meaning that these Processes are using the Asset as an Input and as an Output
- Finally, if there is any, the only or all the Processes that use the Asset as an Input but are not having it as an Output : meaning, the Asset is ending (partially) its life there
I feel like the first exercise is similar to the second and that having the answer to one will definitely helps me with the other. I also feel like there is probably something around the use of FLATTEN somewhere, but I just do not know where to start.
I acknowledge that this is a big job. I someone is ready to help based solely on what I have written or prefer to discuss on a vocal chat in order to get me started, I would be eternally grateful. 