Policy, doctrine, and protocols

From time to time, we really do need to write a few things down in a plan, writing actual sentences of all things. One such plan that comes to mind is a risk management plan.

Now, I'm no fan of boilerplate, that generic stuff that planning authors seem determined to impose on the reader (although most of us just skip by), so I propose that most plans can get away with four content categories:

1. Policy--actionable direction.  What is to be done; who (or what) is affected; why are they affected, and who has the responsibility and authority for policy implementation?
2. Doctrine--the principles and beliefs that inform the policy and
3. Protocols--the rules (and could also be the tools) for policy implementation
4. Governance--authorization and escalation rules; decision rules

Let's try one on to see how it might work. How about "risk identification"; what's the plan for that one?

Risk Identification Policy:

It's the policy of Project X that every manager (project, cost account, and work package) will proactively seek risk identification on a continuous basis in order to forestall surprise and enable more predictable forecast of outcomes

Affected managers have a responsibility to ensure identified risks are submitted to the project's risk management process.

Risk Identification Doctrine:

• Anyone can identify a risk
• Everyone has a responsibility to seek risk identification
• Messengers are not at risk for bearing the message
• Every identified risk deserves consideration in the risk management process

Risk Identification Protocol:

• Continuously assess the circumstances of identified risks to ascertain if revisions, modifications, and additions are required
• Maintain a 360-surveillance of the external threat environment; bring new threats to the RM process
• Maintain a current forecast by analysis, simulation, or model to reveal new risks to project completion
• Elicit expert opinion to formulate risk descriptions 
• Formulate a Risk Breakdown Structure to categorize risks as affecting the baseline, or not ('on or off' the baseline project plan). In other words, be a Bayseian.
  
• Relate identified risks to the Risk Breakdown Structure by affected WBS, schedule, budget, performance, quality, or other risk register attributes

Governance

• Impact decisions follow the project's funding and expenditure authority
• Timeliness is of the essence; urgent assessments will be handled within a business day
• Risk assignments in the Risk Breakdown Structure follow the projects WBS assignment protocols

There now! That wasn't so bad. A Risk Identification plan in less than a page. What a concept!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Governance or error?

Take a look at this:

Is this pilot error or a violation of governance? I'm not the first to ask the question. Our friends at Dark Matter first raised the point.

Could be either, or neither: it could be mechanical.

How to know? And, does it matter the motivation?

Well, actually yes. Governance is in the wind these days, what with agile and all. On the one hand: all hail initiative and daring! On the other hand: who's got the big picture in mind?

Certainly the 'captain in command' is the ultimate team leader. No central authority can intervene, short of shooting him down (I assume a lady is not in command, but she could be, of course).

And, I'll bet he's not reading the flight manual either! Improvisation is the paradigm.

Trust is what it is about at this point. All concerned, especially the two ground observers, are bound to trust the judgment and skill of the captain.

But motivation is still on the table.  The motivation for more agility in governance is to lean out the overhead and concentrate all energy on throughput, that is: governance that actually promotes deliverable output that leads to mission outcomes.  Insofar as our daring captain is motivated for the right reasons, I say: yea verily! 

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Where you stand

Where you stand depends on where you sit

Richard Stengel
Editor, Time Magazine

Amen! When it's not your money, independent action looks pretty good. But, if the the independents are spending your money, governance looks a little different and perhaps a little better!

Actually, Stengel's point is that when you're outside the tent, and don't have responsibility for the consequences of your decisions, it's a lot easier to be a rebel. Inside the tent, things are a little different.

And, if you're an outsider who then finds themselves on the inside and responsible for lives and fortunes, things play a little differently.

It's easy to say "I'm the decider", but it only matters if in the deciding you are also taking responsibility for outcomes and consequences.

Think about it. Where you stand may well depend on where you sit.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Eliyahu Goldratt

Eliyahu Goldratt, a truly innovative thinker, passed away last month, too early by 20 years at least.

