Blog

I've been using the term "knowledge workers" frequently in recent posts, so maybe it's overdue a definition. Here's a recent quote from McKinsey analysts that I find useful:

"The heart of what knowledge workers do on the job is collaborate, which in the broadest terms means they interact to solve problems, serve customers, engage with partners, and nurture new ideas." -- McKinsey report, October 2009

CogniDox is used by companies that make high-tech products - semiconductors, electronics and similar - and so it’s clear that the average user in these companies fits well with this definition.

Over the year, we’ve taken a high level view over an amalgam of many companies that are storing files in a CogniDox repository to see what tools they use when performing their knowledge worker tasks. It’s not a rigorous scientific study by any means, but the results do seem consistent.

What we found is that Microsoft Office Word is still the tool of choice for capturing “what’s important” for these product design companies. For companies with many 10s of 1000s of documents in the repository, Word files were over half of the total stored (56%). The other format that is clearly important is PDF. CogniDox automatically generates PDFs from file formats such as Word and PowerPoint, but even after allowing for these ‘duplicates’ we still saw that PDFs make up over a quarter of the total (26%).

There are pockets of OpenOffice in use, especially among the engineering teams in our sample, but this would be consistent with the market share estimates of OpenOffice.org i.e. 10-20%. In any event, the main application is Writer and it is being used as a straight substitute for Word to serve the same purpose in documentation.

Other Microsoft Office applications came in as follows: Excel (6%), PowerPoint (4%), Project (1%) and Visio (1%). The rest were typically the outputs of specialist teams such as software (zips, tar files, etc) and technical authoring (XML).

Of course quantity isn’t directly correlated with importance. One of those Visio diagrams or Project plans may have taken far more effort and be considered more vital than a bunch of Word files.

This also isn’t a measure of software application usage – I’d expect email clients (Outlook, Thunderbird) and Browsers (IE, Firefox, etc) to figure large in that. This has more to do with the intersection between applications used and file storage.

Note this does not capture the knowledge worker's other modes of collaboration - surveys show the telephone and face-to-face meetings are still the preferred means of collaboration. People love their meetings. I've quoted two other surveys in previous posts that tell us the average time spent on meeting is 1hr 30mins per day, but if you are a Product Manager you could be attending up to 15 meetings per week - at least 3 hours per day of their time.

When meetings are not possible, e-mail and attachments fill the gap across the boundaries of time and location. However, the knowledge workers we analysed would possess in-boxes containing thousands of valuable content files as attachments, if email was the only option.

There wasn’t much evidence of the repository being used for multimedia files – no large image or video libraries. Probably not surprising given the nature of the enterprises and I’d expect different from e.g. a media creative company. Pity, as there’s huge untapped potential for using short (5 min) videos to assist product development – visual bug reports being an example.

There is also potential for Enterprise 2.0 tools in collaboration – but the reality seems to be that we are not using them yet. There’s no reason why that won’t change over time as teams increasingly collaborate using Wikis, micro-blogging and other tools. There may be good reasons to use Facebook for social networking or LinkedIn for business networks, but it has yet to make a case for internal knowledge worker networking.

But it will stay true that a key part of a product developer’s responsibilities is to document the product, and keep a safe record.

And Microsoft Office Word is still their preferred way to do the former.

The concept of a Knowledge Worker has been around for a long time (Drucker, 1959) but it is still a slippery term to define. Sometimes it's synonymous with Information Worker; other times it's a sub-category. It can depend on the company using the term - IBM favours one, Microsoft another. Sometimes it's reserved for a minority who work on unstructured tasks and goals which they achieve through free-form collaboration with others - not to be confused with workers who process information in structured tasks. Sometimes it's the majority, pretty much anybody who uses IT is an information worker.

And they all now work in the "clever" economy.

This slipperiness may be one reason why it's hard to define Knowledge Management applications and to understand fully surveys carried out on the habits of information workers.

There's a survey just out from Forrester that falls into that category. Intriguing and useful in part, but affected by the problem of knowing the makeup of their 2001 respondents.

For example, we learn that Email, word processing, web browsers and spreadsheets are the only applications widely used. But then we're told that while 60% use a word processing application, only 42% create documents. I can't reconcile that statistic with any of the knowledge worker environments I've worked in, so have to assume there is a difference here between information and knowledge workers. Some of us may wish it was true we didn't have to write documents, but have never got that lucky.

The survey does have an interesting graphic on different types of applications and how frequently they are used i.e. hourly, daily, weekly, monthly. Email clients (57%) and web browsers (35%) are the only applications used hourly to a significant degree. There is also an interesting age difference in the use of social networking sites: the 18-29 age group uses these sites extensively during non-work hours, but when they are at work they don't. At work, both they and the 30-43 age group only access these 13% of the time.

The reason for non-use at work may be explained by a different survey. This one, carried out by Robert Half Technology, surveyed 1400 CIOs at US firms. They asked which statement most closely described company policy on visiting social networking sites such as Facebook, MySpace and Twitter. The results were that over half (57%) replied "Prohibited completely" and a further 19% said "Permitted for Business purposes only".  So it is still the case that bigger companies (who would tend to have a CIO role in the first place) are blocking social networking sites.

The decision to block social networking sites isn't necessarily because corporates don't accept their use for collaboration among knowledge workers. It is usually security and data protection that is the cited reason. It's also possible that sites like LinkedIn might be deemed more business-use than say, Facebook, and are allowed. Or, it could be that we are in the transition phase between an old way of working and a new one.

In the meantime, I'm off to update my LinkedIn status and Tweet about this.

There was an interesting survey published just over a week ago - Axios Systems, an IT services management software vendor, commissioned interviews with 1500 IT executives in North America, Europe and Asia.

The headline was that 57% of interviewees felt their IT systems, processes and services were not delivering the value expected of them by their companies.

I was taken with two other points - 67% said that they still had no way of directly measuring the business value of their IT systems in real time, and 63% said that cost reduction would be their #1 driver over the next 12 months. 

"Let's go change what we cannot measure" would seem to be the unfortunate implication. 

However, I'm inclined to see this as an insight into the current state of mind of Enterprise IT groups. Many "go achieve more with a reduced budget" memos have been written in 2009, and the effect on morale must be significant. One problem of measuring quantifiable benefits of enterprise software is that there will be dozens (if not hundreds) of individual applications in use by a company at a given time, and knowing where value was added to the mountains of data is never an easy matter. Subjectively, one knows when an IT application has made something faster, better, easier; but it isn't always easy to see it on the top or bottom line. In this climate, it may be a better idea to put the metrics on hold and follow companies that are exploring the cost reduction promise of open source, cloud computing and virtualization technologies.

A good time to consider the cost of switching from an expensive proprietary solution is when the annual support and maintenance invoice falls due. This is often higher than the Year 1 cost of a commercial open source alternative (and support costs in subsequent years for the alternative will be substantially lower). 

I read a case study recently about a Legal firm moving from an expensive  traditional client/server document management system to open source - a quote that stood out was that it took the project team months to get management approval for the switch because "it all seemed too good to be true". Certainly good enough to overcome the prohibitive costs often involved in such a change.

But it would be a mistake to focus only on cost - the 'fit' of services offered, published APIs, plug-in modularity, feature extensibility when required, and avoidance of proprietary data format lock-in are equally salient. Open data is just as important as open source if you ever decide to change your mind about an application or vendor.