Feature

posted 26 Apr 2007 in Volume 10 Issue 7

Workshop: Enterprise content management

Natural selection

There is no special formula for selecting the right enterprise-content-management package. However, with the breadth of users, business processes and applications involved, purchasers must nevertheless choose carefully.

By Alan Pelz-Sharpe

Software selection and purchasing has always been a thorny issue. Vendor demonstrations need to be closely examined and vendors themselves forensically questioned – do their claims really stand up? And organisations need to look critically at their own needs – not get carried away – and see how well these match with the capabilities genuinely offered by the software on the shortlist.

And then there’s the issue of price and implementation time and costs.

With enterprise-content management (ECM) software, a good first step is to take a thorough inventory of content silos and their owners (you’ll need to do this sooner or later), and base-level corporate infrastructure (human, knowledge, physical) for the project. A complete enterprise-content audit may sound like overkill, but look deeply at what you have and what you find may well surprise you.

The natural inclination in an ECM deployment is to develop expansive requirements.

This is okay as a starting point, but at each step in the process, you’ll want to ask your team, ‘How important is it really that this aspect or process be automated?’ Remember you are not building the perfect system, just a great one.

Furthermore, no single platform presently on the market can address the entire ECM lifecycle seamlessly. Remember that complete requirements are nice, but prioritised requirements are gold. Knowing the features or attributes that are more important than others will make it easier to compare the vendors and will also help you keep costs in line with your budget.

At this point, you may wish to sound out either your favoured systems integrator or a handful of vendors who would appear to be a suitable match, especially on broad-brush cost estimates, to help inform the next step.

This can be done by issuing a request for information (RFI), of course. However, avoid a vendor dog-and-pony show at this point. It is premature and will waste your time (and theirs).

Develop use cases or scenarios

Sometimes called ‘scenarios’, use cases can provide a much richer way of describing your needs and connecting them to business benefits. Use cases can also vastly simplify and speed up the vendor selection process by giving everyone a target to aim at and team members can understand vendor offerings much better if they are discussed and demonstrated using scenarios that they face every day.

We like to develop use cases that start with an ‘as is’ and then describe an ideal ‘to be’. This gives vendors a better idea of what you’re trying to accomplish.

It also enables you to achieve some actual improvements, rather than just an ECM software implementation that mirrors what is already in place. The more detailed your use cases are, the more you will be able to differentiate solutions. But if time is short, even simple use cases may suffice.

Consider the following:

As is

Susan in the Paris mail room sends incoming bundles of letters to each department for local sorting by legal secretaries – who then assemble relevant documents into manual case folders. When lawyers need to collaborate with others, their secretary scans documents on the local scanner/copier and posts the hard-copy documents to the other office or, in some cases, sends TIFF images via e-mail. When close collaborative work between various offices is required, this is usually managed via teleconference or by one party or the other travelling to meet in person.

To be

Susan in the mailroom opens a letter that contains a signed document from a client of the Paris legal firm she works for. She scans the document, which is in fact a completed form that had been despatched to the client for completion some weeks ago. Once scanned, the ECM system recognises the form, reads some elements of it and triggers a workflow. The electronic form is automatically sent to the secretary of the lawyer dealing with the matter and this is registered into the ‘case’ along with other pertinent documents.

In parallel, Susan has sent by internal mail the original hard-copy document to the records management department for processing. The lawyer assigned to this case opens up the report that has been assembled by her secretary and immediately realises that the completed form details will require expert examination by her colleague in another office. She sends the case to him along with an electronic request for them to meet in a secure team-room to work on their response to the new information together.

What you have done here is signaled to the ECM vendor that:

Scanning, imaging and recognition techologies are an essential part of this solution;
Security and confidentiality (potentially digital-rights management or DRM) are very important factors;
Strong collaborative environments are neccesary;
Records management issues may not have been thought through fully;
You have a need for strong workflow and case-management capabilities.

You could have skipped the ‘as is’ piece, though bidders will find it very useful. More importantly, you’ve given vendors something very concrete to propose against and demonstrate when they meet you.

