cazh1 » Blog

KM Overcomplicates: Heisenberg Impact on a VBA Quickie

Jim MacLennan — Sun, 08 Feb 2009 18:08:00 +0000

Got a simple request from one of the folks in Operations; we’re sending out Excel spreadsheets for some quick data gathering, might we do a little basic input validation before they send in garbage that needs to be scrubbed? This person is very sharp, knows a decent bit about what is possible, and this is definitely not something that is worth a major project engagement; “throwaway technology”, a particular fave of mine.

His request was simple – just want to make sure folks enter data into one or two required columns. I’ve done plenty of Excel VBA, and had figured out a simple approach while we were talking (it’s all in the Before_Save() event, naturally), but I couldn’t really tell him how to do it – he’d never programmed VBA before. However, I do have some rather large projects coming this year, and this person’s group will be very important in making timely decisions, implementing change – so I figured that a little lagniappe here would pay big dividends down the road.

Of course, I knew there would be some I couldn’t get all of his requirements right away – I’ve done many similar things in the past, and could anticipate a number of requests down the road. So, a few minutes of Q&A, and I got a decent set of requirements for future flexibility that, if I do a little extra coding now, I could make much simpler in the future.

you may want to jump to the bottom of this post for the lessons learned … gets a bit tedious here …

“Teaching Event” Explodes Scope

Of course, I didn’t want to become the maintainer of another shadow system, so I need to keep this simple. And, I really think there is a lot of potential in quick-and-dirty Excel automation that would do great things for many companies – if more folks knew how to do it. So, I resolved to make the code as modular and self-documenting as I could; I will publish a generic version of the spreadsheet on my code page, so it might be useful Out There as well.

Then again, I have written before about the difficulties of documentation, and I fully appreciate the fact that knowledge capture, while always valuable exercise, adds a lot of overhead – time and complexity, and required concentration. So, I thought I could compound the complexity even more by journaling the programming exercise “real time”, to get some measurements on how much of an impact “good” tech documentation can add. So, I’m composing this blog entry “real time”, to capture a little data.

And, because I just can’t seem to leave complex enough alone, I’ll leave my Twitter client [current fave: TweetDeck] up, and do a little play by play for the Twitterverse as well. Not that I expect much feedback, it’s Saturday evening; had a nice steak dinner with the family, hopefully I’ll stay up through the end of the experiment.

Time Line – Saturday

8:55 pm
He gets a Bright Idea, and starts the blog entry.

9:15 pm
The KM preamble (above) is done, start opening windows. Before I get going, I’ll have four apps open: Excel and the Excel VBA editor, plus a Google Doc (this entry) and Tweetdeck.

I did grab a sample of the spreadsheet to be sent out, with the various columns, header rows already defined, so that’s a nice start.

9:18 pm
Fractal nature of KM – had an idea to #hash tag all the tweets together, so had to go retroactively tag first tweet. Maybe I can code soon …

9:20 pm
Proof of concept / flow was just a message box in the BeforeSave event. Now, I’m off stealing code from old stuff – processing row/column arrays with somewhat predictable locations and dimensions. I need to make what are basically simple loops 99.99% driven with variables, no hard coding. This is the fundamental way to deliver flexibility.

I also will assume future applications that will have multiple tabs with a different data input table in each tab – so will need to build a master loop that runs thru all the tabs.

9:25 pm
Coding finally starts, with a search thru old ssheets. 2-3 more windows opened up. I’m commenting the code while I’m writing it, so the coding time isn’t just raw coding

9:50pm
All stolen code, but built basic structure to process multiple sheets, handle errors at dropout at the end. I think folks might read this source code and get intimidated by VBA – hmmm, might not be helping things. Ah well, on we go …

10:00pm
Some actual new code, still mostly cribbed from other projects – but I’m aggressively genericizing. Also, first comment from twitterverse (@faseidl). Will have to Follow commenters later.

10:05pm
Gonna steal some ReDim syntax, rarely do that, always have to reuse

10:15pm
Been coding for 45 minutes since the last debug, never timed it like this before, kinda interesting

10:33pm
Code is flying, flexible error checking loops all built – writing the magic line of code “If blank then error” now. Probably should structure this bit of code to allow for different types of error checks (<, >, limits, etc.)

10:45pm
Aha, basic loop works, but I made a mistake in my assumption of how to control the thing. I need to specify a column that I will assume is always filled – when I see a blank there, I stop checking. I’ll have to write the “end of check” to be a warning “note: I am stopping here …”

11:00pm
Ok, it’s all done, tested, working just fine. Code was about 140 lines, not a lot. Will do final documentation and code clean up tomorrow morning – kinda tired right now.

Time Line – Sunday

9:45am
Ok, back to it – should be able to finish this up right quick, one would think. Some quick math on the time line above: Roughly 40 minutes (32%) of documentation, 85 minutes (68%) of coding. Not really quantifying how much longer the coding took because I was aggressively cloning (speedup), commenting (slowdown), and genericizing (slowdown).

The sheet works fine, but I do have some work left. Need to package it all up for the original requester, so he knows how to change things; also need to genericize the final thing, so I can publish it / share the knowledge. Again, I’m trying to capture the teaching moment opportunity.

First run throuught the code was to add comments / documentation so folks know how to extend it. The target audience ranges from technically savvy, but no VBA experience, to VBA hackers – I think it’s all in how I structure the code.

9:59am
Getting some additional coding in – trying to take out as many opportunities for typos and such as possible. Restructuring the code so I only have to code the name of the tab to be checked once. I’m actually doing a bunch of coding here, trying to make maintenance as easy as possible – I know these aren’t the most elegant methods, but I am growing conscious of how much time this is all taking. Tradeoffs, always tradeoffs.

10:18am
Code cleanup done – but in testing, noted something I forgot to add. Data checking loop ends with first blank in the “check column”, but if that’s a mistake, and there are data rows below, I should give them a chance to see that – so I’ll let them know what I think has just happened. A bit more detail than just a “success” message – again, this is a data quality check based on my experience with similar spreadsheets.

10:31am
Fine, the actual programming request is done. An email to the requester to deliver, but then I need to finish the Distribution part of KM. Note how I am short cutting the knowledge transfer part of this exercise for the requester – in my email, I told him to let me know when I might drop by, to walk him through the editing / changing process.

Lazy? No, actually quite practical. I’ll be walking him thru the process of making changes to VBA, and I’m not about to document that. Just show him how the basic sheet works, and give him hints on how he can read more , make simple changes if/when interested. I also need to make sure he understands this is not something that IT will “officially support” going forward – just a quick-and-dirty bit of macro coding for a friend.

10:37am
Now, I’m carving out the code, prepping a sample ssheet for sharing … to be posted on my code page. Note that I’m doing some “documenting” by generating sample data, including an error!

10:52am
Here’s is the part of KM that really drives tech folks nuts, methinks. It’s “prep for final distribution”, making everything digestible for a broad, unknown, unanticipated audience. Up until now, the total stands at 75 minutes (39%) documentation, 117 minutes (61%) coding – but from this point on, it’s 100% documentation. Remember, if a tree falls in the forest, no one hears the sound; documentation won’t help until the code is all checked in, text is cleaned up to be made readable, and everything is put where it can be indexed and found.

11:00am
Just starting the editing pass on this blog post – typos, prose formatting When I’m documenting on the fly, I’m not trying to make it look and sound pretty, I’m trying to capture the ideas. However, must invest in the look/feel of final product, else folks won’t read it, understand it, or believe it.

12:00 Noon
I’ll stop the timer on the documentation here – this is a ton of work compared to the size of the original. Just starting the editing pass on this blog post – typos, prose formatting. When I’m documenting on the fly, I’m not trying to make it look and sound pretty, I’m trying to capture the ideas. However, must invest in the look/feel of final product, else folks won’t read it, understand it, or believe it.

Lessons Learned

