Why Many Technology Consultancies Will Never See $100M Revenue

Consider two hypothetical technology consulting organizations.  One has 50 people and 10 million USD revenue, another has 500 people and 100 million USD revenue. Is one just a larger version of the other, with more geographic expansion?

Obviously not.  There are many differences.  For one, it is harder to manage 500 people than 50.  The latter allows you to probably know the names, histories, likes, and dislikes of each of your people.  The former, you might pick up only if you are Rain Man or otherwise have some sort of amazing photographic memory.  That alone is a significant challenge.  However, there are bigger challenges that I think deserve a good deal of attention.

Lets first consider the ways two different organizations like this will look at a comparatively small deal, valued at $200k.  All other things being equal, $200k is 2% of the revenue of a $10M company, whereas it is 0.2% of the revenue of a $100M company.  While all companies will pursue the deal, it is probably more likely that for the smaller company, the $200k deal will get more attention from the founder or senior executive officers than it will for the larger one.  Having see operations in consulting organizations that range from single digit millions revenues to billions in revenues, one truism is that typical deal size is around 1-3% of revenue.  Note that I am not talking about client size – as some clients may have many deals in that range… but single deal size tends to congregate around that number.

A big implication of this, of course, is that with larger deal size, comes longer deal duration, especially for projects.  Lets assume we are selling teams, we are not selling mere staff augmentation, and that the team size is somewhere in the 4-8 range.  Lets assume rates go from a low end of $50 per hour, to a high end of $200 per hour.  This gives us a range of $8,000 per person-month to $32,000 per person-month.  With team sizes going 4-8, you can then expand to team-months of $32,000 per team-month to $256,000 per team-month.  Given these assumptions, a $200k deal will range from 1 month given a very large, high-end team, to 6 months, given a small, low-end team.  The actual deals in this space tend to come in a bell curve shaped distribution, with  $200k deals typically being in the 2-4 month range.

What is funny about that number, 2-4 months, is that is typically where Waterfall style deals tend to really start falling apart.  At sizes below 2-4 months, you start to be in the neighborhood of the predictable.  A great team of otherwise skilled people, working under Waterfall methods, can probably come in under the terms of the contract if you have a 3 month or less duration.  Agile will still probably do better, but a shorter time frame does give you a better chance of success, regardless of method used.

So what happens?  Well – let us just for a second focus on what is easier to sell, in the world of small deals.  First, let me go out on a limb and say that it would be far easier to sell the certainty of Waterfall, with it’s “fixed” budgets and hubris, than the fuzziness of Agile, where you have to admit the truth and concede that you don’t know what you don’t know.  If selling Waterfall is easier, and your typical duration is 2-4 months, one could reasonably conclude that a small consultancy selling certainty will grow faster than a small consultancy selling honesty.  This is especially true in a world that frequently throws out ethical concerns, quality concerns, or any other concern that isn’t “get the deal done”.  The most important growth factor in such organizations is perceived to be sales, because sales people bring in the deals, and at this level of deal, a perception is often that you can get there with commoditized delivery.

But what happens on the way to $100 million?  Well, first of all, we have to multiply everything by 10.  If your typical deal size is $2M, rather than $200k, your duration is also probably longer – 8 months to a couple of years.  You have moved from the world of single projects and into the world of complex “Programs” (i.e. in the “Program Management” sense) that involve a different kind, and number of stakeholders.  At this point, hubris can’t win, because Waterfall utterly fails in the land of long, multi-month projects.  The key skill of the traditional “deal-maker” hunter type who cuts the deal, gets the signature, and moves onto the next one is far less valuable than the farmer “engagement-manager”/client partner type who lives or dies by delivery.  This is why you see so few technology consultancies get to $100M of revenue without the help of either:

  • Being tied to a software product company (i.e. IBM Global Services, etc.)
  • Having a relationship through other means, such as an accounting firm
  • Being an outsourcer who sells on a pure “cost cutting” premise.

Some companies have made it.  I am proud to say ThoughtWorks is one of them.  But for that to happen, something has to shift on the way from $10M to $100M:

  • Delivery matters much more than sales.  Great delivery is your sales engine.  You still need sales – demand has to be generated.  However, much like how a retirement account you contribute to over time hits a point at which the earnings from prior investments exceed new principal contributions – at some point – earlier than you think, delivery is far more important to growth than sales.
  • Reliance on Waterfall as a sales tool has to end.  Waterfall works for deals in the small, sometimes, about as much as Agile, and for some, is easier to sell.  In the large, it does not work very well, and hinders your ability to deliver.  At some point, if you are in the business of doing multi-month, multi-million dollar deals, you have to deal with the realities of software development.
  • The larger you get, the more that workforce engagement matters.  A dynamic delivery organization that feverently acts in the interest of the client and the company is a key differentiator in a space where delivery is the key to growth.
  • You have to be differentiated.  The companies that spend millions of dollars on multi-year programs are not going to select you because you took the executive to a really nice steakhouse and a good round of golf.  There has to be a reason why a large audience of stakeholders will understand why you are different than the thousands of smaller and less expensive companies are going to get the contract.  Saying you have great people or a great process isn’t enough – those are mere “table stakes” to the table.
  • You have to be global.  It is simply a reality of our business that, to compete for the multi-million dollar deals, you have to be able to have great talent all over the world.  Most companies you sell to at this level have global operations.  To service them, you need to be global too.

