Thursday, July 24, 2014

Behavior Outcome Success Failure

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.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Monday, July 21, 2014

Business case -- the case for communication

I picked this up from an email blast from Mike Clayton entitled  "It isn't all logic". He's writing about business communications in general, and that's fine, but as PM's the business case is often the first business document we address.

So, think of brother Mike's comments in the context of the business case you're about to write.

Mike says:

We might think we use data and reason to make our decisions at work, but on most occasions, we'd be fooling ourselves. Never under-estimate the impact of the intangible, the informal, and the downright irrational.

Who are you? 
Before we consciously process an argument, we unconsciously assess the person who is making it. So always ensure you make some reference to your credentials early on: why should I trust what you are advocating? The elements to consider include: your experience, expertise and knowledge; you background, honesty and integrity; and understanding f the issues and how they affect me.

 What do I care? 
 Psychologists are divided. Some say we make our decisions based almost entirely on emotional factors. Others say we make our decisions based entirely on emotional factors, and use the logic of an argument to justify our decision to ourselves. Either way, you have to show me why it matters and appeal to my sense of justice, fairness, compassion, outrage, fear or some other emotion.

 What's in it for me? 
 When you get around to the facts, this will be the question I most want answered. So you need to look at your proposal from my point of view and give me the answer to 'why?' Put this in early - almost as soon as you have laid out your credentials. You are not writing a novel, so I'll want you to get to the point quickly; not keep me in suspense.

 Keep it simple
 Fewer reasons are better than more reasons. Lots of reasons are worst of all. The more reasons you give, the more I suspect you lack confidence because each is weak. Pick your best and give me one, two, or three reasons; no more.

Keep your language simple too
No one buys from someone they don't understand (except some rich people when they buy technology). All of the costs.  Three benefits or fewer, but but give me all of the costs, risks and down-sides of your proposal. If not, I will have a reason to blame you later, if the decision I made to agree with you turns out to be wrong.

 Anticipate my objections
 Take all of the wind from my sails by listing any concern a decision maker might have and addressing them all, on-by-one.

 Make it compelling The average business case is dull to the limit of endurance. You are not writing a novel, but you do want o be read. Use a straightforward structure that flows logically from one section to the next, answering questions in a sensible sequence with well-chosen evidence and examples.

Craft your language with care and keep it short and sweet.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Thursday, July 17, 2014

Agile and Earned Value Management (again)

I've been on this horse before, but it's worthy of another ride. I've just completed a new white paper on Agile and Earned Value Management that you can read/download on

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Monday, July 14, 2014

The best lecture ever

The best lecture ever? That may be a bit over the top, but George McKeon tells us that for him, the best lecture he ever heard had these attributes which we can all take to be communication "must do":

1. You can’t communicate what you haven’t defined.
2. Lose the slides and have a conversation. (Of course, some executives want the slides!)
3. Kill your darlings. (In our world, this is be even handed and show no favorites)
4. Be repetitive without being boring. (In our world: tell them what you are going to tell them; tell them; tell them what you told them)

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Thursday, July 10, 2014

Conversation going nowhere

Sometimes, a conversation -- or, if you like, a communication or collaboration -- actually goes nowhere and just takes up time and space. All talk, no action...

There's no news there; anyone and everyone can make that observation -- and probably has.

Fair enough, so what's new to know about this?

Perhaps, this framework, given to us by Sirini Pillay
  • Beware the illusionist: a talker -- these days, a text'er or email'er -- who really has no intention of action. Actually, these people acquire a reputation for illusion so they are less a threat to progress than you might imagine, since people work around them
  • Beware of compassion and sensitivity: Emote according to circumstances; these emotions often don't work well in business-business negotiations, to take one case. A hard edge may work a lot better
  • Beware delusional consensus: A cousin of group think, wherein, during the conversation, everyone seems to buy in and go along, but back in the day-to-day: No way! and no action is taken. All kinds of anecdotes have been proposed over the years, like active listening, flow-down strategies, scorecards, and other "skin in the game" notions.

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Monday, July 7, 2014

Motivating, engaging, and authentic

John Coleman and Jim Whitehurst tell us in this posting that if -- as a leader -- you're looking to move from "command and control", then you could do a lot worse than moving to a style with these attributes:
  • Motivating to impart purpose: a great way to attract followers, especially followers who have genuine choice (if you have no followers, are you a leader?)
  • Engaging and adapting to the pace of business change. Of course that advice has been around since the first industrial revolution and the invention of industries to replace cottages, but Lord knows every time you look up somebody's got a better plan than you do, and
  • Being authentic. Some leaders just are not people-oriented, and they don't look authentic trying to be. 
So, among these three, I can relate best to the first one; my thinking (call it a bias) was summed up nicely by AliFarquhar, one of those who commented on the posting:
Leaders need to shift their identity from all-knowing experts with the right answers to adders of value through culture stewardship, vision, influence, and the right questions.

Meanwhile, those lower in the chain need to shift from a mentality of "it's theirs and anything that goes wrong can be blamed by pointing the finger upwards" to "it's ours and we own the results as well".

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog

Wednesday, July 2, 2014

Agile as a recursive methodology

In the past I've described the "grand bargain" that has to be struck between sponsor and project. In effect, to repeat a bit, the "change" is first with the management paradigm of fixed-scope for a fixed price.
The essence of agile is unfixed scope -- tactically -- with a fixed scope framework strategically.
Thus, by example, if we enter into a project to build a software shopping cart, a functional cart is the strategic objective of the project.
  • There is a general framework of functionality for such a cart agreed to in the business plan and the project charter, but
  • Many of the detailed feature/function/performance artifacts and objects will "emerge" as conversations go forward during the course of the project;
  • In other words, feedback of early deliverables will influence later deliverables.

In that sense, agile is a recursive methodology in that results are applied to the process of creating results. Thus the backlog somewhat begets the backlog -- a classic case of recursion.

Consequently, the agile backlog is constantly changing, at least in theory. In practice, a lot less so.

And, second: agile dismisses the idea of structured requirements (shalls and wills) so as to substitute "conversations", put down as vignettes in the form of stories and use cases.

This obviously causes some creative thinking re verification and validation (V&V) that is often part of a downstream activity, quite apart from development.

And, third: agile is realistic vis a vis a project of intangibles wherein there are really no physical limitations to constrain requirements.

Thus: back to the challenge discussion: When is agile project "done"?
My counsel is: agile is a best value delivery, within constrained budget and time, of the highest priorities that the money will afford. All else, see V2.0.

Now, if you are working agile through the vehicle of a contract, you can also read this posting: