We will provide more detailed guidance about these in a future advisory paper, but in the meantime, here are the key points to consider:

1. Which Devices to target: This obviously depends on your target audience and what constitutes a mobile device for you. While simple cell phones, PDAs, smartphones, and tablets are quite obvious, what may be less obvious are devices such as gaming consoles or even the good old television that can act as delivery channels in some contexts. In my previous organization, I worked on developing a strategy for a hospital that wanted to be able to stream patient data on a linux-based handheld device carried by docs. Even without going that deep into what constitutes a mobile device, at the very minimum, you will need to decide what kinds of phones and tablets you want to target. This includes both the form factor (or the size) and operating systems (iOS, Android, et.al.). We've discussed this issue in these blogs before:
   • Thinking Holistically Beyond the Smart Phone
   • Android Tablet or iPad
2. Mobile Apps, Web Apps, or Hybrids: There are many ways to develop applications and sites for mobile devices. So you'll need to decide whether you'll stick to browser-based web apps, create downloadable applications, or use both for different use cases. We provide some guidance on which option is suitable for specific use cases in our advisory paper Mobile-Enabling Enterprise Applications: Browser or Downloadable Apps? as well as number of blog posts like:
   • Different Ways for Building Mobile Apps
   • Mobile Apps are Dead. Long Live the Mobile Web
   • Mobile brings site-building tools back from the dead
   • Mobile - the Next Web CMS Frontier
   • DAM and mobile: should you go with a dedicated mobile app?
3. Existing tools or new ones: You probably already have numerous enterprise applications that  provide some sort of capabilities for building mobile applications or web sites. For example, many Document Management vendors provide device specific applications to access a subset of functionality provided by their tools. Similarly, for a mobile website, you could possibly use your existing Web Content Management (WCM) tool or a Portal tool. Alternatively, depending on your scenario, you could invest in a sophisticated mobile middleware framework:
   • Advisory: Adapting Your Content Management Platform for Mobile Delivery
   • Blog: An iPad for DM and RM?
   • Blog: FileNet P8 on your iPhone
4. Managing content for mobile site and related architectural Issues: Publishing a mobile site will raise additional issues related to content duplication, publishing, workflows, and presentation. So you will need to have a handle on technical issues such as:
   • Do you employ a separate repository for mobile content (and this duplicate content) or do you use a common content repository?
   • How do you publish content from your regular web production environment to mobile environment?
   • Do you repurpose or recreate content?
   • How do features such as in-context editing and rich text editors work for mobile websites?
5. What happens to existing websites and content:  You obviously would not want to throw away your existing site, especially if it was not developed a long ago. So it'll be important to understand how you'd reuse existing content or mobilize an existing website. There are many approaches and tools to do that but if you've followed some basic principals of content management -- such as separating your content from its presentation -- you should experience fewer problems here.

There are many more considerations -- such as information architecture and user experience in a mobile context, content migration, alternative development approaches, and so forth. Yet, addressing the key starter issues above will give you a good launch point in your mobile roadmap.

What has been your experience and what are the key issues you've faced? Please feel free to comment below, email or tweet me.

• Complex
• Viral
• Collaboration
• Clunky
• Misrepresented
• Social
• Bottomless Pit

This is typically a pretty pro-SharePoint audience, and in terms of research for our buyer-focused subscription ECM and SharePoint research services it has been a reliable source of peer information over the years.

But I have no doubt at all if we had asked the same question in previous years, we would have seen a more positive list of answers.  Further discussion revealed that SharePoint buyers and users in the room had been caught between a bottom up / top down approach to deployment.  Bottom up in that IT had thrown the problem of SharePoint over the wall and left users to self provision, or business users had simple gone off and acquired SharePoint on their own. Top down in that IT had provided very elementary and unusable SharePoint environments with insufficient education and training.  What was missing in both approaches was:

• Business Analysis
• Process Analysis
• Change Management
• Information Management

