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!
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!
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!
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!
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!
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!
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!
Read my contribution to the Flashblog