How better thinking about deliverables leads to better knowledge work results

Deliverables should be a knowledge worker’s best friend but, like all good friendships, the relationship can get complicated. One of the most direct ways to improve the quality of knowledge work is to spend more time and effort to define appropriate deliverables.

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.

Are you reading McGee’s Musings via Bloglines?

My good friend Jack Vinson has put together the following useful information for blog readers who are using Bloglines and now in need of a new solution. Like Jack, it appears that about a quarter of my current subscribers use Bloglines to follow McGee’s Musings. If that applies to you, Jack’s advice is applicable to your needs.

Bloglines no moreBloglines is shutting down at the end of September.  If you are using Bloglines to read Knowledge Jolt, please find a new RSS reader.  Here are some possibilities for your switch from Bloglines.   

For what it’s worth, about 1/4 of the people reading my blog come from Bloglines, according to Feedburner.  When I look at website referrer information, I see a very small number of people coming to my website from Bloglines.

First off, you need to get your subscriptions.  Some services know how to read from Bloglines, but in case they don’t you need to find the "Export Subscriptions" option under the Feeds tab.  Your browser should offer to save the file to your computer.  You can then import these subscriptions into any other reader.  (Bloglines are showing you how to do that on the home page.)

Then you need to pick a new reader.  As far as reading options, the biggest player in the room is Google Reader (50% of my readers – and similar statistics for many others).  The Google Reader team have even written a welcome post for people who might be making the switch.  A welcome and a look back:

We know that nothing will be quite like Bloglines in the hearts of its users, but if you’re looking for another online feed reader, we encourage you to give Reader a shot. All you need is a Google account (you already have one if you use Gmail) — and here’s a video to help you get started. It’s also very easy to bring your Bloglines subscriptions over, you just have to export them from Bloglines and import them into Reader.

There are a number of other web-based options.  And, like Google Reader, there are some that provide access via multiple devices, such as Netvibes and NewsGator.  I’ve noticed that there are some of the newer "social dashboard" applications that incorporate feed reading, such as Seesmic.  And there are a number of standalone applications (RSS readers or news aggregators), such as my recent looks at RSS Bandit.  It’s also possible to pull a web feed into Outlook or Firefox or Internet Explorer directly.

[Image is my mashup on the Bloglines logo.]

Are you reading Knowledge Jolt via Bloglines?
Jack Vinson
Fri, 17 Sep 2010 23:03:27 GMT

Finding knowledge work practices worth emulating and adapting

[Cross posted at FASTForward Blog]

How might we best go about improving knowledge work, both practices and outputs, in today’s complex organizational environment? Are there paths other than simple trial and error that might lead to systematic gains?

Frederick Taylor and his followers built their careers on finding the one best way to carry out a particular physical task. Later proponents of this way of thinking transferred their approach to defining the one best way to carry out information processing tasks. John Reed of Citibank launched his career by applying factory management principles to automating check handling. Reengineering essentially rebooted these approaches for a richer technology environment, but held to the premise that outputs were a given, tasks could be well-defined, and processes could be optimized.

Peter Drucker, in his typical way, pointed out that the key to understanding and improving knowledge work (PDF) was that there was no defined task to be optimized. Knowledge workers start by defining the task at hand and an output of suitable quality. This is not an approach which lends itself to conventional improvement or optimization approaches.

Two useful approaches come to mind. One would be to identify and shadow individual knowledge workers deemed to be particularly effective. Observing, understanding, and emulating their personal practices would be time well spent. A second approach would be to identify a class of knowledge workers who have been dealing with the problems of knowledge work in the modern enterprise long enough to have developed practices and approaches that might be broadly adaptable to knowledge work activities in general.

Both of these approaches are well worth undertaking. Today, I’d like to take a look at this second approach. A recent blog post by Eric Raymond prompts looking at a group I’ve often thought of as the leading edge of modern knowledge work– software developers. Over the last half-century, this group has been inventing and developing the technological infrastructure that shapes our modern enterprises. As such, they have been the first to encounter and address the challenges of knowledge work. Certainly any group responsible for the Internet and the invention of open-source software will have lessons for the rest of us as we try to bring forth our own examples of knowledge work products.

Raymond, among many other things, is the author of the excellent The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. He also maintains the always interesting and provocative blog Armed and Dangerous. In a recent post, “the social utility of hacker humor”, Raymond dives into the number of the behavioral norms that he believes characterize hackers and software developers. The entire blog post is well worth your time, but let me call your attention to the following excerpt:

…every once in a while something erupts out of them that is a game changer on a civilization-wide level. Two of the big ones were the Internet and open-source software. These two movements were intimately intertwined with hacker culture, both produced by it and productive of it. The origins of our tribe go back a bit further than either technology, but we have since re-invented ourselves as the people who make that stuff work.

And I don t mean make it work in a narrow technical sense, either. As long as there are people who laugh at INTERCAL and RFC1149 and the Unix koans of Master Foo, and recognize themselves in the Jargon File, those same people will care passionately that computing technology is an instrument of liberation rather than control. They won t be able to help themselves, because they will have absorbed inextricably with the jokes some values that are no joke at all. High standards of craftsmanship; a subversive sense of humor; a belief in the power of creative choice and voluntary cooperation; a spirit of individualism and playfulness; and not least, a skepticism about the pretensions of credentialism, bureaucracy and authority that is both healthy and bone-deep.

[Raymond, Eric S. Armed and Dangerous. “The social utility of hacker humor“]

Substitute “knowledge worker” for “hacker” and I believe we will find parallels worth exploring.

This is still in the working hypothesis stage. I can think of a number of practices that might prove worth emulating and some useful entry points into learning more.

Practices worth investigating

Serious software developers have adopted a number of practices as they’ve struggled with the challenge of designing, developing, and evolving products that are pure thought stuff. To the extent that knowledge work is also a process of developing outputs that are themselves largely thought stuff, these practices ought to have analogues. Here’s a preliminary list, in no particular order.

  • Version control/source code control. Final outputs and products grow through a process of successive refinement.

Bruce Schneier’s insights on tomorrow’s privacy environment

Bruce Schneier is one of those disciplined, articulate, thinkers you should be paying attention to if you want to navigate sensibly in today’s digital world. Here’s a brief example from a recent EastWest Institute Cybersecurity Summit.

I’d also recommend his blog, Schneier on Security.

Time for the Larry story again

For me, this has always been the Jessica story, as will make sense when you read it. I, too, tell it from time to time. The actual timing was late in 1993, as I left Ernst & Young at the start of 1994 to co-found Diamond.

I’ve told this one in different forums since it happened in 1995-ish. A recent incident prompts this version.

Back in the days when Harvard Square was one giant bookstore, a corner of two floors was occupied by Wordsworth. Always jammed, knowledgeable clerkery, books, books, and more books, the place where it was easy to walk out with two shopping bagsful of books.

"The TeamNet Factor is faceout at Wordsworth," Daughter #2 said. It was a star from Kirkus at the time, an acknowledgement from the arbiter of good books that this was worth reading.

So I went to take a look and there it was, third shelf up faceout.

I gasped and the man next to me said: "What’s wrong?"

"That’s my book!"

"Great book," said he, "I read it. And have you read my book?" He reached across, a couple of shelves down to hand me Managing Information Strategically, inadvertently pushing me into the woman just beside us.

"Oh, is that your book?" she said. "Well, this is my book, or I mean his book," pointing to the man to her left. "I’m just the editor."

Rewind: The author who reached in front was Jim McGee. The man with the editor was Charles Handy.

Jim and I chatted for a while; he mentioned that he was at Ernst & Young; we exchanged contact info; and I formulated The Bookstore Theorem: The only people there are authors.

Fast forward a year or two to the mail dock at Bear Island where I spotted a couple looking for directions. They wanted to find the girls’ camp that their daughter had gone to; they were staying nearby at the Appalachian Mountain Club on Three Mile Island; they’d just paddled over.

Me: "The girls’ camp is close to our cabin." Off we went, following the red trail, chatting, who are you, what do you do, until eventually the husband said, "I work at Ernst & Young."

Perfect entre for my book-story to which he had the perfect rejoinder.

"I’m Jim McGee’s co-author on that book," said Larry Prusak.

Fast forward again to very recently. Two good friends decided to go to the AMC camp on Three Mile for the weekend so we visited, got the tour of the camp (go, that’s all I can say, it’s beautiful).

Outside the dining hall was a list of those present for the weekend.

Guess who?

Yes, Larry, who, by the way, is reading Jonathan Franzen’s new one, Freedom. "Beautifully written," he says.

Time for the Larry story again
Jessica Lipnack
Mon, 06 Sep 2010 12:57:28 GMT