Scale makes it different

---

Scale is its own thing.

Bigger is not always better, but it's always different.

For that matter, so is smaller.

Look no farther than physics: 

• Smaller: Sub-atomic quantum physics features particles with properties that are statistically uncertain, but those same properties would be deterministic but for the small (!) size.
  
  
• Bigger (or greater): For objects moving at near the speed of light the laws of physics don't change, but the math does (Einstein's theories). For example, you can’t just add velocities together the way Galileo or Newton did; you have to add them relativistically. You can’t just treat distances as fixed and absolute; you have to understand that they contract along the direction of motion(*).

What about projects at scale?

At large scale, one observer (*) has said: "The quantitative becomes qualitative" meaning: when it gets big, the whole thing takes on a different character, apart from the numbers. Example: soloist vs a choir; a few people vs a crowd; the Grand Canyon vs a gorge, and so forth. 

There's a lot going on in big projects; some stuff we all know about and have experience with:

• Communications degrade qualitatively and exponentially with the number of communicators. If two people are talking to each other, it's merely bi-lateral. But if 5 people talk among themselves, there's 5*4 ways that communications can flow: N*(N-1)
  
  
• Bureaucracy inevitably replaces personal trust and one-one relationships. You can't know and trust everyone is a large project with myriad subcontractors (1099s or entire companies), remote team locations, etc. So bureaucracy has rules, workflows, organization structure, and other institutional relationships to replace and substitute for personal relationships.
  
  
• Interfaces, whether institutional in the PMO or as part of systems of deliverables, become all so important. You may not have any visibility or understanding beyond the interface specification you must meet. (See: Systems, below)

 But there are other influences that are prominent at scale:(***)

• Systems is the way you think about things. Anything really large has properties of systems, and so you have to think like a systems-savvy person: interactivity; interconnections; dependencies; sequencing; process and constraints; chaotic and impulsive behavior. If you don't know much about systems, start here.
  
  
• Phase or state changes: Increasing complexity arising from increasing parts is usually not linear; there may be abrupt changes of state or performance. Suddenly there are walls you can't get through; people you can't reach. Or, machines reach their absolute limit, beyond which their performance is unpredictable or unreliable
  
  
• Reduction vs construction: What you can disassemble you may not be able to reassemble or construct from the pieces. An unintended explosion may be an "unmanaged disassembly" in systems' speak. You can't put Humpty Dumpty back together.
  
  
• Symmetry, or not: If it's symmetrical, then it looks the same from all points of view. As things scale up, symmetry is often, if not usually, lost. There are just too many different points of view.

Scale effects on cost and schedule

Scale has two effects on cost:

1. Scale increases friction with so many moving parts to the project. That is a cost increase, albeit with the benefit of having access to myriad capabilities and functionalities
2. Scale is improves efficiency, making cottage industry efforts into industrial strength workflows, thereby reducing cost.

Scale requires "loose coupling" in schedules. 

That is, white space or buffers are needed to accommodate a dizzying number of dependencies and interactions. And loose coupling protects the critical path, as we know from Critical Chain scheduling. All of this has a combined effect of stretching the schedule. But that's the "cost of doing business" at large scale.

 

-------------------

(*) Karl Marx

(**) Attribution: Ethen Siegel

(***) If you are into science, read this oft-cited paper: "More is different"

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Why do they call it a 'black box'?

---

Why do they call it a black box? Maybe it should be just opaque. Either way, it's a system engineering idea:

• Encapsulate a function, 
• Make it opaque and invisible to outsiders
• Feed it inputs and external controls, biases, and offsets (in other words, the 'interfaces')
• Look for and utilize the prescribed outcomes
• Voila! You've got a 'black box'!

Ooops!

What if ...

What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

The question is begged: Do you understand how your black box interfaces with your project or system? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

Working on AI?

The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

A comment on Architecture

---