Twitter definitely adds overhead – can’t quantify it easily, and it was also difficult to keep remembering to post status updates there. Might be because it’s still a new tool, I’m just getting used to it, but it’s a different kind of overhead than the blog entry.
There is a chunk of complexity added because I’m flipping between different windows. Two large monitors helps, but KM requires multi-tasking; if your teams can’t actively, effectively juggle four threads at once, you’ll never get good documentation out of them.
Programming for speed? Hardcode, don’t go for flexibility. The coding time was easily double since I was anticipating reuse, etc.
Only the one comment from the Twitterverse while the project was underway – not sure if that was time of day, target audience, or what. Twitter is still opportunisitc, hit or miss communication – hence the interst (I think) in building up follow lists (ings and ers).
Knowledge capture and sharing can be a relationship management and change management exercise as well. The ability to capture things in writing are important, but not everything
Final time stats, rounded off: Coding 120 minutes (60%), Documentation 80 minutes (40%). I can speed up coding with reuse and practice, but I can also speed up documentation with practice! Don’t give up on documentation because it’s going to shave 40% from all of your effort estimates – unless you honestly track all of the lost time spent looking up definitions, requirements, previous art.

KM is not free, but I think the value is only seen retroactively; folks that have gotten burned with lost requirements, or forced to do rework because the framer’s intent was lost – they seem to be the folks skilled at and committed to KM.

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

Dueling Collaboration Portals

Jim MacLennan — Mon, 24 Nov 2008 02:17:00 +0000

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?

Previously …

Strategies for Fee Structures in Consulting Engagements (March 5, 2006)
Strategies for Intellectual Property in Consulting Engagements (May 8, 2006)
Strategies for Risk Sharing in Consulting Engagements (May 12, 2006)
Strategies for Malware in Consulting Engagements (May 28, 2006)
Corporate Web 2.0 is Spreading – Here comes the Blog (May 15, 2007)
What’s the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
Innovation That Matters – Substance Over Style (January 12, 2008)

Technorati Tags: best practice, collaboration, innovation, Knowledge Management, PMO, project management, Web 2.0, wiki,

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

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

No Silver Bullet for Group Collaboration over Distance?

Jim MacLennan — Wed, 23 Apr 2008 03:59:00 +0000

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.

Previously …

Implementing Intranet on Speed: An Uh-Oh Moment (July 31, 2004)
Blogs as Conversation, and Wikis as Diaries – Not Exactly (January 29, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
More on (sic) experience with wikis (January 31, 2007)
Do blogs fit in the enterprise? Specific examples (WIIFMs) … (April 19, 2007)
More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)

Technorati Tags:

best practice,
blog,
collaboration,
innovation,
Knowledge Management,
presentations,
productivity,
Web 2.0,
wiki,

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

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

Success, Failure, and Insights after 12 Months of Internal Web 2.0

Jim MacLennan — Tue, 11 Mar 2008 02:04:00 +0000

Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:

Blogging is Easy …

The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations – all are fully empowered to fix it.

Some find the blog to be an easier way of communicating because of the “immediacy” – a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day – but if you really understand what you can and should be writing about, you’ll probably make multiple entries every day.

… but Empathizing (with the reader) is Difficult

I still get pushback on the blogs – even among the groups that are currently our “best demonstrated practitioners”. These folks are generating a decent amount of participation and content – but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader – a skill that I’m surprised more folks don’t have, because many like to complain about what they don’t know, or should know, or wish they knew.

Always ask yourself, what did I do or learn today that others would find interesting? No, it’s not that the world wants to understand how my day went, or how I’m feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the “beneficial assumption” …

Most people think the same way I do …
… so I will anticipate what I’d like to hear about my organization, my projects, and my meetings …
… and write about that

Self-Policing the Content

What about stuff that [possibly] doesn’t belong in a blog – even though it’s internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to “negative events’; sometimes the specifics aren’t really relevant and don’t add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool … it’s a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.

Of course, we note that content should not be limited to all that is sweetness and light. There’s nothing wrong with fact-based bad news, but there’s a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don’t write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.

Communicating is Still an Art

Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge – most folks can write acceptably, but may feel they can’t write well – they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.

