cazh1 » Collaboration

Introducing Collaboration Tools? Three Required Personas for Success

Jim MacLennan — Fri, 18 Nov 2011 03:25:36 +0000

An early SharePoint cert test

When introducing collaboration tools to an organization – creating the corporate intranet, defining project sites in Sharepoint, etc. – there are multiple skills you must master – well, at least get better at. You need to capture the ideas and communicate the data such that your target reader understands what you are trying to convey – but you also have to help them locate it in the first place.

Three personas you’ll need to adopt, three sets of skills to master, if you want your stuff to be relevant and get read …

Librarian – Where to start with a big pile of information that needs to be captured and categorized? Consider the typical technical tome – when browsing at the bookstore, how do you pick the one you will buy? I will select the winner by browsing the table of contents, to see how the subject matter lays out – very important stuff. But how do you end up using it? More often than not, I keep going back to the index, to locate a specific word (topic) and find out where the author has stashed the details. The Librarian should know the vocabulary in the book and the surrounding / related areas of knowledge, and fill the index with the key words and phrases that folks keep coming to the information desk to ask about. Sure, most word processors will automate the pagination tasks, but there is some skill and art in choosing the right words – and making sure the document contains those words in all the right places.

Experienced authors who rely on the index to function as their “local Google” will go back to the text and place key words in all the right places. Savvy intranet content producers will anticipate the searcher’s keywords and make sure they are in the document and/or the metadata.

Marketer – There’s more to it then just anticipating the reader’s needs. It’s not enough to write effective prose – you need to create content that wants to be found. Attack the problem like an SEO expert; learn how the search engine indexes content, and what data and metadata gets scanned. The Marketer will understand the local lingo and style of describing things, and make sure to include those words and that style in the text. Be realistic and humble – the vast majority of the planet does not actually think exactly like you do. Think about how you search for stuff on the internet, but also work hard to observe and learn how other folks find and absorb new information.

Completing the document is not enough – success is only achieved when people are actually reading and understanding the material. And they have to find it before they can read it.

Coach – You can document and publish plenty of material, but unless you get folks to actually change their behavior and use the tools, it will sit their like those big fat binders from long-past meetings, lovingly put together for the big event but now gathering dust on the bookshelf in the corner. The key is to find the opinion leaders, the folks who set the standards for the group – and give them extra attention and detailed, task-oriented coaching to change their behavior. Target the experienced hand, the one that folks like to emulate, possibly the one who can dictate the team’s behavior – and get right on the keyboard with them, helping them learn how to use this stuff.

This approach clearly will not scale to a large, geographically dispersed team; but if you can Coach the team leader(s) – teach the right skills and set the right expectations – the rest will follow.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: coach, Collaboration, collaboration environments, collaboration tools, Documentation, empathy, full text search, Google, intranet, Knowledge Management, librarian, marketer, SharePoint, table of contents, taxonomy, team leader, teams, workgroup

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Quantifying Business Benefit of Collaboration Tools (or, What Is This Meeting Costing Me?)

Jim MacLennan — Mon, 25 Jan 2010 02:13:00 +0000

A cast of thousands ...

This post started off as an excuse to experiment with Google Docs, and this really neat feature I discovered – embedding a spreadsheet in a web page as a sharing method. However, it struck me as a potential way to cost justify the time, effort, and expense of implementing collaboration systems with the Most Cynical Among Us.

We’ve all been in large meetings, with tens of people from the project team, along with the expensive consultants, sitting around a table listening to the project manager read their slides to us. The meetings always get scheduled for a full hour (it’s the default in our calendaring system!), and everyone feels the need to speak, if only to make sure their voice has joined the chorus of agreement.

However, many of the Most Cynical Among Us have observed the large number of people in the room, and asked the question “How much is this meeting costing me?” It’s a worthy exercise to go through … so I whipped up a little spreadsheet model to quantify the hard and soft costs …

It doesn’t take long to play with the model and see the dollars add up; even if you don’t believe in tracking “soft costs”, the amount of time spent in meetings can get really big, really fast.

