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.