Michael,

I listened to your podcasts about McKinsey, BCG et al versus the so-called second-tier of Deloitte, Accenture etc.

My focus is IT strategy and I have offers from both McKinsey and Deloitte IT in the North-Eastern USA. I am obviously keen to take McKinsey but I have had coffee chats with the partners from Deloitte and seem to be doing much more strategic and exciting work than McKinsey. The people are also great and went to some amazing schools. The Deloitte recruiting partner is also Harvard alum and I cannot see any differences between her and the McKinsey partners

Maybe you could shed some light on how this decision should be made?

Alex

***

Hi Alex,

Thank you for your email.

I am going to respond to your email in several ways. First, I am going to walk you through an IT strategy engagement which I led as a Principal when I was at BBM. As always, expect lots of details. Second, I want to talk through the differences between BBM and Deloitte on IT strategy and finally, in third place, I want to offer some questions you can ask Deloitte and McKinsey to expose some of the differences I will explore.

In general, it is better not to use the term tier-2 since it is derogatory and the differences between the firms are not that one is good or bad, they just do things in different ways.

I led a few IT strategy projects when I was a principal and worked on one both as a consultant and engagement manager. Moreover, when I left BBM as a principal both Deloitte and Accenture offered me full partner positions. Deloitte S&O designates their full partners as Principals, and I spent a good deal of time having discussions with the corporate strategy and IT strategy guys in the San Francisco think-tanks.

I declined for reasons I will explain and ended up taking over and managing a boutique strategy firm of 300 people across 14 offices, which we then grew and merged with a Fortune 500 company to serve as their internal strategy team.

When I ran the boutique firm, my strategy was to avoid China, USA and Europe. At the time everyone was smitten with China and wanted to be there. From my BBM time, I knew the economics of Chinese projects were not great and it would take an enormous amount of resources to build a presence in China. Resources a 300-person firm does not have, assuming they want to do great work, and really, was China going to disappear in 5 years? No. So we had time to get there.

My strategy was to target Central Asia for a variety of reasons.

First, I knew first hand that BCG was not as established in the region, which is a massive and highly fragmented region. Nor was McKinsey actively seeking to build a presence.

Second, it played to my and the boutiques strength in banking, utilities and resources.

Third, it was a very relationship-driven region where knowing someone could open more doors then having the right brand and I believed that was my strength and that of the other partners.

The reason I discuss Central Asia is because the IT strategy project I want to discuss is one I did in the region, while I was in BBM. It was for a large integrated power utility. Most of my IT strategy experience, not much might I add since I was in corporate strategy, was in utilities and banking so I will draw some lessons across sectors.

Overview of an IT Strategy Study

The context of IT strategy projects for large integrated utilities is sadly consistent around the world, though broadly different between developed and developing world utilities. We were brought in to help the national utility of a larger Central Asian country. It was a behemoth and moved like one. Some of those dreary offices also smelled like one. The integrated dinosaur pumped out 90% of the country’s electricity and 38% of the regions electricity.

With no plan in place, IT developed as crises appeared and 15 years later, when the new CEO decided to reorganize the company and pulled back the blinds on this department, he was surprised by what he found.

It had generation, transmission and distribution arms and operated coal, hydro and nuclear power plants. Most of the assets were antiquated and the last new facility had been built in the 1969 and one power plant actually stood incomplete having lost funding when the Soviet Union collapsed at the end of the 1980’s. The problem at the company was that IT had evolved to respond to the needs of the utility. With no plan in place, IT developed as crises appeared and 15 years later, when the new CEO decided to reorganize the company and pulled back the blinds on this department, he was surprised by what he found.

First, no one could define the IT department. It did many things but no one person could explain what they were. There was no formal structure in place, no teams with designated roles and no formal leadership. The head of IT was a nice guy – how bad can a guy really be when he offers you vodka at every meeting – but he had no control over what he ran.

Second, the IT department ran the grid control for some of the southern power plants. Grid control is not an IT issue. It is an engineering problem managed by systems control specialists. In other words, where IT started and ended was not clear. This is a big problem since the competencies to manager IT systems are diametrically opposite to running systems control. Sadly, a common problem in just about every utility I have seen.

Third, IT did not have a budget. I unfortunately remember the agony of pushing the consultant leading this analysis to go out and build me a budget. It was hard and painful, working off data that just did not exist and needed to be constructed from invoices and payment improperly filed.

Fourth, like any aging asset, performance issues had slowly crept up over the last few years. They were now getting to be catastrophic. You had a situation where the engineers where blaming IT for the problem and IT agreeing. In one memorable case, the head of IT agreed their engineers were at fault for a distribution problem at a plant. How can IT possibly be responsible for an engineering problem at the plant? Even if by some strange accountability issue IT was managing this asset, they should have been doing so.

However, IT had no personnel at that plant and it was a maintenance issues on transformers. In effect, no one knew enough to call out the right people for right real issues and IT management seemed to be under siege and unwilling or unable to respond.

And if he refused to spend the money where they wanted it spent, he would not get it. So he ended up taking the money and spending it in an uncoordinated manner since the line divisions where uncoordinated.

Finally, fifth, IT was badly governed. The nominal head of IT was appointed by representatives from each of the line divisions. He had no budget and needed to get separate budget requisitions approved from each department. The man spent half his life trying to get $5,000 from person x, $2,000 from person y and $10,000 from person z just to buy proper equipment. And if he refused to spend the money where they wanted it spent, he would not get it. So he ended up taking the money and spending it in an uncoordinated manner since the line divisions where uncoordinated.

At the time, as a youngish principal, I took the assignment since I wanted to go to someplace very exciting, but also work under a senior partner who would afford me greater latitude to get things done. As a completely new client of the firm, I also saw it as a chance to do something truly unique, and that is rare in management consulting. Typically, principals work with clients where the senior partner has a long-standing relationship and much work has already been done for the client.

I was able to assemble my own crack team for the engagement; managers, associates and consultants I had used on many previous engagements and whom I had personally trained. I have very high expectations of people and train them well. Many, many partners would send people to work with me just to ensure they were well drilled on the core areas of management consulting.

The phrase “strategy boot camp” was used more than once and I will take that as a compliment. Yet, more than the basics, I trained people to be able to parachute in and hit the ground running. I am the kind of person who feels it is completely normal to call an associate at 3pm on a Saturday and have a 40 minute call about a piece of analyses. My team learned their phones can never be off – ever.

So, I had a great team and grand problem. Despite the size of this utility and the numerous issues at play, I summarized them down to the four above. The CEO had a list of 21 issues, but I felt many were derivatives of the same theme. Therefore I structured the team in the following manner:

Governance: we needed to get a handle for how the IT department was presently run and how it should be run. Governance is not a theoretical construct. Some refer to this work as organizational design, but to me, governance is a better word since one builds a structure to improve governance and results. This was a tough area of analyses as well since it required understanding the organizational structure, decisions required, processes used in the decisions and management of the department. I had a great consultant leading this: super friendly and super smart.

Financial analyses: it is rather impossible to develop any strategy without financial analyses. This was a tough stream as well. The company’s financial statements were an absolute mess. Numbers we wanted were just not available. Moreover, a lot needed to be done here. The financials for the department had to be constructed and analyzed.

Thereafter the financials needed to be benchmarked against peers and finally an IT investment process had to be developed. A really nice young lady from INSEAD was running with this whom I personally liked a lot, but from performance discussions, knew had had troubles on other engagements. I pretended like she was a star – it is amazing what people will do if they think you have high expectations of them. You over delivered on this and was a star in the study.

