About Teamwork

This quote says it all

"By design and talent, we were a team of specialists, and like a team of specialists in any field, our performance depended both on individual excellence and how well we worked together. None of us had to strain to understand that we had to complement each other specialties; it was simply a fact."

Bill Russell
Boston Celtics

Confidence and a matter of range

It's all a matter of confidence: confidence in statistical terms is the cumulative probability over a range of values.  It's a little more handy for project managers because it only expresses an approximation and a judgement, and both of these ideas allow for some leeway.

Using a bell-shaped Normal (probability density) distribution as an example--and, because of the Central Limit Theorem, this is a reasonable example to look at-- risk managers calculate cumulative by summing the height x width area under the curve.  In the figure, we see the so-called "S" curve superimposed on the distribution.  The "S" curve is the cumulative probability.

Confidence is an expression of cumulative probability over a range.  In the example shown, the confidence is "outcome will be equal to, or less than, 4 in 81% of the trials".  Obviously, the 81% is calculated by subtracting 19% from 100%.  The "precision" here is just an artifact of the tool.  The judgement is about the "80 - 20" rule, and the figure is an illustration.

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

Quantitative Methods -- Quote for thinkers

The original statement of the principle: "garbage in .... garbage out"

Mathematics may be compared to a mill of exquisite workmanship, which grinds you stuff of any degree of fineness; but nevertheless, what you get out depends on what you put in; and as the grandest mill in the world will not extract wheat-flour prom peascods, so pages of formula will not get a definite result out of loose data.

- Quarterly Journal of the Geological Society of London, Volume 25, 1869, Lord Kelvin, when speaking of the calculations of the age of the earth

That pesky schedule variance thing

Ever once in a while the argument comes up about EV -SV, the schedule variance in the earned value management (EVM) practice.  Hopefully, everyone reading this knows EV is earned value and PV is planned value, but some know it as Work Performed (WP) - Work Scheduled (WS), or as the DoD Gold card presents it: BCWP - BCWS.

Any way you write it, it's more useful to understand it as a value variance.  After all, it is the difference between two values--earned and planned--denominated in dollars; neither are a cost--both are a value measurement.

The nice thing about thinking about this as a value variance rather than a schedule variance is that the thought is consistent at all the boundary conditions and points.  One boundary point is where EV reaches PV--all the planned value is earned.  The EV - SV calculation is now $0.  As a value variance: no conceptual problem: all the value has been earned.

As a schedule variance, we have to think like a pretzel to explain how the variance can be zero under two of three boundary conditions: the project finishes early, the project finishes on-time, the project finishes late.  In all three cases, the variance can be zero  (if all value is earned) but the three conditions are really quite different vis a vis schedule variance.  Zero schedule variance doesn't compute; they share only one attribute: the value variance is zero.

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

Studying Engineering Before They Can Spell It

Silly me! I have not been keeping up with the fact that engineering education now begins in kindergarten, at least in some schools around the country. And, this has been going on for a while! Who knew?
In a recent article, I was pleased to learn that in New York, for example, ".....Glen Rock school district, about 22 miles northwest of Manhattan, now teaches 10 to 15 hours of engineering each year to every student in kindergarten through fifth grade, as part of a $100,000 redesign of the science curriculum."

Of course, now aware of this phenonenom, I see from a web search that K-12 engineering is all ove the place.  As an old wreck from Georgia Tech, I say: amen!

Photo credit: Ozier Muhammad/The New York Times

Software Human Capital

Software human capital is the theme of the May/June 2010 "Crosstalk: the journal of defense software engineering". Five essays in this issue raise interesting questions and offer some interesting ideas on managing and utilizing human resources in software projects.
One that caught my eye was "From Projects to People: Shifting the Software Acquisition Paradigm"
After reciting a litnay of defense acquisition problems, the authors arrive at the conclusion that more talented people are needed: Here's the main idea:

Establishing a National Systems Engineering Laboratory

