If you have a big project to do, it's very difficult to get started because big projects are so daunting. Most people have probably experienced sitting down to start some project, getting a wave of anxiety about it and then thinking "I'll just refresh my news feed one more time/play one more game of solitaire before I get started". Days and days can pass this way.
The trick is, of course, to not start big projects at all - instead to start a small project and hope it grows into a big project. The trouble is that it's difficult to start modifying a project that's already big if you didn't start it yourself, since even learning enough to make a tiny change is itself a dauntingly big project.
If you can't pick a small project instead of a big project, the thing to do is divide up the project into smaller ones (which itself isn't necessarily a very big project at all - it's just writing down a short list). Then pick a sub-project and just go and do it (recursing as necessary). If you are at all susceptable to procrastination, it's important to avoid looking at the entire list - just concentrate on the one small part of it that's next and forget the rest. Completing one small part gives the satisfaction and mental energy required to start the next one.
It is for this reason that I don't think I could ever write a novel. A small piece of a novel isn't self-contained and independently useful the way that a small piece of a computer program can be, so you don't get that sense of satisfaction from completing it.
One problem I often had at Microsoft was scheduling and estimating time for large projects. Many other programmers I know have the same problem. In order to estimate accurately you need to do a full walk of the tree of sub-projects until each sub-project is no more than a day's work, add up the number of sub-projects and give that as the number of days. That's going to be gross overestimate, of course, since if you know a sub-project is going to be less than a day's work, chances are you know enough about it to do it much quicker than that. But managers (in my experience) prefer it when people overestimate than when they underestimate as it reduces risk. If you desire tighter bounds on your estimate you can figure this out with some practice, by multiplying the number of sub-projects by the average fraction of a day it actually takes to do a sub-project.
The trouble with schedules that are vastly overestimated is that they don't convey any sense of urgency - if you know in the back of your mind that you have three times as much time as you need to do a project, chances are you'll procrastinate for the first two thirds of that time. Then when the project takes longer than you estimated (as projects invariably do), you overrun the allotted time and look less than competent. Trying to achieve the delicate balance between a schedule that is achievable and a schedule that will motivate you sufficiently is difficult.
Scheduling is also very demotivating work in itself because that big list of sub-projects (and the corresponding long stretch of time) looks very daunting, and you don't even get the satisfaction of completing each part as you tick it off the list. I'd much rather not have any schedule at all, and just work at my own pace. I find that "trying to be finished as soon as possible" motivates me much better than "trying to be finished by date X". Managers do like to know when things will be finished, though.
I think the ideal way to cope with this would be to work one project ahead - work on project X+1 while management thinks you're working on project X. Then when you're asked to schedule project X+1 you'll know exactly how long it takes because you've just finished it. Add in a little extra time in case project X+2 takes longer. I never managed to get to this state, though - mostly because I was continually playing "catch up" and also because we weren't planning sufficiently far ahead that I had any idea what project X+1 would be at the start of project X's officially allotted time.
[...] It would be nice to have a website to manage these lists of tasks and use them to help manage time and generate schedules. The schedules should be quite informal - each item should fall into one of three categories - tasks that should take less than a day, tasks that will probably take more than a day (and should be further broken down to get an accurate schedule) and tasks that have not yet been placed into one of the previous two buckets (more details on this costing algorithm). [...]