Get ahead by leaving behind ...

---

Nick Tasler has a posting on the HBR Blog Network with an intriguing title: "To Move Ahead You Have to Know What to Leave Behind" 

His theme is summed up this way in an early paragraph:

The Latin root of the word "decide" is caidere which means "to kill or to cut." (Think homicide, suicide, genocide.) Technically, deciding to do something new without killing something old is not a decision at all. It is merely an addition.

So, what do the hoarders among us do? We save everything; kill -- or throw away -- nothing! Actually, we find deliberately making these trade-offs -- keep this; discard that -- so energy absorbing (Tasler says: exhausting) that we just layer on new change.

This behavior leads to what Tasler calls "trickle down trade-offs" in which there is sort of a push-down stack with the most current issue on top and the not-dealt-with issues more or less far down the stack.

Many of have seen this in action -- and we joke about planning an exit strategy before the stuff at the bottom finds its way back to the top!

No! .. that's not management -- that's escape. To be effective, we must all acquire instinct and be thought of as 'trained killers' of excess (think: Lean!)

---

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

Did someone say: Baseline?

---

In one of my past Agile classes I facilitated this discussion re baselines:

Student 1:
 "I have a new Operations Director, and he says once you've missed a date, you re-baseline, and the item is no longer indicative of a bad/out of date status.
In previous positions, we didn't always or weren't allowed to do that, so that they could track the original dates vs. current progress.
Just wondering how others handle this."

Student 2, in reply:
"When I baseline a project, it is once and done. How can one measure truly the progress and planning of a project if the baseline is reset every time a date is missed? I agree that this would indicate a false sense of progress, a false green.

The only exception I can think of is if the project plan introduces a significant change that is approved by the project board and sponsor that impacts greatly the objectives and especially the schedule.... "

My facilitation:
Not exactly!
Re Student 1: if  you've missed a date, that's a variance. The baseline is still the plan you are managing to so long as you are trying to recover the schedule.

Re Student 2: "once and done" doesn't work either. There may be many reasons to rebaseline as the project goes along. It's not like you have a budget of 're-baselines' and you can only use so many. However, the key to the whole thing is the second point: "... significant change approved by the [controlling authority..]"

So here's the thing: first common sense always applies. In most non-trivial situations you have two plans at all times:

1. The baseline which is the agreement between the sponsor (business) and the project
2. The operating plan which is the day-to-day plan derived from the baseline

As project manager, you must have a strategy to merge or bring together the operating plan and the baseline so that at the end of the day, the baseline is the plan of record... all variances of record are measured against the baseline.

Now, if it becomes the situation that the baseline is no longer valid -- approved changes, etc -- such that there is no practical way to merge the ops plan with the baseline, then you rebaseline:

1.  Record and archive all variances to the baseline -- B1
2. Replan the project; this replan becomes the second baseline -- B2
3. At the project conclusion, sum the variances. Add the variances from the former baseline B1 with the variances accumulated in B2. These become the cumulative variances of record.

To wit: you get no free lunch on variances just because you re-baselined. And, this is the deal in Agile or traditional... no escaping there either.

---

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

Getting to done, even in Agile!

• 
  

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... definition of done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my "definition of done", as it were, has been these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most … and the most affordable … scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently

A typical DoD would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:

"I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels."
Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. In other words his theory is tested in the crucible of a trying to make money or fulfill a mission by writing software. How swell for us who read Cohn!

---

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

Alliance networks?

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me, and I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

When simple is too simple: Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad sub-contractors, to say nothing of the legal details of who has privity of contract.

Some complexity required: For the really complex project, Shipilov recommends the "alliance network" wherein there are multi-lateral relationships between the major partners. Each partner is actually the hub for a traditional "simple" hub-and-spoke.

Shipilov maintains that the multi-lateral relationships between the major partners provides opportunity for, and even promotes innovation, data exchange, and cooperation.

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one big caution: Who is actually in charge? Someone has to be king of the hill, more or less controlling the strategic narrative. It could be the customer (read: source of the money), as in the government for defense system and public works projects, but it could be a "prime contractor" or an equivalent commercial "big dog", the so-called alpha-partner. Shipilov doesn't really address this …. but you will have to.

---

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

Storyboards -- a great technique

---

A great technique for writing proposals, papers, or books -- as I do a lot -- is to storyboard the ideas.

My favorite expression: "If you can't draw it, you can't write it!"

Here's Einstein on the same idea:

I rarely think in words at all. A thought comes and I may try to express it in words afterwards

If you're not a storyboard person, check out this website for insight...

---

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

Systems! And then there were systems

---

I was reading Matthew Squair's course materials on System Safety Fundamentals when I came across this slide:

"Life was simple before World War II. After that, we had systems."
Rear Admiral Grace Hopper (USN)

Ya gotta smile at that witicism!

The Admiral Dr,of course, is best known for inventing the system "bug" when she literally found a dead bug in in an inoperative computer system.

And, she used to hold up an 11.8" piece of wire to show the length travelled by an electron in a nanosecond. (*) Shorter is better! Thus, the sub-micron circuitry of today.

She retired from the Navy at age 79 in 1986 after serving about 50 years.

(*) To be more precise, about 11.8 inches in a vacuum; slower in wire, of course.

---

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

They say: Story is almost everything

---

"Alasdair MacIntyre argued many years ago, you can’t know what to do unless you know what story you are a part of.

Story is more important than policies."

"You can get a lot of facts wrong if you get your story right."

Quoted by David Brooks

That last observation -- good story, wrong facts -- sounds off key, but consider: facts are in the rearview mirror; only estimates lie ahead. If you are a visionary -- see: E. Musk -- you don't want to be too encumbered by facts (i.e., historical approaches). You need freedom to envision!

Not so fast!
Facts and "wrong facts" aren't the same thing. Misusing facts to support a story -- even futuristic and new-to-the-world stories -- is, in some quarters, not-less-than fraud. See myriad SEC cases where investors and employees bought into a narrative based on false facts. One might even think (gasp!): Bernie Madoff!

Now in a different context -- a history of political imperialism -- I've heard the same thing: "They" say: Conceive the narrative, paint the grand picture, and then find facts -- or, if you have too many facts, discard those that are inconvenient."Remember the 'Maine'!"

If you are risk averse, story-sans-facts is not the formula for you! You've got to be willing to live with a disaster if real substance doesn't come along in time to bail you out and validate the story. Story teller beware!

---

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

Is this a mix? Agile, oil, and gas

---

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

Agility needed?
So, what have we got here?

• A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
• A need to run with pilot projects before committing to production
• A need to tie into legacy systems (in the OGM case, distribution systems)
• A lot of deliverables that can be done incrementally and then integrated
• Small (it's all relative re small) teams, co-located, personally committed, with risk hanging on every move.
• A degree of local autonomy required to meet the challenges of the moment

Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":
You can't go around self-organizing (agile speak) willy-nilly! There's regulatory constraints everywhere and safety-first doctrine hanging on every move.

We're here to help!
So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  I'm sure they never heard this stuff in an oil field or an offshore rig! In fact, I'll bet the rig boss is a force to be reckoned with!

---

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

Hello! Robots have limits!

---

Elon Musk, lamenting at the June shareholder meeting about Tesla production

“One of the biggest mistakes we made was trying to automate things that are super easy for a person to do, but super hard for a robot to do,” he said. “And when you see it, it looks super dumb. And you are like, wow! Why did we do that?”

---

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