You are leaving the American sector

50 years ago today

The Berlin Wall, April 13, 1961

For a number of years, I lived in Berlin, attached to an intelligence unit there. We watched over "GSoFG"--Group, Soviet Forces Germany--that maintained a large army in East Germany and the Berlin area. Locally, we called it the "outpost of freedom", 110 miles inside East Germany.

This is really what it looked like:

Photo

 Bookmark this on Delicious  

What did you know and when did you know it?

In a recent report, suggested by Glen Alleman, I read this:

We probed into if and when companies utilize Schedule Risk
Assessment (SRA) within their projects. More than one third
of companies indicated they did use SRA when submitting
proposals. This is interesting because there seems to be
no benefit—in fact there could be a major liability—to
publishing schedule risk during the proposal phase. If a
firm were to analyze its own risk and make pricing or bid
decisions based on that analysis, it would be applicable to
the Truth In Negotiations Act (TINA) and could be required
to be submitted with the bid, damaging the firms chance of
winning. As a result, many firms simply forgo this step during
the proposal phase

The picture below illustrates the statistics:

As a former PMO director that had a portfolio of about 20 - 30 defense projects going at any one time, and writing a dozen proposals a year for replenishment, I can say that what you read and see above is more the case than not. For the last forty years, the mantra of "what did you know and when did you know it" informs much process and decision making.

I used to quip: "the test is whether it will look good on the front page of the Washington Post". If not, don't write it down.

Nevertheless, the need for a SRA, as well its cost counterpart, led me to develop my ideas [in the last century, to put a time frame on it] of the project balance sheet. The idea here is a simple one in concept: there is always a tension between the business side and the project side because they come at things differently. The business, being optimistic, under values risk; the project, being conservative, over estimates cost and schedule.

In the proposal stage, the business wants to win, and at the same time the project may wonder if the business can afford to win. More than once, I remarked: "OMG, we won. What do we do now?"

The Project Balance Sheet

View more presentations from John Goodpasture

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

10 risk questions for executives

I came across a business blog that focuses more on financial services risk than project risk, but in one posting, I found some advice worth passing along to the project community.

Entitled "10 Questions to Ask Executives About Risk", and written by Norman Marks, a compliance officer, it's a good executive communication checklist.  Here's an abridged version of Marks questions:

1. How has the executive team become familiar with leading risk management practices? .... are you using a recognized risk standard or framework?
2. In broad strokes, can you describe how you identify, assess, and determine how to manage .... uncertainties?
3. How do you integrate the consideration and management of risk in the setting of strategy, achievement of goals and objectives, optimization of performance and management of major projects?
4. How have you assigned the management of risk ... [to specific managers], [and] are they informed, educated in risk management techniques, and provided the tools for the task?
5. How are risk criteria, including risk appetite and tolerance, set? How are those levels and expectations for taking risk communicated across the organization? How do you know when the levels are exceeded?
6. How do you manage the accumulation and interplay of risks when a single situation can affect multiple areas, or when the activities of one manager affect others?
7. Are you managing risk fast enough, so you can act when necessary? Is the organization agile? Are you able to change strategic directions if risk levels change?
8. If you have a risk office, what is their role relative to the responsibilities of management?
9. How do you make sure the risk management process is working as you expect?

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

KISS, again

KISS: Keep it simple, stupid!

Is there anything new to report about simplicity, or its virtues?

Perhaps.

To get the conversation started, consider "Fifteen ways to shut down a Windows laptop" 

On the serious side, I happened upon the book "Ten Laws of Simplicity" by John Maeda. You can download the book on Kindle for $12, but here's the gist:

But of course, there are many learned treatise' on this topic.  For instance, David Pogue writes about gadgets, and his 'cause celebre' is also simplicity.  In a TED talk on this , Pogue's "rules" (rules is probably an overstatement) are:

• People like to surround themselves with unnecessary power
• If you improve a piece of software often enough you eventually ruin it
• One approach to simplicity is 'let's break it down'. (but disaggregation leads to its own form of complexity, e.g. the trees rather than the forest)
• Violate consistency in favor of intelligence (don't alphabetize US on a list of 200 countries for US users)
• Easy is hard: pre-sweat the details
• Simplicity sells

Pogue actually mixes in some humor with his talent for piano and song:

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Portfolio project management

Looking for some sources on portfolio project management? Here's an aggregator site that gives a number of links to everything from 'A' to 'W' (Amazon to Wikipedia), with stops in between for numerous blogs and vendor white papers.

You might also like:

Portfolio management and agile: a look at risk and value

View more presentations from John Goodpasture

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The human thing

Crosstalk--the Journal of Defense Software Engineering--has an interesting review of "the human thing" in their May/June 2011 issue.

They chronicle a number of well known characteristics, but this article brings it together in a convenient table:

• Human Performance:

• -Varies nonlinearly with several factors
• -Follows an inverted U-curve relative to stress
• -Excessive cognitive complexity can lead to task shedding and poor performance

• Human Error:

• -Lack of inspectability into system operation can induce human error
• -Incompatibility between human processes and machine algorithms can lead to human error
• -Sustained cognitive overload can lead to fatigue and human error

• Human Adaptivity:

• -Adaptivity is a unique human capability that is neither absolute or perfect
• -Humans do adapt under certain conditions but usually not quickly
• -Human adaptation rate sets an upper bound on how fast systems can adapt
• -Tradeoff between human adaptation rate and error likelihood
• -Need to define what is acceptable error rate (context-dependent)

• Multitasking:

• -Humans do not multitask well
• -Stanford University’s research findings show that so-called high multi-taskers have difficulty filtering out irrelevant information, can’t compartmentalize to improve recall, and can’t separate contexts

• Decision Making Under Stress:

• -Under stress humans tend to simplify environment by disregarding/under weighting complicating factors
• -Reduced ability to process multiple cues or perform tradeoffs

• User Acceptance:

• -Overly complex system design can lead to rejection of the system
• -Humans do not have to really understand software/system operation to develop confidence and trust in system

• Risk Perception and Behavior:

• -Humans accept greater risks when in teams
• -Humans have a built in target level of acceptable risk

• Human-System Integration:

• -Humans are creative but rarely exactly right; however, human errors usually tend to be relatively minor
• -Software/system solutions tend to be precisely right, but when wrong they can be way off

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A quality model

I was skimming through a blog about safety and security in software systems when my attention was drawn to a reference to the ISO/IEC 9126 quality model.

The interesting thing about this model is that it's ubiquitous: there's nothing inherently software-centric about the model, though it was written with software in mind.  In fact, it's a pretty good checklist for anyone (and everyone) interested in delivering good quality to their beneficiaries.

Have a look:

Functionality - A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.

• Suitability
• Accuracy
• Interoperability
• Security
• Functionality Compliance

Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.

• Maturity
• Fault Tolerance
• Recoverability
• Reliability Compliance

Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.

• Understandability
• Learnability
• Operability
• Attractiveness
• Usability Compliance

Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.

• Time Behaviour
• Resource Utilisation
• Efficiency Compliance

Maintainability - A set of attributes that bear on the effort needed to make specified modifications.

• Analyzability
• Changeability
• Stability
• Testability
• Maintainability Compliance

Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another.

• Adaptability
• Installability
• Co-Existence
• Replaceability
• Portability Compliance

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.