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 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Happy Holidays

---

Happy holidays to all!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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!

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog