No is easy

The remoteness of electronic communication makes "saying no" less painful than it ever was. This is probably not news to the blogging community. But couple less painful 'no' with the phenomenon of 'diffusion of responsibility', in which those who say 'no' and become blockers don't have to pay for their decision with accountability or responsibility for consequences, and you have a potentially dysfunctional mix.

I saw it myself when I worked for the US Government. Any mid-level guy could say no; to get around the mid-level took a lot of work, non-value work at that.

When I left government for private industry, I was really shocked by the different deciding paradigm: the decider decided, and the decisions actually stayed decided!

Diffusion of responsibility refers to spreading the decision making among so many individuals that really no one is consequentially on the line, except perhaps for the last guy in the line. It's the project equivalent to putting all 'deciders' in parallel so that no single decider is material. Thus, they can all say 'no' and not be accountable for the decision since 'who was last to say no?' is often not reported or known. Generally, the ordering of the naysayers is not material, so anyone can go first or last.

I've gotten to this point in the blog and I realize I have no answer for the issue. Who was responsible for the financial collapse? No one has really paid a price. Who was responsible for Enron: it's a little clearer there. Who's responsible for a lot of what we endure every day? I don't really know.

Diffusion of responsibility!

 Bookmark this on Delicious  

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

EVM standards compared

I came across a white paper the other day that compares the ANSI 748 EVM standard to its Australian counterpart, and also provides some comparisons to the PMI practice standard.  Conveniently titled "COMPARISON OF EARNED VALUE STANDARDS", and written by Paul Harris, it sums things up nicely for the non-expert in 11 pages, most of which is quite readable table of comparison.

I wasn't familiar with the Australian standard, AS4817, but I learned this:

This is a standard is a practical guide explaining:
1. The basic processes of an Earned Value Performance Measurement including the calculations.

2. The steps required to run an EVPM system and includes requirements, guidance, examples, graphs and tables.

3. Analysis and reporting techniques. It includes a number of charts and their interpretation.

This standard may be used by people who have project experience to assist in setting set up and running an EVPM system and to provide reports using the formulae and examples which assist in explaining the processes.

And, here's an interesting quote from a bookseller pushing a new PMI book on EVM, but you see it quoted elsewhere:

EVM is management with the lights on!

 Bookmark this on Delicious  

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

Never give up

...the software quit before the pilots

Matthew Squair

Matthew's quote comes from his recent blog, one of his many, on the crash of the Air France flight into the Atlantic off Brazil.

This latest analysis is about what else? Software requirements. He lays part of the blame for flying a perfectly airworthy aircraft into the sea, tail down, at 10,000 ft/min, at the feet of the stall warning software, software that quit when foreward airspeed got to 60Kts.

Did I mention tail first?

Matthew's blog is called "Dark Matter". Aptly named in my view

 Bookmark this on Delicious  

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

That wicked thing

In the project game, it's usually said: "it all comes back to requirements"

Usually.....

But, there's a thing called 'wicked', invented more or less to explain requirements--or lack thereof--in the political and policy domain. Unlike the domains most of us work in, projects that are motivated by, or subject to, political and policy influences as dominate influences often can not really formulate requirements, even requirements in the agile sense.

The wicked idea is this: the requirements are not knowable until the solution is knowable. From a project perspective, as conventionally governed, such an idea is a really perverse feedback loop.

In Excel terms, it's what the 'resolver' does: it tries a solution on the source to see if it fits. That's pretty much the wicked situation. You talk about the requirements, then you talk about the solution, and then on the basis of yet another solution that might actually be doable, you back fit the requirements.

I fell upon a paper, one of the source documents for this line of thinking ("Dilemmas in a General Theory of Planning"  by Rittel and Webber) , that outlines 10 'wicked issues'.

1. There is no definitive formulation of a wicked problem. The information needed to understand the problem depends upon one's idea for solving it.

2. Wicked problems have no stopping rule

3. Solutions to wicked problems are not true-or-false, but good-or-bad

4. There is no immediate and no ultimate test of a solution to a wicked problem. With wicked problems, on the other hand, any solution, after being implemented, will generate waves of consequences over an extended--virtually an unbounded--period of time.

5. Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly. With wicked planning problems, however, every implemented solution is consequential. It leaves "traces" that cannot be undone

6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan

7. Every wicked problem is essentially unique

8. Every wicked problem can be considered to be a symptom of another problem

9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution

10. The planner has no right to be wrong. Here the aim is not to find the truth, but to improve some characteristics of the world where people live. Planners are liable for the consequences of the actions they generate

Maybe the arguments about agile methods and requirements are not so bad after all!

 Bookmark this on Delicious  

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

Why projects matter

If there was any doubt why projects matter in an economy dominated by services and led by consumers, consider this bit of wisdom:

... ultimately, moving numbers around can do only so much. Over the long haul, you've got to invent or improve real products and services to grow.

