Tech Enablement in Management Consulting: Best Practices and Common Mistakes

Historically, management consulting companies have relied primarily on human capital to solve complex business challenges of their clients. The traditional consulting approach entailed building a team of a handful consultants to analyze client data and develop recommendations for C-Suite over a 2-3 month engagement.

However, over the last decade, we've seen a distinct trend towards asset-based consulting in which tools and products represent the main asset of the offer. There are several factors contributing to this trend:

First, consulting firms have realized that recognizing patterns in their clients’ problems and productizing their intellectual property (IP) allows them to deliver their services in a much more robust and scalable fashion.

Second, as datasets have become larger and more complex, consultants now need more modern data analytics technologies. Traditional tools, such as Excel and Powerpoint, are no longer adequate for deriving quality data insights.

Third, even with the most sophisticated and seasoned experts, consulting firms see competitive threats from startups leveraging data technologies to deliver insights. For that reason, AI and Big Data have further accelerated the pace of productization in the management consulting space. 

The leading consulting companies, such as McKinsey, BCG, and Bain & Company, recognized the need to evolve their operating model in the early 2000s. They started building reusable assets in the form of tools, datasets, and even stand-alone software applications. However, most of them are still experimenting with various operating models for incubating ideas and driving innovations for maximizing client impact.

Where asset-based approach is used 

The approach is primarily relevant for the areas 1) with a high likelihood of patterns and reusability for structurally similar client problems and 2) data-intensive approaches to solving those problems.

From my own experience in McKinsey and Accenture, I can say that the most common areas where consulting companies launch their own products are advanced analytics in healthcare, consumer data analytics and predictive modeling for service industries, and benchmarking tools in financial services (corporate finance, asset management, banking, and others).

One example is the Healthcare Market Intelligence offering by McKinsey. The company leverages its advanced analytics tooling to aggregate proprietary and third-party healthcare datasets and deliver high-quality insights on provider landscapes or market demographics. Another example is Finalta by McKinsey, a suite of data analytics and diagnostics solutions for banking and insurance. Finalta offers performance-benchmark data from 200+ financial institutions and helps its clients generate actionable insights by understanding their performance against that of peers. 

Organizational models for tech enablement 

There are three main organizational models for technology enablement inside consulting companies. 

1. Centralized model — various consulting practices partner with the central technology team to build a reusable solution to solve a client’s problem. Practices act as internal customers, whereas the central team is essentially their technology vendor. Technology enablement initiatives are treated as projects.
2. Decentralized model — consulting practices build their own internal technology teams or contract external development partners. Practices aim to remain fully independent in operating solutions. Generally, this approach can work for one-off initiatives or single-user applications with low levels of architectural complexity. However, for applications with more complex requirements around data infrastructure (e.g., large datasets, multi-tenancy) or information security (e.g., client data segregation), building software independently outside of the consulting company's existing digital ecosystem may present a number of risks or feasibility concerns.
3. Hybrid model — the central technology team can own infrastructure and maintenance functions, while product development happens in a more decentralized fashion.

3 most common challenges in digitizing assets

Talent 

Consulting companies have to figure out how to attract the brightest technologists. Merely generating ideas is not enough; they need to create teams with strong product culture who can successfully execute those ideas — and eventually, build enterprise-grade software products.

How to find these talents depends on the:

• Function (engineer, product, etc.);
• Level of technological maturity;
• Scale of technology enablement efforts.

Internal recruitment can often be used as a solution when a consulting company has already created several technology teams and is looking to centralize the efforts. In this case, technologists can be motivated to join the central unit with the increased scope and visibility. This may not be a viable option if the consulting company is early in its technology enablement journey.

External recruitment can present some challenges. Highly qualified software engineering and product development specialists may not see a consulting company as the best environment for building their careers. Therefore, such companies may need to target those who are interested in building advanced analytics solutions in specific domains (such as healthcare). Another win-win opportunity is attracting talent with data analytics experience in small/mid-size consulting and data companies. Such professionals benefit from getting a recognized brand on their resume and expanding their scope, while the company brings in experienced specialists with highly relevant skills.

Operating model

Consulting companies must also understand how these new capabilities will fit their existing organizational structures. For example, they must choose between a centralized innovation hub model and a decentralized domain-specific model. 

We see several criteria that can inform this choice:

