Thursday, October 13, 2011

Complicated, complex, and complex adaptive

"Complicated, complex, and complex adaptive": We see these terms a lot in the project business. I'm ok with the first two; the last one is a bit dubious for project managers in my opinion.

Here's some definitions. The first is taken from an interview with Michael J. Mauboussin by Tim Sullivan in the September 2011 edition of the Harvard Business Review, an issue that is dedicated to complexity:

A complex adaptive system (CAS) has three characteristics. The first is that the system consists of a number of heterogeneous agents, and each of those agents makes decisions about how to behave. The most important dimension here is that those decisions will evolve over time. The second characteristic is that the agents interact with one another. That interaction leads to the third—something that scientists call emergence: In a very real way, the whole becomes greater than the sum of the parts. The key issue is that you can’t really understand the whole system by simply looking at its individual parts.

And here's by Gökçe Sargut and Rita Gunther McGrath writing in an article in the same issue on the difference between complicated and complex:

Complicated systems, they say, have a lot of parts, but the parts interact in patterns of behavior we know and understand, and can reasonably predict.

Complex systems are versions of complicated systems wherein the patterns are there but difficult to know about (too many, too obscure, or outside our normal experience) and the interactions, though predictable, are too difficult to predict as a practical matter.

They observe:
Complex systems have always existed, of course—and business life has always featured the unpredictable, the surprising, and the unexpected. But complexity has gone from something found mainly in large systems, such as cities, to something that affects almost everything we touch: the products we design, the jobs we do every day, and the organizations we oversee.

Well, I buy the complex and complicated thing, but every example of CAS that anyone gives is more often biological than not. After all, the biological sciences has been the doman that has advanced the study of CAS the most.

What about agile?
Many say agile methods are themselves an example of CAS because of the property of emergence, and the myriad of agents (developers, testers, stakeholders, sponsors, customers, users et al) that are in constant interaction. Perhaps so. But I don't see agile projects and ant colonies acting the same way. There's simply too many intervening structures, inhibitions, rules, and constraints, to say nothing of project charters, vision, product managers, and market forces that focus the project.

As others have said, it's often nonsensical and many times misleading to cross domains too readily. For my money, I buy into emergence, and I buy into output effecting input (a necessary condition for adaption), but most of the other biological instinctive and survival behavior of ants is not what projects are about.


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

Tuesday, October 11, 2011

Traps when thinking in systems

I've pointed to "Thinking in Systems: a primer" by D. Meadows in prior posts, and here I go again, largely because I think she's offered a lot that is useful to managers of all stripes, not just systems people.

Here's an abridged list of 'traps' she cautions against, a list of ills we should all be cautious about:
Success to the successful
If the winners of a competition are systematically rewarded with the means to win again, a reinforcing feedback loop is created by which, if it is allowed to proceed uninhibited, the winners eventually take all, while the losers are eliminated.

The Tragedy of the Commons
When there is a commonly shared resource, every user benefits directly from its use, but shares the costs of its abuse with everyone else. Therefore, there is very weak feedback from the condition of the resource to the decisions of the resource users. The consequence is overuse of the resource, eroding it until it becomes unavailable to anyone.

Drift to Low Performance
Allowing performance standards to be influenced by past performance, especially if there is a negative bias in perceiving past performance, sets up a reinforcing feedback loop of eroding goals that sets a system drifting toward low performance.

Rule Beating Trap
Rules to govern a system can lead to rule-beating-perverse behavior that gives the appearance of obeying the rules or achieving the goals, but that actually distorts the system. Rule beating is usually a response of the lower levels in a hierarchy to overrigid, deleterious, unworkable, or ill-defined rules from above.


Seeking the Wrong Goal
System behavior is particularly sensitive to the goals of feedback loops. If the goals-the indicators of satisfaction of the rules-are defined inaccurately or incompletely, the system may obediently work to produce a result that is not really intended or wanted.
  Are you on LinkedIn?    Share this article with your network by clicking on the link.

Sunday, October 9, 2011

The forest for the trees

We are all taught from the first moment that the way to eat an elephant is one bite at a time. That is: to work on a complex problem, always start by simplifying the task by decomposition, disaggregation, and separation of the trees from the forest.

Ok, but what about this: (think: object = tree; distant background = forest)


In a posting on "Azimuth", John Baez has a part I discussion of evolution in complex systems from which the diagram, above, is taken.

In addition to the distortion arising from the point of view from which data is viewed, he goes on to caution about the the Dunning-Krueger effect (the uninformed, misinformed, and ignorant are biased to not understand their own cognitive deficiencies), saying, in part:

