Is your ECM Portfolio Management in a Rut?

I recently had the opportunity to meet with a client that had implemented Documentum Webtop 4 years ago. I was part of that implementation. It was like being in a time warp to return after 4 years to see that really no further expansion of the initial roll out had occurred save for adding on lots more object types. This is an obvious sign that a painful gap exists between what the business wants and what IT delivers. Just tossing in a content management system will not fix issues of communication and lack of persistence.

Like the truck in the photo, Portfolio Management is stuck in a rut. It may not even exist. Here are some of the pain points of everyday users take for granted:

• Not being able to find what they know is in the repository.
• Wanting to be alerted when a certain document is approved and meets certain key/value criteria: this is a tell tale sign of lack of workflows which would organize and alert groups and individuals as documents are approved.
• Harboring grievances with DCTM interfaces and tools for years to no avail.

It is easy to blame the content management system for all the woes of just trying to get your work done, but most of the time the blame is on the company's lack of process around listening to what the business wants, how they work, when, with whom, etc. Listening comes first, then documenting, budgeting per business unit (not through IT), managing this portfolio, and, at the end, having IT get it done. Many mid-sized companies do not put too much emphasis on IT portfolio management, let alone content management. Thus if issues arise with content management, IT is blamed, not the breakdown of portfolio management.

The need for dedicated IT business analysts

What happens when business units have a phobia of workflow automation? Nothing, unless IT has a strong business analyst who works with the business to figure out the best ways to automate their headache routines, to detail content and approval processes, to advocate for the business with an eye to the reality of what IT can get done.

Lacking representative governance

Centralized governance for detailing and prioritizing content management projects is key to the success of ECM. The group can not be run by IT as they will bulldoze through projects according to the last technology conference they went to. Business goals and requirements must be the drivers of the projects and priorities.

Technical Architects and CYA

If you are lucky enough to have an IT Architect, hopefully he/she can communicate to both the business needs and technical aspects of them. Many company put IT and architects on a pedestal, which causes conflict if there is a "we and they" environment. If there is a "Cover Your Ass" attitude that usually means that a good chunk of productivity is lost to long winded emails and in battles among IT and between the business and IT. If there's CYA going on, then there's portfolio management dysfunction.

A Road Map to Health

An ECM roadmap, which shows high level goals and detailed ways to get there, is needed for the restoration of trust and communication between what the business wants and what IT delivers. This roadmap should be developed jointly between the governance group and IT with architects and business analyst in the room. If there is a person doing too much talking or pushing around, gently ask him/her to respect the needs of everyone. Having an outside study done would be a disaster and is usually sponsored by individuals who have an agenda that may not be good for governance and portfolio management as a whole.

D2 built on ruins

The "new" D2 client from Documentum is similar to how the Native Americans of Chaco Culture built their pueblos on the ruins of previous structures. EMC seems to like to reinvent the UI wheel every few years. To make our day to day lives a little easier. D2 is their latest attempt to make the UI configurable, flexible, and relevant to today's expectations in client software.

Chaco Culture: Pueblo Bonito

I am not going to dive into the improvements of D2. Let's just say there are many and it's about time. What I will say is that, like Sharepoint, D2 represents a progressive layer of understanding of how users use software to store, describe, and use content. It's another step up the ladder of awareness and better technology to get the tools into the hands of the users who need them.

Will D2 leapfrog Sharepoint as the slick configurator of content management UIs? I doubt it, but it will eventually help with migrations and maintaining consistency with platform upgrades, assuming that it is well tested. This is a big assumption. Speaking of migrations: there's a lot of work to be done moving WDK to D2. All of those customizations out there, all of the tireless hours of converting TBOs...

So the question is do existing customers leap to D2 or do they hold onto their WDK foundations until the last supported release is a year old? If the customer is an old timer (more than 5 years with DCTM) chances are good they will analyze the cost of migrating to D2 vs. another CMS. The leap may be too much to make. It might be cheaper to migrate to open source or another CMS, or DCTM 7.0 might be a must have. I'm hoping for the latter.

Upgrade to More Simple and Other ECM Trends

This image is from www.stickfiguresimple.com

Churn = Change in ECM
In general, IT and business stakeholder churn influences the evolution of ECM systems. As business units become more savvy as to what can be done for free in the public domain (ie, Facebook), they demand the same for proprietary software. For example, Documentum burned through a number of costly search engine deals before settling on open source Lucene. On the flip side, the business is preferring Sharepoint for its ease of use.

CIO Revolving Door
In the middle is IT, contracting development of custom ECM tools and integrations, pushing for automation (without a clue as the intricacies of the business processes--usually), thus burning its bridges within their own companies. Then the CIO leaves or is fired. The new CIO "knows" how to deal with the issues (Laughing at the CIO) which changes the information architecture stack under the guise of innovation or an inflection point.

More Simple Configuration
Microsoft Sharepoint started the trend towards simplification by copying everything that was out there at the time and being smart about configuration. To counteract this trend, OpenText is hopelessly behind and Documentum bought D2 to leapfrog toward Sharepoint. This direction will lead to more emphasis on change management as companies realize how disorganized their content is. Like Sharepoint sites gone wild, enterprise content has been built business unit by business unit, even if it was centralized. Simple configuration will mean more consistent rules and policies around metadata and taxonomy.

