Why software consultancies fail to transform

For many small software consultancy companies, here is the perennial dilemma.

“Whether to remain a consultancy company or to become a product-based company?”

So why software consultancies fail to transform? For two obvious reasons. It is very hard to scale consultancy companies. Real money (and glory) lies in becoming a successful product-based company.

There are a few examples of such successful transformations. Basecamp(previously 37Signals) started as a consultancy company and successfully transformed itself in to a product-based company. Same goes for Fogcreek(creators of FogBugz and Trello).

Such examples are very few and most consultancies fail to do this transformation. Digicorp has been one of such companies so far. We have launched some really good ideas in the past but have failed to make something big out of them.

I am sure there are hundreds of small consultancies who have failed like us. But why?

Why it is very very difficult to transform your organisation from doing one type of work (software consultancy) to doing different type of work (making your own software products)?

The strange thing is, we are not even talking about acquiring different kind of skills here. Software consultancies already have people creating brilliant software products for their clients but the same people are not able to do the same for their own organisations. What is wrong here?

Well, finally I have found a plausible answer or at least a perfect language to describe this phenomenon.

The answer lies in the book — “The Innovator’s Dilemma”, a classic book and all time favourites of likes of Steve Jobs.

The basic argument in the book is:

“If an established company doesn’t disrupt, it will fail, and if it fails it must be because it didn’t disrupt.”

There is an irony in the entire argument as it is circular. Read below paragraph and you might get a gist of the book.

“An organization’s capabilities reside in two places. The first is in its processes — the methods by which people have learned to transform inputs of labor, energy, materials, information, cash, and technology into outputs of higher value. The second is in the organization’s values, which are the criteria that managers and employees in the organization use when making prioritization decisions. People are quite flexible, in that they can be trained to succeed at quite different things. An employee of IBM, for example, can quite readily change the way he or she works, in order to work successfully in a small start-up company. But processes and values are not flexible. A process that is effective at managing the design of a minicomputer, for example, would be ineffective at managing the design of a desktop personal computer. Similarly, values that cause employees to prioritize projects to develop high-margin products, cannot simultaneously accord priority to low-margin products. The very processes and values that constitute an organization’s capabilities in one context, define its disabilities in another context.”

Let me reword one sentence from above paragraph in our (software consultancies) context.

“A process that is effective at building scalable software products for our clients, for example, would be ineffective at building disruptive ideas like [write our own product ideas here].”

Even if we put right people at the right places, it will not help us building“disruptive technologies” i.e. creating our own products. Our processes and values won’t allow the right people (whos) to prioritise correctly.

That is why there is a word “dilemma” in the book’s title. The same Resources-Processes-Values (RPV Framework), which is crucial in building software products for our clients are becoming roadblocks in creating products for our consultancies.

The author has proposed a solution also for the same but it is probably the story for another post.

What do you think? Is your organisation going through the same transformation and failing?