2019.11.26 – Blog post
It is typical for Enterprise Content Management (ECM) or Extended ECM (xECM by OpenText) are still a niche type of project. That means that, the customers do not have extensive experience with these types of projects. It is different when it comes to for example ERP or CRM projects, for which customers usually have strong inhouse competences.
However, this is nothing to be concerned about. It is quite common that companies purchase this needed expertise externally, both for project implementation, as well as, support or application maintenance services. Obviously, it is key to select and work with experienced specialist vendors rather than generalists. At the very least it is important to complement the generalist system integrator with a specialist vendor. The experience, dedication and focus of an external vendor can bring you a valuable experience which an organization does not have inhouse. There is then no danger of being unprepared from the beginning.
If you focus on below top 5 TO DO’s you can avoid any (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.
Something important to take notice of, which is not included, is project governance. You need senior management stakeholders to outline the strategic directives. E.g., is the directive standard best practice (as the process in question is not considered a competitive differentiator) or company specific to get that differentiator from competition? Depending on the situation and strategic directives, one can handle evaluation of custom developments versus standard best practice.
Insist on user stories during requirements analysis phase. They help to move you from something vague to something more specific. In modern times, our advice is to keep the Solution Design and Requirements Analysis phase short. For several reasons, one of them being that requirements tend to change over time. There is a learning curve on the customer side to 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 immense value.
A good user story is characterized by the following:
Customers implement xECM to connect it to one or more leading applications. This is the great value of xECM. You get the benefits of a proper ECM system and it is connected to your business process in other applications.
However, the implementation project and the system need to anticipate that xECM cannot control the leading application and what is done there by others. Often, it might be decided that xECM is connected to a mature leading application, even if it is decided to start with xECM on a small scale. E.g., xECM is only implemented in a handful of departments or just one country. The leading application might already be used for other things on a broader scale. This affects xECM – and not in a beneficial way.
It needs to be anticipated in the project plan and the system design, that xECM is affected by activity in the leading application outside the scope of the xECM project. E.g., the system might be sized to hold just a few thousand account workspaces for the departments that go-live with xECM. However, if not optimized, all account business objects in the leading application may trigger account workspace creation and updates in the Content Server. This can then easily fill the queues of search index or facets processes in the Content Server. This then results in issues for the xECM system that inherently affect testers during the project or users after go-live.
Be agile enough to allow changes, as they will happen. Embrace the mantra that “Changing requirements are better requirements”. Value the learning curve and let go of the mindset that everything is known upfront. However, this is not a free ticket take things as we you go along 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.
Make sure to have short iterations during Build phase (Sprints) and plan for testing by the organization. In case the company cannot free itself up for testing, make sure to plan for short demo´s after each sprint to show and then collect feedback for the organization.
Experience tells us that projects fail or get delayed due to people rather than technology. However, a solid infrastructure and technical architecture are key. Make sure to have scalable architecture to deal with growth of users and content while protecting reliable performance. Plan to have a good and experienced Architect for this piece, as such insights and competences come with years and are typically never exhaustively described by the software documentation or trainings.
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 organization. Do you want to read more about important steps when doing an implementation process?