Outsourcing

Don't fall in love (with your methodology)

No methodology is a magic talisman that can ward off optimistic schedules or lack of stakeholder support.

Having spent most of my career in consulting or around large IT projects, I've sat in many a meeting where methodologies were reverently discussed. For the uninitiated, a methodology is little more than a certain way of performing a task, often with associated tools ranging from document templates to software packages and mathematical formulas.

I recall nearly giggling when I sat through a sales pitch from a marquee consulting firm (the fourth such firm that day) where their methodology was breathlessly discussed as a "key market differentiator." Despite a different series of acronyms and terminology, it was the same as all the others, and all were merely a couple of steps from a standard waterfall methodology. I've witnessed the same thing with clients, especially where the methodology under discussion had been successful in the past. With each successful project, the company grew increasingly cocky, as if the methodology were some sort of magic talisman that could ward off overly optimistic schedules, lack of stakeholder support, or a half-baked system that barely accounted for the business unit being affected.

When all you have is a hammer...

We've all heard the old quip that if the only tool you have is a hammer, then every problem looks like a nail. Methodologies are similar in that they are merely tools to help you accomplish an end. While it seems superficially silly that an organization could fall so deeply in love with a methodology that they forget the problem being solved, it becomes far more likely once millions have been spent on training and certification, and there is a cadre of mysteriously-named practitioners roaming about looking for problems to solve.

Tools from Agile to Six Sigma can be extremely effective, but are not relevant to each and every business or technical problem your organization will face. The flaws of the major methodologies are reasonably well-documented, and it's worth knowing the situations where your preferred tool is suboptimal or even irrelevant. Just as your developers carefully consider the programming languages and technologies they'll deploy to solve a problem, and occasionally abandon their usual tools when appropriate, your organization should have the flexibility to do the same with its methodologies.

Beware the one-trick pony

Some of the most guilty organizations are consulting and implementation providers, who tend to fall head over heels for their methodologies, which then frequently end up being oversold while under-delivering. If your partner wants to tell you more about their fantastic methodology than how they'll solve your business or technical challenge, run for the doors. If the partner can explain their approach in the context of your particular challenge and seems willing to employ alternate approaches should their preferred plan go astray, that's the type of partner you want on your team.

Furthermore, the primary purpose of a methodology is to provide guidance and shortcuts to a repetitive process. If you were sold on a methodology saving weeks of billable time, then find your partners reinventing the wheel at each turn, you're missing one of the primary benefits of working with a partner. That amazing proprietary methodology isn't all that amazing if your partner is recreating templates and spending hours "checking the boxes" rather than solving the problem at hand.

Most teams and organizations have grown better at the formative stages of a new project, spending the time to craft a business case or define outcomes and put some thought into resources and planning. Make choosing the right methodology part of this process, and allow for your preferred toolset to be modified and enhanced when circumstances dictate. Like a craftsman, there will be times when a favored tool just won't work and you'll need to grab a dusty implement from the toolbox, head to the store for a new gadget, or improvise with what you have available.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

6 comments
csudholz
csudholz

Methodology is is the study of methods, I think you are referring rather, to the use of methods. To quote from Patrick Dunleavy's book Authoring a PhD, Cht 5 - Writing Clearly, page 117: "Many people routinely substitute longer noun forms of words where they could use short verb forms. They choose complex forms of words which sound more abstruse, for very little reason. For instance, 'methodology' means the science or study of methods, but many use it just to replace 'method' itself, because it seems to give a more 'professional' feel to do so."

shannon
shannon

All good comments. Some organizations definitely worship and/or hide behind their methodologies. On the flip side, I am amazed at how many organizations I see today that have no plan or process for doing their work. There is this notion that process "adds too much bureaucracy" so they are just not going to have any. In effect, they fly-by-the-seat-of-the-pants. Shannon Gaw http://itmgr.org http://theITmanager.org

cdasso45
cdasso45

.......not the methodology. Of course initiatives have to be managed for all the reasons we are all aware of. As a long time (20+ years) independent consultant and now director of development and enterprise architecture, my experience has always been from a problem solution perspective. The alphabet soup of methodology certifications are practically meaningless if you don't know what you are solving nor how. Certainly managing the solution throughout its life cycle is important and it is typically some variation of your past initiatives.

WasabiMac
WasabiMac

The government agency I am with just signed on with a major IT support provider who had a lot of experience with DoD facilities. Turns out we don't operate like DoD, and all of out centers are not equally equipped or have the same mission focus, resulting in a fairly varied configuration. It has crippled the service for months. While we are plodding forward, it is incredibly painful for the users. Had the contractor effectively sampled the sites and users they would have seen the differences. And on the other hand, the agency should have looked at the proposal more closely and realized the issues as well. They both seem to have been blinded by the pretty charts and all the ITIL verbage in the proposal processes. "Oversold while under-delivering" is a perfect summary of the quagmire we're in. But ultimately, the people who hire the support are the ones accountable for the problems unless there was true misrepresentation or fraud. So before you or your people sign the contract, be sure you and the contractor understand how your organization works and how your users are allowed/expected to operate.

Odipides
Odipides

The biggest problem I've had hasn't been my own bigotry about whatever method I use but when a completely inappropriate framework is foisted on the development team because some senior manager has been 'sold' on it at a conference.

Editor's Picks