Where Are the Comments?

Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can’t judge themsleves based on numbers and responses that you mgiht see on the Internet – heck, it’s taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | No comment |
Post tags: Blog, Collaboration, Communication, Documentation, Knowledge Management, managing projects, technical communication, Web 2.0, Wiki

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

Butting In to the Conversation: PM Communication Tools

Jim MacLennan — Wed, 27 Feb 2008 04:00:00 +0000

Dennis McDonald and Lee White are conducting an interesting experiment on their blogs, crossposting a conversation about project management and social media. I’ll add my voice, with both input on the topic and observations on the method.

(Topic) The Right Tool for The Job – depends on the Job

The first part of the conversation talks about whether social media could replace classic project management tools, in terms of communicating project status. I agree with Dennis – you can never get rid of gantt charts, project budgets, and stoplight issue lists. It really depends on who the recipient of this information is; most of my project sponsors are busy executives who rose to the top in the era of e-mail and PowerPoints. Communication is uni-directional – you to them. Team members and external consultants, on the other hand, require bi-directional, collaborative tools, and most expect web-based environments accessible in and out of the corporate network, instant messaging for quick status checks, and blogs for general updates.

Truth be told, the most valuable tools in the project manager’s communication kit is typically Ctrl+C and Ctrl+V.

(Topic) The Perfect Tool for The Job in Unlikely – but Opportunity Knocks …

Another one of McDonald’s posts lists features a wish list of features for the perfect collaboration environment. It reads like a feature list for MS SharePoint, and McDonald anticipates the reaction well (I, for one, welcome our new Comment overlord … )

I KNOW that many of these features are already available in off the shelf products. Comments that are thinly disguised sales pitches without a sincere effort to contribute to this discussion will be mercilessly and gleefully deleted.

It must be that time of year – I’ve gotten a number of calls from vendors in the last few weeks, pushing any number of PMO environments that promise to manage my resources and solve all my prioritization woes. In these times of tight IT budgets, capital investment for new software like this rare – the dollars are better spent supporting the business.

However, all is not lost. The collaboration requirements of most PMOs can be delivered quite nicely with a collection of FOSS tools, MS Office automation, and a little ingenuity. Looking for a low risk project to throw at aspiring web 2.0 technicians and Millennials suffering from wanderlust? How about those developers trying to learn what makes effective user interfaces?

Every PMO I’ve ever worked with / built up relied all or in part on locally developed tools; the cobbler’s children can usually hack up something serviceable. And to borrow a phrase from Lee White – most of the skills for project management and collaboration comes from creating the tools, not having the tools.

(Method) Not the Right Tool for the Job

I’m not sure I fully understand the technology that Dennis has used to combine the text from these blogs, as well as everyone’s comments. My first reaction on reviewing the feed was less than positive; like a typical blog feed, it probably puts the most recent entry first – so if you want to follow the conversation, you must jump to the end of the list and page backwards. Of course, once I dove into the content, I got a bit lost. I’m not exactly sure of the order of the items in the feed, but best I can tell, the conversation starts in the middle and then sort of bounces around.

Discussion forum software does better at this task. The start of the conversation appears first; as I move down the page, I can scan the main conversation thread as well as any branches from the comments.

That’s the other challenge with this method of capturing and displaying a conversation. There are a number of interesting comments, but I can’t figure out how to comment on the comment, nor can I figure out how to add another voice to the conversation.

I’ve written about this previously; the best tool for the job depends on the type of collaboration you are trying to initiate …

Use an Announcement to make a statement, inform of an event, where you expect no comments or replies. The flow of information is in one direction only – out from you to the readers of the web page.
Use a Blog to make an observation, deliver a status update – capture a well-formed thought. One or two folks may have question or want to add a follow up, but in general you expect a few comments at most.
Use a Discussion Forum when you are asking a question, making a proposal, or establishing a new standard. Here, we expect a lot of discourse, with threaded conversations and branches and such.
Use a Wiki when you are making a statement / documenting a fact. You should expect refinements, additions, and other edits – but not full-on discussions.

Authors Note: I officially despise ecto at this time. This is the second time that I’ve written this post – spent an hour and a half on it last night, only to have ecto mysteriously delete my work. I’m switching back to w.bloggar for now – gave up on it a long time ago, but it appears to have gone through some pretty extensive improvements.

