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.