Manejo de miembros del equipo no calificados / desmotivados

Soy un director de proyecto, para un proyecto importante en la escuela. Uno de los miembros de mi equipo se había unido al equipo como desarrollador, sin conocimiento de idiomas particulares. El miembro ha pasado casi la mitad de la duración estimada del proyecto sin contribuir. Toda la carga adicional de desarrollo ha recaído sobre mí, ya que soy PM y responsable de ello. Durante las reuniones, el miembro siempre asiente, está de acuerdo y acepta trabajar en un plazo determinado. Pero cuando la fecha límite va y viene, no hay absolutamente ninguna respuesta. No quiero quejarme, pero estos son los hechos, de verdad. Paso la mayor parte de mi tiempo casi como niñera, revisando la codificación con el miembro y explicando cómo codificar durante las reuniones individuales.

He tratado de dar tiempo adicional para que el miembro se ponga al día y pasé tiempo tratando de entrenarlo. Casi todo se ha desperdiciado, porque el miembro está demasiado ocupado con otro trabajo importante, o demasiado lento para aprender o simplemente incompetente o perezoso.

¿Puede darme alguna sugerencia sobre cómo puedo alentar al miembro a dedicar tiempo y esfuerzo sólidos para contribuir al proyecto?

dejar al miembro fuera del equipo es muy poco profesional, pero ¿debería considerarlo si se convierte en un problema demasiado limitado de tiempo? ¿O debo seguir usando la política de solo recompensa? Estoy un poco frustrado y no sé cómo proceder.

Gracias-Egon.


Bueno, como se sugirió, el miembro del equipo ahora está preparando diapositivas, escribiendo documentación y todo ese trabajo secundario. Gracias a la gente por ayudarme a tomar una decisión.

Ahora imagina que la mitad de tu equipo es así... FML

Respuestas (7)

Comience a denunciarlo por incumplimiento. Cuando obtenga suficiente documentación para satisfacer a Recursos Humanos, despídalos.

Durante las reuniones, el miembro siempre asiente, está de acuerdo y acepta trabajar en un plazo determinado.

El 02/03/2011, Wally accedió a completar doohickey_12 para el 7/3.
8/3: Doohickey_12 no completado. Wally dice que tomará otra semana.
15/3: Doohickey_12 no se completó. Wally dice que tomará otra semana.

Haga esto para cada artículo del que Wally sea responsable. En caso de que olvides quién es Wally, él es el tipo con lentes en el cómic de Dilbert .

sacar al miembro del equipo es muy poco profesional

No, no lo es. Simplemente están desperdiciando su tiempo y energía, así como el dinero del empleador.

Si odiabas por completo a otro gerente, podrías hacer que Wally pareciera un héroe y conspirar para que el otro gerente te lo "robe". En el mundo de los negocios, hay tantos Wallies que Scott Adams no tiene que ir muy lejos para encontrar el humor.

Si te encuentras en una situación en la que no puedes despedir al tipo y no puedes deshacerte de él, haz que prepare café y vaya a almorzar para el resto del equipo.

+1: uno de mis compañeros de trabajo me recomendó usar una hoja de cálculo para documentar los problemas. ¡Es una gran sugerencia!
+1: un mal miembro del equipo no solo será una pérdida de dinero, sino que afectará la moral de todo el equipo.
@Erik tiene razón. Esa persona está creando productividad negativa para todo el equipo.

PMBOK dice que cada problema en un proyecto es una falla personal de un gerente de proyecto. Repasemos sus errores en el escenario explicado. Espero que esto te ayude a cambiar.

Toda la carga adicional de desarrollo ha recaído sobre mí, ya que soy PM y responsable de ello.

Usted es responsable de la gestión , no del desarrollo. Tan pronto como comenzaste a hacer su trabajo, cometiste un grave error.

Durante las reuniones, el miembro siempre asiente, está de acuerdo y acepta trabajar en un plazo determinado.

Las reuniones no son para aceptar. Las reuniones son para discutir. En lugar de preguntarle en una reunión, debes crear una lista de tareas, enviarle un correo electrónico y pedirle presupuestos . Él debe proporcionar los plazos, no usted.

explicando cómo programar durante las reuniones uno a uno

No debes explicar. Tienes que establecer estándares de calidad en tu equipo y dejar que él los obedezca. Tienen que estar por escrito, esas normas.

el miembro está demasiado ocupado con otro trabajo importante, o demasiado lento para aprender o simplemente incompetente o perezoso

No es perezoso ni lento. Es inteligente porque todavía está en tu equipo y tú sigues cuidando niños. Mi consejo final es volver a las "reglas básicas" de su equipo y revisarlas. ¿Son explícitos? ¿Explican la motivación de cada miembro del equipo? ¿Explican "recompensas y penalizaciones" (¡no monetarias ante todo!, léase Recompensas o Penalizaciones? ¿O simplemente recompensas? )

La declaración de PMBoK es demasiado dura en mi opinión. Este es exactamente el tipo de cosas que hacen que el PM junior tenga miedo de administrar proyectos. Si bien todo lo que dice es cierto y su consejo es bueno, todavía diría que el principal responsable de esto es el empleado que no contribuye. Tiene razón al señalar que es responsabilidad del PM arreglarlo, pero la causa principal es el empleado en este caso (caso en cuestión: aparentemente, otros miembros del equipo no se están comportando mal, lo que sería el caso si el PM fuera constantemente malo)

Si el desarrollador ha acordado un entregable, debería obligarlo a cumplirlo.

Pero cuando la fecha límite va y viene, no hay absolutamente ninguna respuesta.

Tan pronto como no esté entregando, debe escalar el problema. Usted es responsable de garantizar que el proyecto se entregue a tiempo y responder a las partes interesadas, en la actualidad, parece que es un gran riesgo para los proyectos. Todos los acuerdos de plazos deben documentarse, y si hay un incumplimiento persistente de estos plazos, lo profesional es discutirlo con él, y si no hay mejora, dejarlo ir.

Es encomiable que esté colaborando para cubrir las deficiencias de los desarrolladores, pero la preocupación es que su atención se centrará más en lo que él está haciendo que en todo el proyecto.

Dejar que su proyecto se vaya por el desagüe y saber la razón todo el tiempo, eso sería poco profesional.

Entonces, a menos que este proyecto sirva en parte como una capacitación para su miembro del equipo, pero deduzco de su descripción que no era la intención, tendrá que actuar.

Entonces, o lo acepta, pero luego tendrá que hablar con su gerente o steerco y pedir más tiempo/presupuesto y/o ayuda adicional. Tendrá que hacer esto de todos modos si no hay otra alternativa disponible.

De lo contrario, confronte a la persona con el impacto de su comportamiento en el proyecto, hable con su jefe al respecto, y si no cumple (diga dentro de la semana si puede mantenerlo por más tiempo) no hay otra opción. sino dejarlo ir.

No 'esperes' que las cosas simplemente sucedan o que mejoren. Como gerente de proyecto, deberá hacer que sucedan.

Absolutamente nada poco profesional en dejarlo ir. Tú no estás fallando, él lo está.

Aquí hay otra publicación en este sitio sobre Motivar a un miembro del equipo en un proyecto universitario que puede ayudar.

No estoy de acuerdo en que "tú no estás fallando, él sí". Si alguien en un equipo está fallando, es culpa del PM, ante todo. Para eso está el jefe de proyecto.
@ yegor256 no es realista creer que un gerente de proyecto (o cualquier persona, para el caso) puede controlar a otra persona. El PM puede tomar las decisiones correctas para un proyecto dado lo que sabe sobre las personas involucradas. Pero el pm no puede controlar a otras personas.

Estoy completamente de acuerdo con el punto de @Tangurena sobre el uso de una hoja de cálculo; esto ha sido muy útil para mí en el pasado.

Además de la fecha límite diaria que falta, también registraría cualquier otra posible mala conducta:

  • Específicamente, pídale que le avise antes de sobrepasar una fecha límite (25% de la duración de la tarea por adelantado) y registre si no lo hace.
  • Si intenta culpar incluso a un menor en otro lugar: registre, investigue, refute (si es posible) y registre los resultados.
  • Evite la mezquindad, pero no obstante, mantenga un registro de las cosas pequeñas: la mezquindad hace que parezca personal, pero a veces las cosas menores resultan tener un impacto mayor de lo esperado. Las entradas en exceso se pueden filtrar antes de que el documento se utilice en serio.

Además, si está trabajando en otro lugar, ¿es para otros gerentes? Si es así, discuta la situación con ellos para ver si están sufriendo los mismos problemas. Sin embargo, tenga cuidado, en los extremos, esto puede terminar con un nuevo aliado o descubrir que ya ha sentado las bases para socavar sus acciones ("Egon es tan irrazonable, y claramente lo tiene conmigo personalmente").

Consejo final: paciencia. Recuerde darles toda la soga que sensatamente necesitan para mejorar o fallar, y solo tire de la soga cuando sea necesario y decisivo.

Recientemente me hice cargo de un equipo de diseñadores gráficos y actualmente me enfrento a un desafío similar con uno de los miembros de mi equipo. En repetidas ocasiones ha mostrado una falta de compromiso con el trabajo que se espera que complete en los plazos que se le han asignado.

Así lo estoy abordando.

Paso 1: Dado que ya estaba bajo un plan de desarrollo informal (léase sin la intervención del equipo de recursos humanos) con su gerente anterior, revisé su Revisión de desempeño de diciembre y el traspaso proporcionado por el gerente anterior.

Paso 2: Luego senté a la Sra. X y le dije que este es el documento de transición que me dieron y en el mes que he estado aquí, así es como veo su desempeño y estado en el equipo. Luego le di la oportunidad de explicar los desafíos que enfrenta para comprender las expectativas o cumplir con los plazos. Me comprometí a ayudarla a resolver estos desafíos siempre que ella se comprometiera a trabajar conmigo. Ella hizo.

Paso 3: Aquí vino la poderosa hoja de Excel. Creé un expediente donde documenté lo siguiente: configuré la revisión de desempeño del año anterior contra cada objetivo. - revisión mensual contra la revisión de este año. Se le pidió que se marcara contra cada objetivo y evaluara dónde se encontraba. - Rastreador de pruebas de calidad para cada proyecto a través de los registros - Rastreador de diseñador (actualizaciones oportunas, errores editoriales, errores de proceso, etc.) - Agenda 1: 1 (de ella) y un resumen de lo que hará. Cada Agenda incluía su propia revisión de lo que hizo con lo que esperábamos de ella.

Paso 4: Dado que ninguno de estos registros diarios/semanales/mensuales funcionó, me senté a escribir mi plan de desarrollo formal (leído y enviado a Recursos Humanos) para ella. Este documento fue compartido con ella y firmado por ella en presencia de un representante de Recursos Humanos. La hoja de Excel resultó útil para proporcionar "evidencia" de bajo rendimiento frente al rendimiento esperado en la empresa. Pude precisar el proyecto exacto, las fechas, los problemas de rendimiento y su respuesta por la falta de. Este documento describía específicamente que si este plan de desarrollo no funcionaba bien, sería despedida. (le puso el susto del diablo, pero funcionó)

Paso 5: ella ha estado en el plan de desarrollo durante 3 semanas. El plan de desarrollo de un mes finaliza la próxima semana, pero parece que recibirá una excelente revisión mía y del representante de recursos humanos.

Paso 6: si su desempeño cae en calidad y eficiencia después de este plan de desarrollo, será "retirada". No hay nada "poco profesional" en esto. Una manzana podrida echa a perder el resto.

Espero que esto ayude.