Wednesday, December 17, 2014

The best of the bad ...


You can read zillions of books, papers, and posts about the business case in project. In fact, there are four books illustrated below that have a chapter on the business case.

But, you won't find much on projects that don't have a viable economic business case, except for the universal advice: don't do the project!

Not so fast! That advice is economically sound but may not be operationally viable. Really, what do you do when there's no project outcome that's NPV positive, but you have to do something to improve or salvage operations (process, service, or product)?

"Do No Harm" becomes "Do the Least Harm". To wit, take the best of the bad as a reference case (or baseline), and then compare the other alternatives. You might wind up with a "Best (of the bad) Value" decision, to wit:
"Best (of the bad) Value" optimizes the solution operationally at the least worst cost"
So, if doing nothing is not an option, or, more dramatically, failure is not an option, then go get as much funding as you can to deliver the best value you can. That'll be the best (of the bad) value for the funding.


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, December 15, 2014

Cascading risks


Everyone who's done risk management failure analysis for a while on large scale systems has likely done it the "reductionist" way with failure mode analysis, decomposition or reduction into trees of interconnected components, and the like. All good stuff, to be sure, and reduction methods fit the model of subsystems with defined interfaces, or if in the software domain, then: API (application programming interfaces)

Now comes a posting from Matthew Squair with a keen observation: Rather than a hierarchy of subsystems that is the architecture of large scale systems, we are more likely to see subsystems as networks with perhaps multiple interconnecting nodes. Now, the static models used in reductionist methods may not predict the most important failures.
"You see the way of human inventiveness is to see the potential of things and race ahead to realise them, even though our actual understanding lags behind. As it was with the development of steam engines, so too with the development of increasingly interdependent and critical networks. Understanding it seems is always playing catchup with ability ...

A fundamental property of interdependent networks is that failure of nodes in one network can cause failures of dependent nodes in other networks. These failures can then recurse and cascade across the systems. "

Of course, such an idea has been in the PMI Risk Practice Manual for some time in the guise of linked and cascading cause-effects where myriad small effects add up a big problem. And in the scheduling community we've recognized for years that static models, like the PERT model, are greatly inferior to dynamic models for schedule network analysis for just the point Squair makes: performance at nodes is often the Achilles' heel of schedule networks; no static model is going to pick it up and report it properly.

Squair goes on to tell us:
"... we find that redundant systems were significantly degraded or knocked out, not by direct fragment damage but by the failure of other systems."

Ooops! Attention project managers: what this guy is telling us is that it's not enough to right down a hierarchy of requirements, and in the software domain its really not enough to write a bunch of user stories... if that's all you do, you'll miss too important elements
  • Architecture that doesn't fail is a lot more complex than just segregating data from function, or bolting one subsystem to another
  • Requirement "statements" and "gather requirements" rarely give you the dynamic requirements that are the stuff of real system performance
What to do: of course a reference model is always great, especially if its a dynamically testable model; if you don't have a reference model, then design test procedures and protocols that are dynamic, ever expanding as you "integrate" so that you've got a more accurate prediction of the largest scale possible.

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 13, 2014

Quotes... how many can there be?


Earlier this month we got Mike Cohn's "101 Inspiring Quotes about Agile", and now close aboard comes  Jurgen Appelo's "35 best management quotes. "

Mind you, I'm not complaining. There's some really good stuff in both of these compilations. It's just that that's a lot of quoting...


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, December 11, 2014

Moving too fast to schedule?


Is this true?
"Every meeting seems to be full of young engineers scrambling to amass the most compelling facts, trying to create something else they can watch customers use, then build on that. The big loser in this model may be the managers in charge of scheduling things, since it is all happening too fast"



And Hardy -- quoting a senior executive -- relates this lament: “Top management can’t say ‘You must do this.’ It’s hard to give direction.”

Loosely federated teams and feedback
So, this gets us to loosely federated teams, flatter hierarchy, and a critical need to harness feedback. That is, to harness feedback these questions need answers:
  • What do you need to know?
  • Who knows it?
  • How to get it?
  • What do you do with unsolicited feedback?
  • What if it's not what you want to hear?
Scheduling feedback?
And, to the matter of it's 'happening too fast to schedule': How do you get feedback in time, since the timely phasing of feedback is critical? After all, the difference between song and noise is often only a matter of coherent reinforcement... that is all in harmony, phased for the best possible result. Screw up the timing, and the song sounds lousy

The answer is to buffer between the time you collect the information and the time you use it, such that the buffer provides the elasticity required to insert the feedback at just the right moment. Thus, the time-length of the feedback loop needs to be long enough to accommodate the buffer, but not too long as to make the feedback too old to apply.

Tricky timing? That's why they pay you the big bucks!


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, December 8, 2014

Black elephants!!


You gotta love it! First came black swans. Now, we have black elephants!

And what, you might ask, is a black elephant?

Adam Sweidan tells us (as quoted by Tom Friedman):
A black elephant ...  is a cross between “a black swan” (an unlikely, unexpected event with enormous ramifications) and the “elephant in the room” (a problem that is visible to everyone, yet no one still wants to address it) even though we know that one day it will have vast, black-swan-like consequences.

