Wednesday, April 14, 2021

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!

Sunday, April 11, 2021

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!

Thursday, April 8, 2021

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!

Monday, April 5, 2021

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!

Friday, April 2, 2021

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!

Tuesday, March 30, 2021

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!

Saturday, March 27, 2021

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!

Wednesday, March 24, 2021

Backlog blocked?



Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling? 
Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.
  • Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
  • Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.
In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.
 
Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?
If coupling is a benefit, how to obtain it?
First, there's buffers to loosen coupling
The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects
  • To avoid coupling, buffers may not do the trick.
  • But to enable coupling, we need some connectivity
In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 
 
One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.
 
Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 
Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling
Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:
  • Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
  • Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.
Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!




Buy them at any online book retailer!

Sunday, March 21, 2021

Mentioned in Dispatches


In the British Army of yesteryear, it was an honor to be "mentioned in dispatches" from the front lines to the general HQ and the public at large

And so, I'm honored to be mentioned as one of the 130 top PM "influencers" of 2020 in a posting at the digital project manager site.

I can attest to many of those mentioned, many of whom I follow or subscribe-to myself, many of whom I have quoted in this blog. So, I stand in good company of many accomplished individuals in our field who have contributed to our professionalization. 

I commend to you this listing of PMs you might want to become acquainted with in your project work




Buy them at any online book retailer!

Tuesday, February 23, 2021

Agile means ....


Agile means:
  • ‘Agile’ means small teams, working collectively and collaboratively, with this mission: 
  •  To deliver frequent, incremental releases of innovative functions and features, prioritized for need and affordability;
  • Evolved iteratively from a vision according to user reflection and feedback;
  • And produced at the best possible value.(*)
Agile ideas to keep in mind
  •  Requirements are too important to be left to the beginning; they must be evolved with user interaction and interpretation as all the implications come into view
  •  Process emerges to fit the circumstances; control metrics are empirically determined, not defined by historical performance in the manner of Six Sigma (**)
  • Planning is very important but following the plan is not as important as satisfying the customer
Agile works better when...
  • Agile is the better method when requirements are changing, unknown, or unknowable until seen (I won't know it until I see it).
  • Agile methods are best when in situations of fewer than a handful of small teams, typically fewer than 50 developers
  • Agile methods work better in-house than through the constraint of a contract
  • Agile works better with co-located teams than though the cultural translation and limited communications channel of a virtual team

(**) Six Sigma is a ‘defined control’ methodology consisting of a multi-step problem identification practice and a defect control standard formally stated as requiring less than 3.4 million defects outside control limits per million opportunities.  The actual control limits are determined by analysis and by historical measurements


(*)  In this posting, innovate functions and features encompasses product base, product, system, deliverables, and outcomes; these terms are frequently used interchangeably.   

They all refer to whatever it is that the user or customer owns or uses at the conclusion of the project.  The projects applicable to Agile methods are software intensive, but may have many and complex hardware components.  



Buy them at any online book retailer!