Neither the business groups that had SharePoint unleashed on them (or unleashed it themselves), nor the IT department that technically owned SharePoint offers those kind of skills anymore. Yet both assume somehow that the other will figure it all out. It's not so much that SharePoint is at fault; rather that growing SharePoint installations reveal the dearth of supporting resource, and their criticality.

We can call this a lack of skills, but that's not the real issue: it's a lack of enterprise commitment to the "soft" resources required for success here. Remember that SharePoint is like any other enterprise platform: you can't install and forget.  Adherents of SharePoint in the cloud would do well to note this too...

OK, this is partly an argument about labels, but labels matter. What most employees understand as their "intranet" -- updates from corporate communications, some HR forms, and a mountain of outdated docs -- is increasingly irrelevant.

The issue here is not that traditional intranet services have somehow lost value. Rather, it's that business units are moving on. They don't want to be "lured" to your vision of an intranet. They want some fairly specific services. From what I can see, there is a confluence of factors here:

Applications over platforms
Platforms are good for the kind of long-term planning and prep where IT excels. Unfortunately, platforms are less amenable to delivering short-term benefits to business units. Put another way, your colleagues don't need "SharePoint." They want a contracts management system, or a project scheduling utility, or any one of thousands of practical business services.

Ability to self-provision and employ SaaS-based solutions
This can be a tough one to swallow at an enterprise level, and you'll want to keep some controls in place. Yet, you also need to get ahead of practical business needs by offering some real alternatives, or your business colleagues will simply use their credit cards to buy what they need in the cloud.

Rise of Portal Lite
Rather than a big, heavy, developer-intensive enterprise portal, business units are increasingly seeking simpler forms of integration: basic dashboards / health meters, simple mash-ups, activity stream aggregation, and so on. And they want these services available ubiquitously, and not just in a corporate-wide portal. The good news is that some vendors are adapting. Are you?

Emphasis on collaboration and social
If you've spent the past three recessionary years trying to automate processes to cut costs, you're only getting half the picture. Sales, Marketing, R&D, Product Development, and other revenue-generating units want to be more agile, more innovative, and work more closely across silos. It takes much more than technology to do that successfully, but the right collaboration/social toolset is a key part of the overall solution here. When intranet teams deliver the wrong tools or approach, business units take matters into their own hands.

Blurring lines between enterprise applications and enterprise information
Employees don't want services bereft of supporting content; nor do they want content delivered in a way that's not immediately actionable. The sharp divide between applications and documents on most intranets is becoming anachronistic. Savvy intranet managers are focusing on content-enriched applications. The rise of mobile is really pushing this. Even the simplest static intranet "websites" make more sense as applications on mobile devices.

* * *

Let's not have a funeral. The death of the intranet heralds the re-birth of something better: a more practical set of tools that help people get their work done. Intranet managers should re-align with this new world and focus on services that businesspeople can use in the flow of their daily work. The digital workplace is actually less a specific place, but rather a mindset that creates services so badly needed that you'll never have to complain about "poor adoption" ever again.

That's hard, and you may skin your knees at first. Age-old challenges of security and interoperability can get tougher before they get better. Yet your colleagues are already looking way beyond your official intranet. It's worse to be irrelevant than to have experimented and failed. If we can help you, let us know...

* * *

P.S. This post was informed by some great chats at the recent KMWorld event with two of my favorite Digital Workplace gurus, Jane McConnell and Martin White.

Community venues are fast evolving. In the public sphere, the action has transitioned largely (though not completely) to public social networks, where innumerable sub-communities have emerged. Intra-enterprise investments, not surprisingly, have followed more slowly. However, we're seeing enterprises of all stripes paying greater attention to internal communities as key applications within the digital workplace.

But just what constitutes a community? And why is the answer important?

For starters, it's important to distinguish between a community versus simple interaction and feedback. If I comment on an article within my local newspaper website, am I joining a community? The newspaper might think so, but I don't, and it's my opinion as the poster that matters here. A community is something more than a collection of threaded comments -- however valuable those are in their own right -- and that "something more" is where added business value lies.

Intranet guru Jane McConnell defines communities as "Groups of people with a shared interest or practice, who communicate, exchange ideas, and collaborate." This is a great starting point, and I'll extend it with a short list of characteristics that I think make for a real community. If I'm missing some, please chime in with your comments.

Communities have explicit membership. Membership is more than just a login or even a profile, but a sense of belonging and commitment, which is much harder to define but extremely important. One sign of a real community is that members have actively annotated their profiles (with picture, interests, and so on). This in turn conveys obligations for community "owners" to understand members' commitment and manage accordingly -- i.e., with a deft hand that allows membership broad leeway to define where the community goes. By the way, for a great resource on this very issue, consult The Community Roundtable.

Members visit regularly, even without prompting. Members want to participate regularly, to see what the community is up to. Sure, signalling and alerts from the system are essential, and people will want to commune around useful new content, as well. Still, I find it interesting that on media and sports sites, readers will comment on new articles, but communities tend to form around particular stars or personas. Perhaps there are lessons here for internal enterprise communities.

Members have the ability and inclination to connect directly with each other. The nature of those connections will vary, and large communities need to account for a variety of different member-to-member interaction services. Member-to-member interaction separates true communities from workaday user generated content.

Note that I'm not suggesting that digital communities are the shining future of intranet and web interaction. There is a place for ad-hoc interactivity and many people simply don't want to join yet another community, either at work or outside work. The absence of a community does not mean you should forgo the possibility for pervasive interaction with you, the site owner.

Nevertheless, I believe communities are an increasingly important phenomenon, especially within enterprise firewalls. In fact, this phenomenon is one of the key reasons why savvier enterprises are reluctant to commit wholeheartedly to SharePoint (which famously lacks key community services), even as they leverage SharePoint's ample document-sharing and workflow services.

In any event, it's an area we are covering much more closely in our Enterprise Collaboration and Social Software vendor evaluations. And I'm still trying to better understand all the nuances. So keep those questions coming...

Unfortunately, customer confusion is completely warranted.  First, there are several different "versions" of SharePoint available; do you want Foundation, Standard or Enterprise?  There are also add-ons like "SharePoint for Internet Sites" and "FAST Search Server."  Depending on what you need and the features you would like to leverage, there's a seemingly dizzying array of choices.

Adding to this overall confusion, Microsoft has developed their "cloud" offering.  In late 2008, Microsoft release "Business Productivity Online" or BPOS, which included, among other products, a cloud-based version of SharePoint.  The original offering has a relatively straight-forward single tier licensing approach based on the number of users and whether you wanted a "full" or the "deskless" experience.   As of June 2011, Microsoft released the updated version of BPOS called Office365.  Unlike BPOS, Office365 introduces additional licensing levels across two main business size distinctions – you're either a small/professional business or you're a medium enterprise.  Depending on which category your business fits, there are several new license choices ranging from $6 per user to $27; each choice provides a different combination of features and products.

To be fair, Microsoft is not the only vendor struggling with licensing.  Many vendors in this space have trouble presenting an intelligible licensing scheme.  My colleague Tony Byrne recently commented in his "When WCM Vendors choke on the Cloud" post that many WCM vendors are struggling to adapt their licensing models to account for new cloud infrastructure.  In this respect, Microsoft has the double challenge of trying to create understandable license models for both cloud-based and on-premise implementations.

To help our customers begin to make sense of their choices, we have recently released a SharePoint licensing advisory paper.  In the paper, we explain how to distinguish the various versions of SharePoint, we describe what's necessary to license for specific scenarios (e.g., company Intranet vs. a public-facing web site) and highlight other kinds of licensing necessary to comply with Microsoft’s licensing requirements.

1. The recent CMS trend towards website interaction management will get balanced by a renewed emphasis on content, driven by specialized mobile experience needs
2. For enterprise applications, mobile web will prove a better common denominator than mobile apps
3. The next frontier of Enterprise 2.0 lies in socializing existing applications and work processes, rather than creating new info and interaction silos

If any of that piques your interest, you can check out the interview above, or via our YouTube channel.

Since its launch, ECM3 has been accessed by many thousands of people, and employed enthusiastically by both end user organizations and consulting firms around the globe. It continues to be the benchmark for ECM deployments, and has the breadth and depth to be useful in even the most demanding of situations.  If you haven't already downloaded your copy of it I encourage you to do so, and if you find anything in it that you believe could be improved or expanded upon, then get involved and help us make useful changes.

The Gartner model is basically sound, if though somewhat brief; I'm sure it will be of some value to Gartner clients.  I don't know if Gartner referenced the open source model in their work, though they surely must know of it. What I do know is that it's a shame that Gartner did not simply opt to contribute to ECM3/Mike 2.0, and I'd encourage them to consider doing so in the future.

Luckily, intranet managers have another option. For the sixth year, NetJMC will be conducting their "Digital Workplace Trends Survey." Last year over 440 organizations from around the world participated and they all received a free copy of "Global Intranet Trends for 2011" (commercial value $750 US).

Interested candidates can apply to participate by sending an email to "info@digital-workplace-trends.com" with the information requested on this page:
http://www.digital-workplace-trends.com/sign-up-for-the-2011-12-intranet-trends-survey/join-the-survey

You can read what 2010 participants say about the report:
http://www.digital-workplace-trends.com/reviews-of-2010-report/reviews-by-intranet-managers

Key topics this year are:
    Mobile Strategies & Approaches
    Collaborative & Social Aspects
    Search
    Governance & Management
    Business Value
    Future Scenarios

It's a tough question to answer. I could be facetious and say, "with great difficulty", but all joking apart it's a real challenge for many.  Finding staff with the right technical product skills (Documentum, Alfresco, etc.) can be hard enough but not impossible. Getting people with the right business skills is the real test.

First, the tech side.  Many vendors certify and train consultants to be conversant with their products, and at the end of the day a big ECM system is still just a big IT system, so typical Enterprise Architect skills along with good old Java and .Net skills can go a long way.  Good technical ECM skills (along with specific product savvy) might come at a premium, and they may not be in easy to find in your locale, but these folk can ultimately be found and/or trained. 

No, the bigger issue is finding those that can think ECM, that can liaise with the business, that have the right mindset, training, and business analysis skills.

It's a combination of library skills (the core of ECM) and business process management: the ability to talk to end users and business owners, track and model processes and tasks, and both translate and improve on them before connecting to the technology side of the equation.
There are training courses out there for ECM -- and some of them are quite good -- but there is essentially no accredited post-graduate (graduate in the US) level study available,  and that is such a shame. 

In my personal opinion the standard of business analysts (BAs) working in ECM has dropped dramatically over the past decade. Too many BAs now serve just under-trained requirements gatherers rather than skilled people who can perform real analysis. Few BAs really understand process flows and modeling, and even fewer understand the concepts of re-engineering and continuous improvement.

The problem is compounded further when one adds the very specific librarian and information management skills essential to ECM.  There are vacant jobs out there, and employers looking in vain for the right folk to fill them, but this industry has fallen far short in delivering the people needed to fully leverage all that ECM has to offer.

One such truths is that in general, your implementation cost for an enterprise implementation will come to 7 to 8 times that of initial licensing.

Vendors sometimes inadvertently highlight this hidden cost. Recently, I witnessed the regional sales director of a large infrastructure vendor tell a potential customer that for every Euro spent on his company, 7.5 Euros went into the local economy. It was meant as a nationalistic appeal -- but it sort of backfired when the customer inquired whether this meant they were going to spend 7.5 times the license cost on additional integration services. (The reply took about five minutes but boiled down to "yes.") This was a pretty savvy customer, and they had actually calculated that the average cost of most of their enterprise IT projects was 7.4 times the initial offering; to them, this episode was just an indirect affirmation.

