The TOGETHER thing

---

Heidi Grant Halvorson tells us that being together, working together, and actually doing things together is a big deal.

This is news you can actually use

OMG! There's a magical elixir: Halvorson relates this bit:"... the feeling of working together has indeed been shown to predict greater motivation, particularly intrinsic motivation, that magical elixir of interest, enjoyment, and engagement that brings with it the very best performance."

So, we all work in teams.. at least that's been the preferred project organization for more than a generation.. thus, no problem? We're together all the time, or are we?

The take away from Halvorson's piece for me is that working in teams is not enough. You actually have to work together to do things together to get the benefit of "together". Indeed, is this true: "....the weird thing about teams: They are the greatest (potential) source of connection and belonging in the workplace, and yet teamwork is some of the loneliest work that you’ll ever do."?

If you've ever worked from home on a team, you know what this all about. Team work at home can be pretty lonely. Personally, I like the hub-bub of other people around, or at least some background noise to stir up the air.

Perhaps this is the real issue: ".. The word “together” is a powerful social cue to the brain.  In and of itself, it seems to serve as a kind of relatedness reward, signaling that you belong, that you are connected, and that there are people you can trust working with you toward the same goal."

---

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

Speaking off the cuff

---

Every project manager speaks to groups in public... it goes with the territory. But, what happens if someone drops in unexpectedly and an off the cuff briefing or speech or speaking opportunity portends?

If this is not your strong suit, here's some worthy advice from John Coleman writing at the hbr.org network blog:

1. Define a structure: The pressure of extemporaneous remarks comes from their ambiguity. What do I say? What do I not say? The worst and most stressful business speeches are those that ramble without purpose. In forensics we’d tackle this issue by quickly drafting a structure on a note card to support our main point — often an introduction, two or three supporting points, and a conclusion. With these on paper, it was easy to fill in the details with stories, examples, and statistics. Now, when I’m asked to offer unexpected remarks over dinner or at a board meeting, I grab a napkin, notebook, or the back of a PowerPoint deck and jot down my main argument and some key supporting points. Then I fill out the examples and data I need to make those points — usually in 20 words or less. Any ambiguity or tendency to ramble evaporates.

2. Put the punchline first: When I worked in consulting, one of the cardinal rules of communication was “punchline first.” Any presentation should have a clear thesis stated up front so that listeners can easily follow and interpret the comments that follow. I can’t tell you how many times I’ve seen business presenters ramble through a speech with the audience wondering to the very end about the point of the comments. Giving a good business speech is not like telling a good joke. Don’t save the punchline for the end.

3. Remember your audience: All it takes is a few lines to make an audience feel acknowledged and a speech feel fresh. Tie the city in which you are speaking into your introduction. Draw parallels between the organization you’re addressing and one of the stories you tell. Mention someone by name, connecting them to the comments you’re offering. These are small gestures, but they make your remarks more tailored and relevant.

4. Memorize what to say, not how to say it: How many times have you practiced exactly how to say something in your head then frozen up or completely forgotten in the moment? In forensics speeches, we’d often have 5–10 citations to remember, 3–4 examples with names and places, and 3–4 supporting statistics. That’s a lot to research and remember in 30 minutes or less. The trick was this: We’d focus on memorizing key stories and statistics, rather than practicing our delivery. If you spend your time on how to say something perfectly, you’ll stumble through those phrasings, and you’ll forget all the details that can make them come alive. Or worse, you’ll slavishly read from a PowerPoint or vertical document rather than hitting the high points fluidly with your audience. If you know your topic, the words will come.

5. Keep it short: Blaise Pascal once famously commented, “I have only made this letter rather long because I have not had time to make it shorter.” While it seems like the challenge of speaking with limited preparation would be finding enough to say, the opposite is often true. When at a loss for words, many of us underestimate the time we need — cramming in so many stories and points that we run well over our time and dilute our message. No one will appreciate your economy of words more than your listeners, so when in doubt, say less.

---

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

Even if you hate statistics...

Many tell me: "I hate statistics", or they tell me: "I don't know anything about statistics, so I don't use statistics in projects"

Hello!... actually you do use statistics; you're just not that aware of it.

One of the most prominent principles you apply probably unwittingly and unconsciously is the Central Limit Theorem, affectionately: CLT.

From a risk management perspective, the CLT has these two ideas embedded that are useful day to day (look: no math!):

1. Central tendency: similar to mean regression, central tendency says that regardless of the underlying distribution of random effects, whether asymmetrical or not, uniform or not, the aggregation of all the independent effects will have a bell shape with a pronounced central value.

