Pages

Saturday, December 30, 2017

Trust vis Acceptance


As I've written elsewhere, there is not really -- and can not be -- trust between strangers because trust requires a transfer (or exchange) of power based on a mutually shared belief that interests are entangled.

To wit: you can trust me on this because I accept some responsibility for our mutual success

And, I'll only do that if I know you well enough to believe in your competence, your integrity, and your sense of values that align well enough with what I value. This, of course, lets out strangers

On the other hand, even if I don't have trust, I can have acceptance. I can believe, based on observation or context, that you are likely to follow the norms I follow. If that weren't the case, we probably couldn't hurdle down the highway at 80mph with on-coming traffic of strangers. We don't know the other drivers, of course, but we have acceptance of their belief in the value of the traffic norms.

With that in mind, I was struck by this statement in a novel I'm reading:
"Trust is something an intelligence officer does not give on first meeting. But, I [can] accept you"
"The Quantum Spy" David Ignatius

Given that tens of thousands of PMs work in classified environments, and given the breaches of confidence and norms in the past few years, is it any wonder that trust in our industry is devolving to merely acceptance -- with a "show me" to follow?


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, December 27, 2017

Big data -- a quotable snip


For years and years, PMs have been "little data" people. We plot data points, compute averages, look at 1-sigma, 2-sigma (and sometimes, 6-sigma) limits, ponder the Central Limit Theorem, and wonder about the law of large numbers

Fair enough

What then is "big data" if not simply more numbers, more data points?
Andrew Gelman -- eminent authority in the statistical analysis field -- has this pithy answer:
“Big Data” is more than a slogan; it is our modern world in which we learn by combining information from diverse sources of varying quality."
The biggie, of course, is the key phrase "diverse sources of varying quality". That certainly fits the project world -- we are not, after all, operations or manufacturing or distribution where processes are well defined and the data is all about process quality.

And, so what is it we do when the data quality varies?
  • Get more, to see if there is a discernible and useful pattern
  • Use Bayesian techniques to refine hypothesis based on observations and feedback
  • Throw out the obviously bad stuff, though try not to throw it out just because it's an inconvenient counter-point
Of these, Bayesian techniques are the most powerful.
Not familiar with Bayes? Search this blog site; you'll find a lot of stuff here




Read in the library at Square Peg Consulting about these books I've written

Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, December 23, 2017

Christmas math



You know, I wrote a book on quantitative methods in project management. But somehow I missed covering these equations!





Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, December 19, 2017

Fidelity, faithfulness, loyalty, and commitment



Fidelity, faithfulness, and commitment often seem to be the tension between:
  • What the customer/sponsor/user want, and
  • What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and the project team is committed. Simple, right?

Wrong!

It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? Any gap between them should always be a decision and not just a consequence of wandering off track. And, consider this:
  • If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment. 
  • Some will see a shift in loyalty as a breach of commitment, and a lack of faithfulness to the project charter.
  • Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)
Measurements and value
At the end of the day, how are you measured:  Fidelity, faithfulness, loyalty to the charter and specification, or commitment to customer satisfaction?

Keep this thought close by:
What is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, December 15, 2017

The technical debt thing



Steve McConnell has pretty nice video presentation on Managing Technical Debt that casts the whole issue in business value terms. I like that approach since we always need some credible (to the business) justification for spending Other People's Money (OPM)

McConnell, of course, has a lot of bona fides to speak on this topic, having been a past editor of IEEE Software and having written a number of fine books, like "Code Complete".

In McConnell's view, technical debt arises for three reasons:
  1. Poor practice during development, usually unwitting
  2. Intentional shortcuts (take a risk now, pay me later)
  3. Strategic deferrals, to be addressed later
In this presentation, we hear about these ideas:
  • Risk adjusted cost of debt (expected value), 
  • Opportunity cost of debt, cost of debt service -- which Steve calls debt service cost ratio (DSCR), a term taken from financial debt management -- and 
  • The present value of cost of debt. 
In other words, there's a lot of ways to present this topic to the business, and there's a lot ways to value the debt, whether from point 1, 2, or 3 from the prior list.

One point well made is that technical debt often comes with an "interest payment". In other words, if the debt is not attended to, and the object goes into production, then there is the possibility that some effort will be constantly needed to address issues that arise -- the bug that keeps on bugging, as it were.