Goldratt gave us "Theory of Constraints" and "Critical Chain", two really good ideas useful everyday in our business.  TOC--as explained in his book, The Goal--gave us a working paradigm for optimization focused on throughput, the stuff that matters and is valuable to customers/users.  He worked hard to convince everyone that optimizing department metrics does not optimize for the business; indeed, it's counter optimization.  From TOC, we have the underpinning for Lean, and "throughput accounting", a good concept for the agilists. 

From Critical Chain we learn that to protect the critical path and avoid 'merge bias' that destroys schedules, including agile schedules, we buffer to make parallel paths look tandem (serial, finish-to-start).  CP uber alles was his mantra.  And, Goldratt recognized the cumulative error of putting reserves at the task manager level; his idea: the PM should control reserves, buffering the whole project.

We should all take a moment and remember Eliyahu Goldratt.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Quotation: goals

On leaders with staying power:

Most visionaries set a specific goal. When they reach that goal, then they institutionalize it.

Henry Kissinger

What's the point here?

It's a matter of separation: Separating those with staying power and an eye on legacy, and those that are just visionaries who are transitory and not lasting.

Driving a vision into the fabric of the institution is the way to have a real impact. Those who can do it are not just blue-sky thinkers; they are thinkers that make lasting impressions

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunk cost and the rear view mirror

Sunk cost: "everyone knows" that decisions are not to be made on the basis of trying to salvage sunk costs. The saying goes: what's done is done; decisions are to be made about options in the future. The past is past.

Well, if humans were robots, following that rule would be no big thing. But of course it's not that way, and what's more, we know it.

Now into the "sunk cost" arena comes another bias to add to the list: "continuation bias". The first I heard about it was in a post last month from our friends at Dark Matter: "flying in the rear view mirror". I quote:

Plan continuation bias is a recognised and subtle cognitive bias that tends to force the continuation of an existing plan or course of action even in the face of changing conditions

Of course there are other variants to this: "Continuing to do the same thing and expect a different result is nonsense", and other formulations.

Even Glen Alleman recently got into the act with a quote of Fitzgerald's First Law of Program Success:

There are only two phases to a big program: Too early to tell and too late to stop.

Program advocates like to keep bad news covered up until they have spent so much money that they can advance the sunk-cost argument;

that it’s too late to cancel the program because we’ve spent too much already.

Buy why?

It's relatively simple: we hate to lose, and most important we had to lose what we had. People who study these things say it's more than just anecdotal that we are very averse to risking what we have: thus, a utility response that is quite non-linear. We weight a loss, particular a loss of from a reference point of achievement, much more so than we favor a gain from the same reference.

Such reference point adjustment is the basis of a utility concept called "prospect theory". Originally formulated in the financial community, it easily extends to project management. It's a cousin of adjustment or anchor bias. Once we reach a pinnacle, the new height becomes the reference for subsequent measurements of loss.

And sunk cost is the cost to reach the pinnacle. If we can go no farther, or if continuing the same plan only gets us regression, we keep hoping things will change and we'll get back to where we were.

Might happen; might not. Continuation bias: beware!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

What is information?

I've been intrigued by a lot of the content in the book "The Information", a tour de force through the history and development of the concept of information as told by author James Gleick.

One intrigue: the definition of information [as posited by Claude Shannon of the Bell System in the WW II era] paraphrased here as:

The number of choices or degree of uncertainty in the possible statements, outcomes, or messages conveyed

Does this bring a frowny face? It should.

First: Shannon puts no attention on the meaning conveyed by the information.  His idea of information more or less ends with the message itself.

Second: I find it a little counter intuitive.  There's more information content in the uncertainty of multiple choices than there is in a single point outcome. 

But Shannon's point is this: information is 'emitted' as uncertainty turns into certainty.  It means there's little information in a single determinant outcome. Indeed Shannon's name for such an outcome is "bit", meaning one binary [yes, no] digit [or symbol] of outcome.

The corollary: more choices means more bits to represent the choices, and a richer set of possibilities.

Two other ideas:

1. To assure delivery of the message with high quality in spite of interference, add redundancy.  This means add patterns and to an extent make the message somewhat predictable
2. Redundancy takes away from the number of independent ideas that can be put across in a given space of time, so keep the number of ideas minimum if quality counts.
   
   Counterpoint: redundancy can be boring!  So, unless you have a lot of competition for your communication, and thus need the power of redundancy to get the message through, back off on repetition.

So, what does this have to do with project management anyway?

Well, consider executive communication, to include communication by means of a proposal.

1.  Maximum information is conveyed by showing the breadth of the choices you've evaluated and the array of dots you've considered in reaching whatever conclusions you present.  Indeed, the narrative that connects the myriad dots is likely rich in information, much more so than the description of just one dot.  Leave that stuff out, and you may still convey the bit of conclusion, but it's certainly not as rich as could be otherwise.
2. If there's lots of competition for the executive's time (buzz word: mind share), then that's tantamount to 'noise' in Shannon's world.  The countermeasure: redundancy (in effect: imaginative repetition) and patterns.  To some extent, establish predictability.  (Take note of this idea in the coming political campaigns!)
3. There's a trade between '1' and '2': richer information may be an advantage; getting your message through may be even a greater advantage

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Diversification slips away

For the most part, we value diversification.

The usual justification for this belief (assuming beliefs need justification--some would say beliefs are beyond justification) is that diversity reduces risk to the mean behavior. That is: if I have two quantities (also: behaviors), the mean is half their sum, but how stable is this mean position?

After all, we also value stability, from which we get predictability.

To get a handle on stability, we turn to an examination of how each quantity (also: behavior) influences the mean. So, like so many phenomenon that are sensitive to distance, the distance from either quantity to the mean is important. Outliers, a long distance from the mean, can pull the average off in their direction.

Do we want an outlier in control? Usually not.

We value the 'yellow stripe': something down the middle

.
Enter: diversification.

We seek more quantities (also: behaviors) for the composition of the mean. Perhaps there are a total of N. Now, each individual quantity is somewhat diluted by the presence of others. Indeed, we find that the prediction of the mean improves by square-root(N)

Ah, but wait! What if it's really behavior (not quantities) and the objects of behavior are a team of project practitioners. What then?

If the team is co-located, we can expect near-continuous collaboration, a ready exchange of ideas, casual debate on the pro's and con's, and over time two things will happen:

1. Leaders will emerge; by corollary, followers will emerge in the '1 - L' space.
2. Leader/follower relationships establish correlation and cause-effect: movement by one causes movement by others, usually in the same direction.

If we were doing regression analysis, trying to predict the next move, the r-squared coefficient would be near 1 vis a vis leader impact on follower.

Now, to the extent that leaders influence followers, we have a sort of coupling.  Effects are transferred from one to the other; errors are not trapped at the boundaries.

The overall effect is that diversification, which depends on independence, slips away.  It's as if the followers are subsumed into the leader orbit and we're back to having only a few elements to set the average.  The opinion of one becomes the opinion of all.

Also, stability is now vulnerable to the appearance of a new leader 'star'

So, be aware that in the drive for diversification, it's self-defeating to establish the circumstances and environment for tight coupling.  There's something to be said for the virtual team after all!