However, like all generalizations, this 7-8x multiple is not some unalterable law of the Medes and Persians. Among other things, it can depend on what exactly you count as implementation cost, and what you count as licensing cost. For instance, internal resources are usually not billed to a project budget; and likewise, annual maintenance and support often don't hit the project sheet beyond the first year (though they should). And, of course, open source isn't free -- don't even think that 7.5-times-zero means the whole project will be gratis. And for a more comprehensive paper on how to calculate cost, you may want to check my colleague Apoorv's recent advisory for CMS projects.

But if you're budgeting your project, or a vendor calculates ROI for you, use this as a yardstick. You may be getting a bargain -- but remember that if it looks too good to be true, it probably is.

A content management implementation is also a software project and you would require some way of estimating your effort (and hence costs). However, in our experience, established methods such as COCOMO and Function Point Analysis generally don't fare well  for packaged software implementation efforts in general -- content management projects in particular.

In our recently released advisory, Alternative Estimation Methods for CMS Projects, we examine the shortcomings of traditional approaches, and explore what would work for a CMS project.

Here's the table of contents for the advisory paper:

1. Key Takeaways
2. Introduction
3. Package Integration Is Still a Software Project
4. Estimating Content Management Projects
5. Key Advice
6. Conclusion

The advisory paper is available to our Web CMS, DAM, and Document Management research subscribers. 

What could have been a snoozefest in fact turned into a full-on attack of the value and promise of Cloud Computing. At one point the panelists had the audience laughing out loud at the "joke."

Some quotes from the panel:

"Everybody wants cloud like access to content, but they also want tangible ownership of their content"
"The people in Egypt had a hard time reaching the Cloud recently..."
"The Library of Congress putting everything into the Cloud is remarkably naive"
"There is justifiable and important paranoia regarding the Cloud if you are an archivist"

I can't say I am in agreement with the panelists. At The Real Story Group, we ourselves use various hosted options, several of which leverage a true Cloud-based infrastructure.  You should notice, though, that like most pundits, our firm is much smaller than the typical enterprise.  Nevertheless, we regularly recommend hosted offerings for customers where it makes a decent fit.

That said, I don't see customers clamoring for Cloud options, or buying into the dream to the extent vendors and their paid-for pundits would have you believe. Yes adoption is growing rapidly, but so does anything from a low base point.  Cloud most definitely has its place and its value, and I for one happily champion those, but the visceral resistence to the very idea in some quarters stems from equally valid reasons. 

Consider Google GMail, the poster child for Cloud. In the past year alone GMail has had the following "adventures:"

• Erased 150,000 users emails and contacts in Feb 2011
• Multiple outages in 2009/10
• Exposure of 176 million user contacts with the ill-fated launch of Buzz

I single out GMail simply because it is by far the most quoted Cloud-based application in any corporate discussion, even though it is a full-blown SaaS application, rather than a more narrowly-focused, infrastructurally-oriented Cloud service.

The Cloud is no silver bullet. As long as Cloud -- in all its various and sometimes opaque incarnations -- gets pushed to customers as the answer to all their dreams, buyers will remain rightly skeptical.

We'll be undertaking much more research in the coming year into Cloud, particularly the criteria you need to consider when comparing on-premise, off-site, and hybrid options across various application layers.  But the one thing we won't be doing is cheerleading for one delivery method over another, since as of today they all have their rightful place.

Of course, there's no shortage of SharePoint-related events right now, but we've sensed a need for something different, something to add real value to those entrusted with evaluating, buying, and managing SharePoint systems.  In short, an event for those of you looking to develop a SharePoint strategy.

Hence the agenda will critically examine when to use SharePoint, and when not, and most importantly how to increase your chances of success in broad and large deployments.

The summit format is a mix of structured discussions with your industry peers, along with practical advice from recognized -- yet approachable -- experts in an informal setting.

