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

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...

---

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

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"

Quentin Hardy on "What Cloud Computing Means to Your Job"

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!

---

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

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.

---

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

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.

---

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

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.

---

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 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

---

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

Agile stats from Scott Ambler

---

We're always looking for some agile statistics to see how things are going. Here's some decent stuff from Scott Ambler, an agile thinker, author, practitioner of some renown.

I heard Ambler give this live at a PMI presentation in Orlando recently. He's pretty animated when he talks live, so some of the energy of presentation may be missing from just the slides.

I was struck by a couple of things he said (to 100 PMPs assembled at dinner):

• In 10 years most of what we think of as project management will be gone... some management will be around, but not like we know it. This didn't do much to motivate the room of PMPs to move to agile.
• Agile in the main is a risk management strategy (I've been saying that for years, so nice to get some validation)
• All serious agile is a hybrid that marries up traditional swim lanes (see page 23) ... ditto my thoughts on agile in the waterfall
• Beware: pilot projects often don't lead to successful general purpose agile teams because there's too much optimization in pilots ... probably true
• It could take years to transition a large scale enterprise to agile... OMG, that sounds awful... but probably true, unless you just sweep out all the people and start over... it happens.

Enterprise Agile: Are You Ready? from ScottWAmbler

---

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

Growth, maturity, and decline

---

A common sequence studied by change managers -- particularly business change managers -- is the so-called growth-maturity-decline triad.

PMs experience the effects of this sequence more in the business case than in the actual project. After all, it takes a good deal of time to go through the business cycle; and it's not inevitable that the entire sequence ever comes about since managers intervene to redirect the business.

And, the public sector is not immune: Agencies can go out of business, declining as constituent demands declines or gives up; and agencies can re-invent themselves for new constituent demands (it's not your grandfather's motor vehicle department, or bus line, etc).

And, of course, there can be new agencies born of necessity of a changing public demand -- who remembers that in the U.S. conservative Republicans invented the Environmental Protection Agency in the Nixon administration, or the liberal Democrats invented the CIA, in the Truman administration? Now, How the world turns, etc and so on....

So, how does growth-maturity-decline look when viewed through the lens of projects?

Business case: Low cost of ownership
The real test between maturity and decline is whether or not there is new investment going into the business. In the decline stage, the emphasis is on cost control, efficiency, and getting the most out of existing product with existing customers; there's little or no investment beyond required maintenance.

Over time, product will obsolesce and customers will move on.

Business case: New customers for existing product base
If there's investment going into finding new customers with existing product, that's probably a mature organization surviving. 

Business case: New product, but directed to new customers
Growth investment is going into both customers and product, keeping both fresh and competitive.

And, here's a challenge question: when is an expenditure a cost and when is it an investment? Sponsor attitudes are usually quite different depending on the view point.

My answer: It's an investment when it goes toward making the future different from the present; that is: it's aimed at strategic differentiation -- to wit start-up and growth. Else, it's a cost required to keep things moving along as in the present for maturity and decline.

People and things
And, you can extend the argument to people: the CFO carries people on the liability side of the balance sheet -- creditors (they provide time & talent) to whom we owe benefits, salary, etc.

But, what if you're out to hire the one best person to do a task and make a strategic difference toward growth? Investment (asset) or cost (liability).  If an investment, hopefully you've got their scorecard set up to reflect the ROI demand.

---

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

International culture -- more stuff to know

---

I've given many presentations in Europe and Asia -- successful I always thought -- but I probably missed the lessons learned as I read Erin Meyer's blog posting about tailoring your presentation to fit the culture of the audience. Myer tells us he ran into some issues in a briefing to a French audience:

"The stonewall [to my briefing to a French audience that] .... was “principles-first reasoning” (sometimes referred to as deductive reasoning), which derives conclusions or facts from general principles or concepts. People from principles-first cultures, such as France, Spain, Germany, and Russia (to name just a few) most often seek to understand the “why” behind proposals or requests before they move to action.

But as an American, I had been immersed throughout my life in “applications-first reasoning” (sometimes referred to as inductive reasoning), in which general conclusions are reached based on a pattern of factual observations from the real world.

Application-first cultures tend to focus less on the “why” and more on the “how.” .

And, so, Meyer sums it up with this advice:

When working with applications-first people:

Presentations: Make your arguments effectively by getting right to the point. Stick to concrete examples, tools and next steps. ... You’ll need less time for conceptual debate.

Persuading others: Provide practical examples of how it worked elsewhere.

Providing Instructions: Focus on the how more than the why.

When working with principles-first people:

Presentations: Make your argument effectively by explaining and validating the concept underlying your reasoning before coming to conclusions and examples. Leave ... time for challenge and debate of the underlying concepts.....

Persuading others: Provide background principles and welcome debate.

Providing Instructions: Explain why, not just how.

---

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

Figure of Merit

---

"Figure of Merit".... everybody got this, or should I say more?

Some say FoM, of course.

Definition
A figure-of-merit is a metric used to compare like objects or concepts where the metric itself may have no dimension or units of measure (UoM); or the FoM dimension is meaningless for day to day operations. You can also think of a FoM as a weight applied to separate the value or utility of one thing from its peers.

A FoM may have no dimension because it is a ratio of two similarly dimensioned metrics, so the dimensions cancel in the ratio; it may have dimensions that are meaningless  for anything other than that's how the metric got formed -- like days-squared.

Sometimes, when you have no other way to compare something, a FoM, even if you make it up  gives you a way to separate things and make decisions.

Examples
Day to day in the PM domain, we run into a lot of stuff that needs to be compared -- one strategy over another, or one competitor over another, etc -- and there's no one metric that quite does it.

Enter: FoM

You might look at a number of factors and baseline competitor A as a "10" -- a dimensionless FoM. All others are compared to the baseline. If competitor "B" is evaluated as a 20, or some such, and bigger is better, then B is twice as "good" or valuable as A on the basis of a figure of merit.

You might look at the utility of one thing over another. Utility is perceived value; it may not be objective -- quality, like art, is in the eye of the beholder, etc. -- and it may not be functional: what's the perceived value of silver over black? (My wife won't buy a black car .... so, a black car on the sales lot has no value to her )

To look at the utility of something, you give it a score -- a FoM -- probably dimensionless. And, then everything else is compared to it. (Silver gets a 10; black gets a 0)

And then there's the quantitative stuff, like risk variance. Risk is often judged by how far an outcome might be from the accepted norm or average value. But, this implies a direction ... how far in what direction? Maybe it doesn't matter. Perhaps you've got a situation where the direction is immaterial and it's all about distance.

In that case, as in + or - from the average value, the way to get around direction is to square the distance -- now, everything is positive but, alas, the dimension is now squared, as in days-squared.

That's ok, just think of the variance is a FoM: smaller is better! Who actually cares what a days-squared is? Nobody, actually.

---

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