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.

In 2015, I was in a discussion with a group that was bringing consultants on board to work on the migration. Having had previous experience in this domain and with a large AEM migration, the project interested me but I chose not to get involved and so I do not know any details of what happened other than what I’ve read in the CBC article. There are a few things about the project that I always thought were questionable: namely the choice of software and the management of the project. I felt there was an anything-goes sense of desperation in the recruiting, which didn’t make very feel confident about how the project would unfold.

When I read the CBC news article, the following quote raised a flag for me in terms of questioning such a large project’s management.

“A government source with first-hand knowledge of the Canada.ca project, speaking on condition of anonymity, said IT government workers have been told that none of the government’s arm’s-length agencies have been moving their material over to the new site for some time.”

If people haven’t been migrating material for some time, I would want to ask what happened to lose their participation and throw the project off track?

When you have that many sites, involving a large group of people, they’ve got to understand and feel that their concerns are heard, respected, and involved out the outset of the decision-making. There ought to be things motivating them to move toward the project’s goals. Did they participate in selecting the system? Did they receive training and have the necessary support to comprehend the vision of how the new system and associated processes would work? Did they understand and buy in to the goals? Was it going to improve their work experience and outcomes? Were reasonable deadlines established with communication to keep people aware of the project’s movement as they succeeded with their milestones? I’m sure that one could ask a lot more in a post-mortem of the project..

Of more concern to me though is the selection of the most expensive proprietary WCM platform on the market, Adobe AEM, and the choice of hosting Canadian government sites through an American service provider, Amazon. AEM has many good qualities (as well as bad) but the good do not merit its cost.

First, the platform.

Government software selections ought to, by default, consider free/libre and open source software products first and then develop or select proprietary solutions only if no sufficient F/LOSS choice exists.

Some F/OSS advantages include the following. By definition F/LOSS choices result in greater transparency (and potential security) since the code can be audited. F/LOSS can result in large cost-savings due to an absence of licensing fees (though support incurs costs just like it does with proprietary software). In the future, migrating the systems, code, and data for preservation, archival, or shifting formats can be accomplished with more flexibility if the code is open and accessible rather than closed and controlled by a foreign company (which may or may not continue to operate).

F/LOSS does not lock a government into the control of foreign entities and better, it has the potential to involve communities of domestic businesses in support or customization that might otherwise be prevented.

F/LOSS choices align well with government initiatives in that they enable us to also control our own systems, foster our own businesses and communities, and master our own security. In contrast, Adobe AEM is a proprietary product controlled by a foreign company, with no transparency, and no requirement to give back to communities involved with it. Canadians are paying for something that we cannot control and which doesn’t contribute to the Canadian digital ecosystem. It enriches a foreign company.

Second, the hosting.

Government sites hosted by Amazon—a foreign (American) company? Even if the servers sit on Canadian soil, isn’t this a questionable decision? How does that intersect with American laws and American government agencies, which could demand information from Amazon? As I lack detail about this setup, I am certainly not well-informed and I would imagine that all sorts of precautions were taken in this arrangement. Nevertheless, why introduce this kind of a security and privacy risk? Shouldn’t we be critical about putting Canadian government information (not to mention potential personal information) on servers hosted by a company of foreign origin (using foreign proprietary software) when Canadian companies could have provided the same service (or the government could operate these itself)?

Regardless of how the remaining Canadian government sites manage their content, there can be an information architecture, design strategies, and style guidelines developed, which provide usable experiences and good aesthetics for people seeking information from these Web sites. The back-end system can certainly help improve the management, updating, and preservation of the content for the people developing or administering it but it does not necessarily dictate how the user interacts with the public web front. So even with today’s state of affairs on the WCM migration project, Canadian government Web sites can continue to serve their purposes and improve.

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 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.