Quality and schedule could be met (at least within a consistent cost and schedule margin) if we fundamentally shift our acquisition paradigm: from program-by-program cost and schedule management to a focus on the quality of people used to feed our engineering teams. This would be accomplished by establishing what we call a National Systems Engineering Laboratory (NSEL). ..... The NSEL would also be cooperatively staffed with selected personnel from our universities, federally funded research and development centers (FFRDCs), and government services.

There might be some merit to a national effort to build more and better system engineering; perhaps a DARPA like laboratory for this would help stimulate the effort.  Perhaps the author's have an idea worth talking about.

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

Complexity and Complicated

Complicated, says Dan Ward, is unnecessary complexity.  How does this work for you?

Balancing Agility and Discipline

Barry Boehm and Richard Turner wrote an interesting book a few years ago, entitled "Balancing Agility and Discipline: A guide for the perplexed". 

Boehm, of course, is the author of an early, agile risk management strategy and practice called the Spiral Method.  The neat thing about the spiral is that it is like the wind-up of a discus thrower: it can be used as the launching method to a methodology, like one of the agile methods. 

So, it is fitting that Boehm and Turner would write a book on agile--though no one would mistake Boehm for an agilist--since the spiral and any of the agile methods actually fit together.

Boehm and Turner's theme in the book is that discipline works in any methodology, and is essential to predictable performance.  Agile is no exception.  In an interesting twist, there are three endorsements for the book in the form of forwards: Grady Booch, the guru of object oriented practices and a proponent of methods that are arguable not too agile, says he understand's Boehm's point; Alistair Cockburn, author of perhaps the least disciplined of the agile methods is on board also; and Authur Pyster, the CIO at the FAA at the time, certainly no source for agile methods, says FAA is trying to be agile where they can, even though they have truly mission critical software.

For me, the interesting part of the book is the appendices.  Check out appendix E which is metric comparison of performance expectations.

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

The Complexity Cycle

Dan Ward has a nice treatment of complexity in a oft-cited paper: "The Simplicity Cycle: Simplicity and Complexity in Design".  In fact, Dan writes a lot and his other stuff, more or less is collected on a separate site.

Dan's main points are built around this diagram that plots "goodness" vs complexity.  Of course, there's no precise definition of goodness, but it could encompass everything from functional usefulness to design maturity.

Progress along the complexity slope is defined as learning and creating.  At point 2, the path reaches a point of divergence.  Driving to the upper left is more complexity but less goodness, a path called "complicated".  In this paper, complicated is "unnecessary complexity".  This is where non-value added components creep in: either unneeded redundancy or not needed parts.

In the other direction is the simplicity slope.  The idea here is to prune and pear, and to tighten up cohesion and coherence, and introduce looser coupling.  This is not to suggest that an optimally simple object is not complex; indeed, the simplest implementation may still be complex on any objective scale of complexity.

Winston Churchill: "Out of intense complexities complex simplicities emerge".

  

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

Duelling quotes and Prediction

Glen Alleman had a recent quote at his blog, Herding Cats, from the renowned theoretical physicist Niels Bohr: "Prediction is difficult--especially the future"

Sometime earlier, Chinese philosopher Lau Tzu is credited with another insight:
"Those who have knowledge, don't predict. Those who predict, don't have knowledge.”

And, from a source unknown, the widely quoted: "If you have to predict, predict often!"

All to say: the future is not always a deduction from the past.  Indeed, the past may give no clue at all.  Beware any prediction that is calculated.  We tend to predict about things we are familiar with, and worse: we tend to predict the things that are suggested to us!

5 levels of Agile Planning

A nice summary of agile planning over several time cycles is given in this figure posted at the agilejournal.com

There is a pretty good white paper to go along with the figure, entitled "Scaling Agile Processes: Five Levels of Planning".  Fortunately, to give some credibility to his thesis, the author says right up front that agile methods don't scale to enterprise level without some changes!  He is so right.

But even large scale organizations, like DoD, have embraced some tenants of agile methods.  You can check out some of the references to DoD practices in the white paper I wrote on agile in the DoD.  Or, you can take a look at one of DoD's software journals, "Crosstalk" and search the journal for 'agile',  at the Software Technology Support Center.  Or, give a read to "Project Management the Agile Way: Making it work in the enterprise"

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