The Deloitte study focuses heavily on a Traction TeamPage deployment at Alcoa where the study highlights a 61% reduction in hours spent on compliance activities in IT project management. Separately, Alcoa reports substantial performance increases in terms of time savings of over 100 hours per week in an IT implementation that was completed in 7 rather than an expected 18 months. It also highlights Traction TeamPage customer Ensign-Bickford where a process around Tooling Requests that created an continuous feedback loop, reduced re-work and reduced overtime hours from 10 to 1 (or less) per week.
In their analysis, Deloitte says meaningful performance improvement is achievable:
The experiences of Alcoa and OSIsoft prove that social software can achieve meaningful improvements. How did they succeed where so many others did not? Both Alcoa and OSIsoft employed a simple tactic: they avoided focusing on adoption. Rather, they identified specific operational pain points in the business that social software could address. By focusing on something tangible, broadly relevant and widely acknowledged as a problem, they overcame initial skepticism.
Sampson's book is another great reference point on adoption. He takes special care to focus on second wave people.
What-why reversal. A first wave person is attracted to the "what" of the new collaboration technology, but may struggle to articulate the "why" -- the future oriented picture -- to other people. They may "get it" implicitly, but struggle to put it into words. A second wave person gets the "why" (if it's conveyed in terms of their work), but will need help with the "what." (Page 30)
Later on, Sampson uses my quote to lead off Chapter 9 - Making it Real:
The deployments I have seen succeed the fastest and become the most enduring are those that are built under the backdrop of a defined work process that is better conducted wiki or blog-style than in email, Notes, SharePoint or whatever the alternative. Patterns emerge within these deployments that change their nature and branch into new uses of the technology -- but leveraging the core process (or processes) is vital to gaining high participation and sustained user attention.
When you focus on the "why," people stop looking at the platform as a "blog" or "social" system but rather as a work-process system. They take it more seriously and part of their daily work, rather than a destination to only enjoy and engage in when they have a (very rare) free cycle. The patterns that take over become hardened and information infrastructure starts to take root. It's this infrastructure, whether its the history of issue / exception process focused discussions or documentation and later execution of compliance test plans, that creates a pattern on which new use cases can emerge, and enables a substantial Return on Information.
The Computer History Museum's This Day In History March 11 reminded me that today is the birthday of Vannevar Bush (born March 11, 1890), a distinguished educator, engineer, Vice President and Dean of MIT, and President of the Carnegie Institution. As World War II Director of the Office of Scientific Research and Development, Bush managed all US wartime research, reporting directly to President Franklin Delano Roosevelt. After the War he was instrumental in creation of the National Science Foundation based on a 1944 request from FDR. Bush is also known as the author of a famous July 1945 Atlantic Monthly essay As We May Think, where he described a possible "new relationship between the thinking man and the sum of our knowledge" including the Memex - a literary machine which inspired the invention of hypertext twenty years later - and indirectly lead to creation of the Web. See the video archive of the MIT / Brown Vannevar Bush Symposium on the 50th Anniversary of As We May Think for a great collection of talks by Doug Engelbart, Ted Nelson, Andy van Dam, Tim Berners-Lee, Alan Kay, and others inspired by Bush and and his work.
February 16, 2011 · Blog1591 · Posted by Greg Lloyd
Yesterday I read GigaOM analyst and editor Haydn Shaughnessy's Future of Work Platforms report (registration required, free seven day trial available). I commented: Haydn -- A very thoughtful and useful analysis – a combination that’s all too rare! I’m particularly happy to see your thoughts on observable work (see the full report for Haydn's excellent analysis).
Ever since Jon Udell coined the term, it struck me as good way to talk about practical benefits and a business purpose for collaboration. In my opinion it helps by pealing back issues of privacy in context and activity streams, along with subtleties required to support the social dance of getting things done, dealing with exceptions, and staying aware of what’s going around you without getting swamped. This is much closer to jazz than the world of canned business transactions. It requires a level of attention to ease of use and user experience that’s just as important but in many ways more challenging to do well in a business context than for the public Web.
I also thank you for your careful analysis and kind words about Traction Software.
I've thought a lot about how to describe the relationship between Observable Work and the style of action tracking, coordination and agile project management used by TeamPage customers like Brian Tullis and Joe Crumpler, as well Traction Software folk. When you watch a skilled team in action, it's like watching a great jazz group - there are themes, there is structure, and there are limits, but a team shines in individual excellence combined with coordination, improvisation, innovation, handling exceptions, and seemingly effortless awareness of where others are and where they're headed.
Traction TeamPage 5.1 aims to support this performance model.Bill Ives captures the idea well: "The action tracking concept is not old school project management with Gantt charts and resource allocation. It is allowing employees to manage their work tasks and make this management transparent to those who need to know...This is the action tracking part of project management for the regular employee, not the program management office. It brings this activity into the enterprise 2.0 world as every task is treated as an object for comments, RSS, and made searchable to those with the proper permissions."
Every business activity involves some measure of action planning and tracking. People have lived with action tracking systems that range from a list on the back of an envelope, to getting things done style planning, to multilevel project plans for large and complex products like aircraft.
The TeamPage 5.1 action tracking model focuses on making it simple for individuals and teams to plan and coordinate the daily, weekly and monthly activities that drive effective teamwork. This level of coordination can quickly become too complex for the simplest systems, but too detailed – and close to real life – to be effectively modeled, tracked and managed in real time using software designed solely for top down project modeling and planning.
In my opinion, the big difference is action tracking built in to the natural flow of work. This makes daily life easier rather than more complicated.
Collect individual tasks into projects to make summaries easy to report up, and top down progress easy to track by project or by individual.
Tag any paragraph as a task and later dive down by person, task, project or milestone to make personal tracking and maintaining awareness much easier.
Click a name and link to a colleague's profile to see tasks, activity and status from their perspective.
Pop a quick question into a status window to make communication quick, effective and observable.
Add a comment to a task (status message, page, post or paragraph) to raise an issue or suggest a solution, to make exceptions much easier to recognize and handle.
All of this works with TeamPage's advanced search, notification, and a collaboration model that puts tasks, status, conversations and posts in a business context, organizing communication by space for those who have permission to read, while using spaces to protect all content in client, partner or internal spaces that require privacy.
I've worked for the US Naval Research Lab managing parts of very big projects for the US Navy, and as a member of small startup teams. I believe that at the working level the same model supports effective teamwork where bottom up activities meet top down plans as the foundation of projects of any size.
We're seeing first results from TeamPage customers and Traction Software using TeamPage 5.1 integrated action tracking and the response has been great. Look for updates here, on Twitter, or join the TeamPage Forum and the live conversation - or to should I say jam? (to borrow a great term from IBM).
January 21, 2011 · Blog1575 · Posted by Greg Lloyd
Our long-time Japanese reseller partner Applied Knowledge Co Ltd has done a great job bringing Traction TeamPage to the Japanese market. They are an excellent sales and consulting partner for Japanese market customers. AKJ also has deep experience applying Enterprise 2.0 principles, the Traction TeamPage SDK, Japanese Language localization of the TeamPage interface, and Japanese advanced linguistics and faceted navigation capabilities of Traction's Attivio powered Advanced Search.
I'm proud and happy to point to AKJ's excellent Japanese Traction TeamPage Release 5.1 examples posted on tractionsoftware.jp I thank our friends at AKJ for bringing the full set of TeamPage 5.1 action tracking, integrated status, profiles, Attivio advanced search features and Proteus user interface to the Japanese market so quickly and professionally.
I started my talk off with emphasis by asking Why Does Enterprise Search Suck? Then I elaborated on why the social intranet, built on the basis of links and pages, can work with good search such as our TeamPage Attivio® Search Module to deliver an intranet that works. In cases, social software may be used for a given use case (e.g. project management) or it may serve as the backbone for the intranet as well.
November 19, 2010 · Blog1554 · Posted by Jordan Frank
In my role as an emergineer, I talk a lot about best practices and how they can be leveraged in a given customer deployment. One practice that works in any sphere from email to social software and journalism is to write a good headline.
At the Traction User Group meeting in October, Jon Udell talked, in part, about Heds, Deks and Ledes (words used to mean Heads, Decks, and Leads but intentionally mis-spelled so they are not mistaken for content in a news room). He followed the conference, intentionally or not, with a blog post of the same title: Heds, Deks and Ledes.
Jon says: "We're all publishers now in one way or another. None of us can predict the contexts in which what we publish will be found. But if we're careful about writing heads, decks, and leads, we'll improve the odds that it will be found."
He talks through how this applies whether you are writing an email message or a blog post, then really brings it home in a Facebook example where when you post an event "Heds will always be visible to a scan or a search; decks and leads are active in far fewer contexts."
So, his recommendation for posting an event in Facebook is to pack the Hed of an event with the event title, location and date.
Email is a little more forgiving on Search, but when looking at email, we always start by scanning a list of titles (Heds). When scanning its crucial to understand, from a title, if a message is relevant to you and what dates it applies to (if its an event or deadline notice).
In a blog post or wiki page, similar rules apply. You also have to consider that search ranking may be influenced by word order, word proximity and exact matching (all factors in our Attivio Search Module). When writing a title for a wiki page you also have to consider the naming schema for the rest of the wiki. As a result, there may be advantages to being concise in the head, leaving the deck and lead to explain further.
The happy medium, as Jon indicate, depends on where you are publishing, how its viewed and how its searched.
October 15, 2010 · Blog1542 · Posted by Greg Lloyd
TUG 2010 Newport just wrapped up after four busy and enjoyable days. It's hard to express how grateful I am to the customers, partners, friends - and the Traction Software team - who made this such an enjoyable event. First I'd like to thank keynote speakers Jim McGee, Chris Nuzum, Jon Udell as well as customers, friends and partners whose thoughtful talks and enthusiasm made Wednesday's sessions so rewarding.
Jon Udell cheerfully and skillfully moderated Thursday morning's Observable Workshop in an unconference spirit when I asked for the benefit of his advice and experience with no advance notice - thank you Jon!
Thanks to Jordan Frank, Kellen Roach and everyone on Traction Software's exceptional team for making every training, product and developer session sing, and for their consistent dedication to make every customer happy and successful. Special thanks to Chris Nuzum, Andy Keller, Dave Shepperton, and Roger Fujii for the leadership, hard work, dedication and talent that brought TeamPage 5.0 to customers earlier this year, and for the awesome new task and project management capabilities they demonstrated at TUG which we'll announce at E2.0 Santa Clara this November.
September 4, 2010 · Blog1521 · Posted by Greg Lloyd
A few days ago the Enterprise 2.0 Blog published Venkatesh Rao's excellent post The Real Reasons Enterprise Search is Broken. When he hears ironic jokes comparing search on the public Web versus internal enterprise search, Venkatesh notes: "People move on because they seem to think that this is incompetence at work. Search is soo 1.0 right? It's been solved and we're just fumbling the execution, right?" He says: "I have reached a radical conclusion: broken search is the problem, but fixing search is not the solution. Search breaks behind the firewall for social, not technical reasons...Let's start with the blindingly obvious, and then draw some weird conclusions." I think they are perceptive conclusions based on sound analysis, and agree with most, but come at the problem from a different angle.
I strongly agree with Venkatesh's main conclusion: "The fundamental social and information flow assumptions of “search” need to be deconstructed and reconstructed for the enterprise. Local/silo search within single sites/assets is fine. Enterprise-wide search in its naive form is a terrible idea."
I agree that flat and dumb enterprise-wide search is broken for the reasons he points out. The principles that make relevance ranked search work well on the public Web fail miserably in the link-poor, (relatively) small scale, cc spammed, siloed and obscurely hidden environment behind the firewall in most companies.
I agree that "Web 1.0" technology can't address problems of redundant attachments, email hairballs, point-to-point back channel communication that's not even indexed, let alone officialese used to send timed and coded signals the clear! [ I think Venkatesh just outed enterprise steganography. Cool! ]
A few years ago I wrote a note based on similar customer disappointment with enterprise search versus what they saw on the public Web and came to conclusion that the Web 2.0 / Enterprise 2.0 layer over the Web 1.0 layer offers hope for technology-based improvement:
1) Make business context manifest for discovery and search: This means the ability to create spaces that frame natural business context.
A space defines a context for documents, blog posts, wiki pages, status, what we now call activity stream items and more. A space can also carry permission to see or use content within that space - or know that the space exists.
For example a space "Board of Directors" or "Medical Records" may have more restrictive access that a space "Engineering". Although there are good reasons for making spaces as transparent to as many people as possible, a client facing space in a law firm would need to have permission limited to that client and members of the firm - reliably excluding other clients.
Likewise a space in which private medical issues are analyzed and discussed would need to be more private than most other spaces, but provides a perfectly transparent named context for search, faceted navigation and discovery, tagging, activity stream aggregation, or automatic notification - for those with appropriate permission.
A space provides context and can carry permissions, both of which are important for discovery, tagging, navigation, search, and cross-boundary discussions spanning as many spaces as an individual has permission to see (see Borders, Spaces and Places).
2) Searching across business systems is not the major problem. Enterprise search engines such as Attivio do a great job searching across multiple enterprise business systems. An MRP system, Accounting system, CAD/CAE repository may be a "silo", but it's a silo with a well defined purpose that functions like a "bounding space" by providing context that an enterprise search engine can map and use.
For example, searching for a part number might return hits in MRP, Accounting, and CAD/CAE design databases. These different sources can be modeled as facets, which makes it pretty easy to choose from among MRP, Accounting or CAD/CAE hits when you enter a part number depending on content: Are your interested in manufacturing, accounting, or design related part information?
In my opinion, the real problem pops up when you have one, two or a myriad of generic Content Management Systems or email repositories that are used as general purpose buckets where data and documents are dumped:
Without a bit of context (think of the Ark at the end of Raiders of the Lost Ark)
Without hope of making stored content discoverable and linkable.
With redundant copies of email conversations and attachments scattered over tens, hundreds or thousands of email accounts and email servers
I don't know a technical solution that disentagles this mess once it has been created. The context was never recorded or was destroyed when it was stored.
Doing a content search for "Acme Briefing" and finding thousands of hits in redundant copies of different versions of the same .ppt attached to email that has been cc:'d and re:'d to death for months is very discouraging.
Intelligent indexing of context as well as content in an Enterprise 2.0 system such as Traction TeamPage solves the nasty problem of correlating messy human details that people rely on beyond the neatly ordered world of functionally siloed business systems. I realize "Neatly ordered" business systems is a relative. A part number is a lot less ambiguous than "a really big contract problem with important customer" when you're trying to discover something.
The answer to a messily human search for "what's the contract problem" is likely to be found in the Enterprise 2.0 record of work, conversation, tagging and tracking by finding either the answer or people who know the answer (and who are now a click away)
I believe that the transactions and content in functionally siloed business systems should be observable and addressable using standard Web protocols (with appropriate identity and security to allow transparent linking). It would also be best to avoid creating separate social silos that act as walled gardens embedded within each business system, see Intertwingled Work.
3) Make "who links to what and who talks to whom about what" indexable for search and discovery. Indexing author, date, space and other metadata as well as content associated with links and attachments adds valuable context for facet content navigation, discovery and search.
When Mr. Dithers shouts: "Bumstead! Where are we on the Acme Account?", the most timely, frequently discussed and contextually relevant version of Dagwood's slide set could pop closer to the top of the result list, along with the cloud of tags and people who have touched or talked about that account (see Why Enterprise Search Sucks).
4) Be clear what you mean by Enterprise Search.No technology or search engine will be able to find its way through the twisty maze of social relationships and pathological behavior that people can use to hide information that they want to keep private and off the record. The only exception is the technology proposed by Prof Germain Gervais in his Green Chameleon video.
What if you really want the inside scoop on what's happening with the Acme Account?
4a) Use the social network. Find someone in the know and ask them. Enterprise social networking can be a lifesaver when the big barrier is finding something which wants to be widely know in the company but is hidden by an infrastructure that sucks. If what you want to know is the unofficial word (often the truth), find people in the know who are part of a network of trust. If you're been in the military, you'd ask a trusted Sergent or Chief who's well connected in the NCO network.
4b) Hire a private detective. It take human intelligence and experience to find something that doesn't want to be widely known in the company (even if it should be widely known by policy). You could also become a whistle blower and get professional investigators on the case if the issue is really serious.
4c) Find a better place to work. If your just plain frustrated with an inability to find what you need to get your job done and feel happy about it, rise to a position of power and fix it, or find a job in an organization that's not so damaged.
Abstract: Most large organizations face huge challenges in staying aligned, knowing when and how to collaborate, and capturing knowledge for future use. Traction TeamPage has allowed a large virtual team at Alcoa Fastening Systems to implement principles of “Observable Work” – which for us means making visible and transparent the normally arcane processes of Information Technology management. Implementation of observable work practices has increased alignment, collaboration, and knowledge capture in the organization. Topics discussed include:
• What is Observable Work and why is it important? • Overview of techniques used to manage the flow of information. • Examination of a successful multi-country ERP project managed with these tools and techniques. • Areas of improvement and where we go from here.
Tuesday July 6, 2010: As promised, John Tropea posted a comprehensive analysis and synthesis on observable work and Adaptive Case Management (and much more) titled: Have we been doing Enterprise 2.0 in reverse : Socialising processes and Adaptive Case Management It's a great post that's long for a very good reason: John pulls together many themes with well-sourced references and quotes [ another apology to the easily distracted ]. I won't use this comment to summarize all of the points I find interesting and valuable - there's a lot to come back to! I'll will try to summarize one theme John develops that seems directly relevant to Intertwingled Work.
1) Adaptive Case Management is a data rather than process centric way of looking at how people deal with situations centered around a particular problem, issue, or case. It's intended to support people who need to make decisions that depend on complex and unpredictable circumstances associated with the case that require judgment and knowledge work rather than application of a deterministic process. Think of a doctor treating a patient.
2) Observable work can be thought of as an object of Adaptive Case Management, focusing discovery, analysis, requests for advice or assistance and recording of outcomes on the work itself. This centers collaboration on the case (or work object) rather than trying to create a fixed set of business rules or a rigidly repeatable transactional process where none exists. John quotesKen Swenson:
" ... Because the process is emergent, you have to model the process using something that people can read, add to, and manipulate readily while they are doing other things. With knowledge work, it is not the case that you have a dedicated business analyst to work and get the process model just right; instead the actual case worker needs to do it on the fly."
3) Connecting collaboration to the object of observable work rather than a formal business process lines up very well with what Jordan Frank calls Emergineering! or Social Process Reengineering. Jordan describes the difference between Social and Business Process reengineering as the difference between orchestrating a unique response to the circumstances of a case, versus a futile attempt to capture a response as a rigid business process. Jordan quotes a customers' experience:
"... She was a master of what Paula Thornton recently coined as B2.0: Orchestrated Improvisation. Peggy understood the piece parts of what her orchestra members do in their daily work life, understood the process context in which they worked, and, like a good conductor, was able to lead them, like any good conductor, to play together to the symphonic challenge of the day - which was sure to be ever changing but followed certain patterns and basic structures. Whether the technology was new-fangled or old didn't matter - the key was her ability to figure out What, How and Why. Then she could explain the new process (loosely described as a set of interleaved intelligence communities) and how people could use the technology to do their jobs better."
Summary: The idea of connecting collaboration to observable work is at the heart of what Doug Engelbart has taught for decades. One of the most important lessons I draw from Doug's work is that to support effective collaboration, work needs to be both observable and addressable. That seems to be a necessary condition to support Adaptive Case Management using software.Addressable Work might be a better term for what I've tried to discuss in Intertwingled Work - but Ted Nelson deserves a shout out too!
That's a bunch of links! But I include them for a reason.[ For anyone who finds the presence of inline links distracting, see Apology to the Easily Distracted, below. ]
This modest trail is not only observable - it's spread over about a dozen posts on eight unrelated blog servers using unrelated software, loosely coupled by conversations, links and hash tags observable in the Web commons known as Twitter. The only things that connect this trail are links, search, syndicated feeds and serendipity. In the words of Ted Nelson this is an intertwingled trail - although not very deeply intertwingled, and not that easy to follow.
That brings three points to mind:
1) The fact that "intertwingle" is an amusing word can obscure an important idea I believe Ted Nelson is a Casandra-like inventor blessed and cursed with a rapier wit and the ability to invent concepts and coin terms that stick deeply in peoples minds.Hypertext one of the terms Ted coined and concepts he invented - working independently from Doug Engelbart at about the same time - inspired by the work of Vannevar Bush.
One of Ted's mantras: "EVERYTHING IS DEEPLY INTERTWINGLED. In an important sense there are no "subjects" at all; there is only all knowledge, since the cross-connections among the myriad topics of this world simply cannot be divided up neatly." Ted Nelson, Computer Lib / Dream Machines, 1974
Although I think it's useful to believe in the existence of subjects, in the past, conversations could only be intertwingled across paper memos, faxes, written reports and email. Until the advent of the Web it wasn't possible to intertwingle conversations, networks, analysis and work in near-real time and global scale. Now that's trivial and essentially free with basic Web access.
2) The Web does what it's intended to do, so long as content is addressable and findable.The trail on observable work isn't stored in one specific place - but with a little effort it's possible to follow the flow and join the conversation.
The fact that blog posts and comments are created and served by different content server systems is irrelevant, so long as the content is addressable using basic Web standards. How the different servers store the addressed content internally is likewise irrelevant so long as they deliver the content using Web content standards.
The fact that you don't need a single common place to contain all trails is an advantage of the Web, not a disadvantage. It makes finding and linking harder, but the creation and association of trails infinitely easier than trying to force the world into a common "Observable Work" space you create in Lotus Notes, forum, Wave or whatever.
The Web succeeds succeeds by making it possible for anyone anywhere to create a trail which others can find, follow and join using nothing more than their own Web browser, Web search layered over the basic Web, and a place like Twitter (one of many places where anyone can easily create visible, Web indexed trails).
The Web doesn't guarantee that you'll be aware of conversations on observable work going on in other trails unless you search or stumble upon a link which leads you connect the two. I don't follow discussions on LinkedIn, but might be alerted to something interesting there by someone I follow in a commons like Twitter where I do participate.
The fact that everything posted publicly on Web is potentially observable doesn't lead mean you have to deal with Too Much Information shoved in your face - or into your email box.
You choose who and what to follow, augmented by Web search and your ability to jump in and join or forget about and a trail at any time - although you might hold on to a link so it's easy to find the trail again if you change your mind.
3) Business context makes intertwingled work easier to create, discover and use.Unlike the public Web, work in a private or public organization has a purpose and context that can make intertwingled work easier to discover and talk about. Work and discussion in an organization generally take place in the context of broad business activities like sales, product development, research, finance or administration, and the finer grain of a particular case or transaction. Context in an enterprise can be represented as a place where work and conversation happens, with reliable privacy aware search, tagging, linking, comments, status updates and activity streams.
I believe the important point is supporting business context - not business process in the sense of transactional workflow or automated systems. I believe that functionally specialized transactional systems in an organization will likely remain silos of structured information - but market forces will drive vendors to make their content addressable using simple Web standards and services - with consistent authentication and visibility based on context dependent business rules.
These functionally specialized systems will also signal their status using social computing standards that are now starting to take shape. This will push routine reporting and dealing with exceptions from transactional systems into the "social" places where people can stay informed, recognize issues and exceptions and decide what to do. In an ideal world, transactional systems would provide authenticated access to Web addressable content or analysis, signals based on routing activity or exceptions, Web sensible control interfaces - and not a much more. Most human access would be handled on the Web rather than transactional processing side. I believe the Web has become a valid, scalable and secure alternative to proprietary stacks for integrating most enterprise software at the user experience level.
Much of what a sociologist would call "social" behavior when talking about Enterprise 2.0 would naturally center on the sociology of work: how people communicate and interact with others while dealing with questions, issues, exceptions, suggestions and the messy stuff that routine transactional systems can't handle, along with interpersonal relationships that develop in a specific context or as member of an extended enterprise (including customers, suppliers, consultants and external as well as internal stakeholders).
On top of relationships based well-established patterns of work and conversation - Andrew McAfee's strong ties - enterprise social software opens the door to discovering people and groups who most folk in a large organization would never meet face to face.
This offers the same opportunities for serendipitous discovery we see on the public Web, but with privacy in context which enables open discussion and shared goals and purpose that are part of what Peter Drucker calls the purpose of an organization: "The purpose of an organization is to enable ordinary humans beings to do extraordinary things."
Much of what's challenging about using "observable work" principles can be addressed by examples at top, middle and grassroots levels of an organization. What's needed is a willingness to tolerate and encourage observable work in the small under local control, and leadership to make it an enterprise norm.
As Paula Thornton says: "For as much as people want to make Enterprise 2.0 about technologies, then I’m willing to concede this: Enterprise 2.0 is the means by which to achieve Work 2.0 to deliver Business 2.0."
To be continued Jim, Brian, John, Mary, Jack, Paula, Mark, Gordon, Rawn, Jose, JP, Tom, Deb and the rest of the World - over to you. The best way to follow the evolution of the Observable Work trail is Twitter's #OWork tag. All of the participant's seem to use Twitter as a commons linking posts that either directly respond to the Observable Work conversation, or are related in some interesting way, such as Tom Peter's Strategy: Space Matters ("who sits next to whom in your office can make a huge difference"), JP Rangaswami's Musing about learning by doing, Deb Lavoy's Common Operating Picture - share facts, debate possibilities, John Tropea's link to Keith Swanson's excellent slide set, and John's soon-to-be-published post on Adaptive Case Management.
Unfortunately, neither Twitter nor Google's hash tag search seems complete and reliable. So far as I can tell not all Tweets mentioning are found by either service. There's room for improvement on the public Web as well as the Enterprise 2.0 domain.
Apology to the Easily Distracted: Readers who find embedded links distracting don't have to click while reading the paragraph. I apologize if using the Web to source references that would be unimaginably difficult to provide in any other medium is a distraction. I believe it's not hard to exercise a little discipline when reading, then go back and click any links where you'd like to dive deeper based on your interests. I like to put a small number of See Also links at the bottom of posts where you can dive deeper if you choose.
A Fabric, not a Platform - "I believe what's needed is a fabric for actionable work that lives over traditional cloud platforms and services. Not one big box where all the work gets done, but a thin layer of pages, messages, and trails of activity using identity and a work graph to enable people, bots, and AIs to understand what people want to do, how to find the right objects, and how to do it. Transactional and other work done inside a system of record or a selected service platform will still be done using that platform, linked from the actionable objects in the work graph using standard W3C links or vendor API services."
The Work Graph Model: TeamPage style - "...A work graph consists of the units of work (tasks, ideas, clients, goals, agenda items); information about that work (relevant conversations, files, status, metadata); how it all fits together; and then the people involved with the work (who’s responsible for what? which people need to be kept in the loop?)"
Reinventing the Web - Ted Nelson, Tim Berners-Lee and the evolution of the Web. The Web rightly won versus "better" models by turning permanence into a decentralized economic decision.
Reinventing the Web II - Why isn't the Web a reliable and useful long term store for the links and content people independently create? What can we do to fix that? Who benefits from creating spaces with stable, permanently addressable content? Who pays? What incentives can make Web scale permanent, stable content with reliable bi-directional links and other goodies as common and useful as Web search over the entire flakey, decentralized and wildly successful Web?
"Yes, the real learning is in all the nuances of how we work, not reading a manual, it’s a skill, a capacity to act….it’s experience. I agree that the digital era has allowed for invisible work to happen, but at the same time there is great opportunity for your work to be even more visible than it was in the pre-digital era. Now anyone (not just people involved on the task) can come across your work if you use social tools rather than email and attachments…indeed raw interactions are recorded (searchable).
I also think that the constraints of geography and time in virtual teams, kind of means that you have to pay more importance to working more visibly, but not just in a synchronous way like tele-cons…we can use other social tools for when we aren’t all in the same room…and I’m not talking email." - John Tropea
Here's a summary of Twitter chat using tag #OWork, including tweets that weren't shown using Twitter's built-in search - arghh!
I really like Jim McGee's Jun 23, 2010 blog post Managing the visibility of knowledge work. Jim makes the excellent point that "Invisibility is an accidental and little-recognized characteristic of digital knowledge work." and points back to his 2002 post Knowledge Work as Craft Work to reflect on what Jim calls a "dangerous tension between industrial frameworks and knowledge work as craft work". Early in his 2002 post McGee says:
"The Importance of visibility in craft work Almost by definition, the final product, process, and intermediate stages of craft work are visible. Consider your experiences at a glass blowing workshop or touring a silversmith's workshop. The journey from apprentice to master craftsman depends on the visibility of all aspects of craft work."
Jim continues with an exceptional analysis of what he calls "Knowledge work today as invisible craft":
"One unintended consequence of today's technology environment is to make the process of knowledge work less visible just when we need it to be more so. The end products of knowledge work are already highly refined abstractions; a financial analysis, project plan, consulting report, or article. Today, the evolution from germ of an idea through intermediate representations and false starts to finished product exists, if at all, as a series of morphing digital representations and ephemeral feedback interactions."
"In the pre-industrial era, education and work were: Observable, connected In the post-industrial era, they are: Non-observable, disconnected"
Jon notes that only recently have work processes become network observable, and that this was rare in practice for all but software people. Jon speculates that software folk's norms of feedback, iterative refinement and testable outcomes seem aligned with principles of observable work - and they've become comfortable with networked technology after using the Internet for collaborative development of software and standards over many years.
"A whale ship was my Yale College and my Harvard," said Herman Melville's Ishmael; when it came to learning my job, circulating correspondence was mine. Reading my superiors' letters opened a window into how they conducted business with the world outside; I aped things more experienced colleagues did, and saw how they handled tricky situations; I copied useful addresses into my Rolodex (another antique). I learned who knew what, and that made me better at asking for advice."
I don’t think the notion of visible work or observable work is new: mentoring, apprenticeship, and letting trusted folk watch, learn and use what they see on their own is how law, medicine and other professions were originally taught and refined as collaborative practices - and it's still so today. But as Jim McGee points out, we've lost some of the habits of observable work - to some degree intentionally, to some degree due to blinders added by the tools we've grown comfortable using:
I believe that Enterprise 2.0 principles open the door to making most work observable throughout an enterprise. There are important exceptions to protect the privacy of employee medical, financial and personnel records as well as Board and other discussions which require an exceptional degree of privacy until approved for release or for a longer term. I believe that Enterprise 2.0 collaboration principles apply equally to these more private domains within the enterprise as well as domains open to most employees. With appropriate attention to security and privacy in context, most collaborative work with external stakeholders including clients, customers, suppliers can also be made observable throughout the enterprise while simultaneously respecting privacy among clients, customers, suppliers, and all internal stakeholders.
Jim suggests that principles of observable work apply to the flow of work as well as the work product:
"The right starting point is to simply make the flow of work more visible. I suspect that this is one of the underlying attractions of social networking and micro-blogging. They promise to restore some visibility to digital team work that we lost in the first generation of tools."
I agree with Jim's suggestion. I also suggest that both the flow of work and the collaborative work product recognize privacy in context for authoring, linking, tagging, discussion, content navigation and search that seamlessly connects the worlds of flow and content. This makes it possible for almost everyone in an enterprise to be potentially aware of almost everything their organization is doing - and who knows what - to the benefit of each individual and to the enterprise as a whole.
I believe Traction TeamPage 5.0 is exceptionally well equipped to enable that vision - that's our explicit goal - but please see for yourself.
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."
While building our new GWT-based Proteus skin for Traction TeamPage 5.0, we created some widgets and utilities that we thought other developers would find useful. Most of these are pretty simple, but we hope they save other GWT developers some time. As we factor out code that can be shared with others, we'll add more to this gwt-traction Google community project.
As a TeamPage 5.0 user, you'll notice that this is just a tiny fragment of the functionality we built for Proteus. Most of the great widgets we built, like the PillBox and auto-expanding TextAreas, are dependent on other libraries and other sections of code that are more difficult to share. We'll be working to make more of this code available under the Apache 2.0 license.
The goal for the first release was to share some solutions to issues that most GWT developers encounter, regardless of the kind of application they might be building.
The title of this entry had three goals. First, I wanted to convey and play off the stark differences between Social Process Reengineering and Business Process Reengineering. Second, I wanted to leverage the similarities of SPR and BPR to explain that these two processes can, and need, to co-exist rather than compete. Finally, I wanted to ask the question about whether this is the right term of the process. After dozens of conversations with the best minds in E2.0 this week, I've reconciled to a a more targeted and appropriate term: Emergineering!.
When the emergineer shows up at your door-step, you welcome him or her as someone who can help support a people-centric process which has an underlying structure and requires various types of leadership, but has an unknown outcome.
After you read the rest of this entry on Social Process Reeingineering, please continue on with Emergineering!.
Since introducing the idea of Social Process Reengineering? earlier this week I've socialized it virtually and personally (at E2.0 Boston) with at least a dozen customers, bloggers, analysts and other leading thinkers.
Consensus on the concept was generally positive with a variety of feedback ranging from the matter that the "facebook" approach doesn't just work in the enterprise to the matter that the social, structural and business pain have to be taken into account for successful E2.0 efforts.
Two real gems came out of conversations with John Tropea and Nick Gall.
a shift from emergence to social engineering. Social engineering, not in the IT security sense, or Machiavellian sense, but as a means to better focus and harness intellectual capital for specific business purposes.
Serendipitous is the timing of our respective thoughts on social engineering!! Of greater importance is the message of course. His emphasis on a solution points to the engagement factors which include Motivation, Opportunity and Capability. I'll concur that grasping and addressing these factors and then casting them in context of a use case and E2.0 platform structure for supporting the use case are of cardinal importance for those of us looking to maximize success of a use case and achieve the 10x results needed for success.
Separately, I got in touch with Nick Gall (an enterprise architecture and design thinker at Gartner) after watching Introducing Hybrid Thinking where he opened by saying "all too often we are doing architecture to people rather than architecture for people." He comes back to his foundational point in the conclusion of his talk by showing the T-Shirt pictured here. I think its a brilliant reminder that the goal of IT is for human productivity, with a balance of consideration of standards, rather than the other way around. This sounds like E2.0 (doing architecture for people) vs. E1.0 (doing architecture to people). I reached out to Nick figuring he would be keen on concepts of a Social Architect or Social Process Engineer who may lay foundations where emergent work could achieve best returns. Turns out he prefers the metaphor of a Farmer or Gardener, but the semantic debate will take me too far into the weeds.
At E2.0 he swung by for a tour of TeamPage 5.0 and, in discussion of Social Process Reeingeering, he came up with (and even told me I could claim) a modification: Social Process Emergineering.
I liked it. I called another design thinker, Paula Thornton, to chew on this further and we resolved that the term Emergineering is inherently social (emergent) and inherently considerate of process (engineering).
On Tuesday June 15, 2010 we'll introduce Traction TeamPage Release 5.0 to the world at the Enterprise 2.0 Conference in Boston. TeamPage Release 5.0's new generation Proteus interface technology is fast, simple, and looks great. TeamPage 5.0 leverages this technology to add extensible personal profile pages, Twitter style personal status, group live blog technology, slick and simple Feed summary and more as a natural part of Traction's award winning Enterprise 2.0 platform.
I believe Proteus lives up to the TUG 2009 Proteus mantra: Fast, Simple, Beautiful and hope you agree. I'd like to thank all of the members of the Traction Software Team for imagining, designing and bringing Proteus to life - particularly Andy Keller, Chris Nuzum, Dave Shepperton and Michael Angeles. I'd also like to thank the Traction TeamPage customers who worked closely with us in the conceptual design, mockup, wireframe and preview stages of Proteus, social networking, and project management extensions.
A release candidate for Traction TeamPage 5.0 is available today for download and installation by customers - including users of the free five user TeamPage configuration.
TeamPage 5.0 is also running on Traction Software’s corporate TeamPage server which provides free access (registration required).Register today to join the conversation and download a free copy of Traction TeamPage 5.0.
I hope you all enjoy using TeamPage 5.0 as much as everyone at Traction Software already does. Tell your friends!
As much as I hesitate to introduce this term into social software lingo, I think it's exactly what Enterprises are doing with social software on the road to Enterprise 2.0 - striving for a fundamentally new way to work.
"... the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed." Hammer and Champy (1993)
In reference to BPR, Davenport (1993) says that "Today firms must seek not fractional, but multiplicative levels of improvement – 10x rather than 10%."
We are in the same situation today - but trying to achieve those 10x gains with social systems rather than rigid business workflow systems. 10x, while lofty, has to be the goal to overcome the 9x Email problem discussed by Andrew McAfee (in reference to J. T. Gourville's "Why Consumers Don't Buy: The Psychology of New Product Adoption") and explored further by Greg Lloyd in Enterprise 2.0 - Letting Hypertext out of its Box.
Across whatever set of metrics, Social Software has to give adopters the perception that it's 10x better than the alternative.
"Progress is slower than I’d like. I don’t know why more people aren’t doing more. I think part of it is that we have a huge Intranet, and these tools can be hard to find. I think a lot of our people aren’t even sure they exist.”
McAfee's proposed simple solution is to put a box in every intranet page that urges users to Search, Ask or Share - each with a simple text box for input. In the discussion, McAfee references his own rule to deploy "Tools that deliver something novel - that aren't trying to displace an incumbent - avoid the 9x effect."
I am all for the idea of thinking in simple terms, but the suggestion diverges from answering the challenge to deliver a 10x improvement. The suggestion left me wondering "10x over what?" The Search, Ask, Share idea is on target but an action so simple and attractive as Share is dead on arrival if even a few key stakeholders are 9xd in email.
I am on board with avoiding other incumbent tools (except email which is an open wound advertising the pain resulting from broken processes), but it's vital to realize that any time you move communication to an E2.0 system you are displacing a social process (however it manifests - at the water cooler, in meetings, in email) with a social technology process.
Taking a social process reengineering approach, I take a Druckerian vision which agrees with Greg Lloyd's stance in Enterprise 2.0 Schism:
I believe that although both technology and broad bottom-up participation are necessary to achieve the Drukerian vision, neither element alone is sufficient to achieve the noble end of re-engineering how ordinary people work together to achieve the ends of enterprises they choose to affiliate with.
Its the mix of social and technology that come together to enable, in Drucker's words, "ordinary people to do extraordinary things." But not every technology works and not every social group can simply pick up a tool and run.
If McAfee's E2.0 Evangelist from the tech company is so puzzled about why participation in his E2.0 pilot is not succeeding, he should start considering whether people, teams and departments know their Whats, Hows and Whys:
What process does the system support for my group, team, department, enterprise? What business pain does it alleviate?
How, mechanically speaking, do people operate the technology defined in What to achieve the result?
For the last 8 years I've worked on social software with companies and organizations in every pocket of industry, multiple governments in the US and abroad, and non-profits. One of my favorite adoption stories runs counter to what many E2.0 evangelists would ever expect. The deployment was led by Peggy Walker, a grandmother of many at a very conservative, very large, very old mid-western firm. The initial group of adopters were age 40 to 60 - a far cry from the typical Facebook and MySpace generation which some would perceive as a pre-req for E2.0 adoption.
What made this adoption story work, in days and weeks not years, was Peggy's six-sigma green belt which helped her focus one eye on process and one eye on leadership. She was a master of what Paula Thornton recently coined as B2.0: Orchestrated Improvisation. Peggy understood the piece parts of what her orchestra members do in their daily work life, understood the process context in which they worked, and, like a good conductor, was able to lead them, like any good conductor, to play together to the symphonic challenge of the day - which was sure to be ever changing but followed certain patterns and basic structures. Whether the technology was new-fangled or old didn't matter - the key was her ability to figure out What, How and Why. Then she could explain the new process (loosely described as a set of interleaved intelligence communities) and how people could use the technology to do their jobs better.
Social Process Reengineering is a far cry from Business Process Reengineering which may require fleets of consultants and man-years of programmers to arrive at rigid processes that improve the flow of goods through a supply chain.
Instead, SPR requires that we understand our social processes, find the underlying pain points, understand social artifacts, and figure out how to structure for emergence. Finally, the role of leader is not Evangelist, it's Conductor. The individuals who lead the deployment, who work with teams to pile-on use case after use case, need to coordinate their orchestra of workers to outcomes which are inevitably new and always extraordinary.
In fact SPR's flexible and emergent outcomes offers the perfect balance needed by BPR which seeks rigid rules driven outcomes based on process optimization. BPR aims to produce workflow systems for predictable business problems whereas SPR, using social software as the supporting technology, is the agent that lets us plan for change, face competitive threats and leap onto market opportunities. While SPR and BPR seem like opposing concepts, one may just be the Yin to the other's Yang.
One of our customer stories takes me right to this point. At KUKA Systems, an IT team seeded their social software deployment by deploying a set of spaces where anyone at the firm could post issues pertaining to their enterprise systems. They took a social approach to discussing, tracking and executing on changes to these business critical process systems. This is a perfect example of a social process that, to McAfee's point, is one of the simplest things you can do and, meanwhile, has a meaningful and tangible 10x impact on the way issues are handled as well as on the productivity and performance of business systems. Maybe I've just reached the bigger picture point to which John Tropea was referring when he referred to the KUKA Systems customer story as the "Seminal enterprise 2.0 task-based/process soln."
I talked to two customers yesterday, both who came to me with some questions about attaching and linking to excel files.Easy enough, but before responding with a simple answer I challenged them: Why are you using Excel?
Pages vs. Rows, Tags vs. Columns
In both cases, we agreed on a better approach using page in Traction instead of rows in Excel, and a simple tagging strategy instead of columns in excel.
The first case was a customer at a state level Department of Health. Her Excel sheet had a simple list of 20 rows, each describing part of a work plan. There was very little sort criteria, except perhaps a way to scan and see which requirements are complete. She agreed that there was much more detail behind each row which could better describe it, and sharing status on it would mean continual running commentary that would redirect people to the file which they would have to open and then have to detect visually for changes.
The second case was a customer at a Big Pharma with a system for capturing as many as 3,000 journal abstracts at a time and dropping them into an excel sheet. The system applies some logic to the text to break out columns indicating whether certain drugs and certain categories were mentioned. Then a team of people comb through the sheet to prioritize and score each record. This brings up all kinds of work process issues along with the obvious squint session involved in trying to read abstract text jammed into cells.
In both cases, we quickly figured out a strategy for how to arrange the content in terms of Pages and Tags and how to use search to slice and dice the information to satisfy even the most begrudging team members. What brought the matter home in both cases, though, was giving them a tool which gives the article content the appearance of being in a table. This approach not only surfaces the tagging strategy and makes the process of change-over from excel easier, it is also a powerful way to view the articles and support the work process.
An Example - From Rows in Excel to Pages Instead
By way of illustration, here is an example of a product Feature displayed in its article / page view, then represented in a table which has sortable columns for priority, status and milestone.
Single Page View: Here you can see the article and its tags which include assignment of content type (Feature), status (To Do), priority (P2), and milestone (V2_1).
Section Table View: This view leverages the use of a Section in an article which operates as a filter over just the pages marked To Do AND (Feature OR Bug). You can see that the tags are broken out into columns which can actually be sorted. This offers an immediate sense of how the different kinds of tags work together to form a tagging strategy and help structure an emergent and agile workflow.
Section Table View with Page Expanded: The next issue is how you can actually interact with the table. As noted above, you can sort on the columns but what if you want to see more about an article, change status, change priority or add some commentary. The section table includes a (+) feature that lets you expand any page. This displays all its content and right click actions let you add comments, change tags or even edit the article.
A New Way to Work
As people make the transition from email, word and excel to page based communication in social software platforms like Traction TeamPage, there needs to be a fundamental reset on how we think about information and how to organize it.
I love this example because it offers a clear visualization of:
a) Why breaking big word documents into separate pages offers incredible advantages.
b) How page based workflows are achieved with a simple tagging strategy.
c) Why our concept of the types of structure you can create in Excel or database tools can be met and beat with pages, tags and meta data oriented around the pages.
This is one of many good examples of how social software can fundamentally alter the way we work for the better. Making this kind of transition, from DOC and XLS to Pages is not only fun, it makes a profound impact on productivity and communication.
April 14, 2010 · Blog1299 · Posted by Jordan Frank
Rather than thinking about communication, collaboration and KM software in terms of Return on Investment, isn't the real goal to achieve Return On Information?
ROI (in the context of Return on Investment) comes up routinely on this blog and internet wide but I think considering the issue as one of return on information points to the real value sought.
When you think about return on investment, you think about how time is saved or resources are used better for monetary return. When there is not a direct line between action and revenue, as is often the case with knowledge activities, you work hard to identify marginal time savings through less face to face meetings or to quantify the value of insight and team work.
When thinking about return on information, you can consider tactical benefits:
- How easily can I conduct conversations?
- In what ways can we leverage pages in multiple contexts, rather than lose or simply stash and forget knowledge?
- In what ways can information be followed proactively or retrieved reactively?
- What different ways can pages be rendered into cross-sections which may be useful in a status or issue review?
- If the point of wiki is documentation, how can we view pages on a screen and output them to useful formats like email, word or PDF?
You can also consider strategic benefits:
- What benefits are found by opening up lines of communication from "need to know" to "can know" permission boundaries? These benefits may be expressed in terms of value found by connecting people faster or of value found by involving key people who can offer immeasurable value but may not be directly involved in a given team's communication swirl.
- In what ways does journaling raw information (meeting notes, call notes, ideas, issues) support future analysis and insight?
When I did a simple web search on return on information I found only a few relevant references, including one about enterprise search - which may enhance the ability to discover information but does not offer the tactical scenarios for further enrichment of it. While ROI hasn't been at the top of many RFPs I've received lately, I am hoping future RFPs will focus more on information leverage than typical questions about presence of certain features.
For the second annual Ada Lovelace Day, March 24, 2010 - celebrating women in science and technology - I've chosen to write about Frances E. Allen, IBM Fellow, Turing Award winner and pioneer in the theory and practice of optimizing compilers. I've never had the pleasure of meeting her in person, but I'll take the liberty of calling her Fran, as Dick Merwin and everyone I know called her in their Fran stories.
According to her Wikipedia biography, Fran Allen grew up on a farm in update New York. After earning BSc and MSc degrees in Mathematics she joined IBM in July 1957, deeply in debt and planning to stay only until her school loans were paid. She stayed for a 45-year IBM career that included pioneering research and development in computer languages and compilers, leading her to become the first female IBM Fellow in 1989. She retired from IBM in 2002, won the Augusta Ada Lovelace Award that year from the Association for Women in Computing, and the A.M. Turing Award for 2006 (aka computing's Nobel Prize. Fran used the $100,000 Turing prize, funded by Intel, to start a fund to teach girls in areas of the world where educational opportunities are slim.
I first learned about Fran's work from Dick Merwin, then my boss at the Safeguard System Office, and former Engineering Manager of the IBM Stretch / Harvest computer.Stretch (aka the IBM 7030) was an extraordinarily ambitious and influential project to build the world's fastest computer; it was that - although it fell short of its 'stretch' goal of 100x faster than the IBM 704.
Very early in her career Fran played a crucial role in creating computer languages and compiler optimization techniques for the NSA's HARVEST system (which used Stretch technology) which Fran described in a Nov 2000 interview:
From abstract: " In response to government requests, IBM Research designed a system for a very large data processing application, known as the HARVEST system, including Stretch, which was delivered to the National Security Agency in the early 1960s. The combined Stretch-HARVEST Project created a milieu for developing new technologies, new hardware architectures, and new software to meet the challenges of both systems. One of the guiding principles of the project was to make programming easier by the use of a compiler to generate code automatically from statements in the user's language.
Allen was a member of the ALPHA language design team which created a very high level language featuring, among other things, the ability to create new alphabets beyond the system defined alphabets (e.g. English, decimal, integer, binary) and treat complex, heterogeneous data in high-level statements. In addition to an overview of Stretch-HARVEST, the talk will describe some of the lesser known aspects of the project the people and institutions involved, the political climate, and the shared knowledge, views, and value systems which were part of this interesting project at an interesting time in the history of computing. "
And finally: "Allen, 74, thinks women were more prevalent when she started her career--in 1959, three of her four IBM co-managers were women--than they are today. The shortage of women in IT "is getting worse," she says." Fran Allen 2007 Information Week Interview.
Footnote: I tip my hat to IBM for its early leadership in fair, progressive employment and promotion policies that encouraged recruiting, recognition and promotion of highly qualified women, minorities and others who suffered from discrimination. It was was not only a morally right action, but also a business decision that brought exceptional talent to IBM to the lasting benefit of IBM stockholders.