Strategy: it is unusual to have a work stream called strategy but I wanted to understand how the business strategy should pull the IT strategy. So I had this area led by a talented Wharton graduate who was also quite funny since he wore bow ties to the office. He had a tough job to do since the IT strategy could only be built to support the corporate strategy and he needed to flesh this out even though the CEO was not exactly sure what this could be, and it would likely even change over time. Not the easiest job in the world, and it lent itself to scope creep since the CEO could easily have asked him to help with the corporate strategy work. I had to step in a few times to prevent this, and of course, we did do the corporate strategy work shortly thereafter, which was a separate study.

Market analyses: was an area I insisted we have and have it well staffed. My belief was that there was layers of uncertainty we needed to pin down. Yes, the corporate strategy was fluid, but that corporate strategy was fluid because no one really knew what legislation was coming down the pipeline, who would be building station and how the market would be regulated.

We needed to understand this, and look at how other countries/utilities had evolved down the same path. It always shocks me how few people actually read the items on which they have emotional opinions. This was no different. In a think-tank of 12 PhD’s advising the CEO, not a single person had actually read the pending energy legislation, but of course, everyone had an opinion.

And then there was me. My strengths have always been communication skills, ability to know all the numbers and tie it to the big picture, an important skill discussed more here, and the ability to make friends with literally anyone. In fact, the firm used to send me into engagements where they were having difficulties with tough clients. I tended to have a way to bond with people, generally because I tend to leave my ego at the door and avoid judging people. Even when clients screamed at me, I would find a way to turn things around, quickly and painlessly. In fact, my closest friends today tend to be clients who were painfully difficult in the past.

On any engagement I always find out what the firm considers to be the best work ever done in that sector or function. I hunt down the study and people involved and make sure they spend time with my team and I discussing what had gone well or poorly in the previous study. No matter what people say, something always went wrong and I want to avoid that.

I then sit the team down and we decide how we will raise the bar on this earlier study. It is not about doing more, but about the impact we will have. Sometimes we fail to achieve this goal and fail miserably. Yet, the bar has been set so high that even failure looks like success to someone looking in.

Unlike most principals, I tend to take a very active role upfront. I spend a lot of time with each team member discussing their plans, setting clear expectations and reviewing work. I recalled my own experiences with partners who would only give you time after you had reached a roadblock or failed. I did not want that to happen to my team for several reasons. If an engagement is set up well, the rest will go smoothly, thereby freeing me up to focus on the strategy issues.

You also cannot plan everything in a study. You should always expect that something will happen for which you have never planned and discipline early in the engagement creates additional time later to deal with these issues. Finally, the best way to teach someone is to directly work with them. My role was to develop managers, associates and consultants and that was best done via personal interaction.

Differences between McKinsey and Deloitte

In talking through how I ran this engagement, I want to draw contrasts to what I saw as the differences at Deloitte and Accenture when I discussed a leadership role at these firms. I will draw a few contrasts to Accenture as well since they were doing a system implementation pilot at the utility. Though, I am wary of drawing too many conclusions from just this one Accenture engagement.

There are many significant differences between Deloitte/Accenture and McKinsey et al which are covered extensively in previous posts, podcasts and videos. I will merely focus on the IT strategy differences here, though they will be similar in other parts of the organization as well.

The first difference relates to the way people had been trained. While I knew most of my team well, the young lady leading the financial analyses was new to me and from the French office. She had worked in different regions, sectors and with different partners. She had completely different experiences from me. However, when we sat down to discuss the financial analyses; it was as if we had known each other for years. She spoke the same language, had the same approach to breaking down the financials, was easily able to brainstorm out the issues and construct a rough storyboard all in a 60 minute meeting over coffee.

This is a huge difference between McKinsey and BCG versus most other firms, especially Deloitte and Accenture. Consultants are trained to the same exacting standards worldwide. This makes it ridiculously easy to assemble a team and send them in. They are trained to work together seamlessly thereby increasing the international staffing on engagements, and reducing conflicts between offices.

Ironically, when he said firm, he meant just the US partnership. As a federation of practices which are legally independent, Deloitte is unable to enforce the same standards across regions, and this leads to differences in training, expectations and performance: perfect setting for the second difference.

On the other hand, I recall a Deloitte Principal clearly telling me that they were not keen to pursue work in Mexico, from California, since the Mexican Technology team was not as well trained in that region and it would hurt the firm’s reputation to do the work.

Ironically, when he said firm, he meant just the US partnership. As a federation of practices which are legally independent, Deloitte is unable to enforce the same standards across regions, and this leads to differences in training, expectations and performance: perfect setting for the second difference.

The second difference is that technology at Deloitte is just one arm of Consulting. Deloitte S&O, the rough equivalent to BCG, is another and separate arm run completely differently. At BCG, all consultants are hired in the same manner and to the same standards, and trained in the same way. They are first and foremost, a BCG consultant. Specialization be damned.

So let’s play this out. When I, a corporate strategy principal, meets an IT-sector focused manager, I do not treat him differently. I treat him the same because I know he had to meet the same hiring standards as everyone else, he was trained the same as everyone and he could easily be on a strategy engagement but chose to specialize in IT. There is mutual respect.

Do you have any idea how long it takes someone to understand hypotheses, decision trees etc.? Why would a technologist who does not even need to know these things, respect and or even follow them?

Deloitte S&O has its own hiring approach which is broadly case-based and sometimes involves written cases as well. It is a measured process. Deloitte Technology has its own recruitment process which wildly differs across regions and even within the US. Technology is bringing in coders who sit for weeks on end writing code and at the same time they bring in more general IT specialist. The former is absolutely important but is not the attribute of a successful management consultant. And yet these two wildly differing groups are expected to not only work together seamlessly, but also respect each other. It does work out that way, even though I think Deloitte has made a lot of strides in this area, and some firms like McKinsey and Booz have actually tried to emulate them in this regard.

Imagine putting these two groups together to work on an IT strategy engagement. Do you have any idea how long it takes someone to understand hypotheses, decision trees etc.? Why would a technologist who does not even need to know these things, respect and or even follow them? And let’s be honest, most MBA’s have a huge ego which cost them anywhere from $200K to $400K to attain, depending on the school they attended. How in the world will they even respect the important strengths the technologists will bring to the table?

I sat in such discussions with the technologists and MBA’s and I thought I had stepped into a time machine and was back in high school with the different cliques. This brings me to the third point.

Deloitte and Accenture believe they are better than BCG and McKinsey on IT strategy because they have these technical skills. It is their belief and it is no point debating with them since they have a religious fervor about it. Their major point of differentiation is that they can physically code, understand hardware implementation, therefore understand the technical/implementation issues and this makes them better at IT strategy.

There are three fundamental problems with this line of reasoning.

First, technologists cannot always do strategy since they are not trained to do so. I believe history is replete with such examples. I did not have to work in a utility or bank to do corporate strategy work at a bank.

Second, having experience in an IT issue merely means you were exposed to an idea. It does not mean you can analyses and develop a concept. The latter skill is far more important since all clients are different and one should never apply solutions from prior clients.

Third, I have seen the Deloitte S&O and Technology teams “work” together. It is a symphony of cacophony and mistrust. They do not even work in the same room together.

When Deloitte says they can deploy combined strategy and technology skills for clients, let me translate what that means: they will place 1 or 2 business case analysts from S&O to develop the business case for a system implementation. A business case is not strategy. Moreover, I have yet to see such a business case team actually conclude there is no case for the system. There is inherent bias at times and I am sure lots of pressure to “sell” the more lucrative implementation work.

The fourth difference is the definition of IT strategy at Deloitte and Accenture. The first time I asked a Deloitte Senior Manager, over coffee and while I was exploring taking the role, to explain IT strategy he went into this long and confusing soliloquy involving several confusing charts, diagrams and explanations.

There is a simple, clean and crisp definition for IT strategy: it is the organizational structure, resources and skills needed by the IT department to explicitly help the company achieve its corporate strategy/objectives. You can add in processes if you want but I think we are then moving to operations.

The Accenture guys were no different.

Let’s be clear about this. There is a simple, clean and crisp definition for IT strategy: it is the organizational structure, resources and skills needed by the IT department to explicitly help the company achieve its corporate strategy/objectives. You can add in processes if you want but I think we are then moving to operations.

With that simple definition, IT strategy becomes ridiculously easy. Though, I was once told by an Accenture person that it was clear I was in corporate strategy, since my definition subsumes IT strategy to supporting the corporate strategy. In my mind, everything supports the corporate strategy, and if it does not, it should be changed, sold or fired.

Ironically, this painfully simple definition for IT strategy originates from an Accenture partner, who eventually went to Bain.

That said, he got the idea from an IT professor called Venkatraman who got the idea from IBM, who developed the idea from Cap Gemini Sogeti. Good ideas know no boundaries.

The fifth difference was alluded to earlier but I will explicitly state it here. If S&O and Technology cannot get along, how in the world can they work together seamlessly when they do not even speak the same language, or change tack as a team as the findings change. They cannot.

BCG teams work like a school of fish. They are so well trained that even though they may never agree everything up front, we will 9 times out of 10, move in the same direction when presented with data. Each area of analyses is feeding the other and updates must be communicated to allow each team member to adjust.

The idea of doing a business case which is never going to disqualify an IT implementation is now so common that even clients do not question it.

I recalled speaking to a technology senior manager explaining to me how easily Deloitte managed projects since he had 2 weeks to complete his systems study and then hand it to the S&O manager to put in his slides into the presentation. He had no hypotheses to work with, did not see any reason to update the project team often – which probably said something about the quality of his analyses – and did not believe anything needed to be changed in his work. No iterations, no storyboard, painful formatting and a final slide deck which looked like it came from two companies; it did – S&O and Technology.

Finally, I want to discuss conflicts. The idea of doing a business case which is never going to disqualify an IT implementation is now so common that even clients do not question it. They should. My problem is the business model. Implementation projects for Deloitte and Accenture pay far more fees than an S&O engagement would. S&O partners are remunerated on firm wide performance.

Finally, distinguish between what is strategic and what is strategy. Installing a sewage system in New York was a strategic decision by the then mayor to make the city more appealing vis-à-vis London. As strategic as this decision was, I think we can all agree that the installation itself was not strategy. It was engineering. Strategic projects are not strategy projects.

Why would they not recommend an implementation when not doing so will directly hit their pockets? Even if they could, would the technology partners allow it? Would the firm allow it? Would Deloitte S&O be willing to upset a client with the correct recommendation, at the risk of jeopardizing an IT implementation?

Things to ask an interviewer

When speaking to BCG, Deloitte, and McKinsey etc. people, it is wise to focus on a few questions:

• Where do alum’s typically end up when they eventually leave?

• Since I am a strategist, but just in IT for now, how often do I do strategy work in other areas?

• How are new consultants trained in hypotheses, brainstorming, storyboarding etc.?

• How do you ensure alignment with the technology teams who are not necessarily trained in hypotheses, brainstorming, storyboarding, but with whom we work?

Jeff, make a choice based on what you want to do in life in the long term. BCG and McKinsey are finishing schools for executives. Deloitte and Accenture are excellent at what they do, but do different things and teach you a different way to accomplish these tasks.

Finally, distinguish between what is strategic and what is strategy. Installing a sewage system in New York was a strategic decision by the then mayor to make the city more appealing vis-à-vis London. As strategic as this decision was, I think we can all agree that the installation itself was not strategy. It was engineering. Strategic projects are not strategy projects.