OKR's are good for outlining requirements, but the project needs to be viable so start by validating the business case. This includes TCO - how much will it cost to build and how much to maintain.
Project requirements come in many guises: building skyscrapers, changing business processes, designing new tools, etc. etc., so choose the method to suit the requirement and the environment.
Providing an environment where contributors can excel is key. Proscriptive methods like scrum are useful when bringing teams together, but once they have found their feet let them organise themselves. Good governance is crucial for making this work - Cyranix's comment makes some good points on this.
The Manifesto for Async Software Development is a "21st century successor to Agile" and has some useful tips for working with distributed teams, which seems to be the way things are moving:
Both Cyranix and the Async Manifesto make a point of documentation. I would add that all design decisions should be noted with details about the reasons for the choice, and also the options considered and reasons why they were discarded. This will help with learning from retrospectives.