Tuesday, November 29, 2011

Repugnicans and Libtards (Fallacies, Part 15)

Returning now to those thrilling days of yesteryear, the fifteenth installment of my series on argumentative fallacies continues our list of red herrings — responses to arguments that distract from the argument rather than address it directly. This week we cover the abusive fallacy, the appeal to equality, and the appeal to accomplishment.

Abusive Fallacy

Repugnicans and libtards — who could possibly take seriously anything they have to say? The abusive fallacy is an extreme form of argumentum ad hominem in which name-calling overcomes every other part of the discussion. The objective is to smear the individual and group so completely that anything they have to say is discredited.

When someone surrenders to the abusive fallacy, any pretense of rational discussion goes out the window. If Occupy Wall Street protestors are “dirty, smelly hippies,” there’s no reason to address the substance of any of their arguments. Similarly, if there’s nothing to the Tea Party but astroturf racists, then nothing they say need be taken seriously either.

Appeal to Equality

What does “equal rights” mean? After all, people aren’t “equal” in most normative senses. We aren’t all of the same height, or the same age, or the same weight, or the same IQ, or the same income, or the same education. Though I subscribe fully to the moral concept of equal rights, the logical issues of equality are more complex. For example, I believe in equality of marriage rights, but I don’t accept that a fetus should be considered legally equal to a human being. I believe in freedom, but I’m willing for society to impose imprisonment or other penalties for people who commit certain offenses. Is this logically inconsistent?

No. It’s an example of a logical fallacy known as the “appeal to equality.” In other words, citing “equality” as proof that Person A should be treated the same as Person B is insufficient to make the case.

The argument that gays and lesbians should be permitted to marry, or that a fetus deserves the civil rights of a person, requires additional reasoning. This is important, because we all — properly — make distinctions. The murderer does not have the same rights as a non-murderer; a child does not have the same rights as an adult.

It’s not inconsistent or logically inappropriate to make judgments and distinctions; in fact, it’s required.

Appeal to Accomplishment

In 1970, the Nobel Prize-winning chemist Linus Pauling published Vitamin C and the Common Cold, in which he claimed that very large doses of Vitamin C had a variety of health effects. It’s probably fair to say that if I had written that book, no one would have taken it seriously.

The appeal to accomplishment is the logical fallacy that the accomplishments of the arguer serve as evidence in favor of his or her claim, whether or not the claim is necessarily related to the area of accomplishment.

While it’s reasonable to take a close look at a proposition because Expert A claims it’s true, it’s important not to confuse that with the belief that Expert A is necessarily right.

Tuesday, November 22, 2011

Wikipedia Mon Amour

The Problem With Wikipedia (xkcd), Randall Munroe

My late uncle Jack Killheffer was science editor of the Encyclopedia Britannica in the 1970s and 1980s. I remember his office in downtown Chicago as a sea of papers. Piles of documents filled most of the floor space. I’ve never been a clean desk person, but his desk was an archeological dig. He was a chain smoker; his ashtray was the size of a small dinner plate and resembled a fireplace that hadn’t been cleaned regularly.

I thought he had the world’s coolest job.

I’ve always liked encyclopedias. Before Uncle Jack joined Britannica, we had an Encyclopedia Americana. I browsed through the volumes randomly throughout my childhood. I seldom forget what I read; I can still trot out all sorts of odd information gleaned randomly from encyclopedias.

The oldest surviving encyclopedia is Pliny the Elder’s Naturalis Historia. He hadn’t quite finished proofing it when he died in the eruption of Vesuvius in 79 AD. Given the Greek root of the word (ἐγκύκλιος παιδεία, “general education”), it’s clear his was not the first, and he certainly wasn’t the last. De Nuptiis Mercurii et Philologiae ("The Wedding of Mercury and Philologia"), first of the medieval encyclopedias, came out in either the 4th or 5th centuries.

The Arabic renaissance produced the Encyclopedia of the Bretheren of Purity; the Chinese in the 11th century released the Four Great Books of Song (Book 4, The Prime Tortoise of the Record Bureau, contained 9.4 million Chinese characters in 1,000 volumes).

The invention of printing triggered an explosion, including Chambers' Cyclopaedia, or Universal Dictionary of Arts and Sciences (1728), and the Encyclopédie of Diderot and D'Alembert (1751). Of the great encyclopedias of the 18th century, the Britannica is the oldest survivor, dating to 1768.

