If I was to ask if you knew the difference between an epic and a project then you would probably think it was a strange question - everyone who's been involved with Agile knows what a project and an epic is... don't they?
Projects have things like business cases, budgets, stake holders, delivery teams, end dates, governance, business impact... Epics on the other hand are simply big user stories. The clue's even in the name - Epic is short for "epic story", and the term is usually used for discrete requirements that are too big for the team to deliver in one go.
However if you think about it, aren't all the aspects we associate with projects also associated with epics - albeit in a slightly different guise? Let's go through the list above:
Epics represent an investment in resource - usually one or two weeks of development followed by an ongoing support cost (however small). Like any investment, it's expected value should be understood, so it can be prioritised against other work. Once delivered, an epic is large enough to undertake benefits realization to confirm if the expected value was actually obtained.
A project budget is a way of documenting what the functionality will cost to deliver (usually in £s). Epics too have a cost of delivery, but as well as identifying the financial cost (see Business Cases above), the cost is also assessed in relation to the opportunity cost of doing other things during backlog prioritisation.
Whilst large projects may have multiple stakeholders pulling it in different directions, due to their reduced size, epics usually only have one or two. Using the "As a... I want... So that..." format for documenting epics helps to clearly identify who the primary stakeholder is for the work. When the epic is broken down into component stories it may be that additional stakeholders are identified.
By the time epics are broken down and delivered, the project team has usually been formed. This said though the epic may be assigned to smaller delivery units (such as paired developers) depending on what skills are needed.
On some occasions however epics are assigned to larger delivery teams (such as letting off shore resource deliver specific epics). Whilst these delivery teams are also usually in place, this allocation could happen after the epic has been identified.
Projects have an end date which is generated based on its scope (size) and budget (cost). Epics too have a known size (usually an estimate) and budget (the delivery team's capacity) and this is the basis of project planning / epic boards which show when the are expected to be delivered.
By sizing and breaking the epic down into a series of user stories, its delivery can be monitored using the existing Agile governance process used by the delivery team - whether that's fixed sprints ('Agile'), continual delivery (Kanban) or a hybrid of the two (Scrumban).
Both Epics and Projects make changes to the status quo, the only difference is the size of the change that is being implemented. Projects often undergo impact assessment at an early stage where the consequences of the change is investigated in context to the rest of the organisation. A similar process usually occurs during the epic inception where the epic is understood in more detail by the team. As well as identifying the scope, other aspects of epic such as technical approach, key Non Functional Requirements, and user experience... any necessary business changes are also investigated prior to the work starting on the epic.
So in summary a lot of the key artefacts and processes associated with projects are also encountered in one form or another with epics. This leads to the thought that if the only difference between projects and epics is really the size of the change we are introducing, then shouldn't the question be "When does a project become an epic?"