How To Use the Strong Ownership List

Some time ago I wrote about the idea of the Strong Ownership List approach. A recent comment on that post has made me realize that for the idea to be better understood and easier to apply I probably should describe the process it involves in more detail.

Strong Ownership Definition

The whole concept is based on some users being predisposed to undertake certain work more than others. I mostly concentrate on project ownership and knowledge about it, however the concept does also acknowledge different skill levels between various employees.

The idea is best suited for agency environments where there always is a certain base of projects requiring maintenance work, as well as new clients. As over time employees come and go some projects can be left orphaned, especially if the maintenance is not ongoing, but rather tends to come back say every year or two.

Let us assume we have 3 employees at an agency called A, B, and C of similar skill level. We have the following 4 projects that need some work done:

• P1 – built by A
• P2 – new project
• P3 – project worked on by B and C
• P4 – old project none of employees built nor worked on

The simplest application of the Strong Ownership List would suggest the following:

P1 – A is a strong owner

P2 – A, B or C can be assigned as strong owners based on skill and availability

P3 – B and C are strong owners

P4 – again any of the employees can be assigned, depending on the circumstances this can be either strong or weak ownership

The specifics of these will be discussed in further detail later on.

Now the Strong Owner status gives that person the responsibility over the project. It does not necessarily mean that A will do 100% of work on P1, but he would be expected to be aware of were the project is at and be able to point for example B or C in the right direction if they are assigned to complete a task on P1.

Why Do We Need Ownership

Before we go into any further details we should establish why do we need project ownership in the first place. Considering our hypothetical A, B, and C are equally skilled they should be equally well suited for the job… If only life was that simple.

An often overlooked part of development is the setup time. This is even before we touch on things like “getting into the zone”. However the project is managed, be it subversion or ftp connection, the person undertaking the work needs to obtain all or some of the files and setup their environment. Passwords need to be found, as well as connection details.

Next there is the brief. An employee familiar with the project is able to understand the problem quicker, while a newcomer will need a full description of the project, where the problem is, how something should behave, and so on. Certain things will be obvious to a project owner, while for any random worker they might not only be harder to grasp, but there is also the chance they might be misunderstood.

Knowing the client can be another good point. And it does not matter if you just dealt with them via email, or had a hundred meetings in person. While working on a project a certain kind of rapport is developed that helps the employee better understand the client’s expectations and apply the most suitable solution for that particular client-project combination. This can be crucial, as the same project under a different client could have a totally different take at things. In this sense a random employee would not have the benefit of this insight resulting in longer communication, client frustration at being misunderstood, or even worse delivery of something not matching the clients requirements.

More Than One Strong Owner

I probably have not mentioned this previously, but Strong Ownership is not exclusive, a project can (and probably should have – more on this later) more than one Strong Owner. One person could possibly take a more leading role.

Just like in the P2 example when more than one employee is involved in a project and they gain similar level of experience relevant to it by working together, they would both become Strong Owners. However when for example B has done 80% of the work, while C has been doing some ad hoc support on the project under B's direction, then B would become a Strong Owner. Depending on the level of involvement C could possibly be a Weak Owner.

Weak Ownership

One might be tempted to think of it as the opposite of Strong Ownership, however it is more of a lesser version of it. Consider the following order:

1. Strong Ownership
2. Weak Ownership
3. No Ownership

Weak Ownership is the intermediate step between a person not being involved in a project and a person who is responsible for one.

Ownership Of a New project

It is all great in theory, but let us have a look at some concrete examples. To start of, an easy case – a new project needs to be allocated to a developer (or developers).

A, B, and C might have equal skill level, but they are all individuals. This said here is a list of things a project manager might consider when deciding who to assign:

• Employee availability and other project workload
• Previous experience with the client on a different project
• Previous experience with a similar project
• Personal preference (A likes Content Management Systems, B is fond of ecommerce, and C would love to do some ActionScript…)
• Overall worker experience depending on project complexity
• Employee skill level (we assume A, B, and C are equal, but in real life differences are inevitable)
• Number of already Strongly Owned projects

These are just some examples, and the list could go on.

The last point on the list is not crucial, but is a good reminder about even resource allocation. Just as you do not want all projects to depend on one person, you do not want every one to do everything, more on this later.

Ownership Of an Old Project

By old projects I am referring to the orphans briefly mentioned at the beginning. These are the unwanted and dreaded projects that probably no one has a clue about. Usually they just get bounced around like a hot potato no one wants to deal with.

The above list used for new project assignment could probably be a good start guideline for who to give the ownership to. As long as the employee matches the skill set required for the job it is down to more prosaic dilemmas like who actually has time to do the work.

Old projects are also similar to projects with a single Strong owner, who leaves, and no Weak Owners. The difference in such situation is that contrary to already abandoned projects the later situation can be handled by for example a properly done handover, which would create at least Weak Owners or in best case a new Strong Owner.

Solving the Isolation Problem

An employee in charge of a project leaving the company can cause quite a stir and create orphaned projects. However this assumes that at all times the Strong Ownership List approach is used in its strictest form and with one Strong Owner per project.

In this sense the method could lead to work being highly dependent on certain individuals. The trick is to apply the system based on task urgency and complexity.

What I mean is say there is a small change to be made, that does not necessarily require massive knowledge of the projects structure, neither does it affect any processes in it. In such case if the project manager is willing to “sacrifice” the extra cost of initial environment setup for a No Ownership employee, then it is a good way to slowly “promote” a worker up the ownership ladder.

Obviously this requires the project managers to do cost weighting. It doesn’t necessarily have to be restricted to simple tasks. Depending on time and budget one of the two approaches can be taken considering we have a Strong Owner A and a Weak or No Owner B.

Advised and let go – where A (possibly together with a PM) does the initial brief to B, possibly outlining steps that need to be taken, hinting at the best approach etc. After this B goes of and does the work himself, possibly consulting with A in case of problems. This assumes B can spend the extra time on the task without straining the budget.

Shadowing – if the task is urgent but B is allowed to spend some time on learning how the project works A can do the work while being shadowed by B. This could be especially worthwhile with complex systems, as extra comments can be passed about the projects inner workings while the task is done. This means the work is done at the altogether quicker speed however either the learners cost needs to be either forfeited or passed on to the client.

The Ideal World vs Agency Work

The above might straight get some people saying – “but there never is time!”. And in some way you would be right. Learning processes always come at a cost, and it is a sad reality that very often this is overlooked by project managers or even higher superiors.

The bottom line would be comparing two costs (or three as we will see in a moment). Does the cost of using one of the above methods of preventing project isolation outweigh the cost of training someone up as part of a handover period. This should be part of more long term thinking on the side of project managers, and at the end of the day it is up to them to choose between short or long term gain.

The third cost to compare against can be the result of too many short term solutions. We assume above that a proper handover is done when an employee decides to move on for one reason or another. Unfortunately sometimes instead of passing on their knowledge they could be kept involved in current matters almost up till the end of their term.

Again it is down to a sort of greediness. Training takes time away from two employees – both the trainer and the trainee. While in the long run it definitely will pay off to perform a proper hand over if project managers are more focused on finalising current tasks it can lead to them overlooking that long term benefit.