You’ll be hard pressed to find a better way to spend 10 minutes of your day

My faith in deliverables has grown out of decades of practical consulting experience, where defining the appropriate deliverable can mean the difference between mediocrity and success. A deliverable is an identifiable work product intended for someone outside the knowledge work process that marks the end of that particular process. Examples of deliverables include:

• A consulting report prepared by the consultant or consulting team containing recommendations to the client sponsor.
• A list of recommended job offers to prospective employees prepared by a campus recruiting team and handed to the hiring manager.
• Production Release 1.0 of a new application system installed and operating on the companies intranet.
• A project work plan and business case delivered to a steering committee for approval.

Why Deliverables Are Relevant

In the world of industrial work, process outputs are well-defined. This gives organizations a straightforward process improvement path. Holding the outputs constant allows process improvement to proceed by identifying and eliminating activities that don’t add value to the output; to break down, reorder, and redesign process steps to create more standard outputs with less input; and so on.

This path isn’t available to knowledge work practices. The goal is not to produce well-defined, standardized outputs. Deliverables are the closest analogue but their value depends on how well they match the unique needs of their users. No one is interested in a spreadsheet full of someone else’s data; no teacher is likely to value a copy of a paper you’ve submitted to another class. Understanding what aspects and features of a knowledge work deliverable are most valuable to its intended user is key to focusing efforts on producing the desired deliverable.

Natural vs. Artificial Deliverables

Some knowledge work processes produce obvious and natural deliverables. A campus recruiting effort generates a list of candidates to extend offers to. There may be a variety of associated supporting documents (e.g., interview notes, assessments), but the list is the deliverable and is a natural outgrowth of the process.

Other knowledge work processes generate more amorphous or less obvious outputs. For example, what’s the deliverable for a typical project status meeting? Shared understanding among the project team? Agreement about the state of the project between the team and the project sponsor?

Consider the typical status report as a more artificial than natural deliverable and ask how much value resides in this particular item. If you can define the deliverable more effectively, is the world a better place?

Defining Better Deliverables

The better we can define deliverables, the better and more effective we can make our knowledge work. Rather than ignore the end product, we need to be systematic in extracting as much as we can about the expected deliverable that can guide our effort to create it. There are three productive paths to explore in using the deliverable to drive your knowledge work.

• Path #1: Understand the user’s essential quality need

  Does this deliverable need to be exactly correct whatever the time or cost, as good as possible given a particular deadline/budget, or the best you can come up with on the phone? Each deliverable demands a different approach; each requires a conversation (and perhaps a negotiation) with the end user. The history of systems development is littered with examples of failing to follow this path.

• Path #2: Balance uniqueness and uniformity

  We’ve been conditioned by one hundred years of industrial experience to value uniformity. In knowledge work, the value of uniformity is to free time and attention for the essential uniqueness we’ve defined. The folks in marketing may believe that corporate identify standards are about branding. For a knowledge worker, they let you ignore formatting decisions to focus on the content that matters.

• Path #3: Specify stopping conditions

  There was an joke that was old even in my early consulting days that you knew the design phase was complete when the budget ran out. Possibly the biggest challenge for managing knowledge work is determining how to recognize that the deliverable is done. Think of the unfinished doctoral dissertations and manuscripts of the great American novel gathering dust on a shelf or lost in a lonely directory of a disk drive. Too many knowledge-work efforts fail simply because no one thinks about how to recognize what "done" will look like.

Focusing on deliverables means working backwards with the end in mind. Knowledge work is valuable to the extent that it produces end results, i.e. deliverables, that meet the unique requirements of a particular customer or end user. Time invested in understanding what that deliverable should look like will yield the greatest return in defining and focusing the activities that contribute to creating that particular deliverable at the right time and place.

Chris Brogan writes about his strategy for deepening his personal networks. He starts off his list of tips with this one:

"Devote two hours a week to this effort. If, out of the 60 hours an average person works, you can’t find two for this, reconsider how you’re running your day.

This is not the only new year’s resolution I’ve seen along this line. As we become more and more connected through social media, the more we are aware of what those connections mean.

My new year’s resolution? I’m resolving to share more of my thinking, especially about personal networks. Here’s a slide show from this past October I hope you will enjoy.

Personal Network Management Km Forum Oct 2009

Personal Network Management Km Forum Oct 2009

View more presentations from Patti Anklam.

The Year of Personal Net Work
Patti
Tue, 12 Jan 2010 20:52:00 GMT

I regularly get the "why do you blog" question.  I also regularly get "thank you for blogging" notes (thank you for the thank you notes.)

I’m a fan on Andrew Sullivan – he has a magnificent article in The Atlantic titled Why I Blog.  He nails it.

