Activity - Methods - Outcomes

Back in yesteryear, I recall the first time I had a management job big enough that my team was too large for line-of-sight from my desk and location.

Momentary panic: "What are they doing? How will I know if they are doing anything? What if I get asked what are they doing? How will I answer any of these questions?"

Epiphany: What I thought were important metrics now become less important; outcomes rise to the top

• Activity becomes not too important. Where and when they worked could be delegated locally
• Methods are still somewhat important because Quality (in the large sense) is buried in Methods. So, can't let methods be delegated willy nilly
• Outcomes now become the biggie: are we getting results according to expectations?

There's that word: "Expectations"

In any enterprise large enough to not have line-of-sight to everyone, there are going to be lots of 'distant' managers, executives, investors, and customers who have 'expectations'. And, they have the money! So, you don't get a free ride on making up your own expectations (if you ever did)

At the End of the Day

• I had 800 on my team
• 400 of them were in overseas locations
• 400 of them were in multiple US locations
• I had multiple offices
• It all worked out: we made money!

---

Buy them at any online book retailer!

Agile and the Enterprise

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the Enterprise!

And where does that money come from? If you're not the Federal Reserve Bank, you can't print your own money; if you're not a bit coin miner, you can't create coins.

So, the money comes from customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise expectations

So, here's the thing: if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations .... starting with: value return on resources invested.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is required.

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience. Enterprises don't work that way.

There are rules

What makes an enterprise an enterprise is size and scale. And there is the rub: Sad to say, but size and scale is always more than a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. Such then brings rules, procedures, accountability, etc. into the frame.

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard three elements of the narrative you've heard before:

1. Scope: what is it you are going to do
2. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
3. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

You can't handle the narrative?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

Buy them at any online book retailer!

Numbers, numbers! Can't do without them

---

Numbers are a PM's best friend

Is this news?

I hope not; I wrote the book Quantitative Methods in Project Management some years ago. (Still a good seller)

So, here's a bit of information you can use:

Real numbers: (**)

• Useful for day-to-day project management
• 'Real numbers' are what you count with, measure with, budget with, and schedule with.You can do all manner of arithmetic with them, just as you learned in elementary school.
• Real numbers are continuous, meaning every number in between is also a real number
• Real numbers can be plotted on a line, and there is no limit to how long the line can extend, so a real number can be a decimal of infinite length
• Real numbers are both rational (a ratio of two numbers) or irrational (like 'pi', not a ratio of two numbers)

Random numbers

• Essential for risk management subject to random effects
• Not a number exactly, but a number probably
• Random numbers underlie all of probability and statistics, and thus are key to risk management
  
• Random numbers are not a point on a line -- like 2.0 -- but rather a range on a line like 'from 1.7 to 2.3'
• The 'distribution' of the random number describes the probability that the actual value is more likely 1.7 than 1.9, etc
• Mathematically, distributions are expressed in functional form, as for example the value of Y is a consequence of the value of X.
  
• Arithmetic can not be done with random numbers per se, but arithmetic can be done on the functions that represent random numbers. This is very complex business, and is usually best done by simulation rather than an a direct calculus on the distributions. 
• Monte Carlo tools have made random numbers practical in project management risk evaluations.

Rational numbers:

• A number that is a ratio of two numbers
• In project management, ratios are tricky: both the numerator and the denominator can move about, but if you are looking only at the ratio, like a percentage, you may not have visibility into what is actually moving.

 Irrational numbers

• A number that is not a ratio, and thus is likely to have an infinite number of digits, like 'pi'
• Mostly these show up in science and engineering, and so less likely in the project office
• Many 'constants' in mathematics are irrational .... they just are what they are
  

 Ordinal numbers

• A number that expresses position, like 1st or 2nd
• You can not do arithmetic with ordinal numbers: No one would try to add 1st and 2nd place to get 3rd place
• Ordinal numbers show up in risk management a lot. Instead of 'red' 'yellow' 'green' designations or ranks for risk ranking, often a ordinal rank like 1, 5, 10 are used to rank risks. BUT, such are really labels, where 1 = green etc. You can not do arithmetic on 1,5,10 labels no more than you can add red + green. At best 1, 5, 10 are ordinal; they are not continuous like real numbers, so arithmetic is disallowed.

Cardinal numbers and cardinality

• Cardinality refers to the number of units in a container. If a set, or box, or a team contains 10 units, it is said it's cardinality is 10. 
• Cardinal numbers are the integers (whole numbers) used to express cardinality
• In project management, you could think of a team with a cardinality of 5, meaning 5 full-time equivalents (whole number equivalent of members)
  

 

Exponents and exponential performance

• All real numbers have an exponent. If the exponent is '0', then the value is '1'. Example: 3exp0 = 1
• An exponent tells us how many times a number is multiplied by itself: 2exp3 means: 2x2x2 (*)
  
• In the project office, exponential growth is often encountered. Famously, the number of communication paths between N communicators (team members) is approximately Nexp2. Thus, as you add team members, you add communications exponentially such that some say: "adding team members actually detracts from productivity and throughput!"

 Vectors

• Got a graphics project? You may have vector graphics in your project solution
  
• Vectors are numbers with more than one constituent; in effect a vector is a set of numbers or parameters
  
• Example: [20mph, North] is a two-dimensional vector describing magnitude (speed) and direction
• In vector graphics, the 'vector' has the starting point and the ending point of an image component, like a line, curve, box, color, or even text. There are no pixels ... so the image can scale (enlarge) without the blurriness of pixels.
  

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

(*) It gets tricky, but exponents can be decimal, like 2.2. How do you multiply a number by itself 2.2 times? It can be done, but you have to use logarithms which work by adding exponents.

 

(**) This begs the question: are there 'un-real' numbers? Yes, there are, but mathematicians call them 'imaginary numbers'. When a number is imaginary, it is denoted with an 'i', as 5i. These are useful for handling vexing problems like the square root of a negative number, because iexp2 = -1; thus i = square root of -1. 

---

Buy them at any online book retailer!

Schedule management: who's in charge?

---

I mentioned the critical path and the most important path (they are different, sometimes) in a posting this week. Thus the question is begged: who makes all these decisions about resources assigned to the schedule, and who manages the buffers, and who manages the constraints (roadblocks)?

The buck stops with the PM, of course. 

Well, not exactly! Not all the time.
 

There's this problem: You've got a job to do; you've sequenced and scheduled it

But, in the middle of your critical path there is another independent project (or task) over which you have no control. In effect, your schedule has a break in its sequence over which you have no influence.

Yikes! 

This is all too common in construction projects where independent "trades" (meaning contractors with different skills, like electrical vs plumbing) are somehow sequenced by some "higher" authority.

So, what do you do?

If you have advance notice of this critical path situation, you should put both cost slack and schedule slack in your project plan, but there may be other things you can do.

 

Cost slack is largely a consequence of your choices of schedule risk management. 

Schedule risk management may have these possibilities:

• Establish a coordination scheme with the interfering project .... nothing like some actual communication to arrive at a solution
• Schedule slack in your schedule that can absorb schedule maladies from the interfering project
• Design a work-around that you can inexpensively implement to bridge over the break in your schedule 
• Actually break up your one project into two projects: one before and one after the interposing project. That way, you've got two independent critical paths: one for the 'before' project and one for the 'after' project

 At the end of the day: communicate; communicate; communicate!

---

Buy them at any online book retailer!

Supply chain scheduling

---

What can I say here that you've not heard before?

First: we are living in a time of scarcity, and so strategies for allocating scarcity come to the fore.

Second, demand for the scarce drives price -- no news there -- but demand itself may color supply and thereby schedule. Supply will not be directly correlated with price. Why? Because supply is what is going to be allocated, and price in dollars may not be currency. The currency of supply may take these forms: 

• allocation may bring loyalty into the mix; 
• may bring commitment to very long term relationships as the price of access
• may favor the cash deal over credit
• may require large up-front down payments that didn't exist before 
• may require quid pro quo: you have something I want; but I have something you want

Scheduling the scarce

So, now your job is to schedule in the context of such a landscape.

You begin with the normal risk tolerant scheduling techniques like those explained in "Critical Chain" theory:

• Be sure you understand that the 'most important schedule path' may not be -- technically -- the critical path. 'Most important' is where the critical value is as viewed by the customer or sponsor.
• Protect the 'most important' path by allocating what resources to that path first, and starving, if necessary, others
• Generously buffer around all the key milestones so that none are 'fragile' in the sense of bringing down the project if the nominal target date is missed

Architecture may help

Your architect can help you by designing-in all the anti-fragile strategies so that a missing part or resource, or a  sub-optimum substitute, is not fatal or cause a chaotic outcome. Your job is then to schedule these strategies into the master plan.

• Redundancy
• Negative feedback for stabilization
• 'Rip-stop' interfaces between subsystems, objects, and other elements

Your CFO may help

