Blogs

I have now been employed over the last two decades as a manager of knowledge on behalf of Peter Drucker's legion of postindustrial knowledge workers: the folks who are paid according to how well they extract dollars from the purse strings of an information-based economy. Nothing remarkable about that.

What's humming in the backdrop to all this has a lot less to do with engineering or marketing or financial services or any vested value chain in Michael Porter's rationale for ecosystems of commerce. It has everything to do with another self-organizing cycle called the deployment of an information system to store, manage, and ultimately trade on the know-how of knowledge chiefs, Indians, paupers, and kings -- every one of them consumers, producers, and ultimately brokers between the markets they serve and the systems we build for them in support of that effort.

Organizational Ignorance

It sounds grandiose and majestic in scope -- scalable, I believe, is the AIIM keynote name for this. Yet the inner workings could bore the daylights out of the most conventional cog in the knowledge system machinery. There is little that's soaring above the data clouds or epic in strategic roadmapping than the backfilling required to move an organization from the shadows of its own ignorance to the universal driver of all deployment budgets: attaining a state of knowing what we know, a.k.a. the conquest of organizational ignorance.

I say this in the throes of inventorying a sizable backlog of projects and cases where details are unevenly dispersed, inconsistently recorded, and are impeded from being recombined or integrated by a tangle of legacy systems -- each one a firewall within a silo of degraded records, arcane tasks, error-prone entry points, and uncommunicated updates. The problem is so pervasive that us cogs are too busy feeding the silos to put our labors to the knowledge worker sensibility test: are we actually managing these systems or are they managing us? 

If we answer truthfully we see more clearly that the enemy is not a lack of cooperation, intelligence, or executive will to forge systems that perform as well as our team-focused colleagues. The enemy is the fear that the problem is so daunting that it dwarfs our ability to withstand the tedium required to define it, classify it, search it, and ultimately solve it through the demonstration of knowing what we know because:

(a) It's worth finding out and,

(b) Acting on in selective worlds beyond systems of our own design.

The Glamorous World of SharePoint Migrations

To give you a better illustration of my boredom factors, let me tell you of my life in the information weeds where a spyglass holds far more sway than a telescope, compass, or a smart phone. My team is currently in the process of populating our account directory as a lookup list in our test environment of SharePoint 2013. On the surface this looks like a Ritalin-induced flyover through a regimen of cut-and-paste routines. Conceptually this is a forensics exercise in appending metadata to legacy documents and records that would otherwise lose their identities once they transition to from the legacy content system to their new SharePoint home.

I could promote the geek factor in bringing over 70,000 case documents without actually touching them. I could go on about creating lookup tables that correspond to our historic records so that each asset is pre-stamped upon arrival in SharePoint 2013 with their inherited case details. But that plateau is elevated high above the drudgery of piecing those histories together. Automation shmautomation. Whacking away at the weeds here is the boring and critical business of building the metadata foundation. It's not a tool or a survey or .NET script but the meticulous construction of human-built indices. This forms the basis for our metadata foundation and the source data  that can be recompiled in our client libraries once the spade work is completed.

Building Relationships on Metadata Foundations

But it's the seemingly low level task of deconstructing those histories where the patterns emerge, the behaviors happen, and the revelations unfold. CRM gurus like to talk relationships but what could be a better chronicle of those bonds than a logging of case members: How far back do they go? How deep in expertise? How lasting in their commitments?

When a marketing outfit poses these questions the posturing can sound overstated, and even creepy: who's being helped ... who's being hacked? But when you're mining your own organizational histories, the resulting metadata is not just an act of preservation but of planning ahead around account records otherwise lost or buried in the systems we’re migrating to.

Building out those case histories means retrofitting metadata poor archives with accurate account information. It means applying accurate tags to artifacts that will let us trade on our past successes once situated in their new system homes. It means exploration of the relationships, trends, and service offerings that bring us to this hopeful day -- what needs to be revived, what needs to be revisited with emergent thinking? How can a simple re-sorting of our case histories reset the way our firm positions itself or augments critical parts of that positioning already in motion?

In sum, when you're planning your next deployment I encourage you and your implementation team to take the sensibility test:

* Whether your archive is tiny or voluminous,

* Whether your ECM is SharePoint or another platform entirely,

* Whether the systems you’re connecting are even on speaking terms ... consider this:

Let the systems do what they do well, let the people work from their own strengths. The best way to make that separation is an intentional and painstaking slog through the weeds is the most informed way to answer that self-evident and yet seldom raised question that lies at the outset of all deployment calendars.