Interest payments factored in
To figure out the business value of "pay me now, pay be later", the so-called interest payments need to be factored in.

In this regard, a point well taken is that debt service may crowd out other initiatives, soaking up resources that could be more productively directed elsewhere. Thus, opportunity cost and debt service are related.

Bottom line: carrying debt forward is not free, so even strategic deferrals come with a cost.




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, December 12, 2017

ISO 21500 Project Management



ISO has published -- December, 2012 -- the first version of the 21500 standard on project management. The official site for 21500 is here.

The purported benefits are these, as reported by ISO:
  • Encourage transfer of knowledge between projects and organizations for improved project delivery
  • Facilitate efficient tendering processes through the use of consistent project management terminology
  • Enable the flexibility of project management employees and their ability to work on international projects
  • Provide universal project management principles and processes


The good news for the PMP crowd is that there are not many differences between the the two standards since ISO used the PMBOK as the foundation for 21500. A few things are added, and a few things are rearranged, but it's largely the same content. For instance, Stakeholder Management has been added as a knowledge area. But the 42 processes in the PMBOK have been consolidated into 39 in 21500.

Companion standards
  • Quality management systems
    Guidelines for quality management in projects
  • Risk management
    Principles and guidelines


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, December 9, 2017

Avoid -- if you can -- batch transfers


Hiss! We no longer say "waterfall"; now we say "batch transfer"

Fair enough. New label; old wine. I get it.

But, still, to be avoided -- if you can
What replaces the sequential batch transfer (formerly: sequential waterfall. Hiss!)?

Collaboration! (*) And, less optimally, smaller "batches" (did someone say "lean"?)

Mike Cohn has an excellent posting on the "collaboration-replaces-batch-transfer" thing. And, he has some wise advice on smaller batches, to wit:
Small is good, until it's too small. When is that? When there are too many things to manage; when there is danger of a small item getting forgotten; when the forest is not evident because of all the saplings.(**)
-------------------
(*) Collaboration: working together to plan our joint journey down the waterfall, as it were
(**) System engineering speak for "there are so many things that I can't judge the interactions, predict chaotic responses, or understand the value-add of integration"


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, December 6, 2017

Cockburn on Thermodynamics



Many of us learned recently from Alistair Cockburn that he studied engineering in college and took a course in thermodynamics for which he received a passing grade. However, he declares: ....can't recall anything about thermodynamics. He asks: ....does that invalidate the worth of my degree?

No, his degree shows a pathway (his word) of self improvement and education. And, for the most part, a college degree is more of an indicator of ability to perform in an academic or theoretical environment than it is a measure of actual retention of the constituent knowledge base.

On the other hand....
It's most unfortunate for a software leader like Cockburn to not recall his thermo instruction, particularly the famous "2nd Law of Thermodynamics", and its most important spinoff: the concept of ENTROPY

What is entropy?
Entropy is a measure of randomness or disorder in a system. A stable system at rest has an irreducible non-zero entropy--that is: a finite amount of system capability that is present but not available to do work.

And from this stable state of equilibrium entropy can only go up as the system departs a bit from absolute stability as conditions change.

The practical effect is that some of the energy that goes into changing state is diverted into waste thereby raising entropy. In mechanical systems, this is most evidenced by waste heat. In other systems, like information systems, entropy effects are wasted memory, CPU cycles, and unused bandwidth.

The corollary: a system in some elevated state of instability can be made more stable. And, as stability increases, entropy decreases, and wasted energy (work * time) is leaned out.

Entropy for project managers
Now, in the modern practice of information theory and computer science, the concept of entropy is hugely important. The 2nd Law is alive and well!

As practical matter we really can't, or usually don't, measure entropy directly since it's not economic to discover the true minimum state of equilibrium.  What we do is measure the change in entropy:
  • Every bit of non-value add work leaned from a process is a change in process entropy
  • Every improvement in system downtime (rate of failure) is a change in system entropy
  • Every improvement in design errors (error density of design units) is a change in design entropy
And, in a computer science application, the random energy created by random key strokes and other random processes is harnessed and put to work doing useful work in operating systems.  Windows, Linux, Unix, etc all use the entropy [energy of disorder] in this way.

