This is of course complete and utter rubbish. SharePoint sites continue to grow unabated,  and nobody has even started to deal properly with e-mail as a record, let alone the plethora of technologies that Web 2.0 encompasses. You can certainly find examples of brave souls who have made progress if you look hard enough, but they are the equivalent of a few grains of sand on a beach.

Legal has zero clue what IT actually does (beyond provide a poor quality helpdesk). Records Managers have nobody's ear but the RM community. Business thinks it knows best and listens to no one. Ironically the vendor community is for once the voice of reason here. Strip away the marketing hype, and vendors have made huge progress (as our research details) to deliver solutions that can actually provide excellent ERM capabilities in today's highly fragmented and ever growing enterprises. Although product offerings vary subantially among individual vendors, the problem does not lie with the technology.

What matters, more, though, is who's going to fix the situation? More specifically, where does one start to fix something that is so terribly broken?

In my personal opinion the place to start is at the beginning, and to question ERM's "raison d'etre."  Once upon a time office workers made use of filing clerks, who in turn made use of  cabinets, folders, and file plans. Information was managed, and no one needed to know the magic behind it, it just worked.  When you needed to get hold of a piece of information the filing clerk would get it for you, and when you needed to dispose of information the filing clerk would likewise oblige. When you moved onto better things or fell under the proverbial bus, you did so safe in the knowledge that the next person could pick up (information-wise at least) where you left off.  Not so in today's office: information gets lost, information gets hoarded unnecessarily, and when you transition upward or onward, you often leave the equivalent of an information black hole behind you.

The role of managing information through its lifecycle to destruction is arguably more relevant, vital, and important today than it has ever been, but who's responsibility is it? Records Managers are considered impractical and out of touch with modern reality, IT is clueless but sounds clever ("don't worry it's all backed up....."). Business listens to no one; instead they believe they have the task in hand via their zip drives and desktop search.

I am not sure if my need to rant today is connected in someway to the recent discovery online of a photograph of myself from my days in the Army, and my subsequent visit to the Military Museum in Winchester. In turn possibly stirring up a deep seated need to rally the troops, or more likely in my case to start an armed insurrection. But whatever it is, I do passionately believe that the time is long overdue to have a battle royale over what ERM should be, as opposed to what it currently is or is not. A clean slate is required, and fresh ideas based on the reality of overwhelming volumes of information are essential to the debate.

Let's start with the assumption that if you have a large number of subsites, chances are you have complicated politics.  Your reaction may be to just do whatever it takes to get business units into the system, including adding complicated functionality specific to a unit.  I've personally been a party of this approach, but you can easily end up with Frankenstein systems that cannot be maintained or innovated.  Why?  If you implement a disjointed system then it's harder to regression test and to add features since you don't know all of the impacts you will have in making changes.

Let's consider the steps of a subsite launch:

1. Request.  The process for requesting a subsite.
2. Approve.  The process to approve or reject a site creation.
3. Negotiate.  Negotiating the details, especially the functionality.
4. Train.  Training the team that will be managing the site.
5. Create.  The technical creation of the subsite.
6. Embody.  The site owners adding their content.
7. Review.  Quality review before launch.
8. Launch.  Launching the subsite.
9. Maintain and Innovate.  Ongoing maintenance and innovation across all the subsites.

When deciding on your architecture and processes, consider the cost of each of these steps, and not just some.

There are several approaches / philosophies to subsites, but one extreme would be the completely lenient approach where everyone can do whatever they want on whatever platform they want.  In that case, steps 1 through 8 are easy (or last can be dealt with on a group-by-group basis).  But watch out for number 9: if you wanted to add a new and innovative feature across all the sites?  Share content across sites automatically?  Standardize look and feel for you site visitors?  Next to impossible. 

Probably the most common approach is a centralized platform, but where the core web team is lenient about what sites are created and the functionality details.  This can happen when there is weak governance, with the basic idea of "let's just get them in a common system first."  In this case, the request and approval process is easy.  But watch out: the Negotiate stage can take a long time.  Now you've got to not only work out site or group-specific functionality, but argue about which features should be added.  Also, the training and creation process isn't standardized, so takes more time.  Similarly, the review process can take a long time as there may have been misunderstandings of what is possible and not possible.  But the real problem is the maintenance and innovation.  The system becomes so complicated that it's difficult to maintain.  Also, if everyone did their own thing, then it also is difficult to roll out innovative features across all subsites.

Another approach is to "package" your subsites so that creating a new site is almost trivial.  This could include an extremely simple form that would be filled out to create a site, that would just have selections (no free-form written requirements) for the different options of creating your site.  In general, the negotiation would be simple since most folks would want to just fill out the form and get a site.  But if an option wasn't available for a particular group, then there could be a discussion of whether it was worth adding the functionality to the core system (or adding a parameter for an existing piece of functionality) so that it is preferably available to all sites for use.  Obviously negotiating changes to the core system would take time, but by carefully guarding the core functionality, and biasing toward packaging items for everyone, you wind up with a more stable system.  In addition, your system is more maintainable and features can be rolled out more easily across all subsites.  Training should be easier as well.  To pull this off, you will need strong web operations management, and in particular strong product management. 

Yes, there are other possible approaches.  But one thing is for sure: consider all the steps of your subsite and platform lifecycle when deciding on your subsite creation approach.

There are at least five reasons for this phenomenon, and specific steps you can take to mitigate potential problems.

1) RFPs are getting better
In the technologies we cover at least, we're seeing fewer check-list RFPs and more narrative-based requirements. We also see larger enterprises profiting from preliminary RFIs. (Hopefully our advice over the years has played a modest role here -- but many others are offering good counsel as well.)

