Introduction
Over the past 12 months, we’ve seen a large influx of customers and system integrators approaching us for ECM projects that have gone astray. These are primarily due to a mismatch between the quality of resources and the type of project.
By the time these customers and system integrators have approached us, they may have exceeded their entire project budget by a considerable margin. Depending on the damage done, the cost of our fixes may end up with a project outcome that is nearly 2x the original budgeted project cost.
At best, we end up fixing only a few problems of the many ones we could, to help a customer limp across the line because it’s too late to do any more. At worst, when the design is irrecoverable, you are helping a customer get through “go live” in line with the rest of the implementation, knowing that the customer has to reimplement the solution in its entirety after go live.
In this article, I thought I’d put together my thoughts on how some of these projects are going south and some early warning signs to avoid these issues.
Consultants with limited experience
Some experience is better than no experience, but in some cases, it ends up with more damage as the consequential problems are harder to spot. In everyday language “knowing enough to be dangerous,” is coming true and recently I’ve been able to appreciate why.
It is the occasions where a consultant has some experience in the defined module, either as a result of assisting with previous implementations or who has worked solely in a support function previously. They may now feel they have enough of an understanding of how to design the solution and perform an implementation.
This often stems from the Dunning Kruger phenomenon, creating a false sense of self-confidence in their own abilities and not recognising what they don’t know. When you are on a project it is also difficult for you to spot the lack of candidate experience without you having specific knowledge of the solution (how the design should basically look and how those projects run). It’s fish in a barrel, the consultants don’t have to be a rocket scientist to convince everyone they are; they just have to know more than “everyone in the room.” With limited OpenText project experience and very few system integrators or customers with experience, it’s not surprising that this problem often goes unnoticed until it’s too late.
“The less you know the more you should expect in their experience. Eg get a Basis consultant with 10 projects in that industry under their belt rather than 3.”
The consequence of this situation is multifaceted: The first emerges in the design. Lack of experience equates to design issues because the consultant in question doesn’t have the expertise to understand theory vs. practice; to predict the complex consequences of design choices for high volumes of content. Experienced consultants know when to push back on the business to prevent bad decisions, for example, those decisions deviating from best practice which are better addressed by change management or another approach.
The second emerges when it comes to the time required to avoid issues. An experienced consultant is familiar with common issues in advance, and in most cases, the more uncommon challenges as they have seen nearly every scenario. Most projects run on tight timelines, and any weak links on the project create additional risk commonly delaying a go live.
Consultants with no experience
It’s hard to believe, but it’s common to see projects where the consultants implementing the OpenText solution have absolutely no experience in the associated SAP functional module. It’s like having a data warehousing consultant work on a new module. Different concepts, security, objects etc.
There are a few reasons why this occurs:
- A failure in the project management to scope in OpenText adequately, so it’s left to the technical Basis team or another domain consultant to the scope and implement the solution. It’s generally based on the misconception that the OpenText document solution is easy to configure and doesn’t require much work or that the solution is provided preconfigured.
- The customer or system integrator fails to realise that OpenText is as broad as SAP ERP and has a large number of products in their solution set. For example, an SAP Vendor Invoice Management (VIM) consultant is an entirely different skill set to an Extended ECM consultant. Like SAP, there isn’t a one-size-fits-all “Opentext” consultant.
Given you have someone with no module experience, what exactly can go wrong or can’t go wrong?
I’d equate it to the same as putting an SAP basis consultant on a SuccessFactors implementation as a functional HCM consultant. You’re in a position where the consultant doesn’t understand how the solution should be designed and built, both technically and functionally.
Depending on how long the project continues before the lack of skills are identified, the risk to the broader program can be catastrophic. You can’t go live with plant maintenance without basic alignment to the document design – yes the documents need to follow the PM design or vice versa.
If the impact is identified early, you’re starting the stream later than planned and playing catch up with more resources than initially envisaged, and the cost to output ratio of resources isn’t linear.
If identified later, it may be too late to fix for some areas like Asset Management; ECM is mandatory and impacts the ability to go live with the solution. The migration of structure data is nothing compared to the effort to verify, manipulate and migrate the associated documents and diagrams.
There could also be roll-on impacts to peripheral areas such as mobility and work order printing. We have encountered situations recently where SAP solutions have had to be redesigned to cater for design issues in the ECM landscape that are too costly to rectify.
In one case, the solution was so poorly designed that it would require a reimplementation to rectify the issues – the customer considered reverting to an outdated legacy solution because at least this works.
How to avoid the problem:
There are a few things you can do to prevent the issue:
- If you’re a customer, check individual resumes for your consultants working on the project. A lot of the time, some of the smaller process areas of the project aren’t checked because they aren’t considered core areas. Your consultants should have multiple project experience as a lead.
- If you’re a system integrator, check the experience offered on the resume is legitimate. Believe it or not, we’ve been asked to check resumes where the experience on the resume is for projects we have implemented, and the person in question didn’t even work for us. The references should also include customers, not just other system integrators.
- For both customers and system integrators, check the timelines proposed in the resumes. If they seem unrealistic for the type of implementation, they probably are. There aren’t any magic ways to deliver OpenText projects in unrealistic timelines.
- For both customers and system integrators, be specific with the experience offered in the resumes. Many candidates will tailor resumes to fit the role, or in some cases, invent experience they don’t have. As an example, Opentext Vendor Invoice Management might be changed to Opentext to make it more aligned to OpenText Extended ECM. Extended ECM and Vendor Invoice Management (along with many others) are vastly different solutions, so unless the consultant has multiple projects with the specific solutions, they’re junior.
- Look for the warning signs. If they start trying to change the scope to a different product, ask yourself why and ensure they aren’t descoping the areas they aren’t familiar with to suit their skillset. The de-scoping or changing scope isn’t a bad option as long as it’s what the customer needs, not the consultant.
- System restores aren’t common – In the entire time our company has been running, we’ve only ever had one of our consultants use a backup to restore an environment where there were issues with an upgrade. In that particular case, it was unusual; the first of its kind in Australia, an undocumented prerequisite for the upgrade. If a consultant requests a system restore to fix issues or multiple, that’s a red flag.
Why specialised consulting companies are a better solution
One of the ways to avoid these issues is to engage with specialised organisations. You don’t go to your accountant for plumbing advice, and that’s the case here. A specialised organisation provides a couple of benefits:
- A selection of consultants who are all skilled.
- A lower likelihood of someone not having the prerequisite skills as the organisation has the internal knowledge to identify those consultants whose skills don’t match their resumes. If they are any good, they will require new consultants to work under an existing one to validate their skill set for the first implementations.
- A lower likelihood of problems. Even if an experienced consultant hasn’t encountered a particular problem before, he/she has many colleagues/consultants in the same company to approach and validate the correct problem-solving technique. The power of many minds is greater than one.
- Guaranteed results. Niche companies rely on the individual reputation for a specific solution, so a poor implementation can’t be hidden behind a good project.
Need help?
If you’re not sure if you’re getting what you need, feel free to message me privately or send me an email at athol.hill@chromeconsulting.com.au. We can help you validate CVs, strategy, design, project plans and much more.
This article is sponsored by Chrome Consulting