In a past engagement developing and bringing to operations an ERP system in a large scale enterprise, my team was constantly aware of the entropy of our work product.  We didn't know the absolute stable state we might be able to achieve, but we had enough history to know we weren't there yet.

Our basic entropy metric was the rate of discovery of new problems.  This is modeled with a Poisson distribution with a average rate of 'lambda'. (drawing) 
Who do we blame for this complication of the body of knowledge (a search of the PMBOK does not bring up entropy)?

We blame the Bell System and the telephone industry.  Claude Shannon (in 1948) coined the term 'entropy' to describe the telephone bandwidth unavailable for communication purposes; in effect, the residual disorder and randomness in the communication channel after all means to get lean have been tried.  (photo)

Recently, a posting by John Baez, et al explains Shannon and the concept of only measuring the difference in entropy rather than entropy itself.  Baez is a little challenging to read, but hey: no pain, no gain!




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, December 3, 2017

Decision triangle and metacognition



Project management, risk management, and other related disciplines are replete with triangles. Here's one more for the collection, taken from an article on "metacognition" by Marvin Cohen and Jared Freeman.

As you can readily see, it's all about decision making under stress [indeed, that's the paraphrase title of their paper] when information potential [in the form of choices and perhaps disorder] may be maximum but data may be incomplete, conflicting, or unreliable.


Their principal conclusion:
Proficient decision makers are recognitionally skilled: that is, they are able to recognize a large number of situations as familiar and to retrieve an appropriate response. Recent research in tactical decision making suggests that proficient decision makers are also metarecognitionally skilled. In novel situations where no familiar pattern fits, proficient decision makers supplement recognition with processes that verify its results and correct problems

Of course, my eye is drawn to the word 'familiar'. In point of fact, there is a decision bias described by Tversky and Khaneman, named by them as "availability bias". In a word, we tend to favor alternatives which are similar to things we can readily bring to mind--that is, things are that are readily available in our mind's eye.

Back to Cohen and Freeman:
"More experienced decision makers adopt more sophisticated critiquing strategies. They start by focusing on what is wrong with the current model, especially incompleteness. Attempting to fill in missing arguments typically leads to discovery of other problems (i.e., unreliable arguments or conflicts among arguments)."

Of course, there's the issue of calling the question and getting to convergence--or, in sales: getting to yes!  Discovery is good, but it is also is the mark of a more experienced decision maker to stay on course and only evaluate new discoveries if they are truly in the path to a decision on the current problem. 




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, November 29, 2017

When PM meets SysEngr


Project manager
  • Here's your task
  • Here's your budget
  • Here's your schedule
  • Keep your head down; focus on the task; don't get distracted
System Engineer
  • Here's your environment and context
  • Here's your interface
  • Consider the chaotic and integrating effects
  • Keep your head up; look around you; be aware of other stuff going on  
Hello! Did I hear "keep your head down" and "keep your head up"? Focus, but look around; don't get distracted, but be aware of other stuff?
 
Well yes! You did. What's your problem?
The problem, of course, is conflicting agenda, the tension -- somewhat natural -- between the project people and the systems people.
 
And what balances this tension? RISK, of course. It's the project balance sheet I describer elsewhere in this blog: two influencers in tension, and someone has to accept risk to ensure the stresses of each are managed. 
  • Budget and schedule are at risk with chaotic and integrating effects
  • Head's down focus is at risk with other stuff going on
And, who is the ultimate risk manager? The project manager ... none other. The buck stops there, always has, always does




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, November 25, 2017

Systems thinking with Charlie Munger


I was directed to this paper about "The Psychology of Human Misjudgment" by a posting on herdingcats.

The author is Charlie Munger, a man who is decidedly not a system engineer or a project manager, but nonetheless understands some of the principles of the former.(*)

He writes -- certainly as a systems thinker --  this way:
I became so avid a collector instances of bad judgment that I paid no attention to boundaries between professional territories.

After all, why should I search for some tiny, unimportant, hard-to-find new stupidity in my own field when some large, important, easy-to-find stupidity was just over the fence in the other fellow's professional territory? 

Besides, I could already see that real world problems didn't nearly lie within territorial boundaries. They jumped right across.

And I was a dubious of any approach that, when two things were inextricably intertwined and interconnected, would try and think about one thing and not the other.



________________________________

(*) Charlie Munger, best known as Warren Buffett's long time business partner, started out as an attorney with a amateur's interest in psychology, and particularly about behaviors that might inform his law practice.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, November 22, 2017

Project Office relevance


It's probably career limiting if you don't keep your project office relevant to your business

Fair enough

Tom Friedman has some advice along that line of thinking, which I paraphrase:
Analyze -- seek out and take in data; reduce it to information; understand the importance and relevance to your operation; be able to find the needle routinely, not by exception
Optimize -- avoid too-local optimization; seek lean wherever possible; always test for value-add
Customize -- provide the uniqueness of one but with the efficiency of reuse or replication; make it seem like a custom fit and finish even if it's not
Predict --  look forward, of course, extrapolating from history, but be cautious not to over use history; predicting innovation and creative destruction is filled with potholes. Where will the guy below you come up to steal your business? What are your vulnerabilities, like dragging around a legacy installed base? Sometimes, you just have to drop the headphone jack, even if you love it!
Digitize and automate -- AI is the buzz, but use automation to replace all but the higher skill cognitive-intense tasks. And, of course the latest: automate automation.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, November 18, 2017

Plans without resource control


I've been involved in a frustrating project for a while now:
  • My sponsor only understands fixed scope, price, and schedule
  • All my resources work for 3rd parties
  • The 3rd parties' interests only partially align with my sponsor's interests
  • My sponsor can make no commitments of resources since the sponsor "owns" no resources
  • My sponsor keeps asking for a project plan -- mostly, a project schedule
Let's review:
Schedules generally reflect feasibility of scope, capability to finance, and commitment of interests to the project objective 

Fair enough!

My project's scope is feasible.  Check off one
My sponsor and 3rd parties have the money (yea!) lacking only (only!) willfulness and priority (boo!)

My sponsor is committed (and involved) -- yea!;
My 3rd parties can't seem to get themselves committed, but they admit they're involved (semi-boo!)
And, the schedule is thus --- ?
There is no schedule ... only constant pushing on reluctant 3rd parties

Frustrating
Repeat



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, November 15, 2017

On the point of the capitalist spear


Is your project on the point of the capitalist spear?
Probably; or should be.

Capitalist: One who invests the proceeds of business into R&D, new capabilities, and new production to make the pie bigger. (*)

Not-capitalist. One who invests proceeds in other than the above, having no discernible effect on making the pie bigger.  See: zero-sum economic stagnation (I gain by making you lose)
Conundrum: many capitalists make non-capitalist investments; many decidedly not-capitalists start businesses and make investments toward expanding the pie.

Pre-capitalist, zero-sum

Before about the time of Adam Smith, say 17th century and earlier:
  • There was no conviction that the future could be better than the past, and 
  • Saving was a better deal than investing
  • Investing in R&D, process improvement, etc wasn't really on anybody's to-do list
  • There was no concept that economy could grow any faster than the demographics
  • The best use of "profits" was to put them in the mattress, or indulge one's self, leading to enormous wealth disparity, but also leading to a near-desert of new ideas that would expand the economy
Since then
Nearly all who will read this posting believe the future can be better; the pie can be larger meaning the sum is >0; the economy is more likely to be driven by invention and innovation than demographics.

And, thus we arrive at project management and the balance sheet of business:
  • Business assets are entrusted to PM to execute on invention, innovation, and business effectiveness
  • Assets are financed by -- that is, provided by -- lenders and those that work for the project for future payment; and by investors and owners. These are "holders of liabilities" against the business
  • Happiness is a balance: holders of liabilities are happy with the work of the asset managers
Trust
Trust in the future is the lubricant to make all these wheels turn. Trust that the future is a better thing motivates investors (to be investors, rather than savers) and allows for work for future payment rather than "pay me now" .... in other words, credit. 
  • Without a credit system there can be no projects of any scale
  • Without trust -- backed up by rules and regulation -- there can be no banks or contracts
  • Without banks, there can be no credit
  • Repeat
So, deliver!
To keep the creditors happy there have to be favorable outcomes. And, that more less closes the circle on project management: Successful delivery begets more or repeated credit which finances more projects, the objective of which is to expand the economy leading to even more availability of credit and a greater economy.

______________________
(*) See: Adam Smith, author, economist, and philosopher, and "The Wealth of Nations"


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, November 11, 2017

Tools for testing



Tools linked to process, and process linked to tools, are always grist for debate in the agile space. Defect tracking is one of those processes that begs the question: to engage with a tool or not? Many say:
  • Put the defect on a card, 
  • Put the card on a wall in the war room, and
  • Work it into the backlog as a form of requirement that is commonly labeled "technical debt".

For sure, that's one way to handle it. Of course, the cards are perishable. Many say: so what? Once fixed, there's no need to clutter things up with a bunch of resolved fixes.

Lisa Crispin and Janey Gregory, writing in their book "Agile testing: A practical guide for testers and Agile teams", have a few other ideas. From their experience, there are these reasons to use an automated tool to capture and retain trouble reports:

  • Convenience: "If you are relying only on cards, you also need conversation. But with conversation, details get lost, and sometimes a tester forgets exactly what was done—especially if the bug was found a few days prior to the programmer tackling the issue.If you are relying only on cards, you also need conversation. But with conversation, details get lost, and sometimes a tester forgets exactly what was done—especially if the bug was found a few days prior to the programmer tackling the issue."

  • Knowledge base: Probably the only reason to keep a knowledge base is for the intermittent problems that may take a long time and  a lot of context to work out. The tracker can keep notes about observations and test conditions

  • Large or distributed teams: It's all about accurate communications. A large or distributed team can not use a physical war room that's in one place

  • Customer support: If a customer reports the defect, they're going to expect to be able to get accurate status. Hard to do with a card hanging on the wall if the customer isn't physically present. 

  • Metrics: Agile depends on benchmarks to keep current and up to date team velocity.

  • Traceability: It's always nice to know if a particular test case led to a lot of defects. Obviously, many defects will not come from a specific test; they'll be found by users. But it never hurts to know.

Of course, there a few reasons to be wary of a database-driven DTS tool.  Number one on my list is probably one that makes everyone's list:

  • Communications: It's not a good idea to communicate via notes in the DTS. Communications belongs first face-to-face, and then in email or text if a record is needed. DTS is for logging, not for a substitute for getting up and talking to the counter-party.

  • Lean: All tools have a bit of overhead that does not contribute directly to output. Thus, maximum lean may mean minimum tooling.

Bottom line: Use the tool! I've always had good results using tracking tools. It just take a bit of discipline to make them almost transparent day-to-day



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, November 8, 2017

Principles and conviction and blocking


" [He] was a man with principles but no convictions; a man whose sensitive and intelligent gifts were accompanied by no positive agenda. He was ... content to let others take the lead"
Arthur Herman
Historian

With no agenda, "He was ... content to let others take the lead". I add this: only content insofar as principles are not compromised. Thus, many, but not all options are on the table.

All things changeable
The hazard here is, of course, the last one he hears is likely the one he goes with. And, the further hazard is whatever he decides, it is not "sticky". That is: decisions are subject to change, unless there is a stubbornness.

All things blocked
Then you get a principled stubbornness with no particular agenda to be stubborn about!

