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.