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., PMPManager SPS Applications & Development - McKesson CanadaRegional 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.
Once you have defined your methodology, here are some tips on making the most of it:
I am curious to hear your success, and not-so-successful stories.
(1) http://www.answers.com/methodology (2) http://www.joelonsoftware.com/articles/AardvarkSpec.html(3) http://agilemanifesto.org/ (4) http://www.startvbdotnet.com/sdlc/sdlc.aspx (5) http://www.extremeprogramming.org/
***********Thank you Adam for sharing you deep insights.