Why do so many treasury system launches go wrong? And why do those that don’t often not go well? There are many reasons, most of which are linked to skills that treasurers don’t automatically have and to the fact that treasurers don’t regularly implement treasury management systems, in fact many of them only ever do it once.
This series of articles looks back on more than 20 years of experience with such issues. Experience with the selection and implementation of systems, as well as in the in-house development of software products. Let me start by stating the following: We have also made just about every mistake in the book ourselves that we possibly could have made (hopefully only once), and many of these experiences were extremely painful. But, no pain, no gain, and it is usually exactly these mistakes that you learn most from.
In contrast to many treasurers, however, we have had the chance to do it better the next time, and the next, and the next. They normally only have one shot at hitting the bull’s eye. If you ever find yourself in this situation, our remarks and tips below might help you. You may think that one or two of the issues raised are nothing new, and you’d be right. There is nothing new, but you do actually have to do it in practice and exercise the necessary degree of discipline.
In the first part of my series, I’ll be dealing with an issue which may well be the most difficult: The formulation of your questions and requirements vis-a-vis system providers and their products.
Requirements specification = rocket science?
Before we start: Anyone who can’t understandably and completely formulate their requirements has lost the game before it even starts. But what exactly do “understandably” and “completely” mean in this context?
The language – form follows function
From everyday life, we all know that there are communication problems even between people who (believe they) speak the same language. While this might be entertaining in particular situations, it is certainly less fun when it’s time to commit to paper the requirements or wishes (and this is where the fun starts, differentiating between the two) relating to the scope of performance of a TMS.
A favorite and, unfortunately, common error also occurring in everyday communication, is the manner in which questions are formulated. Every day, hundreds of thousands of unnecessary emails are sent because people don’t formulate their questions clearly, digress, and often “miss the point”. Although this should be easy, many people, particularly consultants, seem to think that unclear formulations may be an indication of a high IQ. They aren’t, of course. Therefore, during this phase of a selection process and whenever possible, avoid questions which permit various interpretations rather than being answerable with a simple “Yes” or “No” or a definitive number. And remember that your opposite number is probably going to be better than you at the “Interpretation Game” on the grounds of their past experience. KISS, keep it short and simple, and add a period where you would otherwise use a comma if you want to be understood. This is somehow related to “reader resistance”. We are simply not conditioned to enjoy reading epic sentences. We don’t have the time and sometimes also not the concentration skills necessary.
You would be surprised how often conditionals, the nemesis of linguistic precision, crop up in specifications or requirements. “Should”, “could” and “ought to” – if that’s what you really mean, no problem. But if you really mean “shall”, “can” or “must”, then this is going to be a big problem. Every use of a conditional is an invitation for your opposite number to question or interpret the binding nature of the requirement, and justifiably so.
Listen and watch out for this in day-to-day communication and you will notice that this can be fun, even if you are occasionally the one guilty of muddying the waters.
Don’t get lost in translation
The issue is complex enough even when you speak the same language as your opposite number. When you add a foreign language to the recipe, however, particularly on both sides, even if deciding on English as the “common language” might in effect shuffle the pack a little more fairly, the potential for misunderstandings increases exponentially. There are two areas where people tend to chronically overestimate their own abilities: Excel and language skills. If you have decided to implement the system of a provider where the project language is not the native language of your project team, it is vital that the relevant employees, and certainly the project lead, can communicate with the provider without ifs and buts in order to eliminate, as far as possible, the potential for misunderstandings due to different interpretations rooted in a lack of language skills.
For example, it still scares the hell out of me when I think back to a situation during a system implementation when a German employee of the customer and an English guy working for the system provider wanted to discuss a list of detailed requirements. The German employee was just as convinced as he was wrong about his speaking excellent English, despite suffering from foot-in-mouth disease even in his own language. His English came across as even less sophisticated, which did little to create a comfortable atmosphere and ensured that the employee of the provider was already mentally “offline”. The worst thing, however, was that the German formulated his requirements completely incomprehensibly in his breath-taking English, and the guy from the provider understood something totally different, something which neither of them would ever have found out if I hadn’t helped clarify the situation.
Speaking of asking questions: My experience has been that the majority of people are not inclined to ask questions when they should. Either because they think that they already know everything or because they are afraid of asking a “stupid” question. Both approaches are wrong, and both can be very expensive. If you apply the golden rule of good journalism: “Check, Re-Check,Double-Check”, then you are sure to be on the safe side.
Whatever the case, there is definitely no disgrace in asking questions, even if they appear to be so simple. At the end of the day, you will see the benefits, not only in terms of time and budget, but, most of all, in terms of your nerves.
Requirements specification – test scenarios and preparation for acceptance tests
Specifying your requirements precisely and understandably is quite a challenge even for someone experienced in this discipline. There is another “golden rule” you should bear in mind for more complex requirements: When you are specifying the requirements, also define the test scenario that you want to use to check their implementation. Although this might mean lots of additional work, it can be extremely helpful if you ever need to redefine these requirements yourself. Besides this, a test scenario, which you of course also could and should be made available to the provider, forms the basis for the acceptance of a feature and a fair basis for assessing the extent to which this has been implemented in the solution. Don’t evaluate either your own team or that of the provider retrospectively on the basis of requirements which they didn’t know about beforehand. And don’t expect the team from the provider to discover every possible inconsistency in your requirements themselves.
Requirements specification – and the reports?
Reports are often a reason for customers being dissatisfied with their new systems. Imagine you have just implemented the system offered by one of the market leaders and then find out that you are not getting the reports that you have been dreaming about for years. Or at least not in the way that you imagined them. And now your CFO is on your back because they can’t understand how you could spend a six-digit amount without them regularly receiving “their” reports as a result.
But: did you even specify the reporting requirements? And do so during the selection process? And do this clearly enough? Or did you just ask whether the system delivers a financial status report? What I can tell you based on experience is the following: Whatever you haven’t specified in detail prior to signing the contract, you very likely won’t get at the end of the day, or not in the way you wanted it. But what exactly does “in detail” means when we are talking about reports?
Essentially, a form of functional specification needs to be written for every report, along with a relevant example in Excel in which the contents of every single column should be described in detail. Name the column headers, describe the contents and the formats (number, date, value in ‘000 or not), whatever you think of. Then there are the filter options (group, business unit, single subsidiary), currencies which inputs should be converted into, exchange rates used for translation purposes, and, and, and.
Carefully and clearly document these requirements and then go through them field by field with the employee from the provider. And not with the pre-sales employee, but with those employees who can and actually will implement these requirements. As long as you don’t have a firm commitment from the provider that they can implement this, and as long as you don’t have a clear idea of the costs related to preparing the reports, you should hold off from signing any contract. The alternative is a nasty and, most of all expensive, surprise. I completely fail to understand why people regularly don’t do this.
Don’t be blinded by extensive sample folders of reports, like a menu in a restaurant, which have been implemented for the provider’s other customers over the last 20 years. And don’t be fooled into thinking that what might have been suitable for other clients is also going to be right for you as well. There is an extremely high degree of probability that that won’t be the case.
The following applies: quality rather than quantity. Professional, well designed reports can cost a small fortune and there are good reasons for this. Therefore, query every requirement as to whether it is really warranted or whether the required data could actually be tapped from another source.
Conclusion: One final comment at the end of this section: Discuss your reporting requirements in detail with the recipients of these reports, i.e. also with your CFO, and make sure that these requirements reflect their expectations. There’s nearly nothing worse when you have wrapped up a project and go to your CFO with the first set of reports only for them to scribble additional “wants” all over them. Then you have three new problems: A CFO who is possibly not satisfied, a team that is already working on the next project and no longer available, and no budget available. In other words, the exact opposite of the jackpot you were hoping for. And yes, you can and should get your CFO to sign off on reporting requirements in advance. A good CFO will understand that.
Treamo Finance Monitor - An Interview with a satisfied user
TFM was implemented in the KDK group in only two months in 2012. Since then it has been an indispensable management tool
Treamo improve TFM cash flow forecasting platform with new tools
Cash flow generator, FX hedger and cash flow scenario generator add functionality and effectiveness
TMS: times are a changing - installation in weeks now achievable
TreasuryXpress show that long implementations are no longer viable or necessary as International investment conglomerate achieves cash visibility with C2Treasury™ in under TWO WEEKS