Guerilla Treasurer

I recently participated in a Treasury seminar where the CIO of a bank urged the audience not to believe what software vendors tell them. This CIO really knew what she was talking about as she had previously worked in software sales.

Even though I sell software myself, I agree with her whole-heartedly. The only objective of many sales person is to break down your resistance and get you to buy his solution whether it actually meets your needs or not. If you are not paying close attention, a good sales person can talk you into buying something you should actually avoid like the plague.

A common example of this is the required “minor customisation” of a software package to exactly meet your needs. These customisations are often sold as small addenda to the solution, but they can end up transferring a great deal of currency from your account to the vendor’s account in the following ways:

1. Deployment is delayed by several months – keep in mind that every lost day also decreases your project ROI
2. You WILL get a hefty bill for the customisation – the software vendor is not doing you a favour; they are doing very good business (in fact, they sometimes offer an artificially low license price because they know they get guaranteed extra revenue from the customisation)
3. You need to constantly call the vendor’s help desk about the customisations; and, lo and behold, the support comes with a hefty fee
4. With the first version upgrade (or the next one, at the very least), you are informed that some more customisation is needed to ensure compatibility (now go back to point #2)
5. Finally you realise you have sunk so much money into the project that it is impossible to back out of it gracefully.

This is why you need to make a few things crystal clear before you let any sales person dazzle you with their verbal acrobatics.

First of all, carefully consider how large a project you are willing to commit to. Calculate your exact ROI target (and remember that time is money; you need to consider the savings you lose while the project drags on). Analyse your needs and consider your processes: in my experience it is almost always more efficient to make small changes to your internal processes than to try to change a third-party system to exactly match your existing processes.

And if you have a feeling that the sales person is not telling you the whole truth, you can check for some common warning signs.

The warning lights should turn on if the vendor cannot give you a fixed price for the deployment project but keeps mumbling about how difficult it is to give a precise figure because of customisations or some such other circumstance.

Another clear warning sign is a help desk service that is not free of charge. Quite often this means the help desk is jammed – and if the application works well, the help desk should not be jammed.

I have previously written about the importance of references when acquiring a solution from a new vendor. Just don’t let the vendor get off the hook too easily; instead use the procedure I have described in my previous blog entry.

We recently learned another good reference strategy from a Norwegian buyer: they asked for the name of a customer that had stopped using our product. This was, in my opinion, an excellent question. A former customer is not likely to give a sanitized version of their experiences, especially if they have gone through anything like the merry-go-round I described earlier.

In the same seminar, a representative of a different bank described how they had acquired a business critical solution under a very tight deadline. Because of a corporate acquisition the bank had to find and implement a new system for managing their loans portfolio in under a year (which is usually a mere blink of an eye for a bank). Because of the tight deadline, the bank had taken a Guerilla Treasurer approach and selected a SaaS (Software as a Service) based solution. I was happy – but not surprised – to hear they were very satisfied with the choice they had made.

I am pretty sure you know what I am talking about: knowingly or unknowingly inventing reasons why undertaking an unpleasant or difficult task should be postponed. Instead of writing a monthly report, one fetches a cup of coffee, pops into the loo (just in case), reads the emails, reads the papers, checks friends’ Facebook updates, and once more arranges some papers on the desk. And by then, it is so late that there is little point in starting to work on the report that day.

From the Secret Guerilla Treasurer Academy

The boffins call this phenomenon procrastination. In plain English, it is avoidance. Studies show that about 20% of us suffer from this; however the proportion grows significantly if we move from routine tasks to tasks requiring more creativity. The same studies actually show that up to 95% of university students occasionally procrastinate. I am quite familiar with procrastination myself; it is one of the reasons why this blog is sometimes updated very infrequently.

Procrastination is also one reason for corporate treasuries wasting inordinate amounts of time to undertake even simple development projects. Development always requires creativity and if we believe the studies, up to 95% of us tend to avoid creative work.

Here’s a selection of explanations in treasury development projects that I suspect are procrastination-related:

• There is a more important project that needs to be undertaken first
• End-of-year work or quarterly releases occupy us for at least a month
• Summer holidays block at least three months of the year
• It is soon Christmas time: starting from November no project is worth starting

The study that I so fondly quote, concludes that the major reasons for avoiding creative work are related to problems with perceiving the big picture and perfectionism. This is why tasks related to projects like this should be broken down to small and quick sub-tasks (taking as little as one hour to complete). Instead of writing working instructions for subsidiaries in one go, write just one chapter at a time. Taking continuous steps, even very small ones, is the best way to avoid procrastination.

Another issue that I find hard to tackle is perfectionism (then again, readers of this blog can clearly conclude I have managed to overcome it). Perfectionism is often a typical trait for treasury professionals. When dealing with large sums of money, perfectionism is to be commended, but in development projects one must learn to relax the standards in order to keep things progressing.  Accordingly, one key task of a Guerilla Treasurer in development projects is to help other team members lower their quality criteria just a little bit.

The treasury is often run with a small staff and each member of the crew has fairly independent areas of responsibility. Job descriptions and processes may have developed over time, but in most companies detailed process descriptions have not been created at all or they are hopelessly outdated.

Personnel changes are tough for treasuries, because one needs to find the time for recruiting a new specialist and the new hire must also be given adequate training for the job — these tasks tax the already thin resources of the treasury and all this time is away from taking care of the actual treasury responsibilities.

On the other hand, personnel changes are a prime opportunity to better document processes. But, because of lack of time, this does not get done. And then we are facing the same dilemma the next time we have a personnel change.

So what would a Guerilla Treasurer do? First of all she makes sure good employees feel appreciated and are not keen on switching jobs. The second part is making sure the hiring of new person, should it be necessary, goes smoothly and cost-effectively.

From the Secret Guerilla Treasurer Academy

One basic mistake is being too stingy with the salary. It is plain foolishness to let a competitor lure away a competent person you have spent several years training to be a seasoned pro by paying just a little bit more higher salary than you are paying.

A good employee should not have to beg for a raise. Offering a raise (even a relatively small one) proactively, spiced with appreciative words for a job well done, is certain to increase loyalty to the company and you.

In addition to a reasonable basic salary (commensurate with skills and responsibilities), it is a good idea to consider other incentives, as well. They do not have to be very expensive, the main thing is making obvious that you value the employee and that you are also willing to go the extra mile. For instance, personally delivering a fluffy Christmas tree to an employee’s house is guaranteed to be a more memorable performance than just giving out the perfunctory box of choclates or bottle of wine.

If you have a good and ambitious employee and you are not planning to vacate your own position any time soon, it is still likely you have to give up that employee. If (and when) this happens, it is crucial that you have documented the job description and tasks well and the training of the new staffer can be done effectively. And recruitment can be easily handled by inviting key people at the treasury of a neighbouring company that has a stingy treasurer.

Have you ever calculated how much money your company loses when you push back a development project?

Let me guess: the standard answer is something along the lines of having so many important development projects and only enough resources to undertake some of the projects. Does this sound familiar?

I actually use the exact same line when I cannot come up with any reasonable counter-argument to a salesperson who tries to sell some perfectly reasonable thing to me. But let me repeat the actual question:

From the Secret Guerilla Treasurer Academy

Do you know how much money the postponement of a project costs your company? If you haven’t calculated that, how do you actually prioritize your projects?

Even though treasury is a support function, it is still definitely part of the business. And in a business, all initiatives should be guided by their bottom line impact — no matter what the so-called company values statement says. Consequently, the treasury needs to calculate the value of every initiative and prioritize them on that basis.

During the past several years, I have come across many a company where cash forecasting is one of the most important development projects. Nevertheless, the project is postponed year after year, as some “more important” project demands the full attention of the treasury. Typically these “more important” projects are wide-ranging cash management overhauls, that are used as a pretext to RFP/I/Q indistinguishable cash pools or something similar. A usual trait for these projects is that the effort spent vs. the monetary benefit is not even in the same league as in a cash  forecasting development project.

From the Secret Guerilla Treasurer Academy

I started karate training with my daughter two years ago, while already sturdily middle-aged. Despite my misgivings, karate turned out to be a fantastic counter balance to my work. Doing the karate moves works the brain like doing sudokus and I keep getting into better shape.

Even though I am a rank beginner in the sport, I have already learned that there are no shortcuts to a perfect (or even good) performance. Improvement requires constant practise and development by almost imperceptible baby steps. Every new belt requires a lot of training and all the previous training builds the foundation for future belts.

So what does this have to do with the treasury world, you might ask? I have witnessed numerous development projects that aim straight away for the so-called perfect solution. I have encountered companies that start with cash forecasting and immediately reach for a fully intergrated product that automates everything and eliminates all manual work at once. This is very similar to a lowly yellow belt trying out for a black belt — an endeavour doomed to fail miserably.

A guerilla treasurer understands that development projects are about constant learning; instead of shooting for the complete vision immediately he gradually improves the processes. Even this way, mistakes are likely to happen, but when approaching projects with baby steps, these mistakes are easy to correct and one can learn from the mistakes without them being overly costly.