Wednesday, December 12, 2018

Behavior v Outcome

You have to give Jurgen Appelo high marks for imaginative illustrations that catch the eye and convey the thought. He says this is one of his best illustrations ever; he may be right. He calls it his "celebration grid". I imagine Jurgen will be telling us a lot more about this if it catches on.

But what he says about these grid points is the more important take away:

  • “Celebrate failure” is nonsense, because you shouldn’t celebrate failure that comes from mistakes (the red part). What you should celebrate is learning, and repeating good practices (the green parts).
  • Pay-for-performance tends to drive people away from experiments, toward the safe practices on the right, with little learning as a result. 
  • Hierarchies are good at exploiting opportunities, and endlessly repeating the same practices; but they learn very little. 
  • Networks are good at exploring new opportunities, and failing half of the time, but they’re not good at efficiently repeating practices.
File this under leadership for learning and motivation, change management, managing team dynamics, and carrot and stick.

Buy them at any online book retailer!

Sunday, December 9, 2018

Failure or faults?

Does software fail, or does it just have faults, or neither?
Silly questions? Not really. I've heard them for years.

Here 's the argument for "software doesn't fail":
Software always works the way it is designed to work, even if designed incorrectly. It doesn't wear out, break (unless you count corrupted files), or otherwise not perform exactly as designed. To wit: it never fails

Here's the argument for "it never fails, but has faults":
Faults refer to functionality or performance incorrectly specified such that the software is not "fit for use". Thus in the quality sense of "fit for use" it has faults.

I don't see an argument for "neither", but perhaps there is one.

However, Peter Ladkin is not buying any of this. In his blog at "the Abnormal Distribution", he has an essay, a small part of which is here:

What’s odder about the views of my correspondent is that, while believing “software cannot fail“, he claims software can have faults.

To those of us used to the standard engineering conception of a fault as the cause of a failure, this seems completely uninterpretable: if software can’t fail, then ipso facto it can’t have faults.
Furthermore, if you think software can be faulty, but that it can’t fail, then when you want to talk about software reliability, that is, the ability of software to execute conformant to its intended purpose, you somehow have to connect “fault” with that notion of reliability.

And that can’t be done.

Buy them at any online book retailer!

Thursday, November 29, 2018

Resume tic's

Want a job in "big business", or want to pursue "gigs" with the big guys?
Here's some resume tic's from the those that know the General Motors' needs:
The "new" GM will want workers who are highly creative and capable of working autonomously as well as collaboratively. 

The future employee will take initiative and have a strong technology background, good communication skills, and project management capability
Well hello! That's a prescription right out of the PM playbook
  • Communicate
  • Collaborate
  • Create
  • And, did I mention: initiate!

Buy them at any online book retailer!

Monday, November 26, 2018


MIT is to open a new College of Computing.
That's nice for them

Of note, however, is this bit from L. Rafael Reif, MIT President, as quoted in the press
The goal of the college is to "educate bilinguals of the future"
And, to be clear, bilinguals are people whose 'other interests' are -- among others -- biology, chemistry, politics, history, and linguistics who are skilled in the techniques of modern computing that can be applied to them
Who said IT guys are one-dimensional? No longer; they can be bilingual
And, by extension, so can the project managers of the world be something other than PM-nerds
We can learn other languages as well!

Better yet: we can be multi-dimensional in both knowledge and wisdom -- what a concept!

Never stop learning is probably the right take-away!

Buy them at any online book retailer!

Friday, November 23, 2018

Great project management

Give pause to this insight:
"The mark of a great ship handler is never getting into a situation requiring great ship handling"
Admiral Ernest J. King
The paraphrase is obvious:
  • The mark of a great project manager is never getting into a situation requiring great great project management

Buy them at any online book retailer!

Tuesday, November 20, 2018

Initiative and independent action

From Viscount Nelson, victorious British commander in chief at the naval battle of Trafalgar, we get this insight for initiative and independent action, as described by Admiral James Stavridis in his book "Sea Power":
Nelson knew he would not have clear and instantaneous communication ... [making] precise command and control impossible.
As [Nelson] said in his [planning] memorandum: "Something must be left to chance; nothing is sure ... "
"In case signals can neither be seen or perfectly understood, no captain can do very wrong if he places his ship along side the enemy ..."

So, there's some good stuff there for project managers:
  • Don't lean heavily on the idea you will always be in touch when it matters
  • Accept the idea that command and control systems have their limits; other processes work also
  • Do think it through and commit to a plan -- even though the plan itself may not survive first contact with project reality [some would call this making an estimate .... gasp!]
  • Set expectations and then unambiguously delegate authority to meet those expectations
Something to be avoided:
  • Nelson was killed in the battle, taking one risk too many 

Buy them at any online book retailer!

Saturday, November 17, 2018


So, I'm just catching up with the buzz about blitz-scaling, the business model that says:
Get to scale fast! Actually, get to even larger scale even faster.
Blitz your way there!
Only the fastest to scale wins; there's hardly a spot for number two
One might ask: What's the debt and debris accumulated in blitzing scale?

Reid Hoffman has an answer in his book, titled no less than: "Blitzscaling: The lightning-fast way to massively valuable companies"
  • Conventional process-oriented decision making supported by "facts" and analysis of risk, discounted cash flow and the like, are out
  • What's in is speed, decisions based on instinct and partial data, and a willingness to pay the downside if risks don't work out
Ok, almost anyone could imagine that deregulating is going to allow speed with some broken glass along the way.
In the past Reid argues, business put a high value on not breaking the glass.
Efficient and predictable processes with predictable outcomes was king.
  • Remember the "Theory of Constraints" developed in the early '80s: Efficiency in resource utilization was the answer to better business
  • Remember: the customer is always right?
  • Remember: product quality counts very high --- 1950 quality ideas and 1990 error management (Defined process control; Quality is free, Six-sigma etc)
According to Reid: all good stuff, but too slow!
  • Speed is almost axiomatically opposite efficiency. Many resources will be wasted when you go as fast as you can
  • Don't let the customer get in the way; customers are notoriously cautious adopters
  • Quality can come later; get a product out there and set the frame 
If you read my post on the evolution of Agile, you'll recognize the connectivity of blitz-to-scale with the evolved principles

Buy them at any online book retailer!