It would be interesting to know how many failed ECM projects stemmed from the wrong deployment methodology. I was pondering on this after a discussion with Liz Ure last week in London. Liz is the Head of Information Strategy for the Scottish Government and she discussed with me the inappropriateness of methodologies that emphasis implementation, rather than change.

There are any number of methods being touted for ECM, from Agile to Prince2 through any numerous of (AA-style) "step" approaches. I have long argued that any methodology is better than no methodology, and these are all fine in their way. But to Liz's point, they all emphasize successful system deployment, with a focus on "going live."

However, ECM is a toolset that brings about profound business change. That change can come gradually, in small steps over a long period of time, but in a continuous fashion. In other words you don't just "get ECM." Instead you start to leverage content more effectively within your enterprise .

As ECM becomes more of an IT Infrastructure buy, traditional IT-oriented implementation methods will become ever more important -- but surely they should remain ultimately a sub-process/method to a larger business change process that needs to be undertaken. Fact is, few ECM project leaders are even aware of 7S, Competing Value Frameworks or (dare I say it BPR!). Yet ECM lends itself well to such approaches, just as it does to broader management approaches such as Six Sigma, LEAN, and TQM.

You probably already know this: ECM has a long history of falling short and disappointing, often with a huge bill to rub salt into the wound. One major system integrator told me the other week, "at some level all these systems work perfectly well," yet they continue to disappoint buyers.

Customers do well to recognize that profound business change is the goal here -- rather than the activation of some funky new software -- and that management methodologies may need to reflect that.