There’s no question that enterprise content management (ECM) technology-related projects in the public sector are vastly different animals than ECM-related projects in the private sector. Consider news items like the recent Washington Post report last fall, that the e-forms project run by the U.S. Citizenship and Immigration Services cost more than $1 billion over 10 years—and yielded just one online form. (Now, on to the 94 other forms!)
Of course, most government ECM-type projects aren’t such flagrant fiascos, and the commercial sector is no stranger to train wrecks. But there are significant structural differences between the government and commercial sectors that are relevant to ECM initiatives, and you should be aware of them.
Specifically, government organizations differ from commercial organizations in three key ways that impact how you should plan and implement ECM, records and information management, and information governance projects.
1. Greater breadth and depth of required transparency
Government organizations have Freedom of Information Act (FOIA) and similar obligations, and disclosure and oversight requirements. They are therefore obligated to ensure that more of their information has assured retention and is readily available upon request. One problem this causes is that government organizations are tempted to have very broad definitions of what constitutes a record: potentially almost everything is a record. Well, that’s okay, as long as organizations recognize that there are risk and value differences between kinds of records. Some records are more “record-y” than others and should be treated with more rigor than others. Organizations that don’t have this clear tiering within their “record” category will not properly prioritize their information management and governance efforts. And the result will be a failed initiative.
What’s the best practice to address this issue in the public sector? Government organizations should have broader definitions of what’s a record, but should be careful to differentiate among tiers or levels of records. Vital constituent records, such as birth certificates, should receive far greater prioritization than departmental meeting minutes.
Likewise, commercial organizations should have narrower definitions than government organizations concerning what’s a record. But they should be careful to differentiate among tiers or levels of non-records. Non-records reference documents or work-in-process documents should receive greater prioritization than transient documents.
2. Different set and weight of business objectives
Government organizations prioritize general compliance, cost control, and their obligation to serve their constituents, as opposed to revenue, profitability, product development. This means that there aren’t the kind of counter-balancing “offensive” business drivers and projects to push along ECM and RM projects in the public sector—or to constrain those projects when they fail to meet their original objectives (cf. our now-familiar U.S. Citizenship and Immigration Service e-forms initiative, above).
3. Tighter budgets, dependable budget windows, and margin for errors in implementation
For government organizations, this means that that though your IG vision must be long term, in many cases longer than in the corporate world, you have to execute in much smaller chunks. Your budget cycles are typically far shorter than those in the private sector, and your projects may be delayed or halted at almost any time. The best practice, therefore, is to ensure that you design your roadmap for partial failure. This is actually a best practice for anyone doing significant IT projects, but it’s absolutely necessary for successful government ECM-type initiatives.
What does this mean in practice? It means modeling failure and “half-baked” scenarios -- scenarios where you have to stop at various points in your roadmap. Assume you may be forced to “put down your pencils” every 90 days. Be able to stop at any one of these points and declare victory, while you wait to start up the project again. Make sure you can optimize a completely uneventful, successful implementation – but have lots of “Plan Bs.”