Product strategy. If a consulting practice is looking to productize some of its IP, one of the first things to do is to understand product plans on short-, medium-, and long-term horizons. Indeed, if there's a single, one-off initiative, which will not require ongoing development, leveraging the central development team can be good enough. However, often a practice wants to be strategic about its technology enablement efforts and has a roadmap spanning many product initiatives. In that case, it might be worth investing in growing an internal technology team within the organizational unit. 

Domain-specific scope. For software products incorporating highly complex algorithms or large amounts of domain-specific knowledge, it is highly recommended that the product development team works closely with the subject-matter experts from the consulting teams. This way, all can understand the intricacies of the product workflow and business logic. However, when this logic can be easily formalized, or development effort doesn't require in-depth discussions between experts and developers, the centralized technology enablement model can be the right answer. 

Change-management and delivery. In most cases, it's not sufficient to build tooling and deliver it to the consulting team — instead, there needs to be a comprehensive change management effort. Who is going to operate the tools? What are the required skills for business users? Who is going to own the onboarding process and user education? For solutions with high levels of complexity, we see an argument for the decentralized approach, or at least a hybrid model when the product development team and business team collaborate closely throughout the cycle. 

Client service

Typically, clients of consulting companies expect to pay a fee driven mainly by the total number of billable hours. However, increasing digital product integration requires companies to revisit all aspects of their client-service model. One of the immediate implications is the evolution of the pricing models.

In some cases, the asset team operates independently from other practices, almost as a stand-alone business. Such units have their own clients (who are not necessarily clients for the traditional consulting services!) and a dedicated pricing model for direct billing. It may be a monthly or annual fee for subscription-based services or a fixed price for bespoke  projects. 

More common, however, are the delivery models with assets embedded into the existing consulting practice. Consulting teams work closely with the asset team as part of the client engagement. In that case, measuring the contribution or impact of a solution becomes more complicated. There are two possible configurations:

1. Consulting teams cover the marginal costs of running or deploying assets but don't bill clients directly. The cost of a solution goes against the project margin but is recognized as internal revenue for the asset team. The underlying belief is that offering an asset at no additional price will lead to more client conversations, eventually translating into engagement fees. This model is beneficial because of its low complexity and transparent pricing for clients, but the internal chargeback mechanism increases the operating overheads for consulting teams. 
2. Consulting teams bill clients explicitly for running or deploying solutions and pass through the fees to the teams who own them. This model can work well for mature assets or assets with clear value for clients, which typically implies that the teams have invested heavily in marketing the respective offering. Another condition is that asset delivery must be separated from the rest of the consulting scope, which may not be ideal from the overall client service standpoint. However, maintaining their own P&L allows asset teams to demonstrate value quickly and hence, secure investment for further growth and development. 

Best practices in building technology enablement functions

Consulting companies that lean towards a more centralized approach must be wary of the internal "development shop" mentality. The biggest problem with this model is that the development team is seen as “mercenaries” who are under contract to build what they are told to. They have a limited understanding of the business context and don't have much sense of empowerment to participate in discussions around product choices, let alone question them.

Technologists need to be closely related to their business partners because otherwise, they will not be able to develop sufficient domain expertise to create effective solutions. Furthermore, the "client-vendor" relationship between business and development functions has become a common anti-pattern in the software development world. 

However, we do see an opportunity for a centralized technology-enablement team to support various platform capabilities. For example, user authentication is a standard use case across a wide range of applications. For that reason, it should be centrally owned and maintained, minimizing instances of "reinventing the wheel".

Finally, it is essential to recognize when a product offering is mature enough to be spun off into a dedicated organizational unit or practice. At its early stage, consulting leadership should understand the revenue-generating potential and support the growth and accountability using a dedicated P&L. It is common for partners in consulting firms to view  such offerings as a free add-on to consulting engagements, which can have limiting  effects on growth.

Suppose the consulting company has recognized the product-based offering based on its potential impact for clients and has successfully marketed it as a stand-alone product. On the stage, it is fairly reasonable to create a dedicated organizational unit to support its client delivery. However, when a product offering has yet to be launched, and there is uncertainty around its potential, it may not be a clear-cut decision. In this case, consulting practice may use an MVP-first approach — build a small team of product development specialists and subject-matter experts who can create a small prototype, deploy it to a few clients and measure the results.