• Cash is king when demand exceeds supply
• Long-term contracts with favorable financial incentives may free up supply

Your take away:

Scheduling with scarcity is not just an exercise in time management. All the other disciplines can play a part.

---

Buy them at any online book retailer!

Just what we need: another reorganization!

---

"Whether in government or private business, office reorganizations are invariably touted as efficiency moves, when just as invariably—as anyone who has experienced one can attest—their short-term effects are redundancy and paralysis.

Naturally, the extent of these ill effects correlates to the amount of thought and planning—or lack"

Scott Anderson “The Quiet Americans".

What to do?

As a practical matter, PMO should reflect this experienced voice in project plans by planning for an initial dip in productivity, increased waste (likely increased cost) over the short term, and an extended schedule to allow this all to unfold.

To manage the risk, buffer all the critical tasks and milestones, and assume some less-than-expected performance in the short-term.

All this to give time for new relationships to form, new processes to be practiced and debugged, and for a steady-state to form and become apparent. 

And, of course, some stuff won't actually work; so some adjustment of the reorganization is to be expected, but perhaps only after a good shake-down period.

---

Buy them at any online book retailer!

Classified projects --

---

Most of my career has been working in the black and grey world of classified projects. 

If that is your domain, heed these words:

It is the nature of classified projects that "successes are unheralded and .... failures are trumpeted"

JFK

So, if you have an idea of putting your successes on your resume, looking for your next job, gig, or career move, beware!

 

---

Buy them at any online book retailer!

Virtual collaboration: a comment

---

" ....virtual collaboration is like evaporated milk with 60% of the water removed; safer; mostly up to the job, but a sterile version of face-to-face that leaves an unsatisfying aftertaste"

"Bartelby" columnist in the "Economist"

Our columnist goes on:

"There are downsides to being a clinically efficient worker. They include relinquishing the daily banter and complicity among colleagues..... Hyper efficiency and distance mean less opportunity for interpersonal tension but also less gratuitous job, which is hard to replicate on Zoom."

But then, on a business channel, I hear a start-up guy talking about developing a software application (alternative to Zoom, or Skype, or Webex) that has 'humanity built-in' 

"Humanity built in"! Perhaps, but let's wait and see ....

---

Buy them at any online book retailer!

Ghost writer and communicator

---

So, you work in project communications, perhaps directly for the PM. 

Great job, and it can be a lot of fun being creative.

In the 'old days', that probably meant long-form press releases and updates to the project web page or communications dashboard.

Today, it's those plus social media; scripts and plans for podcasts and videos; and other duties as assigned (ODAS)

But, if you're a ghost writer for the 'boss', who gets the credit? Do you have a byline as a contributor? And, does the boss get the credit for imaginative and effective writing or production when it's really you?

Welcome to the world of ghost writing. 

The person you're writing for gets the credit, usually, and you're lucky if you're recognized outside your PMO. You probably knew all that coming into the job. Why else is it called 'ghost' writing?

 

But what if you disagree in some fundamental way with the content of the communication you've been asked to write or produce? What then?

Two cases:

1. Opinion: It's not your opinion you're opining. You can write 'B' for the public, but believe 'A' privately.
2. False facts: If not about 'beliefs' but rather about misleading or even factually incorrect material, you have an obligation to push back. 

Life is too short

If you can't live with the material you're writing, then don't. Find new material; and find a way to persuade the boss to let you use it.

And if all that doesn't work, you may have to fire the boss! (Aka: get a new job)

---

Buy them at any online book retailer!

Projects and capitalism

---

'Capitalism' is in the news. And, not for the first time we're hearing about how corporations have an obligation more reaching than just the traditional shareholder value -- meaning profit maximization.

Community impact is now in the mix, more so than in the past, and that may mean capitalism will be paying attention to multiple factors beyond profit maximization:

• Environment -- a steady standby, to be sure
• Diversified workforce -- at least as diversified as the local community
• Job stability -- meaning, careful about robotics displacing workers
• Job location -- meaning, careful about remote working, virtual teams, and the lot
• Educational opportunity -- perhaps a mentorship with the local intern program or university
• Social justice -- meaning a safe workplace, and support for social justice in the community

Regardless of whether you think business should take these on, you probably think that these are 'C-Suite" issues -- isn't that what we pay them the big bucks for?

Not so fast!
There is flow-down to consider. Since at least 1992 -- ancient history for many of you -- the "Balanced Scorecard" has been a feature of business score keeping. And with it, a deconstruction and flow-down of corporate goals throughout the business.

And so, we can anticipate that such will reach to the PMO. 

