Having started as a programmer in 1970 for an aircraft manufacturer who used what they had available, which was the waterfall methodology with documentation and change management using the same processes as building aircraft. Since then I have used most of the development and management methodologies in a wide variety of industries during a career which has included computer manufacturers, consultancies and a wide range of UK and international companies. Anyone remember "goto less" programming, decision table programming, the forthcoming ice age and power so cheap we will not meter it? 

My conclusion is similar to Andy's above. Each new methodology is treated with the reverence of a religion with  zealots ensuring that all shall obey the commandments. In many cases the actual project plays second fiddle to the methodology.  I have worked on a project with what was one of the big six where the success of the project was based on the height/weight of the paperwork produced using their methodology. We were using a virtually self documenting 4GL and the relevant paperwork could have been contained in a small A4 binder, they actually produced over 3 feet of it. On one project I had to review a functional specification the customer had to sign off ,produced by a major consultancy. iI was 6,000 pages for an accounting system. Apart from me being unable to recognise what sort of system the specification was describing it did not mention project numbers around which all the companies finances were structured. I asked a friend in the project team and they said because it was complicated they had not yet worked out how to do it.

The successful development projects I have worked on have normally worked due to the commitment, knowledge and drive of a small team of the right people managed by  team players who can manage the politics of the organisation. The methodologies were irrelevant. Where there is a company wide project management team they must also have the right approach to ensuing compliance without stifling innovation. I have worked for a company where blame management was so rife even if you did the right thing you got the bame, projects did not go well.

Finally, for my attempt at proselytising: I would say that a successful project needs to start with the data and entity relationship modelling is a good way of doing this. If the underlying data structure is right then changes to process etc are easier to make irrespective of the methodologies used.

Having started as a programmer in 1970 for an aircraft manufacturer who used what they had available, which was the waterfall methodology with documentation and change management using the same processes as building aircraft. Since then I have used most of the development and management methodologies in a wide variety of industries during a career which has included computer manufacturers, consultancies and a wide range of UK and international companies. Anyone remember "goto less" programming, decision table programming, the forthcoming ice age and power so cheap we will not meter it? 

My conclusion is similar to Andy's above. Each new methodology is treated with the reverence of a religion with  zealots ensuring that all shall obey the commandments. In many cases the actual project plays second fiddle to the methodology.  I have worked on a project with what was one of the big six where the success of the project was based on the height/weight of the paperwork produced using their methodology. We were using a virtually self documenting 4GL and the relevant paperwork could have been contained in a small A4 binder, they actually produced over 3 feet of it. On one project I had to review a functional specification the customer had to sign off ,produced by a major consultancy. iI was 6,000 pages for an accounting system. Apart from me being unable to recognise what sort of system the specification was describing it did not mention project numbers around which all the companies finances were structured. I asked a friend in the project team and they said because it was complicated they had not yet worked out how to do it.

The successful development projects I have worked on have normally worked due to the commitment, knowledge and drive of a small team of the right people managed by  team players who can manage the politics of the organisation. The methodologies were irrelevant. Where there is a company wide project management team they must also have the right approach to ensuing compliance without stifling innovation. I have worked for a company where blame management was so rife even if you did the right thing you got the bame, projects did not go well.

Finally, for my attempt at proselytising: I would say that a successful project needs to start with the data and entity relationship modelling is a good way of doing this. If the underlying data structure is right then changes to process etc are easier to make irrespective of the methodologies used.