Why IT Consulting as we knew it is gone

Part I can be found here

Before I make a deep dive into what are (IMHO) the most promising areas to contribute for modern IT Consulting, let me finish my list of key differences between the way consultants used to work few years ago & what's expected today:

Decomposition (of systems, of projects, etc.)

10 years ago all-in-one, complex end-to-end combined solutions were the way to go. And it really made sense due to problems with integration (mentioned in previous points), non-uniform architectures / platforms & varying skill sets to run them. The effect was quite obvious - once you've set up something, it was damn hard to get rid of it or even make a meaningful change: it usually ended in a huge project. Existing vendors had no motivation to change that as this situation was both setting a high entry threshold for competition & locking clients in a long-deal traps.

But it's all PAST now:

This situation just HAD to change. Companies NEED much higher agility & velocity in shaping the parts of IT landscape that are related to their core business domain. They don't want the same key systems / apps half of the world is already using, they need IT systems to not fall behind consantly evolving business ideas. Defragmentation just had to happen - service-oriented paradigm (if applied in a proper way) supports making changes in one system (even complete replacement) non-disruptive & barely noticeable to the rest of landscape.
Huge effect with small effort

If you check the software development tools, platforms & practices from 00s - they were nothing like what we have at our disposal today. Bare metal, on-premise infrastructure that took ages to obtain & set-up; manual deployment, integration & test processes; slow IDEs, verbose programming languages, clunky middle-ware, lack of utility libraries but the most basic ones. With such a low productivity all what managers cared was repeatability & predictability of sustained development - the ideal model was to standardize windows / forms / screens & produce one by one using the same patterns, activities, actions. The goal was to make the code as trivial as possible (even sacrificing maintainability, etc.), so even the army of monkeys could write it. As a result, you had to get a real army (in terms of shear numbers) to do it.

But it's all PAST now:

Infrastructure is not a problem anymore. Social coding & open sources has brought unimaginable quantity of libraries / frameworks to use (no need to write boilerplate on your own). Modern tools & IDEs are top-notch masterpieces - the best products of software development on the planet, all at your disposal & much more affordable than ever. As a result, a small group (~10) of motivated people can deliver much faster & much better products than whole 'army' before. 'Army' was not affordable by every company (so they needed consultants), while 1-2 teams easily are.
Project VS Product (maintainability)

History of IT development in large enterprises is marked with projects. Each of them was a huge leap with a set purpose, shitloads of scheduled activities followed with some memorable "death-marches" & a long, painful process of accommodation changes within the organization. Each such cycle ended with a period of atonement (aka stabilization), when everyone was recovering strength for the next leap. What is more, this stabilization period was the first opportunity to find out the actual effects of transformation - did we actually achieved the assumed (prayed for) effect or not really? This was a model that suited well the mercenaries: come here for the job, do your stuff in assumed period of time & then "so long", mission accomplished (sort of).

But it's all PAST now:

Companies have learned to think in categories of products instead of projects. They've learned the costs of technical debt & flawed or omitted maintainability. Kanban & the theory of constraints ain't the black magic anymore -> modern companies don't want mercenaries for a one-shot job to clean for them afterwards. Team doing software development should feel fully responsible for the product and all its aspect - deployment, maintainability, openness for future changes. Such a team is effectively contributing (in a creative way) to the vision and shape of the product. Not just for now, but also for near & far future.

As you can imagine, it's far more tricky to write it down within a contract ;P
Methodologies are dead, long live expert practitioners

In Golden Age of IT Consulting, such companies were being brought aboard due to their own, proprietary methodologies. Consultants armed with tons of diagrams, spreadsheets & red books that have described the every step to finish the project in a successful manner were the guarantee of final success. The highest level executives preferred that way, because it was the safest (proven) option - the largest the consulting companies, the more clients have tested those methods in action. As a result, IT Consulting companies were employing smart generalists, that could quickly jump into any kind of role using company-provided methods.

But it's all PAST now:

Spectrum of IT development endeavours is much wider than ever before. The industry is evolving with an incredible speed as well. In such conditions every attempt to create formal, 'carved-in-stone' detailed manuals is doomed since the very beginning. But that's not all - companies don't want local, fresh people with manuals written by remote experts (I've written about that here already) - they demand experts in person, to make sure that these people will not only follow the recipe, but will also be able to react & adapt to local conditions, due to their knowledge & experience. "Experts" with PowerPoint-based knowledge are no experts.
Burst of agile methods

Ol' good waterfall times were perfect for IT Consulting. Analyze, gather requirements, design the solution, break the stuff down to the smallest work item, write everything down, estimate accurately, put all the stuff in the contract, etc. Then after all the stuff is done (it's always done - consultants can't risk their reputation by not delivering), no one could question it: everything was complete as it was carved in the contract.

But it's all PAST now:

Agile is everywhere & some of its aspects are much harder (but still possible, ofc) in multi-company client <-> supplier scenario: embracing the change, distributed responsibility & decisiveness, less focus on formal documentation (& arrangements). But that's not all - many IT Consulting companies outsource development work to low-cost off-shore Delivery Centers. Such outsourcing has its inertia, relies on written, formal requirements & seriously cripples any chance for actual agility in the solution being shaped (which is a bread'n'butter of agile approach).