En 2018, un ex empleado de Cisco obtuvo acceso no autorizado a la infraestructura en la nube de la empresa e implementó un código malicioso que eliminó 456 máquinas virtuales que Cisco usaba para la aplicación WebEx Teams. La ley negó el acceso a casi 16.000 usuarios de WebEx durante un período de dos semanas. Cisco gastó aproximadamente $ 1.4 millones en tiempo de los empleados para auditar su infraestructura y reparar los daños, y también pagó $ 1 millón en restitución a los usuarios a los que se les había negado el servicio.
Situaciones como esta han convertido el sabotaje de los empleados en un tema central para los CIO. Pero, ¿qué sucede cuando los problemas personales de los empleados que no tienen nada que ver con el sabotaje de la tecnología de la suciedad destruyen los proyectos?
Aquí hay una historia del mundo real para ilustrar:
Al principio de mi carrera en TI, trabajaba como programador junior en un gran proyecto de sistema. Cada semana, el gerente del proyecto actualizaba el progreso de la tarea del proyecto, pero varios de nosotros comenzamos a notar que los informes de progreso que se emitían no estaban realmente donde estaba el proyecto. En realidad, muchas de las tareas enumeradas como completadas estaban lejos de completarse. ¡Algunos ni siquiera se iniciaron!
El CIO no sabía esto. Confiaba en su gerente de proyecto y estaba promocionando que el proyecto estaba adelantado a su programación.
Varios de nosotros en el proyecto visitamos al director del proyecto, pero nos dijo que no nos preocupáramos. Finalmente decidimos llevar el tema al CIO. En ese momento, intervino el CIO.
Para entonces ya era demasiado tarde. La gerencia estaba enojada, el proyecto fracasó y el CIO, el gerente del proyecto y varios miembros del equipo del proyecto fueron despedidos.
¿Que pasó aquí?
Por encima de su cabeza y temeroso por su trabajo, el director del proyecto engañó al CIO sobre el estado del proyecto. Fue un acto deliberado y dañino, y destruyó un proyecto y las carreras de varias personas.
¿Se podría haber evitado la situación?
Sí, si el CIO hubiera hecho más “gestión caminando”, visitando a los miembros del equipo del proyecto y comprobando el estado en las trincheras antes de que el proyecto se retrasara demasiado. y si el CIO había tomado medidas para reasignar u obtener ayuda para el gerente de proyecto que estaba en problemas cuando el CIO descubrió que el proyecto estaba atrasado.
Este fue un caso de hacer muy poco y demasiado tarde al no reconocer que un empleado engañó en un proyecto porque el individuo temía por su trabajo y no quería dejar ver que el proyecto que estaba administrando estaba en problemas.
También puede surgir un problema de daño de los empleados al trabajo de TI cuando un gurú técnico se toma su tiempo para completar una tarea de ruta crítica en un proyecto porque no le gusta el proyecto o las personas que lo ejecutan.
Estos son problemas de recursos humanos que tienden a pasarse por alto cuando el liderazgo de TI tiene miedo de ofender a un gurú del sistema valioso cuyos servicios quieren retener, o cuando simplemente se sienten incómodos al confrontar al personal.
Desafortunadamente, cuando mete la cabeza en la arena, existe la posibilidad de que surjan problemas personales de los empleados que interrumpan los proyectos.
¿Cómo se crea un entorno en el que es menos probable que ocurran este tipo de interferencias en los proyectos de los empleados? Aquí hay cuatro opciones a considerar:
- Se agresivo. Habla directamente con tus gurús principales cuando parezcan probables los casos de obstrucción deliberada del proyecto y retrasos. Muchos gerentes de proyectos dudan en hacer esto porque temen alienar a sus gurús y que los gurús aún no produzcan para ellos en las tareas del proyecto. Esto puede suceder y sucede, pero no se puede decepcionar. Siempre hay consultores externos.
- Manténgase en contacto continuo con el personal de línea, así como con los gurús de la tecnología y los líderes de equipo. Cuanto más controle directamente el pulso de su proyecto y cómo se sienten los miembros individuales del personal al respecto, más fácil le resultará volver a poner un proyecto en marcha si ha perdido el rumbo.
- Trabaje de forma proactiva con los empleados de RR.HH. y con problemas para resolver los problemas cuando surjan por primera vez. Esto no solo ayuda a proyectar los plazos, sino que también permite a los empleados que están en problemas saber que usted y la empresa se preocupan por su bienestar.
- Fomentar un entorno abierto y comunicativo en el que todos los empleados se sientan valorados y escuchados, independientemente de las responsabilidades que estén desempeñando. Uno de los problemas que sentimos como programadores junior cuando estábamos en el proyecto discutido anteriormente en este artículo fue que el CIO simplemente no nos escuchaba. La lección que aprendí de esta primera experiencia cuando me convertí en CIO es nunca ignorar las palabras o los consejos de los empleados más jóvenes. Están en las entrañas del “barco del proyecto” y es más probable que vean primero los problemas del proyecto.
Qué leer a continuación:
Tratar con empleados descontentos
La crisis del talento de TI: dos formas de contratar y retener
No pierda empleados de TI durante la gran renuncia
.