I like what Paul Graham said:

I try to build big programs out of small ones. So when I approach a new project, I look for the subset of the problem that I can solve with the smallest program. Then I start adding things.

I'd break the problem into small features and plan to implement each feature in order of importance. (If you can convince your manager to put them in order, that's even better!)

The one trick is figuring out what to do first. If you've broken the job up into smaller pieces, choose the minimum you can do that represent the whole system. This'll let you explore the system as a whole as early as possible so you can see what's feasable and working.