Year: 2010

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

An online survey about personal knowledge management

I wanted to make you aware of a survey about personal knowledge management that’s currently underway that would benefit from your participation. Here are the details along with relevant background.

Survey for Knowledge Management (KM) Practitioners and Researchers

Hello! My name is Kate Bower, and I m a graduate student studying knowledge management, strategic change and leadership and development in the Learning and Organizational Change Program (MSLOC) at Northwestern University, in Evanston, Illinois. I m contacting you and others like you because you are familiar with the field of Knowledge Management (KM), in that you likely practice, study, research, instruct, coach or consult on KM to some degree. Your contact information was obtained through a personal connection or a public source, or this message has been forwarded to you by your own personal connection.

MSLOC program requirements include completion of a 9-month research project, called a Capstone. My Capstone project is focused on the concept of Personal Knowledge Management, or how we as individuals manage our own information and ideas. The purpose of this study is to determine whether individuals who consciously manage their personal knowledge also consciously manage other aspects of their behavior; the secondary purpose is to discover if people who self-describe as effective personal knowledge managers are also effective at managing their behavior in general.

The target participants for this research are individuals familiar with the concept of Knowledge Management in the sense I ve described above: people who practice, study, research, instruct, coach or consult on KM to some degree, as they are likely to be somewhat familiar with the concept of personal knowledge management (PKM).

If you are interested in participating in this study, please complete the online questionnaire, which can be found here. The survey is comprised of 2 open-ended questions and 39 multiple choice questions; it should take participants approximately 20 minutes to complete.

Please feel free to forward this message or the survey link to personal connections that also fit the description of the target participant group.

Thank you in advance for your time and consideration.

Sincerely,

Kate Bower

—
Master’s Candidate
Learning and Organizational Change, Northwestern University 2010
kcbower@u.northwestern.edu

I’ve had several opportunities to meet with Kate and discuss her research. I will keep you posted as she completes her efforts at Northwestern.

Review of Bob Sutton’s "Good Boss, Bad Boss"

Good Boss, Bad Boss: How to Be the Best… and Learn from the Worst, Sutton, Robert I.

I’m becoming a fanboy of Bob Sutton, an engineering professor at Stanford who co-founded the d.school there. It started when i read The Knowing-Doing Gap : How Smart Companies Turn Knowledge into Action, which he co-authored with organizational theory icon Jeff Pfeffer. In 2007, he wrote The No Asshole Rule, which became a NY Times bestseller and was judged among the best business books in 2007. In between, he’s written a variety of books and articles, and an excellent blog, Work Matters, on management and organizational issues in today’s economy. Bob was kind enough to send me an advance copy of his newest book, Good Boss, Bad Boss, which is due to hit shelves early next month.

In Good Boss, Bad Boss, Sutton turns his attention and preference for evidence-based insights to the "authority figure that has direct and frequent contact with subordinates–and who is responsible for personally directing and evaluating their work." The quality of your boss, or your own quality as a boss, makes a huge difference in both the quality of work that gets done and the quality of the working environment. We all want to work for good bosses, presumably most of us aspire to be good bosses as well. Sutton adroitly mixes the substantial body of empirical evidence differentiating good bosses from bad bosses with effective stories and cases. He makes a case that it is possible to  become a better boss for those who wish to make the effort. Substantial and continuing effort, to be sure, but possible.

Sutton does have one core bias, a bias that I share. In his view, "bosses ought to be judged by what they and their people get done, and by how their followers feel along the way." The heart of the book is a series of chapters reviewing what the best bosses do. The chapter titles offer a good clue to both their content and Sutton’s perspective:

  • Take Control
  • Strive to be Wise
  • Stars and Rotten Apples
  • Link Talk and Action
  • Serve as a Human Shield
  • Don’t Shirk from the Dirty Work
  • Squelch Your Inner Bosshole

Obviously, no book on its own is going to make anyone a better boss. Becoming a better boss, like any skill, is a matter of good practice and good feedback. What Sutton offers in Good Boss, Bad Boss is a well organized and well justified collection of practices and ways to sense how well those practices are working. I found myself dog-earring pages, scribbling notes in the margins, and picking up new tidbits each time I went through the book. It reads smoothly and easily; yet it’s also densely packed with insights and actionable advice. As one example, let me share Sutton’s

11 Commandments for Wise Bosses
1. Have strong opinions and weakly held beliefs
2. Do not treat others as if they are idiots
3. Listen attentively to your people; don’t jut pretend to hear what they say
4. Ask a lot of good questions
5. Ask others for help and gratefully accept their assistance
6. Do not hesitate to say, "i don’t know."
7. Forgive people when they fail, remember the lessons, and teach them to everyone
8. Fight as if you are right, and listen as if you are wrong
9. Do not hold grudges after losing an argument. Instead, help the victors implement their ideas with all your might
10. Know your foibles and flaws, and work with people who correct and compensate for your weaknesses
11. Express gratitude to your people

Spiderman may offer the best summary of this book -  "with great power comes great responsibility." Good or bad, bosses are always on stage; their every move and utterance scrutinized. Being a good boss requires self-knowledge and self-awareness to an extraordinary degree. It also requires a keen sense for balance and for timing.

Other books by Bob Sutton

 

Enhanced by Zemanta

How will the Internet change how we think?

By way of my friend and colleague Espen Andersen. I’ve found that I’ve already used this story in several conversations and that I find myself mulling it over regularly in recent days. 

image The Edge question this year is "How has the Internet changed the way you think?". The result is eminently readable – my favorite so far is George Dyson’s answer, which is quoted here in its entirety:

GEORGE DYSON
Science Historian; Author, Darwin Among the Machines

KAYAKS vs CANOES

In the North Pacific ocean, there were two approaches to boatbuilding. The Aleuts (and their kayak-building relatives) lived on barren, treeless islands and built their vessels by piecing together skeletal frameworks from fragments of beach-combed wood. The Tlingit (and their dugout canoe-building relatives) built their vessels by selecting entire trees out of the rainforest and removing wood until there was nothing left but a canoe.

The Aleut and the Tlingit achieved similar results maximum boat / minimum material by opposite means. The flood of information unleashed by the Internet has produced a similar cultural split. We used to be kayak builders, collecting all available fragments of information to assemble the framework that kept us afloat. Now, we have to learn to become dugout-canoe builders, discarding unnecessary information to reveal the shape of knowledge hidden within.

I was a hardened kayak builder, trained to collect every available stick. I resent having to learn the new skills. But those who don’t will be left paddling logs, not canoes.

Short and sweet, in other words. Now, where did I leave that informational adze, what P. J. O’Rourke referred to as the "brief-but-insightful-summary" button?

How will the Internet change how we think?
Espen
Fri, 06 Aug 2010 13:47:02 GMT