Tag: observable work

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.

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.

Culture, Process, and Practice – Effective leverage for Enterprise 2.0

The discussion about organizational culture in knowledge management and Enterprise 2.0 efforts is evolving in useful and pragmatic ways. The earliest discussions ignored culture entirely and implicitly assumed that technology would magically shape the organization as needed. The next round of discussion identified sharing as a desirable global cultural characteristic. If you were in a sharing culture, all was good. Time would ultimately reward your virtue. Those with equal need but less virtue whispered of incentives and WIIFM (what’s in it for me?). Crass and vulgar, but perhaps sufficient for most organizations.

In general these open ended discussions of culture are unsatisfying. They make gross assumptions on the basis of little data. Dave Snowden’s principles of knowledge management (see Rendering Knowledge) provide important pointers to a better answer with his emphasis on the behavior of individual knowledge workers.

Enterprise 2.0 as the extension of ERP

Michael Idinopulos of SocialText noted a shift in the debate at the recent Enterprise 2.0 conference in Boston. In a post titled The End of the Culture 2.0 Crusade?, he observed that:

Last week, the Enterprise 2.0 world turned a corner. Nobody pounded the table for cultural change. Nobody talked about incentives or change management. Nobody talked about transparency or modeling collaborative behavior.

Instead, people talked about process.

…

This is the most pragmatic shift in focus since the inception of Enterprise 2.0. It will have huge effects on the pervasiveness of social software in the enterprise, because it shows a clear path to the business value companies can realize from their implementations.

I ve been arguing for some time that social software achieves widespread adoption only when workers use it in the flow of work. Asking your colleagues to step outside their daily processes and tools to share what they know or network with others won t get you very far. (Trust me, I ve tried.) Bringing your colleagues collaborative tools and practices that make their daily processes better, faster, cheaper, and more interesting does work. It s all about process. Improve the process, you win. Don t improve the process, you lose.

This point of view squares with Ross Mayfield’s that broken business processes contribute to email overload and that

(Employees) spend most of their time handling exceptions to business processes. That s what they are doing in their inbox for four hours a day. E-mail has become the great exception handler.

While this is a very attractive position, it is incomplete in an important, and potentially dangerous, way. If you focus Enterprise 2.0 efforts solely on business process you may get scale, you will likely avoid the issue of culture, BUT you risk missing an opportunity for great leverage.

Leaving Process for Practice: Leveraging Knowledge Work as Craft

Focusing solely on Enterprise 2.0 efforts as an extension of existing business processes treats Enterprise 2.0 as a residual, clean-up, effort. It presumes that the goal worth pursuing is the efficient execution of well-defined processes. It reduces Enterprise 2.0 to an afterthought to ERP.

There is an assumption in this process-centric view that all relevant behavior can be reduced to business rules in the automated system. Exceptions are viewed as system failures or design failures. Moreover, failures in the system are attributed to resistance on the part of system users and operators. Instead of interpreting failures as resistance, what if we start by treating them simply as data?

If you start with process, your goal is uniformity at scale. Ideally, every situation should be treated in exactly the same way. This is eminently logical if you are calculating payroll withholding taxes. It is clever when you extend that logic to treating airline seats as a perishable commodity whose price might vary depending on the day of the week. Can you push in this direction forever?

Are there situations where uniformity and scale are not the appropriate criteria? Of course. The realm of art and craft is all about uniqueness and the value of limited scale. What happens if we opt to start from the art and craft end of the spectrum?

One choice is to accept the dichotomy. There is a class of problems suited to process thinking and a class of problems suited to art and craft. Another choice is to continue to force fit problems into a process view of the world. This has been a successful approach. Consider the number of problems that have been transformed into algorithmic problems well-suited to automation — inventory control and demand forecasting to name two.

A third choice is to ask how to improve art and craft without presupposing that uniform process is the goal. This was the approach started by Vannevar Bush, Doug Engelbart, and their intellectual heirs. This approach spawned much of the technology environment that we operate within today. Oddly, we’ve largely ignored their motives in creating this technology; to support more effective ways of wrestling with intellectual problems.

Engelbart, and those working on his agenda, started building new technology tools because our previous tools and methods were inadequate for the problems we had to solve. They built tools to support new kinds of problem-framing and problem-solving practices. We’ve adopted the tools without considering the practices and behaviors they were designed to enable.

Culture as the sum of shared behaviors

Those who lay the blame for failed efforts to introduce knowledge management or Enterprise 2.0 tools on organizational culture are picking up on this behavioral issue. They are doing so, however, at the wrong level of detail. Organizational culture is a convenient shorthand for the practices and behaviors that constitute "they way we work around here." Changing culture is hard because it’s an abstraction; there’s nothing to push against to get it to move.

While changing behaviors can also be hard, as anyone who’s tried to adopt a new habit can attest, it is possible. Change the right behaviors and eventually you have a new culture. The opportunity in Enterprise 2.0 technologies lies in the new behaviors that become possible. The challenge is that these technologies do not dictate a single set of obvious behaviors. In fact, it is possible to adopt the technologies and make no behavioral changes at all. 

Focusing on behavior is still a challenge. Technology opens up possibilities while setting few constraints. The activities we are interested in here are equally unconstrained by business process; we’ve defined them as the behaviors that don’t fit within the mantle of process. We need to go back to observing how work is currently being done, ask what flows smoothly, see where things get stuck, and design alternate ways to make use of the new range of available tools. We’ll visit those questions tomorrow.

LATE BREAKING LINK: As I was about to publish this post, John Tropea of Library Clips posted a lengthy piece on Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management. I’ve only just skimmed it, but it’s squarely part of this evolving conversation.

Observable work – more on knowledge work visibility (#owork)

My post on the visibility of knowledge work last week generated some some excellent comments and excellent blog posts around the web. For my own benefit I wanted to gather up what I’ve come across so far and put it in one place.

Recap

Greg Lloyd, CEO at Traction Software, kicked things off. pulled together some key threads of the conversation and gave us a better label – “observable work.” His initial summary:

I believe that principles of open, observable work like open book financial reporting to employees – is a simple and powerful principle that people at every level of an organization can become comfortable using. In my opinion, wider adoption of observable work principles can succeed with support and encouragement from true leaders at every level of an organization – as Peter Drucker defines that role: “A manager’s task is to make the strengths of people effective and their weakness irrelevant–and that applies fully as much to the manager’s boss as it applies to the manager’s subordinates.” Enterprise 2.0 and Observable Work

Greg also pointed to an excellent post by John Tropea at Library Clips:

why do I have close to total awareness of people in my personal life that requires low effort, but yet in the workplace I don t have this ambient awareness!

In fact it may be more crucial to have micro-blogging/activity stream networks in the workplace as we share and work on the same/similar/related goals and tasks within our teams, across teams, workgroups, and enterprise wide so the more we are aware, the more we can be on the same page, and have better coordination, cooperation and collaboration surface opportunities (emergence), have the best people on the right tasks, and generally have the ability to be more responsive and adaptive.