When we plan a summit like this, we think about what you the customer wants: meaty sessions devoid of hype, cheerleading, or bias -- with an emphasis on open debate and exploration. Meeting in a fabulous venue doesn't hurt either.

Consider sending a team to join us and your fellow SharePoint travelers.  Jarrod and I are looking forward to meeting you in person, and giving you the opportunity to get "The Real Story" on SharePoint.

Recently, I’ve seen numerous organizations churning out massive amounts of content using faux-CMS methods such as:

Content entry: Word-based forms
Workflow: E-mail and phone calls
Content reuse: server-side include files tracked via spreadsheets
Collaboration: shared network drives
Versioning: multiple versions stored on shared network drives
Archiving: PDFs in shared network drives
Deployment: Simple FTP

To their credit, these organizations have done an impressive job of cobbling together a variety of tools and processes to mimic the functionality that comes with most content management systems. In most cases, these homegrown solutions have served these organizations well -- thusfar.

However, the changing demands of content consumers are putting stress on these methods. With increased content demands, more and more production departments are hitting their breaking points and becoming bottlenecks for publishing important content.

Is your organization one of these?  The good news is that in 2011 there are more options than ever for a Web CMS buyer – we cover 44 of the most significant. All 44 of these commercial products and open-source projects have been around for years and have matured to the point where their base functionality could provide operational wins for you. Your challenge will be to find the right partner to support your visions for the next three years and beyond.

1. "What does an information manager do?"
2. " How does she do it?"

And then proceeds to answer them both.

The book is called TIMAF Information Management Best Practices Vol. 1. I recommend it.

The longer I'm in this business, the more I see the common problems we all face as -- at their core -- information management challenges. The problem with the term "Information Management," though, is that it feels very abstract and doesn't seem immediately relevant to the workaday struggles of the typical website or data warehouse manager. Consequently it's a term that gets bandied about in academia, but not so much within the modern enterprise.

I think this book -- edited by Bob Boiko and Erik Hartman -- will help change that. It's a preliminary collection of best practices that's more specific and detailed than you'd see in the trade press, but more actionable and case-oriented than you'd see in an academic treatise (the authors are all practitioners and consultants). It's also mercifully vendor-free. [Disclosure: two of my colleagues (Alan and Apoorv) contributed chapters.]

If I had any criticism it would be that the book perhaps over-emphasizes content (versus data) in general, and structured content in particular -- a faint shortcoming that's more than redeemed by the step-by-step approach taken in most of the chapters.

As you prepare for a new year, consider going back to the basics, and check out this book.

• Key Take-aways
• Introduction
• The Wrong Way to Build a Shortlist
• 7 Steps to a Better RFI
• Conclusion

The paper is available now to our subscribers.

Take one recent DAM procurement I advised on:

Vendor A's pricing was based on the number of assets in the system - and the proposed pricing was for "up to 1 million assets." The number of users or servers the software was running on didn't effect pricing. This particular customer had planned to have about 2 million assets migrated into the system within 2 years, yet per-asset pricing over 1 million assets was not included.

Vendor B's pricing was based on the number of named users of the system, and a price was given for 50 users. The number of assets or servers didn't effect pricing.

Vendor C's pricing was based on a combination of "casual" and "power" user pricing. "Power" users, such as administrators, were more expensive ($800 per user) than casual contributors ($250 per user). They based their estimate on 20 power users and 80 casual users. An "unlimited" number of assets could be put into the system.

Vendor D's pricing was server-based, allowing for unlimited users and assets, with no benchmarks on the typical number of users that might log into to a single instance of the software.

Finally, Vendor E's pricing was based on a combination of 50 concurrent internal system users, unlimited users of the external portal application for 3rd parties to access assets, AND number of servers. 

Normalizing pricing and comparing apples to apples in such cases is a big challenge. I tend to do this in a spreadsheet, where I work to specify with our customers a 5-year plan for number of users, assets, and servers, and then normalize the pricing based on that. Adding services and support costs to that can bring you to a rough TCO, or total cost of ownership, over the near- and longer-term. What I often find after normalizing pricing is that the "cheapest" and "most expensive" vendors at first glance very rarely end up that way, when TCO over a five-year period is considered.

