Archive
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?
There Are Lots Of “I”s In A Team
“Sacred Cows Make The Best Hamburger”
Do you ever get tired of hearing the old and worn out management cry: “There’s no I in team!”. In this article, I’d like to challenge that unquestioned assumption.
The left-hand figure in the graphic below depicts a man-made group with a bunch of “I”s thrown together. Since the motto is “it’s every man for himself,” the group shouldn’t really be called a team. It’s more like a heap of individual and unconnected parts. In a heap, the whole is nothing more than the sum of the parts.
The figure in the middle of the graphic represents a group of people instilled with the “there’s no I in team” mentality. In this case, the group is more than the sum of its parts and it’s a much better problem solving structure than a heap of “I”s. However, because of the across-the-board homogeneity and lack of distinction between group members, the solutions produced by a group of “we”s are bland and mediocre, like unflavored oatmeal.
The figure on the right shows the ideal team. It’s composed of people who are motivated to succeed both individually and collectively. Relative to the other two types of groups, the team of “I + We”s is a super performer and it creates innovative solutions to problems. Thus, a high performing team is comprised of lots of “I”s.
Sadly, the vast majority of corpo organizations create hideous hybrid abominations like the one in the figure below. Yuk!
By; repeatedly espousing that “there’s no I in team!” to the doers sub-group; treating all work with the same apathetic reception regardless of relative quality; and punishing individual creativity; managers create and nurture a divided mediocracy. Of course, since they are the chosen ones, managers never follow the rules that they espouse for others. Thus, they are constantly and cleverly competing with their brethren for status and entitlement, operating as “I”s. It’s a good thing that the “we”s actually produce the outputs that allow the organization to survive, even though their products are mediocre and boring as hell.
Who’s Important?
Do you want to know who’s really valued by your organization’s so-called leadership? Just take a look at who’s located physically close to them. Look who’s got the big offices and what they’ve actually done to grow the organization. Look at who gets to go on company junkets. Look at who gets the training dollars. Are they the organization’s value producers, or are they the overhead consumers? Are they members of contracts, finance, marketing, human resources, business development, communications, compliance, or are they the people who create the value that keeps the organization alive: the engineers, the designers, the manufacturers, the integrators, the testers, the customer trainers, the customer support staff? Odds are that the people who directly create the wealth are cloistered in cubicle farms at the “back” or “bottom” of the building and treated as second class citizens. Long live those fossil managers who are stuck in the past and are ignorantly happy to operate by Ford’s , Taylor’s, and Sloane’s rules – regardless of what they say. Clueless dolts.
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!
The UML And The SysML
Introduction
The Unified Modeling Language (UML) and System Modeling Language (SysML) are two industry standard tools (not methodologies) that are used to visually express and communicate system structure and behavior.
The UML was designed by SW-weenies for SW-weenies. Miraculously, three well-known SW methodologists (affectionately called the three amigos) came together in koom-bah-yah fashion and synthesized the UML from their own separate pet modeling notations. Just as surprising is the fact that the three amigos subsequently donated their UML work to the Object Management Group (OMG) for standardization and evolution. Unlike other OMG technologies that were designed by large committees of politicians, the UML was originally created by three well-meaning and dedicated people.
After “seeing the light” and recognizing the power of the UML for specifying/designing large, complex, software-electro-mechanical systems, the system engineering community embraced the UML. But they found some features lacking or missing altogether. Thus, the SysML was born. Being smart enough not to throw the baby out with the bathwater, the system engineering powers-that-be modified and extended the UML in order to create the SysML. The hope was that broad, across-the-board adoption of the SysML-UML toolset pair would enable companies to more efficiently develop large complex multi-technology products.
The MLs are graphics intensive and the “diagram” is the fundamental building block of them both. The most widely used graphics primitives are simple enough to use for quick whiteboard sketching, but they’re also defined rigorously enough (hundreds of pages of detailed OMG specifications) to be “compiled” and checked for syntax and semantic errors – if required and wanted.
The Diagrams
The stacked UML class diagram below shows the structural relationships among the diagrams in the UML and SysML, respectively. The subsequent table lists all the diagrams in the two MLs and it also maps which diagram belongs to which ML.
In the table, the blue, orange and green marked diagrams are closely related but not equal. For instance, the SysML block definition diagram is equivalent too, but replaces the UML class diagram.
Diagrams are created by placing graphics primitives onto a paper or electronic canvas and connecting entities together with associations. Text is also used in the construction of ML diagrams but it plays second fiddle to graphics. Both MLs have subsets of diagrams designed to clearly communicate the required structure(s) of a system and the required behavior(s) of the system.
The main individual star performers in the UML and the SysML are the “class” and (the more generic) “block”, respectively. Closely coupled class or block clusters can be aggregated and abstracted “upwards” into components, packages, and sub-systems, or they can be de-abstracted downwards into sub-classes, parts, and atomic types. A rich palette of line-based connectors can be employed to model various types of static and dynamic associations and relationships between classes and blocks.
A conundrum?
In the pre-ML days of large system specification and design, ad-hoc text and structured analysis/design tools were predominantly used to communicate requirements, architectures, and designs between engineering disciplines. The use of these ad-hoc tools often created large gaps in understanding between the engineering disciplines, especially between systems and software engineers. These misunderstandings led to inefficient and error prone development. The figure below shows how the SysML and UML toolset pair is intended to close this “gap of misunderstanding”.
Minimization of the gap-of-misunderstanding leads to shorter *and* higher quality product development projects. Since the languages are large and feature rich, learning to apply the MLs effectively is not a trivial endeavor. You can’t absorb all the details and learn it overnight.
Cheapskate organizations who trivialize the learning process and don’t invest in their frontline engineering employees will get what they deserve if they mandate ML usage but don’t pay for extensive institution-wide training. Instead of closing the gap-of-misunderstanding, the gap may get larger if the MLs aren’t applied effectively. One could end up with lots of indecipherable documentation that slows development and makes maintenance more of a nightmare than if the MLs were not used at all (the cure is worse than the disease!). Just because plenty of documentation gets created, and it looks pretty, doesn’t guarantee that the initial product development and subsequent maintenance processes will occur seamlessly. Also, as always in any complex product development, good foundational technical documentation cannot replace the value and importance of face-to-face interaction. Having a minimal, but necessary and sufficient document set augments and supplements the efficient exchange of face-to-face tacit communication.
Closing Note: The “gap-of-misunderstanding” is a derivative of W. L. Livingston’s “gulf-of-human-intellect” (GOHI) which can be explored in Livingston’s book “Have Fun At Work”.
Committees
The figure below depicts a “bent” UML class diagram of two types of committees. For those who don’t know UML, I hope that the diagram is sort of self-explanatory.
Mediocracies
As the name implies, a mediocracy is an average form of man-made organization. By definition, the vast majority of private companies are mediocracies, regardless of what top management espouses. Mediocracies are characterized by:
- Uniformity, homogeneity
- Stability (at least in the short term)
- Apathy, no ownership
- Hubris, arrogance, entitlement
- The same raises for everyone, regardless of performance
- Lots of managers and few, if any, leaders
- Stunted, bounded, personal and professional growth
- Fixed, rule-based behavior
- Reliance on improvement of obsolete processes instead of new process creation
- Promotions based on conforming behavior over performance
- Social punishment of innovators and deviants
- Slow, throttled, response times
- Lack of negative feedback loops that accelerate learning
- Reliance on firefighters, hero-worship
- A caste system where the upper echelons are disconnected and distanced from the lower constituencies
Got anymore traits to add to the list? Which would you rather work for, a staid and closed mediocracy or a vibrant and open meritocracy?
No Issues Please!
One of the differences between a leader and a manager is the way that they handle status reports from team members. When a leader receives a status report from a team member, she zeros in on the issues/roadblocks section and gets immediately to work. She talks to the team member to ferret out the problem specifics. For those issues that are out of the control of the team member, the leader becomes proactive and goes out and resolves the problem. It’s that simple.
What does a manager do with an issue? A manager ignores it. Hell, it’s work and thus, it’s outside the scope of her responsibility. After a few weeks of submitting issues and seeing no action taken, team members flip the bozo bit on the manager. Trust and respect, which are hard to earn but easy to lose, go right out the window.
Leaders rule, managers drool.
Upstream Bullies
In the aerospace and defense industry, a system engineer is the equivalent of a business analyst. They’re supposed to specify and record clear and unambiguous software requirements for the software development team, and then help the team get the requirements right.
In my experience, excellent system engineers are very hard to come by. The vast majority of them drop open-ended one line bombshells like “The system shall detect targets with a probability of detection of 95%” on the development team. Then these “shallocators” disconnect and distance themselves from the programming team and morph into glorified project managers, but without the responsibility. I call these types of system engineers upstream bullies because they’re always looking over your shoulder and telling you how to do your job even though they’ve never written anything bigger than “Hello World!”. Upstream bullies also demand that programmers dot the I’s and cross the T’s even though their own work, which is the input to the software team’s work, is a useless POS.
Ever wonder why you frequently read about large software-intensive government projects that are massively late and over budget? Besides poor leadership, another big reason is that upstream bullies are at work. If you’re a software developer and you have a choice, stay away from upstream bully shall-meisters.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 