Top 5 To-do´s to avoid ECM project disaster

Author: Tim Stijven

It is typical for xECM (extended ECM by OpenText) or ECM (Enterprise Content Management) projects in general that they are still a rather niche type of project.  That means that within the customers, there is no extensive experience with this type of projects.   That is different compared to for example ERP or CRM projects, for which customers usually have strong inhouse competences.   


Don´t worry.  It is nothing to be concerned about and quite common that companies purchase this needed competence externally, both for project implementation as well as support or application maintenance services.  Obviously, it is then key to select and work with experienced specialist vendors rather than generalists,  or at least complement the generalist system integrator with a specialist vendor.  The experience, dedication and focus of that external vendor can bring you that valuable experience which an organization does not have inhouse.   That being said, no excuse to come unprepared to the start.   Focus on below top 5 “to-do´s” and you are avoiding (x)ECM project disaster.   The list is in random order, as certain aspects might be more relevant to one customer compared to another.


The topics listed are concrete and focused on project setup and project execution.  Not included, but very important is project governance.  You need senior management stakeholders to outline the strategic directives.  Example:  is the directive standard best practice (as the process in question is not considered a competitive differentiator) or company specific to actually get that differentiator from competition?   Depending on the situation and strategic directives, one can handle evaluation of custom developments versus standard best practice.

1. Involve the Business

Business involvement is needed throughout the project, not only at beginning or towards end.  Only this way you can secure building a solution that not only works, but is also workable for the Business.  The representative(s) from the Business should be people with in-depth insights in how the Business works, be able to split the must-have´s from the nice-to-have´s and have access to real users in the Business for validation or review of solution design decisions.   ​

2. Insist on User stories

Insist on user stories during requirements analysis phase. They help to move from vague to specific​.  In modern times, our advice is to keep the Solution Design and Requirements Analysis phase rather short.  For various reasons.  One, requirements tend to change over time.  There is a learning curve on customer side getting a progressive better understanding of the ECM solution (see point 3.)   Despite approaching this phase in compact and efficient manner, it is key to have clarity on the requirements.  Asking the customer to write out the requirements in user stories will turn out to be of great value.  A good user story is characterised by the following:

  • Scenario: indicate what part of the process the user story is relevant to
  • Use case description
  • Role: who executes, what type of end-user performs what actions
  • Personas

3. Embrace change, be Agile

Be agile enough to allow changes, as they will happen.  Embrace the mantra that “Changing requirements are better requirements”  Value the learning curve.  Let go of mindset that everything is known upfront. However this is not a free ticket to go step-by-step and be unstructured without a plan.  Be clear upfront on the vision and the direction, then plan for that.  ​ Tip: plan Solution Design in Sprints, clubbing solution aspects logically together.  

4. Organise an iterative Build phase

Make sure to have short iterations during Build phase (Sprints) and plan for testing by Business.  In case Business cannot free itself up for testing, make sure to plan for short demo´s after each sprint to show and collect feedback from the Business​.

5. Pay attention to technical infrastructure

Experience tells that projects fail or delay due to people rather than technology.  However, a solid infrastructure and technical architecture is key.  Make sure to have scalable architecture to deal with growth of users and content while protecting good performance​.   Plan for a good and experience Architect for this piece, as such insights and competences come with years and are typically never exhaustively described by the software documentation or training’s.


Keep an eye on those aspects and you will not fail and deliver on time.  Good luck and, importantly, enjoy the project and the value you are adding to your organisation.


Other Turnpikes Blog posts:

Let's share this blog post:​

Share on facebook
Share on twitter
Share on linkedin

View all posts: