Monday, December 29, 2014

Optimizing Value --- Managing Risk


Chapter 11 of my recent book "Managing Project Value" is all about how portfolio management enters the frame. For me, the theme of portfolio management is 'best value':

The most scope and the most important scope attainable with the resources available.  

I write:
From the business unit scorecard, the portfolio manager derives many decision drivers. Some decisions involve disaggregating strategy into properly sequenced steps among programs, projects, or independent activities, and other decisions affect best value in other ways
That brings us to the "big three": Sequencing, value, and risk. When am I going to get it; of what value will it be? And, what risk do I have to take to get there?

Sequencing among projects and programs:
  • Importance, now or later?
  • Commitments made, especially to customer
  • Technical feasibility and constraints (walls before the roof, etc)
  • Resource availability (WIP already programmed)
Value optimization:
  • Distribution of resources that can affect velocity, quality, and functionality
  • Distribution of scope among projects that can affect quality, workload, risk, and schedule
Risk minimization:
  • Diversify portfolio scope to isolate risks
  • Allow redundancy among projects to put down single point failures
  • Be anti-fragile in all respects. Be able to absorb shocks 




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

Privacy - Local - Later - Average


If you read "The World is Flat" then you know that for project management the world is a flat platform with nearly unlimited connectivity that allows nearly everyone to climb aboard, more or less equal in their access to function and data.

Tom Friedman wrote the book; he's well known for his pithy summaries, and now he says this, which for project managers, is a heads-up for what the flat and universally accessible platform might bring:
"Privacy is over:" Hackers can get to anything; so beware your faith in non-disclosure agreements, patents, secrets and safes, and whatever you think is proprietary
"Local is over:" That's the message of the platform; I would argue a bit on this one since it is well documented that velocity and local go together. Want to go fast? Get local!
"Later is over:" In fact, if you're on-time, you're late. If you wait, the advantage goes over to the next guy. That brings "too fast to plan" and other inverted process paradigms into the frame.
"Average is over:" Functional automation of all manner of PM tasks is creeping in; and guess what: automation is quicker, faster, more accurate, and did I say 'above average'? Like timeliness, if you're average, you're lost
The first three are more or less on everyone's radar. We know about hackers and platforms and quicker-faster.

OMG, that last one is a problem. In any big organization, half the people are below the organization's average. Don't believe it? Just ask Mr Bell Curve. And, if automation pushes the expectation for the people mean upward, you've got to bring your A-game

And, so what's the A-game? Ever increasing intellectual skills to stay ahead of the robots, and broad experience so you don't get organized out of a job when things change. And attitude: a success today is to be rewarded with a harder job tomorrow... we love 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

Thursday, December 25, 2014

Happy Holidays




Happy holidays to all!


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

Change management transition to Agile



I once asked my Agile class what they would do vis a vis change management to prepare the organization to take on Agile methods, if only a pilot to start. One student replied this way. I thought it was pretty decent list, so I present it unabridged:
In order to gain acceptance I would use the following change management techniques:
- Vision–Clearly articulate the vision and needs
- Phased Implementation–Start out slow and progressively implement Agile practices in a prioritized order
- Create a Communications Plan–Ensure all affected parties understand your vision and realize the benefits of Agile. You need to explore how Agile practices will impact the customer, the organization, various departments and the employees who will be involved.
- Educate Stakeholders–Education of stakeholders is imperative. Everyone on your communication plan needs to understand why Agile is being implemented, and the benefits and practices involved.
- Prepare for Change Resistance–I would use my communication plant to communicate my vision to the sponsor and key stakeholders/customers, accept that there may be resistance to the change. I would need to continually stress the benefits for the nuclear utility and how Agile could be beneficial to them on future projects.

Once the customer agreed to use the Agile methodology to implement the Plant Computer System as a pilot project for Agile, I would transition to the Agile Project t Methodology as follows:

