"With Liberty and Justice for Some" applied to ECM

Glen Greenwald's book, "With Liberty and Justice for Some" can be applied to the world of enterprise information management. In my 20 years of watching content management projects gain political momentum inside companies, be rammed through the process usually ignoring the requirements of key groups, finish with fanfare and pomp, and then IT moves onto the next big project. This is not new, however Greenwald's point that we need to resolve the issues of the past in order to move on fairly and responsibly is crucial.

No one wants to look back on an ECM project's successes and failures, especially given the fast pace of software technologies. When I'm done with a project, the core software has been patched and a major upgrade is approaching fast. If the teams involved with designing, developing, deploying, and testing the project could sit down and work through the issues (because there were no doubt issues: always are) retrospectively the whole company is that much more richer in understanding and agile in their pursuits.

I know, this is called a "post mortem". All companies do this or at least try halfheartedly. What I'm really getting at is true analysis of who the bullies are in the process, which groups got shafted, who broke the rules for personal reasons, etc. I concerned about the characters involved; what they did that was constructive and what they did that obstructed the process. In most companies a "post mortem" is done by the IT team, maybe including a few doers from the business side. Management does not get that involved, unless they want to fire someone or control the situation (I know pessimistic) .

If management understood the underlying negative impact that some of the projects and software used impose on their workers, they would demand closer scrutiny of every project. Instead, management seems to be more keen on the next big thing, leaving the workers to scrap together new ways to design and develop the mess they were just handed on their own. I say mess because information projects never really end; they have a "long tail". Some information management projects eventually fail because they were not nurtured and fed the right amount of emphasis and attention that they rightfully deserve. Just as Greenwald says that the elite have impunity with the rule of law, so to companies and managers as whole need to take their share of the blame, retrospectively, when an information management project fails.

Demos: Not as easy as it sounds

Creating a plain vanilla software demo is easy. You follow the tutorial if you haven't used the software before and create a simple solution to show a potential client. That worked years ago. Now demos are supposed to be multi-tiered catering to new users and experienced users alike.

What is usually missing during demos is a focused solution which solves the business problems that have brought the potential client to see what the demo is all about. They have most likely seen the same vanilla demo over and over again if they are being pitch an xCP solution.

What the client is looking for is your understanding of their problems, that you've been there. Some can see the potential of the demo to solve their problems. Others will want a business analyst to give the details of how the requirements of the business will be matched with the functionality of the software.

The problem is that every business is unique and are seeking software to fix issues with their processes or content management or collaboration. They have gone to the trade shows, they have read the books, they want to move up in their companies. Now you have to somehow convince them that the software can get them their promotion, or at least make them look good.

If you have a fast talking sales guy in the room make sure you get a feel quickly if the clients are comfortable with his energy and fluff. If not, have the demo talk. If that doesn't work, bring out the business analyst who has been in the trenches. If they chew him up, walk away.