ECM made simple – the hunt for

Anyone who has been involve in “Enterprise” Content Management projects will tell you that usually they are nothing but simple. This complexity rises from a number of from education to procedures, politics, skills, adoption, competence, technical chracteristics.. etc

The quick answer to this is to mount a big implementation project. And everybody is happy: the vendor sells licenses, the consulting team has billable months and the customer feels he gets something important since he spends the big bucks on it.

The problem is that this is the default approach from everyone at the table although it’s clear to any sane-minded person that at least half of such projects would be better if tackled with a different approach: give the customer a tool which he would want to use.

Most of the vendors identified this opportunity and addressed it with the “out of the box technical tool” or “platform” approach. These are at best some DIY kits for customer internal IT staff to still try to do a complex projects to address the ever complex business challege. SharePoint executed this quite well at least until it also hit the wall of complex projects/

Because the answer is not a technical tool or a platform.

There is no universal answer either. At least not about ECM ­čÖé

We need to diversify. We need strong competence for complex projects but equally we need to have a market for simple to use and access business solutions / applications. There are probably very very few who can do both well, I’m looking forward for a disruption in this area.

This requires a culture change for all participants. I can’t count the meetings I’ve been into where the customer pushed to have feature after feature inside the solution while the supplier said mostly “yes” since it would bring him more money. I call this the hunt for more muney and the fear of failure. After all, the supplier needs to eat and the customer to succeed.

From this situation we can’t escape easily. But we do need to.

Cloud is here to help. Is an enabler, not the answer. But it generates the kind of focus which can lead to a new market. The market for simple ECM solutions. Cheap, easy to use and easy to dispose.


Imagine buying a business┬ásolution for under 5k. Or paying under 1k/month for the use of your entire business unit.The CRM space is doing it so why can’t we? Basic Office is already like this, are we so much different?
And how do you tackle the complexity I’ve presented at the beginning? You don’t. You just let the customer decide and adapt. Money is the blood of enterprises and if you lower that entry point with a quality product then you just got yourself a new market. This does not exclude the big multi-million projects… it just adds up.It’s tough but it can be done and when can reach with it the impulse buy area for business owners, you struck gold.

But remember: business solutions, with the right equilibrium of features.

See you there!

What should an ECM consultant do

Consulting valueEvery once in a while I find myself in the position of an ECM consultant, brought in by the customer trying to define some Content Management solution or even a big funky ECM platform. And I have also a bunch of colleagues who do this on a regular basis (it’s their job, duh!).

When I picture the consultant stepping in the room I like to see the image of a professional carrying a suitcase, opening it up, putting on the white gloves, calm and imperturbable, client impressed and following with admiration…. you get the picture. So, can we reach this Hollywood dream?

Two weeks ago a senior consultant from one of the top traditional ECM vendor came into a project of mine. The customer specifically asked for the vendor to be involved since it’s about the setup of an ECM platform / vision. Came in, spent 1 week in discussions, generated a PPT and left. That Powerpoint presentation had only one slide actually related to the needs of the customer, a slide which roughly listed some work packages to be done in order to achieve the vision. As much as I would love a magic PPT to solve world hunger, this was not. #epicfail

I’m now doing the same for another project (while trying to salvage the one above also, with my colleagues).

Blank page, customer is anxious…. what should and ECM consultant do?

First: be a consultant. In my mind this translates roughly to this (just some guides, not a full definition.. ok?):

  • know your grounds. You must have deep knowledge about at least 50% of the products and solutions the customer would need. And I mean implementation experience, not just data sheets. Cover the rest of 50% through reading and documenting about it.
  • do your homework. Prepare for the task ahead. Make a plan, write down what do you want to achieve, set up a list of discussion subjects for each meeting, plan for time to digest the meeting afterwords
  • inspire confidence. You are the expert on the field, go to the customer and express confidence in your verbal and non-verbal language
  • be assertive. Nobody likes a consultant who comes and starts bashing things around. You can do that once you establish a trusting relationship with the customer.
  • know why you are here. Have in written form the scope, objectives, mission of the project. Stick with the customer to define them in a measurable and non generic fashion.

Then, be a senior consultant:

  • know the business process area. Don’t go into a telco client and discuss topics from the oil&gas. When you go to a bank, be prepared to talk “bank”. If you can’t… that’s too bad.
  • focus on the added business value, not on the features. This should really be a standard consultant trait… Please be aware that more often than not the ECM platform project will be run by IT. IT is usually a very poor customer when it comes to identifying and following the bussiness value for the company. You will struggle in this case, but please stand your ground!

Ok, but what about “ECM” consultant?

  • make a list of document classes. And for each establish their business owners inside the company.
  • data model. Describe each document class by its attributes. Focus on agreeing on a common set of attributes for all. While it’s very good to have distinct properties for specific class, ending up with hundreds of different schemas is usually very bad. Under 100 would probably be ok for a large enterprise. For a greenfield project, 10 should be fine.
  • make sure the data model has sample values for each and every attribute you list. Each and every one of them
  • user stories. This is more of a generic topic, but I find it especially useful in ECM projects. Focus on the happy path at the beginning, don’t explore (just write down) exceptions
  • map the IT landscape. Also generic, but ECM is very often the centerpoint of integrating data from various sources. Integration, SOA and master metadata management intersect with ECM platforms very well and intuitively from the customer
  • versioning. This can be a pain if not done properly. Start by discussing for each document class when and who creates versions. And how whould they behave.
  • navigation. One hierarchical structure to rule them all? Please don’t. Each business area will want a different perspective on the content. Try to devise a common, minimalistic structure (you need one, don’t leave without it) but be aware that you will need specialized perspectives on the documents almost for all business processes (and usually more than one in the same solution)
  • security. now this is “la piece du resistance”.KISS. If left by himself, the customer would usually end up with a model which is so complex nobody will understand why ┬ásomebody has a certain permission on a document. Try to define which security is applied to a document by a combination of 2, maximmum 3 metadata fields. Clearly define which kind of security is to be applied for “search/navigation/reporting” scenarios and which for the functionality available for a document at a certain step. You’ll find the solution quickly after this exercise. Ask “how is this done now?”
  • mockups. Don’t go in an analysis meeting without them. Only the more general meetings in which you define the scope, objectives, mission statement and such things can happen without screen mockups. As soon as you start talking user stories or any feature, always discuss it on a mockup (wireframe, screenshot, live, whatever suits you)
  • search functionality. Search is paramount in an ECM system. It’s not a “given” feature, it needs to be addressed specifically and you must describe who, how and why searches and what kind of information should be displayed by the solution
  • reporting. Don’t close the analysis without having them nailed. I usually like to start with them from the beginning, although it’s not completely intuitive to do this. You could end up revising all your data model from this, so it’s not a topic to leave at the end.

If you do this, you should have 80% covered. The rest is magic.