I’m proud to note that the first encyclopedia published in the United States was Dobson’s Encyclopedia (1788-1797), published by Philadelphia printer Thomas Dobson (no relation, alas). It was, for the most part, a rip-off of the 3rd edition of the Britannica, with various adjustments made to correct a British bias. Washington, Jefferson, Burr, and Hamilton all owned copies.

Although encyclopedias have a reputation for being objective, thorough, and reliable, accusations (some solid, some less so) of unfairness and inaccuracy have been leveled at just about all of them at one time or another. That’s unsurprising. In our long discussion of cognitive biases both here and here, we learned that misinformation and misperception were fundamental parts of the human condition.

Uncle Jack told me stories about the sensitive political negotiations that took place in pure science entries. People are passionate about facts and interpretations, and both are subject to argument. When I worked for the National Air and Space Museum (NASM), there were similar issues. The Smithsonian’s official position on the relative achievements of Wilbur and Orville Wright versus Smithsonian secretary and pioneer aviation figure Samuel Pierpont Langley is shaped in part by the terms of a contract between Orville Wright and the Smithsonian that contains the following:
"Neither the Smithsonian Institution or its successors, nor any museum or other agency, bureau or facilities administered for the United States of America by the Smithsonian Institution or its successors shall publish or permit to be displayed a statement or label in connection with or in respect of any aircraft model or design of earlier date than the Wright Aeroplane of 1903, claiming in effect that such aircraft was capable of carrying a man under its own power in controlled flight."
There’s been some minor controversy over the years as to whether NASM is unfairly taking sides, but the curators I knew assured me that as far as they were concerned, the facts of the matter lined up just fine with the language of the contract. The Langley claims should have been repudiated. The Wrights were first to fly.

Working in original-source history helped me develop a sense of how much of what we know is the result of a messy and imperfect process. We muddle our way to knowledge, and there’s nothing inherently wrong with that. We don’t have too many other options. Our knowledge not only isn’t perfect, it can’t be.

For that reason, I’ve often felt that the criticisms leveled against Wikipedia for inaccuracy and bias are excessive — though that doesn’t mean they’re wrong. All encyclopedias are crowdsourced; Wikipedia differs only in that the crowd isn’t paid. Well, not in money, anyway. There are many rewards in writing for an encyclopedia, not least the imprimatur of authenticity and accuracy conveyed by the brand name.

We all know that Wikipedia doesn’t count as a final authority — if you can’t confirm what you say from a more reliable source, no one will take you seriously. But for quick reference, an overview, a list of sources, and some basic preliminary data, it’s unbeatable. I probably use it 8-10 times every single day — four times for this article alone. If my factual need is trivial and extreme accuracy not necessary, that’s enough. When I need more, I dig deeper.

That’s true not only of Wikipedia, of course, but of any other source of information. All data — and even moreso, its interpretation — is suspect. Only by consulting multiple sources and striving for self-awareness of one’s own cognitive biases is it possible to arrive at some reasonable approximation of truth.

Wikipedia culture deservedly throws suspicion on its contributors. A neutral point of view is essential, but Wikipedia frowns most heavily on people receiving money for contributing to Wikipedia articles, ignoring many other sources of bias. There’s a large community of Wikipedia editors-for-hire (I know several of them myself), but the Wikipedia culture forces them to hide their conflicts rather than share them. Wikipedia vigilantes have been known to vandalize pages when a contributor is accused of taking money, but that doesn’t correct the problem, it makes it worse.

Bias is unavoidable, but the best cure for bias is sunlight. Wikipedia is large enough and important enough that it’s legitimate for people to earn money from it. There’s nothing new here; encyclopedia contributors pre-Wikipedia expected remuneration as a matter of course. It takes significant time, effort, and work to write and edit a good article. Volunteerism, as wonderful as it is, can only take you so far.

It’s important for bias and conflict of interest to be revealed, but not to be punished. The process of peer review and vigorous debate should be aimed not at expelling the biased, but rather toward greater accuracy, completeness, and consideration of all points of view.

Wikipedia is running one of its periodic fundraising campaigns now, and in the same way I contribute to public radio, I usually contribute to Wikipedia; I use it enough. I urge you to do the same. At the same time, I tend to think Wikipedia would do well to consider running Google-style ads; when done correctly, they add value to the search rather than corrupt it.

There’s nothing wrong with making money in the encyclopedia business. The most important thing is to get the information right.

Tuesday, November 15, 2011

The Ol' Yeller Maneuver (Managing Impossible Projects, Part 6 of 6)

The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. 

