Once a project is started, finish it.
Even with a good process to pick the right projects to execute, there will be a strong if often unrecognized tendency to initiate too many projects at once, or initiate more projects before any already underway have been completed. This goes back to the average senior manager’s split view that most IT spending is a waste, except for their own projects. Given several senior managers in an organization expressing these views, a natural reaction is to have at least one project underway for each manager; if most of the IT efforts are applied to projects for only a few managers, the rest will complain or start looking for other options.
However, running too many projects at once ends up pleasing no one, as no project makes any noticeable enough progress to be seen as a success, because of the competition for limited resources. This is a definite lose-lose situation.
Solving this overall problem requires the use of a few of my principles, especially picking the right projects to begin with. The emphasis for this principle is to get projects done; avoid putting some projects on hold to put the affected resources on another project so the latter can show some progress. Finish one, and then start the next one.
This has always just seemed like common sense to me, but it was uncommon to see it happen. Trying to do too much, and getting nothing done, was found to be such a problem even within software projects that it has led to the development and fast adoption of the Kanban software development approach, starting at Microsoft back in 2004 (see http://agile.dzone.com/articles/how-kanban-got-hot-david) . What stands out for me in Kanban is the emphasis on limiting Work-In-Progress (WIP); I think this has wide applicability to any process trying to produce new deliverables.