Cost-Schedule-Scope-Quality
Wait! In the PMO, our thing is cost-schedule-scope-quality. Where do we fit that other stuff in?

• First effect: Scope -- some of these things will inevitably get cranked into our scope statement. Fair enough. But, scope connects to cost and schedule ..... don't forget that!
• Second effect: Cost -- it takes money to do some of these community things.
  
• Third effect: Velocity, meaning rate of throughput, meaning: schedule. No doubt some of these community things are going to slow us down .... but, perhaps a trade worth making.

Measuring the PMO
At the end of the day, project metrics should -- and will -- reflect this larger landscape. 

 

As examples of how such capitalism objectives might flow down to the PMO, maybe we don't remote as much as we could and keep a more robust local presence. Such will increase velocity because bandwidth has been added to team interactions and communications, and cost may be reduced a bit because remoteness is not free

 

Maybe we adjust the supply chain to be locally more than we need to -- in effect: buy local.

 

Maybe we hire less experienced but local people and invest in their development. Such may adversely effect velocity and cost in the short run but pay community benefits in the long run.

Steady on! Maybe we need a business culture from the C-suite that supports all this!

---

Buy them at any online book retailer!

The Incompetence Dodge

---

There are so many 'laws' that govern Project Management one wonders how to keep track of them all.

Now comes "The Incompetence Dodge", originally formulated by Sam Rosenfeld and Matt Yglesias. Their domain was foreign policy, but their idea can be recast to project management.

Simply put: if your idea failed, you need not look to the quality of the idea; you simply blame others for implementing your idea incompetently. 

Simple tactics, and the dodge

With such a simple tactic, any errors of strategy on your part are transferrable to others as errors of tactics!

Thus, you dodge around bad ideas by the ruse of incompetence by others.

How long can this go on?

How long? It depends on whether you are in charge of the time or the clocks.

If you've got time on your side, you can run out the clock, maintaining the dodge forever.

And, here's the really good part: you don't need jump on incompetence right away. You can wait and see which way it goes. 

• If your bad idea is somehow rescued by brilliant execution, you can claim victory. 
• But, if it goes awry, you can jump on incompetence and avoid personal defeat!

Bottom line: you can be blameless!

---

Buy them at any online book retailer!

Negative feedback: good or evil?

---

The question is posed: Is negative feedback good or evil?

Answer: Good!

Really? 

Yes, 'negative' is good.

Ooops: did I mention what feedback is? Generally it is a sample or portion of an outcome, or something quite similar but directly related to an outcome.

Here's the thing: 'Positive' feedback is reinforcing, agreed, but that may not be a good thing. The primary purposes of 'feedback' are to: 

• correct behavior (not always, or even mostly, human behavior), 
• prevent 'runaway' and chaotic responses, 
• confirm outcomes as expected, and 
• enhance the predictability of outcomes. 

These latter advantages come from so-called 'negative' feedback.

NOTE: providing feedback has its own jargon: We say: feedback closes the loop (the loop is from outcome back to the source that drives the outcomes), or the 'loop is closed'

Now the tricky part: Strength and timing are everything. 

To close the loop effectively, the strength (or amplitude) of feedback, and the timing (or phasing) of feedback has to be such that the feedback provides a countermeasure to the potentially errant outcome, the net effect being an outcome just as predicted, void of the bad stuff.

What could possibly go wrong?

Actually, a lot can go wrong.

No feedback at all is the worst of the worst: the 'system' is 'open loop', meaning that there are outcomes that perhaps no one (or no thing) are paying attention to. Stuff happens, or is happening, and who knows (or who knew)?

Timing errors are perhaps the next worst errors: if the timing is off, the feedback could be 'positive' rather than 'negative' such that the 'bad stuff' is reinforced rather than damped down. 

Strength errors are usually less onerous: if the strength is off, but the timing is on, then the damping may be too little, but usually you get some favorable effect

Practical project management

Feedback for correcting human performance is familiar to all. Too late and it's ineffective; too much over the top and it's taken the wrong way. So, timing and strength are key

But, the next thing is communication: both verbal and written (email,etc). Closing the loop provides reassurance of the quality and effectiveness of communication. You're just not talking or writing into the wind!

And, of course, in system or process design, loops should never be open. Who knows what could happen.

 

---

Buy them at any online book retailer!

Sketching out the architecture

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it."

Box model

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr. Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Buy them at any online book retailer!

The Requisite Law of Variety

---

Now, this could be a bit stuffy, but it's actually quite readable: "The Requisite Law of Variety"

