В мире программирования задача никогда не бывает одна, если это так - значит поставлена она не верно. Зачада "Сделать сайт" - поставлена неверно, к примеру. Большие задачи обычно дробятся и каждому периоду работы обычно предшествует список определенных задач на реализацию. Среди таких задач бывают большие - например "Сделать фотогалерею" и тз, дизайн и т.п. по ней. А бывают маленькие - например, сменить фразу "Выбранные товары" на фразу "Корзина".
С чего начать? С больших или с маленьких задач?
Обычно начинают всегда с больших. И так в целом абсолютно здраво делать, когда проектируется новый сайт или вы знаете систему отлично. На маленькие задачи надо меньше сил, а если вначале сделать мелочь - то на большое не всегда останется рвения. Да и если система создается новая - то вначале надо сделать "скелет", а уже потом навешивать мышцы и кожу 
Но такой подход абсолютно не оправдан в случае, если вы вносите изменения в систему в которой нифига не разбираетесь. В таких случаях лучше начинать с конца.
Например, пришел проект написанный фиг знает на чем, фиг знает кем и когда. Что внутри - непонятно. Делаем мелкий таск - изменение надписи. Дело пятиминутное - тупо прогнать поиск по коду (и базе если по коду не найдется) по этому слову - и поменять его. Задачу сделали - и уже кое-чему научились, например, как устроена система локализации, есть ли она вообще. Какие шаблоны есть в коде. Т.е. решение мелкой задачи помогло попутно разобраться с проектом и узнать что-то о нем, без того чтобы специально колупать его и смотреть что там и где. И так далее - от мелкого к крупному.
Такой подход позволяет убить сразу 2-х зайцев:
- Тратится минимум времени на изучение архитектуры проекта;
- Всегда можно показать заказчику, что работа над проектом идет. Ему не придется месяц трястись и трахать мозг менеджеру, ожидая выполнения самой большой задачи.
Так что, если в коде разбираешься или проект новый - то от сложного к простому, если нет - от простого к сложному.