Previously …

Implementing Intranet on Speed: The Beginning (July 27, 2004)
Communicating Complex Technical Concepts (March 21, 2005)
Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
Blogs as Conversation, and Wikis as Diaries – Not Exactly (January 29, 2006)
Guidelines for Success with your Skunk Works project (June 19, 2006)
Documentation Redux – a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
Corporate Web 2.0 is Spreading – Here comes the Blog (May 15, 2007)
What’s the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
The Right Web2.0 Tool for The Job (July 16, 2007)
Communication is the responsibility of … (August 19, 2007)
Five Simple Rules for Project Names, plus Four Sample Lists (January 7, 2008)
Update on Blogs as PM Tools – Tales from the Front Lines (January 20, 2008)

Technorati Tags:

collaboration,
PMO,
blog,
Project Management,
PowerPoint,
Web 2.0,
tech management

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

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

More Challenges for Applying Web 2.0 inside the Firewall

Jim MacLennan — Tue, 03 Jul 2007 02:49:00 +0000

After my last post … more experiences at work, and observations in the trades and other blogs, regarding Web 2.0 tools for use in business …

Improving Knowledge Capture is Half the Battle

In last week’s Information Week magazine, the story of Procter & Gamble’s push towards collaboration – the tools can meet some resistance. A critical quote: We consistently hear that information posted to the intranet is incremental work. Similarly, in my organization, I have folks continuing to send out eMail project status updates
- and then copying the updates to our project database.

Double work, yes – but is this wrong? Actually, I think it’s required, because teaching the content creators to use new knowledge capture tools is only half the battle. We also have to coach the knowledge consumers that the updates they seek are available elsewhere. So why are we surprised when there is some resistance? You are, in effect adding incremental work; at first blush, it doesn’t matter if the information is easier to use – it’s still a different application than I’m comfortable working with.
Matt Asay has a great post on this concept – hits the nail on the head!

Windley’s post has a great title – Are MBAs Too Dumb to Use RSS? He uses it as a mild perjorative, but there is a nugget of truth here; many folks don’t know about or understand what feedreaders (etc.) can do. Experienced systems implementers know that the pioneers and early adopters are easy converts, but the magic happens when you can connect with the early
majority.

Web 2.0 Technology is Half the Story

Dennis McDonald has a number of recent posts about Corporate IT and Web 2.0 – as if the new technology is the tail wagging this dog. In some ways, I agree with some of these ideas:

Collaboration doesn’t have a chance if corporate IT doesn’t allow it on the network
Corporate IT – especially in public companies – is risk averse, and wants the big vendors
Corporate IT has to be involved, but not necessarily the driver

That last point is key, because you can lead the corporate horse to the Web 2.0 water, but you can’t make them collaborate. It’s a different set of skills – some folks will get it, and some folks will fight it – but I think most folks will stand by, bemused, and watch it all go by, until it becomes a job requirement. That’s not cynical, it’s reality; 500,000 people stood in long lines to get their first-edition iPhones, but most of us stood back and wondered where the cost/benefit really is on stuff like that.

Pick the Best Tool for the Job

More examples at work this week where folks have good stuff to contribute – but where to put it? Is this a blog post, or an FYI / Announcement – or should I start a Discussion? I’m starting to develop some prose to help folks pick the right tool …

A blog is more like a diary, a running commentary – especially suited for status updates on a project. Think like a personal notebook, or a lab journal, that folks can browse and search. Content here should be more around insights, observations.
Announcements – think bulletin board – is this the type of thing you would tack up for all to see, or send out an eMail to All?
A wiki is a searchable reference guide – an online book with many authors, but a single, commonly understood view.

A discussion forum is an electronic conversation – with many voices, but with multiple views.

You can stuff your SharePoint site with all of these great tools, but if you don’t give some sort of guidelines on which one to use – well, don’t be surprised when participation tails off …

Technorati Tags: blog, collaboration, knowledge management, SharePoint, Web 2.0, wiki

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

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

Catching up on Mind Mapping; collaborative tools and some "market research"

