So with that (and with hats off to everyone’s favorite Canadian power trio—and with apologies to all you Triumph fans out there), here are my ECM predictions for 2112…

• What it is and what it isn’t – the very name auto-classification conjures up almost magical powers that can transform a gloppy, hulking mass of unstructured content into a highly structured, polished collection of tagged documents. As you might imagine, this is not entirely true.
• How it works – not from a technical perspective, because this goes way beyond my knowledge. But I do know a bit about the people and process work these tools require to work properly, and the reality of it may surprise you.
• Whether it works – I’m involved with a POC to test some of the auto-classification solutions out there against that most elusive of things: real client data. We’ve got an organization willing to share a chunk of their shared drive content as well as some vendors willing to use their tools to auto-classify that content. I won’t be identifying either the firm or the vendors here, but I will speak to auto-classification capabilities in general and what I saw working and not working during the POC.

For this post, I want to sort out the first point, because I come across lots of misconceptions about what auto-classification is and how it works (some of them my own).

What do you mean by auto?

I don’t know about you, but when I hear auto-classification, I kind of assume that the tool does all the work. Automatic transmissions, auto-renew clauses in wireless contracts, automatons—the basic idea is that something happens on its own, without human intervention.

So my assumption about auto-classification tools was that they classified content with little to no human intervention. Sure I have to push the go button, and I figured I would have to QC the output, but as for the rest of it, Watson or Hal or whatever was going to handle that for me automatically.

Turns out that the reality of auto-classification couldn’t be further from this utopian vision of nearly effortless content classification.

All the tools I’ve come across, whatever the actual algorithm(s) they use to classify, need to be trained in order to function effectively, i.e., you provide the tool some examples of each kind of document you want it to classify so it can learn what makes each kind of document what it is and different from other kinds of documents.

Teach a machine to fish

For example, let’s say one of the documents you want your auto-classification tool to recognize is a contract. First thing you need to do is find examples of all the different flavors of contracts at your organization: vendor contracts, services contracts, big ones, small ones, ones you own, ones sent to you by third parties…enough of them that the auto-classification tool will be able to find any contract that might be in your repository with reasonable (e.g., >90%) certainty.

You might be saying to yourself, sounds great, but I would want the tool to classify lots more than just contracts. I have hundreds, potentially thousands, of document types I would want to classify. That seems like it would take a long time and a lot of effort.

And you would be right. The amount of time and effort it will take you to train an auto-classification tool is substantial, and not just on the part of a few resources. Because you’re going to need lots of examples of document types from across the whole organization, folks from every department will need to participate and shoulder some of the burden.

Danger Will Robinson

Based on the amount of prep work it takes to get auto-classification tools up and running I think it’s more useful to talk about machine classification rather than auto-classification. Here’s what I mean…

Think about a robot in a car parts factory. It arrives day one with all sorts of capabilities: it can rotate its claw, bend at the elbow and shoulder, open and close its pincers, etc. But if you put it in front of the parts that make up the muffler for a Honda Accord and turn it on, nothing happens, because before that robot can do anything productive, you need to teach it how to build the muffler for a Honda Accord.

You need to teach it, step by step and movement by movement, precisely what to do in order to build that muffler correctly. Once you do that, then you can put box after box of parts in front of it, and it will build you mufflers all day (and all night) long. But without the up-front efforts to train the robot, or with poor quality up-front efforts, you’ll get nothing.

Auto-classification tools are pretty much the same from what I can see, and in this respect, it seems better to think of them as machine classification, i.e., after teaching them what to do, they then execute on the rules you taught them to classify content. But what they don’t do is come up with the classification rules on their own in the first place.

The final word

Okay, so much for what auto-classification is and isn’t. Next post we’ll look in more depth at how the up-front training of the tools works to give you a better idea of what that entails in order to be successful.

In the meantime, I’d love to hear from folks out there, especially those of you who have more experience in the trenches working with these tools: am I right about them, or have I missed something? Do you see the matter differently, is there another way to frame the issues up?

Whatever your thoughts, jump in, and let’s get the conversation started.

And for the last 18 months or so, my clients have been pretty silent on auto-classification—they’ve had other ECM things on their mind. But lately the buzz around auto-classification has been picking up at my clients and out in the wider world. So I figured it was high time I devoted some attention to it here.

