Every time I have set up or helped set up a program management function, the first question from leadership is: what will this cost. The second question, usually unasked, is: what will this interrupt. Both deserve direct answers before you start designing anything.
The cost question is easy. Headcount plus tooling. Be specific and tie it to specific programs or outcomes. A program office justified by general value is approved and then quietly defunded.
The interrupt question is harder and more important. A new program office, if it is not careful, becomes a reporting layer that slows decisions rather than supporting them. The teams it touches will resist it not because they dislike program management but because most of what they have seen called program management is overhead dressed up as governance.
The first 90 days should demonstrate value before they impose process. Pick one or two programs that are visibly struggling and make them less painful. Do not build the methodology first. Build the trust first, then introduce the methodology as the thing that produced the result people already saw.
The tools follow the process, not the other way around. I have seen program offices spend six months selecting a portfolio tool before running a single program review. By the time the tool is live, nobody trusts the function.
A program office that engineering and product leaders use voluntarily is a program office that will survive the next reorg. Build that before you build anything else.