Blog

The Central Office of Information (COI) is the UK Government's centre of excellence for marketing and communications. They have just published a report on the costs, usability and quality of selected UK Government websites in 2009-10.

It's a detailed report and the data is available to download. It shows how the UK Government spent £94 million on website development and running costs plus £32 million on web staff in 2009 - 2010. By looking at the analytics it's possible to correlate the costs of building these sites with the number of visitors. One headline statistic was that the UK Trade and Investment website averaged 28,000 users per month but cost over £4 million to build - so each site visitor cost £11.78. 

As an exercise, I took a deeper look at the websites in the COI report to see what technology they're using. These are leading central government websites so it's an interesting sample.

I wanted to characterise the sites from the information available on the Internet - were they built using Microsoft technology as evidenced by IIS web server, ASP.NET framework and Windows Server? Or were they Open Source based, with Linux OS and Apache web server for example?

In the end I extracted data for 38 of the websites, and found 25 were using Microsoft and 13 were Open Source. The majority of the Microsoft sites were running Windows Server 2003, with one instance each of 2000 and 2008.

That in itself bucks a global trend, in that over 60% of all websites are based on Apache whereas IIS 5, 6 and 7 account for 1%, 20% and 3% respectively. Microsoft and its partners have clearly had a strong influence over UK Government procurement decisions.

How much evidence was there of Content Management Systems (CMS) usage? Very little. There was a small pocket of Vignette CMS (now owned by Open Text), some Drupal and Joomla, and one instance of Microsoft SharePoint 2007. There was a weak correlation between the age of the site and use of CMS - it's more common in recently published web sites.

Were the Microsoft based websites more expensive than the Open Source based ones? I ran a non-parametric statistical test (Mann-Whitney) on the two samples and the short answer is that there's no significant difference. This shows that the overall costs of building these sites out-stripped the licensing costs.

Do these sites seem like good value for the UK taxpayer? At an average non-staff cost of £2.5 million per website, absolutely not. I read the report many times to understand how HM Revenue and Customs could spend £35 million on www.businesslink.gov.uk. I just can't figure out how.

What's the lesson? The licensing model of the underlying technology isn't a significant factor in determining website costs. Free & Open Source Software won't matter when a Consultancy or Outsourcing company loads up a contract with tasks requiring many person weeks of expensive billable time.

If there isn't a FOSS advantage, there's still clearly a commercial off-the-shelf (COTS) advantage. One of the main purposes of these sites (apart from serving static information pages) is to provide a portal for file download.

Commercial open source software packages such as CogniDox allow you to do this in a completely secure and flexible manner. It costs thousands of pounds, not millions, and it delivers those features out of the box. And it has competitors such as Alfresco and Nuxeo that can also do the same.

Last Thursday (17th June) the AIIM Roadshow 2010 reached the final day of a four day tour ending in London. The theme was "People and Documents Working Together". It's an annual event with keynotes, case studies and vendor exhibitions. Based on the conversations I had, the attendees seemed interested in transactional content, records management and there was good representation from the Public Sector. Not really the classic CogniDox company profile, in other words!

Take-away impressions from the event? The traditional proprietary ECM vendors must be very nervous at the strong growth of Microsoft's SharePoint. Licensing costs for the former are around 4-5 times what it would cost an organisation to "go SharePoint". Which is not to say that the latter is cheap, especially if you need extras such as Enterprise Search. There seemed to be a sort of complacency amongst the attendees I spoke to that it is OK to buy in a software solution that Microsoft say is a "foundational ECM", then pay again for 3rd party add-ons to make it a complete solution. But I can relate to the statistic that 37% surveyed say SharePoint is their first ECM ever used. Given the way it's bundled into various volume licensing agreements, it must come across to IT departments as "free". And because they have it, and users are asking for department Intranets, why not try it out? But that's a one-way journey.

The Real Story Group (formerly CMS Watch) take the side of buyers rather than vendors. The impression I got from listening to the closing keynote from them was that dealing with traditional ECM vendors hasn't always been a pleasant experience. So maybe working with Microsoft SharePoint is better?

Apart from SharePoint momentum, open source, Cloud and SaaS are also a problem for the ECM vendors. It's hard for them to adapt their architectures and the new business models sit uncomfortably with the traditional revenue streams. It can't be good.

IT Reseller Magazine (http://www.itrportal.com/) is today reporting a survey by Networked Planet (an Enterprise Search software company based in Oxford, UK) that shows 52% of office employees admit they have saved a document to the Company intranet or network (shared drives) and never been able to find it again. Around 39% of them say it's because no-one told them where to file the document, as there were no company guidelines.

The solution of course is better Enterprise Search. It's interesting that Networked Planet offers an extension on their core product specifically for Microsoft Office SharePoint Server (MOSS), so the implication might be that Sharepoint users are also vulnerable to the mis-filed document problem. That might be especially true of MOSS07, because SharePoint 2010 has added more tagging and metadata features. It's also maybe a reflection of the fact that the Microsoft FAST search server option is an extra $14K in licensing costs.

But I would hazard a guess that it has less to do with the inherent features of SharePoint and more to do with the way that IT departments react to business user demands and use SharePoint as a quick fix solution for document sharing and departmental Intranets i.e. barely one step up from the shared network drive and WebDAV. It isn't really an alternative to taking a short amount of time (1-2 days) for the business to do this properly. Call it "information architecture" or "common sense business planning" as you prefer, but it's still time well spent. And something that deserves a champion at the CxO level.

Enterprise Search software helps, but the other characteristics of a document repository - good catgorization, multiple category allocation, metadata tagging, content file types and a company-wide view rather than departmental Intranets; are equally important. Imagine the dilemma of a new starter in your company - how do they know what to search for? If they can navigate instead through a logical hierarchy it means they can self-train in company knowledge (and you don't need to sit by their side for a week).

Networked Solutions has a nice suite of products for the .NET / Microsoft Server market. They're far cheaper than other Enterprise Search software solutions available. But the cost (around $17K) is still more than the free Open Source products such as Apache Lucene/Solr or Xapian. The problem with those is that it moves the costs from licensing to system integration - you have to know what you are doing. This is why we get a bit excitable when talking about the Solr or Xapian or Swish-e integrated search feature in CogniDox. The value of what we have integrated is more than you pay for the entire CogniDox license.

The analysis and research company Basex published a survey this week entitled "The Document Jungle". It is a survey of the documentation habits of 300 knowledge workers.

They reported that each person produces 1 or 2 short documents per day and were called on to review around 3 to 5 documents per week. Some documents are not sent for review or sent to just one co-worker. The majority are circulated for review.

When it comes to circulating documents for review, 60% of the time they are sent as email attachments. The outcome may sound familiar to you - comments come back and have to be manually collated by the editor; there is a high percentage of error as edits get missed or comments overlooked; and comments are not returned in a timely manner.

25% of the survey respondents deliberately leave colleagues off review lists as they know they will slow down the review process. Personal experience tells us that, in the rush to get a major design document ready for a review deadline, it isn't easy to focus on the big picture of why we wanted it reviewed in the first place. "Speak now or forever hold your peace" isn't a very good design strategy, believe it or not.

We have a strong set of features in CogniDox to support the document review workflow, but we are frequently asked by users to include more. In the latest release (v8.2), for example, we added a better way for project leads to obtain reports on the status of documents sent out for review and/or approval. I can create a spreadsheet report by user that shows how many documents they've been asked to review, how many are outstanding (and are overdue on deadlines). I can do the same thing for document approvals.

It's a handy little dashboard-type report that gives even better feedback in larger companies with complex inter-departmental relationships. Routing every design document through a small set of design architects may show up in the stats - these individuals have a large review workload and they are not able to keep up. Good supporting data for your next New Hire request application...

Here are 8 suggestions for how to improve design document reviews in your company:

1. Get a Document Management System instead of using e-mail attachments. You have a very low probability of success in improving your document review process using an email-based solution.
2. Think before you add people to your list of reviewers. Do you really want them to comment, or are you just notifying them that the document is available? CogniDox separates reviewers from people to be notified - use it explicitly.
3. Use the comments field to direct your reviewers. Are you more concerned about technical accuracy in this issue than you are about editorial style? I need to know that as a reviewer. It may make sense to assign sections to individual reviewers - make that explicit.
4. Set meaningful deadlines. If you really need the draft press release reviewed by the end of one working day, say so.
5. Use email to send notifications that documents are ready for review. Include URL links that enable reviewers to quickly and easily navigate to the document review pages in your DMS. It may help to encourage timely reviews if people can see that other reviewers are making progress on their review tasks. Send automated 'nagging' mails when deadlines are missed.
6. Agree a set of terms applicable to your workgroup, department or (ideally) your company. If I reject your draft document and request changes, is that the same as if I accept your draft but leave a set of comments that I expect you to consider and include?
7. It's easier to read review history comments when displayed "in-line" by version and contributor threads. CogniDox allows users to select a document version and read the threads of comments made on each. Other tools such as Google Wave are addressing the same opportunity.
8. Build accountability into the document review process. Make document readiness an explicit part of any new Product Gate Process or QA strategy. Remember, poor documents end up costing extra time and money. Worse, customers may get to read them.

CMS Watch is a great site for learning about document management, web content management, enterprise content management, enterprise portals, web analytics, and enterprise search solutions. It's mandatory reading for those of us making products, and definitely worth the time of any buyer who needs to select a product in this area.

This week they published their predictions for what is likely to happen in 2010. They were also brave and smart enough to assess how well their 2009 predictions fared.

Selectively looking at some of their 2009 outcomes, they probably got it right that Open Source ECM made advances and that social computing diffused into the Enterprise. I think they got it more wrong than they admit on SharePoint being derailed by Office 14  - the interest continued unabated and the beta of SharePoint 2010 did it no harm either.

They predicted that SaaS vendors would expand offerings. There was plenty of activity in the SaaS sector but many buyers are still unconvinced about putting company documents on a third party server. A term of service from a SaaS provider looked at recently is not uncommon: "Once you cancel or terminate your registration with us, we will instantly delete data, content, text, documents, images and information from the service. After the cancellation of the service, all of your content will be lost for ever." Data lock-in as a variant on vendor lock-in, and just as dangerous. 

For 2010, CMS Watch makes some predictions that we can compare and assess in regard to CogniDox.

For example, "Enterprise Content Management and Document Management will go their separate ways" (#1) gets our agreement. There is a tension between providing good workflow tools for document management and the tools used for website publishing. Clearly they need to be compatible and work in unision at some point but doing both in one application isn't necessarily the best idea. Given that prediction, their "Document Services will become an integrated part of ECM" (#8) may seem to be a contradiction. Ignoring that, we'd agree that helping users to automate the production of documents will be helpful and important. We tend to describe this as "document assembly" which I think is a more specific and useful term for e.g. creating a new legal document using metadata to populate key fields.

We'd also agree that "Faceted search will pervade enterprise applications" (#2). They mention Lucene/Solr, which we support in CogniDox 8.0 onwards, but we'd also mention the Xapian open source search engine library and the Flax Search Service as a technology to watch. CMS Watch only mentions SharePoint in the context of "Digital Asset Management vendors will focus on SharePoint integration over geographic expansion" (#3) which may be overly specific - most ECM and WCM companies will consider offering a SharePoint connector. That doesn't however imply that SharePoint is any more than a workgroup Intranet builder with file sharing capability. Buying decisions may verge on the ridiculous - why pay $$ for SharePoint user licenses and then add $$$$ for a proprietary ECM add-on? But SharePoint 2010 will be a force, and we can anticipate a rush on products that see themselves as SharePoint 'killers'.

One thing that correlates with ECM suites and SharePoint is that they can bring hidden costs in hardware / server requirements and the IT admin effort inherent in their client/server architectures. For that reason we'd agree that "Enterprises will lead thick client backlash" (#6) and to a lesser extent that "Cloud alternatives will become pervasive" (#7). Some of the same issues faced in 2008/9 for SaaS still remain.

We'd strongly agree that "Gadgets and Widgets will sweep the Portal world" (#9). People have become accustomed to seeing them on the public web at sites like iGoogle and they will become the definitive user interface for the Intranet. The only question is what widgets are the most essential?

The prediction that "Mobile will come of age for Document Management and Enterprise Search" (#4) depends on what is meant by "coming of age". It will certainly be the case that this will grow from the current small base, but we think this is one for 2011 instead.

That leaves 4 other predictions we have not commented on, and so a quick visit to CMS Watch to read these for yourself is recommended.

We recently released CogniDox 8.1 and amongst the new features was a CogniDox Word Add-in. 

An Add-in is a software component that adds custom commands and new features to a primary program such as those in the Microsoft Office suite. The particular value of the CogniDox Word Add-in is that you can browse and issue commands to the CogniDox repository while you are using Word.

The first elementary fact we faced is that the Office suite is a collection of individual programs and we had to choose which one we wanted to extend. We've blogged recently on the ongoing ubiquity of Microsoft Word as the principal tool for knowledge workers, so it stood out from e.g. Powerpoint and Excel as the one to go for.

Everyone knows there are multiple versions of Office in use across the market. Ideally, we'd support all of them. Unfortunately, the differences between Office 2003 and 2007 makes that two quite separate tasks rather than one. It isn't easy to find out what share of users are using Office 2007 compared to older versions - there's a stat from Forrester that  roughly 80% are using the latest version (2007). This seems on the high side, but then when you consider that new PCs will be shipped with the latest version and that 80% of Microsoft's Business Division revenue comes from Office B2B sales, perhaps it isn't so far out. I have to say we're still not fully convinced though.

So we choose Word 2007. Worst case scenario, everyone plans to upgrade to it and our work is re-usable for Office 2010. Having to support 2003 would have eaten into development time for a product that will become less relevant to our user base.

The next issue was how to tool ourselves for the task. MSDN tools have been prohibitively expensive. Luckily, a year ago Microsoft launched a program for new start-ups that would allow them access to MSDN on a very reasonable basis. You need to satisfy certain start-up criteria - in business for less than 3 years with under $1M in revenue for example, and you have to be nominated by a Network Partner (often a VC or a BA group). But that gets you participation for up to three years and access to  Visual Studio, Windows Server, SQL Server, SharePoint, MSDN, Microsoft Office and more.

We joined BizSpark in mid 2009 through the assistance of our local friendly and capable Business Leaders Network (BLN). With the help of their registration code it was really simple to do.

Once we had access to all these development tools we had to decide which ones to use. We went for Visual Studio 2008 using C#. There's a strong argument to do Office development in VisualBasic.NET rather than C#, because a lot of the Office Interoperability API calls use optional parameters. This is not supported by C# 3.0. As a result, you tend to wind up with fairly verbose code. MS has a KB article about this. Visual Studio 2010 will bring in support for optional and named parameters, which will make working with the Office Interop APIs much more pleasant. As the Add-in is a relatively small project; we prefer C# much more than VB and VS 2010 will bring improvements, therefore we went C#.

At the protocol level, our interactions with the Add-in are via SOAP. CogniDox already had a SOAP interface used by our Linux command line client, so we were extending known functionality to provide a richer interface for the add-in. The benefit is we can reuse the SOAP API to do other integrations. CogniDox publishes its SOAP API using a Web Services Description Language (WSDL) file, and all it took to expose the API to the C# project was to point Visual Studio at the WSDL file URL.

This highlights the fact that Open Data formats can be as important as Open Source.

At the UI level we had to work with the ribbon UI and a custom task pane which are standard UI elements within Office 2007. One decision was between using the WPF (Windows Presentation Foundation) or WinForms for the UI controls. WPF is relatively new and set to be the future of of Windows UI development, but we went the WinForms route because it gave us access to more mature documentation that sped up development time. We may re-visit this decision with future releases of the Add-in. Our priority for the initial release was to explore where we could go with the Add-in and get some real user benefit out in the field.

So, at least one LAMP shop gets to develop for MS Windows. Without the existance of the Microsoft Bizspark program, it's highly unlikely that we would have chosen to do that or be able to fund it.

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.

This week we made our quarterly release of software, which we labeled version 8.0 (as opposed to 7.x) because (a) there were substantial changes to the internal architecture to support search engine plugins, and (b) it has a re-worked configuration system which makes life easier for CogniDox sysadmins.

The headline feature was therefore the fact that user companies can select between using the 'classic' Swish-e or the Apache Solr search engine. We've blogged in the past about Enterprise Search, so I'll just summarise to say that Solr offers features such as frequent incremental indexing, federated search, ‘more like this’ searches and spelling suggestions when no results are found. All of which combine into a single benefit - one search has a far greater probability of giving you useful results.

We also support a third search plugin in Flax Search Services, which is based on Xapian. FSS is still in-development, but it will be supported when it is ready for showtime within months. As we've said before, this is promising technology. Solr on the other hand has the power of the Apache brand. It shows how far F/OSS has come when I can say 'brand' in this context :-)

I've also blogged before about another feature - better document import - so I'll also gloss over that apart from saying that it feels good to rip out a feature and start again when it brings good usability improvements.

For ages now we've stopped using Microsoft Office Project (too expensive) and have been looking at open source alternatives. We've used GanttProject and and OpenProj for task scheduling and resource levelling. It's fair to say we do a lot less of this now than in the past - less spread out geographically, smaller development groups and an Agile methodology explains why - but it still comes in handy when you need to juggle constraints. In the v8.0 release support is provided for GanttProject, an alternative to Microsoft Project that provides project scheduling and management for Linux, Windows and MacOS X users. CogniDox includes an example PDF converter script for GanttProject .gan files. There isn't much to choose between the two mentioned, but GanttProject can import and export to MS-Project .mpx and .xml file formats whereas OpenProj only has save as .xml.

Another open source project we use is FreeMind, a free open source mind mapping application that allows a user to capture relationships as a diagram that represents ideas arranged around a central concept. CogniDox v8.0 can render FreeMind .mm files into Flash movies as the viewable version of the document. Mind mapping is one of those things that people either love or hate. One of the big 'preparation tasks' that companies face before they introduce a document categorisation system is to decide what are the information categories. We tried doing this using outline tools but it just seemed more natural to use a mind map where you start with "My Company" in the middle and then add departments, products, projects and anything else that made sense as links. So we've experimented with FreeMind as an Information Architect support tool. But it also has merit for animating a process or workflow, and that's what we are doing when we create a Flash movie from the static map. It also allows you to create linked maps, so you could create a procedure that links you to the appropriate content in CogniDox or on other systems.

Finally, there was the usual crop of small features that were direct requests from the user base. One was worthy of note: the weekly reminder email to users now includes a useful project collaboration feature – it reports on outstanding document review and approval requests from other users on shared documents. The use case for this is when you are preparing for a product or project gate review - if there are outstanding un-issued or un-approved documents you may decide to cancel the gate review until these are done as you would fail the gate criteria until this is so.

Integrating open source technologies such as Solr, Flax, GanttProject and FreeMind with CogniDox to create a platform of useful tools reminds me of a fundamental difference between proprietary and open source products. 

Proprietary software is nearly always 'streaky' - excellent modules mixed with so-so efforts. In the overall interest of the product's reputation, any concerns about these efforts are frequently supressed or denied. When you merge open source projects into one integrated whole, you can be as objective as you like about the module you are integrating. If you get it wrong, you jettison it and find a replacement. You don't need to have a 'tiger team', or the issues of managing out under-performing contributors. To paraphrase the CSI TV show, its all about the code.

Back in 2003, researchers at the School for Information Management and Systems at UC Berkeley published a fascinating study entitled "How Much Information" that attempted to measure how much information was available in the world (then). It broke down the data by individual media such as TV, Newspapers, Internet, etc.

In TV for example, 21,000 TV stations around the world broadcast 123 million total hours on air every year. Even if 75% of content shown was repeat programming, that still leaves 31 million hours of original content. However, if every home in the world had access to 100 channels and every viewer watched 4 hours/day, then only around 3% of original content is being watched in total.

There is an update to their report that will inform us that each Information Worker in the USA now receives 1.6GB of information each day - emails, reports, blogs, texts, phone calls, etc.

It isn't difficult to see a parallel with the world of TV - that information may be out there but we are not taking it in. Unlike TV, information at work isn't something we are supposed to be able to ignore. It's all meant to be business-critical and we're expected to read and act on it. Some hope.

In fact, there is even going to be an Information Overload Awareness Day next month. In his blog, Jonathan Spira of Basex says there will be an event to mark the day. Cost to attend is $50, but delegates who promise not to multi-task (i.e. IM, e-mail, or text) during the event can get a 50% discount.

Basex have done interesting research to investigate in more detail where our day goes. According to them, the 'worst offender' is time lost to interruptions and recovery time from interruptions. These can be people interrupting in person or by phone, but we are as likely to allow ourselves to be interrupted by an incoming email, tweet or other enticing link. In fact, these non-time critical interruptions are more common. The problem with interruptions is that it takes ages to re-orient back to the original task. Once distracted, it can take 30 minutes to get back. No surprise, then, that interruptions (important or otherwise) total 2 hours and 14 minutes of lost productivity per day.

Another productivity drain is searching for information that you need to do your job. Basex say it takes 1 hour and 12 minutes per average day. Accenture did a survey of 1000 middle managers in 2007 and found that 2 hours per day was spent on search. The Accenture survey also added that 50% of the searches were useless, so that is another 35 minutes to 1 hour of lost productivity.

Meetings were the next big category of time spent in the average day. This takes 1 hour and 30 minutes per worker. Nobody really knows how productive is this time, but anecdotally nobody seems to have a good word to say about meetings. These days, most of them involve people who are busily being interrupted by emails anyway! It is typically the case that ad-hoc meetings with a loose agenda are the worst, so it follows that structured meetings with a clear agenda are the most productive. Roughly 45 minutes to 1 hour probably gets wasted on the wrong sort of meeting.

Another detailed analysis was done by IDC in their white paper on "The Hidden Costs of Information Work". Their breakdown is shown in the table below:

 

 

Most of the people employed by the companies who would use CogniDox are highly qualified, and an estimated cost is £250/day per employee (loaded rate).

The alarming conclusion from the Basex analysis is that one could be wasting 4 hours per day, or £125, on lost productivity for each knowledge worker.

The IDC study allows us to make an educated guess as to how much the right productivity tools, such as CogniDox, might help to improve productivity. A document management system ought to make a big difference to some tasks (e.g. manage document approval, search, file and organize documents) and at least a modest improvement to others (e.g. create documents would be faster using company templates, retrieving an image from an image library saves re-work).

Using a modest estimate, 24% of the cost per employee (£60 approx.) could be saved. In a company of 100 employees, that's £6000 per day.

It would take less than 2 days to re-coup the cost of a CogniDox license for 100 user subscriptions in an annual contract.

Companies are enduring huge pains to cut costs during this recession. It is amazing that any would be prepared to continue to allow wastage on this scale, when there is an alternative way to regain the lost hours of productive time.

One of the top issues in all Enterprise Software is that, no matter how good the software tool, unless it is widely used it is a waste of time and money.

"Shelfware", as it is known in IT circles.

If you purchase a top of the range CRM system to manage all your customer contact details and keep track of your relationships with them, it still falls into disuse unless your salesforce actually use it to record their visits and calls. In fact, 30% of CRM projects completely fail due to insufficient end-user involvement and buy-in.

You may persuade yourself that Business Process Modelling (BPM) will help you understand the critical workflows in the company, but again unless it is well-used and kept in a maintained state it won't deliver. The same is also true of Enterprise Resource Planning (ERP) software.

The core idea behind Document Management Systems (DMS) software is probably the centralized repository for all digital content. Again, unless users are depositing content into the repository, it won't deliver on the promises of saved costs and improved visibility.

It is extremely common to find yourself in a mixed-model where some content is in the DMS, while some is not. It could be that the missing content is legacy information, or it might be that it was once believed that the content didn't need to be included, but now you've changed your mind.

Making it easy to get that errant content into the repository is like an "amnesty" for users. It doesn't really matter about previous policy, because it can be changed with a swift document import.

We've been working to re-engineer the document import feature in CogniDox for exactly this reason. Coming up in Release 8.0.0, we've created a very minimal model where you can just import a zip file, and a slightly more detailed version where a control file will allow you to batch your requests and have them implemented in one execution. It's not that the feature wasn't there before 8.0.0; but rather that it's so much easier to use now.

I've already used it to upload all the minutes from a series of meetings that I realised would be better kept in CogniDox. Talk about not eating your own dog food! At least now I can quickly remedy my mistake.