Einstein's methodology

---

"When I have one week to solve a seemingly impossible problem, I spend six days defining it, and then the solution becomes obvious."

Albert Einstein

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Building the Appian Way

---

As a project, the Appian Way was monumental for its time: Phase I, built in only one year .... 312 BCE ... the paved road (originally, a military road) cuts through the Alban hills and the coastal Pontine marshes to connect Rome to far southeast Brindisi.

But think about this: the Project Executive Officer, PEO, one Appius Claudius Caecus, did not have a couple of tools at his disposal that we so routinely use that they are not even noticeable:

• There was no "0" in the Roman system of math. "Nothing" was not a number. Roman numerals are/were for counting and positioning (ranking, or ordering), but not for measuring. Today, we say that Roman numerals are "cardinal" numbers, meaning numbers that are for counting.
  
  How did Caecus calculate his project variances? Was zero-variance not a possibility, given no '0" in the system?
  
  However, to build a road, you've got to be able to measure things. So, when it came to measuring and dealing with quantities, the Romans relied on a separate system known as the Roman system of measurement. This system was based on various units and standards, such as the foot (pes), the inch (uncia), the palm (palmus), and the cubit (cubitus), among others. These units were used for measuring length, weight, capacity, and other quantities.  
  
  
• There were no fractions in their system of mathematics, even though a pseudo-system of fractions existed in ancient Egypt. Maybe if Marc Antony has been around three centuries earlier, he could have brought fractions home.
  
  
• And, there were no negative numbers. This concept is almost middle-ages in its origin. Not until the 16th century did negative numbers really come into general mathematics. 
  
  Does this mean that Planned Value - Earned Value (*) was always positive? That if circumstances were such that at some point EV were greater than PV, a negative number to be sure, that Caecus could only describe that he was ahead of plan, but couldn't calculate it?
  
  
• And, of course, there was no concept of random effects and probability.
  Those effects were left to the Gods. (See my review of the book on risk management entitled "Against the Gods")

They did it