If You Build It, Will They Come?

Earlier, we discussed the story of the infamous automated baggage handling system at Denver International Airport (DIA), which burned through $250 million before being abandoned as unworkable.

There’s nothing inherently impossible about the concept of an automated baggage handling system, though obviously the implementation is tougher than it appears. No, this is the kind of project in which impossibility is situational: a function of the constraints. While we’ve focused on the Triple Constraints because of their universal application in project management, individual projects have other constraints as well.

The airlines themselves, oddly, had little initial involvement in the airport planning. This gave them substantial leverage later in the process. “If you build it, they will come” often carries a hefty price tag. In order to keep its costs down, United Airlines needed the baggage transfer system to take no longer than 45 minutes to route luggage among its flights.

In 1992, the automated baggage handling system was shoehorned into existing construction in what amounted to a “Hail Mary” play. In terms of project scope, the engineering involved amounted to a great leap forward from third-generation to sixth-generation technology.

Performance, obviously, was the project driver, with budget unavoidably the weak constraint. Significant cost and schedule overruns were guaranteed, and to a large extent acceptable — as long as performance goals were achieved.

So far, we have a very challenging project, but there’s no reason for a project manager to propose killing it. It’s not operationally impossible, and the value of closing the gap justifies a very high level of effort.

The Second Frog

The BAE project team officially recognized these key risks:
  • Very large scale of the project. 
  • Enormous complexity. 
  • Newness of the technology. 
  • Large number of entities to be served by the system. 
  • The high degree of technical and project definition uncertainty. 
The most important risk, however, was not mentioned: the complex stakeholder environment. The initial project was simply to serve United. DIA management expanded the contract to cover all terminals. DIA rejected the BAE proposal to build a 50,000 square foot prototype. Scheduling issues with other construction activities caused huge conflict.

There’s the old joke about the two frogs who fell into pots of water. One pot had hot water, and the frog immediately jumped in. The other pot was warming slowly, so the other frog felt no urgency about escaping until it was too late.

BAE was the second frog.

Politically Impossible

Because the project was not impossible from an engineering perspective, the fact that it became operationally impossible because of the constraints of the stakeholder environment tended to escape notice until it’s too late.

On the other hand, political problems aren’t exactly unheard of. Project managers are supposed to perform a stakeholder analysis. This isn’t just about figuring out your customers — it’s about analyzing the political landscape.

The earlier we identify a risk or problem, the more options are available. If you accompany the sales team when bidding on a job, don’t confine yourself to a study of the technical issues. As project manager, you’re going to have to spend your days dealing with the people, and you can’t tell the players without a scorecard. If you detect political dangers, they need to be part of your risk analysis for the job. This need to affect pricing and schedule, not just for your sake as project manager, but for the sake of the entire job.

If you get into the job and find that these issues are getting out of control, you likely don’t have the power to get out of the problem by yourself. You need allies, and you need them to figure out the problem for themselves. Most project managers see reporting (no matter how necessary) as something that takes time away from doing the work. Reporting, however, is a strategic tool to lay the information groundwork with your stakeholder community to bring them toward the correct understanding of the real situation.

The Ol' Yeller Maneuver

The best way to kill a project is to help the key stakeholders and decision makers reach the conclusion on their own, rather than you telling them. Remember that “operationally impossible” means you can’t figure out an answer. Leave open the possibility that someone else might have an answer you’ve missed. Sometimes they do have an answer for you. And if they don’t, they’re more likely to agree with your assessment.

Sometimes canceling a project is peaceful, sometimes bloody. This one ended with mutual lawsuits. That’s a powerful argument for acting early when the project is likely to be operationally impossible.

So let’s wrap up. A project is operationally impossible if you can’t do it within the stated constraints. There might be too little time, insufficient or wrong resources, or unrealistic or wrong performance criteria.

Sometimes the constraints can be changed, be made more flexible, or in some cases ignored altogether. If the constraints can’t be changed, perhaps you can work around them or accomplish the project in spite of its barriers. 

If the project’s still impossible — well, earlier I mentioned the idea of an American Movie Classics film festival of great project management movies. Apollo 13 is one candidate…but another is Ol’ Yeller. Sometimes a project manager’s job is to kill his own dog.

If the dog won’t hunt, and can’t be killed, the last solution is self-preservation. While captains are supposed to go down with their ships, we project managers are better off living to fight another day. 

The Three Envelopes

There’s the old joke about the outgoing project manager who left three numbered envelopes in a drawer, and told his successor that those envelopes contained the answers to the next three crises the project would face.