"Architecture" has been in the PM-domain commentary more and more as rapid and flexible methodologies compete with more experienced ideas.

• It's been said, correctly, that architecture is where functional utility is addressed first (*)
• And it's been said, again correctly, that architecture generally imposes, usually conforms to, and applies the construction and integration rules for the domain of the project. (**)
• It's been said, repeatedly by me and others, that every project has architecture (and an architect) even if somewhat buried in other tasks and roles, because everything virtual or real has an architecture

But beyond rules and utility there are myriad components to architecture

• It expresses the art contained within the domain. In software, there is definitely art!
• It expresses the culture of the context in which the product or outcome will live
• It provides coherence and organization to the entity under development

Architecture and system engineering share a lot of the same goals for organization, coherency, and predictable performance. 

• System engineering focuses hard on interoperability of the sundry pieces and parts, making interfaces work smoothly, and being the keeper of the flame of cybernetics, anti-fragile, and anti-chaos. 
• And system engineering often morphs into system test for validation and verification.
• Whereas architecture often morphs into softer elements such as appealing design and fit-to-culture.

All said, as long as what you are building is itself divisible -- and pretty much everything above the atomic level is -- then there are both architectural considerations of integration and system engineering choices at interfaces.

What about rapid and evolving methodologies?

These usually are focused at a level below architecture and system engineering. Usually the focus is on rapid or evolutionary development. In the case of Agile methods, there is a lot of flexibility allowed within the general constraints of interfaces. Architects and SEs work at the black-box level; Agilists work on the internal white-box solution

____________________

(*) "Utility" is the measure of effective value vs actual value. If you don't like it, if you can't live with it, or if it means little to you, it has little utility to you, although others may find its actual value quite satisfactory. The classic explanation is a poor person with $10 in their pocket vs a rich person with $10. The utility of $10 to the poor person is very much more than it is to the rich person.

(**) One only has to look into the architecture issues of the Sydney opera house to appreciate how the architect pushed conformity to construction rules to the limit 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Submarines in the Idaho desert

---

Submarines in Idaho?

In the desert?

Actually, a hull, a reactor, and a steam turbine.

All part of the 1953 simulation of the first ever naval submarine nuclear propulsion reactor to run in an actual ship configuration all the way to turning a propeller shaft.

That is what we PMs call a full-scale model and simulation test.

And not only was this first-ever in a ship's configuration, but the reactor-steam turbine combo ran for 96 continuous hours, a near-miracle for the technology of the day. 

"Radical technologies require conservative engineering"
Admiral Rickover, the father of naval nuclear power 

And what significance was 96 hours?

That was the time needed -- according to estimates -- for the soon-to-be Nautilus to transit continuously submerged from North America to Europe.(*)

We know the rest of the story: this "submarine in Idaho" project simulation and testing led to a successful Nautilus, followed by widespread nuclear naval power within a few decades.

---

.(*) Did you know: in World War II, only 20 miles was the extended range for continuously submerged?

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

It's all about negative feedback

---

The question is posed: Is negative feedback good or evil?

Answer: Good!

Really? 

Yes, 'negative' is good.

Ooops: did I mention what feedback is? Generally it is a sample or portion of an outcome, or something directly related to an outcome.

Here's the thing: 'Positive' feedback is reinforcing, agreed, but that may not be a good thing. 

Really? Why not?

Because positive feedback encourages or promotes outcomes to ever increase, following the rule: 'more is better'. But such may become unstable, erratic, even chaotic. And, if the outcome has elements of distortion, disturbance, or some other impurity, then rather than 'more' you want 'less'.   

Negative feedback -- which is to be understood as feedback phased or timed to be not reinforcing -- helps with stability, predictability, and puts a damper on chaotic impulses. Done right, properly phased feedback can reduce distortion and help cancel-out disturbances. (*)

We can summarize this way: 

The primary purposes of 'feedback' are to: 

