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.
Best Answer
When you plan, don't plan every possible thing about the application in advance. Plan in baby steps. What is the absolute minimum functionality you need to start using the application? Start there.
When you start your project, only code out the absolute minimum functionality. When you do code it out, make sure you are writing good, clean code with smart encapsulation. This will minimize errors that come from making changes later.
Iterate on that minimum functionality until you are happy with it. Then start adding in new functionality and enhancements, one at a time. Again focus on writing good, clean code with smart encapsulation.
If you plan in baby steps and write clean code it will minimize the number of changes you actually need to make. By the time you've finished writing that first feature, you should have adopted the patterns your application's foundation will sit on. If there are problems with that foundation, your next features should quickly reveal the problem. It will be easier to see how piece integrate together. The changes you do make should, at this point, cause minimal disruptions.