(Did I mention I was describing the loss of diversity in a sequestered jury?  Perhaps I failed to mention how we citizens of Orlando reacted to a recent murder trial outcome.  And, it wasn't because the jury was from Tampa)

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Portfolio management and Agile

The Question

Are agile practices, like dynamic backlog, persistent teams, and emergent outcomes really compatible with the more laced up space of portfolio management?

The Answer

Perhaps....

Is there more?

With my colleague Alex Walton, we recently had an occasion to address the Central Florida PMI chapter with that question, and to give our perspective on the answer.  I've posted a link to the presentation in the slideshare below (see also: slideshare.net/jgoodpas )

We looked at two primary points that are in every portfolio manager's charter:

1. Drive business value, and
2. Take measured risks to do so

And we compared these with a few things that agilists really guard:

1. Maximum decoupling of outcomes from a big bang vision
2. Flexibility to subordinate cost and schedule to an emergent scope driven by the customer/user
3. Persistent teams that stress personal accountability and commitment, and engender high cohesion as a consequence of high trust.

Portfolios in the agile space (or perhaps the other way 'round)

Portfolioists (a new word: you read it here first) are all about getting maximum coherence among projects, between projects, and with any legacy system or product they have to support or tie into.  Coherence is a relatively simple concept: get mutual reinforcement; the sum is to be more better than the parts individually. 

Portfolioists want loose coupling among these otherwise coherent projects, and they want the coupling, such as it is, to be a network.  Why? Loose coupling traps bad effects from propagating; in effect, a rip-stop in the overall portfolio.

 Each project--network node--has a feature/functionality onto itself, but it also has relationships with other nodes (projects).  If a project (node) fails, as one must expect given the Standish numbers, then other project should have some capability to fill in. 

Portfolioists have a lever they can push and pull to cause redundant capability to spread among projects.  Thus, given a node failure, the portfolio value proposition presses on.  Agilists may not be too happy about being signed up for such redundancies!

And portfoliosts want to be able to allocate and distribute the assets of the business to effect the biggest bang for the buck.  But of course distribution may not be compatible with persistent teams: so another tension.

Agile in the portfolio space (corollary to the above)

Agilists may be sympathetic to the advantages of coherence, but that takes some of their flexibilty off the table.  So there's a tension to be sure.  However, to be effective in an enterprise environment, agilists have to suck it up a bit and be respectful of legacy requirements and API's or other interfaces already in production.

Agilists buy into loose coupling of projects on the network, so check off on that.

Agilsits are not loose coupling bigots of course.  Their preferred team architecture is about as tightly coupled as you can get.  All together physically in close proximity, an embedded customer/user, and a war room to put all the communication in one place.

To some extent, agilists are going to resist portfolioists who want to move resources around to meet business and risk objectives.  But, agilists are realists (there a lot of ...ists in this post!) and so will support the larger good; after all, it's their business also.

Anyway, here's the presentation for more reading:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The Information

There've been a lot of reviews about the book "The Information: A History. A Theory. A Flood" by James Gleick, a rather heavy tome, but nonetheless a readable history of information.  If you like a rich and engaging history, with a dollop of science and engineering, this is the one for you.

As reviewer Geoffrey Nunberg says: "Gleick ranges over the scientific landscape in a looping itinerary that takes the reader from Maxwell’s demon to Godel’s theorem, from black holes to selfish genes. Some of the concepts are challenging, but as in previous books like “Chaos” and “Genius,” his biography of Richard Feynman, Gleick provides lucid expositions for readers who are up to following the science and suggestive analogies for those who are just reading for the plot."

I couldn't agree more.  It's a great read!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

What is a system

I've been reading "Thinking in Systems: A primer" by the late Donella Meadows. Excerpts are readable at Amazon or Google Books.

I was taken in by the elegance and simplicity of her definition of a system:
(From page 2)

And, later from page 12, some similar words:

She opens the book by quoting Poul Anderson:

I have yet to see any problem, however complicated, which, when looked at in the right way, did not become still more complicated

I love it!  [And it's not as dry as the Defense Acquisition University's definition of a system as given in para 1.2 of their manual.]

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Contracting for agile

Have I posed an oxymoron, to wit: contracting for Agile?

Perhaps. Consider these agile values:

• Tight coupling among, and high cohesion between team members
• Maximum decoupling between deliverables, and decoupling between the deliverables and a pre-planned outcome
• Trusting relationships--all for one; one for all.
• Personal commitment and accountability for team performance
• Subordination of cost and schedule to customer satisfaction

There are more, of course, (check out the agile manifesto) but these are enough to consider how these value collide with, or are consistent with a contract environment.

Contracting has many purposes.  Among the top ten: expand the resource base, gain access to skills and environment, and transfer risk. 

But, in a flip of Agile values, a contract environment loosens the team member coupling and tightens the coupling between a plan and a deliverable. 

What about the cost-schedule-scope relationship? It's a rare SOW that begins: "The contracting agency does not value cost and schedule as much as it values outcomes".  That's a tough one to explain to the public constituency, and their representatives, who have a fixed-price retail market orientation.

And, most troublesome, a contract presumes low trust.  Indeed, a contract's so-called high ceremony--all the terms and conditions of a contract--is the antidote to low trust.  A consequence, if not a purpose, of a vehicle like a contract to institutionalize "low trust high ceremony" is an adversarial relationship.

To be sure, an adversarial relationship need not be unfriendly or acrimonious.  Some of my best friends are contractors!  And, I've been one myself.  However, parties to a contract are not really friends; they are parties to a joint interest in an outcome.  (in diplomacy: countries do not have friends; they have interests).  When stresses set in, the adversarial juices amp up.

So what to do?

1. Set in place a contract framework for all the T's and C's
2. On the agency side, parse the requirements backlog into work orders of scope for which the confidence interval is relatively narrow.
3. Freeze the work order requirements for development (call this an 'ice cube')
4. Push the ice cube through the contract channel as a work order
5. Reflect on the initial results; adjust the backlog; parse a next ice cube
6. Repeat until the money runs out.

In effect, this is a strategy of rationing emergence and scope by a funding cap.  However, in terms of answering the mail from the public constituents, each 'ice cube' should be worth what's paid for it.  In aggregate, the public should be, or may be, satisfied with the aggregate bag of ice.

Do you think this will work?

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

STS 135 Shuttle

From my home base here in Orlando, it's a short hour drive to the edge of the Kennedy Space Center grounds and the open viewing areas of pad 39 and the VAB. So, that's what I did this morning: a quick hour's drive, and then me and a million of my closest friends waited on the river's edge for an on-time launch (has that ever happened before?)

In any event, it was awesome and perplexing at the same time as a great program comes to a successful conclusion after 30 years launching (and relaunching) the most complex vehicle ever built by anyone. (Don't let'em tell you that complexity can not be conquered by a little skill and science)

And why exactly did the program end with five serviceable vehicles and an operational destination to go to every couple of months? I have no idea, and I doubt it's really money. Hopefully, manned space will press on from here as it did when the shuttle replaced Apollo.

And, haven't we been hearing there's a need for technical talent in this country; that's we not graduating enough, and not retaining trained immigrants?  Well, here's a technical workforce with numbers in the thousands.  Hopefully, we don't toss it away.

Photo: NASA

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

6 common pitfalls in risk management

Our friends at Eight to Late have a nice post on 6 common pitfalls in risk management. Click on the link to get all the details.

Of course in all things like this, there's a balance to be drawn.  For instance, in the first pitfall we are told not to rely too much on subjective judgment, followed by three or four others that tell us not to be trapped by quantitative analysis.

Oh well, what's an analyst to do?  Damned if you do or damned if you don't!

Nevertheless, a good list and worth a read!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Five things leaders do about innovation

Greg Githens has a succinct piece on leadership and innovation in a post entitled "Five Things Strategic Initiative Leaders Need to Know about Innovation"

Here's a quote from Githens' post, to emphasize his point that innovation may not involve new invention, and may not even be particularly creative.  Innovation may be mostly a matter of clever application:

The future is already here, it is just distributed unevenly.

Perhaps this is true, and likely so in a lot of cases.  But innovation is certainly more than finding the chairs, and changing their aggregation and on-deck arrangements.

To some extent it's about patterns: putting together a mosaic of disparate pieces in a unique way that no one would have thought about; and when I say "put together", that's probably better said as let things emerge as influenced by circumstances, feedback, invention, and intuition.

Frankly, innovators are gifted in ways that many left-brained folks will never be able to understand.  They can just "see it" when others see nothing.  In any event, if you have the fortune to be, or to be led by, a gifted innovator, more fun to you!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Qualitative risk factors

The Los Alamos National Laboratory is one of the U.S. Gov's national institutions that grew out of World War II, focusing today on a variety of strategic threats to global stability through science: nuclear, biological, and environmental, to name the big three.

So, it should come as no surprise that LANL has done a lot of thinking about risk management. I ran across one of their publications on qualitative risk management: "Risk Factor Analysis—
A New Qualitative Risk Management Tool", and was intrigued by the title, thinking: something new under the sun?  [No pun, but LANL is located in the US southwest desert]

Actually, RFA as they call it, is perhaps a new label on a fairly standard idea: putting numerical values on qualitative evaluations--better known as utility.  And then using the numerical values to do arithmetic, the results of which leading toward priority separations among.

I take some umbrage with the scientific minds behind this tool: substituting one label for another--eg "1" instead of 'L' (for low)--does not thereby enable arithmetic on the new labels just because they are numbers.  But don't take my word for it: consult the authority, Dr. Edmund Conrow who wrote the classic text that addresses this very issue:  "Effective Risk Management: Some keys to success" [and, also a bit of trivia, Conrow also wrote the risk chapter for number one all time "Project Management: A Systems Approach to Planning, Scheduling, and Controlling",  by Harold Kerzner]

Nevertheless, in their publication they have a very neat diagram, not altogether unique, but certainly compact, of a view of qualitative risk management.  Note the inclusion of 'budget'.  Nothing from the government would be complete without it.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Cockburn on thermodynamics

Many of us learned recently from Alistair Cockburn that he studied engineering in college and took a course in thermodynamics for which he received a passing grade. However, he declares: ....can't recall anything about thermodynamics. He asks: ....does that invalidate the worth of my degree?

No, his degree shows a pathway (his word) of self improvement and education. And, for the most part, a college degree is more of an indicator of ability to perform in an academic or theoretical environment than it is a measure of actual retention of the constituent knowledge base.

On the other hand....

It's most unfortunate for a software leader like Cockburn to not recall his thermo instruction, particularly the famous "2nd Law of Thermodynamics", and its most important spinoff: the concept of ENTROPY

What is entropy?
Entropy is a measure of randomness or disorder in a system. A stable system at rest has an irreducible non-zero entropy--that is: a finite amount of system capability that is present but not available to do work.

And from this stable state of equilibrium entropy can only go up as the system departs a bit from absolute stability as conditions change.

The practical effect is that some of the energy that goes into changing state is diverted into waste thereby raising entropy. In mechanical systems, this is most evidenced by waste heat. In other systems, like information systems, entropy effects are wasted memory, CPU cycles, and unused bandwidth.

The corollary: a system in some elevated state of instability can be made more stable. And, as stability increases, entropy decreases, and wasted energy (work * time) is leaned out.

Entropy for project managers

Now, in the modern practice of information theory and computer science, the concept of entropy is hugely important. The 2nd Law is alive and well!

As practical matter we really can't, or usually don't, measure entropy directly since it's not economic to discover the true minimum state of equilibrium.  What we do is measure the change in entropy:

• Every bit of non-value add work leaned from a process is a change in process entropy
• Every improvement in system downtime (rate of failure) is a change in system entropy
• Every improvement in design errors (error density of design units) is a change in design entropy

And, in a computer science application, the random energy created by random key strokes and other random processes is harnessed and put to work doing useful work in operating systems.  Windows, Linux, Unix, etc all use the entropy [energy of disorder] in this way.

In a past engagement developing and bringing to operations an ERP system in a large scale enterprise, my team was constantly aware of the entropy of our work product.  We didn't know the absolute stable state we might be able to achieve, but we had enough history to know we weren't there yet.

Our basic entropy metric was the rate of discovery of new problems.  This is modeled with a Poisson distribution with a average rate of 'lambda'. (drawing) 

Who do we blame for this complication of the body of knowledge (a search of the PMBOK does not bring up entropy)?

We blame the Bell System and the telephone industry.  Claude Shannon (in 1948) coined the term 'entropy' to describe the telephone bandwidth unavailable for communication purposes; in effect, the residual disorder and randomness in the communication channel after all means to get lean have been tried.  (photo)

Recently, a posting by John Baez, et al explains Shannon and the concept of only measuring the difference in entropy rather than entropy itself.  Baez is a little challenging to read, but hey: no pain, no gain!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.