• correct behavior (not always, or even mostly, human behavior), 
• prevent 'runaway' and chaotic responses, 
• confirm outcomes as expected, and 
• enhance the predictability of outcomes. 

These latter advantages come from so-called 'negative' feedback.

NOTE: providing feedback has its own jargon: We say: feedback closes the loop (the loop is from outcome back to the source that drives the outcomes), or the 'loop is closed'

Now the tricky part: Strength and timing are everything. 

To close the loop effectively, the strength (or amplitude) of feedback, and the timing (or phasing) of feedback has to be such that the feedback provides a countermeasure to the potentially errant outcome, the net effect being an outcome just as predicted, void of the bad stuff.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

I should mention:

The study of feedback systems generally falls within what is called 'cybernetics'. As described by sciencedirect.com, MIT mathematician Norbert Wiener defined cybernetics as “the study of control and communication in the animal and the machine." 

From Wikipedia, we learn: The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs [ie, feedback] for further action in ways that support the pursuit and maintenance of particular conditions [ie, 'ways that support' requires the correct timing and strength]

---

(*) The difference between noise and song among many voices is timing or phasing. The members of a really good choir or ensemble sense the others and with that feedback each member adjusts to the pace of the others. But, get the timing wrong, and it's all just noise. 

 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Systems thinking

---

"Life was simple before World War II. After that, we had systems"

Rear Admiral Grace Hopper, USN

Matthew Squair, a systems safety expert, has this to say about that (*):

• From the Gesalt (**) school comes the [systems] view that the whole is often greater than the sum of the parts, i.e. there exists properties that emerge from parts aggregated together .... [which is a telltale sign of a 'system of parts']
  
  
• From the cybernetic (**) school comes the view that systems can be understood by studying, in the abstract, control and communication between the parts that effects causal feedback loops and interactions with the environment [The 'blackbox' view of systems is a cybernetic concept]

In other words, there is more than one way to look at or perceive a system. For those that have given this some thought in the past, or have worked with or in system engineering, that there is more than one point of view of what we would call a system is not new news, but multiple views is a key concept when thinking about systems. 

But nonetheless, the I've found these ideas seem to be most common:

• There is the hierarchical view of a system as a collection of subsystems that all combine in some way to make a system. In the hierarchical view, the system is parsed into major subsystems according to their similar position in a hierarchy, which, in turn, these subsystems are further reduced to lesser subsystems until there is no meaningful reduction to be made.

The proposition for breaking apart a system in order to understand it, to scope and specify it, and to be able to actually construct it is generally called reducing the system to its constituent parts, summarized as reductionism.

And, the 'science' or 'art' of reductionism is no small matter. Some truly awful reductions have been made in my experience that harmfully impact the understanding and the means to implement the system successfully.

The risk inherent in reductionism is that the focus is continuously narrowed until the 'big picture' fades way into the background; all sense of synergy and emergent properties that give rise to the 'sum is greater than the parts' is lost. 


• There is the black box view of a system which is about boundaries, boundary conditions, and means to interface with the system for providing input, obtaining output, effecting control, and processing telemetry or feedback to establish stability and predictability of performance.
  
  The question is begged: is there a 'white box' view? Yes, such is the internal detail known to 'insiders', but not necessary to those system 'users' and controllers that stand outside the black box.
  
  Reductionism plays a lesser role; the main utility of reductionism is to decide or allocate functions and performance requirements to the black box, thereby setting boundaries for what is in the box and what is not.
  
  The great advantage of the black box view, apart from a clear understanding for boundaries, is that interfaces become the focus: how to stimulate the system; how to control it; how to measure it; how to use it's outcomes; and how to repair-by-replacement. In turn, these give rise to widely recognized standards for size, weight, connectors, and other physical attributes, as well as standards for intangibles like software objects and APIs.

---

(*) "Critical Uncertainties; the theory and practice of system safety" Matthew Squair, Review Copy, April 2022

