Supply chain bollocks!

---

If you're working projects in the construction industry then you know what I'm talking about: supply chain constraints and missed or stretched schedules everywhere.

 

It may be time to dust off two ideas that are actually timeless:

1. "The theory of constraints"
2. "The Critical Chain"

Now as it happens, both of these ideas come from the same industrial theorist: Eliyahu Goldratt; and he wrote books -- well received and widely read -- about each one (*).

Theory of Constraints

Goldratt had two big ideas in his theory

1. There's no point piling up "inventory" ahead of a constraint, only to have that "inventory" languish and possibly expire before it's sell-by date.
   This means don't work feverishly in one part of the project, only to have another part of the project constrain the utility of that work.
   Resources will be unnecessarily committed to tasks that could be done at another time.
   It's better to put those resources to work -- perhaps even on another project -- where their outcomes can be readily used. Matrix management anyone?
   
   
2. If the constraint is really impacting outcomes in a material way to project objectives, then subordinate everything else to the task of mitigating the constraint.
   In a few words: don't accept the fact of the constraint; do something!

The Critical Chain

Most project managers have heard of this one. Even PMI talks about it. The ideas are these:

1. Figure out the chain of events and tasks that comprise the path to the most important project outcomes. Often, such is the 'critical path' as defined by PDM methods, but not always. Unfortunately, "critical" and "important" do not have a common definition. Let's focus on "important" as the critical chain , and leave "critical" to PDM.
   
   
2. Create 'buffers' -- or schedule slack -- between any activity that joins the important critical chain path. The buffer is there such that those less important activities do not impact the performance of the critical chain, even if they run over and thereby consume their buffers.
   
   
3. And, create a buffer at the end of the critical chain such that any variance along the way is absorbed by the buffer. In schedule speak this is known as "under promise and over perform"
   
   
4. Finally, and somewhat controversially in the age of Agile, centralize the oversight of the 'buffer budget' so that the budget is applied to the most important project objectives as determined by the high command in the project office.
   

 ------------------

(*) "The Goal" is the business novel that explains the theory of constraints

"Critical Chain" is also a business novel

---

Buy them at any online book retailer!

AGILE: mixing methods

---

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)

So, what have you 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.

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!

---

Buy them at any online book retailer!

When mysteries are progress

---

Got a mystery in your project?

Can't figure out what's happening, or

Can't find the root cause -- after following all the methodologies -- for what you measure or observe?

Perhaps you are making progress!

Stuff happens; don't deny; it's yours to figure out why

Once you do, you may have discovered something quite fundamental about the project outcomes 

There are lots of examples:

• There is a lot of dark matter in the universe; why is there more dark matter than visible matter?
• There are missing particles in the Standard Model of particle physics; where are they?
• Why does the speed of light not conform to Newtonian physics (Einstein worked that out, fortunately)
• Why does your bridge collapse after you built it with a lot of steel?
• Why do team mates fly off the handle when you mention X or Y? (Note: no religion or politics in project teams)

 So, there are a lot of examples. What do you do about it?

• Try Bayes methods of hypothesis testing ... make a prediction (perhaps, gasp!, a guess for lack of something better); test for results; change a parameter and look again. Repeat ....
  
  
• Try models: why does the model work and the system doesn't? (NASA calls something like this 'model based system engineering -- MBSE')
  
  
• Get out of the frame and look from a different vantage point. That's what Einstein did.
  
  
• Try forensic engineering or investigation. This is micro-engineering at the nut and bolt level.
  
  
• Change direction and do something entirely different (not retreat; just advance in a different direction)
  

---

Buy them at any online book retailer!

Leading without risk

---

Leading -- leadership -- without risk; without taking on risk?!

It can't be done.

End of posting.

Perhaps a bit more:

To be a leader is to put yourself out front ... exposed, as it were

And, out front you'll find there are no easy answers.

 

If there were such, leadership would be more like management: Follow the rules; stay within the guides; take little personal risk to reputation and career; work for a salary instead of a compensation plan.

But, to be known as a leader is too put at risk not only yourself but your project as well. 

And, you can't buy insurance for that sort of stuff.

 

If you can't step out front ... expose yourself to risk of failure and to making a wrong decision from time to time, then you should look for another line of work.

 

Need even more?

In fact, a whole book was written on just this theme:

Ronald Heifetz wrote "Leadership without Easy Answers"

Highly readable and very instructive. 

---

Buy them at any online book retailer!

When there's no Plan B

---

If there's no Plan B, then the first rule is "Make Plan A work!"

And it might require that you be aggressive about making Plan A work ... no fooling around.

No Plan B

Wait! Isn't there always a Plan B somewhere?
A general officer once told me: If there's no Plan B, invent it!

Insure for failure?

Maybe you can insure against the failure of Plan A. Perhaps that's your Plan B -- just get your money back, even if you forego the functional outcomes of a successful Plan A. 

But you can't go through life buying insurance for every risk. At some point, you need to ask the 'affordability' question. If affordable, don't insure it; otherwise, look at mitigations.

Losing function

But functional or relationship loss is altogether different. You can't buy insurance for that one. There really may be no Plan B.
What then?

When there's no Plan B, then you change behaviors

It's all well and good to follow the first rule: Make Plan A successful.

But mitigating a functional or relationship loss is often and largely about personal interactions, behaviors, personal risk taking, and pushing limits.
And only you can sort this; only you can assess the cost to yourself -- not necessarily dollars.

Think about the cost if there's no Plan B!

---

Buy them at any online book retailer!

Got to keep moving!

---

For some, boredom is the great fear. Got to keep moving!

"He had a function, an excuse for activity. For a few hours at least he wouldn’t be bored. ... he drank the coffee, which was still too hot. He reflected that the fear of boredom had driven him the whole of his life."

Ann Cleeves, Novelist

The fear or boredom was a driver ...
Frankly, I know how he feels

Add value
It shouldn't be motion for motion's sake
It should be about the utility of what you are doing
I need an activity plan for every day ... how will this day add value to what I am about?

About utility
Utility is the marginal difference between face value and the value you -- or someone else -- puts on what your are doing or offering. 

If you think about it, almost anyone can offer up face value if they have the skills for that domain, but if you are in constant motion -- avoiding boredom -- then that activity should be directed at more than just face value.

Even if it's just reading a book, the question is: how much better off are you for having engaged in that activity? For me, I read a lot of history because I think there are lessons there to be applied forward that will add value to my endeavors. And, of course, I might avoid a risk I might not otherwise understand.

If you are driven to activity ...
Make it count for something.

 

---

Buy them at any online book retailer!

Risking the team

---

Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!

Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

WIP Limits
In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:

"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!

---

Buy them at any online book retailer!