cazh1 » Knowledge Management

A “New” Critical Requirement for Business Projects (Part 1 of 4)

Jim MacLennan — Fri, 21 May 2010 03:37:58 +0000

As we continue the deep dive into questions like “how do I get information required to run my business?”, we inevitably get to training – more specifically, training on …

… the business / functional domain, and [your company's] self-image and self-awareness in that domain (who we are, and how we talk)
… process & deliverables expected out of recurring and ad hoc information requests (what info, when do you need it, and what format?)
the technical skills required to access & manipulate data and the reporting solutions that currently exist (where is the data and how do I get at it?)
the softer skills – asking better questions, anticipating response and follow up questions, and delivering simple, insightful, elegant answers

Most organizations will jump to #3, and devote a lot of time, energy, experimentation and opinions on building a destination (portal?) that aggregates and presents all of your existing information in a “user friendly” way. Unfortunately, this is perceived to be the easiest item to “solve” (just buy [something] to make our problem go away), but still complicated enough to make people conclude that the lack of such a place (information repository?) is the root cause of their inability to use information effectively.

Ok, there is typically some truth in this idea, but the reality in most businesses is that documentation for / knowledge of your reports and data is simply not captured well. It’s tough to locate, difficult to read, and tries to communicate complex topics with soundbites & PowerPoint slides. This is why most organizations opt for On the Job training (aka Follow That Guy Around); background information about the application, and the training material, are helpful, but they must be delivered to you in person, by the author.

NASA training - tough to follow these guys around. Click for the original ...

Capturing Knowledge

The “magic” is not the environment that brings us the content – it’s the creation (and maintenance) of the content itself. Unfortunately, some organizations don’t equate the value of knowledge capture with the value of the business outcomes the system delivers; a project that delivers sustainable success will deliver both. All too often, creating and maintaining effective training documentation, and capturing knowledge about how things work, is typically not in the team’s job description or “performance objectives”.

A related topic – Super Users. Many organizations have some folks that are “go to” people, who know the systems and interactions intimately – but only because they have a self-motivated and altruistic interest in knowing and sharing. It can be difficult to create such a “community of support” unless the duties, tasks, and knowledge sharing done by the super users is clearly spelled out as part of their MBOs. The result – knowledge transfer is sustained only when there is time available. When the ToDo list gets too big, these folks are actually incented to get the job done quickly, but not necessarily sustainably.

The root issue: we have to teach the organization the value of content, as well as the skills to create effective content. Effective content communicates understanding and gets the reader up to speed and productive without the author / Super User having to be physically there to explain. Unfortunately, when someone wants to pitch in and create this level of documentation, but doesn’t understand how to effectively communicate, they may overcomplicate the process they are trying to “teach”.

Actually, I think it’s a bit of human nature, encouraged by the power of Google. Everyone wants to consume data analytics and visuals, and excellently formatted, easy to read, helpful training and reference material – but no one wants to create these things. Just like everybody wants an expert on the payroll, but no one wants to train / develop / pay for that expertise; everyone wants the ability to call a Super User, but no one wants to be a Super User.

Consciously or not, organizations are hoping people will raise their hand, and out of the goodness of their heart will put in the time and attention to be a Super User or write effective documentation. This is where the internet tricks us – this kind of thing happens out there all the time. So, if you had a fraction of 1% of the folks out their capturing their knowledge, you would have a document that benefits from the thousands of authors. Unfortunately, that doesn’t scale to the typical business – a fraction of one percent of your population probably translates to 1 person in every location (plant, office, warehouse) for your business.

I call this the Law of Large Numbers - yes, I know that’s not strictly correct …

Another unfortunate strike – typically, when someone wants to help but doesn’t understand how to effectively communicate, they may overcomplicate the process they are trying to “teach”. Simply put, the fact that the stuff doesn’t exist, and we don’t have stuff to share, is symptomatic of more fundamental issues …

We don’t know how to build effective material
We reward the act of building, not the effectiveness of the build (by rewarding reuse)

Stay tuned for suggestions for improving things; coming next …

Capturing Knowledge, and Making in ‘Findable’
If the training material is difficult to locate, and people can’t find it to use it – it might as well not exist.

Capturing Knowledge, and Making in ‘Transferable’
If a knowledgeable trainer is not available, and the training material does not “stand on it’s own” – it might as well not exist.

Calculating the Business Benefit of Effective Training Material
So where is the business benefit? How can I go from “obvious idea” to tangible business ROI?

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | 4 comments |
Post tags:

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

A Hierarchy of Information Requirements

Jim MacLennan — Mon, 10 May 2010 02:24:29 +0000

It’s a common problem statement – ‘I don’t have enough information to (run my business unit, manage this process, identify opportunities, etc.)’. The solution designer, when faced with a question like this, starts with a little detective work; the problem is too broadly stated.

This part of the project is itself an example of the problem – “I don’t have enough information to define the problem of “I don’t have enough information to …’ “

And, after a little detective work, we will probably find one or more of the following is correct:

The information [to run my business] does not exist (KM, BB)
The information exists, but I do not know that it exists
- I am unaware that it exists (KM)
- I suspect it exists, but I do not know how to find it (KM)
- I suspect it exists, but I cannot find it (KM, BB)
The information exists, and I know that it exists, but I cannot access it
- I am prevented from access due to security requirements (BB)
- I have no data access tool (BB)
- I have a data access tool, but I do not know where the data source is and how to connect to it (KM)
The information exists, and I know that it exists, and I can access it, but I don’t understand what I am looking at
- I do not know how to use the data access tool (KM)
- I know how to use the data access tool, but I do not understand the domain / terms / concepts (KM, BB)
- I know how to use the data access tool, I understand the domain, but I do not understand the data structures (KM)
- I know how to use the data access tool, I understand the domain, but the metadata is confusing (KM, BB)
The information exists, and I know that it exists, but I don’t want to access it – I want my team to access it, and feed me the results
- My team complains about issues above (?!?)
- My team only answers my questions – they don’t do any proactive analysis (KM)

A wide range of root causes, and as you read down the list, it’s easy to imagine the range of solutions that could be brought to bear. I have broadly classified solutions for these problems in the list:

KM – Knowledge Management: Some level of documentation, training, knowledge capture, and/or knowledge sharing will be involved
BB – Build or Buy: Includes any technical work, like building a custom solutions, buying and implementing packaged software, and/or configuring the software / information store.

I find it interesting that KM is required in almost all (10 of 13) of the solution cases above, and a “technology solution” (aka I need to Build or Buy something) is required less than half of the time (7 of 13). And how about that little People Management issue that sneaks in near the end …

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

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

Location, Location, Location: Terminology Confusion in ERP Projects

Jim MacLennan — Sun, 12 Apr 2009 00:12:00 +0000

Have you ever experienced the clash of terminology that results when supply chains are brought together, due to acquisition or merger? The typical scenario: different groups using multiple terms to describe where product is manufactured at and shipped from; folks use terms like “location”, “plant”, and “site” interchangeably, and confusion can result – are we talking about SAP configuration? Wide-area network architecture? Rollout plans?

To communicate effectively, it helps to clarify things. Here is a starter list of terms from projects I’ve been involved with. Care to add / edit the list?

Generic Terms

A building is what it sounds like – four walls and a roof.
A facility could refer to one or more buildings.
A campus is a generic term for a group of buildings.

Specific Terms – ERP

In SAP, a Plant is a place where materials are produced, or goods and services are provided. A Plant is made up of one or more buildings.
In some Warehouse Management Systems (WMS), a Warehouse refers to a single building. In SAP, a Warehouse is a collection of Storage Areas; a building can contain multiple storage areas, and a warehouse can span multiple buildings.

Specific Terms – WAN

A Site typically designates a point-of-presence to the Wide Area Network (WAN) – a cluster of WAN devices that connects one or more buildings to the network.

Details!

A Chinese proverb states, “Wisdom begins with calling things by their right names.” When bringing companies and cultures together, project managers need to pay special attention to the words; we must be very precise with our language, so everyone understands that we are all talking about the same thing.

Previously …

Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
Need to watch my terminology (August 16, 2005)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Communication is the responsibility of … (August 19, 2007)
The Five Fundamental Rules of Project Management (October 15, 2007)

Technorati Tags: best practice, documentation, Knowledge Management, project management, SAP, supply chain

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

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

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

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

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

The Power of Paper in Business Communications

Jim MacLennan — Thu, 23 Oct 2008 02:14:00 +0000

Confucius was wrong – it is good to live in interesting times …

I’m deep-diving into a number of projects at work, while juggling a sudden surge in business travel (the majority of my tweets of late). All of the work involves significant change – different tools & process, or reworking process “traditions” that have ossified over multiple years and a succession of owners. I have developed a stack of notes on a range of topics – excellent blog fodder regarding requirements gathering, knowledge capture, resistance to change, etc. All will come out in series, but I’ve got to dedicate a few paragraphs to some foundational topics. These may sound mundane, but I beg your patience – they will establish elements of communication style that act as subtle yet powerful levers in capturing the knowledge, improving the process, and making the changes happen.

The first item on my list has it’s roots in Zig Ziglar and classic sales techniques: the Power of Paper. I found an article on edmunds.com that summarizes it nicely (added emphasis is mine)…

There’s something convincing about hard copies. When something is printed out, it lends substantially more validity to a subject than just the spoken word. Nowhere is this more true than when you’re in the heat of battle. That is, when you’re at the dealership negotiating the price for your new set of wheels.
Rather than just tell the salesman … that Edmunds’ [price] is, for example, $26,393, show them a printout from when you priced out the car. That way, they know you’re not just throwing out numbers. And let’s face it, Edmunds is pretty well recognized so it’s not like they won’t know what you’re referring to.

For some reason, paper bestows a tangible authenticity that has an impact on the conversation. Of course, the Edmunds brand-name certainly bestows additional legitimacy of the printout; it’s not enough to print off an e-mail or start up your word processor and type out a few paragraphs on a blank sheet of paper. Give your paper deliverables some look/feel legitimacy by using all those features that Microsoft / Open Office developers so kindly provided – page headers, footers, multiple fonts, etc. As a concrete example, I have posted my “white paper” document template (available here); it has been refined over the years, and has a number of formatting and content details that present clean, professional looking deliverables suitable for any general topic. I’ve also used this as a base for more complex templates – project proposals, requirements gathering, RFPs, and management presentations.

So what are these “details”? Let me lay out a few Concepts for effective documents, and detail how the template makes it real:

Concept 1: Why take two pages if you can fit into one?
In Practice: Page layout details (such as margins set to a half inch all-around). Paragraph styles that add three or six points before each paragraph or section header (instead of extra carriage returns).

Concept 2: Pages are meant to be printed – the physical page is important.
In Practice: Make the left margin 0.75 inches – we’re adding space for a three-hole punch. Print the page number and total pages on each page – when folks are shuffling the stack, they will know when pages are missing. Print the Last Updated date on each page; this serves as an effective version indicator.

Concept 3: Printed and/or electronic deliverables often contain intellectual property or other information that should be kept confidential
In Practice: Many folks place the corporate logo prominently in the header or footer of every page – this is usually a waste of toner and space (we all know what company we work for – why waste the white space? I prefer the watermark – it’s subtler, yet clearly stands every page – a classy touch (see also Concept 4). Plus, the page footer should say something along the lines of “Proprietary and Confidential”. NB: Every page is key – just putting logos and confidentiality notices on a cover page isn’t enough.

Concept 4: It’s better to look good than to be good.
In Practice: Well, you do need good content – but a polished look definitely adds to the air of legitimacy. This is the biggest reason for the header, footer, and watermark on every page. Also, a Table of Contents is recommended for deliverables that have more than three pages. Note that the template sets the TofC at the top of the first page, but doesn’t necessarily add a page break. Who needs the added whitespace?

Concept 5: Templates can facilitate better content while they support a standard (and polished) look.
In Practice: Good document templates are self-documenting – they feature instructions and best-practice notes within the template itself. Templates for specific types of documents (say, RFPs) will contain a table of contents and a “shell” of empty sections that capture the most effective way to present the information. You can also add stock text for common passages; for example, I’ve written about effective outlines for project proposals. The template for these proposals is actually many pages long, because it’s filled with sample text, such as a list of common project risks or assumptions.

Of course I’m always looking for ways to improve my templates – so any feedback is welcome!

Previously …

Communicating Complex Technical Concepts (March 21, 2005)
Writing like a fiend (August 27, 2005)
Quality requirements for technical documentation are lower than user documentation (April 3, 2006)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Documentation Redux – a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)

Technorati Tags: best practice, documentation, hands on, Knowledge 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