Reduced for a quick understanding, 'the Law' is an interesting concept to consider, to wit:

• Essential Elements (E): these are outcomes, results, or other artifacts that you want to have some control over; or they are controls and mechanisms that you have to influence outcomes and results and disturbances
• Disturbances (D): these are events or actions that impact E .... usually there are a lot of these!
• Regulation (R) or controls: these are the means or actions to limit the impact of D's. Even in the Agile world, there are some controls or protocols to regulate the pace and rhythm
• Passive capacity (K): in effect, buffers and elasticity that limit the fragility of the system and allow for some absorption of D without breaking E 

The Law is a bit mystical when expressed as math, essentially saying:

"the the variety -- or set -- of the E's that you need or value should be greater than

• the variety -- or set -- of disturbances (D) reduced, absorbed or mitigated by regulation (R) and
• other, or further, disturbances reduced by buffers or elasticity (aka: passive capacity, K)."

Practical project management

In other words, the practical advantage to a PM for having a big variety of Es is that Es overwhelm a smaller variety of Ds (or diversifies or dilutes the impact of Ds ) because big E implies a lot of different outcomes that are important, and a big tool set with which to work (*)

Risk management point of view:

So, whereas, some variety of Ds may have impact of some part of the Es, not all Es will be affected. Thus, the larger the variety of Es, the less impactful is a much smaller variety of Ds.

Value proposition point of view

If there is only one thing that is important to you as a project outcome, all your value is in that one thing. Consequently you have set up a vulnerability such that a single disturbance could wipe out your value proposition.  That is way too fragile!

And, 'having only one thing' violates the Law of Variety which intones that the variety of Es should be greater than the Ds that could impact E.

Anthony Hodgson puts it this way:

[The Law of Variety] ... leads to the somewhat counterintuitive observation that the regulator [or PM] must have a sufficiently large variety of actions in order to ensure a sufficiently small variety of outcomes in the essential variables E.

This principle has important implications for practical situations: since the variety of perturbations a system can potentially be confronted with is unlimited, we should always try maximize its internal variety (or diversity), so as to be optimally prepared for any foreseeable or unforeseeable contingency.

If you are familiar with the ideas of "anti-fragile" in system design, this last sentence is a good alternate phrasing for what makes systems anti-fragile, i.e. resilient

---

(*) In effect, the Law of Variety provides opportunity to define project success in several ways. If one of the Es doesn't work out, perhaps another one will. 

Some might say that with such a strategy, every project can be successful, or none a total failure: you just need to find a good E to hang your hat on. 

With such reasoning, it's not hard to conclude that 'project success' or 'failure' metrics are tricky. For more on this debate, look to the endless commentary on the Standish Reports of project success.

---

---

Buy them at any online book retailer!

The worst error in scheduling

---

The worst error in scheduling is to have a milestone depend upon two or more tasks scheduled (planned) to finish at the same time.

Here's a footnote to that witticism: It's assumed the two tasks are independent, meaning:

• They don't share resources
• They don't have the same vulnerabilities to a common risk
• The progress, or not, in one does not affect progress in the other

So, what's the big error here?

• First, as regards milestone success , each of the tasks leading into the milestone is a risk to success (success means: it is achieved on time)
• Second, total risk is the product of all the input risks (as seen by the milestone) . 
• So, whereas each task coming into the milestone may not be too risky, say by example 90/10 (*), three tasks of 90/10 each would present a risk to the milestone such that success is reduced to about 73/27

(*) 90 successes out of 100, or 90% chance the task will finish on time, or early.

What are you going to do about this?

Bring on the time buffers! (**)

• You might be able to add a buffer on one or more of the input tasks to raise the success of that task to 99/01, or so
• You might be able to add a buffer following the milestone, such that any late success is absorbed by the buffer (This tactic is called "shift right" by schedule architects)
• You might be able to reorganize the schedule to eliminate this milestone, or one or more of its input tasks.

(**) A scheduled event of zero scope, but a specific amount of time, aka: a zero-scope time box.

---

Buy them at any online book retailer!

Can you spend $1M in a month?

---

Here's the challenge: On your project, can you spend $1M in a month?

Take a minute and think about it.

Consider:

• If you've got 100 people with an annual payroll of $15M, then yes, it's possible, even likely
• If you've got 20 people with an annual payroll of $3M, then maybe, with overtime and some material charges.

Got your answer?

Good!

Then here's another challenge: If you can spend $1M in a month, can you do a $1M project in a month? Are they one and the same thing?

Consider:

