What exactly is the meaning of taking ownership in a project? I have heard lot of managers say this. Since this is very commonly used and at the same time, not part of formal education, I want to know what exactly is this concept of Ownership(, its origin if possible) and why is it so much important from the manager's context, and how is it useful for the project/company
Taking ownership is not just doing a job, or working on a project; it means making it your mission to see it through.
Don't look to others to address issues; instead look for problems before they become obvious, and find and implement solutions.
If you can't fix it, then don't just toss the responsibility to somebody else; track down the person who can fix it, and make sure they address the issue.
It isn't a stated role on a team; in fact the project doesn't even have to be a team project.
Why does management like to see employees own the project/process/job; because that means that they care. They have moved beyond just showing up for work. They now want to see the project succeed.
In situations where nobody took ownership for a task; that task many times failed, or was completed late, or completed sloppily. Because nobody cared.
People relate to projects in many roles. Ownership is one of them (A ROLE).
Other important roles include champion, sponsor, vendor, client and manager.
The owner is the person who's overall role is to see that the project is completed. Their role is to ensure that all the above roles are filled and working together in concert to complete the project. This is more a social or political role than an operational one.
Dual roles are often present and muddy the waters a bit. Inappropriately exercising roles can lead to poor performance of the project. A good PM will spot this and try to correct it - usually through the owner. This can lead to a head on clash e.g. the owner and sponsor refuses to pay a supplier for work completed and accepted according to contract, the PM objects.
If any of the roles are not being fulfilled, the owner needs to 'take ownership', be responsible and correct the problem. You are to act as a proxy for the true owner.
Likewise for tasks that go to make up a project, the project management team might assign a person or group to 'take ownership', i.e. to own the responsibility to see it through, as several of the responses suggest. Ownership entails taking care, responsibility and the attitude that the thing is your very own. The project manager's triangle (quality, cost and time) needs to be balanced in the best interest of the owner. You are to serve as their proxy.
See pmi.org for further details, Kerzner has a weighty book simply called "Project Management".
It is important to distinguish between ownership of the project and ownership of the artifact. These are entirely separate in the roles/responsibilities matrix.
On big projects roles are distinct and bounded.
On small projects, one person may be 'Big chief, cook and bottlewash'
Disclaimer: This is my experience of only one office in 3 distinct countries and can't be generalized but this is exactly as it went.
I had to upgrade a database from a version X to another version Y in Thailand, China and Japan.
When a database is migrated, the application needs to be patched, new client version is installed and a lot of third party application relying on it, needs to be tested too.
In Thailand, no one took ownership of anything, they all looked to me for anything that wasn't working because it was my "fault". Needless to say, the migration to the new database version was long and tedious.
In china, the manager of the branch took ownership but not so much the employees. The migration went a little better because he was giving tasks to his team as problems were encountered and it really helped speed up the migration.
In Japan, each individual took ownership of their piece. They tested everything from end to end and I never had to ask if it was done. We encountered some problems, they would go work some more on it. No questions asked.
The migration went flawlessly. Everything worked on the first day after the migration.
This is the difference taking ownership makes.
I gave an invited keynote lecture at Software Methods and Tools 2000 in Wollongong with the state of project management being the topic, and you asked:
I first started hearing it in the mid-1990s in Silicon Valley, which is also the time when "Project Manager" started to be a career of sorts, and distinct from "management." I then moved to the East Coast (of USA), and a few years later the phrase arrived at the bank where I worked (c. 2000), although I am not implying that I brought it with me. At that time I managed a group of project managers, thus clearly separating the two types of managerial activities, projects and people.
The management vocabulary is as limited as it is trendy. For example, about this same time the euphemism resources became a soft, squishy substitute for people, as well as machines, buildings, and money. "How many resources are assigned to this project?" is probably a phrase you have heard.
The phrase "George owns this project" is currently (2016 / IT and Academic environment) equivalent to saying "George is the general contractor for the extension on my house." The owner of the project is sometimes identified as the Project Manager, which I think is inappropriate, and strips all of the meaning from the word owner.
The true owner of any project is the person who can negotiate the deal for the people and money to get the job done. Seldom can traditional PMs do this; they report the status, organize the work, search for the people or money, answer the complaints, and sometimes take the heat. These facts push the real ownership onto the customer -- only the customer can say "OK" to the allocation of more funds or schedule slips. In this context it appears that I own the project to put an extension on my house. I can sue the general contractor if things do not go well, but that is the extent of my recovery for bad execution ... as opposed to bad decisions on my part.
I have my doubts that it is. Note that none of the things discussed here ...
... are real. They are unlike customer and vendor which tell you who is paying, and who is being paid. Customers and vendors are real, and they will be around forever.
It's not the literal definition of owning something, but you behave as if you do. This is the difference between a waiter who brings you food that is obviously undesirable compared to one who gives it back to the kitchen, alleviates your concern that your food is taking too long and ultimately brings you a properly made dish.
The restaurant owner who truly promotes waiters taking ownership of their client's dining experience, isn't going to tell the waiter to only return food to the kitchen if the customer complains.
It helps if you know at least the general guidelines for what is the acceptable level of quality of the projects. There were times I've been a manager and there were some projects where I had no desire to get involved nor any knowledge on how to make it work, so I gave ownership to someone I thought would do a much better because the person was qualified and took pride in what they do.
For some people, they don't take as much pride in what they are doing if they are constantly told exactly what to do. Something as simple as tightening a nut on a bolt in an assembly line can lead to poor quality if they just "do what they're told" and fail to alter the task when they know the quality is suffering. Wouldn't you want every working who put your family's car together to act like their family would be riding in it? That's taking ownership.
I find that it is usually a positive way of stating a negative: Your boss does not like NMP/NMF attitudes ("Not My Problem" / "Not My Fault") on the team.
NMP/NMF workers are poison to a team and are usually targeted for removal from the team if the manager can find a way to do so.
EDIT: Per @Chad's suggestion to explain WHY this is important.
The attitude of NPM/NMF individuals is focused on themselves.
"I didn't do that part of the system, so that's not my problem."
"That bug was introduced by "Jim" so he should fix it, not me - not my fault."
This attitude does not put the success of the objective first.
But, the goal of "owning" an objective is to put the objective first and that is important because management knows that requests and issues will be handled by the team and not forgotten or discarded:
"I didn't do that part of the system, but I do have some time, so I'll take a look at it and see if I can put your enhancement in, but, if I find that I cannot take care of it, I'll talk to someone who can."
"Yep, it looks like Jim created a bug, I'll take care of it right now."
OR as per an example in the comments:
"I'm sorry, I'm the database guy, if you want to enhance the gui, you'll have to talk to "Bob" - he's not here right now - so I'll let him know to contact you asap."
"I'm sorry, I'm the database guy, so I cannot fix the problem for you, but I can point you to someone that can."
In all of the "good" cases above, the focus of the team member is not explaining to management why they don't have to do the work. Instead, the focus of the team member is on finding a way to make sure that the work gets done.
I regard this terminology as a red flag, much of the time, particularly when coming from management.
The basic idea is that they want you emotionally invested in making whatever it is happen, working whatever hours and schedules are needed, sacrificing other activities, etc.
If the project was your idea in the first place, and seems important to you, then you are quite likely already doing this, though perhaps not to the extent of totally destroying work-life balance. So if management is asking you to do this, then it's not a project you actually care about, and they know it. Perhaps you figure it's doomed to fail. Perhaps you figure the results would be useless or counterproductive. Perhaps you can easily think of ten more important things, and wish to put your effort there.
Now that's not always true. It's possible they are trying to communicate e.g. that they want you encouraging other people and orchestrating their efforts, not just doing your part of the task. (This might not work so well if you aren't a people person, and don't have authority, but for some people it works well.)
It's also possible they are trying to give you gentle guidance away from a "not my problem" attitude, as described in one of the other answers. It's usually true that the more senior the person, the more scope they take on - and one way to become senior is often to take on increasing scope. In technical fields, you probably don't have to wait to be assigned that scope - just follow any problems wherever they lead, rather than hastily passing them on to some other team, who might have better knowledge.