Thanks for the link Dave.

Andrew Sullivan on Blogging
moc.dlefnull@darb
Mon, 27 Oct 2008 13:56:50 GMT

I’m with Luis that storytelling skill is an essential in today’s knowledge intensive organization.

Today, Gist brings you a better way to communicate and build stronger business relationships.   After a year in limited release and with the input of over 10,000 beta users, we have created a new system to aggregate, organize, prioritize and focus your time on the most important things.   We connect to your inbox or social networks to discover your key contacts and companies, automatically prioritize them and bring together personal communications, news, blogs, and the real-time web all into one neat package.

We assert a few things are true:

• There will be more information, in more places and it’s growing at an increasing rate
• Systems will need to evolve or be created that help users harness the power of the information
• Success in business is driven by strong relationships, both in quality and quantity
• Companies who can quickly respond to customer demand are successful

Gist is a game changer and I am proud to be part of the team that has brought it from concept to a robust and useful solution.  We are privileged to work in such an exciting and evolving space, with great investors and,most importantly, incredible users who will continue to help us focus on what is most important and most valuable.  Thank you for the privilege to make a radical shift!

Gist – a better way…
T. A. McCann
Tue, 15 Sep 2009 12:18:47 GMT

Here are some pointers to other coverage and commentary about the service that are helping me get a better handle on the value of this evolving service:

• Personal Relationship Manager Gist Launches to Public
• Here’s what over 6,000 beta users told us about their business communications
• Relationship Manager Gist Opens Public Beta

What is a Farleyfile you ask? There is a Wikipedia entry for Farleyfile, but I first encountered the concept in one of Robert Heinlein’s novels, Double Star, about a hack actor forced to double for a kidnapped politician. Heinlein’s description captures the essence of the challenge and the solution that Gist promises in this 21st Century incarnation:

The tightrope act I was going to have to attempt was made possible only by Bonforte’s Farleyfile, perhaps the best one ever compiled. Farley was a political manager of the twentieth century, of Eisenhower I believe, and the method he invented for handling the personal relations of politics was as revolutionary as the German invention of staff command was to warfare. Yet I had never heard of the device until Penny showed me Bonforte’s.

It was nothing but a file about people. However, the art of politics is "nothing but" people. This file contained all,or almost all, of the thousands upon thousands of people Bonforte had met in the course of his long public life; each dossier consisted of what he knew about that person from Bonforte’s own personal contact. Anything at all, no matter how trivial–in fact, trivia were always the first entries: names and nicknames of wives, children, and pets, hobbies, tastes in food or drink, prejudices, eccentricities. Following this would be listed date and place and comments for every occasion on which Bonforte had talked to that particular man

When available, a photo was included. There might, or might not, be "below-the-line" data, i.e. information which had been researched rather than learn directly by Bonforte. It depended on the political importance of the person. In some cases the "below-the-line" part was a formal biography running to thousands of words.
…

"God’s mercy child! I tried to tell you this job could not be done. How could anyone memorize all that?"

"Why, you can’t, of course."

"You just said that this was what he remembered about his friends and acquaintances."

"Not quite. I said that this is what he wanted to remember. But since he can’t, not possibly, this is how he does it….

"These are things he would like to remember if his memory were perfect. Since it isn’t, it is no more phony to do it this way than it is to use a tickler file in order not to forget a friend’s birthday — that’s what it is: a giant tickler file, to cover anything."

[Robert A, Heinlein. Double Star. 1956. Del Ray Books. pp.151-154]

Most of us are called on to cope with an order of magnitude or two more relationships than our parents or grandparents ever contemplated. Applications and information management services like Gist are becoming absolutely essential if we hope to cope with those demands.

…this morning I talked about hierarchies of thought–the system. Now I want to talk about methods of finding one’s way through these hierarchies–logic.

Two kinds of logic are used, inductive and deductive. Inductive inferences start with observations of the machine and arrive at general conclusions. For example, if the cycle goes over a bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over another bump and the engine misfires, and then it goes over a long smooth stretch of road and there is no misfiring, then it goes over a fourth bump and the engine misfires again, you can logically conclude that the misfiring is caused by the bumps. That is induction: reasoning from particular experiences to general truths.

Deductive inferences do the reverse. They start with general knowledge and predict a specific observation. For example, if from reading the hierarchy of facts about the machine, the mechanic knows the horn of the cycle is powered exclusively from the battery, then he can logically infer that if the battery is dead, the horn will not work. That is deduction. Solution of problems too complicated for common sense to solve is achieved by long strings of mixed inductive and deductive inferences that weave back and forth between the observed machine and the mental hierarchy of the machine found in the manuals. The correct program for this interweaving is formalized as scientific method.

