Business realities

The hours in consulting are pretty long. 65 hours a week used to be my norm, and that's ignoring the travel time to and from work. So there wasn't too much life outside of work. (I've come to realise, though, that what you do outside of work doesn't change that much with more free time. What does change is that you just enjoy it more -- both in and out of work.)

We have a day, once every month or two, where you take time off from whatever project and head back to the office. One such featured a session with the managers telling the consultants how to succeed. Pretty good advice, actually... but that's not what I'm going to talk about. It's something about the nature of that advice.

The advice had a lot of TO-DOs and suggestions. Do this. Do that. Focus more on this. Focus a lot on that. Great. Now we know what to do more of.

My question, towards the middle of the session, was: OK, so what do we do less of, then?

You can't do more of something unless you do less of something else. In most places, it's easy to answer this with: "Oh, you need to be more efficient." or "Cut the idle gossip". For us, none of these were applicable.

The question pretty much remained unanswered. And with good reason. It's a tough question.

Later, I got involved with a proposal. I wrote a few bits of it. (One page, actually.) Others wrote a few bits of it. And then some standard appendices were added to it. Finally, it ended up as a 180-page document.

The interesting thing is, I can bet no human ever read those 180 pages end-to-end.

I know no one at our end did, because we turned it around in 1 week, and I was the last to assemble the document before sending it out.

I'm guessing no one at the client end did, because they'd have gotten 5 such documents, and had a week to shortlist down to 3.

So if we didn't read it and they didn't read it, why did we put it in?

I think I know why. In my IBM days, I had to make a presentation to the management on productivity. I knew nothing of management or productivity. So I put in a report that had a lot of high-sounding words (you know... value-add, leverage, etc.) that looked reasonably impressive and had no basis in fact.

I did that mostly because I was scared. Of seeming to know less. Of being wrong. You know.

