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.

Tomorrow (Tue, May 18) there's an excellent chance to hear one of the best bloggers and practitioners on the topic of Product Management - Steve Johnson of Pragmatic Marketing is giving a talk to the Cambridge Product Management Group.

The Pragmatic Marketing Framework is a design classic, and mandatory reading for anyone in the field.

Much of my work has been in a Product Manager role even though I didn't always have that title at the time. In the high-tech and semiconductor sector, it was often a simple split between Marketing (the people who set up tradeshows and talk to customers) and Project Managers (the engineers who get the product out on time). Smart readers know this conflates Product Marketing and Product Management. Really smart ones will see the slip in terminology between Project and Product Management. There is a difference between the three titles, and the Pragmatic Marketing website will answer all questions.

Thinking about tomorrow's event made me consider what makes Product Management so difficult and frequently prone to failure?

My inclination is that there are 3 basic problems that make even good intentions into the paving stones leading to Product Hell.

1. Lack of a product workspace containing technical and commercial documentation makes it difficult or impossible for new joiners to become familiar with the product. Before you know it, the old issue of "knowledge is power" raises its head. Or, "Scientia potentia est", if you want to be fancy. Gaps appear in product documentation, and this usually means a shortfall in marketing collateral when it is most needed.
2. Lack of a standard process or workflow causes product decisions to be made in an ad hoc way. At best, it is inefficent as good practices have to be re-discovered. At worst, product decision-making quality varies between instances.
3. Release fragmentation leading to / caused by customer variants makes for a configuration management nightmare. Bringing all the customer versions back into one main branch or trunk build can make publishing a future roadmap very hard to achieve.

For the past 10 years, the solution to these problems for me has been to use CogniDox. Here are a couple of illustrated examples of ways that CogniDox has helped me and other Product Managers / Project Managers have an easier time of it.

The first example is creating a category or workspace for all documents relevant to the project or product release. This can have as many sub-categories as needed, as long as the core requirement is met - a logical place to start when you want to navigate through the product documents.

There's nothing revolutionary about this, but the number of companies I encounter who don't have a structured, common repository for product documents means I have to mention it. The example above illustrates how the category contains everything - software release packages included - that will go into the release.

The second example is something we call a "document holder" in CogniDox. It's a type of document written in XML that has placeholders for other documents. Other documents can be any file format, including video tutorials if you want. 

As you can see, the web page view (icon on the left) is automatically created from the XML file (icon on the right).It's especially helpful because it ensures that the document actually exists, and/or makes sure that correct process is followed e.g. you can't release a draft version, it has to be issued and approved.

What we've tended to do is create a document holder that reflects the structure and contents of the category, because an important point is that we can release the document holder as a deliverable to customers. It will help them understand the product's structure.

When a user from a customer company logs into the customer web portal access that we provide as part of standard CogniDox, they see the product documents that the Product Manager has licensed to them.

If we create one of these per product release or release variant, we know that the licensing manager module in CogniDox will automatically ensure that users only see what we have licensed them to see. There's less danger that the product variants will cause us to make an error of including a file we shouldn't, or leaving out something critical and looking quite unprofessional as a result.

When we start a new project or release, we can copy the category structure from a similar product that we know worked well. Best practices start to become reinforced without any need for heavy-handed mandates.

The next example that I want to cover is the use of Reports to help a Product (or Project) Manager understand the product status. These reports provide a unfied console to assess projects in the pre-release process. If I have a Gate 1 milestone next week and we have collectively agreed that twenty documents will be prepared in support of it, then I can see at a glance how many have been uploaded, reviewed, issued and approved. It saves valuable time at the Gate review meeting itself.

CogniDox tools have been critical to me and others as we make Product releases, and have become as essential as our software code version control or bug tracking systems.

CMS Wire has posted an article on full text search in web and enterprise content management and concludes that Lucene with Solr is the de facto choice.

The reasons given aren't new - the quality of the search results, the stability of the (open source) software, the utility of the APIs, etc are all cited. It doesn't mention some of the major sites that now use Lucene/Solr - I find that the LinkedIn search experience is particularly enhanced by use of it.

But it vindicates what we've known for some time, when we too decided to adopt Lucene/Solr as our search technology.

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.

Theme of the week for me has been "free software".

It started from a strange source - reading about the judgement in the BSkyB versus EDS law case. Briefly, BSkyB hired EDS in 2000 to build a customer relationship management (CRM) system for two call centres in Scotland. The project was worth £48m, and EDS gave assurances that the system could go live within nine months and be completed within 18 months. However, by 2002 BSkyB had taken the development back in-house (it then spent  £265m on the project) and in 2004 sued for damages. It took years but they won - EDS are guilty of "fraudulent misrepresentation giving rise to damages" estimated at £200m. As you'd expect there were arguments from both sides. EDS argued that BSkyB had been vague about what it wanted. Legal commentators seem to agree that it finally came down to the (lack of) credibility of the EDS principal witness, and that's why they lost their case.

But what seems not to bother anyone is the overall cost of the project. I'm guessing there was more to this CRM than the average Saleforce.com project, and I used to work on call distributions systems in my Telecoms days so I know what these can cost, but a budget of £48 million pounds? And then the cost of £265 million to do it in-house? Amazingly high.

Sometimes when you see coverage of open source technology by certain websites or in analyst reports there's a nudge-nudge factor this isn't really proper grown-up technology. Free software - you get what you pay for - is their implication.

But if this is a glimpse into the world of proprietary Enterprise software I think we need to hope that things have changed since 2002.

It puts the arguments between definitions of freeware, free software and open source software into perspective. The arguments between advocates of "free beer" and "free as in freedom" can be fascinating, but pragmatism says free/open source software is really more about not being ripped off. Not being ripped off by the project costs; by the false promises of a vendor's sales team; by the inflexible terms of a license agreeement; and by inability not to to be able to change the software if you want.

There's a common thread between community projects, companies who offer free or freemium product, commercial open source vendors and free software projects. It is transparency, good value-for-money and respect for the long-term relationship with a customer.

Government is known for the same car-crash examples of ICT projects as the above. The UK government came out this week waving a large open source banner, but achivements included the example that "over 25% of secondary schools use the Linux operating system on at least one computer".  Not good enough.

An interesting survey arrived in my inbox from Cobalt Corporate Finance about the latest quarterly survey of a panel of Computing magazine readers and Cobalt’s IT vendor clients. This allows for a comparison of the buyers (202 IT managers) and the vendors (80 C-level executives). They specifically looked at attitudes to Business Intelligence, Cloud computing, Data Security, Green IT, Mobile Computing, PC/Windows Upgrade, Social Networking, Software as a Service, Unified Communications and Virtualisation.

The headline is that responses are all more positive than last quarter, but IT vendors remain more optimistic than IT buyers. The article is found here.

There are two ways to look at their results. The first is which IT technologies are in the "here and now" - in use or under evaluation; and which are further out - 12 months before adoption. This would indicate that Data Security, Mobile Computing, Virtualisation and PC/Windows Upgrade are most prominent in buyers' thinking. On the other hand, Software as a Service, Social Networking and Cloud computing are 6-12 months out in their plans.

The other way to look at the results is to measure the disconnect between buyer and vendor attitudes. This gives an indication of which technologies are at their peak in the hype cycle. The biggest disconnect between vendor optimism and buyer caution came in Software as a Service. On the other hand, buyers are more interested in Green IT issues than vendors seem to think.

The chart tells the story:

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.