Firing your client

---

Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

A recent article gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:

• They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
• They say it's an easy job they can do themselves.. unless you want to be micromanaged
• You don't really know them and they live in a different country/culture.. some learning required!
• They want to talk about themselves instead of the job task... unless you want to be their counselor
• They say they've tried to get the job done with many others, and they all failed.. so might you!
• Rude, insensitive behavior.. unless you like the bad-ass type
• Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Fidelities..

---

Fidelity, faithfulness, and commitment often seem to be the tension between:

• What the customer/sponsor/user want, and
• What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and then the project team is off to do the deliverables. Simple, right?

Wrong!

It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? First, it's should always be a decision and not just a consequence of wandering off track; and second:

• If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment.
• If the decision process takes into account expectation as well as specification, then both of these should be on the list of "inputs" to the decision. And,
• Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)

Keep this thought close by: what is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

How many words does it take?

---

Quantmleap had a nice posting on the word count thing, to wit:

Pythagorean Theorem – 24 words
Archimedes’ Principle 67 words
10 Commandments – 167 words
US Declaration of Independence – 1300 words
EU rules for the sale of cabbage – 26,911 words

This begs the question about complexity: the unpredictable interworking of all the parts! One must wonder if it is possible to actually buy cabbage in the EU?

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Soft power

---

We read a lot about "soft power", but not in the PMBOK. It's not a power paradigm of PMI.

Soft power is a concept developed by Joseph Nye of Harvard University to describe the ability to attract and co-opt rather than coerce, use force or give money as a means of persuasion (Wikipedia)

Attract and co-opt rather than buy your way in... what a concept! And, cheaper.

What does it take to put such an idea into practice? In a word: Leadership!

What's the word cloud for leadership? Here's one list:

Demanding
Supportive
Consistent
Positive
Inclusive
Compassionate

Transparent
Committed
Authentic
Quick
Focused

Authentic
Courageous
Empathic
Timely

 

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Ask-receive-change

---

I wonder if the paradigm for change management should be changed? I'll bet a lot of people have an opinion on this. If so, and having received their input, I wonder if we would all come together to make a change to the means and manner for managing change?

Parse the paragraph just read:

Step A: Pose a hypothesis or ask about a possible outcome
Step B: Test the hypothesis or evaluate the responses to the question
Step C: Plan the change, or roll out what can be changed (successfully)

This is a simple example of the "ask-receive-change" paradigm. Too often, that's not the paradigm of change management. Too often we get:

Step 1: Plot the change
Step 2: Impose the change
Step 3: Enforce the change

A friend recently asked: plot or plan -- what's the difference?
Two responses to that question:

1. Dictionary: Plot: a secret plan or scheme to accomplish some purpose; Plan: a not-secret plan or scheme to accomplish some purpose.
2. Management view: Transparency. Plots come from the back room; plans come from the front room.

So, in change management, should the plotters be planners? Or, is it better to plot before planning?Should managers ask or tell? And, should the need for change be self-evident or enforced?

Of course the words are dripping with bias. Often, you can't plan in a fishbowl; does that make planning in private a plot? And, no matter its noble purpose and majority advantages, there are will likely be a minority -- sometimes vocal -- for which enforcement is the only highway.

My advice: be biased toward A,B,C even if 1,2,3 are necessary.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Befuddled by expected value

---

In a prior post, we mused about "risk amateurs". However, even experts are often befuddled by expected value.

Questions arise:

• What value should I plan for -- the expected value or the full face value?
• What about the most likely value -- shouldn't it figure into the planning?
• If I plan for the expected value, and the risk event occurs, where do I get the money to cover it? Isn't this an unmanaged exposure? And,
• What should I pay to get someone else to take on the risk -- the expected value, or more?

There are objective answers, of course, but the objectivity often has to be tuned for domain, context, and risk attitude, and whether or not there is calibrated data to work with.

Calibrated data: data based on facts and not guesses. Of course, there is a place for estimates: facts adjusted for circumstances where adjustments are based on reasonable and customary experience.

So, the first thing is that if we have calibrated data, then we may have data good enough to estimate event probability and event impact. Multiplying these two calibrated single point estimates is valid for that one point.

We come to the second thing: my objective answers, tuning as suggested notwithstanding:

• Make an operating plan based on expected value; to reduce exposure to an event actually happening, establish reserves (likely on possible coverage of the exposure) and alternative approaches (options) in the event of the risk event.
• The expected value is generally more pessimistic than the most likely value, so expected value is usually a better planning metric. (reduces exposure)
• See my first answer about where to get the money
• Any transfer payment in excess off the expected value is a profit or bonus to the agent accepting the risk. So, if you are not bonus averse, you can pay more than expected value. See: insurance... bonus in excess of the expected value is the basic model for insurance.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Data Item Description

---

In  the old days (in the last century) -- in the defense and the aerospace domains -- we used to routinely write "data item descriptions" (DiD) to define or explain what we meant by a particular data item.

Example: Define "customer" as a data item that might appear in a database. This is no small matter if you've ever tried to do it. You have the buyer, the decision maker, the user, the payer, and the warehouse receiver, to name some but not all. There are also physical descriptions, as in the headquarters, the sales office, the warehouse, etc.

So, it came to pass recently that I was on a volunteer project whereon there was a security task: we were asked to be on the lookout for "bags" and not let them pass a certain gate.

Indeed: what is a 'bag'? Like "customer" this is no small matter to define, and no one on the project wrote a DiD, and likely could not have if asked.  A lost skill? Perhaps!

And so, there were plastic bags, hand bags, back-packs, fanny packs, hyropaks, arm totes -- really, what is a bag?

A classic case of "where you stand depends on where you sit". If you are on a security task, everything looks like a bag! Otherwise, why is a fanny pack a bag?

Suffice to say: there is nothing like a DiD when trying to communicate clearly

Part 1: tell them what you are going to tell them
Part 2: tell them
Part 3: tell them what you told them.

---

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting