ECM Predictions 2112

Rather than hedging my bets by making predictions that are difficult to disprove (click here for a bunch of those), I figured I’d try an alternate strategy in this post: predictions that none of us will be around to verify.

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…

1. The end of the paper office!!!!
2. Shared drive volumes reach the tipping point, organizations finally tackle the unstructured content problem.
3. Big ECM-SharePoint integration ready for prime time (this time I mean it!).
4. SAP will acquire Open Text.

The final word

So there you have it—ECM a century from now. I encourage you all to heckle me today (as usual), but feel free to encourage the generations that come after you to heckle the generations that come after me…and let’s get the conversation started!

Auto-classification: a bit of a stretch

Last post I kicked off a series on auto-classification, which has been increasingly top of mind for my clients of late. I want to tackle auto-classification from a few different 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 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).

Shepley v. Auto-classification

We’ve been told that auto-classification is here, or about to be here, for years now, and every time it turns out to be a lie. The road to working, housebroken auto-classification is littered with casualties (the Wal-Mart DVD recommendation engine is the highest profile failure that comes to mind, but we’ve all witnessed demos and POCs that crashed and burned) while I know of only one real (public) success story, the DOD. But a government entity with no shareholders and massive resources and time at their disposal is not exactly the operating model corporations are looking for.

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!

Taking the plank out of my own eye

My last two posts have cast a critical eye on the RFP process, pointing the crooked finger of judgment first at ECM vendors and then at ECM buyers. Convenient for me, since I fall into neither of these groups.

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…

The other side of the coin: 7 things NOT to do if you’re running an ECM RFP

In the last post I gave it to ECM vendors on the chin about how they can be their own worst enemy during the RFP process, and, based on the response from you all, it seemed to strike a chord with many people out there.

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!

Two short: eight things NOT to do if you’re an ECM vendor at an RFP final presentation

Maybe it’s the lack of sleep from having a newborn or the unreliable power grid (and therefore air conditioning) this summer in Chicago, but I’ve got some sand in my shorts about how I’ve seen ECM vendors handle RFP presentations.

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…

Bundle of joy

My wife and I just welcomed our second child into the world last week, so I’m taking a few weeks off from the blog to spend some quality time with my family.

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

I hope you all enjoy these while I’m gone…see you in June when I get back on the blog train!

Cheers,

Joe

The money and the power

Those of you who are regulars here know that I’ve been digging into James Gleick recently. I published a review of What Just Happened on my other blog, and my last post here took Gleick as a jumping off point for waxing historical; this post does the opposite: I want to take a particularly sharp insight he made about Microsoft in 1998 and use it to think about where we’re headed as we approach the midpoint of 2011.

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!

Posterity, or, Why I decided not to bury that time capsule after all

I’ve been reading a lot of James Gleick recently. For those of you unfamiliar with Gleick, he’s a fantastic science and technology writer, best known for his biographies of key figures in the history of science and mathematics (Feynman, Newton).

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.

Transformational ECM V: For-Profit Education (Part 2)

Last post I started to take a look at how enterprise content management (ECM) is transforming for-profit education providers. I began with an overview of the for-profit ed space, because although most folks have heard of it, it’s not as well-known a vertical as CPG, financial services, insurance, etc.

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.