Are status update meetings inherently a waste of time? Absolutely not – communication is critical, and most organizations typically don’t do enough of it. An exercise like this just puts the potential cost, in time and money, in real terms – and reminds us to focus on maximizing that investment.

Can this meeting be avoided? Collaboration platforms (blogs, intranets, etc.) let us update the team virtually; people can get the information when it’s most convenient for them.

Are we communicating effectively? Sometimes, face to face communication is required and preferred – especially when you need to monitor how the message is being received in real time. Hence the broad focus on effective presentations and impactful communications …

Look at the cost of your last meeting – did you get your money’s worth?

PS: I welcome any suggestions for improvements to the model – to request edit access or to get a copy, send email to jpmacl_docs@cazh1.com

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: business benefits, business value, Collaboration, collaboration systems, cost, Execution, Google, Google Apps, Google Docs, group meetings, Inspiration, meetings, Productivity, project cost, spreadsheet, spreadsheet model, typical group, value, waste of time

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Collaboration “in the Wild”: Some Observations

Jim MacLennan — Sun, 15 Nov 2009 21:11:00 +0000

An Enterprise 2.0 dream scenario: implementing a complex project across multiple sites, in two different time zones, with a large team (well over 100). The team was reasonably savvy with collaboration tools; core team members were quite comfortable with Instant Messaging, and we have been relying on SharePoint for many months. A centralized, coordinated document repository; a single source, very public bugs/issues list – the foundation was in place for some time, so our “go-live weekend” experience was pleasantly predictable.

During this critical time, we had to coordinate with the multitude, and we did that with a highly structured “hour-by-hour plan”, regularly scheduled “all-hands” conference calls, and web-based meeting places so all could review Completed, In Process, and Coming Soon tasks. After a successful weekend, we received plenty of positive feedback, and some interesting suggestions for improvements:

Conference calls were regularly scheduled, and featured tight agendas – which tended to limit individuals’ ability to connect with the right person (until afterward). Since each location had a “war room” where the team gathered for the status calls, some suggested we leave the conference call open 24×7. I wasn’t a big fan of this one, primarily because I’m the guy paying the long-distance bill …
Few on the team are actively using Twitter, but one of the project leads noted that IM was quite popular, and imagined a Tweetdeck-like ability to see instant messages and responses that have gone out previously; “threaded conversations” that could be visible to all, helping collaborative problem-solving and knowledge transfer. I congratulated him on inventing Google Wave …
Like most decent-sized companies, we have a highly structured Process for approving code changes into production – and like most decent-sized projects, we noted a few instances where promotions to resolve problems were delayed (while they worked their way through the Process). Might there be some streamlining opportunities here, since we are working on a high profile project with lots of oversight?

Of course, #3 was a non-starter, but the first two generated some good discussion, Yes, it’s conceivable that we could augment our SharePoint site with a few new extensions or plug-ins to address the first two – but I’m actively working against any changes to our collaboration environments for a very simple reason – we’re not finished with the big project. Phase 2 of 2 is coming in just a few weeks.

Am I being close-minded? Not really, I’m a huge driver of collaboration tools in the company. But, I’m also a realist – and I know two significant factors that argue against change at the time:

Prioritizing “Improvements”: We are implementing ERP and other highly intrusive / foundational systems, and there’s a lot of change that comes along with that. I understand that an organization can only take so much change at once – so why not focus on the stuff that’s bringing real (ie. quantifiable, bottom-line, significant) business value.

New Collaboration Tools need Lead Time & Practice: Eight months ago, sharing files by e-mail and ad-hoc, unstructured meetings were the norm. To be fair, we were working smaller projects with teams of 10-20, and usually in no more than two locations. Over the past few months, as we were teeing up for Big Go-Live #1, we’ve been introducing the newer tools in small bits. For Go-Live Weekend, the team was already familiar with going to SharePoint for status updates, or recording a new Issue in the SharePoint list. The mechanics were old hat, and folks didn’t need to think about it – which was nice, since we need them thinking about their Tasks. If we introduce new collaboration tools with little lead time before the Big Go-Live #2, Tasks will be interrupted with people struggling to remember how to communicate.