Good RFPs tend to create more work for the vendor, and if a potential bidder thinks your project is a stretch, they will more readily beg off.

But those who think they offer a good fit -- and it's all about "fit" -- will usually put in the extra effort.

Indeed, the most important by-product of better RFPs is better vendor responses, even if fewer in number. Responses become more targeted and relevant. This makes it easier to discriminate among them. So there's another trend we've noticed: less contentious down-select meetings. When you're clearer about what you want and bidders have to be more specific about their real capabilities and tendencies, decisions come more easily. (Ditto for subsequent down-select decisions, including after the all-important test phases.)

Of course, not all vendor responses will be as targeted as you'd like. And to be sure, vendors still don't have to look far to find horrible RFPs. But this leads me to point #2...

2) Vendors have become more discriminating
The very economic downturn that has you thinking you're in the driver's seat has vendors watching their cost-of-sales more carefully than ever. In short, they're less likely to chase. That's A Good Thing for all concerned, but also should give you some pause. If you're looking for the right fit, you want to appear at your best when soliciting proposals.

So, avoid nebulous, unprioritized requirements, and never use canned RFPs. Above all, figure out a plausible set of candidate suppliers. When vendors see wacky short lists, they typecast you as an amateurish or potentially indecisive prospect, and are more likely to beg off. Do your homework first.

Then inform the targeted bidders that you chose them through a substantive review process. If they haven't met you, they may balk at responding to an RFP over the transom, even though you've spent a lot of effort figuring out that they could offer a good fit. Try to talk to them on the phone before you send an RFP, and invite a preliminary webinar where useful. Which leads me to point #3...

3) Vendors remain a little paranoid
Whether you like it or not, you may need to assure prospective bidders that the deal isn't "wired" for a competitor. Vendors have always been suspicious that they're getting led around by the nose when a decision has already been made -- where the customer just goes through the motions, perhaps using a fake selection process to secure a better price from the chosen supplier.

In my experience, vendors are overly paranoid, and should give more benefit of the doubt. But they've been burned enough that you can understand their fears, especially if they don't have some sort of relationship with you that establishes initial trust.

[As an aside, at The Real Story Group we work only for you the technology buyer, but on principal we won't advise on nominally competitive procurements where the outcome is pre-ordained and bidders are being exploited. We try to explain to any customer issuing a wired solicitation that it's a smaller industry than they think, and in the long run, reputations matter. Vendors need to adhere the same ethical standards as well.]

4) Systems Integrators are always discriminating
In maturing marketplaces, RFPs increasingly target systems integrators (SIs) or other services firms, rather than software vendors. (We've recommended this on several occasions recently.) Also, when deeply vetting open source platforms, you will often need to turn to a consultancy to bid. In any case, the SI must bring a particular solution to the party, but has to justify both the tool and their organizational fit for your needs. This type of combo procurement can become tricky for you, but also potentially very effective.

Although SIs receive the lion's share of global technology spend, they have narrower profit margins and are therefore careful about what they go after. Also, the best ones are busy. Often very busy. That has them looking for engagements that represent a good fit. A carefully-crafted RFP will let them know if they fall in your sweet spot. A loopy RFP will tempt them to perceive you as a "squirrelly" client -- the kind they lose money on -- so they decline to bid.

5) The vendor screwed up
Sometimes vendors fail to bid simply because of bad timing or other mistakes. There may have been a hiccup in their sales process. Maybe the reps and proposal writers in that region were over-committed that month. Maybe they were in the midst of replacing personnel. Maybe they didn't fully grasp the import of your solicitation.

That's all their fault, not yours. So it's tempting to dismiss them as a poor partner as a result. But you shouldn't over-weight a vendor's sales acumen -- or lack of it -- in your decision, especially if you think they might make a good fit against more enduring criteria like functionality, architecture, and TCO.

Here's how to address this. Confirm whether each vendor is going to participate early in the proposal process so you can give them a chance to overcome issues of poor timing, insufficient understanding, or human mistakes. Don't worry that a candid conversation will make you seem weak-kneed or supplicating; it will likely raise the vendor's interest in participating and you can still remain discriminating in your reviews and negotiations going forward.

By the same token, you shouldn't coddle a potential bidder, either. Sometimes non-responsiveness really does indicate deeper incompetence or disinterest. Just take the extra step to find out what's really going on.

At the end of the day...

Fewer bidders isn't necessarily a problem. Among other benefits it means less reading! And better reading, since, done right, the responses should feel more relevant to your concrete needs.

The problem comes when you don't get a sufficiently discriminating set of responses, and/or a particular supplier that you really wanted to participate begged off instead. To avoid this, follow the advice from #2 and #5 above about communicating early with potential bidders.

Also remember that an RFP and attendant proposals -- while critical -- represent only part of the selection process. Our evaluation research identifies empirical, test-based steps (specific to each type of technology) that you should take before making a final decision.

In the end, like so many things, quality is more important than quantity. Vendors who try to be all things for all customers will respond to vague RFPs. The best fit for you will more likely emerge from a stronger, more focused solicitation. If we can help, please let us know.

