"Ignorance is bliss"- as the saying goes, and it can be expensive when you are talking to snake-oil salesmen of computer systems. The rule is, caveat emptor ("let the buyer beware").
Whenever you plug your laptop or thumb drive into a client's knowledge systems, you may need to be able to share knowledge, which is often in the form of documentation. You need to have common, up-to-date and preferably "open" standards for this. Some organisations have really good knowledge-sharing or workgroup systems. Others do not and just use email to spray copies of documents around. This is a small case-study of one of the latter.
Last year I was working on an assignment for a client whose IT operation was running a moribund, unsupported version of Novell GroupWise (v6.5.6, from 2006), on an IT infrastructure that was based on an archaic operating system (Windows 2000). I was pretty surprised by this as, though the business processes in the organisation were pretty high up the CMM (Capability Maturity Model) - being at Level 3 or higher in some cases - they were using archaic systems to support these processes that I had thought no-one used any more.
I was further surprised when I subsequently learned that there were some areas of the organisation that were running a trial/POC (Proof-of-concept) of a couple of different modern-day workgroup systems that were unrelated to Novell's GroupWise.
The thing is, there's nothing wrong with the latest version of GroupWise. It's very good. GroupWise was a trailblazer in workgroup systems development, and it is still a leader. My surprise arose from my perspective:
(a) I had started managing projects to implement or develop workgroup systems for clients as early as 1985 (e.g., Wang Office and IBM Profs).
(b) My latest such projects were in 2003/4 and in 2006 (SharePoint).
(c) Over the years since 1997, I have become used to using clients' different workgroup systems as a tool for automating and accelerating the administration and communication of knowledge-sharing and for managing projects and business processes across disparate workgroups.
(d) Organisations generally use such tools for solid business reasons. For example, it is presumably not for nothing - i.e., there would be a deliberate business rationale - that HP phased out its three proprietary (own-developed) and very good knowledge-sharing systems, migrating the three knowledge repositories to Microsoft SharePoint by 2006. HP now depends on SharePoint worldwide as the standard, single de facto workgroup environment and knowledge base. Many other organisations have taken a similar approach, using a similarly deliberate rationale.(This is not a plug for Microsoft's SharePoint - which happens to often be a no-brainer for many organisations which tend to use Microsoft products as standard. Not only is SharePoint a very good, robust system, but also it integrates beautifully with existing Microsoft Internet Explorer and Microsoft Office products.)
I could be wrong, of course, but it seems amazing that any organisation would only be trialling such alternative systems - especially when they already actually had an old version of one that would be perfectly OK for most purposes - if only they had bothered to install the latest GroupWise version update and find out.
Some people might say - not me you understand - that the vendors of the alternative workgroup systems who encouraged such a trial without actually pointing this out were acting primarily out of self-interest, on the principle that "There's a sucker born every minute", but I couldn't possibly comment. Nor would I comment as to the susceptibility of IT operations managers who permit/encourage such a time and money-wasting carry-on.
In such cases, you have to ask: "What's to trial or discover that the world has not already been doing for some years now?"
- the point being that you might as well trial the use of the telephone.
Now I know that there is such a thing as being a conservative and risk-averse "late adopter", but this would seem to be ridiculously laggard.
For what it's worth: In my experience of having managed or having being involved in several such trials, they are usually potentially fatally flawed as they do not offer an effective "suck it and see" (an engineering term) pilot approach. That is, they do not enable a real workgroup to actually perform real productive work using the tool, and so discover some of the potential value and constraints of the system - such discovery is usually only forced out by using the system for real pieces of real work and over a long period of time. A pilot is the best way I have yet to come across, to overcome this potential limitation.
For an effective workgroup pilot, the basic and usually common needs are for:
- the development and definition of some kind of strategy for knowledge management and which will be used to guide and evaluate the pilot as it proceeds;
- commitment to a long-term pilot, broken into discrete phases and ending in final, planned implementation;
- the availability of an existing modern-day workgroup system, for use by knowledge workers;
- that system to be stable, maintained in current version, and available for use long-term.
