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.

it’s fascinating to hear about the diverse methodologies you’ve encountered throughout your career. Your reflections on the reverence given to methodologies are particularly thought-provoking. As you’ve rightly pointed out, it is easy for the process itself to overshadow the project’s core objectives, with the emphasis on compliance to methodology often taking precedence over actual project needs. The example you provided regarding the 6,000 page functional specification is a stark reminder of how excessive documentation can detract from clarity and focus.

I wholeheartedly agree with your observation that the success of a project is more often driven by the commitment, expertise, and collaboration of a small, well-aligned team, rather than the specific methodology employed. The ability of team members to navigate the complexities of organizational dynamics and manage internal politics is crucial to a project’s success. In such cases, the methodology becomes secondary to the people and the leadership involved.

Additionally, your point about the importance of data and entity relationship modeling as a foundational element for successful projects resonates deeply. Establishing a solid data structure from the outset certainly makes it easier to accommodate changes in process or scope, regardless of the methodology in use. This emphasis on getting the fundamentals right is something that is often overlooked in favor of the latest trending methodologies.

it’s fascinating to hear about the diverse methodologies you’ve encountered throughout your career. Your reflections on the reverence given to methodologies are particularly thought-provoking. As you’ve rightly pointed out, it is easy for the process itself to overshadow the project’s core objectives, with the emphasis on compliance to methodology often taking precedence over actual project needs. The example you provided regarding the 6,000 page functional specification is a stark reminder of how excessive documentation can detract from clarity and focus.

I wholeheartedly agree with your observation that the success of a project is more often driven by the commitment, expertise, and collaboration of a small, well-aligned team, rather than the specific methodology employed. The ability of team members to navigate the complexities of organizational dynamics and manage internal politics is crucial to a project’s success. In such cases, the methodology becomes secondary to the people and the leadership involved.

Additionally, your point about the importance of data and entity relationship modeling as a foundational element for successful projects resonates deeply. Establishing a solid data structure from the outset certainly makes it easier to accommodate changes in process or scope, regardless of the methodology in use. This emphasis on getting the fundamentals right is something that is often overlooked in favor of the latest trending methodologies.