Inside the first envelope was a note that read, “Blame your predecessor.” The new person often has flexibility denied to the person previously holding the bag. You may have better luck challenging project assumptions and constraints.

Inside the second envelope, the note read, “Reorganize the department,” because — let’s face it — shuffling deck chairs on the Titanic is a long, noble tradition.

And in the third envelope, the note read, “Prepare three envelopes.” If in the final analysis the project really is impossible, it’s time to get while the getting is still good.

And that’s how to manage an impossible project.

The End.

Tuesday, November 8, 2011

Getting Around the Constraints (Managing Impossible Projects, Part 5)

The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. (Art by Baker and Hill Graphic Design.)

Managing Constraints

Constraints, operationally, are what stand between you and the completion of a successful project. If you think a given project may be impossible, it’s a function of the constraints you perceive. If the constraints (defined as the borders of the perceived box) can be modified, or if parts of it are optical illusions, then you may have new options available. The game has changed.

How can we change the envelope defined by our constraints?  Logic suggests two possibilities. If the constraints are real and have flexibility, you can modify them. If the constraints are imaginary, or have elements in them that are not real, you can get around them.  Multiple strategies exist for attacking each area, but they basically boil down to two: change the constraints or get around them.

(There is no "try.")

Change the Constraints
Analysis. Why is it your preferred option best (or sometimes least worst) for the organization? Does your preferred option cause collateral damage elsewhere in the project’s environment?  How much of this is political? How do other people view this concern? You have to understand the complete picture to see all the options, and just as importantly, to see all the dangers. 
Negotiation. Some constraints are subject to negotiation. If you’re bidding on a contract, there’s a price at which you can’t afford the business. On the other hand, sometimes our organization makes the choice on our behalf. “We’ve already got the contract, this is the scope of work, and this is how much we can spend to get it done.” Probe the constraints to see which are negotiable and which are fixed by circumstances.  
Internally, negotiation is the process of making the business case. If you have force majeure to settle the argument, it’s not really negotiation. In negotiation, forcing is not an option. You can only win if you are able to help other people recognize and accept a victory of their own. 
Problem solving. Sometimes constraints are decided, other times they simply are. When an organization prepares a budget, they necessarily make decisions among desirable objectives. They could give you more (or less) money; they choose not to. But sometimes the money isn’t there. They would choose to give you more money; they can’t. You can argue with decisions; you can’t argue (though many try) with facts. That’s a problem. Some problems can be solved. In the Apollo 13 case we discussed earlier, they needed a particular resource (a filter cover), but there was nothing at hand to do the job. Then someone remembered the astronauts wore socks. 
Requirements management.  There is an unfortunate sense in which written requirements too easily turn into holy writ. The purpose of requirements is to define operationally and specifically what the customer wants and wishes to pay for.  There’s always a delicate balance between imposing the detail necessary for control and allowing the flexibility necessary for exceptional achievement. 
Watch out for requirements that have outlived their usefulness, or had even become unproductive to the mission. A small change in a requirement may be of little consequence to the project’s quality, and still spell the difference between success and failure.
Get Around the Constraints
Creativity.  Here is where positive brainstorming rejoins the flow. Systematic creativity – inspiration on time, on budget, and on spec – seems like a contradiction in terms, but professionals in many areas do it as a matter of course. The secret goes back to Thomas Edison’s famous ratio of one percent inspiration and 99% perspiration: creativity is something you can work at. Artists do rough sketches; writers do rough drafts; lightbulb inventors test filament after filament. It’s a process of discovery. As the old joke goes, Michelangelo created David by taking a big block of marble and chipping away all the pieces that didn’t look like David. 
Exploiting holes.  One of the tricks of structured creativity is understanding that some places are more likely to contain insights than others, and look there first. The flexibility of the weak constraint is one good source of insight. So is available slack or float on non-critical tasks. Weaknesses and cracks in the structure of constraints may be exploitable. 
Different approaches. Insanity, Ross Perot famously observed, is doing the same thing over and over again and keep expecting different results. Is there a way around your current obstacle if you switch approaches? 
Rethink assumptions.  Assumptions can err on the side of optimism or pessimism. Conduct a sensitivity analysis of your assumptions: if it turns out to be true or false, how much impact will it have on your project? Investigate the assumptions with the most potential.

But sometimes a project really needs to die, and the project manager is often the one dispatched to do the dirty deed. There’s a skill to this, as well.