- Business Value–Specify how Agile will help resolve any current problems, and how it supports the business objectives.
- Create Implementation Plan–Create and execute a communications plan to share key messages and listen to sponsors , employees and other stakeholders. Continuously communicate progress, objectives and changes. Solicit feedback to ensure support for the transition.
- Create Communication Plan–Create and execute a communications plan to share key messages and listen to sponsors, employees and other stakeholders. Continuously communicate progress, objectives and changes. Solicit feedback to ensure support for the transition.
- Create Training Plan–Create and execute a training plan. Provide the team with sufficient training and continued support. Many Agile implementations have failed after team members were sent to training and afterwards told to implement new approaches without further support or guidance.


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

Require then acquire


Ashton Carter, the soon-to-be U.S. Secretary of Defense, has an essay in Foreign Affairs -- January/February 2014 -- in which he describes measures of the last few years to insert agility into the weapons procurement process.

We're not talking software in the Agile sense -- but some of those ideas scaled up (way up!) are applicable. Carter is talking about timeliness: being able to deliver in a timeframe that which is effective for the mission. But, of course, agilists know what that entails -- see the Agile Manifesto for guidance.

Carter goes on:
The usual process of writing “requirements,” an exhaustive process to determine what the military needs based on an analysis of new technology and future threats, would not suffice in Afghanistan and Iraq. That is because the system known inside the Pentagon as “require then acquire” demands complete information: nothing can be purchased until everything is known
Ooops! All of us who've studied these things and have had real experience in a real war time acquisition know that "require and acquire" is going to get you there fast enough.

Solution: State the mission in functional system terms; provide the timeline. Then give latitude to make it work, and then delegate to the lowest possible level to increase velocity. After all, velocity and management layers are an oxymoron -- to have one requires that you ditch the other.

Or, as Robert Gates, former US Defense Secretary said:
The troops are at war; the Pentagon is not

Thus was born the ...  "Warfighter SIG, which became the Pentagon’s central body for senior officials to weigh solutions to battlefield problems, locate the necessary resources to pay for them, and make the right acquisitions."

And, guess what they discovered: In urgent situations, the Pentagon will have to settle for an imperfect solution that nonetheless fills a gap.

The lesson learned is the same lesson learned and re-learned: To get it done, the day-to-day bureaucracy -- or the matrix system in projects -- always marches too slowly to the wrong drumbeat. Thus, special organizations, SWAT Teams, Task Forces, etc are stood up to get the job done, sweeping aside the protections of due process, taking risks, and driving for payoff.

Would that it work that way and produce results without a war to drive 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

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

Monday, December 1, 2014

The Quality --- Agile thing


"... the definition of “quality” is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another."

Gerald M. Weinberg
Writing in "Crosstalk", July/August 2014:
"Agile and the Definition of Quality"

Weinberg's article in "Crosstalk" is very incisive. Of course it should be. He's been around software and writing about software for several decades, Agile being only the latest to catch his interest.

Here's a few wits about quality from Weinberg -- stuff to think about

“Zero defects is high quality”
-to a user such as a surgeon whose work would be disturbed by those defects
-to a manager who would be criticized for those defects

 “Lots of features is high quality”
-to users whose work can use those features—if they  know about them
-to marketers who believe that features sell products.

“Elegant coding is high quality”
-to developers who place a high value on the opinions of their peers
-to professors of computer science who enjoy elegance

“High performance is high quality”
-to users whose work taxes the capacity of their machines
-to salespeople who have to submit their products 
to benchmarks

“Low development cost is high quality”
-to customers who wish to buy thousands of copies of  the software
-to project managers who are on tight budgets

“Rapid development is high quality”
-to users whose work is waiting for the software
-to marketers who want to colonize a market before the competitors can get in

“User-friendliness is high quality”
-to users who spend 8 hours a day sitting in front of a screen using the software
-to users who can’t remember interface details from one use to the next



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