Effort versioning

I have always had an affinity for organization. I love well-structured documents that reveal valuable information before I have even read a single word. Complimentary fonts and sizes corresponding to header titles, neat indentation signifying well-thought-out hierarchies, and proper usage of ordered lists all excite me. I wish extras like numbered lines were used outside of legal texts and have tried my hardest to push such conventions in even the most rudimentary of documents. A casual observer of documents I have authored would think that all are of a legal nature. One day as I was organizing my team’s efforts, I realized that while some things I versioned, others I did not. Product releases were clearly versioned, and so were the documents we used in internal policies or advertising campaigns. But the campaigns themselves were not versioned. Neither were our individual, team, department, or company goals. They may have been included in documents that were themselves versioned, but the content of the goals themselves was not. So while we were applying versioning consistently between all software and document increments, we were not applying it to all our top-level efforts for which these documents were created. That led to a realization: why not version everything? Version 1.0 of our relationship with a contractor might comprise signing 4 different documents, each with their own version. Version 1.1 might include a small addition to our operating agreement with that same contractor. Our company updates our goals regularly. Why not version every single increment the same way we do with software? Everything can be versioned, from the smallest task, to the largest corporate obligation. The moment something changes, a version increment takes place. Our support agreements with our clients can easily be versioned when something changes. Then we can maintain a change log for every object, relationship, and goal. We would call this effort versioning because effort is the common denominator in anything that could be versioned. The powerful thing about versioning is that we can always confirm we are on the same page with the various contributors, subscribers, and members of an effort. Contractual agreements become clear to everyone. But perhaps more importantly, all our work moves forward constantly in measured, incremental releases rather than continuous changes. Without a release and version structure, we often finagle with documents and deliverables endlessly, never releasing anything of value. Everything remains permanently “WIP” or in “beta”. Effort versioning allows us to always have a current and complete release, while also continuing to improve and develop upcoming releases. With some reorganization, we found that everything worked better. Our tools themselves support effort versioning. It is easier to package up any piece of work as a version of that effort, and once our team has completed it, archive it and begin planning for the next iteration. Each new version has a task queue, in progress, and backlog, a common work structure supported by virtually all modern work and planning tools. After implementing effort versioning organization-wide, we think of all our work in terms of versions. Agreements are solidified as scope, acceptance is captured with timestamps, and nice-to-haves are backlogged. The current stable version is known, meanwhile, we are constantly working toward the next build. Effort versioning allows us to break down every single possible work into the same set of roles, operations, and flows. It isn’t just software that can make use of versioning: all types and varieties of work have the exact same roles, with tweaks for rules. Versioning is the linchpin of a universal workflow. …