Sunday, December 30, 2012

Men around women


Didn't we know this all along?
Men are dumber around women. Thijs Verwijmeren, Vera Rommeswinkel and Johan C. Karremans gave men cognitive tests after they had interacted with a woman via computer. In the study, published in the Journal of Experimental Social Psychology, the male cognitive performance declined after the interaction, or even after the men merely anticipated an interaction with a woman.

Friday, December 28, 2012

To meddle or to micromanage?


It's said that Winston Churchill was a bull that carried his own china shop! Always in action, never at rest, courageous, and a meddler-manager.

Meddler-manager is not the same as micro-manager. Churchill had numerous pet projects -- most of them either in technology or in off-the-books operations -- about which he generated uncountable ideas, all passed to the staff with "action this day!" tags.

Examples abound: floating tanks used at Normandy; the floating harbors, called Mulberry, that allowed for large ship logistics just off the beach; and the SOE (Special Operations Executive) that was a covert effort to assist resistance fighters in Europe.

He didn't micro-manage implementations, but he meddled incessantly inserting top down ideas of what should be done. Consequently, a lot of management energy that could have been directed toward project implementation went instead toward fending off the meddler.

Fortunately, meddlers are more often focused on results -- outcomes -- than process (the internals), so they are often process agnostic. But, meddlers are impatient, seeking immediate satisfaction. So any delay or extraordinary schedule only brings more meddling, and brings new ideas before the old 'new' ideas are fully baked.

The best defense is offense: constant flow of incremental outcomes that partially satisfy and provide short feedback about whats good and bad (right and wrong) about what's been developed (so far).  In other words, deliberate volatility generates the information and evaluation needed for validation and continuous improvement. In other words, over managing change management to the point of smooth sailing may close off just the kind of disorder that challenges improvement.

image by Sebastian Alvarez

Wednesday, December 26, 2012

War room -- for a project


Does this look like the dashboard for a 3-star running a zillion-billion dollar defense program?

That's Vice Admiral David Venlet in the photo, and that dashboard is the way he likes it: low tech, but informative.

Unfortunately for the Admiral-program manager, good and useful and timely program information does not necessarily beget good and timely program performance. This dashboard is for the F-35 fighter aircraft, and by all accounts this program is in big doo-doo.  Of course, that's what you'd learn by examining the data; so there's no mystery that the earned value for this project is way off the mark.

But, back to the dashboard. You can see from the panel on the left that there are many charts to show trend lines for measurements for several different metrics. Project flows are in the center panel, and then subsequent panels on the right document other project activities.

One unique aspect of this dashboard is that some of the data is for the design and development program for the aircraft, and some are for the production program. The acquistion strategy for the F-35 was to begin production as soon as there were design models that verified the likely performance. Simply put, that's a risky strategy, and if the assumptions break down, as they did in this program, all the dashboards in the war room can't put humpty dumpty back on the original track.

One metric that is on this dashboard is the sunk cost -- the actual cost to date. Some are saying that the program must go forward so that the sunk cost is not a waste. Others say you shouldn't make a decision on the basis of sunk cost -- only the future is relevant. So far, it's been decided that the future is relevant and the program continues.


Saturday, December 22, 2012

Antifragile -- things that gain from disorder


A good system is one in which the risks are visible
Nassim Nicholas Taleb


Nassim Nicholas Taleb, most famous for authoring "The Black Swan: the impact of highly improbable fragility", has a new book: "Antifragile: things that gain from disorder"

 
He says in the new book that he wants this book to be the definitive explanation of the spectrum of fragile (read: Black Swan, incalculable risk), robust (read: survivable, calculable  risk), and antifragile (read: risk driven improvement).

In a few words, his points are these:
  • Fragile systems can not absorb shock; they break, they fail, and they do great harm when they collapse
  • Robust systems can absorb shock, but robust systems are no better off after the shock than before; they don't learn or improve from the experience
  • Antifragile systems not only can absorb shock, but the disorder/disruption is actually fuel for innovation and improvement. They next shock will have less effect; any new system will build upon the disorder of the past and be better. 
Mulitple systems
And, we're not talking physical systems necessarily; all manner of human factors and biological systems are included, along with political systems, etc.

One example he has given in a television interview was comparing a taxi driver and an office worker. The former deals with the uncertainty of business every day and constantly adapts to stay afloat economically; the latter, if laid off suddenly, is devastated and adrift. The former is antifragle (because of constant learning and adaption); the latter is fragile (because shock is unstainable)

In business, he says the restaurant and aviation sectors are antifragile, constantly learning from mistakes, and the financial industry is fragile -- vulnerable to black swan events.

Domain sensitivity
Taleb makes the point that the qualities of antifragile are at the same time domain dependent -- that is, context sensistive -- and domain independent -- that is, it is valid to represent the phenomenom in one domain with similar characteristics in another domain, though often we miss this cross domain connection.

Taleb wrties:
"We are all, in a way, ... handicapped, unable to recognize the same idea when it is presented in a different context. It is as if we are doomed to be deceived by the most superficial part of things, the packaging...."

Redundancy and risk management
We learn this about risk management:
"Layers of redundancy are the central risk management property of natural systems. ... Redundancy ...seems like a waste if nothing unusual happens. Except that something unusual happens— usually."