Jim MacLennan — Mon, 14 May 2007 02:05:00 +0000

I’ve written about mind-mapping before – definitely a fan of the concept, I’ve used it for project tracking, organizing threads for blog topics, and even planning major multi-project initiatives. Here’s a quick catch-up on some links I’ve been seeing over the past few weeks …

From Vinson, a link to Keldsen’s latest podcast on mind mapping tips from a “master”. Not the highest quality podcast I’ve everheard,
but some interesting insights. He also gave a decent explanation of why the curved lines; it’s all about providing visual variety; straight lines make different mind maps look the same. Sounds like part of the challenge for a mind mapper is to think of the presentation of the overall picture – it’s just as important as the flow of ideas you are mapping.
Many links pointing to Mindmeister,a
collaborative, web-based mind mapping tool. Like previously mentioned bubbl.us, it’s web based and facilitates collaborative brainstorming with others. A nice feature for the experienced mind mapper – it can import from MindManager (commercial)and FreeMind (FOSS).
I like the idea of collaborative mapping, and I certainly like being able to reuse all the work I’ve done in MindManager, but I still like the “fat client” interface – handles navigation, zooming, etc. a bit better. Still, pretty impressive stuff – I may suggest converting to this tool for my international collaboration.
Chuck Frey has conducted a pair of surveys on mind mapping and mind mapping software. Interesting to see how others have been introduced to this concept (found on web sites, referred by friend, replicating a pen and paper process). The older survey (from September 2006) talks about things like why the idea is being held back at work; interesting to note how internal IT continues to take the hit (at times) for stifling innovation.
Also via Vinson (thanks, Jack!!), a nice list of keyboard shortcuts for MindManager. It never ceases to amaze me how much time can be wasted by reaching over for the mouse to do repetitive actions.
From the download squad – news that market-leading MindManager is teeing up version 7.0 – I hope it’s more than just a user interface facelift, to match the Office 2007 look. Mindmanager does have an impressive connection with Office, but I’m curious about any other new features … I can’t find mocuh info yet …

Technorati Tags: knowledge management, mind mapping

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

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

The Joy of Programming, the Challenge of KM

Jim MacLennan — Sun, 06 May 2007 04:26:00 +0000

alternate title – Techs Managing Techs; not Required, but it Helps

This evening, catching up with my RSS feeds, I happened upon this old screencast from Jon Udell, looking over the shoulder as he and Anders Hejlsberg take a look at LINQ, a work-in-process set of extensions
for the .NET framework. Udell captured my curiousity with this description of the session …

You have to be a certain kind of person to enjoy watching Anders run LINQ through its paces, Intellisensing his way through the construction of C# queries against object, SQL and XML data, but I am that kind of person, and I find it utterly hypnotic.

I love listening to Hejlsberg narrate result sets as blah blah blah blah blah, and Udell calling out the power of muscle memory and his triple quoted multi-line literal with percent markers in Python. In the screencast, we see Hejlsberg type and retype, fixing typos and narrating his stream of programming consciousness while we hear the clack of the keys in the background; Udell drops in occasionally to interrupt the stream for a quick explanation. It’s the kind of web video I just
won’t show to my family; they’d get that look of pity in their eyes, as they fight to hold back the derisive jokes …

But seriously, it is an interesting process to observe. I found myself drawing parallels to other programming projects I have in the hopper, and even caught some hints on how Intellisense / autocompletion works (sounds like it could be driven dynamically by a well defined XML schema; hmmm, I could visualize how that could work …).

I found myself thinking about a presentation I gave yesterday, to an application development group on a range of topics, business and technical. One of the sections that generated the most boisterous conversation was one predicated with an admission – this is the toughest topic to discuss with techs. The general message was Knowledge Management, the specific issue was documenting code and configuration changes to production systems. Examples of good and bad brought a healthy give and take discussion that
culminated in a terrifically honest question – why do we have to take such care in documenting these changes? Who does it really benefit?

