Saturday, November 30, 2013

Security design principles

Security of software systems is all the buzz these days with the emergence of official and unofficial surveillance and hacking. So, one might wonder, why look back 40 years to a 1974 paper on system security principles?

Answer: Some stuff is timeless, and some stuff is still valid after four decades.

We refer, of course, to the classic by Jerome H. Saltzer and Michael D. Schroeder entitled "The Protection of Information in Computer Systems", arguably the most important part of which are the famous "8 Principles of Design"

Saltzer's and Schroeder's Design Principles
Each principle referred to the "protection mechanism"

Principle of Economy of Mechanism
... should have a simple and small design.

Principle of Fail-safe Defaults
... should deny access by default, and grant access only when explicit permission exists.

Principle of Complete Mediation
... should check every access to every object.

Principle of Open Design
... should not depend on attackers being ignorant of its design to succeed. It may however be based on the attacker's ignorance of specific information such as passwords or cipher keys.

Principle of Separation of Privilege
... should grant access based on more than one piece of information.

Principle of Least Privilege
... should force every process to operate with the minimum privileges needed to perform its task.

Principle of Least Common Mechanism
... should be shared as little as possible among users.

Principle of Psychological Acceptability
... should be easy to use (at least as easy as not using it).

Check out these books I've written in the library at Square Peg Consulting

Thursday, November 28, 2013

PM Flashblog E-book... read now!

The PM Flashblog E-book has been published, and you may have seen links to it on dozens of other websites. This E-book is a compilation of many of the blogs that were flashed out simultaneously on August 24/25 (depending on your GMT)

My contribution is on page 46, but there are lots of interesting posts throughout:

Compliments to Allen Ruddock for putting this E-book together

Bookmark this on Delicious

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

Monday, November 25, 2013

The four faces of risk

When you say "risk management" to most PMs, what jumps to mind is the quite orthodox conception of risk as the duality of an uncertain future event and the probability of that event happening.

Around these two ideas -- impact and frequency -- we've discussed in this blog and elsewhere the conventional management approaches. This conception is commonly called the "frequentist" view/definition of risk, depending as it does on the frequency of occurrence of a risk event. This is the conception presented in Chapter 11 of the PMBOK.

The big criticism of the frequentist approach -- particularly in project management -- is that too often there is no quantitative back-up or calibration for the probabilities -- an sometimes not for the impact either. This means the PM is just guessing. Sponsors push back and the risk register credibility is put asunder. If you're going to guess at probabilities, skip down to Bayes!

