Methodology – One Size Doesn’t Fit All

I was talking with Adam Cole and he had some really interesting things to say so I invited him here to provide a "guest blog."

Adam Cole, BMath, I.S.P., PMP
Manager SPS Applications & Development - McKesson Canada
Regional Director, National Board, Canadian Information Processing Society (CIPS)

Methodology, you know what it is. It's the medicine you should take to avoid pain and suffering down the road. But those methodology pills don't always go down so well, especially those big, easily chokable pills called BDUF(1) (Big Design Up Front).

The Computer Desktop Encyclopedia(2) gives us a pretty palatable definition of methodology: "A specific way of performing an operation that implies precise deliverables at the end of each stage." Alas, no matter how palatable it looks, methodologies are prone to having a very bitter taste if not handled adroitly.

Methodologies range from the seemingly default fly-by-the-seat-of-your-pants to the über heavy weights which require documentation for even thinking about a change. One thing that I am absolutely certain of is there is no one-size-fits-all methodology. Each organization, and in many cases, each project deserves its own determination of a best methodology.

Like many of you, I work for a company where we have Titanic projects and we have inflatable dinghy projects. Clearly these projects don't all deserve the same methodology. (Close your eyes and imagine swapping the methodologies you would use to handle these two classes of projects ... ooh, scary!) Yet I frequently see cases of companies trying to shoehorn their "Building the Titanic" methodologies into their small projects. Fortunately the incidence of companies applying micro-methodologies to mega-projects appears to be on the wane. Do you work for either of these companies?

Getting specific, I presently manage multiple large projects. One is highly regulated, the details are very clearly defined, and the end results are expected to match the objectives regardless of what transpires between the period of conception and completion. Wyle E. Coyote could catch the Road Runner and Eminem could write love ballads...I still know what the end results of my project will look like. However, another strategic project I'm working on is only loosely defined. I am pretty sure it's supposed to help my executives make smarter decisions, but anything more defined than this is apt to change more frequently than Brad Pitt and Angelina Jolie change spouses. This is a system that pulls data from other systems which themselves are in flux and outputs "knowledge" which is highly transient. If I rigorously followed my original specs I would succeed in creating a brilliant piece of obsolescence. The former project is well suited for BDUF(1) whereas the later project better aligns to Agile(3) principles.

Adhering to a methodology provides the opportunity to recognize many benefits such as consistency and predictability. But applying the wrong methodology or applying a methodology for the sake of having a methodology is a sure sign of a project in peril.

Here are some considerations I believe you should take when selecting a methodology. Which ever you choose, remember, you have the freedom to customize the methodology to best suit your environment.

  • How well defined are the project objectives? Is this a "dynamic" project?
  • What is your team's experience with the methodology?
  • What do the communications within and external to the core project team look like?
  • How well defined are the specifications?
  • What criteria do you use for defining a project methodology?

Once you have defined your methodology, here are some tips on making the most of it:

  • Be sure to keep your focus on the objective.
  • Be flexible and open-minded.
  • Don't fall in to the trap of gauging success by the number of ticked boxes on your checklist. (This is an indication that you should familiarize yourself with the previous two points.)
  • Understand that you will not build the perfect solution on your first attempt. Get over it. Plan to be iterative from the start. (If you use the waterfall(4) approach ditch it and pick another.)
  • Read the Agile Manifesto(3). You don't need to subscribe to XP(5) to see the merit in these four principals. (Really, I mean it. Go read it! I will wait right here for you.)
  • The best methodology won’t do much for an ill conceived project, nor is it a surrogate for good project management.
  • Have you evaluated the fitness of your methodologies? What tips do you have?

I am curious to hear your success, and not-so-successful stories.


Thank you Adam for sharing you deep insights.

Stephen Ibaraki

Comments (4)

  1. G. L. says:

    Adam you provided such a well-written piece I have been sharing it with others. We focus on Agile. How do you feel it doesn’t work as well–please elaborate? I like to see more of your writings.

  2. Igor Abramovitch, Robert Half Technology says:


    I think many IT managers would benefit from reading this article. I work with numerous enterprises where one methodology is selected and blindly followed. The approach you are describing would save them a lot of time and money!


    Igor Abramovitch

    Robert Half Technology

    Division Director, Consulting Services


  3. Adam Cole says:

    Thank you for your comments G.L.

    Software development is about creating a solution. The solution, be it the autopilot for the Airbus 380 or the subsystem that causes elevators to chime at every floor, is the objective. The methodology is a by-product of pursuing your objective. The methodology must help you meet your objective while minimizing risk, cost, and delivery time.

    What I love about the Agile Manifesto is it’s a philosophy rather then a set of rigid directions. You are free, nay encouraged, to use your intelligence to achieve the project objective. This is a subtle yet important difference from BDUF1,2  which generally asks for thinking upfront by the specifications team followed by coding-by-numbers by the development team. This of course implies that developers are mutually exclusive of business analysts. This I believe is a throwback to the Revenge of the Nerds days. At the dawn of the PC, developers were not inaccurately characterized as social misfits. Appropriately we were not trusted to design system interfaces. Fortunately the expert developer has evolved on par with Moore’s law. We’ve shed our propeller caps and bandaged glasses for Hugo Boss jackets and YSL purses. But more on this later.

    As you have hinted, Agile is not without its shortcomings. Paired-programming for instance excels at reducing bug count, but does nothing at ensuring the solution matches the need. Refactoring without planning opens the door to sloppy programming. Fortunately Agile doesn’t encourage these behaviours. Paired-programming is only one of 12 XP practices and all Agile disciplines promote intelligence-behind-the-keyboard. The point is these mistakes happen, regardless of the methodology, when one becomes too focused on process and loses sight of objectives. Agile disciplines are not immune. BUT, the Agile philosophy (sorry I hate the word Manifesto – I have this vision of a left-wing reactionary faction. …You will use Agile methods or we will pluck out your letter “A” key and remove the glide pads from the bottom of your mouse…) elevates the behaviours which lead to successful outcomes.

    If we look at the continuum of methodologies we have write-once-right on one end of the spectrum with iterate-and-repeat on the other end. The reality is you simply can’t write-once for any project of significance. But, you can’t go on iterating forever. Sooner or later you must freeze the specifications and move to delivery. Regardless of where your methodology lies in this continuum there is one universal: A bright project team who stay focused on the objective is a sure bet for maximizing success.

    We started the other day by saying one size doesn’t fit all1,2. Today we added the axioms that (1) focus on objectives and (2) people, i.e. intelligent developers, are more import than the selection of methodology. We can now have some fun and wrap this up into a neat little analogy:

    Methodology is a tool used to deliver a solution. It is a tool which when used properly can be very beneficial. Like any tool, it is only as good as the hands that hold it. It is only a tool and at the end of the day it is what you build with the tool that counts. Different jobs demand different tools.

    Fortunately for me this leads nicely into another management philosophy of mine, “Situational Empathy”. The best tool in the brightest hands can undoubtedly build a beautiful rocking chair, but if the client’s vision was a Lazy Boy the end product ain’t no success. In Situational Empathy we’ll look at how to REALLY get inside the client’s mind.


    I have mentioned the Agile Manifesto several times. Since it is really a philosophy it CAN be applied to BDUF methodologies. Regardless of how you choose to develop code I can promise you that embracing the Agile principals will improve your solutions:

    • Individuals and interactions over processes and tools

    • Working software over comprehensive documentation

    • Customer collaboration over contract negotiation

    • Responding to change over following a plan

    That is, while there is value in the items on

    the right, we value the items on the left more.

Skip to main content