Other projects are completely dark from the beginning. Such is the case when you're building from scratch or your creation has to integrate with an item that has little or no documentation, or it relies on legacy systems or noncomputing elements for success.
An example might be constructing a type of service that is married to a hardware sensor array. You have more visibility if the sensor array already exists, but if the sensor array is developed anew for the project, then all bets are off. If you have to interact with a legacy system, you'd better hope to have all the documentation or other resources that detail precisely how the system operates.
You also better hope that the method you plan to use works the first time; if you run into a blocker after investing days or weeks, you're right back at the drawing board. Ultimately in these situations, all you can do is throw a dart and hope for the best.
Full disclosure: I've often felt the urge to cut off a spiraling discussion on time requirements and say, "It'll only take an hour," because I knew exactly what needed to be done and exactly how to do it. Inevitably, it took longer due to a tangential issue that wasn't visible at the outset. No one is immune to these errors -- we tend to pad too much or too little, or to vacillate between the two extremes.
The old adage of "underpromise and overdeliver" is perfectly apt and too often ignored, but the corollary of "within reason" is usually missed entirely. As with many situations in life, a dose of common sense goes a long way. Those who can navigate these waters are the ones who tend to deliver success again and again -- which can ultimately be problematic in itself. But that's a story for another day.
Sign up for CIO Asia eNewsletters.