What is boldness?

---

"About boldness: Some might say “impulsiveness,” yet what is boldness but impulse leavened by calculation?

Daniel Allen Butler

Calculation? Where does that come from?
Experience is where it comes from. 

And what can we say about experience?

Steve Jobs would say it's one of the two coins that we get paid: One is cash, and the other is experience.
Others say it's the accumulated wisdom of all your encounters, good and bad

So, can you be bold without experience to base the calculation?
Yes, but then you are going by the "book" (others experience), or guessing or hoping or, in the worst case: foolish!

---

Buy them at any online book retailer!

The first rule of data

---

You can't have too much data .... correct?

Actually, not correct.

The first rule of data:

• Don't ask for data if you don't know what you are going to do with it

Or, said another way (same rule)

• Don't ask for data which you can not use or act upon

And, your reaction might be: Of course! 

The data plan

You may be shocked to learn that often there is no data plan! 

My experience: In the PMO there are often too many incidents of reports, data accumulation, measurements, inquiries, etc. for which there actually is no plan for what to do with it. 

• Sometimes, it just curiosity; 
• Sometimes you're out of your lane and it's really none of your business to know
• Sometimes it's just blind compliance with a data regulation; 
• Sometimes it's just to have a justification for an analyst job
• Sometimes it's a misguided idea that "there can't be too much data".

The tests:

•  If someone says they need data, the first question is: "How does it add value to what you are doing, and do you have a plan to effectuate that value-add?"
• The second question is: "Do you have a notion of data limits: enough, but not too much to be statistically significant, and control limits for useful -- or not -- metrics."

And information?

Well, the usual definition is that information is data, perhaps multiple data, integrated with context and perhaps interpreted for the current situation.

So, the rule can be extended: if there are not means to process data into information, is the data necessary to be collected?

Bottom line: To state the obvious: always test for value-add before spending resources to collect, process, and disseminate data.

---

Buy them at any online book retailer!

The funnel and the pyramid!

---

In every book written about project management, the PMO is at the apex of a pyramid. Sometimes, as in Agile project methodology, the pyramid is flatter than most, but always there is an identifiable top figure.

Fair enough.

But Robert Gates, former Defense Secretary [and holder of many other government titles] writes that he often felt like the pyramid was inverted and thus took the look of a funnel. In the funnel model, the 'decider' is at the bottom of the funnel, with others pouring stuff in. 

 
Funnel v. Pyramid
How can it be that the top person is at the bottom, figuratively?

Gates explains: in the pyramid model, stuff is either pushed up for political cover, or because protocol demands that the decision lies higher, or because the apex person is pulling stuff up that they want control or inspection of

But in the funnel model, the top person is like the paper at the bottom of the bird cage: everything is pouring in from the top; and everybody on the project is busy doing the pouring. Fortunately, only a bit funnels all the way through, but gravity seems to be in charge. It's inexorable.

Filters in the funnel
Fortunately, the funnel can work like the pyramid, only with gravity. There can be and should be filters in the funnel. The minor stuff is trapped early and doesn't make it through. The top person -- at the end of the funnel -- can pull stuff "down", and there is some gravity effect: stuff naturally falls to the bottom for action.

And so for the PMO, the management points are:

• In the funnel model, things move by default. There's an expectation on the part of anyone pouring stuff in at the top that it will eventually come to the attention of those 'at the bottom of the funnel'. Gravity is just the consequence of applying energy to get stuff up to the top of the funnel and pouring it in.
  
  
• But in the pyramid model, gravity works against you. The default is: nothing moves to the top. If you want it to move up, there's work to be done!
  
  

If you like the idea of a funnel, how would you create it?

Just open your door! The funnel model is somewhat like "my door is always open" (even if virtual) ; anyone can "pour" something in. 

 

But, rather than "anyone can", you move to "everyone should" pour something in. As the 'decider' you don't have to pull very much in if you operate like a funnel; stuff will get to you. If you like the funnel effect, you say that's good.

Perhaps, but only if you have the methods, tools, discipline, and staff to sort it out.

If you don't, turn things upside down and operate like a pyramid. Gravity is your friend; a lot of stuff just won't rise to the top.

---

Buy them at any online book retailer!

Do you trust the other side of the transaction?

---

The other side: the counter-party

In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.

 

In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 

 

Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.

 

About counter-party risk

So, you are about to enter into a transaction with another party. What might be the risks?

• Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
• Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  
• Willingness to perform their side of the transaction when the whole deal comes under stress may require backup
• Lead, or being led? Really, who's in charge in this relationship? Can you say you really understand what you are getting into?  Warren Buffet famously said words to the effect: 'I never invest in businesses that I don't understand' 

What is your strategy; what are your tactics; what -- or who -- can you trust?

• You might be able to trust if you can verify: Observable, measurable evidence that your counter party is doing their end of the bargain
• Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
• Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties, and opportunity to observe and measure; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.
  
• Always have Plan B in-hand: what if the counter party fails? What then? Can you exist or terminate the transaction? 
• Are the terms spelled out for mutual agreement? Is it 'liquid' or is there a timeline for exit that has to be accounted for in planning?
  
  

---

Buy them at any online book retailer!

Trust, but not trusting

---

"They say" that trust is essential to any project team working effectively. To not trust is to layer on ineffective and non-value add efforts at surveillance, double checking, micro-management, etc and so on.

Yet, nearly all projects of any significant scope are organized hierarchically:

• Some one is in charge
• Others "report to ..."
• Rules are a tool; they can substitute for face-to-face encounters
• Trust is not really required because 'rules' enforce acceptable behaviors
• Break the rules, and there are consequences. But, the consequences are usually time-limited. You get out of the dog house after you've served your time
  

Not so fast!

Hierarchies may be the on-paper way of organizing, but 'getting things done' requires networks; and networks are definitely not hierarchical. 

But networks run on trust, not rules. No trust ... no network, or least no network membership.

• Oh, yes, there are consequences, but, no, there are no time limits. 
• You may be in the dog house a very long time.

 And so here we are:

• On paper: hierarchies and no trust required. Rules are all that is needed; and consequences if the rules are broken
• In fact: networks are how people work; rules aren't need. But, if trust is broken, there are consequences. And those consequences are very long term.  

---

Buy them at any online book retailer!

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!