Thought Leadership:
20 CTRM NOOB Mistakes to Avoid
In previous articles we have addressed important topics like implementing a CTRM system and looked at what support & maintenance consists of. This article moves on to take a look at the sorts of common mistakes Noobs, (new users), of a CTRM software might make. Of course, it’s impossible to list all potential mistakes but here are 20 that we see occurring quite commonly that can be avoided so as to help ensure a successful implementation and use of the solution.
Executives not prioritising the CTRM Implementation
During the initial weeks of the implementation and even beyond that, it is important that the client has one or many key users attend daily calls to discuss requirements and progress generally. If these meetings are not attended by these user staffs, delays to the implementation are inevitable. It is therefore crucial to any CTRM implementation that upper management emphasizes to the users that, although they still have their day job to do, they may need to dedicate time each day for the initial phase of the implementation and perhaps even beyond that.
No Super-User
Before the implementation begins, the CTRM vendor should ask the client to nominate staff to be “Super-Users”. These Super-Users will be comprehensively trained on all areas relevant to the client to gain an understanding the system’s full potential, and, once live, they will be able to provide solutions and assistance for other users without the involvement of the vendor’s support team or business analysts. These users then become the experts and in-house champions on the system and will be able to support and train their colleagues going forward.
Not being involved in the implementation
During the CTRM selection process often only a limited number of client staff are actively involved. Once the implementation begins, the client should actively involve all members of staff, however this does not always occur. Once live, it is usually the users who provided the most input during the scope and requirements phase, that benefit the most as compared to users who had little/no input.
Not producing real life business scenarios
During the implementation phase, the CTRM vender will ask for scenarios to be modelled for the User Acceptance testing (UAT) phase. Often these are documented with screenshots and evolve into a how-to-guide for specific use cases. Users who have input into what these scenarios (use cases) are will inevitably produce examples that they themselves are likely to encounter. Those users who do not have input could then face a scenario when live that has not been documented, leading to potential delays.
When the CTRM training sessions occur, users who turn up with a list of questions on that module, (or a previous module they have been trained on but want clarity), will benefit the most. Those users who do not prepare for the sessions could go live without a full understanding of what they need to do for their day-to-day tasks leading to inefficient use of the CTRM from day one of go-live.
Paying in full for implementation upfront
The user should look to pay for the implementation in phases and not all up-front. This allows the user to keep control of the implementation, with the vendor having to hit certain milestones in order for the next phase of the implementation to begin.
Allowing the vendor’s B-team to implement
It can often be the case that, during the sales process, the client will have been exposed primarily to the vendor’s A-team, consisting of users that have a vast experience in the industry and the CTRM you have selected. Once the sale has got across the line with signed contracts, the client should insist that a similarly experienced team conducts the implementation and not the B- or C-team, which can consist only of 1 or 2 junior business analysts. Having the best business knowledge on the team will help ensure success. The client should also insist that the head of sales and CEO should be involved at regular intervals during the implementation.
Not considering future plans
When the users are discussing the scope and requirements of the CTRM to the vendor’s business analysts, it is important to also indicate the possible future trading activities that may occur. This could impact how the system is configured. For instance, portfolio structure or reference data naming convention could change if a new business is acquired or started. Disclosing and considering how the business may evolve over a reasonable time frame helps everyone anticipate what changes and flexibility may be needed and ensures that this is configured into the system at the beginning where possible. This helps ensure that the CTRM is scalable at no extra cost or effort.
No Logic for reference data naming convention
When creating reference data, the user should initially take a step-back and view all the reference data required. This could dictate the naming convention for this data. Some fields will be capped at a certain number of characters, for instance calendar codes have a maximum of eight characters. If the client trades oil on ICE, they may want to set-up a calendar called ICE. However, ICE has different calendars for oil and coal, so a new calendar for coal will need to be configured. Knowing this initially would have had an impact on the naming of the first calendar to ICEOIL, with ICECOAL then created for the coal trades. Another example would be commodity code. How do you capture Gasoil 0.1, Gasoil 50 ppm and Gasoil 0.05 in 8 characters?
Not asking for certified training
Most CTRM vendors have structured certified training courses. The business analyst will recommend what course each user should take; however, this commonly only occurs during the implementation, but what happens if a user joins afterwards? If the user does not have adequate training, they will often go down the wrong path, which at best can be a slow process to achieve a certain task or at worse, could impact business critical data. New users to any CTRM should request to attend a formal training course from the vendor.
Not telling the vendor about other applications
Although the prime focus for the CTRM vendor is to implement their software, it is important that the user makes them aware of other applications that they use. The vendor may have previously integrated with that application for other clients and can offer an automation. Alternatively, the vendor may choose to start an integration with a new application if multiple clients would benefit.
Thinking a CTRM will free up your time
Although a CTRM will ensure that some parts of a trade life cycle are automated, and will free up time in certain departments, it is not always the case that there is an overall net gain to a company in terms of man hours. A CTRM needs to be maintained, and daily processes followed. “Garbage in garbage out”. What a CTRM will certainly bring though is standardisation, one version of the truth across all your departments, getting rid of infamous large Excel sheet as well as stronger and better control of your business processes across the entire company.
Wanting perfection
Although, in an ideal world a CTRM would be perfect, with automation and templates for every scenario, often this may not be the case. Users need to be flexible and accept simple workarounds for non-critical issues that occur seldomly. Users who strive for the perfect solution will incur significant delays and additional costs as a result while increasing project risk.
Accepting multiple workarounds
Although short-term workarounds are often required when using a CTRM, the user should not accept them if they are too time consuming, prone to errors and no medium-term solution has been provided on the vendor’s roadmap. If the user has implemented multiple workarounds, it could mean they cannot upgrade to the current version as their workaround has not been adapted for the new functionality. Additionally, the user should not accept having these workarounds being placed in their “own branch” or version, as this will mean they will no longer benefit from upgrades which include new functionalities for other clients. It is therefore a must to be always on the vendor’s core branch or version.
Not testing new releases
Each user should have access to a development environment, where the user should test the new functionality in each new release. This forces the user to learn about the new release and it acts as a safety net to catch any issues that the upgrade could impact them with if placed into production. The user should also use this development environment for training purposes and for testing out new scenarios.
Report in spreadsheets
Although a CTRM is often brought into a company to replace spreadsheets, often users want to extract into excel from the CTRM to perform their own analysis in the friendly format that Excel provides. This is acceptable for ad hoc cases, but it should not be the default for a daily activity, such as reporting. Instead, the user should inform the vendor’s business analyst about the reporting need who will provide a solution within the CTRM.
Only display required fields
Modules within a CTRM will allow users to select what fields to display in the UI. A clean display, showing only fields that the user requires (and understands), improves the user experience. The screens can often get messy if a user continually adds fields, which can also be confusing to other users if screenshots are emailed. It is best to create and save multiple layout views – for specific purposes that show only the relevant and required fields - and to switch between them according to the task than to have a single view/screen for everything.
Not following correct procedure to raise issues
A CTRM vender will have a set path to follow for a user when raising issues, such as to raise a JIRA ticket, and then the support team will investigate immediately. Delays to respond to issues can occur if the agreed procedure is not followed, such as sending an email is to a specific person (who may not be available) or to an incorrect group email address, e.g. info@amphora.net
Not embracing account management
The user should embrace the account management from the CTRM provider post-go-live to ensure that they benefit the most from the software. The assigned business analyst can help identify new requirements, training needs and assist in resolving issues. They will also keep the client up to date with new releases and arrange demos for new features.
Change management
Often, a new client wants the CTRM to exactly reproduce their Excel based process and reports. It is important the client realises that implementing a CTRM will mean that changes on their side will also be required. For example, some Excel sheet deems critical will stop being used, automation in some area will mean that some function will not be required while more data entry in another area will mean one additional staff is needed, etc. When a user changes CTRMs they may want to replicate the previous CTRM functionality/reports without realising the additional strengths of the new platform.
Not being involved in the roadmap
A vender will be juggling various balls when managing their releases. The current release will be maintained by the support team and the business analyst assigned to the client. The next release will be in development and QA. The client will be informed of the new functionality in the next release often with release notes and a walk through by a business analyst. The release yet to start development is where clients can have an impact in what should be included, and can, in some cases, dictate the theme of a release. The vender will have their own thoughts on their upcoming releases but will adapt by moving an item into an upcoming release if multiple clients are requesting the same enhancement.
Real time commodity trading and risk management software