I want to spend a few posts on auto-classification, from a number of angles:

• What it is and what it isn’t – the very name auto-classification conjures up almost magical powers that can transform a gloppy, hulking mass of unstructured content into a highly structured, polished collection of tagged documents. As you might imagine, this is not entirely true.
• How it works – not from a technical perspective, because this goes way beyond my knowledge. But I do know a bit about the people and process work these tools require to work properly, and the reality of it will likely surprise you.
• Whether it works – I’m involved with a POC to test some of the auto-classification solutions out there against that most elusive of things: real client data. We’ve got an organization willing to share a chunk of their shared drive content as well as some vendors willing to use their tools to auto-classify that content. I won’t be identifying either the firm or the vendors here, but I will speak to auto-classification capabilities in general and what I saw working and not working during the POC.

I’m also hoping to hear from lots of you all out there during the series of posts about your thoughts on auto-classification, your experiences with it, thoughts on my thoughts, etc.—so get ready to jump in and get the conversation started.

My first post will be after the winter recess, but in the meantime, I hope you all have safe and enjoyable holidays with family and friends and look forward to seeing you back here in January!

But in the last post, I promised to scrutinize the team I play for: management consultants. Although, along with Doctors Without Borders, the Make a Wish Foundation, and The United Way, we management consultants are making the world a better place one project at a time, we do have some areas for improvement…

But in the interest of being fair and balanced about the RFP process, I thought I’d shine a light on some misbehavior of the other RFP participant: the buyer.

After all, it takes two to tango, and in most RFPs-gone-wrong, there’s ample blame to be laid at the feet of the client as well as the vendors.

With that in mind, here are the top things not to do if you’re the buyer in an ECM RFP:

