Archive
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?
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).
Schedule Policy
Just about every corpo mediocracy in the world has a proverbial “Quality Policy” that it proudly displays all over the place. The inspirational words of wisdom, that hierarchs profess staunch adherence to, are inscribed on framed posters, and/or cute little magnetic sheets. These false idols are distributed far and wide within the cathedral walls for everyone to worship.
However, everyone down in the boiler room knows that the true corpo allegiance is to schedule. How do the serfs know this? It’s easy, and it doesn’t require an Einsteinian intellect to figure it out. Just walk around the cubicle farm and count the number of times you hear managers mention the word “quality”. Then count the number of times that you hear “schedule”. Voila, you then have your answer, and it doesn’t involve rocket science math. Companies that have higher schedule to quality ratios are much more likely to fill the ranks of the average and boring herd.
Schedule worship, at whatever the human and organizational cost, is one of those issues that Chris Argyris calls “undiscussable”. Anyone who points out the fact that the quality policy is actually a lame attempt to camouflage the true and unconditional allegiance to schedule, gets beheaded in true shoot-the-messenger form. Nobody in their right mind “discusses” the quality versus schedule irony because, well, it’s “undiscussable”. 🙂
I propose that all companies develop, distribute, and display their very own authentic schedule policy. One could go something like this:
“The Duefiss corporation is proudly dedicated to meeting schedule. Our allegiance is unconditional. At Duefiss Inc., we will aggressively cut every corner and apply any amount of pressure to our human resources to meet any schedule. It doesn’t matter how laughable or unrealistic any given schedule is. We will commit our minions to it, no matter what the consequences to them, their families, our product quality, or our long term credibility and profitability. When we fall behind the hallowed schedule, we guarantee to turn up the heat on those responsible for the slip, and increase the frequency of status meetings to reinforce our commitment.”
What would your schedule policy be?
Bozo Planning
Why is it that big government and big industry continue to cling to an archaic planning method that clearly doesn’t work. History has repeatedly shown that the Big, One Time Planning (BOTP) method is rapidly becoming more obsolete as the pace of change accelerates. The top half of the figure below shows what has been, and continues to be done for Big, Complex, Multi-technology, Product (BCMP) development jobs.
By definition, BCMPs are hairballs that no one fully understands at the outset. As time ticks forward and the effort progresses, learning naturally occurs and new knowledge is discovered and accumulated. This new found knowledge validates the invalidity of the golden BOTP plan. Strangely but surely, as THEE plan becomes more disconnected from reality, no one says or does anything until the mismatch gets in your face. Driven by fear, no one wants to be the first one to step up and announce that the emperor needs a new wardrobe. Eventually, shoddy work and buggy, failure prone components become visible and impossible to ignore. Finger pointing and defensiveness take over. It’s sick city until the crap gets delivered or the whole shebang is canceled in a highly publicized hatefest.
The bottom of the figure shows an alternative to the toxic BOTP method. It’s called: Planning To Continuously Replan (PTCR). In this method, everyone develops a shared understanding at the outset that PTCR will be used to increase (but not guarantee) the chance of project success. In PTCR, replanning is done at necessary points in the effort. How does a project manager know when one of these necessary points in time has occurred? By rolling up his/her sleeves, getting close to the team and, most importantly, personally monitoring the intermediate work products that are being created in real-time. Trust but verify. There’s no distancing and disconnecting from the project like the bozo executors of the BOTP technique do.
It’s my guess that BOTP will continue to be used by vendors and purchasers of BCMPs in the future. Because of the fear of change and the importance of maintaining (a false) image of infallibility, the comfort of the same-old same-old is always preferred to the uncomfort of the new. This, in spite of the ineffectiveness of the same-old same-old. As Mark Twain said: “I love progress, it’s change that I hate”.
Problems, Growth, And Serious Shrinkage
I first encountered the word “problematique” in John Warfield’s book “An Introduction To Systems Science“. A big problem isn’t singular in nature. It is comprised of an intertwined mess of pseudo-individual problems. This hairball produces painful symptoms that are greater than the sum of its parts. Hence, the word “problematique” seems to better convey the seriousness of a big problem.
The figure below shows a general model of a problematique along with its accompanying set of causes and symptoms. Assume that the size of the problematique is not static. Fueled by the unchecked amplification of its set of causes, it grows uncontrollably over time . New symptoms appear and existing symptoms get worse. It’s bummer city.
As an example, assume that some of the nasty symptoms of a hypothetical organization’s problematique are as follows:
-
Dissatisfied customers,
-
Disengaged employees, and
-
Low quality products
Also assume that the problematique’s true (but usually undiscussable) underlying causes are:
-
Shoddy workmanship,
-
Schedule pressure,
-
Management and worker incompetence,
-
Unscalabe and stifling work processes,
-
Useless and unhelpful documentation (a.k.a. camouflage)
Now, assume that in a sincere attempt to control and ameliorate its problematique, the organization designs and implements what it thinks is a problem control system but is really a symptom control system.
Assume that the symptom control system provides the following capabilities:
-
Frequent damage control trips by executives to customer sites to medicate customers.
-
Free upgrade offers,
-
Lower product maintenance prices,
-
Increased schedule pressure on the work force,
-
The imposition of more constraining processes on the work force,
-
The addition of more self-medicating status meetings,
-
The generation of more useless documentation (a.k.a. camouflage squared).
The symptom control system may work for a while, but since the fuel sources haven’t been cut off, the problematique’s growth soooner or later overwhelms the system’s capability to keep the symptoms in check. The chains break and the symptoms reappear. As the problematique continues to grow, new symptoms appear in the form of decreased demand for the organization’s products, decreased revenue, and decreased profits because of rising internal costs.
Next, assume that by the grace of God, the organization awakens and becomes conscious of the true fuel sources that facilitate the problematique’s uncontrolled growth. The organization then designs an effective problematique control system that severs the fuel source connections to the problematique. In order to pull this miracle off, the control system executes the following unconventional behaviors:
-
Increases work force competence through real mentoring and meaningful continuous training.
-
Recognizes and rewards high quality work over heroic crisis response. Merit over conformance.
-
Relieves schedule pressure
-
Streamlines work processes and eliminates obsolete and useless processes.
-
Calls fewer status meetings.
-
Oversees the creation of less, but more useful/helpful, documentation.
Due to the effectiveness of the integrated control system, the problematique experiences “serious shrinkage”. The symptoms are attenuated, or eliminated entirely, and the organization’s health gradually improves.
Sadly, the effort required to design and implement a symptom control system is much easier than the effort required to design and implement a problematique control system.
Product Development Systems
The figure below shows two (out of a possibly infinite number of) product development systems. Which one will produce the higher quality, lower cost product in the shortest time? Would a hybrid system be better?
Arrogant And Self-Righteous
I’m currently working on a really difficult assignment that’s starting to put me into an arrogant and self-righteous mood. My task is to add a customer-demanded feature to our flagship product that requires pervasive change throughout 400,000 lines of legacy embedded C++ code. Our flagship product is a software-intensive, distributed real-time sensor system that’s used to provide safety-critical surveillance information to our customers.
This is actually the third try at getting this task done. The first two attempts by other people fizzled out with nary a whimper. They were in way over their heads and thus, the work that they left behind is useless to me. So here I am, reverse-engineering 100s of thousands of lines of algorithmically deep code to:
- try and figure out what the current code base does
- try and understand why the code does what it does
- determine what changes need to be made to which code sections in order to implement the feature
This task is hard, really hard, but I’m up to it. The work requires long periods of sustained immersion in the code base and the mental absorption and retention of many fragile and diverse associations. Way more than Miller’s famous 7 plus or minus 2 limit of individual human capacity. I’m not getting any deep help and I’ve got two (yes two) managers taking “status” and watching the schedule . Other well-meaning product team members do help out when I ask them, but they just provide tidbits of help here and there. Help from the managers? Fuggedaboud it. It’s not their “job”, and they don’t have the expertise to help out even if they wanted to (which they don’t). Don’t get me wrong. They’re both good people and I like them very much, but they just can’t help, period.
Alas, I feel that I’m virtually all alone on this effort and it’s making me arrogant, self-righteous, and mad. Why’s it making me mad? Because I don’t feel appreciated and I feel that no one, save for one other person, has any idea of the inherent difficulty baked into the project. I look at what I’m doing, compare it with what others around me are doing, and then I ask myself “why did I willingly sign up for this type of work – again“? When the job gets finished, I’ll in all likelihood just get an “atta boy” and the same average raise as everyone else – just as has happened several times in the past. Thank God that I’m internally motivated to grow and learn.
Boo hoo, poor me!
A Rigged System
Based on observation and personal experience, here’s my assessment of how the system nominally executes:
- A customer issues a Request For Proposal (RFP) or a Request For Quote (RFQ) for a product that meets a perceived need.
- The competitors respond with a proposal that contains a solution, a price, and a schedule.
- An organization wins (kudos and high-fives all around)!
- A program team is formed in the winning organization.
- The program team inherits the proposal schedule.
- The proposal is communicated to the product development group (PDG).
- The PDG forms a product development process (PDP) team.
- The PDP team analyzes the proposal and constructs a PDP schedule.
- The PDP team executes the PDP.
- The PDP team performance doesn’t *match* its own schedule OR the original proposal schedule – sometimes by a large amount.
- The customer, the organization, the program team, and the PDP team suffer the consequences.
- Go to step one for the next effort.
The figure below illustrates the nominal system operation, where M = Milestone.
Sometimes, but not always, the developer organization “forgets” the original proposal schedule and, via the magic of cognitive dissonance, praises the PDP team at the end of the effort for being on schedule and under budget. Sometimes, even the customer conveniently “forgets” original proposal schedule, but the customer’s financial sponsor usually doesn’t.
Do you agree with the assessment of the system’s nominal operation? If you agree with it, then consider these follow on questions:
For each of the participants in the system, where do you think the suffering starts?
Do all participants suffer equally? If not, which participant do you think suffers the most?
Is anyone at fault, or are the unintended consequences a byproduct of the system’s behavior?
What management techniques can be employed to drive “the measure of underperformance” to zero, or ideally, to a negative value?
Are there some management techniques that, if applied, will cause greater underperformance?
If you don’t agree with the assessment, then please tell me why, and what your experience has been.
Do you think the cognitive dissonance scenario exists?
If so, have you experienced the cognitive dissonance scenario?
In the cognitive dissonance scenario, even though the outcome is falsely deemed a rousing success, do you think there is any suffering by one or more participant groups during execution?
The Drunkard’s Walk
Assume that your company has a problem that needs to be solved. Management then creates a project and allocates resources: money, time and you, to solve the problem. The figure below shows the context that is established at project start. There’s you, the hairball problem, and a solution somewhere at the end of the project pipeline.
Since the best solution (out of an infinite set of possibilities) is almost always unknown a-priori, the amount of allocated money and time may not be correct. In my experience as a participant in the development and (mostly) maintenance of large, complex real-time embedded software systems, the “budgeted” amount of time and money is usually vastly underestimated. To top things off, management usually thinks that the problem-to-solution path is a linear, forward-only, sequential march to success.
The figure below shows the real drunkard’s walk that is traversed when a non-trivial problem gets solved. The start-to-end signature is person-specific. A prim and proper straight line to the solution through the official corpo process book never occurs. If you’re familiar with the problem domain and have solid experience with other similar problems, then your solution path may be less erratic than the path of others.
In the example above, notice how there are 3 occurrences of vector segments that go backward in time to revisit and correct mistakes. Each decision that you make to go backwards is a result of new knowledge discovery and learning. Sadly, because going backwards is a serious taboo in linear-sequential-think orgs, some people consciously decide to never go back, knowing full well that they’ve left some turds in the road for their followers to step in.
In a high pressure, micro-watched project, publicizing any regression steps to management in real-time is not a smart move. Even though it’s the truth, an unconscious force within you (ego) can cause you to lie and feign forward progress at every status reporting interval. Thus, in your manager’s mind, you’re “on schedule and under budget”. Splendid!
If you’re working on a multi-person project, then everyone else on the team is performing their version of the drunkard’s walk too. At each weekly breathalyzer test (oops! I meant status reporting meeting), everyone tries their damnest to appear sober in order to avoid a DUI .
Happy drinking!
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 