(**) Gesalt is a term of art taken from German meaning that the attributes of the whole are not deducible from analysis of the parts in isolation. First used in psychology to understand behaviors.

Cybernetics is “the science of control and communications in the animal and machine.” The core concept of cybernetics is circular causality or feedback—where the observed outcomes of actions are taken as inputs for further action in ways that support the pursuit and maintenance of particular conditions, or their disruption.

Norbert Weiner, American mathematician, is credited with defining cybernetics in systems terms.

 

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Roll back the black box

---

It's a system engineering idea:

• Encapsulate a function, 
• Make it opaque to outsiders, and 
• Feed it inputs and external controls, biases, and offsets
• Look for and utilize the prescribed outcomes
• Voila! You've got a black box!

Ooops!

What if ...

What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

The question is begged: Do you understand how your black box works? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

Working on AI?

The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

---

Buy them at any online book retailer!

Numbers, numbers! Can't do without them

---

Numbers are a PM's best friend

Is this news?

I hope not; I wrote the book Quantitative Methods in Project Management some years ago. (Still a good seller)

So, here's a bit of information you can use:

Real numbers: (**)

• Useful for day-to-day project management
• 'Real numbers' are what you count with, measure with, budget with, and schedule with.You can do all manner of arithmetic with them, just as you learned in elementary school.
• Real numbers are continuous, meaning every number in between is also a real number
• Real numbers can be plotted on a line, and there is no limit to how long the line can extend, so a real number can be a decimal of infinite length
• Real numbers are both rational (a ratio of two numbers) or irrational (like 'pi', not a ratio of two numbers)

Random numbers

• Essential for risk management subject to random effects
• Not a number exactly, but a number probably
• Random numbers underlie all of probability and statistics, and thus are key to risk management
  
• Random numbers are not a point on a line -- like 2.0 -- but rather a range on a line like 'from 1.7 to 2.3'
• The 'distribution' of the random number describes the probability that the actual value is more likely 1.7 than 1.9, etc
• Mathematically, distributions are expressed in functional form, as for example the value of Y is a consequence of the value of X.
  
• Arithmetic can not be done with random numbers per se, but arithmetic can be done on the functions that represent random numbers. This is very complex business, and is usually best done by simulation rather than an a direct calculus on the distributions. 
• Monte Carlo tools have made random numbers practical in project management risk evaluations.

Rational numbers:

• A number that is a ratio of two numbers
• In project management, ratios are tricky: both the numerator and the denominator can move about, but if you are looking only at the ratio, like a percentage, you may not have visibility into what is actually moving.

 Irrational numbers

• A number that is not a ratio, and thus is likely to have an infinite number of digits, like 'pi'
• Mostly these show up in science and engineering, and so less likely in the project office
• Many 'constants' in mathematics are irrational .... they just are what they are
  

 Ordinal numbers

• A number that expresses position, like 1st or 2nd
• You can not do arithmetic with ordinal numbers: No one would try to add 1st and 2nd place to get 3rd place
• Ordinal numbers show up in risk management a lot. Instead of 'red' 'yellow' 'green' designations or ranks for risk ranking, often a ordinal rank like 1, 5, 10 are used to rank risks. BUT, such are really labels, where 1 = green etc. You can not do arithmetic on 1,5,10 labels no more than you can add red + green. At best 1, 5, 10 are ordinal; they are not continuous like real numbers, so arithmetic is disallowed.

Cardinal numbers and cardinality

• Cardinality refers to the number of units in a container. If a set, or box, or a team contains 10 units, it is said it's cardinality is 10. 
• Cardinal numbers are the integers (whole numbers) used to express cardinality
• In project management, you could think of a team with a cardinality of 5, meaning 5 full-time equivalents (whole number equivalent of members)
  

 

Exponents and exponential performance

• All real numbers have an exponent. If the exponent is '0', then the value is '1'. Example: 3exp0 = 1
• An exponent tells us how many times a number is multiplied by itself: 2exp3 means: 2x2x2 (*)
  