Consistency = Lower Costs
Consistency will help all ECM systems simplify their compliance efforts. Records managers will have to streamline their complexity, lawyers will get better at mandating search and destroy rules in order to avoid potential lawsuits, and IT will take one more step back in terms of their influence in providing information technology direction.

Leaner IT
IT departments will basically become shells of what they were. Technical architects will be specialized based on industry. Outsourcing will turn into product development, not customization. Information Architecture will take on a new, more important role as the roles of the IT Director will diminish.

Secure Knowledge for $$$
This is a long shot, but we'll see: When a generic UI for information architecture and content is created--a Facebook for Content--more focus will be on security and monetizing a company's content and knowledge. Sharing information for bucks will happen, however the stealing of information, ideas, and software will have to be dealt with. As a publicly owned Facebook is required to grow its investor's money it will buy other content and knowledge from outside sources. As ECM system owners realize that the content they have and the analysis that they learn from it could be just as valuable as their core business, they will partner up with the likes of Google or Facebook for this new revenue generator. 

DCTM Demos Deep Dive

We all know that demos are a great way to show potential clients some of the more unique features/functionality of the product or service you are trying to sell. The issue is to what extent do you know the audience's concerns? If the audience is a pharma, do you focus on compliance and retention policy or do you focus on converting their paper process to electronic forms? If the audience is finance, do you show them an AP solution or an integration with ERP? The bottom line is the related experience you bring to the demo. To really be able to talk about the pain points and show how the product solves them.

The days of a dog and pony show are over. Today's audience are made up of business savvy folks who not only want automation, they want someone who know's what the hell their talking about. If you don't have an analyst who is part of the demo, the demo will look like this:

Realize that your audience will most like sit through a few demos from other EMC partners, open source alternatives, competitors, etc.

Here is a list of key areas and questions to focus on when designing and developing a demo (or prototype):

Who is the audience? 
It used to be IT only, not it is a mixture of IT and business, so make sure the has plenty of meat on it.

Detail the Requirements
If the demo is for an Accounts Payable scan solution, make sure to focus on the inconsistencies of invoices, the exceptions that happen, why payments are held up, etc. Do not promote that everything can be done with configuration unless you are absolutely sure: if you make this mistake and get the contract, good luck extending it after blowing deadlines and coming in over budget.

Audience Push back
Be prepared to defend automation and new ways of looking at old software solutions. Most clients want to design a solution which mimics what their sneaker process, which includes design electronic forms that look exactly like their paper forms. Be prepared to explain advantages of perhaps splitting up the forms for security or signoff reasons, or for reasons of sustainability as the process changes over time.

This is my JOB!
You might be showing a demo to someone who sees it as obsoleting their job. They will pick the demo apart for its shortcomings. They will feel compelled to prove their worth with the knowledge. Take the opportunity to more fully understand their issues and undermining techniques. Be sure to respond with assurances that this will not take their job. If the demo is a workflow, the "big brother" aspect may enter into their minds. The point should be that automation frees up knowledge workers to think and innovate more...

Reports
Business folks love reports. They have the knowledge to interpret them and need to Powerpoint them to the higher ups.

Technical Architecture
Make sure you know how the demo can scale with number of users, the expected performance, levels of security and encryption. Again, if you promise what you don't really understand this will come back to bite you later if for example the encryption level that is required is not fully supported with the OS and software implemented.

Stories
Be sure to have someone who can tell battle stories and how this demo's solution succeeds. It helps to drink your own Koolaid, but how many EMC partners use Sharepoint? A lot. Why? because it is easy to setup. Why aren't all EMC partners required to only use EMC products? Good question, try creating a demo of a break/fix system like Jira and you'll know what I mean, but seriously, if you took the time to use the products that you design solutions for you'd feel more of the pain that your audience goes through.

"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.

Quick Overview of Designing a Basic DCTM Solution

Make sure the business requirements are complete and describe use cases on how the users plan to use the system. The users might say they want everything the "old" system has, but work with them to be as detailed as possible.

Content

List out the attributes which describe the assets.

Custom objects types should be created where the attributes are not standard and need to be entered in, validated and searched by the users via forms on the application server.

Security: Users/Groups/ACLs

Access Control must be detailed out and matched to the custom object types. It may be that you will only have one custom type and one main ACL.

• Users need to be mapped to groups
• Groups to ACLs
• ACLs to folders/objects

Lifecycle

These are used to automate changing attributes on content as it goes through stages of development from Draft, Review, Approve, Obsolete, etc.

Business Process

Using the Use Cases as a guide, create workflows which have activities that follow the procedures for publishing and/or storing assets.

Search

The key to find content is to describe it well enough so that users can find it better than they do now.

Folder Structure

Keep folder structure simple, 2-3 levels deep max if that, and rely more on search to find content.

Most important steps:

Document functional and technical specs

Build prototypes for the users.