We naturally want to achieve small accomplishments early on, so often work on the simpliest problems first.  This is nice, but doesn't do anything to avoid the 80/20 rule and only pushes the most important challenges too close to the finish line.

A better technique is to identify the most difficult aspects of the projects and work with them to expose all of the hidden hurdles.  If you have a more accurate understanding of the path in front of you, the navigation is less reactive and more proactive.  You will have the time necessary to acquire the following to best solve the problem.

• knowledge
• recources
• support

The knowledge of the problem may come from various forms of documentation or vendor specs.  Recources may be in the form of additional tools or talent with more expreience.  Support can best come from your business users and management who will begin to understand the challenge and may be able to adjust requirements when they realize that a large amount of time and money may be spent on an area that has little return in value.

How to fail?

Prototype. Build a simple, focused app to isolate the 1 problem you are trying to address.

Create your proof of concepts that interact with the 3rd party API.  Cross-system communication is often a major pain point.  Test this hand-shake with a large variety of data (in type and size).

Build a site using the new "wiz-bang" UI tools and see how well it will perform the intended tasks.  Test your prototypes with load and bandwidth-throttling tools also to make sure that the concepts will last.

Understand the problem well and produce alternatives.  The business users will understand that there are some technical or operational challenges present.  If plan A won't work, give them plans B and C based off your new enlightened view of the area.

It is important to fail fast only so you can get up faster, stronger and smarter.  Subquent tasks in the project will fall into place easier and you will have a greater chance to stay on target to your milestones.