GERENCIA PREVIA 1

Un proyecto de implementación de una solución de Business Intelligence lleva 9 meses de retraso. El directorio solicita al gerente de proyecto garantizar que no habrá nuevos retrasos. ¿Qué acciones debería tomar el gerente considerando que en 2 semanas hay un hito importante de integración de módulos que no está completamente mitigado?

• Evaluar detenidamente los riesgos del hito, establecer acciones mitigadoras y, de ser necesario, negociar flexibilidad con el directorio.

• Asegurar al directorio que no habrá más retrasos, aún si no están cubiertos todos los riesgos del próximo hito.

• Establecer una fecha de entrega sin considerar la situación actual del proyecto.

• Ocultar al directorio la información sobre la situación del próximo hito y sus riesgos asociados.

  
  

En un proyecto informático de desarrollo de software para una empresa de servicios financieros, el equipo de proyecto ha definido el alcance y los requisitos de manera exhaustiva. Sin embargo, durante la planificación detallada, surgen discrepancias en la estimación del tiempo necesario para ciertas tareas críticas. Se presenta la siguiente pregunta: Pregunta: ¿Cómo debería abordar un profesional en Ingeniería de Sistemas las discrepancias en las estimaciones de tiempo durante la planificación del desarrollo de software?

• Redefinir el alcance del proyecto para ajustarse a las estimaciones iniciales.

• Asignar más recursos sin analizar las razones detrás de las discrepancias.

• Aceptar la estimación más optimista para mantener la motivación del equipo.

• Revisar y discutir detalladamente las tareas para llegar a una estimación consensuada.

Durante la fase de desarrollo de un proyecto informático, se reciben solicitudes de cambios en el software por parte de los usuarios finales. Estas solicitudes podrían afectar la línea de tiempo y los recursos del proyecto. Se presenta la siguiente pregunta: Pregunta: ¿Cómo debería manejar un profesional en Ingeniería de Sistemas las solicitudes de cambios durante la fase de desarrollo de software para minimizar el impacto en el proyecto?

• Ignorar las solicitudes de cambios para mantener la integridad del plan original.

• Delegar la decisión a los usuarios finales sin evaluar el impacto en el proyecto.

• Evaluar el impacto de cada cambio en términos de tiempo, recursos y objetivos del proyecto.

• Implementar todos los cambios solicitados para satisfacer a los usuarios finales.

En un proyecto de desarrollo de software, se identifica un riesgo tecnológico relacionado con la posible obsolescencia de una tecnología clave antes de la finalización del proyecto. La siguiente pregunta se presenta: Pregunta: ¿Cómo debería gestionar un profesional en Ingeniería de Sistemas el riesgo de obsolescencia tecnológica durante el desarrollo de software?

• Posponer la toma de decisiones hasta que el riesgo se convierta en un problema real.

• Ignorar el riesgo y esperar que no se materialice.

• Cambiar la tecnología clave de inmediato para evitar cualquier riesgo potencial.

• Desarrollar un plan de contingencia para abordar la obsolescencia si ocurre.

En un proyecto informático, se observa una falta de comunicación clara entre los miembros del equipo de desarrollo y los stakeholders. Esto ha llevado a malentendidos y a la desalineación de expectativas. La siguiente pregunta se presenta: Pregunta: ¿Cómo podría mejorar un profesional en Ingeniería de Sistemas la comunicación efectiva en un proyecto informático?

• Utilizar solo correos electrónicos para documentar la información del proyecto.

• Reducir la frecuencia de las reuniones para evitar la sobrecarga de información.

• Delegar la responsabilidad de la comunicación a un único miembro del equipo.

• Establecer canales de comunicación regulares y claros, adaptados a las necesidades de cada grupo.

Durante las pruebas de software en un proyecto informático, se detectan varios defectos críticos que podrían afectar la funcionalidad del sistema. La siguiente pregunta se presenta: Pregunta: ¿Cómo debería abordar un profesional en Ingeniería de Sistemas los defectos críticos detectados durante las pruebas de software?

• Priorizar y corregir los defectos críticos antes de la implementación.

• Ocultar la información sobre los defectos al equipo de desarrollo para evitar preocupaciones.

• Modificar los requisitos para eliminar la necesidad de corregir los defectos.

• Ignorar los defectos y proceder con la implementación para no retrasar el proyecto.

Un proyecto de desarrollo de software para un sistema de gestión de inventarios en una empresa mediana comenzó con una planificación detallada de requisitos, pero a mitad del desarrollo el cliente solicita agregar nuevas funcionalidades que amplían significativamente el alcance. El equipo de desarrollo no tiene la capacidad para cumplir con la fecha de entrega original considerando estos nuevos requisitos. ¿Cuál es la mejor forma de proceder en este caso?

• Aceptar todos los nuevos requisitos y extender el cronograma y presupuesto proyectados inicialmente para cumplir con la solicitud del cliente.

• Negociar con el cliente para priorizar los nuevos requisitos y postergar algunos para futuras versiones, de modo de cumplir con los plazos y presupuesto originales.

• Realizar el desarrollo solo con los requisitos originales y entregar el producto en la fecha acordada ignorando la solicitud adicional.

• Tercerizar parte del desarrollo de los nuevos requisitos para completar el proyecto en la fecha comprometida.

Un proyecto de implementación de un sistema ERP en una empresa sufrió múltiples fallas y errores durante la etapa de pruebas, por lo que el gerente de proyecto solicita extender 2 meses la fecha de entrega para realizar las correcciones necesarias. Sin embargo, el directorio de la empresa solicita que se cumpla con la fecha original pues el proyecto ya lleva 1 año de retraso respecto al plan inicial. ¿Qué debería hacer el gerente de proyecto en este escenario?

• Evaluar alternativas como agregar recursos al equipo o tercerizar parte del trabajo pendiente para tratar de cumplir con la fecha sin sacrificar la calidad.

• Congelar los requisitos actuales y dividir el proyecto en dos versiones, entregando la primera en la fecha acordada.

• Asumir el riesgo, realizar una corrección rápida de los errores críticos y entregar en la fecha original asumiendo probables fallas residuales.

• Explicar al directorio que extender la fecha permitirá entregar un producto más testeado y con menos fallas en producción.

Un proyecto de actualización de la infraestructura tecnológica de una empresa se estimó inicialmente en 5 meses. A mitad del proyecto, uno de los proveedores tecnológicos sufre un ciberataque que compromete la entrega de varios componentes críticos. El gerente de proyecto solicita extender 2 meses el cronograma debido a este imprevisto. ¿Cuál sería la mejor forma de proceder?

• Presionar al proveedor con penalidades financieras para que acelere la recuperación de sus servicios.

• Aceptar la extensión de plazos y esperar a que el proveedor restablezca sus operaciones pues no hay alternativa.

• Utilizar componentes de menor calidad con tal cumplir con los plazos establecidos.

• Evaluar alternativas y mitigaciones como la sustitución del proveedor o migración temporal a la nube mientras se normaliza la situación.

Un proyecto de desarrollo de software tuvo múltiples inconvenientes: el arquitecto de software renunció abruptamente, el nuevo programador senior tarda en incorporarse 3 semanas y uno de los analistas de negocio sufre un accidente que lo deja imposibilitado de trabajar por 1 mes. Ante todos estos imprevistos en cascada, el director ejecutivo presiona para no retrasar la fecha de entrega debido a compromisos comerciales. ¿Cómo debería responder el gerente de proyecto?

• Ocultar la información al directorio respecto a los problemas para evitar conflictos por posibles retrasos.

• Renunciar al proyecto debido a que la situación pone en riesgo su reputación personal.

• Evaluar el impacto en el cronograma considerando los riesgos en la calidad del software por apresurar el trabajo para cumplir la fecha.

• Aceptar la presión y aplicar medidas extremas para cumplir los plazos, aun cuando se arriesgue la estabilidad del proyecto.