In the right setting, collaboration tools can clearly add value – even for the most conservative jaded technology users. However, you can’t introduce something so new and expect people to “get it” in the short term. Better approach is to introduce the new tools early in the process, when there is no pressure. This lets the team build familiarity, understanding, and skills by the time you need to rely on these tools for critical communication.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: agile, Collaboration, collaboration environments, collaboration tools, collaborative problem, Communication, different time zones, ERP, hands on experience, IM, instant message, issue tracking, meetings, MS SharePoint, PMO, Project Management, SAP, Wave

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Technical Debt and the Cost/Benefit of Knowledge Retention

Jim MacLennan — Tue, 28 Jul 2009 02:26:00 +0000

A rather rigorous, Financial-sounding title for a high-concept line of thought …

Thanks to Jeff Atwood at Coding Horror, for calling my attention to this article by Martin Fowler on Technical Debt:

developed by Ward Cunningham

Now, before you write off Cunningham as a techie snob or an academic hold-out for unattainable perfection, listen to this healthy dose of reality …

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

I think most of us have seen this phenomenon before; sometimes it manifests as an open willingness to trade quality as just another feature (as measured by the amount of testing before code is put into production). Documentation is another common sacrifice – too often we accept e-mail summaries or PowerPoint outlines as a reasonable facsimile for knowledge capture.

You’ve probably seen this phenomenon where you work, and not just in your IT organization. Many areas of the business will rationalize over-budgeted schedules by summarizing critical findings in a brief email – or, worse, in a Status Update Meeting. “This is an expensive meeting”, I might quip upon entering the room, seeing the conference table ringed with upper-and middle-managers, each weighing in with their understandings and opinions. Don’t misunderstand me – these are typically very effective conversations, with exactly the right people; the folks that know and live the issues, and fully understand the implications of any process change. But my witty entrée was tragically accurate; the understanding and decisions developed at this meeting are too often lost a few minutes after the meeting ends, ideas with a half-life approximately 10 minutes into the start of the next meeting.

Think of it as a knowledge expense (vs. depreciation, as value is lost rather quickly). The expedience and effectiveness of face-to-face communication, with everyone in the same room hearing the same thing consistently and able to ask questions to validate their understanding, typically does not scale beyond the attendees. It’s like listening to a band vs. buying the album (ah, more poetic than downloading …).

In his article, Atwood continues along the Fowler / Cunningham thought process, discussing the need to budget a certain amount of time to pay down our technical debt by going back and finishing that unfinished work; document the things that you sloughed over, rework the inelegant parts of your database schema re code interfaces that rely us a little bit too much on assumptions.

The same can be said for process design and problem solving sessions – remain aware of your level of knowledge debt and budget time to document your findings. I like to call these chunks of captured knowledge “white papers” – I’ll pause while you admire that stunning originality, but there’s a method to my blandness. Calling these things “white papers” helps folks understand the purpose and value of such a document; reasonably short and idea complete. The sweet spot seems to be two to four pages, well-organized, not too wordy, but clear enough that it remains effective months after the design or process rework sessions took place.

Just remember, organizations do the expedient thing all the time, streamlining meetings and decision-making by going light on the documentation. Every once in while, you’ll pay the cost of rework and rediscovery; as our experience grows, and our patience for such “wasted effort” grows thin, task effort times will increase as we invest a little bit more time in better, clearer documentation.

