Before the project
When you're scoping out a project, you need to research and talk through:
- Dependancies
- Known time expenditures
- Risks
This ideally is a collaboration between the guy who represents the business (probably your manager) and the guy who will take responsibility for the work (sounds like you).
Chances are, ahead of time, you can figure out that you'll have a few key technical things that you have to get done, and some of them will be in a certain order, other's won't be. Have a plan and map these out, so you'll know what relies on what (aka, the critical path).
Some areas have known time expenditures. This could be something like technical work you've done before - such as routine tasks in known systems. Others are simply work within the business - like procurement or security approvals. Have the knowns figured out.
Then tackle the unknowns. You'll have to make a guess, and with the dependancies and known time expenditures mapped out, you have some hope of finding your rocks and hard places. You'll probably end up with some awareness that "Task C, which we have no clue on CAN'T take more time than 1 week, or this just won't work".
That's where you hit "risks" - unknown, never-before-tried work is a risk - the risk is that you don't know what you'll encounter when trying it, and what will happen when you hit a problem. There's also the point that someone who had familiarity with this new type of work might do it quickly, but someone doing it for the first time is likely to be slower and make some mistakes.
That's the point where you figure out what to do about the risk. More time is one option, Lengthen the overall project schedule before committing. More knowledge is another mitigation - hire someone who knows the tool, get a consultant, get a killer support contract on the new tool, or budget time for a bootcamp for one of the employees. Or more than one of these things if the risk is big enough.
During the project
Review and rebaseline.
Sometimes you can have predictive measures - for example if task 1 6 weeks, then maybe another task will generally be known to take 1/2 that time... so if task 1 swells to 8 weeks, then figure that task 2 will also go from 3 weeks to 4 weeks.
Other times, you may want to review some of those risks and mitigations. Maybe you went to a bootcamp but it was lame, so you don't feel that you've adequately addressed the risk. Or you got that support contract but the company isn't providing the quality you expected, and your boss needs to have a long harsh talk with the sales rep...
If you don't reflect on whether you are succeeding with your attempts, you fall into the old proverb - "don't that don't learn from history..."
After the project
Do a lessons learned. Avoid blame, but reflect on what worked and what failed. If you had the opportunity to plan this again, what would you change in your plan?
Jot these answers down for next time. After a while you'll probably end up with categories of projects, and some knowledge of what happens when you attempt the big, weird, "we have no clue beforehand how to do this" projects, and a list of solutions that worked and didn't. That's the gold of reflecting, because it'll keep the company from wasting money on stuff that doesn't work.