Identify the Owner January 1, 2008Posted by Darth Sidious in Managing Employees, Project Management.
You’ve heard the saying, “Too many Sith Lords in the Command Ship”, I think you earthlings have a similar saying of “too many chefs in the kitchen”.
Collaboration is great, and should be a natural part of your organization’s culture – but issues and confusion will arise if owners of areas aren’t clearly defined.
Whether it’s fighting a crisis, issue resolution, routine tasks, domain areas, to projects – there has to be ONE owner. Otherwise it’s unclear where information ultimately needs to flow up to, and what the chain of decision making needs to be.
Is your technical staff on-call? What if that pager goes off, but it’s not in that persons particular area of ownership or expertise? The person on-call is the owner – the owner of the alert, and they have the power to rope in the subject matter experts needed, and/or the owners of such areas. Ultimately the resolution of that alert is theirs.
On a Project, there has to be a single-owner. Don’t confuse this with sponsors and supporters of the project. The owner of the project is ultimately responsible for getting the project done.
Do you have a Database team? There has to be someone who owns the maintenance plans, data architecture, schema design, database change policy and processes, etc… It doesn’t mean they have to come up with all the ideas, and all of it could be the result of the team collaborating on what the best practices need to be. And it doesn’t mean they have to do all the work. But the owner is responsible for making sure that that collaboration occurs, gets documented, and somehow enforced.
When fighting a business crisis or a technical one – make sure the owner is clearly defined. Otherwise people are going to naturally float decisions up their management chain, it won’t be clear whose making the decisions in the first place – so you get this decision confusion that results in latency as everyone tries to sync up on who decided what.