Previously …

Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle – Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Innovation That Matters – Substance Over Style (January 12, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
Over / Under Communication for Project Managers (June 29, 2009)

Technorati Tags: collaboration, documentation, Knowledge Management,

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Real Business Users and SharePoint

Jim MacLennan — Wed, 15 Jul 2009 03:22:00 +0000

Introducing buzzword-compliant technology like a wiki, or integrated collaboration spaces like SharePoint, will typically go well with a motivated audience like your internal IT department. But if you really want to understand how this stuff works, try it with “real people” – line employees in sales and marketing, operations, and finance.

Sure, you’ve heard complaints from these folks (they have better PCs at home, the SAP/Oracle UI is brutal compared to Amazon and AT&T U-Verse, and why can’t they just connect their new iPhone to the corporate mail server?). Be warned; demanding users are not necessarily technically savvy when it comes to groupware.

Case in point; we are working a rather large project (many months in length, over 200 people throughout the business) using SharePoint as our collaboration space – and learning an awful lot about what we thought we understood about ease-of-use and intuitive user interfaces. Our collaboration space is a basic SharePoint project site, featuring the usual suspects – a Shared Document library, an Issues list, and an Announcements section. Simple right? Well, maybe not …

Documents Check In, but they Don’t Check Out

Just kidding, the actual check-in / check-out mechanism works fine. It’s just very interesting that this basic concept of version control is lost on most end-users.

But let’s start with the document library itself – it looks like a really nice version of File Explorer, but becomes very frustrating to folks when they try basic tasks like drag-and-drop. Yes, we found the simple solution – there is an option to open the folder in Windows Explorer, but since this menu option is buried right above the file list, it’s hard to find – certainly not “intuitively obvious”.

Version control was a difficult thing to explain – thank goodness for the tight integration with Office 2007. We found it easier to show folks how to edit documents with a simple double-click – that works just like their shared folders on the old file server! You can explain the concepts of version control quite easily, but the whole check-in / check-out, keep-a-copy-on-your-local-drive thing just gets too complicated. We did have to deal with the one-time task of checking in a new document after you upload it, but after that, they just open the files directly, and that’s it.

There is one feature of Shared Document libraries that I really like – the ability to add custom attributes to documents that can appear as columns in the view. Makes it easier to sort / select / search on documents, and people “get it” relatively quickly. Just go easy on the version control.

… Here’s a SharePoint Tissue

I think the most powerful and elegant feature of SharePoint is the flexibility you have with basic list management – even with WSS. Truly, this stuff should cover over half of the “fancy” automation tasks that folks are are asking for. However, I’m still surprised / dismayed by the fact that SharePoint doesn’t include a standard graphical indicator – you know, the classic “stoplight” (green is good, yellow warning, red means um, er…). I’ve written about this one before – why can’t I have a simple datatype (vs. putting together a sneaky little script to make it work).

I also have a significant warning / insight about trying to do too much with your Lists. Do you realize that most end-users in a typical SMB have older CRTs? I’ll bet you still have a large number of 15″ CRTs with slightly foggy tubes, on their last legs (but too expensive to change out for all but the executive staff) (ok, and IT too, sorry). In addition – well, let’s just say that I’m not the only one whose eyesight is beginning to fail them; I can’t tell you how often I’ve tried to talk folks into moving their screen resolution higher than 800×600 – but it just doesn’t work.

What’s my point? Before you put too many columns in your Lists, or too many gadgets on your Site, check with the average user to make sure that it looks okay on their Screen. Heck, before you even begin your design, use SMS or a simple script to poll the user community and find out what kind of screen resolutions have been set. Catering to the lowest common denominator is not a cop-out, especially when the point of a collaboration site is to get people to actually participate!

Push vs. Pull Messaging

(Another opinion:) I think most powerful aspect of collaboration sites is the aggregation of all knowledge about a project into a single, searchable repository. When people send project updates or resolve issues / hold discussions over e-mail, all that knowledge is buried and quickly lost inside people’s inboxes. In SharePoint, a typical Announcements web part (yes, I know it’s just another kind of List) is quite practical as a messaging medium, because folks can sign up for e-mail alerts.

Don’t underestimate the attraction of the e-mail. People are used to getting information delivered to them in their inboxes – it’s expected! All I’m saying with my Announcements list is that you have to subscribe to the information and pull it towards yourself (versus expecting me, the project manager, to remember to push it to you – and everybody else that might be interested).

Real-world learning: this concept didn’t take long to grab hold in our project. It makes sense, people understand it relatively quickly.

On The Good Side

Don’t get me wrong, there is lots of good that’s going on. Now that the larger project is getting used to this new collaboration space …

… our issue tracking list gets better every time someone touches it – and now we have consistent consolidated issue lists for all aspects of the project
… we are advancing our state-of-the-art for shared authorship; there is a lot more visibility to who is working on what, and we’re getting more participation than a normal project
… the combination of all these different pieces – shared documents, issues, announcements, and other things – are massively facilitating communication, and it is noticed by the folks on the team

Yes – these collaboration tools will definitely will bring huge value and streamline communications to your project. Just don’t think it’s easy or obvious.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | One comment |
Post tags: Change Management, check in, collaboration environments, collaboration tools, Content Management Systems, dashboard, document management system, enterprise search, groupware, GYR, knowledge transfer, managing change, Microsoft Office SharePoint Server, MS SharePoint, SAP, shared folders, status flags, status indicators, traffic light, version control, WSS

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Wikis in High School

Jim MacLennan — Sun, 03 May 2009 20:17:00 +0000

Last month, Vinson wrote about the use of wikis in school projects, and it reminded me to dust off some notes I took from a conversation with my daughter Sean MacLennan, late last year. It was a history project about World War II, and the class was asked to compose their reports on a wiki. Sean is a pretty good writer, and she likes to write, so I was interested in her thoughts on the wiki as a medium, and the collaborative process …

Since there were so many parts of WWII, the wiki format helped, because you could break it down into categories – chunk up the tasks into parts. Plus, we could create the categories we wanted, under the outline [stubbed out by] the teacher.

There were 24 kids in the class, but this was a project across multiple history classes [4], so we’re talking about 100 authors. All were split into groups of 3-4, each had to do part of the shared paper. Each group had their own subset of the assignment, and built their own mini-wiki – a home page plus 10 pages of “categories” or topics.

We literally started with a blank sheet. The assignment handout had the high-level outline, but we had to key it into the wiki / web site to get things started.

So, much of the lesson was about the mechanics of the new medium.
Q: How did you carve up the assignment?

We used the sidebar to create the sub pages and a table of contents. Everybody got in a workgroup, discussed how to divvy up the categories, and then started to work on their own pages – add the page, then fill it out. We got to give feedback, too – we had to critique each other’s work, but it was more like “ooo, stop, you are adding too much text”. I noticed some competition / peer pressure starting, to add as much as the other people.

We could add pictures, links to other web pages, and references to Wikipedia with a hot link to it.

One challenge I noticed: some were copying and pasting from the web, and adding no value or reading what they were copying (ex “… if you look at the picture below …”). Some were not putting a lot of effort into it, and the others thought this might bring the group’s grade down; we were definitely nervous about it.

“Peer review” extended to looking at other pages in your own group and grading them.

So, participative collaboration is part of the lesson as well – the group dynamic, and the idea that not everyone wants to be an author. She also hit the issue where one person needed additional training, and hands-on assistance with some of the mechanics (ex. how do I make a table?) – yet another form of collaboration, and plus awareness of the need for web 2.0 tools to be easy to use (transparent vs opaque?)

What about grading?

There was no coordination on look/feel of the overall structure – once the groups had their subset, they just did their own thing. However, the grade for the group was partially based on whether or not all the information came across. No bonus for the group grade on style points; one person’s page could include images, maps, even videos, and another page could just be text cribbed from elsewhere. The individuals got points on their content, but the only part of the group grade was simply whether or not the list of categories was covered. There was some part of your grade for content, however – had to include at least one image, table, graphic, etc., and those had to be spread out reasonably well. There was a target list of 10 content add-on elements, and they had to be spread evenly across the group.

So it was a technical learning event – how to build a page and add content (text and other) – but not a qualitative thing (how good was the writing?).

Any last comments?

No, just get this done and go set up the Wii to the internet, so I can Mario Kart with my friends!

Clearly, there is more than one way to collaborate!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | One comment |
Post tags: class, Collaboration, high school, Mario Kart, school projects, Web 2.0, Wiki, Wikipedia, workgroup

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Five Stages of Twitter Relevance

Jim MacLennan — Wed, 22 Apr 2009 03:36:00 +0000

Click for the original

I’m already fielding internal (as well as external) questions about the application of Twitter in a manufacturing company, and I’m developing a reasonably good model, I think – one that will apply to the hard-core, salt-of-the-earth, manufacturing business leader that I’ve worked with at many organizations.

This “maturity model” approach has been used before; back in December of 2008, Bhagarva sketched out the Five Stages of Twitter Acceptance – but that model only helps existing bloggers and social networkers understand this terse little idea spitter. Kind of like explaining OOP to a COBOL developer – I get the general idea of coding (communicating), but you’ve changed some of the basic rules like procedural vs. event handling (short and immediate vs. in depth and permanent).

This doesn’t help explain YACMTTCDFE (Yet Another Communication Method That They Can’t Distinguish From Email) for those still struggling with Web 2.0 and Social Networks. If it doesn’t arrive in their Outlook inbox, I’m still facing an uphill struggle getting them to understand the mechanism, let alone the concept.

However, I’m getting a decent level of results when I draw parallels to concepts that these folks “grew up” with. The level of understanding and acceptance directly correlates to the level of relevance that the Twitterverse might have for their current information sharing needs. They typically ask …

How exactly do I understand Twitter and it’s relevance to my work day?

Pointless: This has absolutely no value add, a complete waste of time – get back to work!
Cute: An interesting and different communication medium, but I gotta get back to work. Maybe over lunch …
Web-Based Texting: Conversations about nothing in particular, but at least you’re starting to connect. Not sure how it is better than IM, but some don’t even use that …
A Cocktail Party (or maybe the corner bar): Twitter is filled with cliques that are easy to eavesdrop / butt in on – a chance to develop your skills and awareness, and engage larger, targeted networks with pointed conversations about specific topics that I deal with every day. But no pressure, we’re just hanging out ..
A Community: Like a trade group, guild, or local Chamber of Commerce, one that requires and rewards participation. At this highest level, Twitter is both a source and a use of awareness, knowledge and understanding; conversations are multi-directional, real business value is being generated.

I can illustrate these levels with examples from my favorite Twitter Search columns in my Tweetdeck (Search:SAP)

Do I really care if the sap is running this spring?
Funny, I get hits when people watch sap-py movies. Oh, those wacky homonyms …
Twitter as a job board – every SAP job listing pops up. Wait, did I just see a trend tweet by?
Hmm, lots of interesting SAP practitioners are talking about live projects and cutting edge programming work …
Interesting conversations pop up when Oracle buys Sun, or SAP announces the latest product enhancements – I can get a near-real time pulse on market sentiment

I’ve piqued their interest, but now they want to know what “real business value” really means. I’ll post on that next time … stay tuned!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: SAP, Social Networks, Tweetdeck, Twitter, Web 2.0

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Field Notes: Video Conferencing for Business Conversations

Jim MacLennan — Sun, 22 Mar 2009 15:52:00 +0000

This past week saw my first experience with video conference calling – something obvious to consider in these tight economic times. Some observations –

I got quick feedback that my original camera position was disconcerting for the others. I had put it off to the side, which made me look “off camera”, almost in profile, while in conversation. As I thought about it, I agreed – because if I was looking at me, it would be weird / annoying. I do not like it when the person I am talking with is not looking me in the eyes.
On that note – when we’re in a conversation, I’m typically looking at a 6” circle around your eyes. When on a business / working video conference, however, I’m looking at a 2 x 2 inch square picture of the speaker – because we all have other windows open, looking at documents / programs under review. It’s feels more like a “talking heads” newscast than a conversation …
… but you have to take the good with the bad. The ability to bring up a spreadsheet or presentation or application on a shared screen is quite powerful – participants can “see what I see”. You just need to understand that this is a multimedia conversation, and not simply a replacement for a phone call.

On the other hand – my family uses Skype to stay connected with our daughter away at college. When we make the call, we’ll flip the video feed to full screen – and since the web cams on our respective laptops are perched right above the screen, our eyes are focused reasonably close to the other person’s face. Simple conversational video calls, without the multitasking overhead, are reasonably effective.

Microphone configuration is also very important; some folks are using headsets, while I use the microphone incorporated in the video camera. I prefer this arrangement; I’m already comfortable with using a speakerphone on normal calls, and prolonged use of an earpiece gets a bit annoying. The key, however, is to get everyone to correctly configure microphone settings. Everyone’s volume was a little different, and it impacted the smooth flow of conversation.
We are using inexpensive web cams, not highfalutin’ conference calling hardware. In this scenario, the system does a reasonably brilliant job of flipping camera control to whoever is speaking. This seems obvious, but I noticed that when I was speaking, your remote view doesn’t bother flipping to your feed – it stays on the last speaker. This can be a tad disconcerting if that person reverts to typical conference call habits, and looks away / does a little multi-tasking.
I also noticed that people were much more cautious, or overly polite, about talking over one another. I assume that as we get used to holding conference calls in this format, we’ll get more comfortable with the interruptions.

Later in the week, I had a long conversation with a colleague in Germany. Here, the video call format is very effective. Typically, I prefer face-to-face conversations to phone calls – you can react when someone’s facial expressions signal a lack of agreement or comprehension. Of course, this is not practical with meine freunde in Deutschland, where language differences exacerbate the situation. The video call solves that problem immediately and effectively – I found myself communicating in face-to-face mode now, with hand gestures (ex. air quotes) and facial expressions indicate agreement, keep the conversation moving along.

Like any bit of technology, reality is not as smooth as the sales pitch makes it out to be, but still a very effective tool, and something that can be experimented with quite inexpensively.

Experimentation leads to experience, leads to effectiveness.

Previously …

International Meetings – Pick a Convenient Time (April 1, 2005)
Challenges when demoing / training / pitching complex systems (May 23, 2005)
eMail on Blackberry Changes Definition of Acceptable eMail (September 19, 2005)
Hand writing recognition – harder than colored bubbles (November 19, 2005)
Waiting outside their office (February 14, 2006)
Catching up on Mind Mapping; collaborative tools and some “market research” (May 13, 2007)
Alternative KM Tools (3 of 3) (September 25, 2007)
Power Outage Follow Up – Observations (March 28, 2008)

Technorati Tags: collaboration, hands on, Knowledge Management, productivity

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Zodiac of Knowledge Capture

Jim MacLennan — Fri, 16 Jan 2009 04:20:00 +0000

The start of a new year gives me a rare chance to measure my knowledge capture output over time. I maintain electronic journals for the various projects I am driving, business units and functional areas I support, and people I work with. This results in a hundred or so separate MS Word documents, with generally the same format – still, it would be quite tedious to take a word count each week to check my outout.

However, at the beginning of the year, I start a new folder and a new set of Word files – which means that after week 1, I have the easiest scenario for figuring out how much data entry for the week. And, since last week was typical, I set out to total up my data entry – starting with tthe personal journal files, but including other media:

Format     Words
=====     ======
MS Word   15,300 in 22 documents
Notes      3,000 in 4 documents
Blogs      3,100 in 6 entries in 4 blogs
MS Excel 500 in 5 spreadsheets
Notepad    500 in 4 text files
Mind Maps    300 in 7 maps
Twitter      900
Power Point 700 in 5 presentations
Wiki         500 in 2 wikis, 2 different dialects
          ——
          24,800 words in 1 week

Hmm, that sounds like a lot – accoprding to this guy, I could / should be writing eight books per year …

But then I though of all of the other formats that I was not counting … texting via phone, IM over eight different accounts (thanks, Pidgin!), emails over four different accounts (and four different clients). And what about the code? That wiki item at the end got me thinking; most wiki syntax is faux-HTML, right? But I’ve also had to do work just this week in HTML, CSS, ASP, SharePoint, VBA, dokuwiki, TiddlyWiki …

This whole exercise conjured a series of images in my mind, avatars for a new Zodiac of Knowledge Capture …

Sisyphus: The never ending task of documentation. At times, my “backlog” gets so big, I just file a big chunk away under Future Projects …

Hercules: Prodigious output should be the expectation, not the exception. The world / your work group is ever-hungry for more structured knowledge, and they don’t want to wait thru the backlog – they want stuff now!

Job: Patience is a must – you will write stuff and get no response for months … but every once in a while, a glimmer of hope. Had a conversation this week with someone who noted my Emotional Intelligence post from 14 months back (!). They had seen a class offering at a local college, and we ended up talking about how applicable the skills are to our jobs.

Mandelbrot: You need to be facile when plotting and navigating many levels of abstraction. The reader needs to absorb slowly, peel the onion one layer at a time … but they better be able to drill to the required level of detail!

Pavlov: Repetition – Don’t be surprised when you have to repeat, repeat, repeat, over and over, until you get folks used to the idea of going to the wiki, searching the portal, reading the manual.

Deming: Constant Improvement must be in your mind all the time. There is always a better way to get an idea across (which relates to …)

Xerox: Imitation is the sincerest form of flattery. Let’s not lose sight of the goal – capture and transfer knowledge . So, if you see a more effective method of communicating – learn from it!

Tufte: Clarity in communication is everything. You might think this one should be Strunk, but Tufte drives for clear and effective communication graphically / pictorially, as well as in the written word.

Muse: Don’t rule out creativity; you are competing in the market of attention, and you need to capture the mind before it’s ready to receive. You also can’t always rely on the Same Old Stuff when capturing knowledge; keep experimenting with different tools, take the best, leave the rest.

Cthulhu (CNZ?): Develop skills at multi-tasking, maintaining many threads at once (or multiple arms). Multi-platform, multi-editor, multi-laungauge, multi-markup, etc.

Heisenburg: Be aware that documenting processes can be like measuring them – you will probably introduce some change. This is “stealth process improvement”, and might even be manifest laziness (it’s easier to document a simplified process …)

This zodiac needs a twelfth sign – any ideas?

Previously …

Heisenburg KM (July 13, 2004)
Communicating Complex Technical Concepts (March 21, 2005)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle – Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
Innovation That Matters – Substance Over Style (January 12, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)

Technorati Tags: design, documentation, hands on, innovation, Knowledge Management,
Web 2.0, wiki,

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Back to the Future: Twitter "microblogging"

Jim MacLennan — Sat, 10 Jan 2009 04:41:00 +0000

“That’s pretty good, Johnny, but that ain’t the way I heerd it. . . .”

I recall when all this “blogging” talk started, way back in 1999 or so (thanks to Hallett for a decent history). The idea was to post thoughts and feelings, observations about technology, society, or whatever – anything from a daily diary to a project notebook. Scoble and others became (in)famous for posting multiple times a day.

Time marches on, and the medium has morphed over the years. Blog post frequency (BPF?) stopped being the measure of success; sites became electronic versions of trade magazines, marketing slicks, talk radio .. along with the occasionally Really Good Blog (couldn’t resist), capturing knowledgable insights or technical tricks.

Then along comes Twitter, which has made little sense to me to date. Well, ok … let’s say my appreciation for the applicability of this site has slowly matured – along with their ability to avoid the Fail Whale. And I’ve seen another recent burst of activity – mini-Twitter apps, breaking news source, alternative interfaces, even metrics for personal validation. When talk turns to monetization and open source competitors appear, I guess you’ve arrived.

I recently happened upon Mr. Tweet, who has helpfully suggested a series of influential tweeters to follow. When Kawasaki and Scoble appeared on the list, it was like a flashback to the old days …

… but this actually got me a bit more enthused. Posting multiple times per day makes a bit more sense when it’s only a brief thought – and Twitter enforces brevity with the 140 character limit.

So, now I’m trying to post more frequently on Twitter during the day, like a blogging old-timer – encouraged, I will admit, by posting into a tweetosphere more amenable to spontaneous connection; a few thoughts during a Sharepoint presentation brought a quick response from a SharePoint guru and author, with more than a few tech details on some of the finer [Share]Points (aiw).

We’ll see how long this lasts …

Previously …

Twitter (March 22, 2007)
New Twitter features starting to make things more relevant (June 3, 2007)
Thoughts During a Power Outage (March 27, 2008)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
Finally! Relevant Applications for YouTube and Twitter in the Enterprise! (July 11, 2008)
Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
On the Road: Business Travel, Fall 2008 (October 13, 2008)

Technorati Tags: blog, Knowledge Management, twitter, Web 2.0,

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License