Archive
Functional Allocation VI
Every big system, multi-level, “allocation” process (like the one shown below) assumes that the process is initialized and kicked-off with a complete, consistent, and unambiguous set of customer-supplied “shalls”. These “shalls” need to be “shallocated” by a person or persons to an associated aggregate set of future product functions and/or features that will solve, or at least ameliorate, the customer’s problem. In my experience, a documented set of “shalls” is always provided with a contract, but the organization, consistency, completeness, and understandability of these customer level requirements often leaves much to be desired.
The figure below represents a hypothetical requirements mess. The mess might have been caused by “specification by committee”, where a bunch of people just haphazardly tossed “shalls” into the bucket according to different personal agendas and disparate perceptions of the problem to be solved.
Given a fragmented and incoherent “mess”, what should be done next? Should one proceed directly to the Shall-To-Function (STF) process step? One alternative strategy, the performance of an intermediate step called Classify And Group (CAG), is shown below. CAG is also known as the more vague phrase; “requirements scrubbing”. As shown below, the intent is to remove as much ambiguity and inconsistency as possible by: 1) intelligently grouping the “shalls” into classification categories; 2) restructuring the result into a more usable artifact for the next downstream STF allocation step in the process.
The figure below shows the position of the (usually “hidden” and unaccounted for) CAG process within the allocation tree. Notice the connection between the CAG and the customer. The purpose of that interface is so that the customer can clarify meaning and intent to the person or persons performing the CAG work. If the people performing the CAG work aren’t allowed, or can’t obtain, access to the customer group that produced the initial set of “shalls”, then all may be lost right out of the gate. Misunderstandings and ambiguities will be propagated downstream and end up embedded in the fabric of the product. Bummer city.
Once the CAG effort is completed (after several iterations involving the customer(s) of course), the first allocation activity, Shall-To-Function (STF), can then be effectively performed. The figure below shows the initial state of two different approaches prior to commencement of the STF activity. In the top portion of the figure, CAG was performed prior to starting the STF. In the bottom portion, CAG was not performed. Which approach has a better chance of downstream success? Does your company’s formal product development process explicitly call out and describe a CAG step? Should it?
Functional Allocation V
Holy cow! We’re up to the fifth boring blarticle that delves into the mysterious nature of “Functional Allocation”. Let’s start here with the hypothetical 6 level allocation reference tree that was presented earlier.
Assume that our company is smart enough to define and standardize a reference tree like this one in their formal process documentation. Now, let’s assume that our company has been contracted to develop a Large And Complex (LAC) software-intensive system. My fuzzy and un-rigorous definition of large and complex is:
“The product has, (or will have after it’s built) lots of parts, many different kinds of parts, lots of internal and external interfaces, and lots of different types of interfaces”.
The figure below shows a partial result of step one in the multi-level process; the Shall-To-Feature (STF) allocation process. Given a set of 5 customer-supplied abstract “shalls”, someone has made the design decisions that led to the identification and definition of 3 less-abstract features that the product must provide in order to satisfy the customer shalls.We’ve started the movement from the abstract to the less abstract.
Just imagine what the model below would look like in the case where we had 100s of shalls to wrestle with. How could anyone possibly conclude up front that the set of shalls have been completely covered by the feature set? At this stage of the game, I assert that you can’t. You have to make a commitment and move on. In all likelihood, the initial STF allocation result won’t work. Thus, if your process doesn’t explicitly include the concept of “iterating on mistakes made and on new knowledge gained” as the product development process lurches forward, you’ll get what you deserve.
Note that in the simple example above, there is no clean and proper one-to-one STF mapping and there are 2 cross-cutting “shalls”. Also, note that there is no logical rule or mathematical formula grounded in physics that enables a shallocator (robot or human) to mechanically compute an “optimum” feature set and perform the corresponding STF allocation. It’s abstract stuff, and different qualified people will come up with different designs. Management, take heed of that fact.
So, given the initial finished STF allocation output (recorded and made accessible and visible for others to evaluate, of course) how was it arrived at? Could the effort be codified in a step-by-step Standard Operating Procedure (SOP) so that it can be classified as “repeatable and predictable”? I say no, regardless of what bureaucrats and process managers who’ve never done it themselves think. What about you, what do you think?
Amazappos.com
This morning, I stumbled upon a New York Times article announcing that purchase of Zappos.com by the behemoth that is Amazon.com (I’ve owned shares in Amazon.com for over 10 years). From the article:
- “Amazon initially sought to pay cash, but Zappos asked for an all-stock deal, this person said.The extra cash and restricted stock for employees is meant to keep them on board and preserve the company’s culture, the person said. The deal is expected to close in the fall.”
- “Zappos appears to engender friendly feelings even among some of its smaller competitors. Korey Buzzell, who runs the independent site Shoe-Store.net, said Zappos had been an amicable competitor in the past, sending customers to his site when it could not fulfill their orders.”
Since (because of its totally unique and far out culture) Zappos is currently my favorite company to externally watch and follow, I was initially bummed. However after reading Zappos CEO Tony Hsieh’s down-to-earth, understandable, and jargon-less letter to employees, I’m actually excited about the future potential of Amazappos.com.
Here are some snippets from Hsieh’s letter that rang my bell and changed my feelings toward the deal. Notice how many times the word “culture” is used.
- “For Zappos, our vision remains the same: delivering happiness to customers, employees, and vendors. We just want to get there faster.”
- “Amazon supports us in continuing to grow our vision as an independent entity, under the Zappos brand and with our unique culture.“
- “Our culture at Zappos is unique and always evolving and changing, because one of our core values is to Embrace and Drive Change. What happens to our culture is up to us, which has always been true. Just like before, we are in control of our destiny and how our culture evolves.“
- “They are not looking to have their folks come in and run Zappos unless we ask them to. That being said, they have a lot of experience and expertise in a lot of areas, so we’re very excited about the opportunities to tap into their knowledge, expertise, and resources, especially on the technology side.“
- “We learned that they truly wanted us to continue to build the Zappos brand and continue to build the Zappos culture in our own unique way. I think “unique” was their way of saying “fun and a little weird.” 🙂 “
- “Amazon focuses on low prices, vast selection and convenience to make their customers happy, while Zappos does it through developing relationships, creating personal emotional connections, and delivering high touch (“WOW”) customer service.“
- “Jeff Bezos (CEO of Amazon) made it clear that he had a great deal of respect for our culture and that Amazon would look to protect it.“
- “Our mission remains the same: delivering happiness to all of our stakeholders, including our employees, our customers, and our vendors.“
- “We do not have any plans to move any departments, nor does Amazon want us to because they recognize that our culture is what makes the Zappos brand special.”
- “This is not a cash transaction. This is a stock exchange. Our shareholders and option holders will be issued approximately 10 million Amazon shares on a fully converted basis.“
I was also stunned by the disclosure that Zappos.com, which grew into a $1B company over 10 years selling a commodity product – shoes, only has (had?) 100 shareholders. I wish I was one, but now I am!
BTW, Hsieh’s e-letter has a really great video of Amazon CEO Jeff Bezos’ intro to Zappos employees embedded within it. He describes his values, and more interestingly, how Amazon got started. He also unembarassingly and openly shares some of the stupid mistakes that he made in piloting Amazon to where it is today.
Functional Allocation IV
Part IV is a continuation of our discussion regarding the often misunderstood and ill-defined process of “functional allocation”. In this part we’ll, explore the nature of the “shallocation” task, some daunting organizational obstacles to its successful completion, and the dependency of quality of output on the specific persons assigned (or allocated?) to the task.
If you can find one, the process description of functional allocation starts out assuming that a human allocator is given a linear text list, which maybe quite large, of “shalls” supplied by an external customer or internal customer advocate. Of course, these “shalls” are also assumed to be unambiguous, consistent, non-contradictory, complete, and intelligently organized (yeah, right).
My personal experience has been that the “shalls” are usually strewn all over the place and the artifact that holds them is severely lacking in what Fred Brooks called “conceptual integrity”. Sometimes, the “shalls” seem to randomly jump back and forth from high level abstractions down to physical properties – a mixed mess hacked together by a group of individuals with different agendas. In addition, some customers (especially government bureaucracies) often impose some overconstraining “shalls” on the structure of the development team and the processes that the team is required to use during the development of the solution to their problem (control freaks). Even worse, in order to project a false image of “we know what we’re doing” infallibility and the fact that they don’t have to do the hard value-creation work themselves, helpful managers of developer orgs often discourage, or downright prevent, clarification questions from being asked of the customer by development team members. All communciations must be filtered through the “proper” chain of command, regardless of how long it takes or whether technical questions get filtered and distorted to incomprehensibilty through non-technical wonks with a fancy title. Bummer.
Because we want to move forward with this discussion, assume the unassume-able; the customer “shall” list is perfectly complete and understood by the developer org’s system engineers. What’s next? The figure below shows the “initialization” state. The perfect list of “shalls” must be shallocated to a set of non-existent product functions. Someone, somehow, has got to conceive of and define the set of functions and the logical inter-function connectivity that will satisfy the perfectly clear and complete “shalls” list.
Piece of cake, right? The task of shallocation is so easy and well described by many others (yeah, right), that I won’t even waste any e-space giving the step by step recipe for it. The figure below shows the logical functional structure of the product after the trivial shallocation process is completed by a robot or an expensive automated software tool.
Realistically, in today’s world the shallocation process can’t be automated away, and it’s highly person-specific. As the example in the figure below shows, given the same set of “shalls”, two different people will, “after a miracle occurs”, likely conjure up a different set of functions in an attempt to meet the customer’s product requirements. Not only can the number of functions, and the internal nature of each function be different, the allocation of shalls-to-functions may be different. Expecting a pristine, one-to-one shall-to-function mapping is unrealistically utopian.
What the example below doesn’t show is the person-specific creation of the inter-function logical connectivity (see the right portion of the previous figure) that is required for the product system to “work”. After all, a set of unconnected functions, much like a heap of car parts, doesn’t do anything but sit there looking sophisticated. It’s the interactions between the functions during operation that give a product it’s power to maybe, just maybe, solve a customer’s problem.
The purpose of part IV in this seemingly endless series of blarticles on “functional allocation” was to basically point out the person-specific nature of the first step in a multi-level nested allocation process. It also hinted at some obstacles that conspire to thwart the effective performance of the task of shallocation.
Functional Allocation II
Assume that you’re lucky and your company has a standard, generic product breakdown structure as follows:
- Product
- Functions
- Subsystems
- Configuration Items (Hardware and Software modules)
In order to achieve business success, an operating product needs to perform the functions that a user needs or wants for some reason. The functions are implemented by the number of, and interconnections between, the product subsystems. The subsystems are comprised of the hardware and software modules that animate the product.
Depending on the complexity of the new product that is required to be developed, between one and three “allocation” paths from concept to product can be pursued. The figure below shows these paths.
If the problem that the product is required to control or solve is simple, the relatively short bottom path can be selected. If the finished aggregation of CIs do their intended job of seamlessly and elegantly supplying users with the functionality that they want/need, then the product will, in all likelihood, be successful. Profits will flow and customers will be happy. Classic win-win.
If the problem is complex, then the top path should be followed. Consciously or unconsciously pursuing the bottom path for complex products can, and usually is, disasterous. At best, money will be lost. At worst, people can die as a result of the end product’s failure to do what it was intended to do. Even if the top path is correctly chosen, failure to execute the process effectively can produce the same result as choosing the wrong bottom path. For success, the product and the “allocation” process must match. Success won’t be guaranteed, but the likelihood of success will increase.
So, what can cause a business failure even when the product and process are correctly matched at the outset? The list of reasons is long. Here are just a few that come to mind:
- Technical incompetence
- Managerial incompetence
- Massive external or internal schedule pressure that leads to corner-cutting
- Inter and/or intra-group rivalries naturally encouraged by hierarchically structured organizations of rank and privilege.
- An unfair reward system
- An obsession with following a rigid, micro-prescribed process to the letter of the law (dotting all the i’s and crossing all the t’s)
In summary, a product-process mismatch virtually guarantees long term business failure, but a product-process match may, just may, result in business success. The odds seem to be stacked in favor of failure. Bummer.
Functional Allocation I
Some system engineering process descriptions talk about “Functional Allocation” as being one of the activities that is performed during product development. So, what is “Functional Allocation”? Is it the allocation of a set of interrelated functions to a set of “something else”? Is it the allocation of a set of “something else” to a set of function(s)? Is it both? Is it done once, or is it done multiple times, progressing down a ladder of decreasing abstraction until the final allocation iteration is from something abstract to something concrete and physically measurable?
I hate the word “allocation”. I prefer the word “design” because that’s what the activity really is. Given a specific set of items at one level of abstraction, the “allocator” must create a new set of items at the next lower level of abstraction. That seems like design to me, doesn’t it? Depending on the nature and complexity of the product under development, conjuring up the next lower level set of items may be very difficult. The “allocator” has an infinite set of items to consciously choose from and purposefully interconnect. “Allocation” implies a bland, mechanistic, and deterministic procedure of apportioning one set of given items to another different set of given items. However, in real life only one set of items is “given” and the other set must be concocted out of nowhere.
The figure below shows four different types of functional allocations: shalls-to-functions, features-to-functions, functions-to-modules, and functions-to-subsystems. Each allocation example has a set of functions involved. In the first two examples, the set of functions have been allocated “to”, and in the last two examples, the set of functions have been allocated “from”.
So, again I ask, what is functional allocation? To managers who love to remove people from the loop and automate every activity they possibly can to reduce costs, can human beings ever be removed from the process of functional allocation? If you said no, then what can you do to help make the process of allocation more efficient?
Productivity Lag II
In part I, we saw that the learning curve for each person is different (duhhh). I also defined the Critical Mass Time (CMT) to be the time lag between starting a new project and actually being able to “start contributing something useful”. The figure below recaps this idea.
Other factors, besides experience and expertise, that determine the CMT value are: the amount of, the quality of, and accessibilty of pre-existing information about the problem to be solved. If the information is sparse, fragmented, and/or inefficiently stored in other people’s fallible memories (tribal knowledge) because of the failure of management to lead, then the CMT will be larger than if the critical-to-success information is coherent, integrated, and recorded somewhere that is easily navigable and accessible.
At the CMT point, productivity starts manifesting in the physical world as visible intermediate work outputs. Product specifications, designs, test definitions, equipment assembly, prototyping, model definitions, etc., begin to emerge and push the project forward. Like any activity that is predicated on fallible human thought, the creation process is iterative and chaotic. It is not smooth and organized as the final output may imply to an after-the-fact external observer (like most managers). It takes iterative, mistake-prone work and structure to temporarily harness the ever present increase in entropy.
The figure below shows the full time lag between project start and project completion. Again, the time lag ‘tween CMT and project “done” is highly person-specific.
The figure below shows the end-to-end project start time to project done time for three different people that were given the same project task to perform. The difference between the total “schedule” performance of person 3 and person 2 is the case we want to zoom in on. How could it be that person 2 ramped up faster than person 3 but finished the project later? WTF?
Some reasons that may explain this anomaly are:
- Person 3 had a hard time finding and absorbing high quality, pre-existing information about the project and task at hand.
- Person 3 is slower at learning, but more talented at applying.
- Person 2 lost some motivation for one or more reasons and slacked off somewhat
- Person 3 rushed through the task and produced crappy output that may not be discovered until the project is further downstream; where the cause might not be connectable to the person’s output.
I’m sure that there are a gazillion other factors that may explain the anomaly. You can form your own list.
The main point of this article was to discuss what everyone knows, but often forgets: Numbers don’t always tell the truth. Superficially looking at hard and cold “schedule performance” numbers without digging in to examine their validity can be unfair to those who are quantitatively measured for personal performance evaluation by hierarchs. Lazy bozo managers who do this deserve what they get: the exodus of some of their best performers, an unmotivated workforce, a low quality product portfolio, and an unfair reward system. In essence, it’s one of the hallmark characteristics of the herd of mediocracies that cover the landscape of the business community.
Productivity Lag I
Each person naturally has a different learning curve. When an engineer is assigned a new task to perform on a new technical project, there will be a lag in productivity because, well, it’s new to him/her. The person needs time to learn and understand the context surrounding the project and the details of the problem to be solved. Since each person is different, each person will have a different time-to-productivity, or Critical Mass Time (CMT). The graphic below shows a typical learning curve for a specific person. The slope increases with time because as new learning occurs, it feeds on itself and the acquisition of knowledge gets easier.
The CMT is a physically underive-able function of the experience and expertise (two independent qualities) of a person. It is also a function of the area of overlap between those two attributes and the novelty/depth of the problem to be solved. As the figure below shows, the person-specific CMT is at its minimum when there is 100% overlap. Note that if there is no overlap, the CMT is essentially infinity. This sad state can happen, for example, if a Radio Frequency circuit designer is assigned the task of designing and writing product software, or a plumber is assigned to perform brain surgery, or an enterprise IT software engineer is assigned the task of writing embedded signal processing software. It’s easy to find other examples of total mismatch.
Assuming that the experience and expertise of each person in a group of people overlaps somewhat with the project task that needs to be performed (no cases where CMT = infinity), the graphic below shows how CMT differences within the group can vary radically. Obviously, if you were a manager, you’d like to have Person 1 working the problem.
So what happens when an executive manager or marketer commits the company to a scheduled project completion date without knowing the learning curves of his/her people, or the difficulty of the problem to be solved? As the figure below shows, blown schedules occur. Before (and after) the schedule is missed, increasing pressure-to-complete is continuously exerted by management, mistrust grows, and the employee-management relationship suffers. Of course, since management is (at least) one level removed from the action and they don’t have to perform the task themselves, they are blameless. Because of the FAE, the employee, of course, is fully at fault and a “performance improvement” plan may be in order. If an employee ruffles feathers and dares to publicly point out the mismatch, accusations of “not being a team player“, “malcontent“, and/or “bad attitude” are the thanks he/she gets. If the employee persists, the ostracism may be followed by a stronger message to STFU – a required trip to “people-skills school“.
This pattern of dysfunctional behavior occurs so often in hierarchical corpos across the land that it is taken for granted and it is “undiscussable“. It is also one of the reasons why people do everything they can to get out of the pig sty and climb the corpo ladder to succes. The further away from the action you move, the higher the chance that you’ll be sanctioned by the big boys(gals) to convert from a pressure-receiver into a pressure-exerter. As an added bonus, you’ll make more money because of your “increased responsibilities” (sic).
Clanthink, Groupthink, Spreadthink
Everyone has heard of the term “groupthink“. However, have you ever heard of the terms “clanthink” or “spreadthink” applied to a group of people? John Warfield, a prolific systems thinker who’s been ignored for decades by the mainstream, defines these three types of psychological phenomena as follows:
Clanthink = Everyone in the group believes in the idea/concept, but it’s outright wrong. Those outside of the group that don’t believe the idea/concept are ostracized, tortured, killed……. or all of the above.
Groupthink = Everyone believes in the idea/concept, but tantalizingly, it could be either wrong or right. If the group is wrong and all of the the individuals outside of the groupthink circle of membership remain steadfastly silent out of fear of persecution, then the group, and those that that they lead, all suffer.
Spreadthink = Everyone in the group places a different level of importance and meaning on the idea/concept.
Classic clanthink examples are: 1) the massive group of flat-earthers back in Columbus’ time; 2) the church-brainwashed, sun-revolves-around-the-earth-because-humans-are-the-center-of-the-universe gang back in the Galileo era. Can you think of others, besides whack jobs like: Hitler’s inner circle, Enron executives, George W. Bush WMD disciples, the Moonies, scientologists?
Groupthink is a weaker, but much more common form of clanthink. The cult size is much smaller, but there are many more groupthink groups than clanthink groups, especially in the business domain. Just about every organization in the world is infected with groupthink to some extent because they are hierarchically structured. Hierarchically structured pyramids of rank, privilege, and I’m-smarter-than-you step-ladder-idiots are especially rife with the stank of groupthink. The higher up you go, the more groupthinkage there is. Why? Because (almost) everyone wants to get to the head shed in order to acquire the material riches and titles that hierarchs sprinkle upon themselves. Thus, the exclusive club members: 1) unconsciously accept whatever idea/concept/method the next hierarch above them espouses, 2) kiss ass, and 3) say “yes massa” in order to facilitate their next step up the gold plated ladder of privilege.
In my mind, spreadthink is the most interesting concept in Warfield’s trio. Each person is, duhhhh, an individual. Thus, each person will naturally have an internally created, different opinion on any given issue. In environments that facilitate/enable/catalyze the public externalization of each individual person’s true thoughts and opinions, spreadthink will naturally emerge. In such a situation, assuming that the group has an a-priori agreement on how to make and execute a decision, the “best” course of action may be achieved. Hierarchies, by the physical and meta-physical shackles that the pyramidal structural pattern imposes on their members, are anathema to the diversity of spreadthink. Bummer, cuz the corpo pyramid, an unnatural structure of human creation, hubris, and self-aggrandizement, isn’t gonna go away soon.
Hierarchy will never go away. Never. – Tom Peters
Thinking Your Way To Enlightenment
Virtually every spiritual teacher that I know has stated that you can’t “think” your way to enlightenment. I consider myself a heavy thinkaholic and because of my personal experience I know that they’re right. I’ve tried to think my way into an enlightened and awakened state so hard, so many times, that the effort has led to the exact opposite result of what I intended. Reading, viewing, and listening to spiritual material can get you to the bus stop of awakening, but it doesn’t guarantee that the bus will arrive on time. It doesn’t even guarantee that the bus will arrive at all.
So, what’s a thinkaholic who wants to discover his/her true root of being supposed to do? You can’t stop thinking because, like flying is innate to birds, thinking is innate to the human condition. Thus, I’m stuck in an endless repetitive cycle of gathering more and more thought-based spiritual knowledge even though I know that it doesn’t work.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 