How to balance ownership and overprocessing?

Question

I am a project manager in a functional environment, focused on helping one of the key technical teams deliver products on time/budget/scope. The team consists of several very talented, very dedicated people who take real ownership of the work that they do.

Unfortunately this often gets taken a bit too far in the sense that, in my opinion, there is a lot of over-processing of work. This leads to an almost constant sense of crisis, causing unnecessary stress and risk of team burn-out. Depending on the product being developed, the team leader (to whom I report) is one of the prime culprits.

What is the best way to balance the team's disposition to taking ownership while convincing them (and my boss) that sometimes "good enough" is all you need and the product doesn't need to be "perfect"?

Answer 1

You are dealing with a specific personality type. Trying to 'change' him/her or get him/her to see the error in his/her ways is futile.

Instead, look at the process. In each of step in your process, you have entry criteria and exit criteria. When the work nugget finishes a step, it is not considered finished until it passes each criterion test. Same thing at the end of the process itself. Also, you would have a control there, at each step and at the end of the process, where there are rules about how verification and validation of the work piece is performed, who has the authority to sign it off, and allow it to continue in your supply chain.

It sounds like your work processes are not defined in this manner, which allows human intervention to run amok. Attempt to introduce this in your processes, established evaluation criteria, definition of finish, roles who are allowed to say finish, etc. Typical BPM 101 rules.

Answer 2

There isn't any direct relation between ownership and overprocessing. What I believe you look for is limiting overprocessing in a way that doesn't harm ownership and not a balance between one and the other. Actually, I'd say that you just look for a way to just limit overprocessing. Period.

It seems that one thing you miss in your team is common understanding of your goals or, which would be even worse, common goals at all. I mean, you, team members and team leader should all understand where you are heading and what is at the end. You should all share the same view of what is the outcome of a the project and of what quality it is. And then, what is needed to get there.

At the end of such discussion you may end up either agreeing that pursuing perfection is something you want, but you will also be aware that it doesn't come without cost. Another outcome, and the one you expect, is that you set the bar too high and you aren't willing to pay such high price within this project.

Either way everyone involved would understand what the goal is and what is needed to achieve it. Bearing that in mind everyone in the team should find it easier to fine tune their activities in a way which brings you closer to the goal.

It would be even easier considering that you work with people who have the sense of ownership. As long as they, as a group, own the goal their actions will likely adjust their behavior in a proper way.

Think of it this way: let's say that the goal is to have the first version of the app live before some date because otherwise something bad happens (your app doesn't follow law changes, a competitor gains the attention of early followers or whatever). If everyone in the team understands this, they will also understand (and see) that pursuing perfection with one of many features simply increase the risk of not making it on time. If such situation happens for the first time its impact may be ignored but delay built every time something similar happens would be hard to accept by anyone. I assume understanding this would simply change the attitude toward overprocessing.

Answer 3

Short, constant-time development iterations, where you have to make the deadline could help. If the issue needs improving and the priority of the improvement is high enough - then improve it as a task in a future iteration.

However, if the developers feel that the result is not usable/stable, then they should have the freedom of either improving it or not publishing it.

There should be a balance between quality and speed. - A perfect product that doesn't reach the market on time will probably be a failure. - A product that makes the market on time but is unusable will also probable be a failure. Try to explain this to the team leader.

Ultimately, the project manager or owner should have the final decision.

Answer 4

There is 2-part solution:

1. Business (project/product management) has to assert (in a sensitive manner since it is already a performing team and you dont want them to take it negatively) the fact that they are happy with good enough. Then they should make the stopping point visible, something like "ok guys here is where we stop..." This could be timeline, test coverage, functional coverage, UAT tests pass or whatever is relevant to the project. The earlier the end point is visible in the project the better it is.

2. To compliment the first part and to keep the team fresh and challenged, leadership has to come up with the next to do project/task for the team and try and make it visible towards the end of the current project/task.

Hopefully this could keep the team motivated.

Answer 5

It is entirely in the customer's hands. Good enough is only good enough if it meets the customer's needs/provides value to them. Turn the delivered work over to the customer. There word will settle all differences.

Answer 6

Hold your grounds. A boss will push as long as you say yes. I would say no 1 or 2 times and tell him or her why you can't get perfection: give him or her a fair explanation on how you and your co-workers do your work. Explain why you can't do more. Mention how people feel: stress, on the verge of burnout, etc. If your boss do not agree, ask for additional workers. It is not a confrontation, it is a way of reflecting to the management the limits you have as human beings. Explain that if you loose somebody for a sick leave, for example, it will be very costly for the compagny + hiring new and temporary employees. Challenge your boss with a no, but politely and with truthful explanations. If he or she is a good manager, he will listen because it is in the best interest of his compagny. Explain to him or her that they will make more money that way.