And that is really frustrating: Someone gets dug in, gets in a blocking position, simply because it's the first thing they decided and now they don't want to change. The classic definition of a blocker! ("It's the principle of the thing .... !)

Unblock
Now, I would never argue against having principles but I would argue for "emotional intelligence" to know when you are the child in the room. Perhaps you should listen to the adults .....



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, November 5, 2017

Living forward


I wrote a few days ago about the hazards of history as a predictor for the future.

And, then this shows up from herdingcats:
Life can only be understood backwards but you have to live it forward.

You can only do that by stepping into uncertainty and by trying, within this uncertainty, to create your own islands ....
Charles Handy
I like the theme about not living in the past, and I think I like the idea that it takes time and space to get a proper perspective on how we got here from there. The present understanding is usually only a first draft on history, etc.

But, as I wrote a few days ago, history is hazardous to the future ... it may be a stroke of good fortune never to repeat; or, bad things happen to only a few good people so most unwittingly avoid the pitfall.
 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, November 2, 2017

Project history -- valuable?


Is keeping project history valuable? Doesn't every project office have at least cost history? Isn't all parametric pricing based on history?

Yes, to all of the above! Would there be statistics without history? No!

Ooops, perhaps everyone does not agree:
"History can not be explained deterministically and it can not be predicted because it is chaotic.

So many forces are at work and their interactions are so complex that extremely small variations in the strength of forces and the way they interact predict huge differences in outcomes....

Not only that, but history is what is called a level two chaotic system. ...  Level two chaos is chaos that reacts to predictions about it, and therefore can never be predicted accurately"
Yuval Harari

And, so the take away on this is what? That history is useless for predicting an outcome based on that history? Or, that one historical outcome could easily have been another, quite different, except for some favorable interactions -- thus, who knows what might happen the next time around?

Or, even more intriguing is the last point: a prediction actually changes the predicted outcome. Somewhat like the oft encountered conundrum that a measurement or observation changes that which is measured or observed.

And, of course, there is the timeless nemesis: causation vs correlation vs coincidence.
  • Causation: A causes C
  • Correlation: A causes some reaction in B which causes some reaction in C (correlation has a third party in most cases, though B may be hidden and hard to discern)
  • Coincidence: Stuff happens
Ultimate take away: history is problematic, even if it is very instructive. Predictor be aware!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, October 29, 2017

Of facts and theories


"I have no data yet. It is a capital mistake to theorize before one has data. Insensibly, one begins to twist facts to suit theories, instead of theories to suit facts"
Sherlock Holmes
Yes, Mr Holmes has hit upon the dilemma of various reasoning strategies:
  • Inductive reasoning: from a specific observation to a generalization of causation
  • Deductive reasoning: from a generalized theory to a predicted set of specifics
As he correctly posits, inductive reasoning is hazardous. Just a slight error in facts, or in fashioning causation, or most frequently confusing causation with correlation, may lead to quite incorrect theories.

Thus, the strength of Bayes reasoning (*), a form of deductive reasoning. Aren't we all Bayesians?

-------------------
Look up Bayes Theory on Wikipedia; it's means of deducing conditions which are predictive of facts, a form of statistical reasoning.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, October 26, 2017

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, October 23, 2017

Knowledge and utility


"The real test of knowledge is not whether it is true, but whether it empowers us. Scientists usually assume no theory is 100 per cent correct. Consequently, truth is a poor test for knowledge. The real test is utility. A theory that enables us to do things constitutes knowledge."
Youval Harari
And, so what's the argument here?
It seems to be: Knowledge which has no practical utility is like the sound of one hand clapping. If you can't apply it, if you can't do something with it, if it doesn't improve your project or business, then such knowledge is "worthless" in the "utility space".

And that, more or less, brings us to the insight that "value" is dynamic and not constant everywhere.(*) Dynamic value means dynamic mapping of objective value into utility value. To wit: objective value, like truthful knowledge, may be value-less in some circumstances. Or, put another way, there is a non-linear, and perhaps even unpredictable, relationship between valuations

Example (used often, so I claim no authorship): If you need five dollars cash and you don't have it, then five dollars has real objective value. But if you have five dollars and don't need it because you actually have 100 dollars handy, then the utility -- meaningful value -- of five dollars is less than it's objective value because your circumstances probably don't change whether or not you have $100 or $95 handy.

In other words, value is dynamic depending on need, application, timeliness. Knowledge shares these same properties: if it comes too late, it may be true, but it has no utility. If it's irrelevant to the project objectives, again it may be true, but it has no utility.

The real test of knowledge is not whether it is true, but whether it empowers us.  How true!
__________________________
(*) OMG! Project cost is objective and constant everywhere, but project value is dynamic and not constant. What does that do to the business case, the ROI, and all the rest of project finance that depends on comparing a constant-value input with a constant-value outcome? Grist for another posting!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, October 17, 2017

A world without a 0?


Can you imagine project management without the help and usefulness of the number 0?
Indeed, could we do modern project management without 0?

On the other hand, the Romans, and the Greeks and Egyptians before them, did pretty well in project management, and they had no 0; they didn't even have the concept of a number 0.

Recall your Roman numerals: 10 = X; 20 = XX; 50 = L, and so forth. No need for a zero in any of that!

Good grief! the pyramids, the Greek Parthenon, the highways and aqua ducts of ancient times, all managed without a 0! Boggles the mind to think of it.

On the other hand, engineering and project problems could be solved in the ancient world.
They had Euclidean methods that were quite effective.(*)

And before there was 0?
And so what preceded the zero? Apparently some civilizations understood "void" or "null", but the Greeks thought the concept challenging to the teachings of Aristotle, and so they passed on developing 0.  These are "place holder zeros" and they predate the numerical zero by several millennia

At last, a 0
Yea! for India. Apparently, India is in the lead to be credited with the invention of 0.
A National Geographic essay on this very subject sheds some light:
Researchers at the University of Oxford's Bodleian Library recently conducted carbon dating on an ancient Indian text known as the Bakshali manuscript.

They found that some pages in the manuscript date to the third or fourth century, five hundred years older than previously thought. That pushes back the origin of what would eventually become the zero symbol, 0, we use today.

The manuscript shows a series of Sanskrit numerals. In it, zero is represented by a small dot.

Some doubt
Ooops! There are some doubters about the Indian origin of 0. ZerOrigIndia, or Project Zero, in the Netherlands, partners with researchers in Mumbai to pinpoint the origin of zero.

Nonetheless, I think we can all agree with this statement:

" .... zero was crucial to the zero-to-nine decimal system upon which algebra developed in 9th century Persia and was essential for physics principles documented by scientist Blaise Pascal in the 17th century."

_____________________________
(*) The Greek mathematician Euclid put down his theories (**) of a system of proofs which came to be known as geometry. His books of "Elements", circa 300 BCE, actually went as far as showing how to solve equations (early algebra) and define irrational numbers, all with geometry. So, no need for 0, though there was a centuries-long fuss over "what is a 'point', and how is it measured?"

(**) There were many earlier mathematicians that contributed to a body of knowledge that gave Euclid a foundation to work from



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, October 14, 2017

Large scale strangers


Anything on a large scale requires strangers to work together effectively. No strangers? Probably not really a large scale.

And so how does this work? I've always said: strangers don't trust each other. Why? There's no common basis for trust -- "I believe in you; you believe in me." is missing

Nonetheless, here we are with complex projects -- some on a global scale -- with all manner of strangers cooperating effectively. We don't necessarily trust each other so what is the trust mechanism?
  • Trust in money for one thing. We can exchange products and services with complex and large scale projects because we trust the value of those efforts when "monetized".(*) Which, if you've never really thought about it, is trust in the full faith and credit of governments to protect the value of money -- monetary policy is you will. Right now, that's pretty much the dollar, pound sterling, euro, yen, and the yuan -- the world's reserve currencies
  • Trust in the portability, perpetual storage, convertibility in and out of transactions, and no requirement to be physical give money its prominence in society(**). No matter how long you keep it, or where, it never wears out or spoils.
  • Trust in the rule of law insofar as it applies to terms and conditions for employment, contracting, purchasing, accounting, etc. In other words, trust in the value of anti-corruption
  • Trust in the general acceptance of a global morality -- stealing and assault are illegal everywhere
  • Trust in certain standards, like time for one thing, Newtonian physics if you're working in the not-quantum world, and Euclidean geometry if Einstein's relativity is not bothersome to  you. One second is one second everywhere (atomic clock arguments set aside -- we're not talking space station stuff here)
Now, here's another one, perhaps off the center stripe, so I offer it separately:
  • The power of bureaucracy (yuk!). No, it's true. Bureaucracy is what makes it possible to organize large number of strangers effectively; pass instructions around; receive and integrate product into a product baseline. We would never have advanced from the 18th century cottage industries without effective bureaucracies to put thousands of strangers together
  • The ability to translate or transliterate languages, both written and spoken. Though there are curiosities: Chinese has never spread beyond China even after being around for thousands of years; English is a global language after only a few centuries
  • And, of course, the separator between humans and animals is imagination; language facilities imagination among strangers.
_________________________________
(*) What about barter you ask -- or what about favors? Small ball stuff. Barter and favors don't scale.
(**) Only about 10% of the money in the world is physical  
Some of the ideas in this posting are derived from "Sapiens" by Harari, and "Empires of the Word" by Ostler


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog