Date: April 8, 2009

Author: JT

Tags: , , , , ,

Comments Off on The ‘Business’ in TBC

The ‘Business’ in TBC

Balancing Act, Technical Business ConsultingAs a Technical Business Consultant, there are times where I find the role akin to being an ad hoc CTO.  As a business savvy technologist, there are frequent situations where two or more interrelated problems need to be solved concurrently.  For instance, a technology-based issue might be interpreted in black ‘n white fashion, yet doing so may preclude a successful business deal from being closed.

As I discuss in, “Is Your Technology Working For You?” and, “What Is Technical Business Consulting?” there is a need for someone who can span the differences between primarily technical and business oriented parties.  In this post we’ll look at an example, operating as a global technical account manager, I put the ‘business’ hat on to help the team deliver a better solution.

We were six months into an extended sales cycle with a Fortune® 100 company selling a mid-range design software product.  The issue was not one of whether or not to adopt our products; they had already decided to do so.  What was protracting the situation was a need to reconcile how many licenses of our product they already had, how many they needed, and what the overall price tag would be.

The first point was software licensing.  As with any organization of decent size, when it comes to acquiring new licenses (particularly upgrades for pre-existing licenses), disagreement over the final count is common.  The crux of the problem is always poor management, control, of the asset.  Because the cost to do an audit may be prohibitive (e.g. how many copies of Office are in your office?), the vendor and customer often simply decide to ‘agree’ on a number.  Some modest attempts to do an audit may be attempted, to help test expectations, but in the end it’s often an agreed-to number…particularly the more commoditized the software may be.

While determining the license count is primarily a technical challenge (using network auditing tools and the like) the technologist must be sensitive to how they coach the rest of the sales team in coming to a number.  Typically the vendor will feel their customer has under-reported its actual usage.  The customer is nervous because they don’t want to be perceived as having committed software piracy.  The vendor does not want to be taken advantage of but…they want the revenue.  Regardless neither side wishes to make ‘too’ big a deal of it.  In the end, a successful sale depends on the perception of a win-win.

Contract negotiations at this level can take months, occasionally years.  The contract values are themselves significant enough to have material cash flow consequences.  So designing a proposal that takes into account cash flow, the actual demand for the product in question (e.g. do we really need this many), along with total contract value, is important.  In this case, it fell to my shoulders to develop the business model supporting the various considerations.

The result was a 4-sheet Excel workbook.  The first sheet (tab) was a ‘dashboard’ that let the customer play what-if scenarios.  In provided input based on the number of software licenses required, by product type, by funding business unit, and by volume.  The dashboard provided summary level feedback while the other three pages (tabs) provided printer-friendly documents of total contract value, annual payment values, and breakdown by customer business unit.  In essence, it was a tool that allowed Purchasing to help sell the final deal internally.

As the final numbers began to congeal, both software count as well as contract values, we were finally asked one more question.  Would we take a single up-front payment, discounted around 20% of contract value, rather than annual payments over the course of the proposed 3-year contract?

While this was a challenge for the account exec at first, for me this was a TVM proposition.  The customer had actually given us an olive branch.  By granting them a discount to do a single payment option, we made it more palatable for them.  On our side, it was also tactically beneficial.  The sales VP who would get credit would want to recognize any and all revenue right now.  Politically, this was key since most VPs could expect to transfer out of their current role before the life of the contract expired, so ‘grab it all now’ had merit.

How do you convince the CFO?  This is where the Time Value Money (TVM) calculation came into play.  A bird in hand is worth two in the bush, or so the saying goes.  The real question is, are 1.8 birds in hand worth 2.x in the bush?  It was a relatively simple matter to use our own company’s internal rate of return (IRR) to figure out what the value of the contract would be, discounted backward to today’s dollar value.  The customer had hit the number close enough; we could propose the deal to senior management directly and with confidence.

Technologists often view things as on/off, bits and bytes, black or white.  ‘Business’ often requires some ‘tolerance,’ an ability to apply gradient, a gray scale.  To be successful required being able to readily blend both the analog and digital worlds; work to understand the capabilities, interests, and limitations of the various concerns; and understand one’s role within a team.

Comments are closed.

%d bloggers like this: