Should organization follow programs, or the other way around? Issues in PPBE reform

The main points which will be stressed in the succeeding paragraphs are: first, that PPBS has been and is being oversold and, in some ways, misrepresented by its own advocates. Second, that much of the literature and some of the behavior relating to PPBS is premised on an oversimplified view of the world, of the society, and of government. Third, that there are certain intrinsic difficulties of PPBS which its advocates have not acknowledged or dealt with effectively.

That was budget scholar Frederick C., Mosher in “Limitations and Problems of PPBS in the States,” Public Administration Review, Vol. 24, No. 2 (March-April, 1969). PPBS, of course, if the Planning-Programming-Budgeting System, and today has added an “E” for Execution. Here’s one of those problems that often goes unacknowledged:

Inevitably the definition and classification of programs and subprograms will differ from the structure of the organizational hierarchy. Every major program, however it is defined, will have consequences for other programs and with the organizations responsible for sectors of those other programs. A few writers have suggested that entire jurisdictions and large departments be reorganized to accord with a more rational PPBS program structure. It may well be that the discipline of PPBS will contribute to improved organizational patterns – which, as observed above, usually means among other things greater centralization. But there is no way one can design complex organizations without overlaps, competing perspectives, and interdependence.”

The Army and Navy had to reorganize their procurement in the 1960s to conform to the PPBS program structure by abolishing the bureau and technical services in favor of a chief of materiel command with various systems program offices.

As described to the Congress with the Air Force 375-series regulations in 1961, the steps to a procurement program were (1) the staff officers “decide what is needed,” (2) the systems project office is created to “obtain it;” and (3) the combatant commands “use it.” In deciding what is needed, the staff performs extensive  planning, such as to “Identify responsibilities, tasks, and time phasing of major actions of each participant.” Before the SPO could change the plan, it had to run up the chain to Headquarters, which would “Assure that all participants are provided with adequate, consistent, and timely decisions, guidance, and resource allocations.”

Certainly, the new organizational structure did not relieve DoD of overlaps, competing perspectives, and interdependence. Today’s problems of interoperability of systems and use of enterprise tools is a consequence of this creation of program stovepipes. Analytically, each program is suboptimized within its own parameters, and built full stack. This is in contrast to the recombinatorial innovation dominant in the 1950s into the 1960s and before.

Be the first to comment

Leave a Reply