That's handy because no matter how pessimistic or optimistic are the various WP managers about budgets and schedule, at the project level it all washes out and there will be a general bell curve to the central figure that is the sum of the durations or the sum of the budgets.

2. Regression to the mean: most natural phenomenon have random variations (the time for the paint to dry, etc) but over time they find their way back to their long term average.

If your project is to paint the fence, then there may be a few warm days, a few dry days, a few cool days, but over enough time, the time to paint the fence will wander back to its long term average. This gives you the basis for parametric estimating with relatively low risk.

This, of course, underlies the long term quality assumptions in Six Sigma and other process control paradigms. Of course, if there is tool wear, like the paint brush wearing out, then such non-random effects will bias the mean off its natural center.

Generally, biological systems, like people, regress to the mean unless there are material changes in environment, training, tools, etc. So, just because a team member performed really good (or bad) this time, such non-average performance does not predict the next time.

Malcolm Gladwell tells us it takes 10K hours to become an expert -- about 5 years in normal times -- so the drift of the mean with expertise is usually quite long.

I say weights and you say probabilities...

---

Just to be clear: weights and probabilities are not the same concept:

• Probabilities express the proportion of certainty allocated to each value. Consequently, the proportions all add up to 1.0 like slices in a pie.
• Weights, on the other hand, express relative strength... as such there is no need to have proportionality among weights unless it's convenient.

We hear these terms used interchangeably... weights when we mean proportional uncertainty; probabilities when we mean relative weights. With context, we usually know what is really meant, but not always.

In marketing and sales, we often hear about probable sales (ok) and weighted market values (ok), but then somehow the weighted market value becomes the win probability... not likely true

And, we see similar usage on the risk register where weights and probabilities get mixed.

• It's ok to say impacts are weighted by some binary scale (High = 4 x Medium; Medium = 2 x Low)
• It's even ok to say risks are weighted by their probabilities: risk impact x risk probability
• But, it's not ok to an 80% probability of this happening and a 30% probability of the opposite happening. If these are all part of the same pie, they may be weighted by a ratio of 8 to 3 for some parameter, but they are not 8 to 3 in probability: 80 + 30 > 1

But wait: the world will not end if these errors are made. On the other hand, let's wipe out ignorance!

---

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

What are you doing on mute?

---

From no less a project management tome than "The Atlantic" comes this bit of confirmation that we all know but don't talk about. People on conference calls aren't always paying attention.

OMG! Is that news?

Here's a graphic to make the point
I guess I'm old school: if on mute you'll find me in the top couple of bars... doing email or something else.

---

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

It's faster in the slow lane (?!)

---

Are we all physicists?

We might be.

This might be another take on the tortoise and the hare, but it's more about flows in projects, whether WIP flows in the Kanban, conventional team throughput, or staffing pressures and policies. And, for the quants among us, there's a bit of physics as well.

Imagine this experience (we've all been there): Driving on a multi-lane highway at moderate traffic volume, everyone is in their place: fast guys are in the fast lanes; slow guys are in the slow lanes. All is order.

Now, the volume builds, and you notice an inexorable shift of volume to the fast lanes: everyone wants to get ahead of the crowd.

Now it gets interesting: the fast lanes slow down with increasing volume but the slow lanes keep on moving... moving in fact faster than the fast lanes! And, as volume builds, the phenomenon is more apparent, until... volume overwhelms the whole system and all lanes move together in fits and starts.

Fits and starts: that's physics, actually. So is the slow lane being faster.

And what are the physics that apply to Kanban boards and all the rest of the flows in projects?
Answer: reflected energy. The load (capacity) can't absorb the energy (volume) being thrown at it, so it throws it back in the form of reflected energy (everyone stepping on the brakes).

Do you have microwave waveguides in your project, or any kind of load-matched transmission system? If so, you probably measure the return loss: energy transmitted but not accepted by the load, thus to be reflected.

And, if the reflections are timed right they create coherent waves (standing waves). Thus, in traffic, and elsewhere, with too much volume being applied, you might be standing still in one place, only to move ahead at the speed limit at another place, then to stop again... ergo, standing waves of coherent reflection.

And, we see it in all manner of project flows... the lesson being obvious... throw more volume at the fast guys (fast team) and eventually they'll slow down until everything they are doing is being done slowly, only to be passed by the less-fast (we won't say mediocre, or anything like that)

In the software business, we have Brooks law [I paraphrase]: Adding people (volume) to a slow (late) project makes it slower (later)

Your job: volume manager. No point in throwing good energy after bad... it's just going be reflected right back at you.

---

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

Email anyone?

---

The office memo has been gone for 20 years, but it seems we're still learning how to email effectively. It's as if all the "memo composition rules" were throw out and not passed down to the email generation.