In other words, what got you here won’t get you there.  Many, many companies get stuck in a rut at some point between the 10 and 100 million dollar revenue mark, and fail to recognize what they have to do in order to break through.  If you are a consultant, it is something you need to think about – especially if you are the kind that wants opportunities to have a larger impact doing important work.

Why Many Technology Consultancies Will Never See $100M Revenue

Business Intelligence does not Come From a Product

There is this guy, Bradford Cross, whom I met on my first project at ThoughtWorks.  I remember the day in a profound way, as I was on my first day at a client that, you could say, was something of a well known company in the top tier of accounting firms.  The kind of place one might perceive, without knowing further, was the kind of place that still may have a “business attire” dress code.  Well – here I am on day one, and this person walks in, I think wearing a green belt, unmatched pants, having messy hair – ready and eager to start work on this new project we were working on.

Welcome to ThoughtWorks, and Welcome to Silicon Valley!

Fast forward to today, and this same person, who I remember having a passion for functional programming and math that far exceeded anything I could muster up, is now one of the people behind FlightCaster – a service that uses functional programming (using Clojure and Hadoop) to implement a predictive algorithm that can tell you – with far more accuracy than the airlines – when your flight will arrive!  Being the cynical skeptic that I tend to be, I really did not believe it until I started using the service myself.  While I am only two flights in, the results are very promising.

To sum up what it does, the service uses 10 years worth of flight data, along with a certain amount of statistics wizardry that I almost certainly don’t understand, to correlate various events (plane arrival times, weather, etc.) to instances where delays occur.  More to the point, when I think of what business intelligence should be, what FlightCaster does seems far more interesting to me than what I have seen in most vendor presentations.  This is what leads me to the idea that BI comes from an idea about how correlation might occur, combined with technical folks who understand statistics and know how to harness data to do analytics.  It almost certainly never comes along because you install a tool.

So if that is where BI comes from, what is the most ideal toolset for helping to realize it.  There are no shortage of vendors who will try to sell you something that will lock you into their stack.  Or sell you some sort of whiz-bang UI that convinces you that you can go cheap on people so long as you just have good tools.  A typical anti-pattern is that an organization will buy the tools, then basically use them to do reporting against a data warehouse and post some simplistic results to some dashboard.  Something that, when you get down to it, you could have done without the tools, and probably without the fancy dashboard, at far lower cost using simpler tools.

This is especially true today.  We now have functional languages, equipped with great math and statistics libraries, that are for the most part mainstream (Clojure and F# come to mind).  We have open source tools like Hadoop (no more big expensive software) which make this stuff work in distributed computing environments that make it so you can leverage commodity hardware (no more big expensive iron).  If FlightCaster, a service that is as innovative as anything I have ever seen in the BI space, probably moreso, runs on this kind of stuff, it is probably good enough for what most companies would ever call their own BI efforts.

So what are the barriers to this?  One barrier I have encountered is that there is a bias against BI efforts that require “programming”.  I once gave a webinar about this topic to a group of CIOs, Consulting Executives, and BI product vendors.  One of my points was that the most useful BI efforts would require a technologist.  One guy in the crowed literally booed.  There is literally a subculture in the world of BI that thinks if you have to have someone program something, you have done a bad job.  Why this is the case I can’t be certain, but given that there are corners of the IT world that see programming as something to be avoided, it is not entirely surprising.

Another barrier is that there are more than a few CIOs or “Directors of BI” who are charged with the task of implementing a BI initiative, but have no clue where to start.  They know they need it, and that is as far as it goes.  Opportunistic salesperson comes on the scene, sells the SKU, and suddenly, we have a BI initiative made mostly out of shelfware.  It does not help that the world of “big database” (think IBM, Oracle, Microsoft) sells a database product that is largely a commodity without some proprietary BI extension which is usually added for differentiation purposes.  With a database software sales force already ensconced in the world of the enterprise CIO, it should suprise nobody that there are folks who think you need IBM, Oracle, Microsoft, or some other product to do BI.

I am here to say hogwash.  You don’t need any of that stuff.  The tools are here, they are free, and they have clearly done BI on a scale grander than most BI efforts I have seen inside most corporate IT.  What you need is a decent use case (tell me when my flight will arrive), that is solvable by a combination of data, math, and organizational will.  Do that, and you will have Business Intelligence.

Business Intelligence does not Come From a Product