Approvers (so they don’t have to chase you down for an explanation)
Auditors (so they don’t have fodder for audit findings

… and the most important, the most self-serving, and the best reason …

Authors (so they can remember what they were doing six months later)

The best reason to document is entirely selfish – do it to guarantee your own productivity.

This was something I could attest to, from personal experience. I think I am a very good commenter / documenter, because it has paid off for me in the past. I’m still a coder by training, and I definitely remember when I didn’t document as much. It only takes one …

… bad experience of having to reverse engineer my own code – because the comments just stunk.

… good experience of being able to pick up a piece of code I haven’t looked at in six months and quickly get back into it – because there were well-structured, decent comments in place

It’s the kind of observation, made from experience, that can resonate with technical folks. It’s the same kind of ongoing, hands-on interest in the art of technology that makes screencasts and prose from folks like Udell really interesting, and (I believe) a required part of any tech managers job – balanced, of course, with the business of technology.

I don’t think deep technical experience is required for managing techs – but it certainly helps.

Technorati Tags: knowledge management

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

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

Selfish KM, Web 1.9, and the ‘Death’ of Tagging

Jim MacLennan — Wed, 21 Feb 2007 04:21:00 +0000

In a recent NetworkWorld piece, Gibbs wrote about the tagging meme, and where it apparently sits on the technology life cycle. No new insights
for me there (but possibly fits the CEPP rule for others); I was involved in a number of knowledge management (KM) projects back in my Monsanto days (IAPL) [note to self: too many acronyms, hhh] and
we hit many of the classic walls;

CRM systems that failed because sales reps guard their customer intelligence
Collaboration spaces that failed because corporate and international culture equated “asking for help” with “weakness”
Document management systems that failed because arriving at consensus around a taxonomy is difficult

Ok, well, I guess failure is too harsh in all of those cases – it’s just that the ultimate deliverables got toned down a lot, because we were oversold on the value of things (like ubiquitous tagging) without appreciating the difficulty of implementation (ie. you say poe-tay-toe, I say poe-tah-toe).

Even in those days (mid-90′s), I never really understood why folks got all fired up about keywords for categorizing documents; Google and Yahoo and other online knowledge bases showed that searching for words and phrases was plenty effective. No need to browse tables of keywords looking for articles by category – most of the time, folks were looking for a needle in a haystack and needed
the right water tank.

Besides, MS Office documents have supported document metadata for eons, but few even know it exists (try File, Properties) … how many Word documents have you received (or created!) where the Author was set to “Corporate User”?

I think the fundamental flaw here is the premise that tagging is done for other people’s benefit; my tagged content can be useful and relevant and helpful for you. The truth, however, is that it’s very difficult to control and/or predict how other people receive your message and understand your meaning. Again – why is Search often referred to as the next Killer
App? Because the better engines pull commonalities from the content, and don’t rely solely on tags / categories.

McDonald writes about a personal bookmarking strategy and calls out some of these same ideas – a large chunk of the knowledge gathering and retention work we do is for our benefit, not for sharing. Nielsen has a nice
article that calls out how a small percentage of users on a given website account for most of the activity, while the majority are lurkers, looking for information for themsleves, not sharing. This is not a bad thing or a good thing, it’s just a thing; the foundation behind the Law
of Large Numbers.

So why tag? Well, it’s actually a fairly common productivity device – the manila folder, the cool labeler that all the data center guys like to play with – it’s human nature, we just like to categorize. I’m actually a big fan of tagging, but for very selfish reasons; my tags become useful KM tools for me across all of the various sites, services, and tools that support the idea. “Selfish
KM”, or “Web 1.9″ – a slight step backward from the utopian view, maybe a bit more pragmatic.

I’ve launched into a mini-project to standardize tags for my del.icio.us links, blog content, and other stuff. A real hassle, for some of the reasons Gibbs calls out, especially when it comes to “syntax”; I use TiddlyWiki for my personal wiki, but it can’t handle tags made up of separate words, so I have to allow for CamelCase - ugh.
I will, however, document my cross-platform (sic) tagging standards there, and slowly push them out to my other public and private knowledge bases.

I think the death of tagging has been greatly exaggerated, it’s just moving to a more pragmatic place in our KM toolbox.

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

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