• In the project office, exponential growth is often encountered. Famously, the number of communication paths between N communicators (team members) is approximately Nexp2. Thus, as you add team members, you add communications exponentially such that some say: "adding team members actually detracts from productivity and throughput!"

 Vectors

• Got a graphics project? You may have vector graphics in your project solution
  
• Vectors are numbers with more than one constituent; in effect a vector is a set of numbers or parameters
  
• Example: [20mph, North] is a two-dimensional vector describing magnitude (speed) and direction
• In vector graphics, the 'vector' has the starting point and the ending point of an image component, like a line, curve, box, color, or even text. There are no pixels ... so the image can scale (enlarge) without the blurriness of pixels.
  

 ----------------------------

(*) It gets tricky, but exponents can be decimal, like 2.2. How do you multiply a number by itself 2.2 times? It can be done, but you have to use logarithms which work by adding exponents.

 

(**) This begs the question: are there 'un-real' numbers? Yes, there are, but mathematicians call them 'imaginary numbers'. When a number is imaginary, it is denoted with an 'i', as 5i. These are useful for handling vexing problems like the square root of a negative number, because iexp2 = -1; thus i = square root of -1. 

---

Buy them at any online book retailer!

Negative feedback: good or evil?

---

The question is posed: Is negative feedback good or evil?

Answer: Good!

Really? 

Yes, 'negative' is good.

Ooops: did I mention what feedback is? Generally it is a sample or portion of an outcome, or something quite similar but directly related to an outcome.

Here's the thing: 'Positive' feedback is reinforcing, agreed, but that may not be a good thing. The primary purposes of 'feedback' are to: 

• correct behavior (not always, or even mostly, human behavior), 
• prevent 'runaway' and chaotic responses, 
• confirm outcomes as expected, and 
• enhance the predictability of outcomes. 

These latter advantages come from so-called 'negative' feedback.

NOTE: providing feedback has its own jargon: We say: feedback closes the loop (the loop is from outcome back to the source that drives the outcomes), or the 'loop is closed'

Now the tricky part: Strength and timing are everything. 

To close the loop effectively, the strength (or amplitude) of feedback, and the timing (or phasing) of feedback has to be such that the feedback provides a countermeasure to the potentially errant outcome, the net effect being an outcome just as predicted, void of the bad stuff.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

 

---

Buy them at any online book retailer!

Sketching out the architecture

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it."

Box model

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr. Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Buy them at any online book retailer!

When mysteries are progress

---

Got a mystery in your project?

Can't figure out what's happening, or

Can't find the root cause -- after following all the methodologies -- for what you measure or observe?

Perhaps you are making progress!

Stuff happens; don't deny; it's yours to figure out why

Once you do, you may have discovered something quite fundamental about the project outcomes 

There are lots of examples:

• There is a lot of dark matter in the universe; why is there more dark matter than visible matter?
• There are missing particles in the Standard Model of particle physics; where are they?
• Why does the speed of light not conform to Newtonian physics (Einstein worked that out, fortunately)
• Why does your bridge collapse after you built it with a lot of steel?
• Why do team mates fly off the handle when you mention X or Y? (Note: no religion or politics in project teams)

 So, there are a lot of examples. What do you do about it?

• Try Bayes methods of hypothesis testing ... make a prediction (perhaps, gasp!, a guess for lack of something better); test for results; change a parameter and look again. Repeat ....
  
  
• Try models: why does the model work and the system doesn't? (NASA calls something like this 'model based system engineering -- MBSE')
  
  
• Get out of the frame and look from a different vantage point. That's what Einstein did.
  
  
• Try forensic engineering or investigation. This is micro-engineering at the nut and bolt level.
  
  
• Change direction and do something entirely different (not retreat; just advance in a different direction)
  

---

Buy them at any online book retailer!

Backlog blocked?

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling? 

Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

 

Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?