Anyway, enough whining; here's my FIVE RULES for EFFECTIVE EMAIL (I'm shouting here!)

1. Only one subject per email in the body text
2. Subject line is relevant to subject matter (no generic subject lines)
3. Use key words in subject or body that will be used for search later on when you are looking to recall the email; think about how you would write a SQL SELECT statement to retrieve the email
4. If you reply to an email received on subject "A" but want to divert the topic to "subject B", then edit the subject line to start a new thread
5. Avoid river raft paragraphs (long flowing text without breaks); every couple of sentences should be separated with a space. People read online with a different attention span and reading pace than they read on paper.

Did I say five rules? Think about the sixth: Imagine your email in the New York Times... are you ok with what it says?

---

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 is a process -- or not?

---

First, the agilists tell us that they are not slaves to process, like their traditionalist brethren are. Agilists are free! And then they tell us that you must, must, must:

• Release something every two weeks, or four at the outside
• Have a daily stand-up of no more than 15 minutes
• Have a retrospective meeting at the end of every iteration
• and, so on....

And, they tell us, these are not processes but rather practices. A process, after all, has protocol, input, controls, and output.... and these don't?

Nonsense. Agile has process like every other methodology; they may be shorter in duration but they are processes nonetheless

Now comes a really radical idea into agile land: Let's do away with these processes and really be free! No less an eminence than Mike Griffiths, an independent trainer and consultant who is steeped in PMI ACP stuff, who blogs at Leading Answers, has given us this wisdom:

It's not the process, stupid!

Here's the core of his argument:

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

• Sense making – agree information gathering steps and prioritize exploratory work
• Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting
• Consensus gathering - collaboratively gain consensus on direction, approach and decisions
• Prioritization – build mindful to risk reduction and business value
• Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates
• Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings.
Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail

Did you read that last point? That's a biggie!

