Canadian Government WCM Migration Project Failed—It’s for the Best

Our former federal government (under Harper’s Conservatives) decided to migrate some 1500 government Web sites to a single content management (WCM) system. They chose Adobe’s AEM product and it looks like the project collapsed in failure. As a Canadian citizen, I’m glad the project has not worked out. I can see how such a project could have merit but the software choice was a bad decision in principle and apparently the project planning and management were not undertaken properly. Too bad it didn’t fail sooner to prevent wasting so much money. CBC’s article about the project is here and I’ll point out a few thoughts about why I think the choice of WCM system was bad in principle and raise some questions on project management. Continue reading “Canadian Government WCM Migration Project Failed—It’s for the Best”

Alfresco ECM in 2013

I had a chance to hear from Alfresco earlier this year about its direction and some new product features. Alfresco has grown to be a go-to, lower-cost, open source solution excelling in large-scale intranet implementations, corporate file sharing services, and document collaboration.

Alfresco currently has 33,000 customers whose ECM activities are enabled through on-premise, public or private cloud, or hybrid deployments. This is a particularly convenient situation for Alfresco considering there is a good deal of interest in hybrid environments from organizations seeking ECM systems.

You can download my report from this link (it’s free but it does require registration).

Demand Trends of ECM and WCM Buyers

After aggregating the high-level needs of thousands of people telling Technology Evaluation Centers (TEC) their requirements for enterprise content management (ECM) and web content management (WCM) systems, I’ve put together two reports showing the trends. You can read more about these high-level requirements in TEC’s latest, free ECM market survey report and WCM market survey report.

We found that security is one of the most frequently sought requirements, across the board. Unsurprisingly, many characteristics necessary for managing business processes are high-priorities as were search and indexing in the WCM space.

We also found that while it’s a growing portion of the market, organizations seeking an ECM system that is not on-premise, remain a minority (about 30% of the demand). In the WCM space personalization features were deemed rather important by buyers. I’m guessing that both of these requirements will be even higher in the coming year since both cloud offerings (and hype) have increased and the ideas for experience management are also getting more recognition.

Note that each of these reports are based on a complete year of data from 2011. In 2013, I’ll publish an update using the complete 2012 year data.

Laserfiche ECM and Its Latest Release

I spoke with Laserfiche about the new version 9 of its Rio enterprise content management (ECM) system. In the latest release the company is really pushing on the business process management functionality. They’re positioning the system more for managing processes without necessarily seeing them as document-centric. You can download the report from the Technology Evaluation Centers site (free).

It covers a lot of the other functionality provided in the Laserfiche products too–things like they handle document acquisition, redaction, workflows, and more.

A Brief on EMC Documentum in 2012

I’ve published a new report on the EMC Documentum family of content management products and services. Go here to download it (free from the TEC site).

EMC’s path for Documentum has taken it in some promising directions. While this report doesn’t cover everything, it does explain a few of the key areas that EMC has been working on and plans to roll out in 2012. In particular, the report looks at what EMC is doing with mobile devices, governance, and case management.

If you’re in the process of evaluating enterprise content management systems and you’re interested in how Documentum stacks up for your needs, the report includes a (free trial) link to evaluate Documentum in TEC’s online decision support and analysis system.

Wiki While You Work

The Globe and Mail published an article about using wiki applications in the workplace. While not a new notion, this is the first time I’ve seen it in a regular newspaper and not an IT business rag. A point the article touches on is the wiki’s security. I think wiki security may be one of the more misunderstood issues about using a wiki for work and an important differentiating factor in determining when to use an enterprise content or document management system (CMS/DMS) and when to use a wiki. In fact, I think it’s hard to beat a wiki if you need an application to capture and disseminate employee knowledge.

“One drawback is security. Much of the hype around wikis concerns their ability to place everyone from the receptionists to clients to chief executive officers on the same virtual playing field.”

The key phrase above is that it puts people “on the same virtual playing field.” Useful things take place when people are uniformly able to document their activities, collaborative or otherwise. Simplicity is a defining aspect of wiki applications–they make it incredibly simple to collaborate on developing, publishing, or otherwise contributing to company information, documents, in some cases products, etc. I’ll talk about an internal wiki only, as I realize that one open to clients as well may present a slightly different set of issues. Still, I’d argue that in most cases the somewhat loose security issue is more of a benefit than a drawback. Let me illustrate this with how the company I work for, uses one.