Project context
Almost every project I know of embraces continuous improvement. But to make it effective, CI should be paired with reflection, investigation of root cause, and actionable strategies. These get at the learning component of being antifragile.

Actionable strategies begin with a dolop of system engineering: decouple where possible to trap problems before they propagate. Decoupling is most often accomplished by modularity and defined interfaces.

And then we add redundancy -- equivalent capabilities implemented in different ways decoupled for independence -- and cohesion.

Cohesion is the property of absorbing shock without failure. We get at this with buffers, redundancy, and elastic physical properties.

The final test
Taleb gives us this as the final test:
[We] .. detect antifragility (and fragility) using a simple test of asymmetry: anything that has more upside than downside from random events (or certain shocks) is antifragile; the reverse is fragile.


Delicious Bookmark this on Delicious

Thursday, December 20, 2012

How old is the wine? Exposing risk


Mike Cohn has a posting on a "risk exposure burn down chart".

It's a take off on the more familiar object and task burn down chart applied universally in agile. Mike's chart is pretty straight forward: Estimate the risk impact (as modified by likelihood) and call this 'risk exposure'. When the risk is mitigated, or passes by without impact, the exposure is burned off.


Nice. But is this old wine in a new bottle?

Exposure
Some years ago -- actually, many years ago -- I took over a department of about 85 engineers, mostly system engineers, with a budget (then) of about $10M annually. One of the first things my new boss asked me to do was to figure out what my (our) exposure was.

Exposure? I understood this to be a question about risk, but what's the metric here, and how do you measure for data? For instance, the metric could be scope exposure, schedule exposure (as in Mike's chart), quality, or budget. Or, it could be some other "measure of effectiveness" -- MoE -- that was applied in the various programs.

In the moment what my boss was asking for was an estimate of the budget risk (impact and likelihood) that was lurking in the work package assigments to which my department engineers had committed themselves.

That $10M department budget was all signed out to various projects for work that had to be done, but what if the work could not be done for $10M? How much risk was there for me as department director and for the various program managers who needed the work done?

So, I had my metric: monetized budget; and I had a way to measure it.

Management and Monte Carlo
What I did, of course, was build a version of a risk register, much like Mike's but with some differences that account for risk management: for each work package, I asked my WP managers to give me a 3-point estimate (no single points allowed!) of the  remaining effort required to get 'done' (cost-to-complete according to a completion standard more or less understood by all -- a similiar idea exists in agile, of course).

A Monte Carlo simulation of the WP estimates gave me -- actually, my business analyst -- a single point measurement (expecgted value statistic) to compare with the single point budget. Each statistic value is a deterministic number so I can do arithmetic on them. Of course, the optimistic, ML, and pessimistic numbers are random numbers -- values in a distribution -- so I can't do arithmetic with them, except by simulation. Thus, their columns are not added.The difference in these two points was my (our) exposure measured as the risk weighted expected value of the portfolio.

The spreadsheet below illustrates how it was done:


Tuesday, December 18, 2012

Andreessen's motto


I was amused to hear Marc Andreessen say his motto is
"Often wrong; never in doubt!"
You might say supremely confident, even a touch of arrogance that he'll find the way out, no matter the hole he's in (First rule of holes: stop digging!)


In any event, if you've not been exposed to the rapid fire delivery of Mr Andreessen, there's an interview with him on Charlie Rose that you might like. And, as always, Andreeseen specializes the 'next big thing'.

Sunday, December 16, 2012

Decision models for business rules


If you're a business analyst or requirements analyst then a good deal of your time is devoted to business rules and the way those rules are represented in requirements, use cases, and user stories.

Modernanalyst.com has recently posted a couple of essays on decision models and the way that the underlying  individual decision tables are integrated into a more macro view of the decision model.

Part I is entitled Why Decision Tables are not enough: From Decision Tables to Decision Models and Part II is a follow-on: More on Decision Tables and The Decision Model in Practice

The authors posit that decision tables should be treated like any other relational table in a relational paradigm, thus requiring adherence to certain rules for building information by rows and columns. For instance, decision tables should follow the normal rules of normalization, which in a few words, removes redundancy and generally provides for the maxim about data: "enter once, use many"

From the first essay that presents a six step process for building decision tables we learn that we can expect:
...  a deliverable that is more valuable than its pieces. The resulting model is:
  • Comprised of the most atomic pieces of business logic (no Ors, no ELSEs, no OTHERWISE, one conclusion fact type)
  • Based on disciplined fact types
  • Normalized to minimize redundancies
  • Predictable in structure and
  • Aligned with business performance and directions.
From the second essay we learn that the benefits of decision tables are explained this way:
  • A decision table is an intuitive visual representation. This circumvents the need for other less friendly representations – such as formal language, strict grammar rules or fill-in-the-blank sentence templates.
  • Both business people and technical professionals understand a decision tableif it is devoid of technical artifacts.
  • Some forms of incompleteness, inconsistency, and redundancy become visible ina decision table.
  • Certain technologies lend themselves to easy automation of decision tables. In fact, most Business Rule Engines (or Business Rule Management Systems, BRMS) accept decision tables as a format for creating and making some changes. That’s because automation ofdecision tables into such engines is fairly straight-forward.
These essays have a good exposition of the author's ideas, but there is a supporting 20 page "primer" (in pdf format) about decision models that is worth a read. You can find it -- after free registration -- at this location.