Question was…
“Describe a situation in your professional or personal life when recursion, or at least the principle of recursion, played a role in accomplishing a task, such as a large chore that could be decomposed into smaller chunks that were easier to handle separately, but still had the semblance of the overall task.
Did you track the completion of this task in any way to ensure that no pieces were left undone, much like an algorithm keeps placeholders to trace a way back from a recursive trajectory?
If so, how did you do it? If not, why did you not?”
There’s ALWAYS math at the core? “The Universal Language” they call it
And my answer, was…
Work
Breakdown
Structure
(Finally!)
WBS’s are what many of you have already put out there; i.e. at a large Corporate Customer of mine, I participated in large rollout, slated for about two years – yet, as they were somewhat similar in nature, given that the ‘target’ audience was always the same (Branches, Regional Offices, and Corporate) they were all ‘tagged’ under the exact same project number.
That it’d later mushroom into filling out a whole wing/building with a call center, trainers, engineers, contractors for the phone system, etc. did NOT matter – it was all ONE project
That’s the PMBOK (Project Management Book of Knowledge) way to ‘describe’ not only the breaking-down of the actual tasks (and the actuarials that ensue, as for example, we had a whole team dealing their way of naming an Exception Process, where a 600+ step technical hardware installation manual had to stop due to technical incompatibilities that required a VERY human interface to negotiate with multiple stakeholders, work on assessing impact and even ROI (Return on Investment) as the overall relationship between Branches and Corporate somehow echoed that of Franchisors and Franchisees, giving Franchisees a lot of latitude in Capital Investitures like these, etc…)
Anyway…. that’s the anecdotal: Theoretically, then…
https://www.workbreakdownstructure.com/work-breakdown-structure-according-to-pmbok.php
(Does that NOT look like a fractal?… I mean, a graph from the textbook?)
Relevant excerpt?
“According to the Project Management Body of Knowledge (PMBOK®), and the Practice Standard for Work Breakdown Structures – Second Edition from the Project Management Institute (PMI), the work breakdown structure can be used to effectively decompose the project scope, to improve estimating, to better control the project execution and to more accurately verify project completion. In addition, using a work breakdown structure approach summarizes project information to improve the opportunity for use of historical information, which, can aid in both speed and accuracy of future projects. The work breakdown structure is a repeatable process that can be used as a template for future projects.” (PMBOK, 2013)
Hence, the ‘recursiveness’ of these projects – which as mirrored by my Customer’s experience, where they were able to ‘boilerplate’ these projects/rollouts, onto something that’s somewhat repeatable – yet mold it to fit the scope and constraints, and above, all, the budget of each – which as I mentioned earlier, had a lot do to with the way the entire structure was legally incorporated, as those were the boundaries, that much like a ‘Demarc’ (anyone who’s been in telco – telecommunications – knows that’s the lingo for “rat’s-nest-filled-with-a-gajillion-bits-of-twisted-pair-and-orange-tags-that-only-a-tech-can-decipher”) = ‘Demarcation Point’
So yes, how does ‘recursiveness’ extend to the real world?… look around!… any Franchise/Branch of a nationwide or regional entity, most likely, there are processes that a Project Manager oversees – and tickles, tackles and otherwise shapes to fit the needs and budgets allowed to move ‘forward’ – in a remarkable fashion, when one considers that the endpoints at said Customer’s project? about a quarter million, ONLY at the Branch/Franchise levels!
Now, since it was asked as to ‘how’ it was tracked, a bit more on the ‘what’ is being tracked?
“A work breakdown structure is deliverable-oriented. So what is a deliverable? In a word, it can best be described as a noun. What is the difference between “write xyz specifications” and “xyz specifications”? One describes the end product and the other describes a single step to produce it. The end product is described as a noun without a verb. A deliverable can be delegated to a team or leader who can then be responsible for the work product and complete work should be returned when complete. A work breakdown structure is complete when all of the deliverables necessary to obtain the project goals are identified.
A work breakdown structure is a hierarchy. That means that deliverables can be further decomposed into parent and child relationships. In this case “xyz specification” may be further decomposed into “xyz functional specifications” and “xyz performance specifications”. It is important that if decomposing the deliverable that the lower child decomposition represents 100% of the parent. This is similar to how we learned to outline our writing in our freshman English class. We can continue decomposing the deliverables until we feel comfortable that we have defined in a way that we can effectively manage and control the project.
Simply put the work breakdown structure technique divides projects into smaller more manageable chunks that can be more easily estimated and controlled. It gives a black and white version of the work effort needed and almost as important if the work is not in the work breakdown structure it is not a part of the project. The work should be decomposed until it is clear to teams performing the work. This provides a clear line of sight between the work and the goals for the project.” (ibid)
I’ll wrap up this paste up with a word on an app many cannot live without (per above, as you can see, PMBOK applies to MANY disciplines – not only I.T.)
http://office.microsoft.com/en-us/project-help/create-work-breakdown-structure-wbs-codes-HA010156785.aspx
Relevant excerpt:
“Outline numbers
Outline numbers are the simplest type of WBS coding. Microsoft Office Project automatically calculates an outline number for each task, basing the numbering on the outline structure of the task list. For example, the first task in your task list is numbered 1. If that task has three subtasks, the subtasks are numbered 1.1, 1.2, and 1.3.
Outline numbers consist of numbers only (no letters), and you cannot edit them. They do, however, change automatically when you move a task up or down in the task list and when you indent or outdent tasks. For example, if a subtask currently has an outline number of 3.5.4, and if you move it up one row in the list, the outline number is automatically updated to 3.5.3. If you then outdent that same subtask, the outline number is automatically updated to 3.6.” (Microsoft.Com, 2013)
So I guess Indices and other typographical artifacts, again, straddle that boundary of logic and usefulness?
@Kankuchito on Twitter/Instagram/Tumblr & Pinterest
@Kankuchito's Blog 
You must be logged in to post a comment.