Start all of the pieces of work a little bit earlier. The key to starting work early is not succumbing to the pressure of having to finish the work. Don’t worry about finishing. If you’re a developer, you can start doing things while your design or information architect are working because a lot of your work actually isn’t dependent on their work. Some of it is, so you probably won’t be able to finish, but that shouldn’t stop you from starting.
Share Work-in-Progress Early and Often
When you share work-in-progress, share it with the caveat that no feedback is needed at this point. You’re simply sharing it to let people know where you are. For example, if you have to make 12 wireframes, share it when you finish 2 or 3. Rather than spending a whole week to drop 12 wireframes, share 2 – 3 wireframes every 2 days. The more often you do this, you start to build rhythm, and rhythm builds momentum.
What keeps me busy in my classes is trying to help my students learn how to think. They say, "Rob holds his hands like this...," and they don't know that the reason I hold my hands like this is not to make myself look that way. The end result is not to hold the gun that way; holding the gun that way is the end result of doing something else.
…The more general issue is that a person who doesn't understand the thing they're trying to copy will end up copying unimportant superficial aspects of what somebody else is doing and miss the fundamentals that drive the superficial aspects. This even happens when there are very detailed instructions. Although watching what other people do can accelerate learning, especially for beginners who have no idea what to do, there isn't a shortcut to understanding something deeply enough to facilitate doing it well that can be summed up in simple rules, like "omit needless words".