... if we don’t understand a system well from the start, we may overestimate how well we understand the limitations inherent to the simplifications we employ in studying it.

But, it's not only trees: it's also use cases and user stories, and then ultimately Test-Driven-Development scripts, all decompositions that have the potential to alter perspective.

Thus, constant attention to "re-composition" to validate low level requirements with high level vision is necessary. That is the essence of the "V-Model", a bit of system engineering that we can all take advantage.

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

Friday, October 7, 2011

To Push or not to Push

A lot's been written about Steve Jobs' legacy at Apple since his decision last month to step down from CEO and remain only as chairman. Unfortunately, Jobs died Oct 5th.

Among the anecdotes told and retold is his oft repeated anti-LEAN doctrine: features and functions are to the PUSHED to the customer because, he says:

It’s not the consumer’s job to know what they want

And it's not only Apple.  Sony has also been said to have not consulted any outsiders regarding the Walkman.  Again, when it's "new to the world", what's a consumer to say?  Hit, or no hit?

Well, what would the LEANers say about that? The Lean mantra, of course, is to pull consumer requirements from the customer, not push them (arrogantly) from the developers/stakeholders to the consumer.

And, what would the agilists say? Apple most assuredly does not embed customers/users on its product teams. They, perhaps as much as any competitive innovator, guards their intellectual property and marketing plans as closely as any. One only needs to go back to the infamous case of the lost/stollen iPhone prototype to see them in action.

That's not to say that a product manager internal to the company is not closely consulted on new products, but on the most important features and functions, hardly any less than Mr Jobs himself makes the final decisions.  Others need not apply

Conclusion: Alistair Cockburn may have been spot on when he said: any methodology can be made to succeed in some situations; any methodology can fail.  Perhaps, as it always has been: inspirational vision, leadership, commitment, and methodology.

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

Wednesday, October 5, 2011

Now on Kindle

If you would like to follow "Musings" on your Kindle, now you can. "Musing" is published concurrently to the Kindle blog store and is available on a monthly subscription.

Just search the Kindle Store for "blog john goodpasture", and you'll get there.




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

Monday, October 3, 2011

Sins of progress

Paul Solomon, an industry guru in earned value, has an article in a recent edition of the "Journal of Software Technology" (August, 2011, vol 14, number 3) that lists a number of sins that distort progress. I'm sure of none of you reading have done these things, but I repeat Paul's list so you can be aware.

Among his observations and examples of misuse and abuse of the project's management reserve (MR), he lists these tricks (paraphrased and translated for the non-defense project audience, so these are not a direct quote of Solomon's remarks)
Rework--in other words, error of feature, function, or performance requiring correction--is not included in the budget (though it's reasonable to expect some rework as part of the natural variation in the design and development processes). Rework is identified as a risk (on the risk register) and money to fund the risk response is included in management reserve (MR). Later, funding is transferred from the reserve to the budget when the design or test item does not meet, or no longer meets, technical requirements.

Cost drivers such as software lines of code (LOC), number of drawings, hours per drawing or per LOC, are understated (justified as aggressive interpretation of bottom up estimates) compared with empirical data and realistic estimates.  The low ball estimate is called “management challenge” and identified as a risk, not an issue. Later, funding from the management reserve is transferred to the budget to cover the risk.

The same conditions exist, as above, but no “risk” was identified. Instead, the additional iterations are called “scope growth” even though the basic tasks were planned in the budget
The number of tests (and resultant rework and problem reports) is understated based on realistic estimates and empirical data. Later, the tests and rework needed to meet technical requirements are funded from MR as “additional scope” even though the customer requirements are stable.

Work that could not be completed internally is transferred to a supplier. MR is used under the pretext that it is “additional scope” or “unplanned.”

So, you might ask: what's the management reserve for if not to fund problems not foreseen? That's Paul's point exactly: rework--at least to some extent--should be in the baseline so that the project's cost is not a matter of deliberate deception. So also for the other practices. In other words, trust and integrity, so valued in the implementing teams, starts at the top. No news there, but never a bad thing to review.

Of course, these practices are not exclusively in the defense domain. Try big time construction if you want more examples. This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"

Good grief! Is there no one on top of this?

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

Saturday, October 1, 2011

Quotation for today

Did you know this little tidbit?
Wall Street hires more math, engineering and science graduates than the semiconductor industry, Big Pharma or the telecommunications business

Need an example? Consider Salman Khan, an MIT graduate, who went from school to Wall Street. But after a few years, found himself doing something a lot more useful: he founded the Khan Academy.

Would that others follow in his footsteps!

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