Whatever you do, avoid ‘tick box’ RFIs. Vendors have seen them all and have figured out how to check all the boxes. Yes, you still need to outline some canonical requirements (‘must run on Microsoft Windows Server 2003’, for example), but try to keep these to a minimum and instead describe more use cases to illuminate the breadth of your needs and find out how they will meet them.

Indeed, remember the differentiating power of the word ‘how’. Rather than ask a vendor, ‘Workflow?’ ask: ‘How do you support workflow in collaborative environments?’ If they use a Microsoft ActiveX control, but most of your authors work from Apple Macs or any non-Microsoft environment then you have a problem.

There’s one final point when you change your RFI to be less about the product and more about your firm and its needs. To the extent that you open up your business processes, failures and successes in great detail – and ideally you will – it is prudent to have potential bidders sign a strict non-disclosure agreement first.

The business case

Is this a good time to set a project budget? Two schools of thought predominate. One recommends waiting to see what potential opportunities lay ahead and setting a budget later. However, it may be more practical to set a budget now to discipline the rest of the requirements-gathering and vendor winnowing, while remaining flexible depending on what arises. In either case, don’t forget about the cost of customisation and integration. Account for all of the services you may need and only set aside 25-35 per cent of your budget for software.

Review technology alternatives Use your requirements and the outlines of the new system to develop a workplan, which will simplify matters for you and the vendor alike. The workplan, together with your use cases and the deliverables described above, can serve as the basis for a request for proposal (RFP).

Vendors will gladly come in to present their products first-hand, which may serve as a learning experience and could help sharpen your requirements and shorten your list. But chances are that if you have designed your system carefully, you might not need to conduct a wide cattle call.

Always have them demo your use cases rather then their canned routines. This is vital. A browser with a good internet connection is much more useful here than a Microsoft PowerPoint-slide presentation. Insist on the former.

Be sure to ask what optional modules the vendor will not include in your solution and is not including in its price. Unfortunately, ‘sandbagging’ remains rampant in ECM: to fully realise a solution after you are underway, the vendor informs you that you must purchase optional modules. This potential for extra cost is especially important to consider for ‘deployment’ modules and application server or portal connectors. The bottom line here is that you should not be seriously comparing vendors until you have completed the previous stages.

Perform due diligence

You probably already know the importance of performing due diligence on server software, but in any case, here’s a brief primer.

For starters, you’ll want to talk to companies just like yours who have already implemented the package. Vendors will total the number of licences they have issued in the past year, but try to find out how many actually were implemented and then kept the product.

If you are suspicious about a particular feature or module, ask to see it in production on a live server from among the vendor’s clients.

This is especially critical when your implementation depends on integrating two or more products – the fact that the vendors are ‘partners’ often means little. How many sites currently use those two products in tandem now?

Fair or not, it’s the early adopters that provide integration lessons for everyone else.

If you are going to procure professional services from the vendor or an integrator (and you probably will), be sure to meet the team who will work with you. Every company has experienced ECM hands. Many of them are extraordinarily knowledgeable, but unless you are BP or General Electric (or even if you are), they are likely to be preoccupied with the next sales call as soon as your contract is signed.

So, meet the actual project managers, architects, and developers who will be implementing your system or training you how to run it. If you can’t work successfully with them, what makes you think you can work with their product?

Note that this is especially important with vendors who are enjoying substantial success and momentum in the marketplace, and are therefore growing fast and hiring a lot of staff. That’s right, corporate financial health and the quality of the human resources at hand can be competing dimensions.

Review any vendor’s financial performance, but with a grain of salt.

We have seen big, successful companies jettison ECM offerings and niche vendors survive and thrive. Note that most of the major ECM software players have gone through the stress of flat sales earlier in this decade and only in the past few years have climbed out of this trough.

Nevertheless, there remain key metrics to evaluate, such as available cash (and burn-rates for cash-flow negative companies) and revenue momentum. Of the two, cash in hand is the best indicator of whether a company will survive. Use your experience – and instincts – here. For better or worse, positive ‘buzz’ around a particular vendor may be a better predictor of long-term viability than the quality of the technology.

Consider asking for a proof-of-concept If you are about to blow hundreds of thousands of any currency on ECM licences alone (with integration on top), it’s reasonable to ask your list of vendor finalists to come in to your shop, install their packages on your hardware and to develop some sample templates and workflows that make sense to your team.