So, somehow, the Romans built a magnificent road, parts of which survive today, without a "0", without fractions (formally at least. One can imagine half a cubit, even if they can't formally express the idea), and without negative numbers. 

I wonder if I could run a PMO without these tools? Doubtful! And, my PMO would also have random numbers and systems of probability which also did not come along until about the 18th century.

_____________

(*) PV - EV is a variance, calculated at a specific point in time, that indicates positive or negative schedule variance. You've either earned what you've planned at the right time, or you've not. Some caution, however: this formula is only valid for only the duration of the baseline timeline of the project; it's not valid thereafter. Example: It's invalid to be a year late beyond the baseline delivering all the EV, and then declare that PV - EV is 0, thus no schedule variance!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Think often, think critically

---

Boom! Sometimes we react without conscious thinking. That's survival impulses kicking in.

But there are not a lot of "booms!" in the PMO.

Thus, there's time to think.

And thinking is what occupies most of the time in the PMO domain.

So, if thinking is what we do, then we should be thinking of the quality of our thoughts.

And for quality in the large sense, we should "Think critically"

Critical thinking can be about a lot of things, together, independently, holistically with the environment. Common components are these:

Analysis: Breaking down complex ideas or information into smaller parts to understand their components and relationships. This is process-thinking to reduce or deconstruct complexity.

Evaluation: Assessing the credibility and quality of information, arguments, and sources by examining their strengths, weaknesses, and biases. Especially the biases, of which there seem to be an almost endless list.

Inference: Drawing logical conclusions based on available evidence, reasoning, and patterns. But don't stop with the first inference you make: Bayesian reasoning comes in here: test the hypothesis; gather more evidence; modify the hypothesis, and test again. Repeat.

Interpretation: Making sense of information and identifying underlying meanings or implications within the context of the project, the business, or the environment. Interpretations are always situationally sensitive.

Problem-solving: Identifying and defining problems, generating and evaluating potential solutions, and selecting the most effective course of action .... which may be prototyping and experimentation to ascertain risks and practicalities of the chosen course.

Reflection: Examining one's own thought processes, assumptions, and biases to enhance self-awareness and improve future decision-making. This, you might say, is another Bayesian process.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The Four Maths of the PMO

---

Math may not be your favorite thing in the PMO, but hear me out.

There are four 'systems' of math you are probably using without thinking too much about them.

So, if that's so, why think about them now?

• Somebody may use the terminology around you, so informed is better than ignorant
• Communicating with your administrator, analyst, or systems person may be more informed
• You may want to learn more about one or the other, so a look-up of terms is handy

Here's a quick read on the four:

1. Arithmetic and linear algebra: Arithmetic is the add-subtract-multiply-divide thing you have been doing all you life; linear algebra is just using arithmetic in a systematic and rules-based way -- in other words, formulas -- to find some values you might not have but need  (that conveniently lie along straight lines (thus, 'linear')
   
   This is really useful stuff for adding up costs, figuring out schedules durations, and solving for resource unknowns, not to mention (gasp!) working forecast with earned value formulas
   
   
2. Exponentials: See my post on this topic. Exponentials form the world of non-linearity (no straight line). Exponentials are seen in the project office explaining  the non-linear "utility" of the project's value proposition, escalations in communications complexity, discounts for future risks, discounted cash flow (DCF) methods, and other useful stuff
   
   
3. Statistics: Statistics, and its close cousin 'probability', let us deal with uncertainty in project affairs. In this domain, we find 'random numbers': that is, numbers that are a bit uncertain because of incomplete knowledge or because of random effects (for which more knowledge doesn't help).
   
   We can't do arithmetic directly on 'random numbers' because we don't have certain knowledge of what to add or subtract from one random effect to the next. Thus, simulations of statistical effects are the best way to handle such requirements. The 'Monte Carlo' simulation that is built-in to many scheduling apps and some cost and finance apps is an example of handling statistical effects on schedule numbers with simulation.
   
   Keep this idea of 'no arithmetic with random numbers' in mind when people come to you with a risk matrix that purports to multiply random numbers for uncertainty and impact. No can do!
   
   
4. And then there's calculus! You say: 'I can skip this; we don't use calculus in our PMO.' Actually, you do! Calculus is the math of 'change'. And there are always change and changing effects in the PMO.
   
   One powerful idea from calculus is that we can add up the individual effects of change, usually a lot small effects, and we call this process 'integration'. Even more handy, we can specify the integration limits to include only those effects in which we are interested. 
   
   Here's an example of something you probably know about: The so-called "S" curve of accumulating probability. This curve is very handy for assessing confidence limits in risk management. It is actually an integration result straight out of calculus. Small increments of probability from a "bell curve" are integrated to form the S-curve. In other words, if we 'integrate' the "bell curve", the result is the "S" curve!
   
   Of course, the ideas work in reverse: Given the "S" curve, we can 'differentiate' it into the "bell curve" which then provides visualization of central clustering, and visualization of the outliers on the tails where events happen infrequently. 
   
   The secret to understanding derivatives is that they are always ratios: "something per something". If the "per something" part is time, then usually the ratio is a velocity or an acceleration; otherwise it's a density, as in 'parts per million'. The bell curve, being a derivative of cumulative probability, expresses a 'probability density'. 
   
   But maybe you are working in Agile methods and are concerned for 'velocity' and perhaps even the need for 'acceleration' of the evolving product base. Agile product velocity is the "first derivative" of a unchanging base; 'acceleration' is the first derivative of velocity and the second derivative of the original position.

Got it all?

Now you are the PMO math person!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Your project runs on exponentials!

---

When you read stuff like this, you have to wonder: what's this all about?!

The greatest shortcoming of the human race is our inability to understand the exponential function
- Albert A. Bartlett, The Essential Exponential! For the Future of Our Planet

Sounds profound! 

And so it is. Exponentials are the way we bend the project around the corner, or move out quickly. Linear straight-line stuff becomes curved.

Think of it: 

• The future does not have to repeat the past; 
• We can accelerate from where we are now; and 
• Phenomena can -- and will -- die off or slip quietly to an asymptotic finish

What is it?

Technically, an exponent is a number that tells you how many times another number, called the 'base', is multiplied by itself. For example, 2 exp 4 tells us to multiply 2 (the base) by itself 4 times, yielding the number 16. The exponent is sometimes referred to as 'the power'. We might say, '2 to the power of 4'.

Fair enough.

Functionally, it's the multiplying-by-itself thing that bends the curve and creates acceleration in values. In linear arithmetic, the first four products are 2, 4, 6, 8. But in exponentials, the first four products are 2, 4, 8, 16 ; clearly the exponential expression is not linear.

It's common to say: "That's increasing (or decreasing) exponentially". 

What that means is that 'as you move away from the present point, things accelerate quickly'.

Now, for the math inclined or curious, see the footnote at the end of this post.

Consider project communications:
The number of ways that N people (or systems or interfaces) can communicate is N*(N - 1), which for large N is approximately N x N, or N-squared (an exponential, N with exponent of 2).  

This the heart of the argument -- made famous by Dr Fred Brooks --  that adding more staff to a late project may make it even later, because ....  Because communications become exponentially more complex, and thus less reliable and predictable, as you add staff.

Consider project finance:
The present value of future business benefits of a project are discounted, exponentially, by the expected risk.

Financiers think of risk in terms of the 'rate of return' they demand in order to agree to commit capital to a risky project.

And, this rate of return, "r", is compounded over time. Compounding means that [1 + r] exponentially decreases with the number of compounding periods. The future value is "discounted" to a present value by that decreasing factor.

Consider risk management:

The idea that risk inversely compounds exponentially with time, and thereby discounts the value of future decisions and outcomes is commonly held concept in risk management. 

Other types of risk are subject to exponential effects. For example, the density of probable failures in the future is inversely and exponentially related to a present value of the failure rate. 

Consider the so-called "bell curve"

The 'bell curve' shows us the effects of natural clustering of random outcomes or observations around the mean value.
The actual formula for the curve is non-linear to be sure, and usually we just look up values we are interested in, which for the most part delineate confidence intervals.

But at the core of the bell curve formula's is an exponential expression which is all about how far from the mean is the confidence interval and the point of observation or measurement, i.e: 'distance'-from-the-mean squared strongly influences the confidence intervals of the 'bell curve'.

Consider schedules at the milestone

There is a 'shift-right' tendency at milestones when two or more tasks have to finish together. If the probability of each finishing is 0.9, then the probability of the milestone finishing on time is 0.9 exp N, where N is the number of tasks finishing together. That is a much lower probability of success than any of the contributing tasks.

Consider the random arrival rate of independent actors (events)
Again, the probability distribution of random arrivals is an exponential, and an important concept in certain elements of risk management (Earthquake prediction, to name one, but other types of failures as well). 

Consider 'utility'

All but the simplest concepts of utility are non-linear, and many ideas of utility can be explained or represented with exponentials.

-----------------
If you look up Bartlett's book, you'll find most of the chapters are available free in pdf format
Shout-out to herdingcats for the quotation

Footnote for the math inclined or curious:

It's common to think of the number '2' as 2 with an exponent of 1 (any number with an exponent of 1 is equal to itself); and the number '1' is 2 with an exponent of 0 (any number with an exponent of 0 is equal to 1). Other examples: The number '4' is 2 with an exponent of 2; the number '5' is 2 with an exponent of about 2.35, but also 5 is the number 10 with an exponent of about 0.7.

And, a negative exponent is mathematically equivalent to division: 1 divided by the exponential. For example, 0.5 is just 2 with -1 as the exponent, usually written as 1/2.

But here's a limitation of exponent math: there is no exponent that will give us exactly the number '0', although we can get pretty close with an arbitrarily large negative exponent. 

Now the "base" doesn't always have to be '2'. If we change the base to 10, the number 2 is now 10 with exponent of approximately 0.3. (somewhat like there is no exponent that gives us exactly the number 0, there is no exponent of 10 that gives us exactly the number 2. This is the reason that financial reports and other resource reports are not computed with exponential math. Such reports require exact numbers, not approximations)

You may have heard the expression that "things are logarithmic". That's another way of expressing the idea of an exponential. The 'logarithm of 2 (in base 10) is equal to 0.3'. That statement is equivalent to saying '10 with exponent of 0.3 is equal to 2'.

---

Like this blog? You'll like my books also! 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!

Dodging the pandemic

---

If you're a PM running a project during the pandemic, you probably have one or more of these problems:

• Supply chain issues: stuff is out of stock; stuff is not available on time; stuff costs more
• Velocity and throughput issues: Throughput is slower to achieve; there's more overhead and NVA (non-value added)
• Communication errors: Remote work is really work with restricted bandwidth; nothing really replaces the high-bandwidth of in-person person-to-person communications, formal and informal. Restrictions introduce timing errors; misunderstandings; information gaps
• Matrix assignments: to keep people off overhead, they are assigned piecemeal to multiple projects. But this introduces commitment conflicts and start-stop inefficiencies
• Innovation MIA(*): Most innovation is a beneficiary of a lot of informal collaboration that somehow surfaces a neat thing to do. Such may go MIA with remote working

So, what is to be done in such an environment as described above?

• First, bring on the slack! You need to buffer every budget ... cost or schedule ... with slack (white space) that allows for the project to absorb small shocks in supply chain, velocity blips, resource conflicts, etc. Such a strategy is the essence of being "anti-fragile"
• Second, be aware of -- and react to -- constraints (bottlenecks) that may move about ... here and then there ... as external circumstances change. You may need to be at the top of  your game applying the "theory of constraints" (**). 
• Bring in redundancy and work-arounds to keep things moving. You may need back-up supply chain options, prototypes, and ability to work with reduced scope by applying redundant capabilities (instead of 10 blades in the rack, maybe you can work with just 6 that are essential)
• Add excess bandwidth to facilitate increased informality and opportunity for interaction.

Bottom line: Make everyone in your chain aware of the lean-in you are doing so that there is confidence and support for your PMO.

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

(*) MIA: missing in action
(**) Read about Elihu Goldratt's "Theory of Constraints" on Wikipedia or elsewhere

---

Buy them at any online book retailer!

Beware common sense!

---

This bit comes to us from Neil deGrasse Tyson from his book "Accessory to War"

"What separate great scientists from ordinary scientists ... is the capacity to .... not let common sense dictate or constrain their thinking.

The formidable English physicist Issac Newton, for instance, questioned the the fundamentals of light and color. Who in their right mind would have thought that ordinary light -- white light -- was composed of colors at all?"

In contemporary parlance, this is "thinking outside the box", a meme of behavior and mindset which Tyson might have us believe separates the really good from the only adequate.

Of course, there is a case for "only adequate" which probably describes the bulk of practitioners since the truly gifted and great are out on the tails, as it were. "Only adequate" gets us safe and sturdy, risk averse, tried and true, and free of controversy. The ball does not advance very far, but then it's not supposed to.

On the other hand, "only adequate" isn't going to get you "E = mC2" and all the rest. If you are going to try to convince the world of space-time warp, best to avoid common sense!

---

Buy them at any online book retailer!

The case for "little data"

---

"Big Data" is the meme of the day, but most projects run on "little data", the sort of data that fits into the constraints of spreadsheets like Excel. It's everyday stuff that drives estimates, scorecards, dashboards, task assignments, and all manner of project analytics.

So, assuming you using Excel as a spreadsheet for doing actual calculations and data entry, and not a row-column table version of Word, you will find that you to do some analytics and data analysis from time to time.

Pivot tables are one spreadsheet data tool, but that's not the discussion today. Today, it's filters, which is the Excel name for the process and tool, but which the database people -- familiar with SQL for row by column -- would call a query.

And so, how to do a filter in Excel, something practical for the project manager? There are Youtube's galore on the subject, but here's a neat, step by step, illustrated process that goes from the simple to the advanced.

Just what the PMO need to get into the data business

Some other rules
Beyond what you will read in the linked article, there are a few data rules that will make life simpler

• Every column should have a header or title that is unique, even if just column1, column2, etc
• Only one data value in a cell. Thus, first and last names should be in separate columns; so also city and state. But maybe also captain and ship's names. This is called "normalizing" the data
• Keep the static data in separate row/column areas from the data that changes. So, if a ship sails to San Francisco on a certain date, the ship's description goes in one area; the city description in another; but the city/date/ship is dynamic and belongs in a third area.
• Don't put 'word processing' paragraphs or labels in the middle of the data. In other words, maintain the integrity of row by column
• It's good to have at least one column that is guaranteed to be uniquely valued in each cell, like a row ID
• If you can avoid using "spaces" in the data, that's good. It makes the query more sure. So, "column1" instead of "column 1"

 

---

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

Hello! Robots have limits!

---

Elon Musk, lamenting at the June shareholder meeting about Tesla production

“One of the biggest mistakes we made was trying to automate things that are super easy for a person to do, but super hard for a robot to do,” he said. “And when you see it, it looks super dumb. And you are like, wow! Why did we do that?”

---

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

The real problem?

---

"I cannot define the real problem, therefore I suspect no real problem, but I'm not sure there's no real problem"

Richard Feynman, Theoretical physicist

---

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

Good ignorance

---

Ordinarily, we don't put much value on ignorance -- or being ignorant. It's said that in the pre-modern world, say before the enlightenment in Europe in the middle of the first millennium, that all you needed to know was pretty much what could be learned from history. If it wasn't known, then you didn't need to know it in the same way your forebears didn't know it.

But, thankfully, we came to understand that history -- if that's all you know -- is quite limiting. The enlightened figured out that there is a case for ignorance -- that is: recognizing you are ignorant of something. And, then setting about with a project to fill in the blanks.

And, you might notice, guys like Newton and daVinci brought the concepts of observations and mathematics into the battle of ignorance. Indeed, for the longest time before, math was considered "philosophy". And then we have Bayes, somewhat a contemporary of Newton, with his version of continuous improvement: form a hypothesis based on assumed conditions; make observations; then adjust assumptions about conditions to conform to observations.

And so, that's the idea here:

• Know, going in, that you are likely ignorant
• Recognize the value of theorizing and observing to overcome ignorance
• Don't assume history has all the answers -- it doesn't
• Appreciate that improvement doesn't just come from reorganizing what you know(*); sometimes new facts are more powerful (See: Newton)
• Repeat 

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

(*) Pre-Newton methodology which actually carried on in some forms until the industrial revolution

---

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

Bring me a solution

---

I've always been an advocate of "bring solutions when you bring problems". In other words, no whining.

Some argue the opposite: Bringing a solution is like bringing an advocate that has something to lose if the solution is not adopted ... prestige, face, standing, etc.
Perhaps fostering or initiating an opportunity to discuss the problem before a solution gets locked in is better

Well, yes, perhaps.
And, I'm sure there are situations that need/require brainstorming and an open source approach.
But, not every solution is so elusive or difficult.

In most cases: come with a solution (or a solution candidate), but be open and insensitive (on a personal level) to an alternative.

We're all big people here! (Or, here's your opportunity to be the adult!)

---

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

Small data

---

I've written before that the PMO is the world of 1-sigma; 6-sigma need not apply. Why so? Not enough data, to wit: small data.

Small data drives most projects; after all, we're not in a production environment. Small data is why we approximate, but approximation is not all bad. You can drive a lot of results from approximation.

Sometimes small data is really small.  Sometimes, we only have one observation; only one data point. Other times, perhaps a handful at best.

How do we make decisions, form estimates, and  work effectively with small data? (Aren't we told all the magic is in Big Data?)

Consider this estimating or reasoning scenario:

First, an observation: "Well, look at that! Would you believe that? How likely is that?"
Second, reasoning backward: "How could that have happened? What would have been the circumstances; initial conditions; and influences?"
Third, a hypothesis shaped by experience: "Well, if 'this or that' (aka, hypothesis) were the situation, then I can see how the observed outcome might have occurred"
Fourth, wonderment about the hypothesis: "I wonder how likely 'this or that' is?
Fifth, hypothesis married to observation: The certainty of the next outcome is influenced by both likelihoods: how likely is the hypothesis to be true, and how likely is the hypothesis -- if it is true -- to produce the outcome?

If you've ever gone through such a thought process, then you've followed Bayes Rule, and you reason like a Bayesian!

And, that's a good thing. Bayes Rule is for the small data crowd. It's how we reason with all the uncertainty of only having a few data points. The key is this: to have sufficient prior knowledge, experience, judgment to form a likely hypothesis that could conceivably match our observations.

In Bayes-speak, this is called having an "informed prior".  With an informed prior, we can synthesize the conditional likelihoods of hypothesis and outcome. And, with each outcome, we can improve upon, or modify, the hypothesis, tuning it as it were for the specifics of our project.

But, of course, we may be in uncharted territory. What about when we have no experience to work from? We could still imagine hypotheses -- probably more than one -- but now we are working with "uninformed priors". In the face of no knowledge, the validity of the hypothesis can be no better than 50-50.  

Bottom line: Bayes Rule rules! 

---

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

Simplicity and complexity

---

Simplicity requires a lot of complexity

Jack Dorsey

Founder, Square, Inc

Can you repeat that?

Making it simple for the user/customer/beneficiary often requires a lot of 'backstage' complexity.  Ask any system engineer. 

Project managers beware!  Often, the sponsor's vision is simplicity itself.  And, the sponsor makes resource commitments on their idea of value.  But the sponsor's value allocation of resources may not comport with the resource allocation needed to make project outputs simple for the user, customer, or beneficiary.

Why should it?  PM's can't assume the sponsor has any real idea of how to make the vision a reality.  That's for the project team to discern.

Inevitably, there's going to be a gap: a gap between a value allocation on the one hand and a implementation estimate on the other hand.  What bridges the gap?  RISK!  And of course, it's left to the project manager to the be chief risk manager.

Don't expect much help from the sponsor to close the gap.  Just the opposite: expect demands that you close the gap!

I've expounded on this idea before.  I call it the 'project balance sheet': a way to represent the three variables that inform every project charter: sponsor value expectation, project implementation need, and the risk between them.

The tension of simplicity and complexity is ultimately a tension between value and resources.  Beware simplicity!

---

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

Staying educated (enculturation)

---

The robots are coming!

And, "enculturation" is my new word. I'm proud to use it. It means "to get with the program" and absorb the culture!

The robots are enculturating!  (and, that's a for-real word also)

We see that robot headline repeatedly. What's the antidote?
The usual answer: Education. Learn to do stuff the R's can't; and we see that one also

Now comes some specifics around this:

• At school, "learn to learn". See instruction about how to ask questions; to think critically; to approach new things or even unknown things; to collaborate
• Where possible, practice creativity, even if you yourself don't think of yourself as creative.
• Be curious; avoid lazy practices of not seeking solutions and answers

And, then of course, there's this advice: consistently work on your personal knowledge base; it's part of your job description. Some leaders famously don't read, but among millions there are very few non-readers who are successful.

On-line is good, youtube or the KhanAcademy.com are great, but so is your local university library. Most are chock full of professional stuff -- books, papers, periodicals, videos

In other words: a high degree of self-direction and discipline are needed to maintain and impove skills. In the spectrum of situational leadership, you yourself need to be your own S1 

And then there's this: if you're still looking for a job, the new resume may be a video to show how you actually work; solve problems, etc

---

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

Debt is not all bad

---

Debt is not all bad; it's not living beyond you means if you have the means -- and commitment and discipline -- to pay it back. In fact, debt can be a source of leverage, a means of managing risk, and a means to bring the future closer to the present.

And so it is in the metaphor of technical debt in a project. Technical debt has been around as long as there have been projects. It's just that until the past 25 years we've not really called it "technical debt". More likely you've used these terms:

• Punch lists of things not done
• Low priority stuff deferred
• Action items from a design review
• Future resources borrowed for near term action (aka: mortgage the future)
• And, others .....

And so Mike Cohn, noted Agilist, in an emailing on the subject tells us:

"Ward Cunningham introduced the idea of technical debtat the 1992 OOPSLA conference. Cunningham’s term is often used by development teams to claim that technical debt is evil and all technical debt is to be avoided.

Cunningham’s point was exactly the opposite. It was that technical debt can be OK. He wrote, “A little debt speeds development so long as it is paid back promptly with a rewrite.”

So it’s not technical debt itself that is evil. It’s letting technical debt accumulate."

And, so the point is:
Don't let "deliver the best" be the enemy of getting on with it and making progress. For those old enough to remember, Win 95, Microsoft's first real windows OS (forgetting an even earlier version that I can hardly recall) was replete with "technical debt". And, Win 98 wasn't much better.  But, a lot was learned with those early efforts -- even if Apple was learning faster and delivering better.

Indeed, the whole point is to get something out there and gain experience from user's interaction. But, at the same time, have a plan to "learn fast". The slow learner will lose all advantage of going into debt.

Of course, if the customer's domain and culture is that "failure is not an option" and "it has to work the first time", then the debt needs repayment sooner than later.

But even if those are the constraints and the height of the bar, the opportunity for leverage and learning are not forfeited by the quality standard; they are simply sequenced differently.

---

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

Failure modes

---

How do we fail? Let me count the ways

• In the beginning, say the first Egyptian pyramid project, failure wasn't even talked about. If it happened, you just disappeared, and someone took your place -- properly incentivized not to repeat your experience
• Advance a few millenniums and we arrive at "Failure is Not an Option". In this model, something -- anything -- that yields a strategically successful outcome is acceptable. It need not look anything like the intended
• Advance a few decades and we get "You're allowed to fail"  followed closely by "Fail early!". In this model risk is a recognized and accepted partner to innovation, although certain contributors are not acceptable: incompetence, laziness, and recklessness to name three.  However, arrogance and eccentric behaviours are tolerated
• Now, in present time, we arrive at "Fail early; fail hard" which morphs to "Fail Upward!" which we learn is something of an art. It's even advanced to the point of having a blog stream on Medium and, separately, a conference to learn how fail with success (if that is not an oxymoron)

So, what do we make of "fail upward"?  That's where you advance your career and your fortunes by having demonstrated an ability to "fail early; fail hard", a recognized elixir of the successful -- in the end, anyway -- strategic outcome. But, of course, it takes a second party -- someone with deep pockets -- that recognizes your talent. You can't be a loner and successfully fail -- it's a team sport.

Indeed, we learn from essayist Kate Losse, these insights:

Thanks, in part, to a playlist of TED talks on the productivity of failure, the dictum to “fail harder, fail faster” is now being peddled in fields from scientific research to elementary education.

Consider recently published books like Stuart Firestein’s “Failure: Why Science Is So Successful” and Jessica Lahey’s “The Gift of Failure,” which argues that children today occupy such risk-scrubbed environments that opportunities for failure must be manufactured.

At AltSchool, in Silicon Valley, where pre-K tuition is $27,000 a year, modeling failure is part of the curriculum"

Summary: Failure is an option!!
 

---

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

Get people moving

---

Here's a useful paradigm both for the traditionalist and the agilist from a corner of the PM space not normally the place for such: CriticalUncertainties, a typically conservative blog about critical safety and failure (or fail safe) requirements in complex systems.

But, nonetheless, we get this input from critical systems safety expert Mathew Squair:

When you don’t know what to do, don’t sit down and plan what you don’t know, get people moving, talking, collaborating and making stuff. Then out of that activity you’ll find the information will emerge that will allow you to make decisions.

As Tom Peters points out we need to understand whether our methodologies have an inherent bias for action or a bias for planning, and then whether the situation is complex (but understood and stable) where planning will pay off or uncertain (with high novelty and volatility) where talking, thinking and looking at the small grain issues to build a picture of where we are is what we ought to be doing.

---

What more on agile? Available now! The second edition .........

Bookmark this on Delicious

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

Learning wisdom

---

Can wisdom be learned? Some say yes. Consider, if you will, this bit of an essay:

If we want to produce wise people, what are the stages that produce it?

First, there is basic factual acquisition. ... Research shows that students with a concrete level of core knowledge are better at remembering advanced facts and concepts .....

Second, there is pattern formation, linking facts together in meaningful ways. This can be done by a good lecturer, through ... discussion, through unconscious processing, or by going over and over a challenging [idea] until it clicks in your head.

Third, there is mental reformation. At some point while studying a field, the student realizes she has learned a new language and way of seeing — how to think like a mathematician or a [project manager] or a physicist.

At this point information has become knowledge. .... It can be manipulated and rearranged. At this point a student has the mental content and architecture to innovate, to come up with new theses, challenge others’ theses and be challenged in turn.

---

Bookmark this on Delicious

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