In a prior post, I set a backdrop on some posts I would do on management consulting. The first topic will try to capture some styles of building the solution (I call these underlying flavors of management consulting).
In Ethan Rasiel’s book, "The McKinsey Way," he outlines the problem solving process as having three attributes:
- Fact-based
- Rigidly structured
- Hypothesis-driven
Fact-based consulting is something that the majority of top, traditional management consulting firms practice. It is something I practice now and had practiced while at Pittiglio Rabin Todd & McGrath (PRTM). Fact-based consulting requires a lot of legwork to gather data, interview information, reports, benchmarks, etc., but it is about the only thing one can rely on to build an iron-clad case for a company. It provides value to clients because clients sometimes learn things they did not know collectively as a group. It also provides value to the consultant because in many cases, while the consultant may know less about the specific operations of the client, the consultant can draw on new facts gathered and experiences of working with other companies (or benchmark data).
On the second point of being rigidly structured, Rasiel’s book talks about the pervasive McKinsey thought structure of MECE (pronounced "me-see"), which stands for "mutually exclusive, collectively exhaustive". I like this structure. It reminds me of core computer programming techniques of case statements and engineering analysis related to breaking down larger chunks into orthogonal and comprehensive components.
Now McKinsey tends to be more of a generalist strategy firm than PRTM or the type of consulting I practice. In general strategy consulting firms, consultants may work in a wide varieties of industries before specializing. Thus, at firms like McKinsey, one could be working on a dog food manufacturer on one project, a valve manufacturer on another, a financial services market entry project, etc. McKinsey clearly has more detailed consulting frameworks for attacking problems, but MECE seems to be a good core framework.
Management consulting firms like PRTM, on the other hand, have historically had a different structure. In part, it is because PRTM is less than 1/10 of the size of McKinsey (say 350ish consultants versus 4500ish [don’t quote me on exact numbers]). In the Eastern region of PRTM, consultants join a practice in a particular industry space, and they are usually expected to have experience in that space prior to business school. While I was at PRTM, I was in a sector that covered telecommunications companies, and to a lesser extent, companies in the software space. PRTM tends to have management consultants that have both science or engineering degrees, plus an MBA from a top-tier business school. If you didn’t have some of this background, you’d better be an exceptional leader and client driver (times two at least). On top of having less of a generalist structure, PRTM has historically fortified around three functional areas: product development, operations and supply chain management, and customer service operations. Over the years, PRTM has expanded and fortified around strategy, marketing and sales, and strategic IT management (see home splash page), but it has grown out of the core competencies in the three first areas I mentioned (more or less). These are the core aspects of high-tech firms anyway, right? How all of this affects the problem solving structure for PRTMers, is that the consulting method tends to de-emphasize intellectually-driven approaches and focuses more on a core motto of "results not reports". What this means is that PRTM consultants are more focused on being facilitators and leaders of client projects and less intellectually-driven. This is not to say that that PRTMers are not intellectual and smart – most certainly they are – it’s just that when the rubber hits the road, if push comes to shove, consultants would probably throw a report out the door in favor of helping a client move forward with results that stick. Pragmatism over intellectualism.
I should note that in Rasiel’s book, he does indicate that it is best practices for McKinsey consultants to only make recommendations that can be implemented based on client capabilities, bandwidth, etc. – "all roads lead to Rome" so to speak in my book when it comes to providing quality consulting services. I just wanted to point out the difference in flavor between the two firms. FWIW – I tend towards being a pragmatic person, but I have a wife who is both an academic and former consultant with ZS Associates. I’ll let you decide what style of consulting I practice.
On the final point of being hypothesis-driven (i.e., developing formulations of what the options are for improving the business), what struck me about Rasiel’s depiction of McKinsey was how front-loaded the process was in terms of brainstorming and coming up with hypotheses. Some of the team sizes were characterized as quite large, but more importantly, the intensity of the up-front process was striking. In essence, developing the hypotheses in an exhaustive roadmap and then being able to test each branch is very methodical. It also reminds me of a core team under pressure type model that breeds excellence.
People probably have differing experiences at PRTM. From my experience, I would say that we typically either had a core framework in advance of the project (e.g., improving product development cycle-time) as a baseline or used more of a facilitative approach to working with the client to determine the best way to proceed. Hypothesis testing was more typically pursued slightly later during project execution. I would say that this probably has more to do with the fact that the majority of the PRTM projects I worked on were implementation-oriented or strategy + implementation-oriented. At McKinsey, the firm historically grew out of strategy into more strategy + implementation projects.
In any case, some of the differences seem to stem from both market & product focus and where the companies came from. Worthwhile to be aware of when considering these firms (e.g., as an employer). May also shed some light for companies that are looking to use management consultants (i.e., is there a particular style that will serve your specific situation better?).
Steve Shu
