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