Category Archives: ECM

Enterprise Content Management (ECM): Web Content Management Systems (CMS or WCM), Document Management, E-Mail, Collaboration Systems, Groupware, and more.

ECM, Grumbles, New Paradigms

Non-collaboration: the “To Each His Own” approach

What has finally moved the Portable Consultant to post after all this time? Frustration!

So-called “matrix teams” come from different work units, by definition. In my current business environment we come together for a project, apply our subject matter experience, and go on to the next project when done. Each member reports to a different organizational unit, with a ‘dotted line’ to the Project Manager.

Unfortunately, the collaboration systems we use are all too often designed by, and for, those separate work units rather than for the projects.

This results in the following (in no particular order):

  • Separate repositories for the business analyst, the infrastructure architect, the project manager, etc.

  • Where cross-discipline access has been considered it is likely to be hit-and-miss, depending on who asked for access to the repositories of the other groups and when. This results in name-based rather than role-based access.

  • Different naming conventions between repositories.

  • Different taxonomies (folder structures) for each work group.

  • A general lack of consistency in meta-data (where it exists) and searches (which should be based on that meta-data).

The diagnosis of the To Each His Own approach to collaboration is confirmed by the high number of email attachments that are necessary for the matrix team to keep members informed and documentation current.

In my current situation it wouldn’t even be enough if the project manager were to set up a shared repository – there are two PMs: one for ‘the business’ and one for ‘IT’. Even these PMs don’t share the same repository.

The solution for this To Each His Own approach varies from situation to situation. The first step in all instances, however, must be a realization of how fruitless it is to invest in collaboration without some form of inter-group oversight or cooperation to support the matrix team environment.

Have you encountered this where you work? Did anyone try to address the situation? What approach succeeded? …failed?

Yours sincerely on a typical Monday (but posted on a Tuesday),

Cheers,
-pmh

ECM, Grumbles, Ramblings

Some ECM “Do’s” and “Don’ts” for February

In the northern latitudes of North America February is considered quite a dismal month. With cold, grey skies overhead and worthless, shadow seeking groundhogs below there is not much to be encouraged about except the slowly lengthening hours of daylight.

The Portable Consultant is feeling understandably low, therefore, when against this bleak backdrop he is exposed to an ECM project that seems to model much that can go wrong with an ECM initiative.

While the following is not intended as a comprehensive list, these are some of the Do’s and Don’ts that the principal consultants on the project failed to be aware of. In no particular order they were:

  • Do have a Project Charter… an SOW is nowhere near good enough for the implementation of a critical enterprise infrastructure such as an ECM.
  • Don’t undertake ECM as an IT Department driven technology project… ECM is more dependent on business requirements and business processes than, say, a new firewall. These days the IT guys should be tightly integrated with the business; e.g., the head of IT should be a CIO who ensures C-level priorities, not technology, drives IT.
  • Do establish an ECM Steering Committee that is representative of the whole enterprise and leverage them to provide guidance, impetus, and a high-level sign-off for company-wide issues such as the corporate taxonomy, key metadata, and security models as well as critical SLA and Disaster Recovery (DR) requirements. Specifically…
    • Don’t confuse backup/restore requirements with DR. DR is about business continuance after the entire office and/or data centre has ceased to function while backup/restore is about a broken server, corrupted database, or some such.
    • Don’t just sit down some afternoon and enter new metadata fields into the production system on the fly without first gathering, documenting, and having affected parties sign-off on the relevent requirements.
  • Do not rely on business units to gather and present their own requirements without extensive guidance from knowledgeable ECM consultants who can speak to the business in their language, the language of business processes not software configuration.
  • Do not expect one of the Big 4 consultancies to necessarily know all this and manage the project according to ECM Best Practices… sometimes just one experienced independent consultant can be enough to help even a large global enterprise to navigate the treacherous waters of ECM deployment… without all that excess overhead. <grin>

Sigh. Time to crawl back into my burrow, I suppose. Wake me up in another six weeks.

Cheers,
-pmh