Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

In the Flow: Patterns of Observable Work (e2conf preso w/speaker notes)

by btullis

2,382 views

@BrianTullis and @JoeCrumpler presentation slides from Enterprise 2.0 Conference Santa Clara, November 10, 2010. Thanks to everyone who attended in person and gave us your feedback and questions. For everyone who was not able to attend, please take a look at our slides. Notes are available on most slides.

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

5 Embeds 86

http://community-roundtable.com	78
http://www.communityroundtable.com	5
http://static.slidesharecdn.com	1
http://webcache.googleusercontent.com	1
http://staging.metropoliscreative.com	1

Statistics

Likes: 8
Downloads: 0
Comments: 0
Embed Views: 86
Views on SlideShare: 2,296
Total Views: 2,382

Brian: disclosure statement.
Our primary mission at Alcoa Fastening Systems Information Services is the delivery, operation, and enhancement of enterprise software and related services for thousands of internal customers. My role is Director of Information Services, trying to ensure that all of our moving parts are making that happen. We have about 80 IS colleagues at 20 operating locations, worldwide, and we also work hand in hand with our Corporate IS organization. It is a large, virtual team Joe : I manage our North America Aerospace Project Management Office, where I oversee and manage major system implementations and integration efforts across multiple locations. [more info…]
Joe : We are a leading fastener manufacturer, supplying both the aerospace and heavy industrial markets. If you have ever flown on an airplane, our parts helped get you to your destination. The context is an IT organization serving a global manufacturing company. The rest of the presentation and our case study show how that works in practice.
We hope to show you what observable work means to us, what is the value, and explore patterns that can be applied across many different knowledge work contexts. There will be some theory, but we want to apply each theoretical pattern to how we are implementing it in practice. Joe: [preview of the case study]
These are some of the many wonderful thinkers and practitioners out there that helped us directly and indirectly, and whose ideas we have used and remixed. Thank you. There are links here to the Traction User Group channel on Blip.tv. The keynote talks from Jim McGee and Jon Udell discussed Observable work and they are worth a look. Also, the Observable Workshop was filmed and that is available for viewing.
We have the perhaps not unique situation of working for a company that grew by acquisition, leading to a complex hairball of legacy business processes and accompanying IT platforms. We work in a highly matrixed environment. Most of us have at least two bosses; some of us more - although I don't think any of us have 8 bosses like Peter Gibbons in Office Space. We are a public company, so we have Sarbanes-Oxley to worry about. On our team, we have a charter to deliver common IT-enabled solutions across dozens of locations, each of which is evaluated by a stand-alone P&L. The people we work for are highly focused on manufacturing and engineering, rather than the black box of IT. We are always looking for ways to improve ourselves and our team’s performance. We cannot change the world, but there are some things squarely within our control. Our challenge is to figure out how to structure our team and our processes to meet our mission. We see Observable Work as a key enabler to our mission. Joe : talk about the problem in terms of complex project management, and what are the issues we need to overcome.
We start from a point of view that says that there is something fundamentally broken about the way that knowledge work gets done in most organizations. It was in ours, and in some ways still is, but we are taking specific steps to address that. Here is a cross section of issues and concerns that we have. How can we: Share what might be half-baked ideas that would benefit from outside input, but that we don’t share openly for fear of being shot down? Document and share lessons learned on projects/audits/operational failures so that we don’t repeat the same mistakes again? Narrate our work so that we don’t have to drag each other into status meetings and waste our collective time reporting what we did instead of letting status emerge naturally from our visible work? Make our electronic documents come alive and be linked across an organization instead of going to die in networked file shares and content silos? Describe exactly the heck it is we are talking about when it comes to social media being used to get work done without calling it “Wikipedia for the workplace” or “Facebook for the enterprise”? Ultimately what we are trying to bring about is a basic transparency to what are traditionally black-box knowledge work processes. And we are in IT – IT is the deepest, darkest, most obscure of the black boxes that exist in most organizations. We mean transparency in the sense of getting as few as two people that work for the same company on the same project to be able to see and to understand explicitly what each other is doing…so that together they can create a better outcome for the organization. And if we’re lucky, add-on benefits of in-the-flow communication, strategic alignment, and knowledge re-use all emerge from this first principle of helping teams get work done. Perhaps this doesn’t seem like a big deal. But my experience is that in most organizations, it is, and we don’t like to talk about it.
Our main concern has everything to do with increasing performance, eliminating waste, and doing more with less. We need specific ways to make this happen, and the patterns of observable work are helping us to do that. Joe discuss specific benefits expected from improving project-related processes, and how those will be discussed in detail during his case study.
This slide is an attempt to show you how we have broken down the Observable Work concept. You will see some themes pop up as beliefs, core patterns, and actual usage patterns, so excuse us if we repeat ourselves. It all starts with our core principles and beliefs. What thinking leads us here? It’s some of the usual stuff about transparency, etc, and others that are maybe less obvious. From the core principles we talk about core patterns. These are basic building blocks that are recombined and extended in various ways to come up with People, Process, and Technology usage patterns. These core patterns are actually skills that we find that most of us do not have, are not taught, and do not consistently apply in practice. However, they are absolutely key to a thriving knowledge work environment. These usage patterns will be discussed with examples from our own environment through the classic framework of people, process, and technology. We also discuss things that we have learned but not necessarily applied. Please do not get hung up on this being an authoritative or exhaustive list. Maybe someone will write a book on the topic – we are trying to say enough so that you get the idea. Finally, we will discuss a detailed use case that applies the framework to a complex project management scenario.
In using the term silos we are thinking at all levels of organization - roles within a department, across departments, locations, business units, between companies. As much as I would like to, I don't want to seem naive and say that silos are 'bad' and that they must be smashed. I think that we can try to make them permeable . In fact, I believe that managers have a responsibility to make their own silo as permeable as possible. The real underpinning of the several principles is trust. No one is going to feel comfortable working across silos, outside of their normal chain of command and comfort zone, without it. I don't have a formula for that, but it takes time, and you can lose it in an instant. We are social where required, but it's not something that we dwell on. The social aspect deserves a little more discussion. A pure focus on Information and Process Flows tends to ignore the social dimension of how we live and work as human beings. Our ability to be effective will suffer greatly if we neglect this. Being IT guys, and introverts at heart, remembering this is not always easy - but we try to get a little better at it every day – although I don’t think that we will ever groom each other like the chimps in that slide. We seek simple solutions to business problems, fighting a tendency to over engineer just because it is possible. What we do and how we work is highly interdependent with the rest of our organization. Finding and leveraging these links adds value and relevance. Surfacing these links and finding the relevancy of each individual action makes work more rewarding for everyone involved. Joe: The point about status is subtle, but important. We believe that working this way can reduce overhead and administration, allowing everyone to focus on doing work, not reporting on it. I will touch on that in the case study.
These core patterns, we think, are the basis for the people / process / technology patterns through which we have implemented observable work. They may not be the best list, and our thinking is still evolving. In fact, this list of core patterns stems DIRECTLY from the Observable workshop held at the Traction Software User Group conference on October 13-14, 2010. First and foremost, most of us work for organizations…and where they exist, we have to respect those boundaries. Otherwise we are going to have trouble paying our mortgages. That being said, there is a lot of dysfunctional nonsense going on that we think that we can overcome. The best technological framework to make things visible is through the web. Unless of course your audience is using IE6. Maybe not Twitter…but think about how you can log or narrate what you do for the benefit of yourself and your team. This is a practice used by many craft workers over the years…and it’s a practice we have lost. At its most basic, it means writing down or recording what you do, as much as possible. Information changes all of the time. If you distribute an artifact (file, page, presentation, etc…) – link to it. Do not send the information itself unless it’s absolutely necessary. You have a finite # of keystrokes available in your hands over your lifetime. Use them judiciously…so distribute information to the widest scope possible to be most efficient. No matter what Google says, it is important to give search engines some help. You need to be “discoverable”. There is an art to naming files, articles, web pages. Think about your audience and have some discipline to how you ‘name’ things within your organization without going overboard into taxonomy hell. This topic led to some heated debate at our observable workshop, and if during Q&A anyone would like to debate it, we’re ready for you. Now that you have seen the core principles and the core patterns…if we haven’t convinced you at this point, it is probably not worth it to continue. The naysayers will shout that the real world doesn’t work like this and that there’s no way that the CEO is going to live blog secret strategy meetings to the public, or even to most of the company – and that is not what we are proposing. Be patient and we hope to show you the practical value of how these can be applied in real world situations.
The title of this track is Community Development and Management. I will say that for the longest time, I discounted the need for any consideration of this softer stuff. I typically started with a vague notion of process, jumped into enabling technology, and then perhaps we would do a little organizational or stakeholder analysis as some minor change management task. All of the stuff that we are learning in this track – I wish that we had that two years ago! So far I am concluding that the People patterns are most important; however, they are the hardest to define and replicate widely because they are so dependent upon specific organizational contexts. We are going to give it a shot.
Strong ties to start Existing “in the flow” work processes – meeting notes, project status, or, well, grooming. Starting with strong ties, we can build positive feedback loops spread to more use cases, and hopefully more teams (eventually leveraging weak ties) So what does this really mean? Take an existing team or organization, defined in a traditional organization chart, formed around specific projects, or ad hoc This team is held accountable collectively for deliverables; strong ties; there is an innate sense of “we” that they bring to their work. In our case, where we started was “AFS Information Services”. We are an IS/IT organization within one business unit of a large global corporation. Communities of trust usually have existing work processes that can transition to an Owork method, and use cases do not have to be invented. This can speed adoption. We think that you should start small, because everything is political. Within smaller groups you can build positive feedback loops around Owork experiences. There is a very important concept of building these communities in the flow of work. The only way we have found to align individual interests and motivations with those of the group is to start in the flow of work and give individuals benefit from using various tools and techniques. Then and only then can you extend to small communities, large communities, and the entire company. That’s our experience at least. As they join other teams and groups, they bring an Owork philosophy with them.
Joe : Discuss AFS IT example of multiple locations. IT guys working all over the place. Multiple bosses. Finding use cases around small teams, building up with strategy, etc. Simplified example shows potential starting points. There are others… The extent to which you need to think about this depends on your organization’s complexity and culture. This simplified chart taken from our own experience shows hundreds of potential communities built around the corporation, business units, functions, project teams, and various subject areas. We have found that you really have to start somewhere and solve problems in an existing community, before building something galactic in scale that solves everyone’s problems.
Joe : Example of the Information Services Community and how it is deployed for project issue / problem management where complete transparency is not possible. Observable Work has a flaw which is difficult to overcome. The general issue involves dealing with conflict in an open forum. The specific issue is the risk of exposure resulting from an admission in a post that might lead an influential third party to conclude that the author is to blame for a failure on a project. This fear paralyzes free expression and acts as a damper on clear communication. When we started, everybody is our company was capable of viewing our project wiki. The reason behind this approach is the need to involve anyone anywhere, on demand, in project work. That flexibility is key. The theoretical limit was 65,000 people, while the practical limit, those who were actually interested enough to look, was closer to 150. The actual limit, people who care about the project, may only be 25. However, In the minds of the team, they are always writing for an audience of 65,000 people, not 25. This miscalculation greatly influences what they are willing to write about. Caution guides every decision when an employee thinks their job may be at risk, or that they might be viewed as attacking a colleague. Our job is to provide a safe but open workspace limited to the people who actually need to know about the mistake, which in practice may be limited to as few as 10 people. My colleague (and Director) Brian Tullis recently modified our current model to include a work group level view of the main workspace. He took this action after an open discussion on a troubled project reveled that team members feel exposed if they post their myriad self-assessed mistakes in an open wiki. Understanding this concern allowed Brian to create a semi-private “open to work group” workspace as a subset of our open wiki. The combination of the two workspace views allowed for open collaboration on non-controversial issues, and protected collaboration on controversial issues. Our setup has four tiers, built on the observable work definition of "observable in context" and the core pattern of "respect organizational boundaries": Open to all – This is where the work gets done. Every article, milestone, deliverable, and conversations starts here. In theory, any person in the company can view any file. It’s an open wiki limited only by access to the company WAN. on a percentage basis, 98% of all articles reside here. Open to work group – this is the newly created workspace mentioned above with access limited to our group. In this case, our work group is our IS organization. Since we post most articles in the “open to all” workspace, this area is limited to items that might cause the risk of exposure to a team member. A practical example is a semi-private discussion happening on a public project deliverable. Everyone sees the deliverable, but only the project team sees the semi-private discussion and it's all happening on the same permalink URL. It is a really nice capability of our platform. Open to Management – this is an original group created when we started the open wiki. It is a safe place to for the IS management lead team to collaborate on issues that require privacy or to support work processes that are privileged. Main articles may post in the “open to all” wiki while the collaboration takes place in the “open to management” workspace. Private – An individual workspace is an additional layer where an individual can comment on a “open to all” article but keep the content private. A good example may be tagging an article for a follow-up with reference notes.
Joe : [describe the role of a community manager in our world and perhaps apply it to our project workspace] There are many ways to describe a community manager, and we think that the speakers in this track have done a fantastic job of that. Leader, servant, sociologist, emergineer are some of the words that come to mind for us. More than managing their individual communities we think that community managers bridge communities of trust; they leverage weak ties within and particularly across communities. Every community – however you define the word – needs one. Not only do you need a community manager for your “global” community, but you need one at all successive levels – sub communities, workspaces, teams, etc. You may call them something else but ultimately this is what they are doing and it is a skill well worth developing for today’s work environment. It is tempting to say that no one is in really in charge and that some sort of structure will always emerge from the chaos, but it doesn’t always. Ideally, this type of role is embedded in the work processes of various teams and can lead by example.
Brian: Beyond ice cream, we need to share our questions, concerns, problems, answers, work products. It is more critical than ever that we do this today in our siloed organizations - within a department, across departments, locations, business units, between companies. As much as I would like to, I don't want to seem naive and say that silos are 'bad' and that they must be smashed. I think that we can try to make them permeable . In fact, I believe that managers have a responsibility to make their own silo as permeable as possible. This is difficult even within communities of trust, enabled by competent community managers. Some cultures are just not receptive to this. This is just hard. To quote a fellow 2.0 Adoption Council member, “We can't talk our way out of a culture we behaviored our way into...we must behavior our way out." There is an important point to make about innovation as well. We are coming to learn that innovation is something that happens on the edges. It is already hard enough to do anything remotely innovative inside of large companies. If we are not sharing what we do, then I think that we are missing the point. We talk later about the concept of narrating your work. It doesn’t make much of a point to narrate if you’re not sharing with anyone. As an example, approximately 40,000 of my colleagues can view every project deliverable, blog post, strategic communication, procedure/process documentation, audit report, and compliance test done on my team. We have things that we make “less public”, but generally speaking, this is a practice I would like to see spread.
What we do and how we work is highly interdependent with the rest of our organization. Finding and leveraging these links adds value and relevance. Surfacing these links and finding the relevancy of each individual action makes work more rewarding for everyone involved. If we wait until we are “finished” before we “post” something or store it for public consumption in the content management system, then something gets lost. Context. The “how” of knowledge work products. Unfinished business from days or weeks or months ago that can be picked up and finished later by someone else. Snippets can be remixed into something bigger and better. [quote Patrice Livingston via Paula Thornton – “infrastructure for synchronicity” here] “ I knew at an instinctive level that what we were doing — all the unstructured communication, all the relationship building and stuff that our team was doing — was much more valuable than the work we were doing in written reports and meetings and minutes, which is what consumed the body of our time. See context for knowledge work products. Tolerance for things unfinished but that are available and can be finished later. Not only does this facilitate problem solving, but it also promotes innovation because these unfinished bits can be fuel for future innovation (narrated, in-process, and shared – it’s all related).
Brian: Process patterns are specific techniques that you can use.
Brian: Dave Winer coined the phrase “Narrate Your Work”, or at least popularized it. I can share what it means for us. It may well mean other things for you. In our environment, we struggle with knowing what is going on – where ARE we on this project / task / issue etc. What was the thinking behind a certain strategic decision? Why was a certain document updated, what exactly changed, and what does it mean? We have to keep working files. We have to track action items. We have to take notes. We have to record our thoughts somewhere. The more visible we can make those thoughts in the form of narrated work, we can unlock a lot of value that we never knew existed. Assuming that we have in place a culture receptive to “in Process” information, enabled by community managers operating within communities of trust, then narrating your work can be a fairly simple solution to the “where are we, what’s the context, and why did we do this” questions. This concept goes well beyond semi-official status-type information. If we are narrating what we do, we get extra information that can be useful not only to the project and task at hand, but for other, currently unknown uses down the road.
Brian: A real world example. We have an IT project that involved the migration of a large number of distributed applications to our data center. The article contains some basic instructions at the top that explains to the reader that what they are see is an Excel file that is updated live inside of the browser, and every time progress is made on the project, or anything fundamentally changes, or if the project resources make any kind of progress, they make a comment to the article. When we took this screenshot there were 168 comments to the article. If you want to know what is going on in the project, chances are that you are going to find it here. This is not brain surgery, folks. Our colleagues have to track their complex work somewhere, and in my case, it’s in my company’s best interest to set up a culture and give them a platform where they can do that so that it’s effectively shared with everyone else.
Joe: That’s Brian’s family at the beach
Joe
Joe: Status from visible work is a special case of Narrating Your Work. Here, the explicit purpose of narrating your work is that you can eliminate non-value added status calls/meetings/emails through making available your work through an activity stream related to your project/issue/task. Activity streams are a topic we’ll touch on later in Technology patterns. This is not to say that we do not write status reports per se. It means that when we do meet, we can focus on real issues, conflicts, and escalations, rather than telling everyone exactly what we did last week. A brief status report that points to narrated work fixes that problem. We will focus more on this in our project management case study.
Joe: What’s the status of the Customer Returns Test Scenarios? By reading this article, we can find out – Is the scenario complete? What were questions from the customers? How did we react to those questions and change the article? Are we complete with the end to end process? Has everyone approved it? This example is a test scenario for a customer return process, part of a major system upgrade. The business analyst who created this article had some simple goals: describe the business process that needs to be tested within the software get feedback and approval from colleagues in Customer Service, Quality, and Finance Notice the paragraph-level comments by Customer Service and Quality - there is a threaded discussion in the middle of this test scenario. At the bottom of the article, there are "I approve" comments from everyone time and date stamped, with links back to their profiles. A key takeaway is that we invent lightweight processes as required using text, tags, and comments. We did not trade emails to collaborate and we did not use a structured workflow or business process management system to accomplish the approvals. We strive to create and share all of our work products just like this – for projects, strategy, compliance, documentation, budget, etc. Approximately 30,000 of my colleagues can read that hypertext article if they need to see it, and 2,500 can comment on it. If we need to show them, or pull them in for collaboration, we can. Over to Joe.
Brian: The example we have chosen to illustrate building links between silos is 2010 Global IT strategy wiki article. It is important to note that even within a single functional area like “IT”, you can have content silos and process silos that keep content and information segregated from each other. In our world, that would be Strategy documents and articles, blog posts, regular communications updates, compliance procedures and tests, projects, and various person and location profiles. This really has nothing to do with having things available and open. It means actually taken the step to build links between pieces of content and most importantly, between traditionally siloed processes. As a simple example, there’s a really simple way to show that some of our major projects are aligned with our strategy – they are directly referenced and linked. We also believe that there is a direct benefit to increasing employee engagement in this particular scenario. This comes through people seeing how their work supports the larger strategic goals of the organization.
Brian: Within the technology patterns we will show a few examples of how we use technology specifically to deal with information overload as well as unlock the potential static electronic files.
Brian: This is a snapshot view of the activity stream of all articles and comments made on October 8, 2010. While this is marginally useful to some people, it’s fairly useless without filters. It is just too much to look at and it’s not relevant for a large audience.
Brian We will not win any design awards with our Spartan activity streams and news pages. We extend the concept of activity streams deeply into our platform. We heavily use functionality which allows the construction of search widgets called “Sections” to be placed inside of any individual article, allowing us to pre-build searches for our users. This is really important in a world where you are narrating your work. There are rules to respect when it comes to article titles and tagging, but we can transparently enforce those through the use of “Add” buttons which automatically apply the proper tags. This example is our all projects activity stream, with latest news across all projects as well as a view of our latest monthly strategic project updates (Joe writes those, by the way, and he does a great job with them).
Brian We thought that an interesting technology pattern to discuss would be “Living files”. This technology pattern is closely related to the People Pattern “Responsibility to Share” and the Process Pattern of “Narrate Your Work”. This is really where the rubber meats the road in Observable Work. We have a complicated relationship with all of these electronic files that we have created over time. Can’t find it. Don’t know how it relates to other files, within and outside of its current silo. If you can find it, you only have a final version of it. It’s not searchable by the enterprise. Maybe you find a copy that is called version 10, but you might really need version 4 because that is what your customer or supplier is referencing at the time. Someone updated the project plan, but the only thing you really know is that the “last modified date” changed and it’s now 4 kilobytes bigger – but SO WHAT?! A living file is any electronic file – usually Excel, Word, or Powerpoint equivalents (with MS Project, Mind maps, PDF or other file types thrown in). A living file exists IN CONTEXT with its environment. Many times, there is active collaboration happening around and within the file. We strongly believe that in cases where you might have used MS Word you can make it a wiki entry, so history and version tracking are built in. If it must be a specific file type, you need a hypertext parent article, with associated comments, that are linkable and discoverable to the rest of the enterprise that needs to see it. A living file evolves over time, and its changes are narrated by the authors and editors. Good practices are to say what changed from one significant version or revision to another, and WHY. The why is perhaps more important than you think. Because of volume of electronic information that we create, if the why is not known at the time of creation or change, it is perhaps lost forever. While I think it is important to capture WHY for your colleagues – it helps you yourself to remember what the heck you were thinking when you did something. The Narrate Your Work Process pattern example from earlier illustrates this well. I will show it again here – it’s an Excel file scorecard, displayed in a web page, that gets a comment any time there is any significant change.
Brian: Here is the scorecard again. I hate to use the same example, but it’s a good illustration that I can show publicly. The matrix in the middle is a live Excel spreadsheet. Here, we are pointing out the number of comments – 168 total. Each of the applications in the first column gets its own comment group in the threaded discussion. SPC Proficy has 24 comments. We have also used this technique with various Powerpoint presentations, documentation in Word or PDF, and other Excel files. The more important and strategic the file, the more we try to do this. Obviously, you can’t do this with every single file you create. Or you could, and maybe if we did that, we’d create fewer files!.
Joe:
Joe:
Joe
Joe
Joe:
Joe: Reference NTN blog post and talk about other issues.
Joe: Brian and his mother in law.
Brian : What we tried to demonstrate today was the concept of Observable Work and how we have implemented it on our team. I hope that we have succeeded in that. It is a journey, not a destination. The most compelling value proposition we have found is the elimination of waste processes in project management and other non-value ‘status’ situations. If you have a supporting culture with able community managers, shepherding your community through these techniques can be a very rewarding process. Your mileage certainly will vary. We have purposefully stayed away from a discussion of vendors and platforms. There are a number of solid platforms available today that allow an Owork philosophy to flourish, although it is likely going to be pretty rough going if your only tools are email and networked file sharing. We do not want to leave you with the impression that we have found the holy grail of productivity and collaboration and the application of social software to work. We have a set of principles and underlying technical solutions that work for us. There are real issues around organizational dynamics, personal motivation, politics, and the risks of transparency that we deal with every single day. Going forward, we want to continue to learn first, and teach second. We are not sure that this approach scales up and out, but our approach is to start small and build out. As this technology space evolves, it will have implications for us. We can only hope that the principles we have identified can be implemented in any platform, regardless of vendor or underlying technology. Otherwise, we are too busy getting work done to worry too much about it.
Brian : Please see Jon Udell's article. As best I can tell, he invented the term Observable Work. There's lots of good stuff here. Jim McGee’s TUG2010 keynote is worth a look, as is Jon Udell’s talk, all recorded online. I highly recommend that you download the Observable workshop MP3 and listen as a podcast. From time to time, we will continue this discussion online in our blog, where we talk about productivity, collaboration, and project management. We would love to see your feedback there.
Thank you for your time. Thanks to our colleagues as well. All of the examples you saw here are just their "Observable Work" in action. You can connect with us on Twitter or LinkedIn. This presentation will be on SlideShare soon.