Some time ago, frustrated with the problems of repeatedly sending mass e-mails to everyone in our company, I set up an internal corporate wiki. A wiki is excellent for work that is in constant flux or must be accessible by everyone in the company.

  • communicate important news or announcements
  • inform about policies that must be adhered to
  • distribute documents
  • collaborate on work issues
  • capture and disseminate the day-to-day knowledge that employees develop

I think these things fail through e-mail but work with a wiki. I think most of these things are usually (though not always) too encumbered with hierarchy structures, metadata entry, and access controls to be the most effective for the types of things I mentioned above. Even when people save e-mail messages, they must make repeated archaeological expeditions through their e-mail histories. If announcements need to be referred to in the future, there’s no guarantee people will be able to find them in an inbox. Policies and problems that have been solved are likely to be forgotten if they’re not easily present and visible, as they are in a wiki. Ensuring that people always use the most up-to-date versions of documents means making them easily accessible and that is so nicely accomplished with a wiki. Using e-mail to collaborate on projects can become a nightmare of criss-crossing information, which often leaves people out of the loop. If people are in the habit of working with a wiki on all sorts of general day-to-day tasks, it becomes an automatic, company-wide storehouse of employee knowledge.

Using a wiki facilitates these activities. For example, at TEC, internally we use the fantastic, open source Wikka Wiki application. It’s simple enough that people can be productive with it after about five/ten minutes of instruction. It doesn’t confuse with over-sparkly and burdensome features. It’s fast–takes fractions of a second to access and edit in a web browser. It doesn’t require manipulating difficult access permissions. These are all important features because they make it at least on par, if not sometimes easier than sending an e-mail or accessing a DMS. If you want to change peoples’ work habits from constant e-mail use, then I think the alternative ought to be at least as easy and efficient or else offer something so incredibly good as to compel its use.

Before the wiki, people would forget what an important policy might be after six months. Now, even if forgotten, it can be easily found for reference. Before the wiki, frequently used documents were sometimes difficult to disseminate in their most up-to-date form. Now they’re updated, in short order, on their corresponding wiki page.

Before the wiki, information about projects that different groups in the company had to collaborate on, was spread across different people’s e-mails. There was the risk that someone wouldn’t get all the information s/he needed. Now it gets collaboratively updated on pages that anyone within the company can see, which has the added benefit that sometimes people without an obvious, direct connection to the project can discover it and contribute or use it in positive ways that nobody would have imagined previously.

I don’t think a wiki replaces a DMS or vice versa. A DMS might sound like it is designed to capture and better enable such collaboration but I don’t believe that is necessarily its strongest point. I think a DMS is probably better-suited to developing documents that require tight version control, traditional hierarchy structures, and cannot necessarily be developed as content within web pages. A DMS might be more useful for archival purposes or for documents that are sensitive and absolutely must have special access controls. But a DMS tends to be more cumbersome in the security and access area, and thus loses utility in the area of capturing and disseminating employee knowledge.

Spreading the wiki. In the past, people sometimes would tell me about some sort of project they needed to work on or information they wanted to store in an easily usable way. I’d recommend they try the wiki to facilitate it. So they’d ask of course, “what’s that?” and I’d spend five/ten minutes explaining it. The interesting thing is that then they go off and explain it to other people on their teams, then the different teams work on things with the wiki, word-of-mouth makes its use spread. I’m sure this isn’t a 100% effective way to promote its use but I was pleasantly surprised that after implementing the wiki and announcing it, people started pushing its use of their own accord.

A system that requires a lot of security, perhaps needing more of a top-down approach, wouldn’t permit this type of usage to happen. Setting up access controls, accounts, and maybe designing structures for how a company uses its systems of collaboration and knowledge sharing may be time-consuming and ultimately not do the job for which they’re intended. On the other hand, a wiki method allows this to self-organize. The chaos of knowledge that frequently gets developed and lost throughout a work place gains a facility in which to reside and that attracts use.