Web content management procurements can offer a similar myriad of pricing options, such as per domain, per user, per items, or per server. Staging and development instances of the software are sometimes, but not always, less expensive than the production instance. 

Search tools, by contrast, are sometimes priced by the size of the index, so the more content you make searchable - the more expensive it gets.

For every product we evaluate in our research, we outline details of how vendors typically price their software, and the range of a typical deal. This helps our customers narrow down to an appropriate short list based on their budget, which is often a key criteria for selection. 

But increasingly, vendors are offering multiple options, only adding to the confusion. In the last six months, I've seen one DAM vendor do a bid that was $800k for a large Fortune 100 corporation, and then bid $180k for a very similar package when pitching to a non-profit. I often say that buying enterprise software is akin to bartering for a handmade basket in a third-world market -- it's all negotiable, and $180k is better than $0.

But the point here is, don't just look at the price on the "investment" line of the proposal and think the story ends there. Uncovering the real story of vendor pricing takes diligence, investigation, and normalization against the competition.  

However, unless your workplace is some sort of rigid digital production line, your colleagues need something else besides training. They need education.  Education means explaining to people why you're implementing the system, including the broader context and hoped-for benefits, along with future enhancements.

To be sure, both training and education are important.  They just emphasize different things.

Education becomes particularly important with social and collaboration tools, where your colleagues' lack of clarity around purposes and norms may make them cautious about participating.

Many social software vendors we cover argue that their tools are "so easy to use you don't need training."  That's bunk. Training is almost always essential.  But even if your colleagues take readily to simple tools like blogs, that doesn't mean they understand the purpose, value, and expectations regarding posting and commenting.

Information management systems rarely work as advertised, especially with initial implementations.  People who understand the bigger picture will adapt and get more value from the technology in the long run.

This is hardly surprising when vendors typically like to calculate support contracts on the basis of ~20% of list pricing per annum, in perpetuity.  So for example on a $1m software deal (list price) you will typically pay around $200k per year in ongoing fees.  Even if you negotiate the initial licensing costs down to $500k, you may still pay $200k per year in support fees, if the vendor calculates this against list.

Twenty percent of list price is a lot of money, and just as these fees can make up the bulk of a firm's yearly IT expenditure, so too do they make up the bulk of many software vendors revenues. Since support is also very lucrative, anticipated future streams also represent a critical part of vendors' stock valuations.

Hence whilst vendors will usually negotiate on up-front license costs -- in some cases to the point where they are virtually giving the licenses away for free -- they will be very reluctant to move on the support fees.

It used to be that support was calculated at closer to 10%, but 20% seems to be the average now, with some wanting even more than that. That percentage has risen over the years as the amount of money buyers are prepared to spend upfront on licenses has dropped (to zero in some cases). So you often spend the same today in the long run, as you did back in the day, only you feel better about it now, since you don't have to cough up quite so much in advance.

What this means for you the buyer is that you need to always compare and contrast  the total cost of ownership (TCO) of any new systems over a 5 year (or longer) time period to fully understand what this is really going to cost you. You also need to be recognize the reality that when vendors are happy to slash up front prices or give their software away for free, they are not doing it to be charitable to you or because you are a mean and lean negotiator, they are doing it because the real money lies elsewhere.

As an interesting aside, today I discovered that a small number of European CMS vendors have recently been prepared to calculate support costs on negotiated prices, rather than list.  This is unusual and not something I have seen happening much elsewhere. It may simply be that list pricing is in the slow process of adjusting downward to simplify the process of pricing, or it could be a knee jerk reaction to the perceived commoditization of CMS systems. Whatever it is, it a trend that we will continue to watch with great interest, and if you have insights you would could share on this topic please drop us a line we would love to hear from you (technology users and buyers only please).

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.

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.