1. Try to compress the RFP timelines beyond all reasonability. You’re buying a multi-million dollar platform and committing dozens (or even hundreds) of your employees for weeks, months, or years of work to get that platform up and running and delivering value to the organization. You can’t make an informed decision in four weeks—heck, you can’t even make a bad decision in four weeks. So rather than creating an unrealistic schedule, rushing the vendors through the response and demo phase, and pressuring the team to evaluate them…and then pushing the deadline further and further out to give everyone enough time to get things done, take a step back and create a reasonable schedule. And if it’s longer than you planned (or than upper management is comfortable with) get real and own up to that now. Much better than over committing and having to blow past your end date.
2. Do things just for the sake of doing them. RFPs have hoary and venerable traditions associated with them—many of which are completely irrelevant to selecting the best solution. Take the time to huddle up as a team to discuss how RFPs are typically run at your organization and the pros and cons of that, as well as some ways that you might run them differently to get more value. Include not only the core project team but any key decision makers as well as ancillary stakeholders like procurement, finance, legal, etc. Get all perspectives on the table up front, before you’re in the thick of the RFP and running up against your deadlines (see #1).
3. Let procurement own the process. Is procurement important? Yes. Do most corporations require you to jump through certain procurement-themed hoops to purchase enterprise software? Yes. Does that mean that procurement knows the right solution for your business needs? Absolutely not. Make sure you’re clear with your procurement folks about the division of labor, i.e., what they are responsible for and what you are (see #2).
4. Let the vendors own the process. RFPs are not your job…in fact, this may be the first one you’ve ever participated in. But you can bet that every member of the vendor sales teams has participated in dozens if not hundreds of them. They likely know how these things work much better than you or the rest of your team do, but that doesn’t mean that you should become passive. You’re looking for software to solve your business problems, not theirs; so step up and own the process.
5. Forget that you’re the customer. You are at the center of the RFP process, you are the reason for it existing in the first place, and you are the person ultimately that must live with the solution that gets chosen. Every element of the RFP process should be engineered to deliver value to you. If some part of the RFP process does not, you should be seriously questioning why you’re doing it (see #2).
6. Take your vendors’ time and efforts for granted. Yes, you are the customer and yes, you have a right to expect responsiveness from your vendors and yes, they want to sell you stuff and yes, they will likely make a very big commission for doing so. But that doesn’t mean you can treat them poorly, waste their time, or expect them to give you hours of free consulting just for the privilege of being part of the RFP. These are real people with real lives, many of whom are very committed to solving client problems with technology. Despite how it might look sometimes when they’re standing in front of your exasperated team speaking to slide 477 of their deck, they spend a tremendous amount of time and energy creating RFP responses and planning presentations—often missing out on time with friends and family to do so. Try to honor that in your dealings with them during the selection process.
7. Forget that the goal of the RFP is to solve business problems with technology, not acquire software. There’s so many moving parts to an ECM RFP that it’s easy to get lost and treat the RFP like an end in itself, which of course it’s not. Selecting, purchasing, and implementing the technology is really just the prelude to the real work: delivering solutions to the organization that solve meaningful business problems. We tend to get lost in all the bells and whistles, all the feature sets and product roadmaps we hear about, and visions of FULLY EXTENSIBLE ENTERPRISE PLATFORMS LEVERAGING THE FULL CAPABILITIES STACK TO DELIVER INTEGRATED SOLUTIONS SEAMLESSLY dance in our heads. None of which matters if we can’t quickly and effectively deploy the chosen technology to deliver value to our end users—don’t lose sight of that.

Hopefully this post helps spread the blame for RFPs gone wrong, but as always I’d love to hear from you all out there: jump in and share your advice for buyers on how not to handle the RFP process.

But as I sit here in my hotel eating room service and writing this post after a long day working with clients, I feel a little disingenuous, because with this series of posts so far I’ve conveniently left the plank in my own eye.

Yes, ECM vendors have issues and yes, ECM buyers have issues, but what about us consultants? Not the integrators and implementers who actually do things, mind you, but us more strategic folks, the ones who come in with their fancy suits and their white iPad2s and all those 11×17 Visio diagrams and tell you what you should do…and then conveniently leave before the real work starts—what do we do that makes life harder for all you clients and vendors out there? Where do we need to step up our game to live up to our aspirations of serving client needs before all else?

And while I take some time in the next week to cast a critical eye on the practitioners in my own guild, feel free to get the ball rolling with thoughts and criticisms of your own: I can take it!

1. Have more salespeople in the room than there are client team members. Sure, there’s a lot of technical detail in the solution you’re pitching. And, yes, there is some value in having enough experts in the room to answer any possible question. But I’d rather have two or three people speak at a business digestible level about the solution and then agree to get expert follow up where needed.
2. If you do bring an army of salespeople, they shouldn’t be on their phones or computers doing other work during the presentation. If they’re that busy—and have enough bandwidth during the presentation to be buried in email or other work—why are they here?
3. Be unable to provide a clear idea of what your solution costs – I know that this depends on a lot of factors, but it’s possible to represent this in a transparent, reasonable way. Don’t use it as an excuse to hedge by being vague or ambiguous.
4. Try to pack 6 hours of material into a 3 hour session. Yes, ECM is complicated and we could spend a whole day just talking about a single capability, like OCR, let alone all the functionality included in the solution. But at a certain point you need to be able to net it out in the time allotted or cut something. If you can’t come in on schedule in a 3 hour presentation, how will you fare during the implementation?
5. Show up as the incumbent with anything less than a full knowledge of the client context – this is your client, who has already bought stuff from you, who you are supposed to have a relationship with. If you come to the table ignorant of the basics, why should they buy more stuff from you?
6. Be less organized than the client – You do RFPs all day long, they don’t. You should be Johnny-on-the-spot with follow up items, questions, requested information, etc. Don’t make the client work for it. And let them know daily where you are with your items. This RFP is a big deal for them—heck, some of their jobs may be on the line over the results. Do everything you can to make it less stressful for them and easier to do business with you.
7. Be unclear or ambiguous where you are strong and weak relative to the RFP requirements – In terms of weaknesses, this is obvious: if you can’t meet a requirement (or don’t meet it well), so be it. No one meets them all. But hedging or dodging only casts doubt on your integrity as a vendor on top of your inability to meet a requirement. And in terms of strengths, don’t undersell or miss the chance to point out where you’re strong. It’s obvious to you, and it might be obvious to someone who’s read the response, but not everyone in the room has.
8. Make sure the client gets a feel for who you are as an organization and as individuals – The client isn’t so much buying a piece of technology as they are entering into a relationship, and that requires them to trust you and your firm. They can’t do that if they don’t know “who you are”—so spend time while you’re there showing them.

There. I feel better already.

But how about you all: got any good advice for vendors on how not to handle the RFP process? Jump in and share your best horror stories.

And in the interest of fairness, I’d love to hear from the vendors: what are the things that buyers should avoid? How do they make the process more difficult, less effective, etc.? What makes you absolutely cringe during the RFP?

Let’s get the conversation started…

While I’m doing that, here’s some oldie but goodie posts you may not have seen before:

• No one cares about ECM
• What does an organization really value?
• Everything I needed to know about ECM I learned in Divinity School
• Irrelevant taxonomies

Microsoft is a forward-looking company with a sharp eye for the power points, the lever arms, the control valves in the emerging digital economy. In the software sector of the economy of the late eighties and early nineties, there was just one important power point: the operating system. Microsoft owned it and used it to gain dominance over that entire sector. In the helter-skelter Internet-driven world we’re now entering, a variety of power points are taking form. The start-up screen, what you see when you turn on your computer, is a power point; Microsoft insists that manufacturers hand over all rights to that screen. We’re not just plumbing.

Internet search sites are power points, because they can become habitual portals of entry for users seeking information or ways to spend their money. That’s why it was important to make sure that your Search button would take you to a page at home.microsoft.com.

James Gleick, What Just Happened, (p. 210)

You are correct, Sir

Despite the fact that the essays in What Just Happened are ancient by Internet standards, Gleick doesn’t get much wrong in them, and his assessment of Microsoft is no exception. As a company, to this day, they continue to try to leverage what he calls power points. And while they’ve failed in some cases (music, search, mobile), they knocked it out of the park in others (desktop software, document management, development platform).

And I think the most important thing for me about what Gleick’s saying here has less to do with Microsoft (or any other specific company) and more to do with the general principle of leveraging power points. In the thirteen years since he wrote this article, the companies that have been able to find and leverage power points have achieved massive success.

iPod, iTunes, Microsoft Office, SharePoint, .NET, Google, Android—all these products are great examples of what it means to leverage power points…and have made their creators (and their business partners) huge amounts of cash. And along the way they’ve given us consumers some killer products that have changed the way we work and live.

But all this stating of the obvious begs an interesting question or two:

• What are the power points currently up for grabs?
• How are things looking for the main contenders (and maybe the dark horses most folks are unaware of)?

The final word

Over the course of the next few posts, I want to take a look at some of the areas where I see power points up for grabs today.

• Social Business Software—this is an emerging domain that has a whole new cast of players jockeying alongside industry giants to gain control.
• Document Management—this one has been settled since shortly after MOSS 2007 was released and has seemed in the bag for Microsoft through the release of SharePoint 2010…but there are rumblings on the horizon that make Microsoft’s domination less-than-certain going forward.
• End-user computing hardware—aka, tablets, this one has the potential to restart competition over previously settled power points like browser, desktop software, and development platforms.
• The application layer—aka, SaaS, The Cloud, the app store model, etc., this one is less about outsourcing than about the balance of power in how businesses procure software.

In the meantime, I’d love to hear from folks out there about Gleick’s ideas, my take on them, or your take on them. While I let the next post percolate, jump in, and let’s get the conversation started!

I recently finished What Just Happened, a collection of his technology essays written from 1991 – 2001. He covers a wide range of subjects, from WinWord user groups to the future of money in the digital age and the quality of early-90s internet porn. It’s not only a real page-turner, but an amazing time capsule from the earliest days of the Internet.

I’m going to review the book later this week, so I won’t say more in that vein here. But I came across a passage that really got me thinking about the role information plays in human culture, both for how we understand ourselves and contemporary society as well as our historical ancestors and their culture. It’s long, but worth reading in full to set the stage for this post (which is even longer).

Who, if anyone, will decide what parts of our culture are worth preserving for the hypothetical archaeologists of the future? Can any identification scheme help readers distinguish true copies from false copies in the online world’s hall of mirrors? What arrays of optical or magnetic disks might provide reliability and redundancy for more than a few years of storage? Still, hope comes from the simple truth that the essence of information does not lie in any technology, new or old. It’s just bits, after all.

In the world before cyberspace, countless bridge hands were played and words spoken and memory vanished like vapor into the air. Think of all that data, dissolving no sooner than it was formed. Once in a while people managed to snatch a bit back from the ether, with pen or paper or, later, audio- and videotape. They succeeded in saving for posterity a fair portion of what was worth saving: the speeches of Lincoln (the major ones), the poetry of Shakespeare (but not quite reliably), the plays of Sophocles (except the lost ones), and a few dozen terabytes more.

James Gleick, What Just Happened (pp. 200-201)

Although Gleick’s writing about our penchant to keep everything digital, he’s skirting around the edges of some concepts that are fundamental to how we think about history. I want to unpack the most interesting of these here in some detail, because I think they not only help us view Gleick’s ideas in a larger context, they help us see these historiographical concepts in a new light as well.
We don’t ever have everything

The first thing to realize is that everything from the past doesn’t (and cannot) survive—by default, the artifacts we have left to us are always a subset of the superset of everything that used to exist in that culture.

Seems simple enough, but this truism has profound consequences for historians, because the way you interpret an artifact and its context has everything to do with how well you understand its relation to the larger superset of things it once belonged to.

Context is everything

For example, 2000 years from now, when archaeologists comb through the remains of a twenty-first-century U.S. city like Arlington, Texas, they’ll find the remains of clothing indicating that the Pittsburgh Steelers won Super Bowl XLV. What’s more, they’ll likely find lots and lots of it—tens of thousands of examples, in fact. And they’ll probably also find them in other U.S. cities in similar numbers.

How are these future archaeologists to interpret their find? If they know nothing else of Super Bowl XLV, then they have a simple conclusion: the Steelers won it.

If, on the other hand, they’ve come across contemporary references to Super Bowl XLV, they’ll see that those references indicate that the Green Bay Packers won Super Bowl XLV—and what do they do with that? Do they believe a single reference over tens of thousands of physical artifacts that suggest something different?

For these hypothetical future archaeologists, getting the real meaning of their find right depends entirely on understanding the larger context of how we marketed sports merchandise in the twenty-first century, and whether those future archaeologists will know that is anyone’s guess.

Never talk about religion, politics, or sex

This may have seemed like a silly example, but it raises the same fundamental issues that a spectacular find like the Dead Sea Scrolls does. These texts, which seem to be written from a radical, non-mainstream Jewish point of view, were found in caves in the desert, with no definitive indication of how they got there. And how you chose to explain how they got there has profound implications on your understanding of Judaisms in the ancient world.

On the one hand, you can argue that a radical group of non-mainstream Jews living in the desert hid them there for posterity. Following this line of reasoning, the ideas in the texts represent a fringe element in the world of ancient Jews. This is the explanation most folks who study these things subscribe to.

On the other hand, you can argue that mainstream Jews, in advance of a Roman invasion of Jerusalem, grabbed whatever texts they could find from the Jerusalem library and took them out in the desert to hide them for posterity. Following this line of reasoning, the ideas in the texts represent mainstream Jewish points of view (or at least points of view tolerated by mainstream Judaisms).

Now, if you think BPM-ACM or SharePoint versus big ECM debates are hotly contested, you ain’t seen nothing yet! So I’ll leave the debate over the real context of the Dead Sea Scrolls to those who know more about this than I do (with a nod to Norman Golb’s pioneering work for those who are interested in digging deeper).

But no matter which side of the issue you ultimately come down on for the Dead Sea Scrolls (or Super Bowl XLV for that matter), you can see how absolutely critical context is to understanding the meaning of an artifact.

Wait, it gets worse

If that were all, historians could maybe sleep well at night. But the real problem is that the farther we are from the original provenance of an artifact, the less context we have. For example, the superset of “all things that exist in Chicago in 2011” gets smaller and smaller with each year that passes.

And even that might be surmountable if it weren’t for the fact that, 2000 years from now, when faced with our greatly reduced subset of all things that existed in Chicago in 2011, our hypothetical future archaeologists won’t be able to know with certainty how the original superset was reduced over the intervening 2000 years to reach the subset they have before them. That is:

• Did it happen naturally, randomly, during the usual course of events?
• Did people who lived after 2011 consciously save and destroy objects for some purpose?

The answer, of course, is that the superset of all things that existed in Chicago in 2011 was reduced in both of these ways over many occasions through many discreet events (e.g., fire, flood, negligence) and by many different groups of people with many different purposes for doing so.

Core samples, random samples, skewed samples

The fact that random and conscious forces acted on the superset of all things that existed in Chicago in 2011 to produce the subset they have before them should give our hypothetical future historians pause: how will they determine whether the subset of all things that existed in Chicago in 2011 they have before them represents a core sample, random sample, or skewed sample.

• A subset that’s a core sample would contain elements from across all areas of the superset, maybe not in exact proportions, but fairly evenly and give a good representation of the cahracter of the original superset.
• A subset that’s a random sample would contain elements from across the superset in proportions that are not representative or meaningful in any way—they are a scatter-shot collection drawn according to no particular logic from the original superset.
• A subset that’s a skewed sample would contain elements from the superset that have been preserved out of proportion to their original distribution, whether by accident or by design.

I’ll dig deep into my previous life as a Historian of Christianity and Judaism for an example that speaks to this point.

The past is a mirror

Ancient Alexandria was a fantastic, cosmopolitan city perched on the southern rim of the Mediterranean Sea, which, for many centuries, was ringed with lots of fantastic cosmopolitan cities. Greek was the primary language of Alexandria, and citizens from many cultural backgrounds lived there—including a thriving, vibrant Jewish community.

The Jewish texts we have access to today that have survived from ancient Alexandria are a subset of the superset of all texts that existed at the time there.

Centuries later, there was a thriving Christian community in Alexandria, also Greek speaking. And they left us texts that are a subset of the superset of all texts that existed during their time in Alexandria.

Here’s where things get interesting, because the Jewish texts from Alexandria seem like direct antecedents to the later Christian texts—so much so, that historians often talk about an Alexandrian school of thought that unites both Jewish and Christian thinkers across centuries.

But, if you’ve been reading this post carefully, you should be a bit skeptical about this claim. After all, drawing a direct line of influence and continuity across the centuries between these Jews and later Christians assumes a lot about the context of these texts…and just about all of it is missing.

There are no historical accidents

We could just as easily (and perhaps much more plausibly) assume that later Christians had to make decisions about which texts of their Jewish predecessors to save and which not to save—and faced with finite resources and the difficulty of copying texts in the ancient world, wouldn’t they have naturally preserved the texts that resonated with their views?

And if this is true, then what do we do with all the texts they didn’t choose to preserve, all the points of view, all the different ways of being Jewish that didn’t make the cut?

We can’t recover them—they are lost forever (or at least until someone finds them in a cave when excavating the foundation of a new shopping mall). But it does change how we view the Jewish texts that do survive, i.e., we won’t be so sure that they represent the only way (or even the most significant way) to be Jewish in ancient Alexandria because we don’t know the context in which they were written well enough to do so.

Get to the point already

Ok, so if you’ve made it this far, I thank you for persevering—this has been a roundabout way to approach Gleick’s ideas. But here we go.

His first point is that, given the sheer volume of information we’re creating on the Internet and with electronic tools, how will anyone in the future figure out what was really going on in our culture?

Fortunately, the superset of all information on the Internet in 2011 is already being reduced through natural and human means. Sites come down, technology goes out of use, people delete information, and the once “complete” picture of the Internet at a point in time decays. Over the course of 2000 years, this decay will be substantial—who can say what will be left and how well or poorly it will represent the larger context within which we all encountered it?

So the answer to his concern, “Who, if anyone, will decide what parts of our culture are worth preserving for the hypothetical archaeologists of the future? Can any identification scheme help readers distinguish true copies from false copies in the online world’s hall of mirrors?”, is that, like all cultural artifacts, the artifacts contained in our Internet will endure and pass away according to a logic that is larger than we are, driven by people we will never know.

Not sure if that’s comforting, but at least it puts us in the same boat with everyone who ever came before us.

Can’t we do something about this?

Gleick’s second point is that we should take comfort from the fact that, in the past, folks managed to identify what was important and save it for posterity:

They succeeded in saving for posterity a fair portion of what was worth saving: the speeches of Lincoln (the major ones), the poetry of Shakespeare (but not quite reliably), the plays of Sophocles (except the lost ones), and a few dozen terabytes more.

If they did it, surely we can do it—so take heart, weary web surfers…

But as you might be thinking based on the rest of this post, it’s far more likely that what was saved was a combination of accident and prejudice, and that it’s important only because it has been saved, not the other way around.

If we had all of Sophocles’ tragedies, Lincoln’s speeches, the totality of Paul’s letters, or Shakespeare’s rough drafts, would we still view the paltry stuff we have now in the same light? Or is it the sheer fact that these things somehow survived (through a combination of luck and human determination) precisely the reason that we find them meaningful?

We are (almost) all of us curators these days. We’ll spend time after hours and on weekends to comb through the information out there and promote what we find useful, important, interesting. Heck, this very post is an example of this behavior. In the first decade of the twenty-first century, curation and filtering are the skills of the new information elite—there’s more than enough (actually too much) content to go around, so the real value these days is in raising up the truly valuable for your community.

The final word

So in the end, I don’t share Gleick’s worries—and maybe, with hindsight, thirteen years after he wrote this essay, neither does he. We create things to use here and now, and over the course of the years, as we die away, some of our things do, too. And later, 50, 100, 500, 1000, 2000 years later, folks will stumble upon our things and wonder about the people who made them, who used them, who saved them, who destroyed them. And they’ll understand us as well (and misunderstand us as deeply) as we misunderstand all those who came before us.

With that done, I want to turn to look at some of the particular ECM needs of for-profit ed providers and how fostering better content management practices can help transform these organizations.

Growing pains

The biggest challenge facing for-profit ed providers is growth, whether organic growth or growth by acquisition. Over the last six or seven years, for-profit ed has experienced huge growth, and while this is obviously a good thing, it brings significant challenges.

• Operations - scaling to keep pace with growth is difficult, from back office functions like HR and accounting to front-office functions like enrollment, financial aid, or curriculum development
• IT - not only is scaling existing systems a challenge, but integrating new systems from acquisitions can quickly overwhelm even a mature technology function
• Personnel - the difference between for-profit and traditional educational cultures is vast—when a traditional educational organization is acquired and becomes part of a larger for-profit organization, sparks fly and change management is a daunting task
• Student experience – large for-profit ed providers are typically a patchwork of content sources, delivery platforms, and service organizations—and if this makes things difficult for employees, you can imagine what it does for a consistent, quality student experience
• Curriculum development – on the one hand, large-scale acquisitions give for-profit ed providers more content than they know what to do with, but on the other, they also have to build agile, effective curriculum development functions to allow them to move into new markets before their competition

ECM solution areas

Although the challenges for-profit ed providers face as a result of their rapid growth don’t have a single solution, there are some significant ways that ECM can contribute signally to how organizations face these challenges.

• Structured Authoring and Publishing – to enable a workflow driven authoring process that leverages modular content creation and reuse, author once – publish many, and multiple-channel output
• Enterprise Collaboration – to enable virtual teams, distributed expertise management, and knowledge sharing
• Workflow/Advanced Case Management – to digitize, automate, and streamline core processes, both transactional (e.g., application, enrollment) and knowledge worker (e.g., financial aid decision-making, grading, customer service)
• Document Management – to improve how documents are created, managed, and accessed across the organization
• Portal - to provide user communities, discussion forums, and alternative feedback channels for employees
• Socal Media Integration and Community Development – to provide user communities, discussion forums, and alternative feedback channels for students
• Customer Communication Management – automate, standardize, and optimize how providers communicate with students across all channels

Real-world examples

For-profit ed providers are addressing these ECM solution areas in a variety of ways. He’s some of the real-world solutions I’ve seen in my travels.

• Centralizing the management of student records using paperless, straight through processing and an enterprise image repository
• Streamlining student on boarding and management with self-service web tools
• Standardizing the curriculum development process with an authoring platform
• Creating virtual “student unions” with online community tools
• Creating communities of expertise to connect SMEs across the organization, whether in home office (such as curriculum developers or tech leads) or campus functions (guidance counselors or instructors)

The final word

The for-profit ed market, as breakneck as its growth has been, shows little signs of stopping. As this market continues to expand, and providers continue to grow organically and through acquisition to gain and maintain competitive advantage, they’ll be under increasing pressure to streamline their operations. The ECM solution areas I’ve outlined above, along with other enterprise domains like CRM and ERP, will be central to their continued success.

While I muse on what the next transformational market in this series will be, I’d love to hear from folks out there—thoughts on for-profit ed? Other perspectives on how they’re using ECM to transform their business? Is there something I’ve missed?

Jump in and share your thoughts with all of us and let’s get the conversation started!