A program management system is at its peak value when you realize that it would help new product launches and you implement some sort of system. Shortly after its implemented, there is a natural inclination to make the system attempt to anticipate and answer every conceivable question from every conceivable manager from every conceivable functional group. It's from the "if a little is good, more must be better" school of thought. Like taking a drink from a fire hose. That's when you fall victim to the law of diminishing returns.
As the program management system grows and gets more complicated the energy goes into managing reports, checking boxes and debating shades of red on red/yellow/green charts instead of spending the time actively leading the team, making critical decisions and prioritizing work. As the program manager is increasingly rewarded or punished based on the quality of system maintenance they start to question whether their job is to manage the system or deliver a smooth launch.
Systems get more complicated and demanding with the best of intentions. The idea is to make past failures less likely to happen again. The issue is that the layers that are added to help and protect average program managers are a burden to the good ones. It makes everybody a C student. The E and F students get a boost and the A students get weighted down. The result is mediocrity, at best.
Every attempt should be made to keep the system complexity to the minimum level necessary to lead the team to success. The value of any tool should be judged based on its contribution to successful launches and the minimum level of reporting necessary to provide a common window of visibility into the program for stakeholders and customers.