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.

(1) https://www.answers.com/methodology
(2) https://www.joelonsoftware.com/articles/AardvarkSpec.html
(3) https://agilemanifesto.org/
(4) https://www.startvbdotnet.com/sdlc/sdlc.aspx
(5) https://www.extremeprogramming.org/

***********
Thank you Adam for sharing you deep insights.

Stephen Ibaraki