Use the window below to chat with me (if I'm online ...)
Use the edit nick field above to let me see your name.
cazh1: on Business, Information, and Technology
Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Sunday, November 23, 2008
Dueling Collaboration Portals
I noticed an interesting phenomenon this afternoon; we are experimenting with SharePoint as our internal project management / collaboration portal. A nice platform to choose, because it's popularity is growing, and there are a wide selection of add-on products and development partners ready, willing, and able to help us spend our money to make it even better.
The interesting part is that we are running into other companies who are also working with SharePoint. Specifically, third-party consulting firms that want to work with us on projects - they have (wisely) set up outward-facing portals, so they can effectively connect and collaborate with the paying customers.
Basic training is clearly not an issue here - but after a few hours, some of the (ah, what's that word? oh yes ...) interesting issues come bubbling up ...
Mechanics
What's the protocol here? An internal project could start their own team site, and when the external partner is selected, we'll want to pull them into our collabora-party. Intuitively obvious, but most end-user firms do not regularly extend their intranet / SharePoint servers outside the firewall.
Of course, your external partner may be righteously convinced of the superiority of their portal-enabled project management process - leaving us with a new type of distributed version control problem. Even if we manually keep document libraries in sync - I'm to lazy to deal with dual entry of issues.
Intellectual Property
There may be an IP assumption that needs some clarity. I'd wager both parties have a certain interest in any intellectual property generated during the engagement - will this portal approach make it easier or more difficult to control? And what about the IP represented by the blogs, wikis, discussions, etc. embedded within - will the end of the project deliver an electronic version of all that stuff? You may need to revisit your Master Consulting Agreements.
Interoperability
Data sharing is straightfroward when both organizations are running SharePoint. It becomes problematic if different portal platforms are used. I'm currently not aware of any standard workflow or portal object API - possibly another great opportunity for some entrepreneur - portal synchronization over the Internet?
In Retrospect
None of these general concerns should surprise - it's just the latest iteration of a common problem when dealing with electronic meda. We've all seen engagements where organizations are on different e-mail systems, different versions of MS Office - even different platforms (Macintosh vs Windows, AutoCAD versus Pro-E). I'm sure more are on the way - Dokuwiki vs. MediaWiki? Et 2.0, Brute?
posted by James P. MacLennan at 8:17 PM
| Permalink
|
|
Sunday, November 16, 2008
A Plea for Empathetic Communication
It's impossible to over-communicate
Sounds a bit strong, but if you think through your real-world experiences, this shouldn't surprise anyone. No matter how hard you try, your message will be missed by someone ...
Problem: It's all their fault!
Rely on Web 2.0, and ...
... they won't subscribe to the RSS feed; they don't understand the concept, and have no other information sources that supply feeds
... they won't sign up for the email notifications; that feature is hidden, no one told them about it
... they won't read / browse / search the wiki; there are too many unfinished pages in there, and they don't consider it reliable
... they can't find it using intranet search - they don't know where this feature is located. And even if they did, the results aren't as targeted and "right-on" as Google
So, you try to rely on "first generation" electronic media, but ...
... they didn't read the email, it got lost in their inbox with 100 other new messages today
... they didn't see, therefore, didn't read the attachment
... they did not check their voice mail
Even the "old fasioned way" doesn't always work ...
You are having a face to face conversation, but it's not sinking in because they are checking their Blackberry and thinking about the currently unfolding interruption ...
Solution: Don't jump on the latest communication bandwagon and expect a Silver Bullet - you need to balance flexibility and focus. Different media work for different people, so work to communicate your message using a variety of methods. Of course, if you try to supply all media for all tastes, there won't be enough time to get any real work done. Just know that there is no one best way to get information out to all who need to hear your message - and adjust accordingly.
Problem: It's all your fault!
If you can get them to the electronic content, you still have to create content that actually communicates the correct information. Even if they are capable of subscribing to RSS feeds, or opening a document attachment - if the content does not convey with clarity, they won't catch your drift. Worse yet - if the first one or two samples don't convey anything, they will stop listening to everything.
Solution #1: Practice practice practice - The only way to get better at anything is to keep iterating.
Observation: It's no one's fault - it just is ...
Think about it - don't you receive messages in your inbox that are not clear / difficult to read, or hear about things after the fact or through the grapevine? And don't you glance at your Blackberry during meetings? When you set your phone to vibrate, you avoid distracting others (good!) but you are invariably distracting yourself (who just called ....?)
Fact is, we are all swimming in a sea of information, bombarded with messages from all sides - and we're bombarding others as well. A little humility and a lot of empahty go a long way ...
Get feedback - if your medium or your content are not effective, find out why. Ask your intended audience what works best for them. Majority rules, so if you have a few email holdouts that don't know how to set up an RSS reader, do it for them. Better yet, do it with them - and show them what else they can subscribe to!
Understand what the current corporate / organizational / local culture is, and play to that. You don't have to accept the status quo - but don't tilt at windmills just because wiki is a cool sounding word that would look good on your resume. Introduce change judiciously, and don't let it override the goal at hand - you need to get the status of this project updated!
Never undrestimate the power of face time. When you craft a beautiful, concise, complete summary of the upcoming meeting, and someone still insists on calling you up and talking about it - don't look on this with disdain - it's an opportunity! What was it about the email / document that was incomplete? Was I not clear? Also, since most recipients of project updates are getting them for a reason (stakeholders!!), it's a great opportunity to make sure they get the big picture, understand the original objectives, and are still in support of the initiative.
Projects end, but relationshps go on. It's always good practice to improve your communications and connections with the various technology and business process teams, in and out of the company. These is always a "next time", and next time could be that much easier if you are consistently building your foundation of clarity, openness, completeness.
Effective communication is very difficult, and requires constant work. Realize this, model your actions accordingly, and your impact and influence will grow.
Previously ...
posted by James P. MacLennan at 10:10 PM
| Permalink
|
|
Monday, October 13, 2008
On the Road: Business Travel, Fall 2008
I don't travel a significant amount in my current position, but when I do, it seems to come in chunks. I'm about half way through a round of travel this fall - mostly business, but with some personal travel mixed in. Six cities, three countries in less than four months. Some observations at the halfway point ...
@ the Data Center: The Surreal Life
I'm finishing this entry around 4am - just off my second night in a row on the "late shift" for our Disaster Recovery (DR) exercise [Note: final edits and post mid-day, after I got home]. I've been deep in the "bunker" - a highly secured building with acres of processors, busily working away for any number of companies. No matter what city you are in (even New York!), the traffic is very light between 1 and 3am! And I'm definitely on a different cycle than the majority; yesterday morning, I got off the elevator heading out, and some late-night revelers were stumbling to their rooms after their own "late shift" at the local night spots. No fun like that for the IT folks - gotta keep the brain waves clear, working the checklists.
I've got an easy role; I'm a Shift Manager, just the "manager-in-charge" for the time I'm on. The techs are doing all the heavy lifting, although I get to join in the chorus should we need to escalate anything with our DR hosts. That, and making sure the folks trying to tough it out and go 20+ hours straight are not falling asleep at their consoles. The general preference is to work in the windowless rooms - time goes faster when you can't see the beautiful weather outside. Added bonus - excellent bandwidth to the Internet, which makes it a much better place to work than the hotel room. There are also less distractions (junk daytime TV), and plenty of free food. Alas, that's the other difficult thing to manage when on the road - gotta watch the calories!
Staying Healthy
I'm getting too old to party much on these business trips. Typically, I've got some emails, presentations, or other such stuff to work on during my off time. I can't always count on a decent health club / fitness room - I don't typically stay at the high price joints, but every once in a while I'll luck out and find an elliptical. However, I do like to walk around in the cities that I visit - big or small, always good to get a sense of the place.
Healthy eating is the other big challenge - typically, I'm eating in restaurants, and most American eateries serve up oversize portions that don't help the cause. In general, I find I don't gain much during most trips - never out long enough to develop any seriously bad habits. Unfortunately for this trip, the data center kitchen is always well stocked - has to be, the DR team is working a 24x7 task plan with a ton of stuff to get done in the alloted time. Gotta feed folks well to keep them awake and happy - lots of water, too.
The Crash of 2008, as seen from the Night Shift
It's a strange sensation, working on a weekend project that really destroys your regular schedule - makes following the news of the week a bit disjointed. And what a week - the Dow lost more value than any other week in history. As we wait in the airport, rest in the hotel, or stare at the consoles as tapes load, conversation can wander towards events in the financial and business world - and this adds to the feeling of disconnectedness. It's almost too big to comprehend - but the blogosphere is nicely provides a nuanced, multi-faceted view of the situation, stuff that really makes you think.
Staying Connected
I must say, traveling over the last 2 years has been a joy, now that I'm armed with my Blackberry Pearl and the Internet. I've downloaded the Google Maps application, and while my Pearl doesn't have GPS, it can swag my location by triangulating against cell phone towers. I never get lost, and it's easy to find the right spot to eat, shop, or visit. I was surprised to find out my current location has no pancake houses near the downtown area. Disappointing ... When you can get a decent connection, the Internet lessens that disconnected feeling. These days, I get the majority of my news from websites and blogs, and those stay comfortably constant, no matter where I'm at. Interesting sensation: the environment has changed considerably, but you are just as connected as when you are sitting at home.
Soon, it's time to load up the van and head for the airport - and another round of experimentation with Ping.fm. I've been experimenting off and on with Twitter again, and since I've recently made the leap and started a page on Facebook, I thought I'd also try this multiple status updater. Note that I don't send travelogue updates to LinkedIn - as I've noted before, the "what am I doing" feature doesn't seem to be used much by my network, so I'm sure that the group doesn't care to know when I take off and land. I assume Facebook will become my semi-professional, friends-and-family social network, while LinkedIn stays all business. Twitter? Well, I'm still not sure how relevant that is to me, but I'll ping stuff every once in a while. I do like Ping.fm's ability to quickly toggle parts of your notification list - I will Ping all (including LinkedIn) when I post to this blog, but the "social" stuff doesn't go to the business network.
posted by James P. MacLennan at 12:59 PM
| Permalink
|
|
Tuesday, August 05, 2008
Where to Start? (1 of 2) Process & Procedure
Where to Start? (1 of 2) Process & Procedure
If you need a one-slide, three-bullet, PowerPoint special for describing the basic tactics for "How to Achieve Operational Excellence", try these:
Process and Procedures
Metrics and Measurements
Continuous Improvement
The first two are nicely alliterative, but you might consider substituting Standards and Processes as your lead-off if we're talking about an IT, Finance, or Engineering department.
Now What?
Of course, now you have to generate the details; the "motherhood and apple pie" routine only lasts thru the first meeting. Here's where many organizations discover that it's hard to know where to start. Most people find a blank sheet of paper intimidating; they prefer editing to creating. Also, folks are easily overcome by the volume and complexity of all of the processes they go through every day.
<aside> And for some reason, people seem to gravitate to the most difficult thing to document - "experience". It's like whistling - hard to describe on paper, but easy to demonstrate, with multiple variations and endless complexities. How can I possibly convey my thought processes when I'm debugging a system, triaging a set of problems, or pulling together those first few critical design elements?
Well okay then - let's not think about that right now. We'll talk ourselves out of any process documentation before we even start! <aside>
Start Simple
For every job, there is a recurring list of "stuff" that folks do every day - administrative and busywork tasks that must be done, just to keep the wheels turning. This is the kind of "process" that lends itself very easily to documentation (and, afterwards, automation, but that's another post). It's the little things that you do, unnoticed until you take a vacation day or call in sick. All of a sudden, things stop working or start breaking, because you weren't there to reboot the server first thing in the morning, or clear a cache, or check a job queue for stuck items ...
So a great place for your team to start is to build a ToDo list of repeating tasks. It can be a simple text file, a Word document with nice formatting, a spreadsheet with convenient rows and columns - it really doesn't matter. My personal favorite is the spreadsheet - I use tabs to break up the lists into nice sized chunks ...
Click on the picture for a full-size image!
I've posted a few simple files on my Source Code page:
There are some nice features in the spreadsheets - like color coding for when a task is done (x) or undone (o). Also, the current day, week, month are highlighted automatically.
Collaboration Suggestion
If this idea makes sense, consider skipping the documents / spreadsheets, and create this as a wiki page (or collection of pages). Then, the entire group can add their recurring tasks - and the group will develop a shared master list. This makes it much easier to encourage shared tasks, standardization of work, etc.
Note: Does this structure remind you of 43 Folders and Getting Things Done? Well, that's definitely in the ballpark, but GTD focuses more on personal productivity. Daily / Weekly / Monthly Process Lists add structure and enhance productivity for a group. If you can scale the ideas in David Allen's book to help an entire group - and make it easy for folks to join and leave the group - go for it!
Some Task List Best Practices
Tasks on the lists should be one-liners. "Reboot the Server" or "Empty a Job Queue" are great, but if a single task actually has a series of process steps involved, best make that a separate, more detailed task list
Continuous improvement and ongoing documentation are themselves recurring tasks; consider putting a task to start each day thinking about items that are on your plate today that could/should make this list
The sample spreadsheet features the color-coded "checkmarks" that indicate when a task is complete. If you use a wiki (like TiddlyWiki), there may be plug-ins / extensions (like this one) that allow you to put checkboxes in the wiki itself. Checking the box when something is complete makes you think through each process step-by-step; if you just scan the lines every day, it's easy to slough them off. Plus, it's psychologically satisfying to see all those unchecked items get crossed off the list!
posted by James P. MacLennan at 9:51 PM
| Permalink
|
|
Tuesday, July 22, 2008
Enterprise 2.1: Exiting the Trough of Disillusionment
Enterprise 2.1: Exiting the Trough of Disillusionment
"What will you do with that car if you actually catch it?"
-- what the cat asked the dog (from the Chicago Reader, circa 1989)
So you've gone all "Enterprise 2.0", spinning up a wiki, a blog, and a SharePoint or Drupal server inside your firewall. Now what happens?
The groundswell of interest in "cool tools" brings a wave of users and a burst of feed reader activity - for a few weeks. Before long, however, the organization will get some rush orders, a month-end close, a project deadline, and/or a few vacations on the team ... and the same old excuses begin to weasel their way into the conversations. Folks begin to realize that collaboration and participation is more than reading (I actually have to type something into this thing?). Management styles are tested, and we find out if KM can be pushed on or pulled from the group. The questions start on a familiar note ...
Why?
The classic pushback against documentation; we see no immediate value added. When I'm programming or implementing a system, I'm making stuff happen; when I'm documenting, I'm only creating files that no one reads (and some ambient white noise for my cube neighbors). Of course, if there's only one person in the department that knows how the system works, and if they happen to be out on vacation when a problem arises, it's all hands on deck and a general scramble to figure out how things work. Imagine your consternation when you find out it's a five-minute fix ... if only they had written something down ...
There's also the career flexibility issue; if you're the only one that knows how something works, you'll never be able to move to the next interesting technology - stuck maintaining the Unknown System. Unfortunately, a plea to the value of Future Flexibility doesn't help when you're dealing with someone who likes to maintain control over the Predictable Present. Sooner or later, the benefit of getting rid of their inflexibility far outweighs the cost of reengineering anything ... it's just delayed pain.
Who?
Another classic question (who is supposed to write this stuff? Not Me!), with a contemporary twist ... the collaborative tools allow us to quickly broaden our audience/author pool, including folks outside of IT. In fact, this is a significant difference from fads gone by - non-IT folks are getting exposed to collaborative documents on publicly available, open environments like Wikipedia and Google; it's getting easier to talk to a growing number of people about interacting in a collaborative environment; the team isn't limited to the techies any more!
Which?
A much more important question - which platform should we use to capture this knowledge? When do you use a blog versus a discussion forum? Will I wiki, or should I SharePoint? Choosing IM over eMail is easy, but when should I tweet instead?
If you're working on this question, it's actually a good sign - folks have enough hands-on to understand the good and the bad about a variety of collaboration media. Experience is your best guide here; wiki's are great for fast entry and immediate distribution, but (IMHO) it's difficult to maintain a table of contents, index, or any multi-chapter / multipage chunk of knowledge. At home, I'm building the fifth generation of my home software development environment, and I've already passed over my personal wiki tool as unsatisfactory. Too many processes and interlocking technologies surrounding the servers, development environments, and push-to-production processes. It's much easier to create an actual Administrator's Guide (sample); a formal document with table of contents, chapters, diagrams, even page headers and footers. If I bothered to print it out, it'll look great - but I don't care about the paper. I like the structure that a book gives me - this is broad collection of information about a set of technologies and processes required to do one basic thing.
Each of the different Web 2.0 / KM tools has different strengths and weaknesses - flexible info structures, formatting efficiencies, ease of distribution, and support for collaboration / version control. The light will come on when you understand your biggest problem is collecting the knowledge; presentation, distribution, search, and sharing are covered nicely by the various intranet technologies, but the magic is in the making.
Doom and Gloom - and a Silver Lining
Disruptive technologies come and go, there are no silver bullets, and there's always a problem somewhere. If the environment is user friendly, it won't scale. If users accept the concept, they won't have the time to create content. If you can get all of these budding authors to write prose that is readable, you'll struggle with making it findable.
But hey - we're trying to pull out of this "trough of disillusionment" - so focus on the things that Web 2.0 does well ...
Lowers the technology bar for collaboration - all you need is a browser!
You're not introducing new ideas, you're just making them work within your company
Widens the author pool (and experience base!) for knowledge capture
... and focus your attention on the "next version" (2.1) - practical questions of why? who? which?
posted by James P. MacLennan at 8:46 PM
| Permalink
|
|
Friday, July 11, 2008
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
Finally! Relevant Applications for YouTube and Twitter in the Enterprise!
If you are involved with manufacturing these days, you've no doubt heard about Lean Manufacturing. I'll not go deep into this area here, but one fascinating (for me) aspect is the thread (in some quarters) that ERP and computer systems are the enemy of Lean. On the whole, I don't disagree - process improvement, kanbans, and attacking muda are typically very physical exercises; roaming the floor, walking through the processes (gemba walks), reorganizing workspaces for flow, designing and simplifying standard work - all very visual, participatory efforts that continue over time (constant improvement). Computer systems can just get in the way - metrics and measurements that require extra data entry, or inflexible processes that can't be changed quickly. Much of Lean thinking is common sense and practical, applied thought - computers can over-complicate things!
However, it's that visual, participatory nature of process improvement that can be something of an obstacle, especially if you're working in an extended organization with many locations. It's difficult to gain insight over the assembly process unless you're standing at the bench, twisting and turning to reach for components. It's hard to design practical speed improvements for changeovers if you aren't there handling the tools / molds. And it's often extremely difficult to get the folks who know how to do this stuff (operators) to effectively document their work!
Enter the YouTube idea (which I freely admit is not my own, but the originator has no problem sharing his insights). Travel budgets are shrinking, time away from the shop is tough - but all I need is a 5 minute show-and-tell of a process. Why not a quick video? It's hard to describe how I can easily, visually manage WIP until you stand in that one key spot on the floor, and see how the sight lines to the various workstations all line up perfectly. Why don't I just show you ...
What about Twitter? Well, eMails, blogs, and wikis are really just fancied-up documentation tools, and nobody likes to create documentation. But Twitter can be terse, instant, and informal - not too intimidating for the itinerant author. Heck, sending tweets about ideas and observations on the job would be very much like sending text messages from your cell phone, an increasingly common, popular, and non-threatening task. The bonus, however, is that Twitter traffic can be broadcast (unlike your typical point-to-point text) and saved to a database for further review and insight.
Now, the public YouTube and Twitter sites are probably not the way you want to implement these ideas; much of what we're Tube-ing and Tweet-ing is company confidential. Corporate IT should get involved - either host it yourselves or properly vet a third party site for access & availability, storage & security.
... finally, a chance to walk into the COO's office and say "tweet" with a straight face ...
Interested in more Lean Manufacturing resources? Here's the best of what I've found on the 'net ... check 'em out!
posted by James P. MacLennan at 1:58 PM
| Permalink
|
|
Thursday, June 05, 2008
Opportunistic Insights from the RSS Stream
Opportunistic Insights from the RSS Stream
I've written about using RSS for internal as well as external information sources. This past week, I found a couple of interesting tidbits in my feed reader (behind the firewall) ...
1. Eyes on the Skies: It's that time of year again; oil price volatility will continue if any big storms create problems for refineries in the Gulf - something new to keep an eye on. Never fear - our friends at NOAA kindly put out an RSS feed for storm details - here's the latest graphic on Tropical Storm Arthur, the first of the season. You can keep track of incoming storms using this RSS feed - at the very least, you can be first on your block to know the name of the next storm ...
Some of the responses to this original item pointed out the need to watch the tornado forecast as well put and potential impact on manufacturing plants and/or shipping lanes. There are many different ways that weather can impact the supply chain ...
New applications in the automotive and electronics sectors will drive the growth, although packaging will remain the dominant market. This is despite its share forecast to fall from 65% in 2007 to 40% in 2025.
I took this to mean that packaging is the dominant application of bioplastics, and will remain so. However, the future will see multiple other applications for this material emerge. More applications means larger markets, more innovation in the basic material - which is better for all plastics manufacturers.
3. From Rumor to Fact: One of the project managers recently added (1234) Project XYZ to our PMO database - I found out when the items popped up in my feed reader. That's how it's supposed to work ... Actually, my first reaction to the project was that the description (jpm note: we call it a "mini_charter") was a bit thin. But then I read the first comment, and there's definitely more meat there. At this time, Project XYZ is a multi-headed mystery monster - there are initiatives, teams, projects and such in multiple areas of the company. Clearly, more details to follow - but now we have a validated source of information for at least one of the BU's!
Show vs. Tell
These were my insights for the week, but a number of folks have told me of their own Aha! moments, watching project updates aggregate on their desktop via RSS. I suspect most folks reading this would think little of my "insights" - but that's because we understand how RSS works. To the rest of the world, websites are proactive (I have to go to them) while e-mail inboxes are reactive (the information comes to me). RSS and feed readers turn that paradigm around; once you see it in action, you get it immediately. But it's enough of a phase shift that sometimes explanations and PowerPoints aren't enough. Timely, relevant, in-context examples such as these just click.
posted by James P. MacLennan at 10:42 PM
| Permalink
|
|
Friday, May 09, 2008
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook)
The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook)
The volume of Twitter posts popping up in my feed reader is ticking upward, a phenomenon I find interesting because of something I noted recently on LinkedIn. A few weeks ago, a new feature appeared, enabling me to report what I'm working on - Twitter for the office crowd. Always willing to try some flair, I jumped on the bandwagon, and set up a recurring ToDo for updating my LI-net on the day's focus.
meta-tweet
That lasted less than two weeks - some clear (and discouraging) trends had emerged:
Few people in my network were using this feature, and actively noting what we were doing - and it was primarily folks that I know are active bloggers, engaged in the practice of Web 2.0 (and they, too, have trailed off in their LI-tweets)
For the "regular" folks in my network, it was the one activity (daily or twice daily updates) that generated the most inbound comments. I got multiple e-mails, noting that I must be manufacturing additional hours each day.
Without fail, whenever you mention SAP, data warehousing, or any other specific technology, every product sales rep or consulting firm in your network will call that day and offer a$$istance.
I remain a fan of LinkedIn and social networks in general, but my personal jury is still out with Twitter. I think I want it to succeed, but I'm not sure exactly what it can succeed at. The ideas and innovationsarestillcomingin - one of them is sure to make sense to the wider audience, right? In the mean time, I just don't see it catching on in the mainstream enterprise business environment.
I wonder if the gap is generational, or just a different target audience? Much like the difference between Facebook and LinkedIn - is it GenX vs the Millennials, or is it social network versus professional network? Earlier this week, Bernard Lunn weighed in with his compare and contrast post, and observing that both platforms attempt to add Yet Another Messaging Medium to your current array. Dennis McDonald's reply post backs up the notion that there are different audiences in play here - he also has done a deeper dive in Facebook than I have, so if you want a more qualified and detailed comparison, check out Dennis' work.
Or maybe Hugh MacLeod (gapingvoid) has it pegged ...
insightful
Note that Mr. MacLeod is clearly a Twitter fan - maybe he gets this stuff it better than I ...
posted by James P. MacLennan at 9:55 PM
| Permalink
|
|
Thursday, May 01, 2008
RSS: Underappreciated Web 2.0 in the Enterprise
RSS: Underappreciated Web 2.0 in the Enterprise
We added RSS capabilities to our internal PMO systems this past month, and traffic & content is already building up to become a valuable resource. Some have [correctly] noted that this increased visibility puts a bit more pressure on project managers and team members, to keep updating project blogs with pertinent information. This "time shifting" of communication should develop into the most effective way to let the rest of IT know what is happening in all areas.
There are some very interesting threads and conversations going on ... for example:
One Supply Chain systems team informs us of process improvements in product development - nothing to do with IT, but interesting nonetheless
Another team is putting together ideas that will take some significant IT costs out - that's a very active thread
The SAP application team is debating with the Basis team on the merits of a Unicode upgrade - and onlookers from Supply Chain Planning and Data Warehousing are noting dependencies on Unicode in their platforms
These spontaneous, organic, and very impactful "conversations", between people still experimenting with a new technology, show me real potential for spontaneous innovation and idea sharing. More evidence of the value of [judicious] experimentation with new technology - no silver bullet, but just enough spark to start a few fires.
Interested in learning more about RSS? There's lots of good reading out on the Internet ...
Voyage is an imaginative RSS-feader which displays the latest news in the "gravity area". Interesting navigation - I don't think this is practical for internal use, but it sure looks good!
Newsmap translates news feeds and frequeny to a variable bar graph approach.
Universe DayLife is, well, spacey. Translates the universe of news and connections to stars ...
posted by James P. MacLennan at 7:48 PM
| Permalink
|
|
Tuesday, April 22, 2008
No Silver Bullet for Group Collaboration over Distance?
No Silver Bullet for Group Collaboration over Distance?
Lots of organizations have to deal with the challenge of implementing standard work and best practices over physical distances. With sales offices, distribution centers, and manufacturing locations scattered across the country, what's the best way to get people who know their stuff to collaborate on process improvement - and then take that knowledge back to their home office?
While wrestling with this challenge, one executive I know preemptively ruled out videoconferencing. It's a common suggestion, but the general feeling was that it's just not useful, has never proven itself in practice.
I happened to agree with the idea that videoconferencing wouldn't help in this situation. The team was talking about productivity improvements for an assembly process - workstation layout and hands-on participation was required to effectively work out the wasted movements. However, when defending the No Webcams position to some gadget freaks around the table, we came up with a/the fundamental flaw with remote video: it lacks spontaneity.
Historically, videoconferencing was set up in specific rooms that had to be reserved in advance. For higher quality connections, equipment is expensive, and the expense had to be pre-approved. Advances in digital cameras brought devices mounted on desktops, but this tied you to that specific location. Today's nifty notebooks have built-in cameras, but these can be tough to use with a group of people (crowding around).
Yes it's possible to use videoconferencing, but the physical limitations tend to quickly dim the excitement of all but the most diehard tech fans. In practice, local process improvement teams would just walk over to the workstation in question, skull out the best way to do something, and take a break for some coffee by the time we had the webcam hooked up ...
Lack of spontaneity is probably why the vast majority of PowerPoints are delivered with printed decks, and not overhead projectors. It's still more time efficient to quickly print off a few copies than it is to chase down a projector, lug it and your notebook computer into a conference room, get everything hooked together, and try to remember how to switch to the external monitor. (Hmmm, good thing they added all those cool slide transition effects ...)
Truth is, having paper copies isn't all that bad. Some folks like to take notes on their handouts and file them away for future reference. The medium of communication has its own utility, a sort of residual value that most people understand how to use. The same is true for fancy collaborative technology like videoconferencing. The magic is in the actual conversation, but that can get lost in the struggle to get the technology working before you can actually use it.
Does this mean that collaboration technology is doomed to failure? Of course not - knowledge capture and reuse, and differences in physical location and time zones, are still problems for organizations that rely on the "old way of doing things". You just need to pick your tools judiciously, and build up to the fancy stuff over time.
Wiki's will not work if people don't already have an interest / desire / skill / method for creating documentation. Wikis solve distribution and access problems, but they don't make people suddenly want to write.
Blogs will not work if people don't already have the need to communicate while competing for people's attention. Blogs solve time and distance chanllenges and facilitate simple Q&A, but they don't automagically endow authors with reader empathy.
Collaboration Spaces will not work if people don't already have the need to share documents and edit them within a group. Collaboration Spaces solve version control and tracking hassles, but they don't help groups create impactful documents where none existed before.
We needed to see productivity improvements in component assembly within 60 days, so flying a couple of key people around the country was a small price to pay for the quality of work that we got. We took a small step forward - getting process experts to a different location, to put faces to names, and empathize over common challenges, experience the satisfaction of defining a workable solution - and experience the joy of business travel. Maybe next time we could look into videoconferencing, because interpersonal relationships and understanding of the power of shared best practice has already been established.
