From a technology development perspective, Rogue says that more time and more money don't make the system better. Rogue asserts that constraints foster creativity, and that restraint is a virtue, both organizationally and technically. It's about allowing the schedule & budget to constrain the design, rather than allowing the design to drive the schedule and budget.
There's a strong streak of imperfectionism running through the Rogue Project Leader approach. That is, there is an explicit preference for delivering something tangible now, however imperfect or incomplete, instead of promising a hypothetical perfection to be delivered at a later date.
All too often, the engineering world starts with a preference for perfection and a tolerance for delay. Macho sloganeering leads otherwise sensible engineers to assume a "failure is not an option" posture. The end result is excessive risk aversion, increases in complexity that actually reduce reliability, cost over runs and schedule delays... all mistakes made in the name of ensuring we don't make any mistakes.
Rogues make mistakes too, of course. Rogue projects can (and do) fail, but Rogue failures are not surprising to the Rogue Project Leader, and they're not the end of the story. Rogue failures also cost less and teach more than the epic fails caused by pursuing perfection over long timelines.