However.. (there's always a however it seems), there are three other conceptions of risk that are not frequentist in their foundation. Here are a few thoughts on each:

Failure Mode Event Analysis (FMEA): Common in many large scale and complex system projects and used widely in NASA and the US DoD.  FMEA focuses on how things fail, and seeks to thwart such failures, thus designing risk out of the environment. Failures are selected for their impact with essentially no regard for frequency. This is because most of the important failures occur so infrequently that statistics are meaningless. Example: run-flat tires. Another example: WMD countermeasures.

Bayes/Bayes theorem/Bayesians: Bayesians define risk as the gap between a present (or more properly 'a priori') estimate of an event and an observed outcome/value of the actual event (called more properly the posterior value).

There is no hint of frequentist in Bayes; it's simply about gaps -- what we think we know and what it turns out that we should have known. The big criticism -- by frequentists -- is about the 'a priori' estimate: it's often a guess, a 50/50 estimate get things rolling.

Bayes analysis can be quite powerful... it was first conceived in the 17th century by an English mathematician/preacher named Thomas Bayes. However, in WWII it came into its own; it became the basis for much of the theory behind antisubmarine warfare.

But, it can be a flop also: our 'a priori' may be so far off base that there is never a reasonable convergence of the gap no matter how long we observe, or how many observations we take.

Insufficient controllability, aka anonymous operations: the degree to which we have command of events. Software, particularly, and all anonymous systems generally are considered a "risk" because we lack absolute control. See also: control freak managers. See also the move: 2001: A Space Odyssey. Again, no conception of frequency.

Do you have a comment? Optional, of course.
John - Instructor

Check out these books I've written in the library at Square Peg Consulting

Saturday, November 23, 2013

Work from home infographic

If you work from home, full time, or just a few days a week, you'll identify with this infographic big time.

The Work From Home Disadvantage

Bookmark this on Delicious
Please include attribution to with this graphic.

Check out these books I've written in the library at Square Peg Consulting

Wednesday, November 20, 2013

It's urgent -- but not important

Kotter* says: Provoke urgency to get change moving

In your project life, you are going to be faced from time to time with both establishing/promoting urgency and importance as possible tools you go to in affecting change.

A few words about these popular choices:
  • One thing to keep in mind is that urgency and importance are not the same thing. Many things that are urgent are simply not that important... they are urgent only because they have a temporal sequencing issue that puts them at the head of the line and a need to do now.
  • And, many important things may have weak sequencing demands, so long as -- in the end --they get done.
Kotter, of course, is using urgency as a prod to get things going. The caution is the familiar bromide:  "Nothing is urgent if everything is urgent".

* John P. Kotter, "Leading Change"

Check out these books I've written in the library at Square Peg Consulting

Monday, November 18, 2013

Leveling up..

Ever been told you're working above your pay grade? Maybe you're "Leveling up". That's the label  you get when you work or consult with others at higher level, even if they are only an intellectual or experience level beyond yours

Consider the challenges*:

John Baez tell us:
Sometimes, in your ... career, you find that your slow progress, and careful accumulation of tools and ideas, has suddenly allowed you to do a bunch of new things that you couldn’t possibly do before. ...when they’ve all become second nature, a whole new world of possibility appears.

You have “leveled up”, if you will. Something clicks, but now there are new challenges, and now, things you were barely able to think about before suddenly become critically important.

It’s usually obvious when you’re talking to somebody a level above you, because they see lots of things instantly when those things take considerable work for you to figure out.

Talking to somebody two or levels above you is a different story. They’re barely speaking the same language, and it’s almost impossible to imagine that you could ever know what they know.

Somebody three levels above is actually speaking a different language. They probably seem less impressive to you than the person two levels above, because most of what they’re thinking about is completely invisible to you.

Check out these books I've written in the library at Square Peg Consulting

Friday, November 15, 2013

Insufficient controllability

"Insufficient controllability"... it just rolls out when you say it. And, it's one definition of risk*. A related malady is: "autonomy", as in autonomous machines achieved with (gasp!) autonomous software.

Critical Uncertainies (Matthew Squair) brings us these gems in a posting about machine autonomy.
Squair tells us:
From this perspective the approach of the authors to risk can be seen as a reflection of our human fear of loss of control. The greater the autonomy of automation the greater our perception of risk. Thus a loss of control to something as intangible as a software program is always going to be perceived as a risk

It seems reasonable when you think about it. Perhaps "insufficient controllability" belongs on the long list of cognitive biases that inform risk attitude. It certainly explains "control freak" management styles!

* Brun, W., Risk perception: Main issues, approached and findings. In G. Wright and P. Ayton (Eds.), Subjective probability (pp. 395-420). Chichester: John Wiley and Sons, 1994.

Check out these books I've written in the library at Square Peg Consulting

Wednesday, November 13, 2013

Tell me what you know

I don't think this is new insight, but I'll repeat it here for the record. In his recent book "Takedown" about his years in executive leadership of U.S. intelligence analysis, Philip Mudd* writes about Colin Powell's* approach -- in three steps -- to being an 'analysis consumer', something every project manager is almost every day:
  1. Tell me what you know
  2. Tell me what you don't know
  3. Tell me what you think
If every risk management experience followed the Powell protocol, we'd all be the better for it. (Left unsaid: the Rumsfield version of the Powell protocol about the 'unknown unknowns' and the Ignorance Management Framework!)

Mudd goes on to give his insights re analysis, certainly something every Business Analyst or project office analyst should heed:
    1. Maintain objective separation between those who analyze (analyst) and those who use analysis product for decision-making (analysis consumer)
    2. Be abundantly clear in the analysis product vis a vis the Powell protocol (as above)
    3. Always understand that an intention is not always supported by a capability, and that possession of a capability is not sufficient to impute intention.
Now, a close look at Mudd's third point is really instructive if you are bidding competitively for project work:
    • Among capabilities of your competition, what are the competition's intentions (beyond trying to win, of course)?
    • Among the intentions of your prospective customer, what are the customer's capabilities to effectively use/employ/absorb your deliverables?

Not without coincidence, this leads directly to Chapter 12 of my most recent book "Maximizing Project Value" (see links below) re 'game theory': the systematic means to assess the intersection of intention and capability.

*Philip Mudd: Former counter-terrorism executive at CIA and FBI
Collin Powell: Former U.S. Secretary of State, and Chairman, Joint Chiefs of Staff

Bookmark this on Delicious

Check out these books I've written in the library at Square Peg Consulting

Sunday, November 10, 2013

Firing your client

Are you an independent practitioner? In the US, 1/3rd of the workforce are independents. An amazing proportion to my way of thinking.

One of the advantages -- and at the same time, one of the hazards -- is that you get to fire your boss; and, you even get to select your boss.

A recent article gives a few pointers for the newbie independents -- know when to hold'em; know when to fold'em. You know you've got a bad client when:
  • They try to set up the deal at 10pm at night or a weekend... unless you want to work 24x7
  • They say it's an easy job they can do themselves.. unless you want to be micromanaged
  • You don't really know them and they live in a different country/culture.. some learning required!
  • They want to talk about themselves instead of the job task... unless you want to be their counselor
  • They say they've tried to get the job done with many others, and they all failed.. so might you!
  • Rude, insensitive behavior.. unless you like the bad-ass type
  • Those that ask for a miracle, or an unlimited commitment.. unless you give up your independence

One suggestion is to beef up the contract; guard your intellectual property rights (something I really pay attention to) and get a non-refundable down-payment. That one has been a sorting parameter for me. Don't forget the non-poaching clause: your client shouldn't have the freedom to hire your staff.

What's the right wording: "We're not a good fit", or "This job is not a good fit for my skills" (I use that one a lot)

And, if they really insist you take the job, add on a premium for your anticipated trouble!

Check out these books I've written in the library at Square Peg Consulting

Friday, November 8, 2013


Fidelity, faithfulness, and commitment often seem to be the tension between:
  • What the customer/sponsor/user want, and
  • What the project charter/scope calls for.

Why so? Why isn't it straightforward? The business case begets the project charter; the charter begets the project plan; and then the project team is off to do the deliverables. Simple, right?


It's never that simple -- though on paper that's the way it should be.

What is reality is a challenge between "fidelity to user expectation" and "fidelity to user specification".

Expectation v specification. How to manage this? First, it's should always be a decision and not just a consequence of wandering off track; and second:
  • If you have the latitude to shift "loyalty" from specification to expectation, you are in what the community generally calls an "agile" environment.
  • If the decision process takes into account expectation as well as specification, then both of these should be on the list of "inputs" to the decision. And,
  • Indeed, there may be two decisions, one for each criteria, with the customer as the referee: does the customer want to honor the spec, or shift to expectation? (Does the customer have the latitude to make this decision?)
Keep this thought close by: what is really at stake is a "best value" outcome: "the most useful and important scope that's affordable."

Check out these books I've written in the library at Square Peg Consulting

Tuesday, November 5, 2013

How many words does it take?

Quantmleap had a nice posting on the word count thing, to wit:
Pythagorean Theorem – 24 words
Archimedes’ Principle 67 words
10 Commandments – 167 words
US Declaration of Independence – 1300 words
EU rules for the sale of cabbage – 26,911 words
This begs the question about complexity: the unpredictable interworking of all the parts! One must wonder if it is possible to actually buy cabbage in the EU?

Check out these books I've written in the library at Square Peg Consulting

Sunday, November 3, 2013

Soft power

We read a lot about "soft power", but not in the PMBOK. It's not a power paradigm of PMI.
Soft power is a concept developed by Joseph Nye of Harvard University to describe the ability to attract and co-opt rather than coerce, use force or give money as a means of persuasion (Wikipedia)
Attract and co-opt rather than buy your way in... what a concept! And, cheaper.

What does it take to put such an idea into practice? In a word: Leadership!

What's the word cloud for leadership? Here's one list:


Check out these books I've written in the library at Square Peg Consulting