Here is a quick revenue assurance quiz for you all. Answers (at least, what I think the answers should be) are given at the end (no scrolling down to read them first!)
A. What is the typical Return On Investment in purchasing new software to detect revenue leakages?
B. What is the likely payback period when using new software to detect revenue leakages?
- 1 year
- 1-2 years
- 3-6 months
- 1 month or never
- 4 years
C. Which of these is not a quote from W. Edwards Deming?
- “You can’t control what you can’t measure”
- “If you can’t describe what you are doing as a process, you don’t know what you’re doing.”
- “If you do not know how to ask the right question, you discover nothing.”
- “Whenever there is fear, you will get wrong figures.”
- “Does experience help? NO! Not if we are doing the wrong things.”
- “Management by results is confusing special causes with common causes.”
Here are the answers (as far as I know):
A. (6) Zero. Purchasing software to detect leakage generates no return. Fixing leaks that were found using the software might generate returns. That depends on whether there are some leaks to find and whether somebody has the time, incentive, pride, professionalism, ability and authority to do something about them.
B. (4) 1 month or never. You either find a lot of things going wrong straight away, or you never find that many things going wrong. So either the project pays off immediately or not at all.
C. (1) “You can’t control what you can’t measure” was by Tom DeMarco.
So what is my point? Well, most sales pitches for revenue assurance tools, software, equipment, whatever, are nonsense. They pretend that revenue assurance is like a new source of ongoing revenues. Every part of that sales pitch is wrong. Here is why.
For a start, revenue assurance is not a new source of revenues. It is only a way to get full value from the old sources of revenues that the business already had. If somebody did not sell the product, build the network etc then there would be no revenues to leak, but these costs get conveniently ignored from the Return On Investment equation for revenue assurance, because they are treated as sunk. Well any investment can be made to look good if you ignore lots of costs on the basis that they were sunk costs. You might as well argue that the only function in telcos that generates a Return On Investment is billing and cash collection, because building a network is a sunk cost, sales is a sunk cost, marketing is a sunk cost… you get the idea.
Then comes the idea that revenue assurance is an ongoing and regular source of additional revenue. Well, it could only be an ongoing source of additional revenue if you think the business is always destined to be wasteful without the constant intervention of an assurance team. That is a bit like saying you need a team to constantly spy on other workers because you cannot trust them to do their jobs properly. Of course people make mistakes, and will go on making mistakes, but if they make lots of mistakes over and over you need to educate them or replace them, not pay someone else to point out their mistakes. People have been known to sometimes get things right even without the help of revenue assurance ;) Which is lucky, because most things in most telcos happen without the help of revenue assurance. When a revenue assurance team generates money for telcos, it happens in one of two ways. The first way is that the revenue assurance people find a big problem that needs to be cleared up. The second way is that the revenue assurance team is responsible for managing a regular recurring problem.
Big problems that need clearing up should get cleared up, generating a lot of value in a short amount of time. These are the big wins they are most likely to be reported by vendors when they boast of the returns generated by using their tools. There is no dispute that these one-off big wins can unlock a lot of value for the business. However, they are not an ongoing source of revenue. It is misleading to present them like that. The problems are individual and specific. Once solved, they can stay solved. And the similarities between one problem and the next may be relatively abstract. So it is very hard to productionize money-generating revenue assurance in the way that vendors would like to pretend. Sure, you can do the same detection checks over and over, but you should not be finding money over and over, unless you are failing to learn lessons and resolve the root causes of why errors occur. Revenue assurance is a subset of operational risk management. Risk implies probability, not certainty. So presenting leakage as a certainty is a nonsense. The best that can be said is that it is probably occurring somewhere, but you cannot be certain if it is occurring, and where it is occurring, until you start looking for it. There is always the likelihood that you will sometimes look for leakage in places where none occurs.
Regular recurring problems that need regular management should not require recurring intervention by the revenue assurance team. You may ask why I think that. First, there is no point viewing something as a problem unless you intend to fix the problem. For example, the problem of recycling suspense is only a problem if you cannot cope with the volumes of suspense and lose money as a result. If you actually expect a certain amount of traffic to regularly fall into suspense, and you employ a team to manage the recycling of this suspense in a systematic way, then this is not a problem for the telco – it is just part of the normal process for that telco. It may not be the most efficient or cost-effective way to arrange processes, but that does not mean it does not get the job done. Second, managing regular operational processes is not the job of a team that is supposed to be doing assurance. Things like recycling suspense, for example, may be a regular operational burden. If so, someone who does a regular operational job should handle it. Assurance must have something to assure; if an “assurance” teams ends up doing an operational job, they are not assuring the job being done, they are doing it. It does not matter what the team is called, it matters what they do. You can give a team called “revenue assurance” the job of regularly managing suspense, but if the same kinds of traffic regularly fall into suspense, and the team regularly performs the same activities to manage and recycle suspense, then are not providing the business with assurance, they are just part of normal business operations. These kind of tasks may be falsely attractive to a revenue assurance team worried about keeping their jobs and the support of executives. The attraction is that the tasks are specific, regular, easy to describe, and the benefits are easy to explain and predict. A reliable source of revenue benefits can be very attractive to a revenue assurance team. But this predictability is the very reason why these tasks are not part of revenue assurance proper. Assurance is about reducing and managing risk, not about fixing known recurring errors. That kind of work is not a source of assurance and is not a source of new value for the business. It is just a part of the normal processes, no different to any other of the million activities performed in telcos on a regular basis. Focusing nominal revenue assurance efforts on predictable low-level error management takes resources away from proper risk management. It also begs the question of who is meant to be assuring the people in revenue assurance performing the routine operational tasks, and hence making sure they do not make mistakes.
Although it is called revenue assurance, it has more in common with cutting costs than generating revenues. The only limit to generating revenues is how much customers want to buy. If you can persuade customers to buy more, then you can sell them more. On the other hand, you can cut and cut and cut, but eventually you will run out of things to cut. If you cut too far, it reduces profits instead of increasing them. The same is true of revenue assurance, in that you can plug leak after leak, but eventually you will run out of leaks to plug. Yes, I know that next year there will be new products, and people will make new mistakes… but it does not follow that new leaks will occur rapidly enough, and in large enough volumes, to sustain the demand for revenue assurance in pure financial terms. Either revenue assurance is driving down leakage or it is not. If it is, then there will be fewer leaks in future to fix. If it is not, then either do more assurance to make more money, or do no more assurance because the additional profit that would be made is less than the additional cost of the extra assurance.
In the real world, if a manager cuts a cost, they do not get a bonus each year for the rest of their lives. They get a pat on the back in the year when the cost was cut, and next year’s budget will assume a lower cost base. This means the manager has to find new ways to cut costs if he wants to impress people. Which is why it gets harder and harder. The same is true of revenue assurance. If revenue assurance generates a few million for the company one year, it should be harder to do it next year. If the problems were fixed, then next year revenue assurance needs to find new kind of leakages to fix, and not just congratulate itself for what it did last year. On the other hand, if the problems were not fixed, and the revenue assurance teams needs to expend regular and predictable effort on managing the problems, then they are not problems at all – just a part of the normal business process. In this case, the “revenue assurance” team is just milking a specific kind of operational responsibility and saying it adds value when in reality it is no different to any other operational responsibility. Saying that the money would “leak” if they did meet the operational responsibility is no kind of response. You could describe any activity as plugging a “leak” if you rationalise that the business would be financially worse off if nobody did it… and that would mean sales, marketing, network operations, Old Uncle Tom Cobley and all would end up working for the revenue assurance department!
The challenge for any revenue assurance team is to have a process, without becoming part of the routine day-to-day processes it is there to assure. That means knowing how to ask a good question, without knowing what the answer will be. It does not mean asking the same question over and over because the answer is a good one for revenue assurance, in that the sense that the same check will regularly discover the same kind of leakage. When revenue assurance asks questions it knows the answer to, it means it is not asking more fundamental questions on the root causes of problems. Part of the reason for all the nonsense spouted about the value of revenue assurance is fear. People fear that they will lose their job, will not get exec backing, will not get sufficient budget etc unless they can show the value they add. The downside is that they often manipulate the data to suit an inappropriate model for revenue assurance. For example, a simplistic but false assumption is that revenue assurance generates revenues, so should be subject to the same kinds of revenue targets as applied to other revenue-generating departments in the business. It is often easier to distort revenue assurance results in order to satisfy this inappropriate model, than it is to explain why the model is wrong in the first place. Following the logic to its natural conclusion, that means the revenue assurance team is doing its job if it generates predictable returns by doing recurring operational tasks, and is not doing its job if it drives resolution of root causes or moves on to look, with unpredictable results, for faults elsewhere. The worst thing that can happen is that a business becomes “experienced” with the wrong model of revenue assurance. If somebody wants to change the remit, to cover new things, unlock new value, address risks that have yet to be addressed… then they run into the obstacle of experience. Experience shows there is great value in resolving the errors in places that revenue assurance already looks, so why divert resources to look elsewhere? Experience shows that the business cannot be trusted to undertake certain kinds of operational responsibility without making mistakes, so the revenue assurance department had better hold on to responsibility for those tasks. Experience shows that the challenging targets set by management are always met by revenue assurance, so why argue for a reduction in targets as a way to get the revenue assurance team to address the root causes once and for all, instead of routinely managing the symptoms of broken processes? So managing by results is a flawed way of looking at revenue assurance. The businesses that peddle their wares by promising these results are allowing themselves to become part of the problem, not the solution. The irony here is that revenue assurance is all about gathering data, but you manage it by managing the immeasurable – what you do not know. Controlling risk is recognizing that there are some things you do not know but would like to know. You cannot manage or control risk by pretending you know everything to begin with.
Many objectives can be attained even though management of progress cannot be measured. If a group of scientists work on a cure for cancer, I do not expect them to measure their percentage progress towards the cure on a project plan. That does not mean they are not making sensible and informed decisions about where best to spend their efforts and what lines of research might generate the most useful results. It just means they do not do so with the benefit of certainty. The same is true of any discipline that deals with an absence of knowledge. Reframing the problem in terms of certain knowledge – think of the vendors that promise if you buy their tools then you will know everything – is misguided. Sometimes the cost of getting knowledge can be higher than the benefits that result from it. And focusing on getting certain and deep knowledge of some things may distract attention from the pressing need to gain knowledge elsewhere. The trick for revenue assurance is to guide the business not towards the elimination of risk, but to the right level of risk. That means spreading the assurance net wide to cover all risk, but not necessarily delving deep into the specific operational details. Investments like that are impossible to justify in terms of simple and measurable ROI and payback period. Let us just hope there is some room for sensible decisions not based on ROI and payback, even if it makes us feel out of control. The truth is that when it comes to managing ignorance, appearing to be in control is more harmful than admitting its limits.