If coupling is a benefit, how to obtain it?

First, there's buffers to loosen coupling

The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects

• To avoid coupling, buffers may not do the trick.
• But to enable coupling, we need some connectivity

In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 

 

One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.

 

Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 

Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Buy them at any online book retailer!

Complicated and complex

---

"They" say it's complicated

"They" say it's complex

Are they saying the same thing?

No, actually, there are differences:

• It's complicated if "it" has a lot of parts and pieces
• It's complex if the parts and pieces have a lot of interactions among them, and many of the interactions are not readily apparent, hard to model or predict, and may even lead to chaotic responses 

Good or bad; fix or ignore?

So is complicated or complex a good thing or bad? How would you know? And, what's to be done about them? 

Short answer: Chaos is almost always bad in a system, product, or process -- whatever is the project's outcome. Thus, for that reason alone, complexity may not be your friend.  

But, even without chaotic propensity, complexity is usually not a good thing: complex systems are hard to service; hard to modify; difficult to integrate with an established environment; on and on. If such are present, then complexity is present -- that's how you know.

Complicated is usually a matter of cost: lots of parts begets lots of cost, even if there is minimal complexity. Simple is usually less costly and may not necessarily sacrifice other attributes.

So, what do you do? 

You've read the theory; now, to action:

• Chaos is bad; let's start there. The fix is to reduce complexity. To reduce complexity, a generous number of interfaces are required.
  The purpose of the interface is to block propagation of chaotic responses and contain risk to smaller elements of the system.
  Proof is in the testing. All manner of stimuli is applied to try to induce chaotic responses, and address those that occur. 
  
  
• Complexity is first addressed by interface design; then by service design. To wit: if you have to fix something, how would you separate it from the system for diagnosis, and then how would you repair or replace? Addressing these functional problems will in turn address many of the issues of complexity
  
  
• Complicated means a lot of parts. If that's more expensive than you want to afford, then integrated assemblies will reduce the part count and perhaps address some of the issues of complexity.
  If you've ever looked inside an old piece of electronics circa 1960 or older, you can appreciate the integrated modular design of today's electronics. Hundreds of piece parts have been integrated into a dozen or fewer assemblies.
  

---

Buy them at any online book retailer!

Coupling, coherence, and other stuff

---

Has someone in your PMO suggested applying a dose of system engineering to portfolio management? If they have, I wonder if they think of it as "three C's and D"?

A bit cryptic? Well, not so much when you spell it out:
Coupling, coherence, cohesion, and diversification

The short form explanation of  three C's and D looks like this:

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. 

 

In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

Diversification

Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management. 

---

Buy them at any online book retailer!

Risk management: what's to know?

---

If you only know one thing about Risk Management, know this:

Schedule slack is your most powerful tool

Poorly developed instincts and skills in the use of this most powerful tool are leading causes of poor risk management

If you are a Systems person --- a strategic thinker; an integrator; a "it all has to work" person -- you'll translate schedule slack into to "loose coupling"

Loose coupling is your most powerful tool

This all sounds like schedule, but the side effects are profound (slack is like a nail; it works everywhere):

• Time is lost to effect design, manufacturing, or delivery mitigation
• Pressures mount to "do something"
• Short-cuts are taken
• The thing may not work at the end (oops, that's career limiting)

And, the list of slack misuse is relatively short, so everyone should be able to keep these bullets in mind:

•  It shall be: All schedules require slack; a schedule without slack is but a hope, and is risky all the way
  
• At the end: Slack is always sequenced after a risky event is to occur. NEVER put the slack first, hoping it will all go away
• Don't add risk unwittingly: Unnecessary coupling (to wit: bundling) just adds risk where there was none. Decouple everything; don't purposely couple anything. 

If you bundle (tightly couple) the statistics are against you:

• If two independent events have a 9-in-10 chance of success, then when tightly coupled and no slack between them, success of the pair is only 8-in-10, a loss of 10 points
• It gets worse fast: a pair with 7-in-10 chance of success degrades to less than 1-in-2. A loss of 20 points.  Good grief!

The effect of slack? NO loss of points .... a cheap way to fight  

---

Buy them at any online book retailer!

If you can't draw it .....

---

Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.

Fair enough -- no news there. We've talked about storyboards, etc before.

But then the heavy lifting begins. How to fill in the details? Where to start?

My advice: Draw it first.

If you can't draw it, you can't build it!

And so the question is begged: What's "it"

Three elements:

1. Narrative
2. Architecture
3. Network

And, one more for the PM:

• Methodology

Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.

Narrative: (an example)
Bridge stanchion with strain sensor and sensor software

Architecture:
Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):

Black Box

Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)

And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:

Interface

And then we add content (white):

Content

Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:

• Black: Boundary
• Blue: Interface or API
• Grey: Buffer
• White: functional content

You could call this an architecture-driven approach and you would not be wrong:

1. First, come the boxes:

• Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
• Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software

Then comes the interface:

• Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?

And then comes the "white box" detail:

• The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
• And then there is the actual functional content, to include feature and performance.

Network

2. Second big step: networks of boxes

• Think of the boxes as nodes on a network
• Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
•  Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
• That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.

3. Third big step: white box design.

Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts materials to build out the box.

• Expect to refactor the network as the white box detail emerges
• Expect to refactor the white box once development begins. See: agile methods

And, not last: Methodology:

The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!

The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:

Interfaces and boundaries are sacrosanct!

Now What?
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!

---

Buy them at any online book retailer!

So, you need a System Integrator -- SI

---

You've got a big (big!) project with a lot of moving parts (different contractors doing different stuff).
You've been told: Get yourself an SI!

The questions at hand: what is a System Integrator (aka SI), and what do they do?

Point 1: the term is "SI"; and the SI is an independent team, separate from the system engineer "SE" and the architect

Point 2: the SI works directly for the PMO, not the SE or the architect in most cases

Point 3: the SI comes on the job early, typically from Day-1, working down the project definition side of the "V" chart (see chart below)

Point 4: the SI is the first team responsible for the coherence of the specifications and the test plan. Thus, the SI is an independent evaluator ("red team") of specifications, looking for inconsistencies, white space gaps, sequencing and dependency errors, and metric inconsistencies

Point 5: the SI is an independent technical reviewer for the PMO of the progress toward technical and functional performance. The SI can be an independent trouble-shooter, but mostly the SI is looking for inappropriate application of tools, evaluation of root cause, and effectiveness of testing.

Point 6: the SI may be an independent integrator of disparate parts that may require some custom connectivity. This is particularly the case when addressing a portfolio. The SI may be assigned the role of pulling disparate projects together with custom connectors.

Point 7: the SI is an independent integration tester and evaluator, typically moving up the "V" from verification to validation

Point 8: in a tough situation, the SI may be your new best friend!

What about agile?
'Agile-and-system-engineering' is always posed as a question. My answer is: "of course, every project is a system of some kind and needs a system engineering treatment". More on this here and here.

And, by extension, large scale agile projects can benefit from an SI, though the pre-planned specification review role may be less dominate, and other inspections, especially the red team role for releases, will be more dominate.

V-model
Need to review the "V-model"? Here's the image; check out the explanation here.

---

Bookmark this on Delicious

---

Buy them at any online book retailer!

After that, we had systems!

---

I was reading Matthew Squair's course materials on System Safety Fundamentals when I came across this slide:

"Life was simple before World War II. After that, we had systems."
Rear Admiral Grace Hopper (USN)

You've got to smile at that witticism!

The Admiral Dr (*), of course, is credited with leading the team that developed the first linking complier that led directly to COBOL.

But she had a fierce wit
Perhaps she is best known for inventing the system "bug" when she literally found a dead bug in in an inoperative computer system.(**) She retired from the Navy at age 79 in 1986 after serving about 50 years.

