Dennis McDonald's Web Site

Date of Interview

• Feb. 15, 2006

Folloup Interview

• A followup interview with this respondent was conducted on April 6, 2006. Notes from that interview are located here.
  

Description of Respondent

• Respondent is a senior application engineer in the software licensing division of a 15+-year-old telecommunications services company.
• Previously the company provided services on a domestic service bureau basis only. They have now decided to license their system. This requires development of comprehensive documentation of their system and procedures so the system can be operated by licensees.
• Respondent is in charge of a project to develop such documentation collaboratively with support of wiki technology.

Interview Notes

• The current domestic service center supports four sophisticated product lines.
• Respondent: "Very few people understand more than their specific part of the job."
• Current documentation is very structured but is incomplete.
• Respondent's job role: he regularly serves as an intermediary between business and technical staff and also supports sales staff.  He is experienced in translating between business and engineering and frequently "creates content" to support a variety of corporate functions.
• There are currently no official  internal blogs or external blogs. Management is concerned about "information leakage."
  
• Respondent believes that multiple blogs would be required to provide information support for the existing product line and that, with multiple RSS feeds, it might be difficult to provide a unified view of the system and procedures required to support the current product line.
  
• Respondent is promoting use of a wiki as a "central knowledge collection point" by which potentially hundreds of individuals can contribute their knowledge about product systems and processes.
  
• Asked about the need for hierarchy and structure, respondent  points out problems with the company's current "traditionally structured" document repository that focuses on a strict file-oriented method for storage and retrieval of documentation. "There are too many choke points," he says, and he contrasts this with the decentralized and collaborative model supported by the wiki.
• Respondent admits that, behind the scenes, there still has to be a "system administrator," but he points out the various features of a wiki:
• Collaborative authorship spreads the load beyond a few overworked technical writers.
• Responsibility for documenting system expertise is pushed closer to those with direct knowledge and expertise.
• Wiki has built-in features that facilitate content management and tracking including history, version control, various external logs that can be selectively exposed to authors, users, or administrators -- and XML feeds that can support various publishing and access options.
• We discussed the issues of authority and responsibility. I asked if one of the reasons respondent was comfortable with not being overly structured in his approach to overseeing the organization of the content was because the jobs and responsibilities people will be documenting are already well defined and structured and that this existing structure would carry over to the wiki. "Not necessarily," he said, "We already have a learning organization." He explained that the organization already is receptive and adaptable to taking responsibility like this and that the wiki technology reflected this orientation.
• Respondent agreed there may be issues associated with collaborative/decentralized documentation in highly regulated or safety oriented knowledge repositories -- e.g., aircraft maintenance, pharmaceutical, etc.
• He summarized the advantages of the approach as follows:
• "lots of hands" will be involved.
• The system will support more frequent updating than the current structured documentation approach.
• The database structure underlying the wiki will support generation of multilingual versions of the documentation as required by non-English speaking license customers.

Interviewer comments

• Some of the functionality benefits mentioned by the respondent for using wiki technology to support collaborative documentation refer back to classic concepts of "database publishing" where a common repository of data drives multiple output streams. A major difference is that modern wiki technology is more advanced in how it takes advantage of sophisticated underlying data structures as well as the interactivity and availability of web based systems and standards.
  
• We did not address the social relationship aspect of the current staffing beyond respondent's reference to the company being "... a learning organization." Respondent appears to say that current employees and work groups will decide on their own what needs to be included. Given their current intimate relationship with providing customer support, this makes a great deal of sense -- as long as employees are provided  (and are compensated for) the time to do what is needed.
• We did not address the cost issue at all and whether this system would supplement or replace existing documentation systems. Related ripple effects that bear analysis include impacts on training and support and on the processes by which engineers and customer service and support staff interact.
• Also not discussed was whether the wiki system was viewed as another way to assist the transition of the company into future years when trends in "baby boomer" retirements might impact overall company access to critical knowledge and expertise. This was discussed in a recent podcast by CIO Magazine titled "Beating the Boomer Brain Drain Blues." Social networks established to match up younger and older engineers in other industries are one way to facilitate business transitions impacted by key staff retirements. This "succession management" function could be an important by product of use of collaborative knowledge management technologies such as wikis.