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.

1. 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.
2. 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.
3. 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.