About risk, she is quoted "Ships are safest in port, but that is not what ships are built for"

And, of course, she is famous for demonstrasting that a nanosecond is the time taken for electrical signals to travel about a foot. She was known to carry a bundle of 'foot-long' "nanoseconds" to her classes in computer science. Watch here for her demo.

 ++++++++++++++
(*) PhD, Yale, '34 Mathematics
(**) a mix of lore and truth

---

Buy them at any online book retailer!

Unintended consequences of metrics

---

In the online "Cross Talk -- Journal of Defense Software Engineering" for Sept Oct 2016 there is a an article entitled "Positive Influences and Unintended Consequences" by Rob Ashmore and Mike Standish of the U.K. Defence Science and Technology Laboratory

On the general topic of metrics, they make the point that generally all metrics have unintended consequences. (No news there; I think we can all agree with that. In my parlance: For every measure, there is a counter-measure. To which there is a counter-counter measure .... ) And to make their case, they cite observations by other researchers of U.K. public sector organizations that the consequences can be grouped into eight distinct types:

• Tunnel vision, when management focuses on quantified aspects of performance rather than overall quality.
• Sub-optimization, where narrow, local objectives are prioritized over the wider objectives of the organization as a whole.
• Myopia, which involves the pursuit of short-term targets at the expense of legitimate long-term objectives or outcomes.
• Measure fixation, where managers focus on the metric, rather than the objective for which the metric was developed.
• Misrepresentation, where the reported metrics do not match the behavior on the ground.
• Misinterpretation, where those to whom the metrics are reported make incorrect or inappropriate decisions.
• Gaming, where behavior is deliberately altered so as to exploit loopholes in the measurement system.
• Ossification, where an overly rigid measurement system prevents innovation.

To combat these phenomenon they introduce and explain a tool which is really just a cause-effect diagram that closes on itself -- closed loop. A "causal circle" of sorts. Read the article for more detail.

 I can't fault them on that idea. I've been preaching for years that closed loop systems are the only stable systems, and that goes for communications generally, measurements specifically.

---

Buy them at any online book retailer!

It's as easy as 1-2-3!

---

Counting, positioning, or measuring: what's in a number?

Remember pre-school or kindergarten: we all "learned our numbers".
Ah! but did we?

Want to count something? Just use the integers, starting at 0 and going in familiar step: 1, 2, 3 ....
The count takes on the dimension of what you are counting: dollars, inches, meters, liters, etc
You can do arithmetic on count, but because of the dimensioning, the results may or may not be viable: square inches are ok, but square dollars are not.

Want to rank or position something? Again, we fall back to the integers -- 1st or 2nd position is good; position 1.2 in a queue has no meaning or implementation. And, there is no dimension per se in a position.
Some arithmetic still applies, but it's tricky. Addition is not commutative:

• You can add 1 to the first position to get the second position, 
• But you can't add first position to a 1. Stuff like that.

Want to measure something? You can use any rational number for measurement. (a number that can be fashioned by the ratio of two numbers). Really, anything on a measurement scale is rational and can be a measurement.

But there are irrational numbers which can not be formed by a ratio (like "pi"). Nonetheless, you can measure with irrational numbers. The area and circumference of a circle are measured with "pi"

For a number to be useful in measuring, every number in between has to be meaningful. That's why you don't do measurements with ranks and positions: the in-between numbers are not meaningful.

Calibration: And, to be meaningful, the scale has to be calibrated.  A ruler with irregular spacings or a warped or bent rule, or guesses without reference to benchmarks or other reference classes are uncalibrated. And, thus, every number in between is not meaningful.

Project management
And so, where does the rubber meet the road in project management?

• Budgets, schedules, resource estimates and utilization need calculation, measurement, and counting
• Anything else that's quantitative

We're done here!

---

Buy them at any online book retailer!