It can be surprising to see engineers struggle to define work as a project or a task. A team that can't tell the difference is displaying a warning sign that it's lost a view of the bigger picture. Often the team has been focused solely on bug fixes and patches to legacy software.
I think the simplest definition is that a project is a group of tasks that add value to a software product. This can come in the form of a new feature or improved functionality. In Scrum, a project is comprised of one or more user stories that in turn are comprised of tasks. Tasks, on the other hand, are just descriptions of work. It can be writing a piece of code, testing a program, or writing your status report. Projects take longer than tasks to complete and (hopefully) provide more organizational value.
From a customer perspective, there's a good chance that customers as a group don't care about the individual tasks you're working on. They want to know the value and timelines of your projects. One way to communicate timelines is through a roadmap that describes what work is in progress and what work is planned, usually for the quarter. Personally I'm confused at why some tasks, like installing software on a server, try to make their way onto our roadmap. The goal here is to inform your customers about how your projects are cumulatively making their lives better. Big picture stuff.
If you've been fixing bugs for so long you've forgotten what a project is, I'm sorry. It does take some experience to know what you should put in your Outlook Tasks and what you should put in your Product Backlog. What every team deserves is someone in the role of helping to guide the team's work - someone with the authority to create and prioritize projects, someone who interacts with customers. Someone like a Product Owner.
Technorati tags: Scrum Product Owner