VBA project protection is famously weak by modern standards, which for an authorized maintainer of an inherited file is fortunate, so the options from cleanest to most technical, all for a file you legitimately own:

Understand what it is first: the VBA project password protects viewing and editing the macro code, not the workbook data or the ability to run the macros and it is a genuinely weak protection layered on the file, historically bypassable because it was never real cryptography. This is why authorized recovery is straightforward where the same weakness would be alarming on something meant to be secure.

The cleanest route, if the original author or documentation exists at all: exhaust asking, since the intended password might be recorded somewhere, a project note, an IT record, the author's successor, before technical measures, the five minutes that occasionally saves the effort.

The technical route for the modern xlsm file, hex editing the protection state: the VBA password protection lives in the file's structure and can be reset by editing the vbaProject.bin inside the xlsm, which is a zip archive, altering the protection key so the project opens without a password. Documented procedures exist for this, editing the CMG, DPB and GC keys in the project stream and it resets rather than reveals the password, giving you access to maintain the macros, which is the actual goal.

The tooling route for those who prefer not to hex edit: VBA password recovery and removal tools automate the same reset, taking the file and returning it with the VBA project accessible, appropriate for an authorized maintainer wanting the result without the manual editing. The honest framing throughout, this works because VBA project protection is weak, which is fine for recovering access to your own inherited file and is exactly why VBA passwords should never be relied on to protect anything genuinely sensitive, the code being the thing to secure elsewhere if it matters.