Tuesday, June 01, 2004


Methodologies Part 1

In the perpetual quest to add value and differentiate themselves from other firms covering the same beat, the Powerpoint artists will trot out the dreaded methodology. Most methodologies proffered by consultants are fungible commodities, basically convering Scope, Analyze, Design, Build and Implement phases using varying terminologies, frequently swapping the scope and analysis phases in the sequence (no doubt to make sure the hooks are planted), and always with a liberal amount of risk management activities that seem to cover everything other than the risk to the client.Not that there isn't some good stuff in these methodologies, but frequently the real world aspects of the project will supersede the pedantic approach ordained. Most people tasked with large or high-visibility projects are pragmatic folk who know what's needed to accomplish the overall goal, but when the higher-ups ordain the methodology, all hell breaks loose.

Let us consider the history of a methodology peddled for years. To protect the innocent, I'll give it the pseudonym of Immanent (Sidebar - I don't mean the word "imminent", meaning impending. "Immanent" means "inherent" or "intrinsic". Readers of bumper stickers and William F. Buckley will recognize this setup). It was considered an important rite of passage upon joining the firm to become conversant in Immanent. The most respected consultants would be seen with the little binder containing Immanent visible from their open briefcases. There was only one teeny problem in that Immanent looked like it would work well for a complete "green field" project, but using any of its various approaches (which in graphic form bore a suspicious resemblance to either a board game or lower digestive anatomy) would quickly run afoul of little things like production and regulatory requirements for any sort of project that needed to integrate with real running systems and processes.

Of course, the continuous mantra was to "Immanentize" (told you it was a belabored setup!) any projects that we were associated with. Regardless of whether it was an assessment, infrastructure deployment, or other project that was fairly irrelevant to the methodology, if the person whose P&L the project resided on demanded that the project be "Immanentized", you had darned well better Immanntize the project plan, even if it made absolutely no sense. Given that most project plans were filled with lots of marginal activities and tasks to puff them up to the point of being a step-by-step checklist, the net result was projects that bordered on incoherent.

An additional wrinkle came along where Immanent was sunsetted into a product I'll call "Immanent Mark 2" as a result of corporate machinations and realignments that I'll go into in another thread. Immanent Mark 2 actually had the Immanent content in it, but it was well hidden and the implication was that it was deprecated in favor of Mark 2, with even less versimilitude. To the best of my knowledge, Immanent was sold to a number of customers (and therein lies the next installment), but Immanent Mark 2 was a relative flop, but we still had to Immanentize even if the relevance was nil.


<< Home

This page is powered by Blogger. Isn't yours?

Technorati search