Reproduction permitted for personal use only. For reprints and reprint permission, contact

With tech implementations, it's NOT the methodology, stupid

Methodologies are often presented as the stuff of legends. Sit in any presentation by one of the large implementation companies, and by the fiftieth PowerPoint slide you'll likely be convinced that the methodology being presented will create a flawless implementation, nearly run itself, and eventually bring about world peace in our time.

Each company presents its methodology as unique and special. When they are questioned about the competition, images of six-year-old kids fighting on the playground still come to mind: "My methodology can beat up your methodology!"

Is there any method to all this methodology madness? On some level, a methodology plays an important part in any project. Similar to a road map, the methodology maps out what tasks should be completed during certain stages of the project's lifecycle, and should provide a “toolkit” of ready-made templates and skeleton plans to save reinventing the wheel.

Like maps however, different methods are more appropriate for different tasks. Just as you would not take a highly detailed topographic map for a drive across the country, any company advocating a “one methodology fits all” approach should immediately be regarded with an element of suspicion.

The dirty little secret in the implementation business is that all of these methodologies are nearly identical. Most are based on a standard Systems Development Lifecycle (SDLC) model, providing for well-defined and demarcated phases from planning and analysis to testing and implementation.
Again, returning to our map analogy, endlessly debating methodologies, or strongly advocating one “brand” over the other, is akin to arguing the merits of AAA versus Michelin road maps. While a methodology can provide a solid overall framework for a project, if you are not comfortable with the staff that will be provided for your project, or do not feel the implementation company has adequate skills, the best methodology cannot make up for shortcomings in these more important areas.

Again, if you're embarking on a road trip, the best maps in the world will not help if you have no car, driver's license, or gas.

Nuanced position

So what is one to do when comparing methodologies? All of them will sound reasonable, since they all are derived from the time-tested SDLC. However, there are some nuances to be aware of:

A huge advertised benefit of a large implementation company and its particular methodology is the “toolkit” component, with pre-delivered documentation to complement the steps outlined in the methodology. Ensure that this actually exists, and more importantly gets used on your project. When firms are billing at an hourly rate, there is a large incentive to “reinvent the wheel” on every project for the sake of increased billings or resource requirements, even when the company has likely completed similar templates on many previous engagements.

Understand that the methodology alone probably contributes to about three percent of the success of a project. The quality of decision making, talent of the implementer, project and program management, and a litany of other factors make far more difference. Do a little research and you will likely find no implementations that were successful based on methodology alone.

The other side of the coin is that if you find a vendor with particularly talented staff, extensive experience in your implementation area, and an excellent management team, do not let a weak methodology sales job weigh heavily on your decision. A sad fact of implementation life is that many of the components of a methodology will fall by the wayside when the going gets tough, and only excellent management and leadership will save the day.

If a potential implementation partner spends hours trumpeting their “proprietary” methodology while brushing aside questions around staffing or project experience, run quickly in the opposite direction. A methodology alone never makes for a successful implementation.

Previous articles by Patrick Gray

Patrick Gray: Fire your CIO? If he's not implementing strategy, show him the door

Patrick Gray: Five steps to buying the right package software

Patrick Gray is the founder and president of the Prevoyance Group, located in Harrison. N.Y. He focuses on providing information technology strategy consulting to organizations of all sizes, helping them use IT to generate measurable value. His first book, Breakthrough IT: Supercharging Organizational Value Through Technology, will be published this fall. He can be reached at

The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.

WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.


Robert T. Merrill responded 8 years ago: #1

The main premise of this article, that all software development methodologies are alike, is in error. It's not true in software, just like it's not true in manufacturing.

What's the difference between Toyota and GM?

One difference is how they approach product development, manufacturing, and subcontracting. Does it matter? You bet it does. Visit

The "time tested" waterfall SDLC, with "well-defined and demarcated phases from planning and analysis to testing and implementation" and centralized command and control, is the software equivalent of the Frederick Taylor style assembly line.

The agile methods, with their emphasis on short cycle times, frequent feedback, and as-needed planning and decisions, are the software equivalent of the Toyota Production System and Product Development processes.

I agree with the author that trustworthy and competent people trump methodology. But I also believe that buyers of implementation services need to know the difference between waterfall and iterative, and need to understand the risk profiles of both when planning a major project.

Robert T. Merrill
uFunctional LLC

Terry Dexter responded 8 years ago: #2

I must disagree with Mr. Merrill. Software development has taken enormous strides since the days of punch cards and human operators. Agile software development, for all its hype, is limited to unique user driven applications. Performance or load testing is virtually unheard of and configuration management is chaotic at best. I must ask if Mr. Merrill knows if the Toyota Assembly Line to which he alludes was developed by agile methods. One suspects it was not.

The Waterfall Model, in all of its various incarnations, has been proven to result in well executed and well tested applications. However, it does require a firm hand at the reins. In this, Mr. Gray is quite correct, the capability of the management, their understanding of the project scope, and development methodology is critical. Any tool can be misapplied with disasterous consequences.

Kirk Knoernschild responded 8 years ago: #3

I certainly agree that people trump process. But even the best people, if forced to conform to a prescriptive and ceremonial processs, are destined for failure. Virtually all organizations adopt a variation of the waterfall methodology. In fact, the waterfall model for software development is one of the greatest misinterpretations in the history of software development. Waterfall methods originated from Winston Royce's IEEE Wescon article in 1970. He described the typical software lifecycle, and explained the importance of "iterations." Unfortunately, initial interpretations of his proposed lifecycle left out the iterative aspect, and waterfall was born.

Mr. Dexter, your statements that agile teams don't performance or load test is absolutely incorrect. Agile emphasizes frequent delivery of functional software, enabling teams to perform all types of testing early in the lifecycle and throughout the lifecycle. Frequent feedback from these tests serve the development team well. A team may claim to be applying agile practices, but if they aren't disciplined in getting the feedback, those practices enable, the team isn't agile.

And this is the first reference I've ever seen that agile teams lack configuration management. CM is a key ingredient of agile teams and there is nothing chaotic about it. Surround your CM tool with a robust continuous integration strategy, and you've begun to form the foundation of an agile team - one that can respond quickly to change, gather frequent feedback from it's customer, and more.

Agile development is very formal, and requires great discipline, but foregoes the ceremony found in traditional methods. Increased agility means a team is able to accommodate change, remain adaptive, and keep moving forward (in the right direction) when faced with change. There is nothing bad about it.

Tom Keeley responded 8 years ago: #4

Methodologies are intended to provide structure to the development process. The unfortunate side effect (that the author may be hinting at) is that rigorous enforcement of a methodology refocuses all the development effort on the methodology, rather than developing the product the methodology was intended to support.

The suggestion that methodologies can eliminate the need to “think” appears to be a common objective of third-generation organizations, where the focus has shifted from innovation to cost containment.

-Add Your Comment


Comment Policy: WTN News accepts comments that are on-topic and do not contain advertisements, profanity or personal attacks. Comments represent the views of the individuals who post them and do not necessarily represent the views of WTN Media or our partners, advertisers, or sources. Comments are moderated and are not immediately posted. Your email address will not be posted.

WTN Media cannot accept liability for the content of comments posted here or verify their accuracy. If you believe this comment section is being abused, contact

WTN Media Presents