• It's hard to get 100 people up and moving coherently to start and finish something in a month (that $1M may disappear into "start-up" inefficiencies)
• It's not too hard to get 20 people moving, but you might have to really work on motivation if you think you're going to spend $1M on people, but there may be tools, training, facilities, etc that will absorb funds.

So, having thought about it, maybe if you really need your 100-person team, 2 months and $2M is a better thing to have;

And, if you only need your 20-person team, even with overtime, you will be hard pressed to spend as much as $1M

What does all this mean?

You've just made some 'estimates' (gasp! that dreaded word)

Perhaps a bit crude and rude, but at least the 'breadbox' is somewhat defined

Never let it be said that nearly every minute of the day we are not making estimates:

• How long to get to the computer (home or office)
• How long for that meeting
• How much time to spend on email
• How much to spend on a car, hotel, or even a cruise
• On, and on, estimating!

---

Buy them at any online book retailer!

Which comes first .... A or B?

---

This is not about the A/B argument in Agile methods. 

This is about get the elements of project scope sequenced in the right time order 

• Does "A" come before "B", or not, and 
• Is there a dependency between "A" and "B"? 
• If not, then the sequencing question may be moot. If they are truly independent, then they can be scheduled for convenience, or according to some other dependency, "C"

But if the "A" before "B"? question is viable, then ...

Sequencing is the first task in forming a schedule, but only after you figure out the scope.

 

A before B

If you understand the nature of A and that of B, then if there is a dependency between them vis a vis time order, then getting A done before B sounds easy, but sometimes it makes you wonder!

• Is there a preamble to B that should be done before A is completed?
• Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
  
• Can B really start after A, or are there other dependencies on the start of B?
  
• Do I really want B to start, or do I want to pause and start C somewhere else? 
• If I start B, immediately after A, have I introduced unnecessary risk or other impacts?
  

Schedule depends on sequence

So, if you're thinking about sequencing, you're probably also thinking about schedule: how long it's going to take?

Or, the other way around: if you are working on a schedule, you have to get the sequence down first. 

 

From time to time, arguments boil up about scheduling tools, like MSProject and others. The usual thinking is that these tools are "so last century" and haven't kept up with more agile planning techniques. 

 

And, worst of all, these older tools promote waterfall (gasp!) scheduling, which is demagoguery for finish-to-start precedence. 

 

Finish-to-start precedence is a sequencing concept. If you pooh-pooh such precedence, I challenge you to put up the roof before the walls are in place.

It's all about the sequencing

First, you have to know what you are going to do. To wit: you can't sequence that which you don't know about, and furthermore, even then there may be sequencing errors you discover once you understand the full extent of the scope.

 

For any project, step 1 is to assemble (or define) the elements of scope by some affinity criteria. (Using the roof-after-walls example, get all the roof stuff in one grouping, and all the wall stuff in another grouping. That way, you can sequence the roof group after the wall group.)

Advice to PMO

At the PMO level focus on the major sequences that drive toward value-add milestones.

---

Buy them at any online book retailer!

Of clocks and time

---

What does this mean?

You have the clocks, but I have the time!

It means:

• If you are a tactical thinker, and I have the patience for the strategic, then I'll win in the end
• You may win all the battles, but I'll win the war (See: American revolution war with England)
• You may misunderstand the fundamentals of the project nemesis. You may be too lazy to understand; you may be the one that kills the messenger; you may be drinking your own Kool Aide (See: group think, bubbles, silos, small inner circle, etc)
• You have mistaken the tree for the forest
• You have a serious case of 'confirmation bias'

---

Buy them at any online book retailer!

Let it be mensurable!

---

To be mensurable is to be 

• Measurable
• Calculable
• Estimable
• Determinable

And, why do we care?

Enter: risk management

To compare two dissimilar risks violates the rule that risks to be compared must be similarly mensurable.

In a recent post, Matthew Squair, writing at 'critical uncertainties' makes the point that early on ....

(and I quote Squair)

".... lockdown sceptics were pointing out that your risk of drowning in a pool, in California, was much higher than that of dying from Covid 19 so why to worry? if you feel this is intuitively wrong, in fact wronger than wrong, you're right.

One of these risks is based on an independent probability. That is if I drown in a pool it's not going to have an affect on the probability of my neighbour drowning. But, on the other hand if I have Covid 19 you'll find the probability of my neighbour having Covid 19 is dependent on that; that is, the probabilities are dependent.

In one we truck along with a base rate of events unaffected by each other, in the other the events can affect each other and the risk can suddenly blow up.

