"It will not do to leave a live dragon out of your plans if you live near one." ~ The Hobbit

No matter what you do, no matter how long you prepare, your plan will begin to slowly, or not so slowly, unravel before your eyes.  Plans fail, that is the one constant you can actually plan for.  

If you know things will go wrong, should you just throw caution to the wind and forget proper due diligence in planning your project?  Never, in fact, never ever!  A plan that is even a horrible 10% right is better than no plan at all.  Review previous plans to build expected-to-actual comparisons, evaluate your team's capacity/velocity, come up with real-world fix/find rates for bugs, or whatever you usually do.  Just know that you don't know everything that will happen to your precious project (yes Bilbo, I wrote precious on purpose).

Great, so how do we combat that fact that we know "stuff" happens.  I've long been a fan of a 25% unknown factor.  Take whatever you come up with as your planned completion date and increase it by 25%.  I don't care if it's only a week long plan or a whopping twenty-four months (may the wondrous software gods help you in that instance!).  The world is full of evil project disruptors just waiting to throw your plans into a tailspin.  You don't know them all, but you can know that some will surely visit your shire (yeah, I did that on purpose too).

Alfred Pennyworth: "Why do we fall, sir? So that we might learn to pick ourselves up." ~ Batman Begins (2005)

Embrace failure by failing fast.  I'm a fan of Agile, so I usually promote Scrum as a way to offset the risk of failure.  If a sprint fails, you only "lose" two weeks worth of progress as opposed to multiple months.  It's a lot easier to get back on course when you are two weeks off plan as opposed to finding out halfway through your project that your estimates were off by 50%.  

Another tactic is to enable your teams to aim high with their goals and strive to excel.  Sure, when you aim high, you won't hit the mark every time, but I am willing to bet that you will be more impressed with a team that just misses a high target than a team that continually meets conservative goals.  Challenge your teams to continually increase their velocity.  Every once in a while, they will over-achieve and hit that high mark.  When that happens, smile and get out of the way.  An over-achieving team is hard to slow down once they figured out how powerful they can truly be.

A final change-embracer is the concept of an evolving design.  Massive up-front designs age quickly.  Do you really know everything you need to know to properly design a feature that won't be worked on for seven months?  Business priorities change, architectural decisions get tweaked, and new brains join teams with fresh ideas on how to do things better/faster/stronger.  Just like with plans, design small.  Design what you know at that moment. 

Mickey: "Your nose is broken." 
Rocky: "How does it look?" 
Mickey: "Ah, it's an improvement." ~ Rocky (1976)

My favorite part of Agile/Scrum is the retrospective.  Encourage your team to come up with creative ideas that may help the team work better.  Again, welcome failure in this process.  Worst case, you try something new, it fails inside of two weeks, and the team decides to try something else in the next sprint.  Get people talking and throwing out ideas to try.  I've found that emphasizing that these are things we would try for at least one sprint really helps people loosen up their idea-generating brain cells.  

Constant improvement is the only way to stay ahead of your competition.  Think of it this way.  Every day, you either get better, or you get worse.  There is no maintaining your current position because you must assume that your competition is out there doing every thing they can do one-up you.  So if you are not improving on a daily basis, you can bet whoever is chasing you is.  That is how you actually get worse by doing what you've always done.  Get better every day and every sprint!