As subscribers to our SharePoint Watch research know, the platform presents several important challenges to licensees.  SharePoint is somewhat weak in centralized administrative controls (fine grained controls aren't universally available for things like security), and management capabilities essential for larger organizations often require 3rd-party add-ons. Of course, these shortcomings will get worse if SharePoint spreads virally within your enterprise.

That said, firms must also take responsibility in implementing proper governance policies that normal humans can understand and apply; too often organizations create draconian and inaccessible governance plans or simply leave users to their own devices. Both situations create more harm than SharePoint's own provisioning management issues.

SharePoint is weak in some areas and strong in others.  However, this is one place where I tend to side with Martin White, of Intranet Focus. He once remarked that SharePoint, more often than not, points out an information management issue that most firms didn't know they had because they weren't managing their information prior to implementing SharePoint. 

Take for example a recent study by University College London into the UK's groundbreaking transition to electronic patient care records for the National Health Service. This initiative has come at a cost so far of $360 million dollars, and (to quote) "will require a high cost and an enormous effort to fulfill it's potential." That's a nice way of saying that the effort to date has largely been a waste of time.

The problems that have dogged this particular initiative are the same problems that arise in almost all similar projects, regardless of the industry sector or budget size. 

• Undertaking a full content audit, and ensuring that all the original data is not only accurate but also consistent, is difficult, time consuming, and costly
• Migrating content from (often disparate) systems is always a major challenge
• If you have not proven the value of the new system, people with stick with the old
• Validating and continuously improving the new process without full buy-in from the old users is near impossible

Though I do have Luddite tendencies, I am not advocating that you should avoid moving manual and paper-based processes to electronic methods. But I am advocating that you do so with your eyes open to the inherent complexity and difficulties.  Build a business case first, and ensure you have a full grasp on the work involved. Electronic processes are not by default any more efficient or cheaper than manual systems. 

And as for the rather cynical attempt of the ECM industry to push the benefits of Green IT, digital data is often no more "green" than paper. Sometimes it's worse. 

One final consideration is that of confidentiality. If you have highly confidential information remember that it is far easier to inadvertently expose that data to a multitude when it's in electronic form, than paper. 

Again to be clear, great cost and efficiency gains can be got from the move from manual to automated processes. But the move is often far bumpier and less clear-cut in terms of benefits than many think.

I spent this past week at the AIIM UK  Roadshow talking to buyers and end users of ECM technology. My mantra was that we often do not recommend to our research subscribers that they invest in more technology. Rather that you understand better what tools and platforms you own already, and make best use of it. It's an unusual proposition from an industry analyst firm, but as we have 100% independence, it's one we're happy to give.  Likewise we have no problem in advising our customers to think twice before diving headfirst into projects that are based on the belief that automation in itself equals improved business.

It's a surprising acquisition from two angles, first that CA should have seen so little value in this division to dump it, and secondly that Autonomy, already something of a holding firm with overlapping products, should feel the need to buy still more overlapping technologies.

That being said CA had two decent products, that essentially provided a two-level approach to compliance. (We evaluate them both in our ECM research.) The first, a general and very practical, bucket-style approach to retention, that could have the second (Records Manager) added to it for those with a need for more granularity.  However, both were acquisitions by CA. Records Manager was from the MDY acquisition in 2005 and had previously been called "FileSurf." The second, Message Manager, was from a firm called iLumin that was also acquired in 2005, and at the time was a market leader in e-mail management. 

Neither acquisitions really settled at CA, and never really found themselves a part of CA -- itself a huge and at times difficult organization.  At first glance it seems CA did not really appreciate what they had, or the strategic value it could provide to their overall data management practice. 

Autonomy, though, already has records management systems (from Meridio and Interwoven) along with archiving from the Zantaz acquisition.  Why they should need more I don't know.  The only thing that is clear from today's announcement is that Autonomy has further confirmed the general impression that they are a holding company. Undoubtedly Autonomy will soon announce that the CA products have been integrated via "The IDOL Platform", but we would strongly advise buyers to take time to see how this really works itself out -- as well as the long-term costs.

Yet many organizations seem to be under the impression that if they buy eDiscovery software something magical will happen: That regardless of the complete and utter chaos that constitutes information management within their organizations, at the push of a button or two the eDiscovery software will find the required information, and then present it in a neat and secure format, thereby meeting the eDiscovery request.  Even in the world of Harry Potter, there is no magic that powerful.

A good example of just how far the hype is from reality was nicely illustrated by Goldman Sachs this week. In responding to an FCIC (Financial Crisis Inquiry Commission) request for information, Goldman provided 5 Terabytes of data, the equivalent of 2.5 billion pages of documents. To quote the FCIC Chairman, "We did not ask them to pull up a dump truck to our offices and dump a load of rubbish."  Now I have no idea whether this was simply a deliberate attempt to obfuscate and hinder the crisis probe -- as the FCIC seems to believe -- but I doubt that it's the whole of the story even if it is a part of it.

eDiscovery requests fall into two main categories: the easy and the impossible.  The easy ones relate to specific individual and a specific transaction. By freezing an individual's email account and network folders almost everything you have been asked to look for is found.  The impossible category consists of almost everything else. In these cases lawyers sort things out in back rooms, usually come to a compromise, and when they can't, either fight the request through the courts or simply settle.  When a government probe like this comes along though you have no real option other than to comply, or at least attempt to as best you can.

To meet eDiscovery requests with ease, you need solid information governance across the whole organization to be in place, and you need a lot more than a search engine on steroids.  When firms have billions of documents or even just millions, knowing exactly which documents are needed, and how they related to each other in a chain of events resulting in an eDiscovery request, will require a lot of manual trawling, lawyers at high hourly rates, and pragmatism for the foreseeable future. 

The only good news is that many firms are now recognizing that no magical software will ever be able to fix this situation. You need good information management practices, and a plethora of content technologies (ECM, Search, Archiving etc) all working in tandem. 

In the context of the debate around a new U.S. Federal government OMB policy on the use of persistent cookies, as well as other national governments' interest in enabling site visitors to opt out of web analytics tracking, Google's stated goal is to make opting-out "easier."  The company has responded by developing a downloadable browser plug-in that disables Google Analytics data collection from all sites using Google Analytics.

Why is downloading a plug-in considered any easier than disabling cookies from within your browser options? Or adding websites to your exclusion lists? 

I can understand why some people may want to opt out -- especially for particular websites -- but it's important to understand that Google has selected the "nuclear" option here in lieu of using its market authority to promote a more modest, site-specific approach. (Competitor Omniture, now part of Adobe, provides a site-specific opt-out service, but doesn't promote it heavily.)  Adopted widely, the nuclear option will add to the myriad difficulties that already compromise web analytics accuracy. The impact will be magnified if Google's approach gets endorsed through the new Federal cookie policy and other government policies.

