Documentum D2 4.0 – Risk Mitigation Strategy

August 21, 2012

We had a good discussion with a client last week that is looking to implement D2 4.0 out of the box for an extranet application. Given a new product and an end of year deadline for implementation, we discussed steps to take to mitigate the risk of D2 4.0 (or any product). This post will touch on those thoughts and share best practices mostly focused on a “try it before you buy it” approach.Try it before you buy it – User Requirements and System Capabilities

Core to our approach for mitigating risk of any project is a small “Phase 0” or “Sprint” focused on understanding the business requirements and how well they match the capabilities of the system. For a D2 implementation, a key risk will be that D2 is a “configuration only” application. While this approach could be beneficial for clients looking to reduce customizations, we get concerned that, for certain requirements, the D2 system may not be able to be configured to meet the requirements.

As we pointed out in our D2 limitations post, Power Promoting – the ability to move a document from Draft directly to Approved – is something that is not provided by D2. If the business has that requirement, users should understand that it is not possible and should look for alternatives within the D2 capabilities.

We would recommend a risk mitigation plan that focuses on a small prototype of D2 with a core group of requirements as the initial Phase 0 activity. In this manner, the risk that D2 cannot meet requirements can be addressed at the beginning of the project.

Try it before you buy it – System Stability

One valid concern about X.0 releases is stability of the new release, given the specifics of a client’s environment. Back in 2005, we had two clients looking to develop Documentum systems. One client chose the 5.2.5 platform for stability; the other went with the new at the time 5.3 SP0 release. While the number of stability issues associated with 5.3 SP0 cost the client and put some of the project at risk, the 5.2.5 client had to pay for another eventual upgrade to 5.3 at significantly greater cost and effort.

At this point, we would not recommend clients consider D2 3.1 to avoid the cost of a later upgrade. Given the newness for D2 4.0, we would recommend a risk mitigation plan with a phase 1 (after the phase 0 POC for requirements) that focuses on stability testing. Given the number of differences with D2 from existing Documentum infrastructures (Interface, Lifecycle, Security, Watermarks….), successful clients will be the ones that learn about issues associated with stability before attempting to release and later finding these issues in production.

Try it before you buy it – System Performance

One of the items that Documentum clients typically avoid is a performance test with appropriate volume of users and documents. While the system can perform well with small amounts of documents and a couple of users, performance issues can arise when production volume users attempt to access the system concurrently from a variety of geographic locations.

One difficult issue to address when trying to catch this type of problem before system deployment is the ability to set up a realistic performance test. While there are tools on the market, given the variety of users and activities, it is often very difficult (and expensive) to set up a realistic test to mitigate the risk without large costs without reducing the risk. The effort and possible lack of results (still get performance problems in production) is the reason many clients skip a large performance test. To avoid the cost and expense of attempting a full-blown performance test, TSG tries to mitigate the risk in a number of different ways.

Migration and Production Volume – typically we will recommend clients do a production load into the new system to be able to test the Documentum Content Server with full volume of documents. This testing is not as involved as multi-user testing and can help with performance tuning of the docbase.

Pilot Versus full-production Rollout – rather than a big-bang approach to production rollout, we recommend small groups of users along with their content to be gradually rolled into the system. In this manner performance issues might come up over time rather than a big-bang approach filled with lots of complaints from lots of users for performance and other issues including training, bugs and volume.

SWAT team once in production – given that it is very difficult to catch performance issues in development, one risk mitigation strategy would be to allocate resources from the development team to be able to quickly address performance issues if they arise in production.

Try it before you buy – Support

With any new product, support can be an issue. While users will uncover issues, a bigger concern is that the support engineers are new to the product as well. A successful risk mitigation strategy might be to test the support capabilities of Documentum with D2 as issues turn up in the Phase 0 or Phase 1 testing before moving to later implementation phases.

Summary

Successful risk mitigation strategies with D2 4.0 focus on having an understanding of how the software capabilities, performance and support will work in production before the application goes into production. We have suggested some of our standard approaches in this post. If you have other thoughts, please add below.

Comments

Great article – but *I ask with a little bit of sarcasm* how do you get your customers to pay for all these mitigations and still deliver the project within 3 months and true to the business case?

e.g. Great tips on the mitigating the Performance Issues – we also recommend the same approach to our customers but many times the issue we face is that the customers want to onboard a small group of users from – each region/BU – which can be challenging due to other constratins in the solution or the business e.g. if a Contrats Management solution is limited to one Department then senior management does not get full visiblity of all contracts from the new solution.

Is it easier & overall cheaper to just have an oversized platform instead?

I would typically say that the mitigations vary in price based on the risk. We recommend the Phase 0 regardless of the size of the project for all the risks associated with user acceptance and requirements matching up to the new tool. Some of the mitigations wouldn’t be needed for .1 releases but, given the rewrite for D2 4.0, we think they are all important.

For a 3 month implementation, all mitigation efforts around perfromance and stability could be in parallel to the development effort.

I agree that changes affect performance but see volume as a bigger driver than customization. Expensive queries like folder and repeating attributes will work great in small volumes but completely bog down with more documents. Typically having experienced Documentum developers understand the expensive stuff can help do the parallel performance testing before all customization/configuration is complete.

While D2’s configuration only model might eliminate the ability to customize, it is important to remember that many times customizations are done to improve performance (more efficient query – ex: begins with rather than contains).

[…] In regards to interfaces, clients should consider the relatively risk of new releases and new products. Documentum has recently released D2 4.0 . While we applaud Documentum’s effort to offer new interfaces, we cautioned clients to review the tool as any other new product as mentioned in this post. […]

One of the more interesting usages for machine learning is the potential to speed up and add efficiency to the indexing of documents. At TSG, we are currently adding this capability to our document indexing application. This post will describe the current methods of indexing from the major vendors and how an ECM 2.0 solution […]

Too often, migrating to Alfresco can be seen as a massive undertaking where the migration effort means moving all the content, integrations and people to the new platform in a migrate all at once, “Big Bang” approach. Given the effort to move all the different components, along with training the users on a new system, […]