Is another methodology required? (Does it not make the market place more confusing?)

Actually, another methodology is always required. There is a new methodology for every project.
How many of them should be published? I'd like to publish about a dozen or so of them, from different projects so people could see the different ways of working.
Alistair

Hello Alistar,
What methodologies do you have so far?

Crystal Clear is a distillation that comes from interviews with about half a dozen project teams that had worked the same way (just uncovered a new and more interesting one - 14 people in a unique room setup, in Copenhagen).
Crystal Orange we used on a 45 person project in 1994 (Smalltalk / Rel DB / Cobol, client server).
Crystal Orange Web was in a 50 person company doing continuous web delivery every other week.
Ron Crocker is hopefully going to describe his work with a 70 person, multinational team on large mobile phone project - very interesting variations on the agile theme he cooked up there.
I suspect that RUP's origin was the agilely concocted Canadian air traffic control project, a life critical multi-hundred person project.
I'm needing a 20-person project. Don't have any life-critical projects. Don't have any industrial web-site development projects (though I saw the methodology for one, briefly).
What else should I collect?
Alistair

alistair , crystal is family of methodologies , if i am not wrong ?
I have read your book on " Surviving object oriented project ". in that also , you have interviewed many successful , unsuccessful groups before putting that in perspective in book.
What advantages do you feel in interviewing the groups ?

Interviewing groups is my form of learning. What i've learned is that nothing is obvious is methodology... seemlingly obviously good ideas turn out to be bad, and seemingly obvious bad ideas turn out to be good. And there is always another way of working that also works.

so , shall we say , even if we are using heavy weight or light weight methodologies , something good may turn bad & bad may turn good ?
so , best practice would be to use one's own methodology ? isn't it.

shailesh,
I think you get it.

All of the programs I have worked have used the "do what works until it doesn't" and "what looks like it would help from methodology X" to get things done. I guess it is sort of like the concept that each project has its own methodology/approach.
There are common threads running through them, though. Need to talk with the customers and users throughout the project, test all the time, get the interfaces nailed first are the few that came to mind right away.
What are (some of) the common aspects across the projects you have worked on and heard about, Alistair?
John

You've got them, John.
Watch your back for risks all the time (technology & people), get close to the customer, show and get feedback as quickly and often as possible, check the design for quality, test where possible, and especially in risk areas, communicate with the team.
Look across the effective teams and methodologies, and you'll find these themes in many clothings.