You should define this exercise in advance, using your scenarios, rather than using canned vendor demo sites. Note that, depending on whether the proofs can be done concurrently, a proof-of-concept step could add a month or more to your selection cycle.

Nevertheless, this kind of ‘show me’ evidence can be a powerful indicator of which offering will work best for you. In our experience, it saves time in the long run.

Perhaps most importantly, it is the best way we know for actual system users to definitively identify what will work best for them. Don’t be scared by this. It is to your benefit to emplace accountability with end users. You may risk ruling out a vendor who elects not to compete in this way. For an enterprise installation, this is an unreasonable position for a vendor to take, but in the mid-market, the cost of participating in a proof-of-concept could far outweigh any margin the vendor would likely achieve.

One way to avoid this is to offer to compensate the vendor an agreed upon sum for their time (but not their software) if they invest in a proof-of-concept and do not emerge the winner.

If you can’t do a proof-of-concept, then at least send your staff – developers and users – to training at the two vendor finalists’ training centers. You’ll likely have to pay for it, but it will be a fast way to feel certain about which solution will best suit your needs.

Choose a package

With solid requirements and a firm budget the choice should be fairly clear by now. Negotiate your best terms. If you go the proof-of-concept route, you probably want to negotiate those terms before the final tests, when you will still have maximum leverage, but hold off on completing the contract, as issues may arrive during that phase that you might wish to address in the final agreement. No software is perfect. Conduct a group debrief after the competition phase and make a list of what you don’t like about the package you are going to select. This helps you set internal expectations and account for necessary workarounds as you finalise the implementation plan. Contributing resources towards resolving some of the shortcomings your team finds could be part of the final deal.

Prototype as early as possible

If you are purchasing a large system, consider confirming that you made the right choice before getting the full number of licences you will ultimately require. This means quickly implementing even a partial solution for part of your platform – perhaps a single section within a single department.

That way, you – and your vendor(s) – can learn critical lessons while the stakes remain reasonably low. It will also enable you to show project momentum.

And if it all blows up, hopefully you will have hedged some of your investment.

That sounds awful, but what is worse than admitting a mistake and switching to a different package? Not admitting your mistake and being stuck justifying a system that doesn’t meet even your basic business needs. On many occasions CMS Watch has heard, “Yes, this software stinks, but we paid $X00,000 for it, so we have to use it…”

Alan Pelz-Sharpe is a principal at CMS Watch, covering ECM technologies and practices. He is the author of the vendor-neutral report, The ECM Suites Report, which was published in April 2007. This report is written exclusively for ECM technology buyers and features comprehensive reviews of some 30 ECM software suites, as well as copious practical advice for buyers and users. It is arguably the most comprehensive report on ECM software available. For more information please go to: http://www.cmswatch.com/ECM/Report or contact Alan directly by e-mail, aps@cmswatch.com.

Six common pitfalls to avoid (and best practices to follow)

Throughout this process, you can take advantage of the lessons learned by those who went before you. Having led many ECM implementations and after debriefing dozens of practitioners, CMS Watch analysts have seen much go wrong – and much go right. Here is a distillation of some common pitfalls, along with best practices to follow to improve your likelihood of success.

Pitfall one: Selecting an ECM package before developing solid requirements and a business case.

Best practice: Gather thorough requirements – but only after establishing a business case to shape and discipline the process – then select a package that truly meets your needs.

Pitfall two: Thinking an ECM software package will provide an ECM solution.

Best practice: Model your existing and prospective ECM processes and content stores

using building blocks of people, content, practices and infrastructure.

Pitfall three: Not involving internal stakeholders from the very beginning.

Best practice: Involve system users in the design, implementation and testing of the system.

Pitfall four: Spending insufficient effort describing and organising content, and underestimating migration times.

Best practice: Invest in mapping the structure of your content, ‘chunking’ it, building workable taxonomies and creating user-centric information architectures. Then clean your data.

Pitfall five: Looking solely at the product and not enough at the vendor.

Best practice: Perform as much due diligence on the vendor company as you do its product.

Pitfall six: Missing or underestimating internal change management issues.

Best practice: Recognise and make explicit how new systems and tools are likely to affect peoples’ jobs and enlist their support for productive change.