To be very clear the two risks are immensurable and not directly comparable."

He goes to point out that many such immensurable comparisons are being made in the Covid space, such as the risk of getting Covid itself compared, incorrectly, to the risk of blood clot from a vaccine, etc.

---

Buy them at any online book retailer!

Tactics and strategy

---

Consider this military bit or wit, and put it in the context of a PMO dealing with tactics and strategy, as well as tactics and logistics on complicated and complex projects. Are you the professional or the amateur?

"There is an old—and misleading—bit of conventional military wisdom which holds that “amateurs study tactics, while professionals study logistics.”

The truth is that amateurs study only tactics or logistics, while professionals study both simultaneously.

The most brilliant tactics ever devised are pointless when the supplies needed to execute them do not exist, while all the supplies in the world are useless when a commanding officer has no idea how to effectively employ them."

Quote from "Field Marshal: The Life and Death of Erwin Rommel"

by Daniel Allen Butler

---

Buy them at any online book retailer!

You are a fiduciary

---

Alex Korda, a British businessman in the late 1930s, was quoted as saying about a project budget, with a shrug:

“A lot of money—other people’s money, of course, but still a lot.”

Let me offer some advice: when it's other people's money (OPM), it could be career-shortening to shrug off the budget or the budget overruns.

And, by the way, as a PM, you have a fiduciary responsibility to always act in the best interests of your "client". In this case: whoever's money it is. If it is not yours, then you should walk a mile in their shoes and handle their money the way they would.

---

Buy them at any online book retailer!

The best thing you can do to manage risk?

---

You ask: What's he best thing I can do to manage risk?

Answer:

Make time your friend. 

 

Insert time buffers in your schedule around every uncertain event, around milestones that are critical to success, and around major blocks of scope that determine whether project objectives will be met.

Time is your friend if it is allocated in your schedule to give you space to work, and rework, mitigations. Time is your friend if you have the space to accommodate the less optimum outcomes. 

But time is not your friend if you've not allowed for the consequence of coupling between risky outcomes, and have not provided a buffer space to work the work-arounds.

Beware of shift-right!

What's "shift right"? 

If a milestone success is determined by the likelihood of multiple independent outcomes finishing together, then the likelihood of the milestone finishing on-time is degraded by the product of their likelihoods. To restore the confidence in the milestone schedule, it has to be shifted to the right.

Example: Two independent outcomes of 80% confidence each result in a 64% confidence in their joint success

So, if you buffer that milestone in the first place, then the "shift right" is built-in from the beginning and is not a shock when it happens.

---

Buy them at any online book retailer!

Let's hear it for bureaucracy!

---

If you can't trust your people

Or, you don't know your people well enough to trust them

And, you can't replace the former

Nor do you have time to get to know the latter .....

Then the management solution is simplicity itself:

Invent a bureaucracy and assign them to it!

Bureaucracy is the management alternative to trust. 

• Rules, regulations, and punishment do all the work. No fuss, no muss!
• Sometimes, incentives are useful, so don't leave them out.

Now admittedly, bureaucracy cuts against the flat, agile grain which is "the way to do it" for modern managers. 

But, beyond a point, flat is too flat, and agile is too agile.

Let's be realistic:

• Many can not handle complete freedom, 
• Have questionable judgement, 
• Are misaligned to strategic goals and imperatives, and 
• Generally spend time and money without regard to the fact that neither the time nor the money is theirs.

Bring on the bureaucrats!

---

Buy them at any online book retailer!

The only two things you need to know about statistics

---

Number One: It's a bell, unless it's not
For nearly all of us when approaching something statistical, we imagine the bell-shape distribution right away. And, we know the average outcome is the value at the peak of the curve.

Why is it so useful that it's the default go-to?  

Because many, if not most, natural phenomenon with a bit of randomness tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency for random outcomes to cluster around the center, giving rise to the symmetry about the central value and the idea of "central tendency". 

To default to the bell-shape really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data. 

In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

Number Two: the 80/20 rule, etc.

When there's no average with symmetrical boundaries--in other words, no central tendency, we generally fall back to the 80/20 rule, to wit: 80% of the outcomes are a consequence of 20% of the driving events. 

The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, are the mathematical underpinnings for understanding many project events for which there is no central tendency. (see photo display below) 

Jurgen Appelo, an agile business consultant, cites as example of the "not-a-bell-phenomenon" the nature of a customer requirement. His assertion: 

The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range

What's next to happen?
A lot of stuff that is important to the project manager are not repetitive events that cluster around an average. The question becomes: what's the most likely "next event"? Three distributions that address the "what's next" question are these:

