As software can easily changed according to changing business needs, software is never really done. So, it's unnecessary to put it in a project.
While you do a factory building project and decide a point at which you are done, you wouldn't do a car manufacturing project.
Software development is more similar to building cars than to building factories. So instead of projects it is better to think of assembly lines (sprints, kanban boards, etc) and throughput (e.g. burndown). The question is how many business changes come in every week and how many can you solve every week.
Measuring and viewing things the right way then also shows how successful you actually are as a development team.
PS: If your company isn't working like this yet, you might consider getting some external help quickly. This is the standard for quite some time now, but admittedly it's hard to find out what the standard is if you rarely get new people added to your team.