In the old dark ages, software was build using the famous waterfall approach: plan, analyse requirements, design system, build system, test system and run system.
This goes back in the fifties, in a time where this separation of duties and the specialisation of tasks was a strong reality in a Tayloristic environment.
I think that there is the origin of the plan, build, run concept, long before COBIT and IASCA. Some clever consultant just let the detailed stages out, to make it easy to grasp for non-technical managers and auditors.
Nowadays, big consulting firm continue to sell the idea as a proven path to success.
However, everyone who was involved in real software development knows, that you can't plan all the details from scratch, and that you need some degree of flexibility in order to cope with uncertainty. This is why agile is so popular today. Adaptative and iterative planning goes along with development. And the growing popularity and success of DevOps proves that it's better to integrate development (build) and operations (run).
Look at project management itself. PMBOK explains that complex projects require progressive elaboration. PMBOK and ISO21500 both see planning not as a phase (as in plan/buil/run) but as a set of processes carried out throughout the project.
With this in mind, how can Plan/build/run be implemented ? Project managers in a plan department, loosing gradually understanding of technology and buisness ? Developpers in a build department who are required to go through plan to organize their work ? And after go live, the same developpers do no longer intervene in support (despite they know system best), because support is run and not build ?
In my personal life I witnessed such transformation, and the end result is that it's difficult to get projects done, and there was a huge overhead of interdepartmental communication, when the same people delivered efficiently as an integrated team before the plan/build/run organization.