The typical advice is do pilots as the training vehicle... Fine, I agree with that. But Griffiths might say (though he didn't) that the purpose of the pilot is not to train on the process but to train on the ideals and principles as listed above.

Fair enough.. But CAUTION: this stuff DOES NOT SCALE. If you have a few teams of really good people who work well together, Griffiths is probably spot on re doctrine, though I'll be even these teams migrate toward process they define for themselves and work for them.

But, if you're working at scale, you probably need look towards what Kent Beck did when he invented XP: practice and process discipline! Toe the line!

I see this issue in my Agile classes repeatedly as students tell me they intend to trade process doctrine for freedom, whereas what they mean is that they are going to trade traditional process doctrine for a more agile doctrine. For newbies, that's probably a good strategy.

---

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 cost of value

---

Everywhere I go I make it clear that agile in the enterprise begins with a business case. I make this point in my books* and blog postings over and over. The logic of this is obvious on its face: if you are going to spend other people's money (OPM) they'll hold you accountable. Accountable for what? That's what the business case is for... to answer that question. And, if your processes require a project charter, you can morph the business case in the charter.

But agile goes a step further: agile asks that the customer/user/product manager be embedded in the project and empowered to interpret the requirements in the backlog: sequence them, give them priorities, and recommend new ones, ones to change, and ones to delete.

So, given that empowerment, what then is the utility of the business case. What happens to accountability?

Actually, and in the spirit of keeping it simple, yet effective:

If the customer/user/product manager recommends changes in requirements, not anticipated in the business case, and these changes are material to the business proposition (cost of value), Agile provides two methodology opportunities:

• The retrospective evaluation leading to the next formulation of the next iteration's backlog, and
• The release planning session (or process), leading to production releases to the business.

Beyond these methodology opportunities, each business may have processes to handle business case changes that would overlay the project methodologies.

In each opportunity, the witting and accountable product manager goes back to the business case to evaluate impact to the cost of value, very likely consulting with affected stakeholders. It could be messy of course, and it could delay things, but following the agile principle of provoking change early on, it's really in the job jar of the agile product manager to be pro-active about attending to the business case.

---

* Maximizing Project Value, Chapter 3, discusses the agile business case
Project Management the Agile Way, Chapter 2, also describes how to build an agile business case

---

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

Adm Rickover on 'good ideas'

---

Good ideas are not adopted automatically. They must be driven into practice with courageous patience.

Admiral Hyman Rickover

---

Quoted by Jurgen Appelo


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

So you need to write an RFP

---

Spoiler alert! This posting may be dry to the taste...

Ever been asked to write an RFP (request for proposal)? It may not be as easy as you think. My metric is about 2-3 hours per finished page, exclusive of specifications. Specs are normally just imported. So, it could take you the best part of a week to put an RFP in place.

My outline is given in the Slideshare presentation below

Beyond the outline, here's a few things to think about.

Source identification: Sources, per se, are not part of the RFP, but sources are its audience. And the RFP is written for a specific audience, so sources certainly influence the RFP

Source identification, or more better, source identification and validation (vetting), is both a science and an art. The science part is an objective list of source attributes; the art part is judgment, admittedly not objective.

Of course, there's sole source (the only one in the world who can do it) or selected source (the only one in the world you want as your contractor), but more often an RFP regulates competition among multiple sources.

Award criteria: How are you going to decide who wins?

• Lowest cost, technically acceptable (pass/fail) is the easiest and most objective.  Just open the envelop of all those with passing technical grades and take the lowest cost -- no questions, no fuss
• Best value is not easiest and not objective but it might get you the most optimum solution. Rather than pass/fail, you get to consider various innovations and quality factors, various management possibilities, what the risk is to you, schedule, and of course cost.
  
  Best value may not be lowest cost. That's always controversial, since cost is the one value proposition everyone understands. No one wants to spend more than the value is worth.
  
  The flexibility of best value (or, glass half empty: lack of objectivity) comes with its own risk: the award, if in the public sector, is subject to protest about how the best value was determined.

Risk transfer: what technical, functional, and business risks are you going transfer to the contractor via the RFP, and are you prepared to pay for that transfer? In effect, you're buying insurance from the contractor. All other risks are your to keep; you can be self-insured, or pass them off to an insurance party.

Here are some risk methods  you can put in the RFP:

• Contract incentives, penalties, cost sharing, and other contract cost-schedule-scope controls: all are forms of risk management practices.
• Liquidated damages: you get paid for your business losses if the contractor screws up
• Indemnity: your contractor isolates you from liabilities if something goes wrong
• Arbitration: you agree to forgo some of your legal rights for a simpler resolution of disputes

Statement of work (SoW): This is the part most PMs know something about, so a lot of words aren't needed. It may be the first thing an interested contractor reads. The SoW answers this question: what is it you want the contractor to do? A top-level narrative, story, WBS, or vision is usually included.

The SoW is where you can say how agile can the contractor can be interpreting the vision. Think about how anchored to your story are you?

Typically, unless you are pretty confident you are right, you don't tell the contractor how to do the job, but only what job needs to be done.

Specifications: How's and what's: Specs are where you can speak to measures of "how" insofar as you tell the contractor how something is to be measured; or you can speak to measures of what insofar as you tell the contractor what the metrics are and what the metric limits are

Requirements: And last but not least, the infamous Requirements backlog or matrix. Requirements are usually made a part of the SoW  as detailed "what's" or they can be a specification onto themselves.

Requirements are where problems surface on almost every project:

• Are they objective, that is: having a metric for DONE
• Are they unambiguous? ... almost never is the answer here. Some interpretation required. 
• Are they complete? ... almost certainly never is the answer here. But, can you admit the requirements are incomplete? In some culture and context, there can be no such admission. Or, you may be arrogant about your ability to obtain completeness. My take: arrogant people take risks and make mistakes...the more arrogance, the larger the risks... etc
  
  But, where you can say: Not complete, then presumably the contractor can fill out the backlog with new or modified requirements as information is developed?
• Are they valid? Can you accept that some requirements will be abandoned before the project ends because they've been shown to be invalid, inappropriate, or OBE (overtaken by events)?
• Are they timely? Can you buy into the idea that some requirements are best left to later? ... you really don't have enough information at the beginning. There will be decision junctions, with probabilistic branching, the control of which you simply can't

RFP template 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

It's a matter of character

---

One of the benefits of independent practice is that you can hire and fire your boss -- this I've done, so I speak from some experience.

But, of course, they can hire and fire you pretty readily as well -- more experience here too.

At least on the first point, character comes into play big time for me. If I can't trust the boss; if the boss is not a role model for both leadership and management; if the boss is alienating, then I pack up.

In a recent essay, I found a lot of empathy for four points as the drivers for building the character I want not only in a boss, but in colleagues as well. Here's what the essayist wrote, in part about character drivers or influencers:

• First, habits. People who practice small acts of self-control find it easier to perform big acts in times of crisis.
• Second, opportunity. Maybe you can practice self-discipline through iron willpower. But most of us [need] a realistic path [for] something better down the road.
• Third, exemplars. Character is not developed individually. It is instilled by communities and transmitted by elders.
• Fourth, standards. People can only practice restraint after they have a certain definition of the sort of person they want to be.

Character development is an idiosyncratic, mysterious process. But [close associations with role models of character may] reduce the alienation and distrust that retards ....
 

---

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