Sacred geometry are mathematical visualizations of life's complexity. They are undeniable formulas that mirror nature and are most commonly seen in the formation of seashells, plants and trees.
This is my first time documenting on the idea of using sacred geometry as a basis for documentation practices. This is a currently my theoretical adaptation using Sierpinski's Tree fractal that branches into two equal halves. Later this fractal can be transitioned into Sierpinski's Triangle. The reason I felt this fractal was an ideal framework for documentation is the ease that it fits into Project Management's Iron Triangle, where the categories of Resources, Money and Time are made into the three points of scope.
I will split this blog post into the good the bad and the ugly of documentation frameworks and how using fractals can improve everyone's lives.
The Good of documentation frameworks
There's no getting around documentation frameworks in product development and multiple disciplines have been created to make sure company information is secure, accessible, and lives on a predictable lifecycle.
How does using a fractal make documentation frameworks better? Put into practice, using a fractal format should do a lot to alleviate much of the chaos that occurs within the discipline of project and record management.
Improve hierarchical organization
Standardize relevance
Optimize efficiency
Enable auditing
Improves overall development maturity
The root of the documentation begins with the portfolio and branches off between resources and money. This creates the clear structure between Project Management and Finance. My personal experience has shown that Product Owners and Project Managers who aren't intimately tied to collaborating with the Finance team quickly lose control of their budget envelopes and fall into danger of mismanaging the value they bring to the company. This creates very awkward executive meetings where the stakeholder has to explain how money was used successfully for the company, and if their documentation is a mess, it erodes confidence.
As the tree splits and splits again the branches become more time specific. This is because the element of Time is introduced as metadata to track projects while retaining the unique identity of the branch roots. By standardizing the element of time, the relevance of projects can be easily filtered since it appears on the same branch level with other projects.
In this example, I would use Atlassian's Jira and Confluence applications. Confluence would form the basis of documentation for this framework while Jira's project tracking would be the sap that flows through the branches.
The Bad of Documentation Frameworks
What does your company's documentation framework look like? Chances are the larger the company grows at scale the more difficult it becomes to keep track of files. Such as document relevance, relationships and ownership become obscured. This is made worse during mergers, sunsets and staff leaving positions.
By using the Portfolio as the root of the tree it becomes easier to track activity and branches can be cut or at the very least earmarked for restrictions on further editing.
The Ugly of Documentation Frameworks
The most dangerous aspect of mismanaged documentation isn't the difficulty of searching for files or mismanaged growth, but the ease of losing control of sensitive information that could put the company at risk of legal action.
By using Sierpinski's tree fractal with the inherit hierarchical structure in Confluence, this fear of losing control of sensitive information can be diminished. Confluence's admin controls for controlling exclusivity is simplified, because if the root branch is made "restricted" this setting is applied to all aspects from that particular root, thus creating gateways of security.
Another feature is automating the archiving of select pages after a specified time or date. Working in conjunction with the legal team, this would greatly improve the company's protection of harmful or sensitive data.
In Conclusion
Using Sierpinksi's Tree and Triangle provides a solid basis of logic in splitting documentation into an easily understandable format that solves a number of inherit pitfalls that occur from unregulated documentation framework practices. The "roots" and "branches" fall into an easy vernacular form that also improves communication between parties.
Questions for you:
What does your documentation framework look like?
What are the best and worst aspects of your documentation?
If you had a magic wand what would you add or take away from your current documentation framework?
Was this blog article useful or interesting and why?
Note: First image taken from https://coefs.charlotte.edu/ksmit351/fractals/
Comments