There are “trouble spots” in all projects. These are the parts of the project that aren’t fully thought out, lack documentation or in general are just vague. In the programming world, they are also the parts of the project that you or your team doesn’t have experience developing or that the solution is unknown. I can’t tell you the number of projects I’ve been in where there is at least one feature of the project that can be described as a trouble spot. Try as I might, they always seem to appear.

So if all you saw in these trouble spots was bad stuff, wouldn’t you do everything you could to avoid them. Of course, but often these trouble spots represent the best parts of the project. They are the opportunities as well. They are the parts of the process that make you better at what you do. Sometimes the trouble spots are the best spots.

As a project manager, I’ve seen it many times. A developer, or myself, will start into one of the trouble spots, looking for an answer, and just keep going. The hours churn away. Sometimes you get it, sometimes you don’t. And as you travel down this path, while your interest is high and maybe you’re learning a lot, you are basically burning money.

How do we sort this out? The project still needs to be completed and therefore the problem still needs to be solved. I’ve got a few tricks that I use regularly to make sure I stay out of trouble.

First, I give myself a time budget. I estimate how long it should take me to solve the problem and drop it down by half. If a feature of a project should take 12 hours, my time budget is 6 hours. This is the hard ceiling of my time. If I don’t have an answer to the problem within sight by this time, I back out and start over. This may seem like a waste but it is better to waste half of the allotted time than burn through the entire amount and still have nothing to show for it. That’s the problem with programming issues—it’s nearly impossible to figure out the time it will take to solve a problem when the scope is completely unknown. Experience can help you estimate better but it sometimes doesn’t seem like enough. Usually at the end of 50% of the time, at the very least, I’ll have a complete sense of the problem and that makes the time spent worth it. With the remaining time I’m able to look at alternative solutions, different approaches or even outsourcing if the budget allows. The trick to this is to watch your time closely and to be ready to give up your current approach. I’ve seen many projects turn ugly when a developer or designer refuses to give up on a bad course of action.

Second, you can avoid these trouble spots by identifying them more closely. That means writing the necessary documentation and making sure you’re clear on what the problem is that you are trying to solve. An extra bit of diligence here makes a very large difference. You know what they say, “an ounce of prevention is worth a pound of cure.”

Third, and this only works sometimes, but you can avoid the problem in some projects. I don’t recommend this but there are times when a client asks for something really cool (yup, “really cool” is synonymous with “trouble spot”) and they don’t really want or need it. Sometimes these features can be dropped and everyone is better off.

Fourth, and this is the most fun, develop friendships with people that do the same work as you. Whether you use Facebook, Twitter, IRC, blogs or even just a telephone, people around you could help you solve the problem. I’ll be the first to admin that I’m not a great programmer but I have lots of friends that are. When I get stuck, sometimes all I need to pay for the answer is the cost of a beer.

Trouble spots will happen but if you watch for them and have a strategy for overcoming the problems, they can seem a lot less daunting and potentially you can turn them into the opportunities they are.