Finding the True North for Quality Management

My official title during the last year has been " Quality Management Office Analyst". There are different interpretations to it. The word "Quality" does not help because the first thing people have in mind when they hear that word, is "Quality Assurance". When we say "Quality Management", we mean Processes, but it is like saying to someone "Don't think of an elephant" and actually expect that they won't have an elephant in their mind. I am saying all this because we have been struggling for a while to come to a consensus for our team Vision. We all seem to want the same thing and create the same target system, but someone is always coming up with a different variable that when injected in the previous system, it changes the target system. Is related with the theory of system hacking I guess.
On our team site, we have this blurb where we have tried to encapsulate what we are trying to do:

"Our team is devoted to support continuous improvement in (insert here company name) product delivery.Our goal is to improve customer satisfaction with reliable and predictable product deliverables."

 

I guess it is not bad, but there is something there that doesn't make me (and some other people on my team) happy. We can't call this our "True North". 

Last week, I was trying to pick my next book to read. I had two options, Toyota Kata and Management 3.0. While debating over them, Andrew Annett "pulled" me toward Toyota Kata. So, that has been the book I have been reading during the past week and I am somewhere in the middle. For all of you out there that have read this book, you know where my mind is right now. I am now in the process of comparing how we are doing things now in our company, and how Toyota is doing them. I know that Toyota is a Manufacturing company and we are an Insurance company. But Toyota's strength is not on dominating the Manufacturing market. Their strength is on the way they think, and that is a feature that is independent of the market, independent of the service, independent of the product that a company delivers. 

This way of thinking, is drawing me back to the Vision of my team. I guess the easy thing is to take Toyota's vision and apply it to my team's:

Toyota: "Survive long term as a company by improving and evolving how we make good products for the customer"

My team: "Live long as a team that improves and evolves the process delivery of the company"

Although I know that this is just a draft and some cosmetic patting is required, I am still not happy with it. The problem is that we are looking at our team as a permanent team in this company, without an exit strategy. I know that a company needs continuous improvement and from that point of view, I can say that we should always be part of this company. But that statement gives me a sense of failure, not able to ever celebrate success. Makes me think we will never reach a desired target state, because there is always something to improve.I think that part of the continuous improvement is also the fact that my team, at some point, should not be required.

And that's where I got a Eureka! moment. Rather than adding to our Vision what we want our team to be, I thought to add to our Vision what we want the company to be. So, again, in a draft mode, fully aware of the need for cosmetic changes, I came up with something like this:

"Get (insert here company name) to a state where Continuous Improvement is natural element of the Vision of the company and all the structures in this organization"

I am happy!! Why am I happy with this?

I like the fact that we have:

• An end goal
• A way to measure the  Success Criteria.
• A clear set of Recipients that will run with it, on their own, with a clear understanding on what to do
• It's recursive (ok, that's the geek in me!)

I like the fact that we want to create a Sustainable System, where the need for improvement will be organic, not injected from my team or any other external team. The mindset of Managers at any level will be on the Continuous Improvement of the current process, whatever that process is at any point of time.

Now let's see what others think. Feedback appreciated!

Deming's right!

In an environment where teams are not stable and people are considered resources, all the focus of People-Managers is how to juggle around people from one project to another project or to a Severity 1 issue with Production. It gets complicated when you add here roles like Project Managers that have tight deadlines to reach and they have planned to deliver with a certain number of people assigned to their projects. So a conflict is inevitable between these two parties.

On one side you have Projects Managers, with 100% focus to release their deliverables. They have all the training out there (minted by a lot of certificates and organizations with big names and high prestige) to protect the people on their teams and keep them focused on the most important stuff. They have a "big fight" at the beginning of the project to get the right people on their projects and make sure they are allocated 100% or at least 50%. Once they "won" that battle, then they move in protective mode, where they must make sure that these people are not pulled onto other tasks. In some cases, they are so protective, that even when the people on their team are done with their tasks, the PM doesn't let them go, just because they are assigned 100% to that project and there might be some defects coming up. .

On the other side, you have the People-Managers (for developers, testers and analysts), that are faced with all the  requests for what work needs to be done, and they should allocate their people to the right projects and at the right percentage of time, as per their skills. But when another project comes up, or a Severity 1 issue comes up, they are left with the need to ask for someone to put a project on hold and get to this new task.

So the "battle for people" begins. A person that is promised 100% to a Project Manager, can't be pulled to another task. Even if that person is done with the project. The definition of done is a grey area, especially when testing is not done right after the developer has submitted the code. This gives the PM the right to keep this person assigned to his project in order to take care of defects that will be found. But the People-Manager can use the time of this person on another task, until defects are found and prioritized.

Guess what the people feel like?
One synonym I can think of, is like a child that is being pulled on the left arm by his mom and on the right  arm by his dad, while these two parents are fighting with each-other  and are telling the child "I love you more, stay with me".

Nobody is asking "What does this person like to do? In what direction does he/she wants to grow professionally? What is a task that would bring excitement on this person's career?"
So on a setup like this, looks like Deming's brilliant phrase : "A bad system beats a good person all the time" is very true. They are all good people. They're all focused on their goals. All of them want to succeed. But they are all trapped in this environment where people are allocated by time and not by task. Teams that are created for a project rather than bringing the project to a stable team. Environment where trust and collaboration does not exist because the common goal is not clear.  Environment where deadlines are set without asking the people that will actually do the work. Environment where it is not safe to call out a project that is going downhill because it is consider as failure.

I don't have a quick fix for that and I don't think it is an easy one. But rather than try to work with PM and People Manager on how to manage the people better, I'd rather take the long and bumpy road to fix the environment that creates these issues.