statcount

Thursday, 3 January 2013

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.

No comments:

Post a Comment