Monthly Archives: June 2011


My favorite thing about collaborative software and techniques is the ability to quickly assemble and coordinate an ad-hoc cross-functional remotely diffuse team to work on an urgent or important problem.

Imagine a situation at a manufacturer where a production line has gone down due to the failure of a key computer application. A person in IT is notified by a worker on the line. The collaborative software is used to create a document that describes the problem and a high priority is assigned. The IT worker assigns appropriate troubleshooting resources via the software: maybe a techie to check the hardware, someone to check the network connection, someone to investigate the interface between an in-house written entry program and the ERP packaged software provided by an outside vendor (who might also be tapped for input). Notifications and alarms are issued.

All of these people report back or can ask questions via the collaborative software, keeping a centralized record of progress on these steps.

People on the line are granted access to the problem document as needed and are subscribed to all updates as they occur. They can answer or ask questions. Managers can be subscribed so that they can monitor progress and can easily see which parties are involved and whether the crisis is getting the appropriate attention and resources. People who manage relationships with outside stakeholders – perhaps a customer whose shipment may be delayed or a vendor whose product may be faulty, are included. Anyone who needs to be kept in the loop is easily added.

Troubleshooters can address the entire group instead of playing phone tag with individuals and hoping that information is relayed to the correct parties.

Everyone’s roles and behaviors become easier to discern. I’ve found that the people who have a tendency to disrupt meetings and discourage the input of others with sarcasm or bullying tend to monitor themselves better when their comments are self-documented. These controlling tendencies are visible to all and can be confronted and coached if bad behaviors surface here. This makes it easier for the entire team to focus on the problem at hand, minimizing the interpersonal dynamics or conflicts that might occur in a more private setting.

Individuals who hoard knowledge become more apparent as do the knowledge sharers. Stellar performers can be lauded and thanked right there in front of everyone involved.

The entire process is self-documenting and becomes a source of knowledge should a similar problem occur later. The document can become a repository for evidence: a place to attach PDF copies of reports, emails, affected vendor or customer info, notes, links to similar problems, checklists, etc. It becomes a workspace, lab report, and agenda. If further action is needed to prevent a reoccurrence of the problem, the document becomes an invaluable resource. It formalizes problem solving, notification procedure and evidence retention. Problems are less likely to be band-aided and forgotten. It becomes more possible to trace the root cause of secondary problems that sometimes arise due to the unforeseen consequences of a bad ‘fix’ of the original problem.

The entire process is self-documenting and becomes a source of knowledge should a similar problem occur later.

Integrated with best practices from a discipline such as ITIL, this type of collaboration can reduce the number of critical incidents in an organization, allowing everyone a breather from constant firefighting so that the organization can focus on becoming more competitive and effective, rather than focusing on just keeping the lights on.