When they hit, we’ll claim they were black swans no one could have predicted, but, in fact, they are black elephants, very visible right now.
Friedman points out the obvious: "If they all stampede at once, watch out."

So, where to look
The hang-out for most black elephants is the Risk Register! It's the perfect habitat... unlikely and unexpected events, thus ignored for the most part -- at least when it comes to actually funding mitigations -- but certainly visible to anyone who wants to look. Indeed, so visible that like the elephant in the room, they are brought up dutifully at every risk review.

And, what to do
Yelling fire in the theater will likely cause a stampede, so that's not a good choice. The other choice is to do a little private risk management -- whatever you can afford -- to get in position to push back on the risk if it becomes more of a threat. Of course, at that point, funding may appear and all the conventional approaches are then available.

But, the last resort, of course, is step out of the way, and prepare to sweep up the debris! Keep a little in reserve for the sweeper team -- you can always spend it later if you don't need it.

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 5, 2014

Management as retrospection


One agile practice that goes directly to scope control (different from creep) and business value retention is the retrospective practice which engages the power of examination after the fact, or post-iteration (sprint) evaluation.

In systems speak, you are sampling the performance and by feedback to the team for the next iteration, you are affecting the next performance by affecting the scope going forward.

In Bayesian speak, you are updating the a priori estimate based on new observations and facts, and perhaps new estimates (I'll not say guesses!)

A bit of system engineering:
This is a classic feedback loop (the iteration is the object in the loop). Outcomes influence errors sources such that future errors are corrected or acknowledged.

The power of retrospective examination, however, is diluted if feedback is not phased properly. That is, the feedback must be timely such that a corrective action in practices and the composition of the backlog can be affected in time to make a difference.
 
I've often said that the difference between noise and song is only a matter of phasing.

The lecture
Thus, is the scope is to be changed, the change must be viewed in a total context and not a context that is out of sync or out of sequence. This is what I mean by scope control as different from scope creep. Retrospective examination can help with the timing, particularly at scale when there are multiple retro's going on at nearly the same time.

Oops! Here comes the traditional guys:
Of course, there is a bit of irony here: traditional methods, once underway, are highly retrospective in their management practices. PMs are constantly looking back at actuals (cost and schedule) and earned value (scope accomplishment).

The glass half empty:
The problem with retrospective examination, if there is one, is the tendency to forecast forward based on a projection of the past into the future. That may be ok, but if any factors have changed, or will change, the past-is-the-future paradigm breaks down.


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 3, 2014

Are PMs all capitalists?


Are PMs all capitalists? Should we be? We could be: we work for money, and we spend other people's money (OPM) to drive outcomes, reaching for "success" all the time, and fearful of failure (consequence: we may not get another chance to be the leader)

But, do we have a conscience? Do we care what we are working on? If we were asked to build the first "bomb" would we do it for the science and engineering, and leave the policy and philosophy to others?

I've certainly had friends who've "opted out" of some programs. When I worked in the US DoD as a program manager, there things that gave me pause. Likely, most of us have paused at the juncture of capitalism and society at large.

McKinsey has a post on more or less this topic. Here's a thought that goes to the PM business:
Human creativity develops a variety of ways to solve ... problems, but some inevitably work better than others, and we need a process for sorting the wheat from the chaff. We also need a process for making good solutions widely available.

Capitalism is the mechanism by which these processes occur. It provides incentives for millions of problem-solving experiments to occur every day, provides competition to select the best solutions, and provides incentives and mechanisms for scaling up and making the best solutions available.

Meanwhile, it scales down or eliminates less successful ones. The great economist Joseph Schumpeter called this evolutionary process “creative destruction.”

The orthodox economic view holds that capitalism works because it is efficient. But in reality, capitalism’s great strength is its problem-solving creativity and effectiveness. [emphasis added] It is this creative effectiveness that by necessity makes it hugely inefficient and, like all evolutionary processes, inherently wasteful.

Capitalism inevitably leads to the dichotomy of "win-win" or "win-lose": Solve everyone's problems, but each less optimally; or solve one problem optimally and let the others suffer. Classic game theory! (See Chapter 12 of my latest book on Maximizing Project Value").

Clearly, as PMs we don't relish "pulling our punch" and serving up the less optimum knowingly.

McKinsey -- somewhat unhelpfully -- leaves us with this issue but no real solution:
.... the solutions capitalism produces are what creates real prosperity in people’s lives, and that the rate at which we create solutions is true economic growth, .... entrepreneurs and business leaders bear a major part of both the credit and the responsibility for creating societal prosperity.

But standard measures of business’s contribution—profits, growth rates, and shareholder value—are poor proxies. Businesses contribute to society by creating and making available products and services that improve people’s lives in tangible ways, while simultaneously providing employment that enables people to afford the products and services of other businesses. It sounds basic, and it is, but our economic theories and metrics don’t frame things this way
Here's another way to frame this that is familiar to PMs who read this blog: the focus of projects should be on outcomes first, inputs (like cost, schedule, specifications, shareholder value etc) second.

As "outcomists" we can be cognizant of the larger landscape. As "inputists" we can be responsible for being good stewards of resources. But, outcome dominates input... in my opinion.


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