1

Project Management: 15 “secretos” sucios que debe reconocer

Anterior1 of 2Siguiente

Veamos algunas de las solicitudes – delirantes y desesperadas – que garantizan el desastre en el Project Management de cualquier proyecto y gestión de TI.

Para los sistemas de negocios, la fecha en los proyectos que “corren en vivo” realmente importa y los jefes de proyecto parecen dispuestos a sacrificar los límites presupuestarios con más frecuencia de lo que están dispuestos a ir más allá de un plazo programado.

Hay razones comerciales sólidas para hacer esto como lo son bonificaciones, comisiones y valoraciones de las acciones que dependen de los ingresos y ganancias en el trimestre.

Así que usted no desea hacer cambios que pudiera estropear los resultados trimestrales, pero desea implementar cambios lo antes posible del trimestre siguiente. Ahora el problema: tienes un par de días adelante, y la presión de tiempo para cortar y hacer el cambio sólo va en aumento.

Por ello, el índice de inteligencia colectiva del equipo de proyecto sólo disminuirá. Para la semana de finales de julio, todo el mundo estará presionando para un corte y cambios al nuevo sistema para que todos puedan tener sus bonos en el Q2.

Síndrome Caperucita
En el empujón final para el release, en el departamento de Project Management se escuchan todo tipo de sugerencias que están bien intencionadas para tomar un camino que, se supone, es más directo y menos tortuoso como:

  1. Escatimar alguna prueba de TI y enfocarse en las de integración.
  2. Realizar pruebas de integración y de aceptación del usuario en paralelo.
  3. Saltar la configuración del control de sobrecarga.
  4. Que haga la depuración y las correcciones directamente en producción.
  5. Saltar algunos de los casos de pruebas más difíciles, sobre todo los de integración.
  6. Realizar pruebas funcionales sólo para los primeros tres casos de uso.
  7. Cambiar la prueba (por una más fácil) de aceptación de usuario para los equipos remotos.
  8. Preocuparse acerca de la calidad de datos después de entrada en funcionamiento.
  9. Traer un equipo de tigres adicional a su personal.
  10. Conseguir consultores que trabajen doble turno.
  11. Olvidarse lo que se está haciendo sobre procesos de negocio en validación y código de comprobación.
  12. No encender todas las integraciones hasta más tarde y hacer actualizaciones de datos en la noche para mantener las cosas un poco sincronizados.
  13. Darle vuelta a la instantánea del nuevo sistema que tiene bajo impacto sobre pocos usuarios, por lo que puede demandar la entrada en funcionamiento a pesar de que los usuarios de levantamiento pesados ​​están todavía en el antiguo sistema.
  14. También necesita algunos recursos ultramarinos de bajo costo para hacer la entrada de triple de los datos que serán necesarios.
  15. Mientras tanto, los desarrolladores podrán trabajar sólo en la versión real del nuevo sistema en la que no hay ningún usuario.
Anterior1 of 2Siguiente