Monday, April 25, 2016

ECM Maturity Markers

The Bell curve graph above is meant as a rough visual representation of the maturity of ECM. On the Y-Axis is ROI, on the X-Axis is Time. Some companies have more of a Long Tail graph. Some have a straight line that never achieves ROI.

Marker #1 (year 1)

Discovery and Roadmap Development

The business is interview, given the heads up that change is coming.

Driving Force

Sets the stage for how the whole rollout will progress
Ex: Finance vs. HIM: the first project usually gets the most attention, the onsite vendor team, the full budget request, the flagship presence.


The project with the most bang for the buck is chosen and developed. The focus is on this project, regardless of the impact on other teams and systems.

ROI measure

It’s absolutely critical to get baseline measurements of the current processes. Measurements that highlight the FTEs involved with pushing paper, referencing multiple systems, etc.

First project Implementation

Usually the ECM vendor or associated consulting group installs, configures and deploys the first implementation with a lot of fanfare. It might even get mentioned by the CIO.


Within a year, the initial consultant(s)/employee(s) will leave project or company. They are there to feed off the initial expense budget and leave to get on another budget train.

Marker #2 (year 1-5)

Execute Roadmap

This is when the ECM manager attempts to execute as much of the ECM Roadmap as possible. As the ROI is realized, there are second and third waves of getting the most out of the investment. Licensing costs be scrutinized. Upgrades are delayed.


In some cases, the roadmap is rewritten to expand the initial vision of ECM, in others it is reduced. If the ROI goal proves hard to reach, more projects may get started to reach it.

Stop Gaps

ECM suites are capable of serving as stop gap solutions to many different areas. As other systems labor on with obsolete technology, ECM can sweep in and save the day. As older systems are replaced, the documents and images need a relatively inexpensive place to be stored for retention. This is perfect for ECM.


All possible integrations are added to the solution that stream line the indexing and processing of the incoming content.

Marker #3 (year 5-8)


ECM is fully mature; its expansion is over. The original team is smaller. Most of the maintenance is routine.


The biggest issues are scaling for storage and performance. In large ECM systems this can be more and more of an issue. The original Roadmap usually doesn’t include plans for splitting up the repository that is now huge.


At some point, a director will make the case to move the system to the cloud. Because it is huge, the argument to move it might be a good one.

Marker #4 (year 8 to XX)

Superseded by Better Technology

There will be a time when the shiny, new system becomes old and obsolete. The need to simplify and break apart the system becomes a necessity for survival . Technical advancements will become too glaring to ignore or workaround. Migration projects might start up to gradually dismantle the solution piece to move them into more modern systems.

Life Support

As new technology pressures increase, it may be an option to put the system on life support and left for retention only. 

Friday, April 8, 2016

9 Ways to Mitigate Risks of ECM Upgrades

We all know ECM upgrades can be challenging, we also know that in a perfect world there would be no hiccups. When does this ever happen? Some of the worse issues can explode when an upgrade is “supposed to have no impact” on other systems.

In Mike Bourn’s blog article, ECM System Production Deployments – What Could Go Wrong?, he describes the ways to mitigate the “busted weekend”. He describes the infrastructure and expertise requirements to mitigate risk. I’d like to add a few others:

1. Frequency There’s a reason that cloud services is supplanting onsite installation beyond cost: maintenance. It’s a way to have other do upgrades every year without the hassles of begging for resources. If you are still have your ECM system in-house, great! Keeping up with the version service pack 2 release upgrades is ideal for mitigating the various infrastructure and database risks.
2. Number of environments
The number of times you practice the steps involved with an upgrade is directly related to its success. 
3. Using Prod data
I can’t emphasize enough the importance of refreshing your environments with production data. The majority of content files don’t necessarily have to be copied. The issue is mainly around the potential issues with data quality and upgrade duration measurements.
4. Type of Documentation
Write documentation as if you have been up for 24 hours and are stress out. Create lists and take screenshots. Make believe you are dumb and need step by step instructions, don’t cut corners. Also, don’t blow off any install messages: these can blow up upgrades.
5. Reliance on outside services
It’s fine to have tech support on a support retainer for the cutover weekend, but I would try to do all of the actual pre work, testing, and troubleshoot. This is one of the best chances to learn more about your system, to gain an in-depth understanding beyond what the manuals or basic maintenance can offer.
6. Empowering the right individuals
Try to include as many individuals in on the upgrade procedures. Distribute the troubleshooting tasks among them. 
7. Testing Efficiently
Regression testing can get so bogged down in the weeds that larger issues are missed entirely. Try to design a multifaceted strategy that balances the number of tests with the likelihood that it would be affected by the upgrade.
8. Diversity of User’s OS and Browsers
Please don’t forget that the User base is not like you. Their PCs may not have been included in the last round of OS upgrades or patches. Their web browsers or java versions may be configured with different options. Their PDF viewer may be old. 
9. Ready to Go
If you have a multiple person team, keep one home and rested, ready to come in on the following day to deal with the post upgrade issues because there will always be some.

There are infinity ways an upgrade weekend can go bust. By drilling into each of the above areas, you should mitigate many of potential hiccups. If you are lucky, the issues will be minimal. You will be able to rest on Sunday before going back in for more on Monday.