Next Week: The Ol' Yeller Maneuver

Tuesday, November 1, 2011

Orange Ropes (Managing Impossible Projects, Part 4)

The following series is adapted from a keynote I delivered at the Washington, DC, chapter of the Project Management Institute back in August. Parts also come from my book Creative Project Management (with Ted Leemann), published by McGraw-Hill. 

Sometimes in organizations there is a form of relentless optimism, the corporate cheerleader equivalent of “failure is not an option.” I appreciate the motivational value of positive thinking, but there’s a huge brainstorming value that’s often overlooked in negative thinking. You can’t figure out which constraints may be illusions until you make a list of constraints in the first place.

When people perceive the job they have been given is impossible, or the conditions under which they must labor are unfair or insufficient, it’s usually not a good idea to push optimism down their throats — too often, it backfires and makes the situation worse. It’s no use telling people not to think of negative things, it’s like me telling you not to think about the color orange or about an elephant.

(Are you thinking about an orange elephant now?)

Orange Ropes 

Speaking of orange elephants, I don’t know how many of you have ever trained an elephant, but if you want to train an elephant you start with a baby elephant and an orange rope. The color is very important.

You tie the orange rope around the leg of the baby elephant, and fasten that to a stake in the ground. The baby elephant tries to get away, but he can’t break that orange rope.

Over the years, the baby elephant grows to full size, but he’s learned his lesson: you can’t break an orange rope. Now, you can take some flimsy, rotten rope, spray paint it orange, and the elephant will treat it as unbreakable. But if the elephant ever figures it out…he’s free.

Some constraints are fake, and others are real…but they change. Experience can be a wise teacher, or it can blind you to a new and different reality. That’s why I believe that negative brainstorming is a hugely overlooked tool for managing difficult or impossible projects.

Negative Brainstorming

A negative brainstorming process works just like a conventional brainstorming session. Participants offer potential ideas on a specific topic with no criticism or evaluation of ideas or suggestions allowed. The major difference in negative brainstorming is that the specific topic —and the focus of ideas — is negative.

In conventional brainstorming, the focus is on finding creative ways to solve the problem. In negative brainstorming, the focus is on finding all the obstacles, barriers, and events, including internal, external and self imposed, that could prevent completing the project as currently defined.

Here’s a list of good questions to get a negative brainstorming session started.

  • Why is this project impossible?
  • What are all the things we can’t possibly do?
  • What are all the things others can do that will prevent us from accomplishing this project?
  • What ideas can we think of that absolutely are not worth trying?
  • What’s the worst possible decision we could make right now?
  • What could we do to turn this project into a complete catastrophe?
  • Why are we doomed to fail?

In asking a negative question, I don’t mean to imply that the questions are necessarily accurate descriptors of reality. They don’t have to be. What the questions have to do is to correspond to the cognitive biases that keep us from finding a solution.

Doomed, But Hopeful

We may not in fact be “doomed to fail,” but a negative brainstorming exercise on “Why are we doomed to fail?” is a powerful way to bring the most serious risks and issues to the surface where our team can deal with them.

Negative questions like these can be utilized with all sorts of brainstorming processes, or techniques. Some approaches include having the participants respond in a round-robin style. Another approach is a simple free-for-all where participants offer ideas randomly. The leader can set a time limit or a target total number of ideas before concluding the process. The important thing is to concentrate on finding all the negative possibilities, rather than stop and try to solve the barriers as they are identified during the brainstorming phase of the process.

In negative brainstorming, it’s vitally important to encourage participants to offer even the most outrageous possibilities that could negatively impact the project. Our goal is to elevate concerns from the subconscious background into the conscious spotlight of project management, and we can only do that if we recognize what they are in the first place. If people feel criticized for stupid suggestions, the total number of suggestions will go down, including the not-stupid ones. That’s why, as in all brainstorming processes the initial phase is to gather ideas — not solve problems or criticize specific contributions.

After completing the negative brainstorming session, the evaluation process begins by taking each negative idea in turn and determining (1) if you can overcome the obstacle, (2) if so, how, and (3) if not, what then?

At least some (perhaps most) of the constraints, barriers, and issues you identify will turn out to be both real and solid. That’s completely normal. You are looking for the exceptions. In positive brainstorming, most ideas turn out to be of limited utility, but if you get one winner it can be a game changer.

In negative brainstorming, if most constraints turn out to be solid, but there are exceptions, the project can go from impossible to possible — occasionally even easy — in the blink of an eye.