• The Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], 
• The Exponential Distribution [commonly used for evaluating system device failure probabilities], and 
• The Poisson Distribution, commonly used for evaluating arrival rates, like arrival rate of new requirements

Two things are good enough
For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

Otherwise, fall back to the Pareto concept. It's good enough.

---

Buy them at any online book retailer!

Plausible denial

---

What follows is an all-to-sad commentary on government. 

But what if "government" was "PMO" in this quotation? That would be really sad. 

Perhaps "lie" is too strong; perhaps 'self-delusional' or some other less in-your-face spin is more the case. But you get the point: the unvarnished truth is sometimes just too much for the moment. Time is necessary to find your way back on the center stripe. And to make time, some spin of the truth is required.

Perhaps; but plausible denial: that's running from responsibility. That can not be condoned.

“It is a truism that all governments lie: they lie to each other, they lie to their own people, they frequently lie to themselves. 

But a fundamental premise of functional government is that such deception .... must be an exception rather than a norm: to rule effectively, a government must be able to maintain at least a minimum level of credibility; by the same token, it must inevitably fail when it chooses to function on plausible deniability alone"

Daniel Allen Butler

---

Buy them at any online book retailer!

Two choices

---

To a senior manager:
"What is the best way to manage a project?”
In response:
“You’ll find that there are always two possible decisions open to you,” the senior manager replied crisply. “Take the bolder one—it’s always best"

Daniel Allen Butler (paraphrased a bit)

---

Buy them at any online book retailer!

Perfect proposals (by Clayton)

---

Do you read Mike Clayton? You probably should.

Here is his idea of the 12 points of a perfect proposal:

What are the elements of a perfect proposal? Here are 12.

 

You

No one wants to hear all about you. See the next subtitle. That's who your audience wants to hear about... themselves. But (and it's a big 'but') they do need to know enough about you to know you are worth paying attention to. So, for a cold proposal, this means using the introduction or cover letter or some other means to establish your credibility - what my dad used to call your bona fides.

Them

This is what they want to know... What's in it for them? Show how you have their best interests in mind with this proposal. You understand their needs and desires and know how to satisfy them better than any alternative solution can.

Focus

Keep your focus on the specific situation. Any sign of standard 'boilerplate' descriptions, arguments, or evidence will make it look less about 'Them' and more about 'anyone'. 

Value

How will your proposal deliver and maximise value to them? The vast majority of business decisions revolve around the capacity to either make money or save money.

Benefits

But there can be other benefits too. Describe the non-financial value your proposal offers - and what this means to them. This, of course, means you need to take time to understand them and their requirements and priorities. 

Emotions

All that hard evidence gives them a reason to make the decision to accept your proposal. But it won't motivate them to do so. For that, you need to tap into their emotions. Find emotional hooks into pride, fear, duty, desire, ambition, loyalty, passion... Emotions drive decisions: reasons justify them.

How

So, you also need to show how your proposal will solve their problem, deliver their joy, or enhance their reputation. Make the link between what they want and what you are proposing as clear, simple, and short as you can. A 15-step sequence from the cause (your proposal) to the effect (their outcome) won't cut it. 

Process

Next they need to know what will happen if (when) they say yes. What will you do, what will they do, and how long would it all take? For confidence that your is the right choice, they need to see a plan that clearly works.

Context

This section lets them understand how your proposal fits into your life and theirs - your business and their own. This shows that you and they are compatible and is the equivalent of the more traditional (cheesy) 'how we are different to the competition'. Of course this differentiates you. It shows how this proposal is right for them and for you.

Business

Don't go all techy on a technical proposal. Remember who you are speaking to. If your audience is a business person or a group of businesspeople, focus on the business. If your audience is software engineers, focus on the business of software engineering: not the hardware. What is their business? That's how to frame your proposal.

Structure

I get it. You have a lot of ideas to get down. But, before you start, develop a structure that makes it compelling for them to follow. If they asked six questions in a sequence, then a great structure is to answer those six questions... in the same sequence. Make it easy for them to say 'yes'.

Quality

Finally remember Mark Anthony's advice: 'The evil that men do lives on. The good is oft' interred with their bones'. People remember your mistakes and easily forget all the good stuff. Make sure you check the quality of your proposal, not once, not twice... Better still, get the pickiest, most pedantic person you know to do it for you. You invested all that time. Now add a little more investment, to avoid throwing it all away!

---

Buy them at any online book retailer!

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!

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!