When you are your own boss, things like responsibilities and project ownership are pretty obvious – you are liable for everything, period. However when working at an agency with projects coming and going, and sometimes resurfacing after even years of dormant life things get a bit more complicated.
At some point we tried to introduce project ownership. This unfortunately gets a bit problematic when you hit the projects that no one has any clue about and the original developer has left ages ago (or it can even be unclear who the original developer was!). It does mean that someone eventually will know something about the orphaned projects once they take responsibility for them. Though again in case that person moves on, the situation will start over.
Why should you even bother?
The idea of a “strong ownership list” came to me when I was looking at one of the fellow developers struggling with a change on one of my projects. Most people in the office have a few projects they have worked on pretty much exclusively. In this sense it makes no sense to get a random person to work on a change, as you lose out straight away just because, they need to gain access to the project, possibly download a copy of the website to their computer (for example subversioned projects…), get their head around the problem if it is something more complex than a text change, etc.
The difference is even more obvious when the owner already has everything set up (personally I do not remove my older projects from my workspace), thus removing the whole preparation cost. Also because of the familiarity with the project time savings can also be made at the stage of making the changes. You know the file structure, you know how objects interact, how templates are set up, so on and so forth. It might not always be the case, depending what exactly the change is, but it is a risk a project manager might be unnecessarily taking.
The benefits of strong ownership
This way we get back to the “strong ownership” approach. If the cost difference (say in time spent on the work) is negligible between worker A (the author) and worker B (any random developer), than the ownership would not be strong, and can be ignored for planning purposes. The same goes for a project without an owner at all – the preparation cost for any developer would be similar, the only difference possibly being developer skills, which is not a concern in this discussion. However when a a project (or the change to a project) is complex enough for the difference between assigning it to worker A rather than worker B to be significant, than applying a strong ownership list approach will save both time and frustration.
There is also one more benefit of applying the fore mentioned strategy. Under pressure of time, a developer unfamiliar with the project might tend to produce a solution which would not be optimal for the project as a whole. Especially in an agency environment, where time is of the essence, this could lead to patchy work in the long run causing more problems than it actually fixes. Often it can also lead to treating the symptom, rather than the problem in fear of affecting unknown areas of the project by digging deeper.