To be clear: I understand reasonable privacy concerns.  My alternative would be to provide site visitors with the option to use their browser to opt out of tracking from the specific website they are visiting, or opt out of all tracking from the particular web analytics solution, but not automatically default to the latter, as Google has done.

Why would Google promote the all-encompassing opt out? After all, it's the biggest web analytics service provider in the world by a large margin.  Global opt-outs hurt its customers.  Except that its customers don't pay anything for the service, whereas government goodwill is critical to Google's success in many other lucrative areas.  For Google Analytics customers, it's just another reminder: there's no free lunch.  

What is common across them all is the desire to consolidate, and to gain more value from the huge volume of information sitting in documents across their units. Sometimes this is no more than a desire to find things quickly, wile in other cases the goal is to merge and integrate business process tasks with relevant and current information. In still other instances, the enterprise simply needs to reduce costs, do more with less.

Multiple repositories can come in many different forms, be they hundreds of SharePoint sites, a handful of massive ECM systems, or a combination of shared drives and Outlook folders. But they all represent the same basic problem. "I have the information I need, it's somewhere, but I can't access it or find it easily, let alone leverage its full value."

When trying to come up with an approach to improve these multiple repository situations people usually consider the following approaches:

• Migrate everything into an Über Repository
• Federate the management of the repositories in place
• Start an information governance project
• Work on Information Architecture/Taxonomy/Metadata
• Take a federated search approach to the situation
• Utilize API's and/or EAI to integrate at the back-end
• Build a portal/mashup to integrate at the front end
• Use BPM to integrate in the middle
• Go the SOA route to deliver shared ECM services

In fact there are still more approaches you could take, and the options above are not mutually exclusive, but they are the most common.

What is not so common is taking an approach that tries to address the bad practices that created these situations in the first place.  Somebody once said, "It's OK to make mistakes, but not OK to make the same mistakes repeatedly." Yet that is what so many organizations do when it comes to managing information effectively.

Rather than jumping straight into one of the options enumerated above, I would advise you to take a step back and to first consider starting every information management project with a major cleaning exercise. 

For example, if documents have not been accessed in X period of time, let's be honest, they are unlikely to be accessed ever again, and in most cases there is no legal or regulatory requirement for you to hoard dead information. So take the chance to identify deadwood data, and get rid of it, preferably by a formal disposition process, or if you must then simply move it to cheap offline storage and "archive it."  But whatever you do, work toward a situation where only active and relevant information is sitting in your silos. Move or destroy information that is not.

For many organizations such a clean out delivers more value than the rest of the project activities put together. In some cases volumes of content get reduced by 80% plus, and as a result when you are browsing, searching, or mining content you are only accessing current, relevant information.  It also makes the job of consolidating, migrating, or integrating information silos much more worthwhile. 

This should always be your starting point: clean data. Otherwise you'll spend most of your time knitting together in one way or another an awful lot of useless files.

When I advise our clients one to one, or simply chat with people for research purposes there is almost always a common thread.  People tell me that they use SharePoint, or Documentum or Open Text or whatever, for managing their corporate documents, but when I push a little further almost without exception, a much larger number of documents within the organization sit in folders on a Network Drive. The actual document management systems account for only a small fraction of the documents within any organization.

Network drives have never been good places to manage documents, nor will they ever be -- yet that is where most of them sit.  It's depressing really, but nevertheless it is reality. Network drives (or shared drives as they are often referred to) give the illusion that you are doing something constructive to store and manage documents, but really they are just dumping grounds, expensive trash cans.  The only difference in practical terms is that trash cans actually get emptied at some point. Shared drive trash just grows until they become overwhelming mountains. 

But what to do?  A starting point is for organizations big and small to recognize they have a problem, that things are unmanageable and boldly declare "We are document hoarders!" You may even want to do a fearless inventory of your content, and humbly address your shortcomings.  Implement a retention and disposition policy, and learn to let go of documents that no longer have value.

Shared drives are addictive and a hard habit to kick; get some outside help from others that have experience in kicking the same habit.  And if you ever do sort out your shared drives, consider yourself a success, and then turn your attention to the documents sitting in e-mail folders....

We could debate what governance means -- I define it as consistent structures and processes for making effective decisions -- but everyone agrees governance is critical to long-term success.

I don't claim to be an expert on website and IT governance, but after a couple decades of helping people make technology decisions, I'll boil down my thoughts on the topic to one simile:

Governance is like sex.

• People tend to talk about it more than they do it, and...
• ...Most people don't do it as much as they'd like
• At least one key player needs to really want it or it will never get started
• There are many different ways to do it satisfactorily
• It's more art than science
• It's more successful in environments characterized by mutual trust
• Other people can give you a lot of good advice, but only you can make it happen
• You may not get it right at first, but that shouldn't stop you from trying
• A shared sense of fairness encourages repeatability
• In the end, bad governance is better than no governance at all

