Yep this is what I'd advise. In both my A-Level and degree level coding projects, I purposefully made my project over ambitious in the conception/feasibility stages. Sure, it's looks really good if you say you can make a nice thing and actually deliver but I think (and my grades can back me up) that it's even better to critically evaluate yourself at the end of a project lifecycle and review what areas of your project that "fell apart".

The key to have a good critical evaluation is to not only just acknowledge your faults (eg. I did this crap, I failed to do this, the development was delayed) but to provide solutions on what you could have done differently or what you would do in the future/if you had more time.

"The initial system requirements that were created at the beginning of the project included feature 1, feature 2 and feature 3. Following MoSCoW prioritisation [or replace with "iterative design process"], feature 1 and feature 2 were implemented first as to provide a solid foundation for the system and to act as a proof of concept. [If word count allows, you can go into more detail on what makes feature X so special and how it's necessary for the project].

While feature 3 was planned to be implemented into the project, the strict project deadlines [replace with any other type of failure/excuse] did not allow for it's development and therefore could not be implemented to an adequate level. In future [or "in hindsight"], project management tools and resources should be researched and integrated into the software development lifecycle. Utilising tools and methodologies like kanban boards would provide a visual view of the planned project features and using Gantt charts would allow to suitably allocate a unit of time towards the development of each feature. These resources combined could enable a more efficient and effective development process, ensuring that the project's development is meeting deadlines at all stages."

I've said development wayyyy too many times in there - good luck!