Rana Foroohar

Build something! Make something! Deliver something! What a concept--I love it!

 Bookmark this on Delicious  

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

A reason to be

I scanned through a 'learned paper' the other day, and frankly I was not impressed with the argument. But the author made a couple of interesting points about the breadth of "reasons to be" vis a vis business projects.

Here's a digest of "reasons to be"

• as integrating mechanisms enabling cross-functional integration
• as contractual arrangements between markets and hierarchies
• as time-limited teams working towards stipulated deadlines
• as temporary organizations with distinctive characteristics vs the permanent organization
• as effective tools in organizing product development
• as the natural work form in [high tech] companies
• and as the core units of analysis for understanding the production of high cost, complex products and systems, so called “CoPS”

And you might ask: What did you not agree with? Answer: the author's premise that "projects are an island" and that managers and executives fail to connect projects to the larger business context. The author says:

Contemporary thinking on project management is thus grounded in a lonely project perspective. Both textbooks and research literature primarily discuss individual projects. The perspective is from the inside. The dominant unit of analysis is one project at a time, the time frame is, at maximum, the life cycle of one individual project, and the dominant level of analysis is the individual project and sometimes the individual PM. In this perspective, the players and actions of the environment do not appear in their own right, rather through their relationship with the project in question. The historical and organizational contexts of the project are taken for granted, or simply not included in the analysis

If the author is talking about the PMBOK Guide and other generic project management literature, he's right. There's no way the PMBOK Guide can go much beyond explaining a general approach, and most of that explanation is given to planning, the one activity that is more or less ubiquitous.

But in real situations, I say: Nonsense! That's not my experience and I doubt it's the experience of many. When you're spending other people's money [OPM], they care, and they insist that performance is in the domain and personality and value system of the business.

 Bookmark this on Delicious  

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

Four leadership roles

Blogs are all about lists and checklists, but hey! that's not all bad. Whole books have been written about the power of checklists

Here's another list: Four leadership roles for the program manager, and it comes with a swell graphic:

Chief Storyteller

Stories are a universally understood and appealing method for organizing thinking and persuading others. You can weave a lot of information into the telling AND you also arouse your listener’s emotions and energy.

Chief Learning Officer

The job of the leader is to create a constructive environment for learning. Of course, the premise is: there's something to learn. And what's to learn? About the vision, the mission, the direction, the imperative to move forward; certainly not the mechanics of project management, which most executives don't know anyway

Chief Integration Officer

Leaders fit the strategic initiative and its outcomes within the larger organizational, political, and social context. Pay attention to interfaces among these because many failures occur at the interfaces of these disparate systems.

Chief Decision Architect

The leader’s guiding principle as Chief Decision Architect is this simple guiding principle: Effective decisions lead to quality results.  Of course, there's also to consider efficient decision making--efficiency often plays into and affects effectiveness.  There's a case for deliberate and there's a case for 'get on with it!'

 Bookmark this on Delicious  

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

The decision making triangle

Project management, risk management, and other related disciplines are replete with triangles. Here's one more for the collection, taken from an article on "metacognition" by Marvin Cohen and Jared Freeman.

As you can readily see, it's all about decision making under stress [indeed, that's the paraphrase title of their paper] when information potential [in the form of choices and perhaps disorder] may be maximum but data may be incomplete, conflicting, or unreliable.

Their principal conclusion:

Proficient decision makers are recognitionally skilled: that is, they are able to recognize a large number of situations as familiar and to retrieve an appropriate response. Recent research in tactical decision making suggests that proficient decision makers are also metarecognitionally skilled. In novel situations where no familiar pattern fits, proficient decision makers supplement recognition with processes that verify its results and correct problems

Of course, my eye is drawn to the word 'familiar'. In point of fact, there is a decision bias described by Tversky and Khaneman, named by them as "availability bias". In a word, we tend to favor alternatives which are similar to things we can readily bring to mind--that is, things are that are readily available in our mind's eye.

Back to Cohen and Freeman: "More experienced decision makers adopt more sophisticated critiquing strategies. They start by focusing on what is wrong with the current model, especially incompleteness. Attempting to fill in missing arguments typically leads to discovery of other problems (i.e., unreliable arguments or conflicts among arguments)."

Of course, there's the issue of calling the question and getting to convergence--or, in sales: getting to yes!  Discovery is good, but it is also is the mark of a more experienced decision maker to stay on course and only evaluate new discoveries if they are truly in the path to a decision on the current problem. 

 Bookmark this on Delicious  

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

Quotation on feedback

Systems of information-feedback control are fundamental to all life and human endeavor, from the slow pace of biological evolution to the launching of the latest space satellite....

Everything we do as individuals, as an industry, or as a society is done in the context of an information-feedback system.

J.W. Forrester

 Bookmark this on Delicious  

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.