(Funnily enough, the presentation was pretty well received. I don't know if it was because they were polite or had become numb to bullshit.)

This fear is pretty common. I know how that 180-page document ended up as a 180-page document, and I'm sure you've seen this happening before. First, here's a sample conversation at the client end, when they're writing up a request for information.

Martin: So, what do I put in the RFI?
Clive: Here's a template we used. You can use some of that. Ask Nick for the one he used last month, and Natalie for hers. Maybe you should get something from our procurement team and information security group to be on the safe side.
Martin: And how do I make the RFI out of this? (BTW, this is a "bold" question that's rarely asked.)
Clive: Well, make sure you cover everything from all of these documents.

So the RFI asks asks:

• if any of your 80,000 employees are a member of any one of the following 340 organisations that are considered disruptive,
• how many employees you have in each geography, function and vertical -- where the break-down provided is as per their definitions (we cook up numbers which, if you add up, totals to over 200,000)
• how much you spent on paper-clips last fortnight, and other such intimate corporate P&L secrets

And we answer these. The answers to the above 3 questions were "No", a table of numbers, and "We are not at liberty to divulge this information..."

Now, looking at the answers above, it still doesn't add up to 180 pages. It's hardly half a page. But you've got to take the following conversation at our end into account.

Steve: You know, we've got to put in some details about our methodologies in this section.
Me: I have.
Steve: Yeah, but maybe we should add more, you know, like supply chain methodologies and change management.
Me: But they're irrelevant!
Steve: Well, can't say that. Change management is always relevant. SCM... well, no harm putting it in. They can skip it if they don't want to read about it.

That's it, isn't it? There's no harm in doing more. I'll just toss it in. If you don't want to read it, skip it. I'll just ask you to do more of these. If you can't, skip the useless stuff.

An innocuous sounding statement: do more. I tremble whenever anyone suggests it. There's no defence.

There's a fundamental belief at work here. That more is better.

This is fueled by a lack of confidence. Put in high-sounding words. They look impressive. What's missed is that experts use jargon because they understand what it means, and it conveys a lot in few words. Others follow a cargo cult science.

What we lose, though, is subtle.

Firstly, it wastes time. It wastes my time. It wastes your time. But hey, time is not all that important. (I'm not saying this sarcastically. I believe that wasting time is quite OK, really, and it's not such a big deal.)

What's more important is that it destroys focus. Some things in the document are important. Most others are not. In a 180-page document, I can't find the important stuff! It actually does harm to put it in if it's irrelevant.

That's the tough tradeoff, really. A tangible incremental value against an intangible loss of focus. The value looks attractive when you're less confident. The document seems completely unfocused anyway.

So what the heck, put it in.

Do more of this. And that too.

---

So what can you do? Quite a bit, surprisingly.

Firstly, you've got to believe that less is more. The response to "What's the harm in adding...?" is "It dilutes the message". There's two things here. Believing it. And having the courage to say it. Trust me, you really believe it only when you say it.

Next, you've got to understand -- really understand -- before you write or speak. That requires not fooling yourself. And it requires a lot of practice. I've had nearly 20 years of training in fooling myself, so it's an uphill task. Many people are worse off, never having tasted true understanding.

Third, you've got to be brave enough to shut up, or say "I don't know". Initially, this was tough for me, but I learnt from a friend. I always thought him not-so-smart, but honest. He'd ask, "But why?" and when I'd explain, he'd say, "I don't understand it." After two hours of trying to get him to understand, I'd realise that I was the one who never got it in the first place. After a while, I got into the habit of being very prepared before I explained anything to him.

Saying "I don't know" doesn't make people think less of you, I've found. I know a lot of people disagree with me. One of the most consistent feedbacks I've received in the first half of any project or firm I've been in is, "He should speak up." Dammit, I don't have anything to say! If I know something, I'll say it. If not, I'll shut up. Now, despite this feedback, no one's quite objected to me. And in the second half, they're always amazed at how much I've improved based on the feedback.

The feedback had nothing to do with it, of course. I just happen to know more in the second half of a project.

There's a reason why your boss wants you to talk. It makes you appear knowledgable. In the short term, that's good. You talk about "value" and "leverage" and people nod wisely.

In the long term, it makes you less able to say "I don't know." (What? This brilliant chap who knew all about value and leverage doesn't understand our way of calculating ROI?)

It makes you less likely to ask questions.

It makes you learn less.

It makes you dumb.

On the other hand, I've learnt to plead ignorance up front. "Do you understand ROI?" "No." Not even an excuse for it. Frankly, it saves time.

Sometimes, a meeting's running late, I'm hungry, and I just nod at whatever's said, and you lose the window of opportunity to ask. Except, I've learnt, there's no such thing as a window of opportunity. If you don't get it, ask. If they've said it thrice, and you still don't get it, ask. More likely they're not clear about it.

---

Postscript: This morning, I had to convert a document into a standard template. My document was 3 pages long. The template (just the headings) was 14 pages long.

Why? Because someone wants all documents in that format. Does it help them? Maybe not. But it has to be done. Standards.

Sometimes, it's easier to give up. The smart thing is to minimise the effort on pointless work. I took 15 minutes. Beyond a point, I protect myself rather than the poor reader.

If you have a bunch of projects you could do, and want to decide which ones to take up, I was taught a rule: if a project has positive net present value, do it.

That is, find out how much money you have to put in (& when), and how much you'll get out (& when). Adjust for money today being worth more than money tomorrow. If it makes a profit, just do it.

There are 3 aspects to this calculation, of which two are usually ignored.

1. Time value of money. Money today is worth more than money tomorrow. People usually don't adjust for this -- either because they don't know they should, or because they're not sure how much to adjust by. It's usually OK to ignore this. The difference is not often much. Your estimations of cash flow are likely to be off by more than this adjustment anyway.
2. Cash flow projection. This is tough too. People batch these together into two groups: what you put in and what you get out.
3. Investment and return. This is the often used part. You put in money (over time), and you get money out (over time). Do you get more than you put in? How much more?

In other words, I've seen Return on Investment (RoI) used far more than Net Present Value (NPV).

In my MBA classes, I was taught that this is wrong. That you need to worry about RoI only if you're budget-constrained. If you have enough money (and organisations can always borrow), you should do all profitable projects.

I can't tell for sure if organisations are budget constrained or not. Departments do have budgets. But whether they stick to it or not depends on the department head's risk aversion and political power. It often has nothing to do with projects.

But I've seen a bigger complaint cited more often: people don't have time. Time is a bigger constraint than money.

This works in two ways. You don't have staff to execute a more projects. Or you don't have management time to pay attention to new projects.

If you're constrained by money, it makes sense to maximise return on investment. But if you're constrained by time, maximise return on effort.

BTW, effort is not the same as time. Outsourcing, for example, increases return on effort, but probably not return on investment. Vendors take money without taking up staff time (except a bit of management time). If you're manpower constrained, and not money constrained, use them as much as possible. Similarly, investing in assets rather than in hiring improves return on effort.

When at BCG, there was a whole theme around this called Workonomics. Like Economics is about maximising return for money, Workonomics is about maximising return from your workforce. Powerful concept. It's a pity I've never seen it applied where it's really needed.

The most important thing is: at any point, you have only one constraint. Maximise return on that constraint. If it's money, maximise RoI. If it's staff, maximise productivity. If it's customers, maximise share of wallet. And so on.

| alternate titles: Project selection Project Return on Investment NPV capital budgeting

If you have a bunch of projects you could do, and want to decide which ones to take up, I was taught a rule: if a project has positive net present value, do it.

That is, find out how much money you have to put in (& when), and how much you'll get out (& when). Adjust for money today being worth more than money tomorrow. If it makes a profit, just do it.

There are 3 aspects to this calculation, of which two are usually ignored.

1. Time value of money. Money today is worth more than money tomorrow. People usually don't adjust for this -- either because they don't know they should, or because they're not sure how much to adjust by. It's usually OK to ignore this. The difference is not often much. Your estimations of cash flow are likely to be off by more than this adjustment anyway.
2. Cash flow projection. This is tough too. People batch these together into two groups: what you put in and what you get out.
3. Investment and return. This is the often used part. You put in money (over time), and you get money out (over time). Do you get more than you put in? How much more?

In other words, I've seen Return on Investment (RoI) used far more than Net Present Value (NPV).

In my MBA classes, I was taught that this is wrong. That you need to worry about RoI only if you're budget-constrained. If you have enough money (and organisations can always borrow), you should do all profitable projects.

I can't tell for sure if organisations are budget constrained or not. Departments do have budgets. But whether they stick to it or not depends on the department head's risk aversion and political power. It often has nothing to do with projects.

But I've seen a bigger complaint cited more often: people don't have time. Time is a bigger constraint than money.

This works in two ways. You don't have staff to execute a more projects. Or you don't have management time to pay attention to new projects.

If you're constrained by money, it makes sense to maximise return on investment. But if you're constrained by time, maximise return on effort.

BTW, effort is not the same as time. Outsourcing, for example, increases return on effort, but probably not return on investment. Vendors take money without taking up staff time (except a bit of management time). If you're manpower constrained, and not money constrained, use them as much as possible. Similarly, investing in assets rather than in hiring improves return on effort.

When at BCG, there was a whole theme around this called Workonomics. Like Economics is about maximising return for money, Workonomics is about maximising return from your workforce. Powerful concept. It's a pity I've never seen it applied where it's really needed.

The most important thing is: at any point, you have only one constraint. Maximise return on that constraint. If it's money, maximise RoI. If it's staff, maximise productivity. If it's customers, maximise share of wallet. And so on.

| alternate titles: Project selection Project Return on Investment NPV capital budgeting

I am selecting a CRM package for a bank. I asked my colleagues how they'd gone about it, and got 8 responses. Every single one of them had the same weighting approach: Take a huge list of criteria, assign weights, score each package, calculate a weighted-average score, pick the highest one.

As I mentioned earlier, I think weighting is a lousy method. (See Errors in multicriteria decision making.) You can't say "I picked this package because it has X, Y and Z features, which the others don't." You can only say, "Oh, overall, it has the highest score..."

The scores and the weights are subjective. You spend ages arguing between a 3 and a 4. You can manipulate them very easily. And you end up having to revise the scores many times to get to the answer you want.

Since I now had an opinion, I put my foot down, and said, "Here's what we'll do. Let's make a list of essential criteria. They will all be YES / NO questions. Any package that doesn't meet any criteria is knocked off. That's it."

This may appear simplistic, but it isn't. You see, at the end of the day, only a few criteria really matter. Ideally, you just pick these, and compare packages against these. Since you don't know which these are, you make a bigger list, evaluate them all, and then realise the truth.

Sometimes, you have too many criteria. Then none of the packages make it, and you have to sacrifice some of your criteria.

Sometimes, all of them make it. Then you can choose to enforce more criteria. Or maybe not. If all of them meet your criteria, just pick the cheapest one.

Internally, we were convinced of this approach, and took it to the client. Things were fine for a week. Then, complaints started trickling in.

1. Fear: "I've already used weighting in earlier package evaluations. Now, if you use filtering, it'll make my earlier evaluations look bad..."
2. Uncertainty: "I don't know... what if there's no YES / NO answer? What if we need shades of grey?"
3. Doubt: What if it lets everything through? What if it rejects everything?

Uncertainty is the most popular objection.

"What if we need shades of gray?"

I always ask: "Any example?"

"Well, you know... it can come up."

So I give them an example, and explain how it can be broken in to sub-questions.

"Well, yeah... but just to be on the safe side, could we have a score?"

The exercise is still going on. I haven't seen a valid concern yet. What's interesting is, everyone is hesitant about filtering, but no one can defend their objection.

| alternate titles: Selection criteria ERP selection criteria Software criteria

I talked about my approach for multicriteria decision-making, and mentioned that it was fundamentally flawed. Here's why.

The charts above compared two industries. The bigger the area, the more favourable the industry. The underlying assumptions being:

• The criteria are comparable. (Points at the same level are of comparable importance. Twice as large is twice as important.)
• All (and only) relevant criteria have been included.

In this particular example, I know for a fact that both these assumptions are invalid. And in every case I used this methodology, the assumptions fail.

You won't draw the criteria to scale. We used revenues and growth as two parameters, and marked each industry as high, medium or low. The scale for revenue was Rs 100 cr, Rs 500 cr and over Rs 500 cr. The scale for growth was <5%, 5-10%, >10%. We picked this scale in order to fit the range well on these graphs. Not because Rs 100 cr of revenue was worth about the same as 5% of growth. And yet, that's the implicit trade-off this graph is asking us to make.

We also had very qualitative criteria, like "Capability" (KSF), and they were compared head-on with growth and revenue. Using qualitiative criteria is not a bad thing. But when the visual makes you trade-off capability against Rs 500 cr of revenue, I feel queasy.

You will miss important criteria. Usually, the process for identifying criteria is bad. "Think of every criteria you can" was our standard approach. In this instance, in our first iteration, we had a dozen parameters. We showed it to the client. They said, "Look, our Chairman likes these industries a lot. He doesn't like that bunch. We're much more likely to focus on the ones he likes." And that's absolutely important! We ended up adding a "Passion / vision" based on the fit with the company's existing businesses, and that proved the deciding factor.

Another time, I built an entire model on which project to outsource based on 10 parameters. (It was everything I could think of at the time.) The one that I missed was, "When is the project starting?". It turned out that this was the most important criteria. In fact, it was the only important criterion. If I'd simply said, all projects starting after 1-June-2006 can be outsourced, I would've been 90% right.

You'll keep the irrelevant parameters. This is the worst of all. Even after we learnt which the important criteria were, we didn't throw away the useless parameters. We never throw away hours of work, even if it's useless. So the model keeps bloating, and the irrelevant criteria influenced the shape of the graph more than the relevant ones.

Another problem is that this methodology cannot answer questions concisely.

"Why did you knock off Industry X?"

"Oh, because on a cumulative score against revenue, growth, lifecycle, capability, passion and 10 others, it scores less than 45 points."

A good answer should be short. For GE, it would be "You'll never be number one." For HP, once, it would've been "It's not where we can excel technically." For Warren Buffet, it may be "I don't understand the business."

After these experiences, and based on hindsight, I've come to believe the following about MCDM (multi-criteria decision making):

1. Remove irrelevant criteria. Usually a few criteria make the decision. The rest don't matter.
2. Filtering works. You don't optimise in MCDM. You're trying to do well against criteria that are often not comparable. You're better off if you filter out unacceptable levels of criteria, and treat what's left as acceptable.
3. Use a decision tree. Don't compare options. This is the basis of fast and frugal heuristics. It keeps focus on the important criteria, and makes the process easy to implement / explain.

I'll let you read up on fast and frugal heuristics. I'm convinced it's the best way to make decisions based on multiple criteria in the scenarios I've worked on.

| alternate titles: Decision making analysis Decision making case study

Decisions are usually based on multiple criteria. You have to trade off between criteria. I've been involved many such decisions over the last 5 years.

Example 1: A conglomerate wanted to identify industries for growth. We shortlisted 19 industries, identified 12 criteria for the attractiveness of an industry, researched each one and plotted them on spidergraphs like below.

The intention was that, to identify the most favourable industries, you'd just pick the ones with the largest filled area.

Example 2: Another time, we had to decide among BPO vendors. Again, we picked a bunch of criteria and compared vendors against these criteria.

Example 3: Once, we had to identify stakeholders' position on a project.

Those who were big on the right of the graph were for, and those who were big on the left were against.

---

In all the above cases, the same process was used for decision making.

1. List criteria exhaustively
2. Evaluate options against each criteria
3. Assign weights to criteria (equal weights implicitly assigned above)
4. Compare options

Having applied this methodology it several times, I am convinced this process is fundamentally flawed. See how in this post: Errors in multicriteria decision making.

| alternate titles: Multiple criteria decision making

14 years ago, I was introduced to the process of normalising grades. Professors "fit" students' marks into a normal distribution and assign grades based on that. (I still don't know how they do it).

Since then, I've encountered normalising a lot. My performance at work is normalised. I normalise my song ratings and movie ratings. I've normalised all kinds of things at work: lead-time of delivery of fans, movements in savings account balances, calls to a call centre, demand for a resource... you name it.

(What I mean by normalising is, I find the mean and standard deviation, and assume that it's a normal distribution with that mean and standard deviation. For things under my control, like movie ratings, I revise the ratings to fit a normal distribution.)

In fact, I normalise everything I encounter by default.

A few years ago, I started feeling uncomfortable about this. I've now figured out why normalising is bad -- at least when done blindly like I do.

First, let's explore why normalising is good. Normalising eliminates biases. If the Prof in Section A grades higher than the Prof in Section B, normalising takes care of it. If a Prof is extremist (more A's as well as F's), normalising takes care of it. If a Prof is skewed (lots below average, few extremely high above average), normalising takes care of it.

Eliminating biases makes sense if Section A is fundamentally like Section B. It's not better, nor more extremist, nor more skewed. If the sections are large enough and picked randomly, this assumption is correct. If Section A represents the smarter half, or people born in the second half of the year, or people from the Western states, or any other non-random selection, this need not be correct.

An aside: You may wonder why people born in the second half of the year is non-random. If school admissions start in September, and admissions start when you're 3 years old, kids born in September will be nearly 4 years old when they join. Kids born in August will be between just over 3 years. That one-year difference, to a three-year old, is HUGE. For example, you will find a birth date bias in football, with most premiership players being born in the months of September - November.

Normalising goes a step further than eliminating bias, however. Normalising forces a normal distribution. This would be right if the underlying data is normally distributed. But if not, we may be making a mistake by force-fitting.

The Central Limit Theorem says that if you add up random variables, you get a normal distribution. Provided it's a large sample, variables are independent, and each has a finite standard deviation.

This means that many things you get by adding random variables are normally distributed. For example:

• Number of heads when you toss a coin (add up each coin toss)
• Average age of an army platoon (add up each soldier's age)
• Terminus-to-terminus time for a bus (add up the time between each stop)
• Price movement of an stock exchange index (add up each stock's price movement)

But a lot of real-life data is NOT normally distributed. The usual reasons are:

1. It's not the sum of random variables
2. It doesn't satisfy the central limit theorem (independence, large sample, finite standard deviations)

Here are some non-normal distributions that are NOT the sum of random variables:

• Soldier's age within an army platoon. What random variables could you add up? You'll probably find a lot of people at age 18, because that's the minimum age. A little fewer at age 19 -- last year's recruits. Far less at age 20 -- 2 years minimum service accomplished. Certainly not a normal distribution.
• Price movement of a single stock. What random variables could you add up? You'll find that there are far larger price movements than a normal distribution predicts.

Here are some non-normal distributions that don't satisfy the central limit theorem. (These are, in fact, things I said were normally distributed earlier. You see? It's easy to think things are normal, but in reality they're not.)

• The terminus-to-terminus time for a bus. The number of bus stops is quite small. More importantly, the time between stops isn't independent. If there's a traffic jam, an entire section of the route will take more time. If there's a delay between point 2 to 3, it's likely that there'll be a delay between points 1-2 and 3-4 as well.
• The price movement of a stock exchange index. The price movement of stocks follows a power-law distribution, which does not have finite standard deviations. Also, the price movements are not independent.
• See more non-normal distributions.

Summary: Don't assume that anything you see is a normal distribution. It usually isn't.

I'll shortly talk about what happens when you assume something's a normal distribution, when it really is not.

| alternate titles: Non-normal distributions Normal distribution

I rate movies on a scale of 1 (bad) to 5 (good). This is an absolute scale. Initially, I assumed that I would watch as many good movies as bad ones. So I'd have about as many 1s as 5s, and 2s as 4s. But, when I looked at my ratings for movies over the last year, I had far more 4s than 2s. My movie ratings were not normal.

Rating	Frequency
1	8
2	31
3	98
4	81
5	18

The reason is clear. I pick good movies rather than bad ones, based on reviews. If I rated every movie there was, the ratings may be normally distributed (or they may not). But when I pick movies, I consciously reject those I know would have a low rating (based on reviews), so my ratings would be more clustered around the top.

Even if I redefined my scale, I'd still have more than 50% above the average. This is not a contradiction. I watch a LOT of good movies with very similar ratings, and a few disastrously bad movies. The good movies will have a higher-than-average rating, and there'll be more of them than the bad movies. This is a skewed or asymmetric distribution.

So, selective picking can wreck the normal curve.

Yet, almost everything is selectively picked. Colleges try and pick the best students. Organisations tend to pick the best employees. If they rate performance, they're likely to find a bias towards the higher side -- at least, the good colleges and organisations. Force fitting a normal distribution pushes down genuinely good people. (In bad colleges and organisations, it pushes up genuinely bad people).

I was working with the treasury of a bank. They were trying to estimate how much money could flow out of their savings account in a day, worst case.

I took their total savings account balance at the end of each day and found the standard deviation. I took thrice the standard deviation, and said, "You can be 99.7% sure that your daily loss won't be more than 1.5% of the balance."

That would be right if it were a normal distribution. But it's not.

Banks have millions of savings accounts, each of which is like a random variable. But unless they're independent, and they have finite standard deviations, the central limit theorem won't work.

Firstly, savings account transactions are not independent. If there's a run on the bank, they'd all pull out their money. Whenever a company declares dividend, a large number of savings account are credited. Salary accounts are credited at the end of the month. As a rule of thumb, you could say that if one savings account goes up, the others are likely to as well.

Secondly, savings account transactions are not normally distributed. If you take a single savings account, you won't find a bunch of debits and credits. Every month, you'll find one large credit for the salary, one mid-sized debit for monthly expenses, and several small debits for individual transactions (bills, ATM, etc.) Once in several years, you'll find a gigantic debit (purchase of car or house, wedding, etc.) or a gigantic credit (retirement / pension fund, sale of property, etc.)

As a result, the savings account is likely to fluctuate a LOT more than if it were a normal distribution.

If I had just looked at the data, I'd have found several occurrences of fluctuations greater than 1.5%. The normal distribution predicts that there should be fewer than 0.3% of such cases. That's about 1 per year. I'd have visually been able to spot nearly one a month. I'd also have been able to spot the huge 4% swings that do happen once in a few years.

People wiser than me have made the same mistake. I was interning at Lehman Brothers when they were planning to launch a new electronic bond-trading product. My task was to trace the bond price movement.

The data we had was bad. Many bonds jumped as much as 40% in a single day, due to data errors. The bulk of my task was to clean out these errors.

After cleaning up, there was still two jumps that couldn't be explained. I went to my boss, who recognised them at sight. One was a sudden drop in price of all Government bonds in December 1998. The other was a 32% drop in price of Hikari Tsushin -- a mobile phone retailer -- on the day they went bankrupt.

We concluded that the daily price drop wouldn't be more than 9%, to a 95% confidence level. If that was right, a 32% drop in one day would happen once in a million years. Yet, we had Hikari Tsushin just the previous year.

We didn't bother about it. In fact, we didn't even think about it. If we'd checked, we'd have found that the daily price drop was closer to 12% or something, to a 95% confidence level.

Summary: Force-fit a normal distribution on non-normal data can understate the worst-case scenario. Often you're better off just inferring confidence levels from the raw data than from a fitted distribution.

Change management can be analytic, as opposed to touchy-feely.

Our client's operating margin was falling. The bosses wanted to offshore their back office. Others weren't convinced. To manage this change, we needed three questions answered:

• Who's not convinced?
• Why aren't they convinced?
• What'll convince them?

Who's not convinced?
We plotted the level of support and importance of key people on the stakeholder support matrix. This split people into 4 groups (below). Then we showed it around to people and had them move people around on the matrix.

• Minor sceptics. We largely ignored them
• Change facilitators. We tasked them with roles in the project
• Change agents. We made them influence the others
• People to convince. The ones we needed to focus on

This is a simple concept, actually. The insight is, putting names on such a matrix, and getting people to move them around, is a robust way to get everyone on the board and at the right spot.

Why aren't they convinced?
We sent everyone a list of benefits and issues in outsourcing. They rated them. We grouped the results and plotted them. Here's the result for Uli.

Uli saw more issues than benefits. Quality and possible better service were benefits. But he was afraid the company wasn't ready, and vendors wouldn't understand their operations.

The advantage of these charts is that you can put them side by side, and compare where different people stand. It gives you a great view of why they're objecting, and whom you can use to counter that.


What'll convince them?
Once we knew why people objected, it was easy to manage.

For example, to counter Uli's fear of organisational readiness, we got people who felt this was not an issue to put forward their counterpoints.

To counter fears of vendor ability, we got a bunch of them to visit BPOs in India, and spread their confidence to others.

We arranged workshops, making sure that each group had people to convince and change agents.

This did require a lot of soft skills. But the success was largely because of the structured ground-work. Change management can be quite analytic. | alternate titles: Organizational change management Business change management Best practices in change management Change management case study

Change management can be analytic, as opposed to touchy-feely.

Our client's operating margin was falling. The bosses wanted to offshore their back office. Others weren't convinced. To manage this change, we needed three questions answered:

• Who's not convinced?
• Why aren't they convinced?
• What'll convince them?

Who's not convinced?
We plotted the level of support and importance of key people on the stakeholder support matrix. This split people into 4 groups (below). Then we showed it around to people and had them move people around on the matrix.

• Minor sceptics. We largely ignored them
• Change facilitators. We tasked them with roles in the project
• Change agents. We made them influence the others
• People to convince. The ones we needed to focus on

This is a simple concept, actually. The insight is, putting names on such a matrix, and getting people to move them around, is a robust way to get everyone on the board and at the right spot.

Why aren't they convinced?
We sent everyone a list of benefits and issues in outsourcing. They rated them. We grouped the results and plotted them. Here's the result for Uli.

Uli saw more issues than benefits. Quality and possible better service were benefits. But he was afraid the company wasn't ready, and vendors wouldn't understand their operations.

The advantage of these charts is that you can put them side by side, and compare where different people stand. It gives you a great view of why they're objecting, and whom you can use to counter that.


What'll convince them?
Once we knew why people objected, it was easy to manage.

For example, to counter Uli's fear of organisational readiness, we got people who felt this was not an issue to put forward their counterpoints.

To counter fears of vendor ability, we got a bunch of them to visit BPOs in India, and spread their confidence to others.

We arranged workshops, making sure that each group had people to convince and change agents.

This did require a lot of soft skills. But the success was largely because of the structured ground-work. Change management can be quite analytic. | alternate titles: Organizational change management Business change management Best practices in change management Change management case study

Packaging can make a huge difference to products. It really hit me when I saw this bottle of Heinz's ketchup. My two big problems with normal ketchup bottles are: (a) the sauce spills to the side of the bottle and sticks to the cap, and (b) it's tough to pour the last bits of sauce -- you have to hit the bottle a lot.

Now, I didn't know I had these problems. But when I saw this bottle, it hit me. You keep the bottle upside down -- so it's easy to pour the last bits of sauce. And they way the nozzle valve is designed, the sauce doesn't stick to the cap. Perfect! Since then, I don't buy any other ketchup bottle. Even if I WANT ketchup, I don't buy it unless I get this bottle. Packaging made be brand loyal. (Caveat: I'm not REALLY brand loyal. I'd buy any ketchup with this packaging. But only Heinz has it right now.)

The same thing with honey. The same packaging with honey gives me a third advantage. I can drink a bit of honey directly by holding up the bottle over my mouth and squeezing it. Plus, I don't need a spoon. Because of this, my consumption of honey has shot up to 1 bottle of honey every month. Further, I have started spreading honey over ice cream these days. Note: packaging changed my eating pattern.

So, impressed by all this, I wandered around superstores, exploring the innovations in packaging (mainly in food). I will shortly blog about that. In the meantime, here are some innovative packages introduced around when Heinz's inverted ketchup was. | alternate titles: Package design Packaging design

A software services firm once asked us, "How come we are not able to staff projects quickly, even though we have a lot of people on the bench?"

There were a bunch of reasons, but among those, we found something interesting. They were implementing two policies that were logical on their own, but disastrous together.

(The bench is where programmers sit when they are not on a project.)

Here's how they work. When a project starts, the project manager requests resources (people) for the project. HR passes on matching CVs to the project manager, who approves or rejects them, in consultation with the client.

They had two principles. Firtly, all matching CVs that are available are sent to the project manager. This is a good policy because it gives the project manager and the client a lot of options.

Secondly, while a PM is considering a CV, it is not double-submitted to someone else. Again, sensible, because you don't want two clients asking for the same person at the same time.

But together, these policies killed staffing.

Every CV that is proposed is effectively "out of circulation" until it is accepted or rejected. Yet, the person is still on the bench, and very much "in circulation". So he can't be staffed, even though he's available.

On average, 2.4 CVs were sent for every request. On average, a manager would hold the CV for 10 days. So, every request enforces 24 person-days of compulsary bench-time.

On a typical day, 75% of CVs were locked up this way. For example, on 22 Dec 2003, 291 CVs out of 384 were proposed for resumes. So a new request would have less than a quarter of the available bench to pick from.

No wonder they were complaining they couldn't staff quickly enough, even though they had a large bench.

Once, we were looking at whether banks made money on demand drafts (DDs).

DDs are costly. 90% of a bank's costs are people-related, and it takes a fair bit of time (hence people) to process DDs. If you pay for DDs in cash, it costs even more because the teller has to count the notes.

To recover this cost, banks charge a fee. The fee increases with the size of the DD. A DD for Rs 10,000 may cost Rs 50, while one for Rs 100,000 may cost Rs 200.

But apart from the fee, banks also earn float on the DD. Let's say you go to a bank, pay Rs 100,000, and take a DD. You mail the DD to someone, who cashes the DD three days later. The bank has your Rs 100,000 for 3 days, and earns the overnight interest rate at around 5%, netting Rs 41 in the process. This float is significant for large DDs.

Our client bank was making a small loss on DDs. Every DD less than Rs 50,000 caused a loss (even after including float). And 3 out of every DDs was smaller than Rs 50,000.

Then we had this bright idea: let's lower fee for large DDs, attract of them, and get more float income. DDs above Rs 50,000 are profitable. So big DDs are worth going after. 80% of the float income comes from the top 22% of DDs. So surely, the big DDs are worth going after. Float income increases forever, whereas fee income is capped. So big DDs could absolutely be terrific.

We were thrilled. Here was a revolutionary counter-intuitive idea: have lower charges for DDs to get more money. We kept talking about it to our client. But at the end, we didn't suggest it. It got left behind the conventional idea of increasing the fee for small DDs.

We were a bit disappointed, and kept cursing the conservatism of public sector banks. Goes to show how the bright young consultants can be naive. For, as it later turned out, the bulk of DD revenues is really fee income (88%), not float income. Had we lowered the fee income, there's would've been no chance for the float income to make up for it.

Why did we miss that? A couple of reasons. The simple one was, though the float income increases forever, doesn't beat fee income until the DD is about Rs 2 crores. DDs typically stay with you for a few days, and you can't earn much interest on that.

The other reason was subtler. We had assumed that the float income for a DD of Rs 100,000 is 100 times that of the DD income for Rs 1,000. But the float income does not increase linearly! Someone who gets a DD for Rs 1,000 doesn't mind waiting a bit to present it, but someone who gets a DD for a lakh would walk to the bank the very same day. The chart below shows how long customers wait to cash DDs. The X-axis is the size of the DD. The Y-axis is the number of days they wait. It shows a clear diminishing trend.


Lesson: Conservative bankers might make more money not listening to hotshot consultants.

We were working with the financing subsidiary of a conglomerate. They had two divisions that gave loans for buying vehicles (mostly trucks, but also cars). One division used the direct channel. They had direct marketing agents (DMAs) who were paid a commission for getting the contract, and the division collected the monthly installments. The other used the dealer channel. The dealers would get the contract as well as collect the installments.

They wanted to cut costs, and asked us which channel had more flab. Since the company used IRR (internal rate of return), we defined the operating cost as the reduction in IRR. For example:

12% IRR paid by customer (through monthly installments)

9% IRR to subsidiary after reducing the cost of processing his loan

3% is therefore the operating cost.

After two months of analysis, we confirmed the subsidiary's own opinion: the dealer channel had lower operating cost. The direct channel's operating cost was 3.8% while the the dealer channel's was 2.7%.

So we said the direct channel is flabby.

But the direct channel guys didn't agree, and fought every inch of the decision.

"Do you think these figures are wrong?" I asked.

"Look, all we're saying is, we KNOW they pay out huge commissions to dealers. We KNOW they're overstaffed. They just CAN'T have a lower operating cost."

I was tasked with resolving the issue. After a month of breaking the cost every single way, something interesting emerged. If we measured the operating cost per contract in Rupees, both divisions had the same cost per contract: Rs 18,500. That is, the total cost incurred in getting the customer and servicing the loan over the lifetime of the loan was Rs 18,500 in both divisions.

It turned out that the size of the loan was different: the dealer channel was still lending mainly for trucks, while the direct channel had entered the high growth passenger car market. Cars cost less than trucks. So while the dealer channel was paying 18,500 and getting interest on a large truck, the direct channel was paying the same 18,500 for less interest on smaller cars.

This is a strategic decision. The subsidiary had chosen to enter the car business knowing it would be less profitable but have higher growth.

But the story had a twist.

The 18,500 of operating cost per contract broke down as follows:

	Dealer	Direct
Getting the loan	5,000	7,000
Servicing the loan	13,500	11,500

The dealers are paid a servicing cost as a percentage of the loan. Servicing in the dealer channel is a variable cost. The direct channel, however, employs its own people, and incurs a higher cost only when it hires more people. About half of the costs are fixed. If the business doubles, the number of people you need increases only by about 50%. Servicing in the direct channel is more a fixed cost.

This subsidiary was planning to double their business in two years. At that point, the dealer channel would still cost Rs 18,500 per contract, but the direct channel would have come down to around Rs 13,000. So, going forward, the direct channel is really cheaper!

We told them to try and reduce the dealer commission.

Postscript: The subsidiary still went ahead and cut costs aggressively in the direct channel. It's easier to fire your own people than to tell 500 dealers to reduce their commission, especially when you need them to also sell your trucks.

Banks install ATMs to lower their branch costs, and to attract new customers. When working out the economics of ATMs, we found that lowering branch costs alone could not be a viable reason to install an ATM.

The bank argued as follows:

"Every time someone withdraws money from an ATM, they avoid going to the branch. With enough people going to the ATM, I can afford not to increase my branch size, and that saves me money. Since it costs me Rs 20 every time a person withdraws cash (in terms of salary, rent, etc.) and an ATM costs about Rs 2,200 a day, I'll break even if there are 110 cash withdrawals from the ATM."

The argument misses a crucial point: every ATM transaction does not replace a branch transaction. People visit ATMs more frequently than branches, thanks to them having smaller queues and being open 24 hours. As a rule of thumb, people visit ATMs twice as often as a branch to withdraw cash.

A teammate didn't believe me. We argued.

"When I used the branch, I would withdraw money for the entire month at the beginning of the month. I continue the same with an ATM."

"But I withdraw cash whenever I need money. And in smaller chunks. Sometimes, I just withdraw Rs 200. That way, I get to carry less cash too."

"Ah, you may be the exception, as always. Very well, I will find out."

He went to a fairly representative branch, and asked them how much money would people withdraw before their ATM was installed. Since ATMs impose a limit of Rs 15,000, he discarded transactions above Rs 15,000. The answer was: people used to withdraw about Rs 3,600 every time they came to the branch. Then he asked, what's the average ATM withdrawal. Answer: Rs 1,900. In other words, people seemed to withdraw only half as much from an ATM as from a branch. (And therefore, on average would withdraw twice as often every month.) My teammate was finally convinced.

So, in order to break even, the ATM must be used about 220 times a day, not 110 times. This is nearly impossible. ATMs are used mostly in peak hours: morning while travelling to work, during lunch, and evening when travelling back to work. Apart from these hours, the ATM is practically unused. This gives roughly a 4-hour window. The time between two ATM transactions is at least a minute. So a very busy ATM might be able to make the 220 transactions in that time. Most ATMs will not.

In fact, we found that only 4 ATMs managed to break even, among their 250. The cost-saving argument alone is difficult to justify an ATM.

Reliance Infocomm, after launching their prepaid business in India, introduced an new scheme. Pay Rs 4,300, and get a mobile phone PLUS prepaid vouchers worth Rs 4,300. Effectively, you're getting a mobile phone for free. The scheme made good financial sense for Reliance. With a million subscribers to this scheme, they could recover Rs 430 cr of their upfront capital investment and retire their debt. Besides, the Rs 4,300 would have normally been bought over a period of around three years by prepaid subscribers, making its present value around Rs 3,600, at an interest rate of 12%. Add to that the reduction in distribution cost due to bulk selling, and possibility of non-usage, etc... the economics might work out.

But after the scheme was launched, Reliance was puzzled. Why did the sale of their normal prepaid cards dip? Any new prepaid customers would obviously go in for the new scheme. But old prepaid customers would still need prepaid cards, and should have bought them from the dealers. The dealers should have come back to Reliance to stock up their prepaid cards. Why didn't they?

What happened was, they hadn't anticipated was the ingenious market. Many new customers didn't need the full Rs 4,300 worth of talk-time. Spotting this need, dealers would repurchase these prepaid vouchers at a discount.

Dealer: "Look, if you don't need the entire Rs 4,300 worth of vouchers, I'll buy some of them back."

Customer: "I just need Rs 1,000 of talk time. Can I return Rs 3,300 worth of vouchers and take Rs 3,300 from you?"

Dealer: "I'll take Rs 3,300 worth of vouchers, but I'll pay you only Rs 3,000."

Customer: "Well, I'm effectively paying Rs 1,300 for a mobile phone plus Rs 1,000 worth of talk time. Sounds good!"

The dealer now has Rs 3,300 worth of vouchers. So he doesn't go back to Reliance to restock. When regular prepaid customers come in for prepaid vouchers, he'd offer some from the repurchased stock. The customer benefits (lower cash payment), the dealer benefits (higher margins), and it's only Reliance left wondering why the sales dropped.

Over my last few years as a consultant, I've seen many interesting ways in which markets have emerged where they shouldn't have, creating havoc in pricing and scarcity. Fixed prices fluctuate, free goods acquire a value, and non-tradeable goods are traded. I'll share a few of these examples over the next few weeks.

Once, a fan manufacturer asked us, We did an analysis and found that our wholesalers' margins fluctuate. How could that happen, when we are fixing their buying and selling prices?

The manufacturer sells several popular fans. Their highest selling fan (call it HS), for instance, was sold to wholesalers at Rs 1,089, who would then sell it to retailers at Rs 1,100. No question of margin fluctuation.

I took a trip to Lohar Chawl, the wholesale fan market, to get to the bottom of this. After a few conversations in dingy warehourses, here's what I discovered. Fans are bartered. Wholesalers keep as little cash and inventory on hand. Often, a retailer would order a fan (say X) not in stock. The wholesaler doesn't want to lose the deal, and doesn't have cash, but he would have some inventory of HS, since it's such a high-selling fan. He goes to another wholesaler, and says,

"Give me some fan X, and I'll give you some HS fans instead. You'll be able to sell these HS fans fairly quickly anyway."

"Why should I? Tell me your customers name and I'll sell it to him myself, and make the profit."

"Tell you what. I'll give you my HS fans for Rs 1,079 instead of Rs 1,089. You'll get a higher margin when you sell it."

This is a routine matter in Lohar Chawl. If you don't have a fan, barter it for another (often HS) at a discounted price. So the wholesaler's margin would depend on how many fans they bought at a bartered price!

Poaching was another reason for the margin fluctuation. The manufacturer demarcated territories for each wholesaler, saying "You can sell the these 20 retailers, you can sell to those 18, and so on." Ambitious wholesalers, or those with inventory to dump, would do a side deal with a retailer.

"Look, your wholesaler charges Rs 1,100 for this fan. I'll sell you this lot for Rs 1,095. And let's keep it quiet."

Yet another reason for margin fluctuation was smuggling. Sometimes, the wholesalers would be able to smuggle fans into Mumbai without paying octroi. And sometimes they wouldn't.

The biggest lesson for me from this was, It's bloody tough to restrict a free market. I'll tell you more about this shortly.