From ''CategoryMethodology '':

A Methodology specifies some process for developing software.
Each one has a specified set of deliverables (code, documents, test
results, ...) and tasks which develop them.  They differ in what
conditions they work with and on
any number of other criteria which others should expand on.  

Many seek MinimalMethodologies to minimize the overhead.
Officially adopting a methodology often implies unusual attention
to the complete LifeCycle, from RequirementsAnalysis through ProductionSupport.
This can be a good thing, since "minimizing overhead" too often means the
software coders are just ThrowingWorkOverTheFence.  However, methodologies
which specalize in giant paper documents are mostly good for extracting money
from the government.  If this is your aim, look no further than the SEI
CapabilityMaturityModel, which was designed for that software development environment. ''But SW-CMM isn't a development methodology and it doesn't require giant paper documents. Have you read it?''

For a large project, adopting an appropriate predefined methodology or
at least adapting an existing one is
a necessary but not sufficient condition for success.  Choosing the
wrong methodology can make failure likely, but RollingYourOwnMethodology
from scratch is difficult.  Going without a defined methodology to ensure everything gets done that is needed guarantees failure!  

Click the title to see the Methodologies currently indexed here.
-- MarkSwanson

----

'guarantees failure' is pretty strong.  I can't tell whether the discussion should go here or RollingYourOwnMethodology, but in my several dozen project debriefings and interviews, I found the opposite - I have no success cases using a predefined methodology, and every successful project rolled their own.  In fact, rolling their own methodology is now a core process step in two large organizations I have spoken with, and they feel is essential. Could you add some background to your assertion so we have an idea what you are basing it on? --AlistairCockburn

----

Hmm: I agree that it was too strong.  I edited it above: I think that adapting from some existing methodology(s) is the easiest solution.  Creating a new one is hard though some find the intellectual effort required worthwhile.  But too often large projects, under the guise of RollingYourOwnMethodology, don't really decide on anything and end up leaving all the hard or boring bits to be done never.  That ''is'' fatal!  -- MarkSwanson

----

Alistair, both my experience and gut feel say that rolling your own is the only way to go, but I'm curious about the two large organizations you mention.  What can you tell us about the starting point for "rolling" a project's methodology?  Are these start-from-scratch (seems unlikely), or do they have some basic methodology bones they begin with and roll the flesh and skin from there?  This would be like what Mark Paulk (of CMM fame) calls "tailoring", something I think is expected by those with experience, but almost unknown outside those circles.  Thanks, --WaldenMathews

----

Indeed, tailoring.  As pointed to in RollingYourOwnMethodology, two relatively new papers on my web site: 
Just In Time Methodology Construction (http://members.aol.com/humansandt/papers/jitmethy/jitmethy.htm)
and Balancing Lightness With Sufficiency
(http://members.aol.com/acockburn/papers/barelysufficient.htm)
are about that.  In those and the other methodology papers there (e.g. MethodologySpace) I'm trying to get at some principles with some predictive value, to give the bones you refer to.  I have as a critical success factor of a methodology that it gets tuned by the group... think about what that implies (scary, huh?)  Hence the JIT becomes more important, and some principles would sure help.  --AlistairCockburn

----
CategoryMethodology