Actually I have never seen a cycle-type maintenance problem complex enough to really require full-scale formal scientific method. Repair problems are not that hard. When I think of formal scientific method, an image sometimes comes to mind of an enormous juggernaut. A huge bulldozer–slow, tedious, lumbering, laborious, but invincible. It takes twice as long, five times as long, maybe a dozen times as long as informal mechanic’s techniques, but you know in the end you are going to get it. There is no fault isolation problem in motorcycle maintenance that can stand up to it. When you’ve hit a really tough one, tried everything, racked your brains and nothing works, and you know that Nature this time has really decided to be difficult, you say, “Okay, Nature, that’s the end of the nice guy,” and you crank up the formal scientific method.

For this you keep a lab notebook. Everything gets written down, formally, so you know at all times where you are, where you’ve been, where you’re going and where you want to get. In scientific work and electronics technology this is necessary because otherwise the problems get so complicated you get lost in them and confused and forget what you know and what you don’t know and have to give up. In cycle maintenance, things are not that involved, but when confusion starts, it’s a good idea to hold it down by making everything formal and exact. Sometimes just the act of writing down the problem straightens out your head as to what they really are.

The logical statements written down into the notebook are broken down into six categories: (1) statement of the problem, (2) hypothesis as to the cause of the problem, (3) experiments designed to test each hypothesis, (4) predicted results of the experiments, (5) observed results of the experiments and (6) conclusions from the results of the experiments. This is no different from the formal arrangement of many college and high school lab notebooks. But the purpose here is no longer just busywork. The purpose is precise guidance of thought that will fail if they are not accurate.

The real purpose of the scientific method is to make sure Nature hasn’t misled you into thinking you know something you don’t actually know. There is not a mechanic or scientist or technician alive who hasn’t suffered from that one so much that he’s not instinctively on guard. That’s the main reason why so much scientific and mechanical information sounds so dull and so cautious. If you get careless or go romanticizing scientific information, giving it a flourish here and there, Nature will soon make a complete fool out of you. It does it often enough anyway even when you don’t give it opportunities. One must be extremely careful and rigidly logical when dealing with Nature: one logical slip and an entire scientific edifice comes tumbling down. One false deduction about the machine and you can get hung up indefinitely.

In Part One of formal scientific method , which is the statement of the problem, the main skill is in stating no more than you positively know. It is much better to enter a statement “Solve Problem: Why doesn’t cycle work?” which sounds dumb, but is correct, than it is to enter a statement “Solve Problem: what is wrong with the electric system?” when you don’t absolutely know the trouble is in the electric system. What you should state is “Solve Problem: What is wrong with the cycle?” and then state as the first entry in Part Two: “Hypothesis Number One: The trouble is in the electrical system.” You think of as many hypothesis as you can, then you design experiments to test them to see which are true and which are false.

This careful approach to the beginning questions keeps you from taking a wrong turn which might cause you weeks of extra work or can even hang you up completely. Scientific questions often have a surface appearance of dumbness for this reason. They are asked in order to prevent dumb mistakes later on.

Part Three, that part of formal scientific method called experimentation, is sometimes thought of by romantics as all of science itself because that’s the only part with much visual surface. They see lots of tubes and bizarre equipment and people running around making discoveries. They do not see the experiment as part of a larger intellectual process and so they often confuse experiments with demonstrations, which look the same. A man conducting a gee-whiz science show with fifty thousand dollars’ worth of Frankenstein equipment is not doing anything scientific if he knows beforehand what the results of his effort are going to be. A motorcycle mechanic, on the other hand, who honks the horn to see if the battery works is informally conducting a true scientific experiment. He is testing a hypothesis by putting the question to Nature. The T.V. scientist who mutters sadly “the experiment is a failure; we have failed to achieve what we had hoped for,” is suffering mainly from a bad script writer. An experiment is never a failure solely because it fails to achieve predicted results. An experiment is a failure only when it also fails adequately to test the hypothesis in question, when the data it produces don’t prove anything one way or another.

Skill at this point consists of using experiments that test only the hypothesis in question, nothing less, nothing more. If the horn honks, and the mechanic concludes the whole electrical system is working, he is in deep trouble. He has reached an illogical conclusion. The honking horn only tells him that the battery and horn are working. To design an experiment properly he has to think very rigidly in terms of what directly causes what. This you know from the hierarchy. The horn doesn’t make the cycle go. Neither does the battery, except in a very indirect way. The point at which the electrical system directly causes the engine to fire is at the spark plugs, and if you don’t test here, at the output of the electrical system, you will never really know whether the failure is electrical or not.

