TOC and the Kanban

---

Remember TOC: The Theory of Constraints? Goldratt explained it in his business novel "The Goal".

TOC is alive and well if you use Kanban in your WIP management

First, you may ask, before considering the theory:

What is a constraint?

• Limitation on throughput

What’s throughput?

• Stuff, outcomes, that are valuable to business or client
• That which is value-add to the business value proposition
• Debris is not throughput; it’s overhead

Now, what's the Theory?:
Once a stage is full, there’s no advantage to keep piling up WIP inventory at earlier stages

And, what is it that I'm supposed to do as manager re TOC?

Subordinate to the constraint

• “Efficiency” of widgets/hour at earlier stages is meaningless
• To clear the constraint, subordinate all resource allocations to the priority of working on the constraint
  All hands on deck rule

And, how can I make a constraint more capable so that I can improve throughput?

• Add similar resources (parallelism)*
• Re-organize methodology at the constraint
• Re-tool or re-train
• Avoid constraint by going a different direction

* Beware of Brooks Law: adding resources to a late project makes it later (Fred Brooks: "The Mythical Manmonth")

---

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

Kanban models

---

Looking for a Kanban model for your WIP -- work in process?

How about the simplest? DO -- DOING -- DONE?

Kanban	What it’s about
To Do	All the backlog from customer; all the project debris, all the technical debt
Doing	Everything started but not finished
Done	All done, except some debt might have been referred to TO DO

Too simple?
 Here's the one I like the best because it's ubiquitous and can be applied really anywhere:

Kanban	What it’s about
To Do	All the backlog from customer; all the project debris, all the technical debt
Narrative, design, outline	The epoch story; the overall architecture; the outline of the deliverable(s)
Construction	All the building and assembly of units
Integrate & test	Tie the units together and see if they work
Validate and Verify	Everything accounted for?  Ooops, left one out; back to construction
DONE	All done, except some debt might have been referred to TO DO

Got one you like? Use it!

---

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

50 PM blogs

---

I was honored to find this blog among a list of the "50 Great PM Blogs for 2017"

Among these are a number of blogs that I follow, so I say the list is a good list of stuff to read.

But one not listed that I'll add for your list is Critical Uncertainties, authored by Matthew Squair. From down under in Australia, Squair writes eloquently about safety, risk, and failure management in projects and systems.

---

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

More on technical debt

---

I'm not shy about recommending the other guy's stuff. Here's two postings worth the read on things you can do to deal with technical debt:

Phillipe Krutchen
Concrete things you can do about your technical debt

Scott Adler
11 Strategies for Dealing With Technical Debt

---

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

PM as Fiduciary?

---

Consider this explanation of a fiduciary:

In a fiduciary relationship, one person, in a position of vulnerability, justifiably vests confidence, good faith, reliance, and trust in another whose aid, advice or protection is sought in some matter.

In such a relation good conscience requires the fiduciary to act at all times for the sole benefit and interest of the one who trust

So, what are we to make of that?
Certainly, the project manager is, or should be, is vested with confidence, good faith, reliance, and trust. So, that makes the PM a fiduciary watching out for the vulnerable.

And, in a project situation, who is vulnerable?

• The client or customer?
• The sponsor?
• Other project staff 

And, the PM is to hold all their interests in hand and find the best solution that optimizes interests for each of them? Good luck with that!

At some point, some ox is going to get gored. And then who blames the fiduciary? And to what risk is the fiduciary held?

The answer is: it's different in every project, depending on whether the client or sponsor is most supreme. And, of course, how does the PM get measured?

• Business satisfaction re the project scorecard
• Client satisfaction re business relationship

I think this why they pay the PM the big bucks!

---

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