So hopefully at least by now you're smiling. If you have any particular (but not X-rated!) governance success stories you'd like to share, please chime in via the comments below.

(P.S.: I'll be touching a little bit more on web governance in my May 11 webinar, "How Do You Know If It's Time for a New Web CMS?")

Many enterprises run aging CMS implementations. Over time, what were initially small quirks and inconveniences can become more serious inhibitors:

• Perhaps you're concerned that your current CMS technology has become more of a business obstacle than business facilitator
• Maybe you've fallen so far behind or customized your installation so heavily that an "upgrade" to a contemporary version now really represents a wholesale platform replacement
• Sometimes you wonder about whether you're keeping up with the latest industry trends

We've been there ourselves.

At the same time, switching tools is never cheap, easy, nor quick. You need a solid rationale if you're going to make a move.

Register here.

The last few weeks has seen a drama, albeit not a Bollywood one, unfold. It all started when the IPL chairman cum commissioner Mr. Modi fired the first salvo on Twitter about a new IPL franchise which was being "mentored" by a ruling party MP. The MP, Mr.Tharoor, quickly tweeted back to start a scandal now being called by various names such as IPL-Gate, Modi-Gate, and Tharoor-Gate. An alert media was quick to latch onto it and generate breaking news, eventually revealing much more than the shenanigans of Modi and Tharoor.

We next saw the two protagonists leaving their coveted positions: Tharoor resigning on an emotional note in the Parliament and Modi being suspended -- ironically via e-mail -- by IPL's governing council.

This is certainly good news for Twitter: people in India who have no clue of the web now want to tweet. But what has this got to do with Content Management?

Well, the IPL scandal that's rocking the Indian Parliament and cricketing world revolves essentially around the issue of compliance. Let us examine how many of the problems could have been avoided had the IPL followed good compliance practices.

And what constitutes good compliance practices? We offer a short online course that lays them out. Let's review some important compliance considerations in the context of this scandal:

1. Executive sponsorship: IPL is a sub-committee of Board of Control for Cricket in India (BCCI). On the face of it, IPL had it's own CEO, Chairman, as well as a Governing Council (GC) of 12 members. So it appears there was a suitable level of top management support. However, it now turns out that the CEO was just a figurehead with most of the decisions being taken by a proxy. The BCCI and the GC assumed that the CEO would do his job and were caught wrong-footed.
2. Well defined governance procedures: Okay, so they created a governing council (GC). The GC boasts eminent members, including well respected cricketers, politicians, and administrators -- but all without any accountability. And just like the CEO, the GC remained a silent spectator to all the wrongdoing, never consulted on important matters. In fact, the GC members remained unaware of major transactions involving billions of dollars, since all of these were handled by just one single person. No procedures existed to ensure the placement of suitable checks and balances.
3. Identified (and prioritized) compliance requirements: What's that? Since everyone involved was making big money, no one in their wildest dreams thought they'd need to comply with legal and ethical rules. The current scandal have revealed (among other things): inconsistencies in shareholding patterns, bid and contract documents gone missing, and some suspect funding sources. No processes were defined to approve contract documents or to keep an audit trail of transactions.
4. Ability to manage change as a result new business processes: Processes were non-existent and every activity was handled in an ad-hoc manner, depending on whims and fancies of individuals.
5. Systems to monitor, audit, and enforce compliance: There were no systems and more importantly no desire to enforce compliance. Everyone was in for the love of money, not for the love of the game
6. Right tools – such as those for managing content and records – to optimize your compliance efforts: The parent body, BCCI is the richest sports body in India and also the richest cricket board in the world. One would assume that a cash-rich cricket board would invest in technology that would help them in managing records and documents, enabling processes for tracking bids and contracts and other dealings. Yet, the BCCI doesn't even have a decent web presence. Use of technology could have facilitated transparency, something they evidently wanted to avoid.

Will applying proper Content Management practices and following the steps above in and of themselves enable organizations to avoid tax evasion, illegal betting, bribes, suspect shareholding patterns and so forth? Of course not. If you have people of questionable integrity and ethics running an organization, no amount of management practices will help.

Nevertheless, technology can help uncover and document misdeeds. If IPL had followed basic compliance principles, things would not have gotten so far out of hand. And we would have enjoyed our greatest passions - cricket and bollywood -- even more.

(Special thanks to Siddharth Gongala for supplying background info. Sid is a Sports Producer for an online channel.)

Specifically, if you've been messing around with the beta version(s), hopefully you've heeded Redmond's admonition that there's no supported upgrade path to the RTM version. To quote one Microsoft rep, "Upgrade from SharePoint Server Public Beta to RTM (in-place, or database attach) for [the] general public will be blocked." Microsoft itself will migrate over its sanctioned beta-test customers, but everyone else needs to essentially recreate any pilot applications in the final version, and physically migrate data.

Meanwhile, close Microsoft partner Metalogix says they will release a migration tool in May to at least move data. (On an unrelated note, Metalogix's public website runs on SharePoint competitor, Ektron Web CMS.)

The problem here is less about significant changes in the RTM version; they seem minor, at first blush, though please comment below if I'm wrong about that. Rather, at some point -- likely later this year -- your beta installation will expire and simply stop working. So, if your enterprise got excited about SharePoint 2010 and just couldn't wait, and asked your favorite SharePoint integrator to implement some SP2010-based services, then those services will need to get re-built in (and the data migrated to) the RTM version. The level of effort will depend in part on how well they "packaged" their development.

In any case, don't wait until expiration to find out what's entailed there.

First off, it became clear quite early on that perhaps the regular news from the traditional media (newspapers and TV, but including their online presence) wasn't keeping up anymore. When the eight o'clock news actually mentioned "people on Twitter are saying..." I switched off -- I can get that real time on, well,... Twitter, following the hashtag #ashtag. Several forums kept me up-to-date with the latest news and charts from across the web, and even several blogs were better at keeping track of the latest developments. Also, I'd suggest journalists to at least take the two minutes to read the entry on Eyjafjallajökull on WikiPedia -- it doesn't look good if you know less about the volcano in Iceland than your viewers do.

But that's just the news -- if you really need the information, because you're stuck in an airport or about to leave on a planned trip, you want to know where you're going (if anywhere). Unsurprisingly, here, too, traditional communications were failing. Call centers were flooded and it was impossible to get through to airlines and airports. And many of their websites.

As first the north and west of Europe were covered in the ash clouds, then the center of the continent as well, the various sites started returning 500 "Server too busy" errors (or just no response at all). At times like these, it's immediately apparent who has contingency plans for their website and who doesn't. Some managed by putting up a low-bandwidth replacement (like, for instance, Schiphol airport did). For most of these sites, it should really have been one of the WCM requirements.

In many cases, their role was now largely delegated to Twitter (and some on Facebook), which fortunately kept going just fine. And another advantage was also very apparent -- where the web (if it's working) is still mostly "pushing out" information, Twitter and Facebook allowed interaction. Because people certainly have understanding for the disruption the volcanic ash causes -- as long as they're getting at least the sense that other people are working very hard to help them out. As long as they're getting up-to-date information, they'll be much more forgiving.

There's an excellent analysis of how various airlines responded available on SlideShare. It's the summary of an assignment for a class on Social Media for PR at St.Edwards University. I especially liked this quote: "It seems like every time I'm scheduled to discuss the role of social media in crisis communication some major crisis comes along -- usually just in time for class."

And this certainly isn't limited to commercial companies dealing with paying customers. In fact, EUROCONTROL, the European Organisation for the Safety of Air Navigation, was one of the unlikely stars of the past weeks. Their feed on Twitter shot up in popularity -- it kept up-to-date to the minute, kept going through the week-end and actively engaged with worried travelers. It put a virtual face on EUROCONTROL, which will be an unexpected reward for the normally rather anonymous organization.

And if you still think your industry is unlikely to be affected by volcanic eruptions, so you don't have to prepare for one, that's true. It'll probably be something else you haven't thought of yet. In any kind of industry, you'll have to deal with crisis. It's foreseeable that those will be unforeseeable -- which is exactly why you should make sure you have communications backups when they hit.

So heed these examples. Prepare for crisis in a pragmatic way. Make sure your site can cope and you have other channels available, as well. Think web and social, not phones and signs. In the long run, that's likely to be cheaper and much, much more effective.

But really, as is so often the case in education, it's not the teacher but the willingness of the "non-technical" types to learn that makes all the difference.

When content technology implementations go wrong, it's often blamed on a gap of understanding on the part of IT as to what the business really needs. Sometimes that's accurate.

But just as often I find a gap of understanding on the part of business users about how content technologies work, what they can accomplish, what's realistic. Business users sometimes sigh exasperatedly, and might utter a phrase like, "I don't care how it works, I just want it to work." 

This is foolhardy thinking. Even if you're "not technical," a fundamental understanding of how the technology you use every day really works will help you be a better team member, and allow you to more clearly articulate what you want from the system.

Think of it, at a minimum, like your car: you don't need to understand every detail of what makes it go, but you do have to understand that it needs gas (or electricity!), what all the buttons and pedals do, the consequences of what you put into it, and what needs to be done to keep it running well.

I recently spent some time with a client who had picked a new Web CMS late last year and just launched an alpha version of a new website. The marketing team was rejoicing over the realization of content reuse: "look, we put it in the system here, and then it shows up on all these other pages!"  Eighteen months ago, they were completely new to modern content management. Through education and a focused effort, marketers at that firm now understand the power of what they can do -- and also the limitations of the system. Without a willingness to gain that understanding, they might still be cutting & pasting static content -- or in separate silos, taking whatever the IT team handed to them.

So if you're frustrated with your CMS, DAM, or other content technology, take the time to understand the fundamentals first. Then you'll be on a better path to improve your situation.

• 11,000+ unique visitors to ECM3.org
• 3,300+ downloaders of the model
• Some exciting stories of people sharing their real-life experiences using the model (we will be sharing our own stories in some subsequent blog entries)

We know that version 1.1 of the model is long overdue, but we've been collecting community feedback and will be working to publish a "dot release" in the coming weeks. From what we've seen so far, no major changes will be needed, just some minor tweaks here and there. However, if you feel inspired to add to and expand the model let us know, as we would love to see version 1.2 and even 2.0 at some future point.

Please continue to send your suggestions, comments, and examples of how you are using the model. Thanks for all of your help in creating something that is making a real difference in the industry, and do remember this is true open commons. Make use of it, it's yours!

Now, this team understood the technicalities of document and records management just as well as I did. My “aha!” moment came when I suddenly realized that not one of them had ever actually managed information for a living. Not one of them had ever been in the position of an end user, sitting there day in and out trying to manage, or even frequently access business-critical information.  

Fortunately during the same engagement I was able to speak to a wide range of actual end users of the current system, and quickly realized that they they in turn, had no concept at all of such concepts as “check in/check out”, or “a single source of truth.”  But they did know an awful lot about how to manage information; in some cases they knew a lot about how to manage information really badly.

In this project, we were able to actually bring both sides around the same table (figuratively and literally), and facilitated the conversation so that each began to understand the others' frustrations and hopes.  Both sides learned a great deal, and though peace was not brought to this particularly fractious environment, they took some great steps toward avoiding all-out war.  

I say it all too often, but it has never been truer: regardless of whether you buy a full ECM Suite from the likes of EMC or IBM, buy document and records management solutions from HP, Objective, or Laserfiche, or even opt for the SharePoint route, you will fix precisely nothing with the technology itself.  Change comes from understanding and adroitly changing the underlying business requirements and structures, along with both current and future business processes.  

With a little bit of our help this organization did just that, and though various technical and organizational teams contributed, the most important work they did was to attempt to understand their information management problems holistically. 

They took the brave and liberating position that:

• I can only see the world through my own eyes
• So, please tell me how you see the world
• Together we might see something very special indeed

Ultimately they embarked on one of the most successful information management projects I have witnessed in many years. For even though the project is ongoing, the initial changes have achieved more than most projects could dream of.  The only sad part to this tale is that the old document management system they had previously used and had come to despise was never a part of the problem.  The shiny new (and very expensive system) eventually was not really a technical improvement -- it just started getting used properly.

If there are lessons to be learned and shared here they are no more than:

• Ensure both the business and the technical team are equally engaged in any document management project.
• Pay special attention to the needs, views and insights of those who will use the system every day -- proxy representatives of the business may not be one and the same
• If you have an information management problem, start from the assumption that it is due to bad information management practices, not technology
• If you need a helping hand, think of us here a the Real Story Group ;-)

So in summary, let me remind you of what some very clever Swedes once said...."knowing me, knowing you...aha!"

To quote:

Workflow services can help minimize the cost and time required to coordinate common approval processes -- but only if the service does what you want it to do, and users don't "work around" the system....

Subscribers to our WCM and DAM research streams can download the workflow paper here.

While some web managers in the Federal Government might wish to use Google Analytics, historically that solution has been more hamstrung than others because of Google's use of persistent cookies.

If you practice web analytics in the Federal government you know that persistent cookies are verboten by order of OMB -- unless you get approval from the director of your agency. In the real world of agency politics, that's like reaching the Mt. Everest summit. While other analytics solutions (such as Omniture and WebTrends) will certainly provide more accurate visitor data if they use persistent cookies, they aren't dependent on persistent cookies for data collection.

While Washington has seen some debate about loosening up the persistent cookie restriction, there has been no public movement since a flurry of activity and public comment during the summer of 2009. I expect that this will get resolved at some point before the end of 2010, but no one knows for sure.

Meanwhile, Google has issued a work-around.  According to the company, you can virtually eliminate the persistence in the GA cookie by using built-in tracking code functions to set the cookie time out to "0" in the two parameters below: 

Of course, this raises an interesting existential question: is a persistent cookie with time-to-live set to zero still a persistent cookie? Functionally, it becomes a session cookie, expiring when the browser closes.

Federal web managers have a more practical question: Why bother approving Google Analytics unless there was the possibility of being able to use it?  As for whether a non-persisting persistent cookie is acceptable to OMB...well, we'll have to await guidance on that.

You'll find no lack of answers.  My colleague Alan argues persuasively that ECM is most useful as a term to describe the biggest platform vendor offerings. Industry association AIIM defines ECM as "...strategies, methods and tools used to capture, manage, store, preserve, and deliver content and documents..."  AIIM also held a clever contest to define ECM, where the winning submission suggested it was about laundering and generally taking care of your documents as if they were your clothes.  The discussion continues, and there are no lack of definitions.

I suspect the emphasis on ECM definitions stems from a disconnect. We have this all-encompassing term -- Enterprise Content Management -- that doesn't reflect how marketplaces and real-life projects actually break out into very specific categories and disciplines, like Document Management, Web Content Management, Digital Asset Management, Information Architecture, E-discovery, Process Improvement, and so on.

I think there's actually a deeper question that's looking for an answer here. Let's strip out "enterprise" and simply ask: What is Content Management?

My definition is...

Content Management is the management of content.

Now, at this point you might be feeling ripped off, because of course that definition is a tautology. But please bear with me.

The goal in implementing content technologies and related processes is really to apply management principles to content. Unfortunately, "management" too frequently gets conflated with "control." This is a common thread through many definitions of ECM in particular: "controlling unstructured information." Yet, management is much more than control. Good management also features enablement and empowerment. Management implies rules, but also supports creativity -- often in different amounts in different contexts.

By thinking in terms of management objectives, we liberate ourselves from definitions that are too narrow, prescriptive, or technical, and instead focus on business outcomes. For example, it is fashionable now to talk about distinguishing "managed" and "unmanaged" content. I think this is a mistake. After all, the minute you decide to delete some seemingly unmanaged content -- such as a comment on your blog -- you have made a management decision. If you leave MySites turned on in your SharePoint installation, enabling individual employees to provision new team spaces whenever they see fit, you have made a management decision.

What I am really urging you to consider is a spectrum of control and enablement that is business context-specific.

There are many precedents for this. After all, we take it for granted that the enterprise will manage human resources, and that the management of those resources will encompass both control and enablement (again to varying degrees, depending on the context). Ditto for financial management.

As a practical matter, the management of content means first of all inventorying and prioritizing your existing content stores, before settling on technologies. Ask yourself in each case, what does it mean to manage this information? Don't be surprised if management means varying the way you exercise control, enablement, rules, and empowerment across different contexts.

Then explore suitable technologies. You may need Document Management systems with defined workflows (control) -- while supporting individual discretion at key points (enablement). You may also need free-form Collaboration software (enablement) -- as long as it comes with an auditable archive (control).

When you get to that point, let us know if we can help you.

From the introduction:

An important, yet rarely acknowledged architectural and product development shift has transpired over the past couple of years in the content technology marketplaces we cover. The debate has shifted from "Suite vs. Best of Breed" to "Platform vs. Product." This is partly a natural evolution in vendor marketing as technologies and marketplaces mature. Yet this shift also has profound implications for you, the customer. Beyond the normal criteria of cost, functional fit, and vendor fit, you need to assess a tool's position on the Platform-Product continuum against internal needs and capabilities.

The three-page briefing offers five specific steps your enterprise can take today to make sure you make the best technology choices for near-term and long-term success. To subscribe to our research so that you can receive advisories like this, contact us here.

Today all too often IT and Business Managers focus their energy on the future system, with an implicit recognition that the current system needs to change, yet without really understanding the intricacies and essential challenges in the current system. As a result we see many well intentioned projects fail, simply because they tend to either repeat the same errors as past projects, or they fail to convince users of the need for change. 

Take two recent situations I have encountered, the first involved a document management implementation that had failed on so many levels, due to promised functionality and usability simply not materializing.  The key reason that the vendor failed to deliver was due simply to the fact that the product purchased was a pure Microsoft product, and the firm had a near pure Java technology environment. Not unfortunately a particularly uncommon situation.  Moving forward to the next generation of document management, the firm employed us to help them.

But it was quite a battle to get the buyer to focus on products that were a technical fit for them; in fact I would go as far as to say that if we had not worked with them there would have been a very good chance of them repeating the exact same mistake.  The reason being that over the three years that the original system had run, people had moved on, memories were short, and the reason for all the troubles forgotten. Received wisdom had it that they had simply been ripped off by a technology vendor.

In another case, we are working with an international company that is trying to make a radical business change. Their business continues to expand and their current information management system is overwhelmed with redundant, inaccurate, and duplicate data. Moreover it has become prohibitively expensive to administer and maintain.  Though new technology is a part of the solution to the problem, the most important part of the solution is to simply impose the most basic information management principals, including retention and disposition and applying metadata consistently to content.  Of course the old technology had all this functionality and more, but it had never been utilized consistently. 

This particular project runs into the tens of millions of dollars, and will likely be worth every penny, however by demonstrating to  end users key differences between the As Is and To Be situation in a practical and straightforward manner.  What this firm has learned to their credit is that information chaos can become acceptable and normal very quickly; people simply accept that that is the way things are. By vividly contrasting the current situation with the future they are receiving enthusiastic support from many who had been identified as potential obstructors to the project.

It's a simple lesson really, your map and directions are only of use to you if you know what your current position is.  Never assume you know why or how you got to your current position. Take time to figure it out. You may well find that the complex mess you currently work with is the result of some very simple and simple to correct errors made early on.

Last week, I blogged about the increasing trend toward specialization in the Search & Information Access space. As you may know if you've been reading our Digital & Media Asset Management Research, the DAM industry is yet another area where specialization is ongoing. One trend that's helping drive the verticalization of DAM is the broader use of video in Web publishing and in enterprise scenarios.

Video, as a digital mode of communication, is nearly ubiquitous. This means video asset management (as a capability within DAM) will assume ever-greater importance in the months to come. If you're in the market for a DAM system, you'll want to think about what this may mean for your overall content management strategy -- and take video requirements into account when shopping for a DAM system.

Depending on the business you're in, your use of video may not be extensive today, but it may well become a key content category for you in the near future. Just as the podcast phenomenon suddenly found many companies in the business of managing MP3 files "overnight," pervasive video will likely find many Web CMS owners wishing they'd thought through the vicissitudes of Flash and MPEG4 ahead of time.

Video is becoming more important in broad intra-enterprise cases as well.  Many (if not most) companies have security cameras stationed in their stores, offices, or on company grounds. What happens to all the security-video footage? In some cases, old material is simply destroyed after a certain amount of time. But it still has to be cataloged and stored short-term (then dispositioned appropriately). Is it safe to just manage such footage in ad-hoc fashion? Maybe. But maybe not. What happens if an employee sues the company after (for example) suffering an accident on the job? If the accident was caught on video, the video becomes a key piece of evidence. What if the employee's lawyers claim that the accident was part of a series of similar events? If archival footage of all similar events, across time, is available (and can be found with the company's search technology), it could decide the case.

Video also plays an important (and increasingly critical) role in health care. Nowadays, at major hospitals, all surgical procedures are recorded, for legal reasons. This results in huge volumes of video files that need to be cataloged, archived, and dispositioned.

Highway-patrol cars are (more often than not) videocamera-equipped. Every traffic ticket, every arrest, every roadside assist, is video-recorded. All of that material has to end up somewhere. It's best if it ends up in a repository, managed.

Law enforcement agencies routinely videotape suspect interrogations. Again, this creates enormous quantities of video information that needs to be cataloged and managed -- preferably in such a way that footage can be semantically searched later on, if needed. According to Herndon, VA-based MediaSolv Corporation (which sells video asset management systems specifically designed for police use -- a prime example of the increased verticalization we're seeing in DAM), 28% of U.S. states currently require the recording of "custodial interviews" (i.e., police interrogations), and fully half of all states have already passed evidence-preservation legislation. This essentially amounts to state-mandated use of DAM.

Take a look at your own organization. Do you see video management in your future? If the answer is "yes" (and it probably is), you'll want to consider availing yourself of our Digital & Media Asset Management Research, where we rate each of the 20+ vendors we evaluate on their video-management capabilities. We can help you get a handle on your media management needs -- even if you're still deciding what they are.