To test properly the mechanic removes the plug and lays it against the engine so the base around the plug is electrically grounded, kicks the starter lever and watches the spark-plug gap for a blue spark. If there isn’t any he can conclude one of two things: (A) there is an electrical failure or, (B) his experiment is sloppy. If he is experienced, he will try it a few more times, checking connections, trying every way he can think of to get that plug to fire. Then, if he can’t get it to fire, he finally concludes that A is correct, there is an electrical failure, and the experiment is over. He has proved that his hypothesis is correct.

In the final category, Conclusions, skill comes in stating no more than the experiment has proved. It hasn’t proved that when he fixes the electrical system the motorcycle will start. there may be other things wrong. But he does know that the motorcycle isn’t going to run until the electrical system is working and he sets up the next formal question: “Solve Problem: what is wrong with the electrical system?”

He then sets up hypotheses for these and tests them. By asking the right questions and choosing the right tests and drawing the right conclusions the mechanic works his way down the echelons of the motorcycle hierarchy until he has found the exact specific cause or causes of the engine failure, and then he changes them so that they no longer cause the failure.

An untrained observer will see only physical labor and often get the idea that physical labor is mainly what the mechanic does. Actually the physical labor is the smallest and easiest part of what the mechanic does. By far the greatest part of his work is careful observation and precise thinking. That is why mechanics sometimes seem taciturn and withdrawn when performing tests. They don’t like it when you talk to them because they are concentrating on mental images, hierarchies, and not really looking at you or the physical motorcycle at all. They are using the experiment as part of a program to expand their hierarchy of knowledge of the faulty motorcycle and compare it to the correct hierarchy in their mind. They are looking at underlying form.

(Chapter 9. pages 107-111 from Pirsig, R. M. (1999). Zen and the art of motorcycle maintenance. 25th Anniversary Edition. Morrow.)

Which troll-fighting techniques work

Cory Doctorow: In my latest InfoWeek column, I look at what works, and what doesn’t, when it comes to fighting trolls:

In the wake of the Kathy Sierra mess, Tim O’Reilly proposed a Blogger’s Code of Conduct as a way of preventing a recurrence of the vile, misogynist attacks that Sierra suffered. The idea was that bloggers could choose to follow the Code and post a little badge to their sites affirming their adherence to it, putting message-board posters on notice of the house rules. Although it sounds like a reasonable idea on the face of it, bloggers were incredibly skeptical of the proposal, if not actively hostile. The objections seemed to boil down to this: “We’re not uncivil, and neither are those message-board posters we regularly see on the boards. It’s the trolls that we have trouble with, and they’re pathological psychos, already ignoring our implicit code of conduct. They’re going to ignore your explicit code of conduct, too.” (There was more, of course — like the fact that a set of articulated rules only invite people to hold you to them when they violate the spirit but not the letter of the law).

O’Reilly built his empire by doing something incredibly smart: Watching what geeks did that worked and writing it down so that other people could do it too. He is a distiller of Internet wisdom, and it’s that approach that is called for here.

If you want to fight trolling, don’t make up a bunch of a priori assumptions about what will or won’t discourage trolls. Instead, seek out the troll whisperer and study their techniques.

Link

I’ve been following the controversy and conversation around Digg, HD-DVD keys, and the AACS-LA response. I’ve found the following to be among the more thoughtful and useful posts on the topic for my interests:

• Digg Users Revolt Over AACS Key
• AACS Plays Whack-a-Mole with Extracted Key
• EFF explains the law on AACS keys
• 09 f9: A Legal Primer

My views on copy protection and DRM (digital restrictions management/digital rights management) have generally been more pragmatic than ideological or policy oriented. I think the evidence suggests that copy protection and DRM schemes generally don’t accomplish what they ostensibly claim to. They don’t stop anyone who wishes to circumvent them, and they increase costs and interfere with the rights of those who do play by the rules.

In this most recent incident, we’re discovering that the latest generation of technology tools and services with explicitly social components are even farther ahead of law and policy than usual. “Cease and desist” letters begin to lose their effectiveness when the number of “offenders” starts to expand exponentially. “Deep pockets” lose their effectiveness when the conflict becomes asymmetrical.

The decision makers here are not stupid people, despite what their responses might suggest. On the other hand, they do appear to be “net deaf” or “net blind.” Their judgment is formed and informed by long experience in linear environments. Whether they can compensate for that experience in a changing world is problematic. Ed Yourdon in another post that just hit my feed reader offers some thoughts on why it may remain difficult.

The problems of hierarchy are largely invisible from the top. The power of new networks is hard to appreciate if you don’t immerse yourself in it. It’s a bit like trying to coach a sport that you’ve never played. There’s only so much you can learn by watching from the sidelines. If you want to make sound decisions, you need to invest in acquiring the requisite experience.