Is genius a force multiplier?

---

In military circles a "force multiplier" is a factor, capability, or other influence that has the effect of making the force larger or more effective than it physically is. Instead of massed troops, a less awesome force -- multiplied up in some way by a force multiplier -- has the effective impact of the larger force.

Does this idea apply to our domain: project management?

It could of course.

One possibility is the impact of a true genius. Can one individual have the impact of many? Possibly.

We've all played the management training game of having a team solve a problem more effectively than one individual -- but can it work in reverse? Can the intersection of genius with project teams really work?

Genius is often iconoclastic... a challenge to all the norms. Genius is often temperamental, intolerant, arrogant, and self-centered.  We know: arrogant people take risks; arrogance begets mistakes.

Not exactly your team player, but hey!... the genius is supposed to have an extraordinary impact; not necessarily to blend into a team

And, here's some news you can use: You can't schedule epiphanies; you can't schedule break-through innovation; you can't schedule the next discovery of a new law of physics. And, you can't schedule the impact of genius...

But over time, something is bound to happen if a genius is given latitude: arrogance, intemperance, etc are accepted as the cost of doing business. That of course is the power of small business with little bureaucracy... nothing administratively to get in the way (and vice versa: don't look for break-out genius in a large organization, Apple perhaps excepted... but only because Jobs was at the top)

So, back to PM: can you make room for genius among your project processes, metrics, and dashboards?

---

Bookmark this on Delicious

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

Lean entrepreneur in the enterprise

---

Brandt Cooper added something to the body of knowledge at the Australia 2014 Agile conference in Melbourne. His topic is the lean entrepreneur, though there's not much in the presentation that is lean specific. Nonetheless it's a worthy read about the trials and tribulations of the experimenter - entrepreneur

He starts off by declaring that there are two upfront killers of entrepreneurial innovation:

• a demand for ROI and 
• a demand to know when innovation will arrive. 

Likely so.

What caught my eye was the use of these charts to develop his ideas that it's not all predictable, not all estimateable, not at all a sure thing worth of a ROI commitment, and certainly not easily put on a calendar.... Thus our Hero!

And, don't forget the change thing....

 

---

Bookmark this on Delicious

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

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.

---

Bookmark this on Delicious

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

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.

---

Bookmark this on Delicious

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

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 slideshare.net/jgoodpas

Agile earned value exercise from John Goodpasture

---

Bookmark this on Delicious

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

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)

---

Bookmark this on Delicious

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

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.

---

Bookmark this on Delicious

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

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".

---

Bookmark this on Delicious

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

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: www.johngoodpasture.com/2012/11/conversation-through-contracts.html