ISACA Journal
Volume 4, 2,018 

Translated Articles 

Fuente de ayuda Q&A 

Sunil Bakshi, CISA, CRISC, CISM, CGEIT, ABCI, AMIIB, BS 25999 LI, CEH, CISSP, ISO 27001 LA, MCA, PMP 

Q  Nuestra organización está considerando múltiples proyectos para desarrollar e implementar Soluciones basadas en TI. Yo he revisado varios sitios web, pero no pude obtener una lista detallada de escenarios genéricos de riesgo para proyectos relacionados con TI. ¿Puede usted ayudar?

A  La gestión de proyectos es un área especializada de conocimiento sobre como completar un trabajo que involucra varios tipos de recursos dentro de las restricciones de entregables, costo y tiempo. Teniendo en cuenta la proliferación de TI como un habilitador para casi todas las áreas de un negocio, la mayoría de las organizaciones inician proyectos relacionados con TI en un momento u otro. Para aprovechar las técnicas de gestión de proyectos para entregar a tiempo y dentro de los costos, es imperativo para la organización tener un marco de gestión para proyecto y programa. (Un programa es un grupo de proyectos con un alcance mayor y un objetivo.) Si tal marco no está disponible, implementar uno debería ser el punto de partida. Un marco estándar se puede obtener de la Guía del Cuerpo de Conocimiento de Gestión de Proyectos (PMBOK), Sexta Edición.1

Los aspectos clave de la gestión de proyectos son identificación del riesgo y las estrategias que podrían usarse para mitigar o minimizar el impacto debido al riesgo. La guía de ISACA COBIT 5 para riesgos2 es un excelente recurso sobre cómo administrar el riesgo. Además, ISACA también publicó Escenarios de riesgo utilizando COBIT 5 para riesgos.3 Sin embargo, es importante entender que cada organización necesita desarrollar sus propios escenarios dependiendo de los factores de riesgos internos (dentro de la organización) y externos (ej.: competencia, legal, reguladores) factores de riesgo y la naturaleza de entregables del proyecto, sus tiempos y presupuesto. A continuación, se enumeran algunas áreas genéricas de riesgo asociadas con proyectos relacionados con TI que pueden ser útiles.

Planificación y programación del proyecto

La planificación del proyecto es la clave para completar con éxito el proyecto. La mala planificación es la razón principal de la falla del proyecto. La planificación requiere la comprensión de todos los aspectos de los entregables y restricciones del proyecto para la ejecución. Los siguientes factores de riesgo se deben considerar al planificar un proyecto:

  • Calendarios de disponibilidad de recursos por el patrocinador del proyecto, los cuales no coincidan con las líneas de tiempo del proyecto.
  • El plan del proyecto está preparado teniendo en cuenta la mayoría de las estimaciones de esfuerzo optimista.
  • La estructura de desglose del trabajo (WBS) omite algunas tareas.
  • El plan del proyecto depende de recursos específicos.
  • Se usan líneas de tiempo poco realistas.
  • La tecnología existente no admite entregables.
  • Las líneas de tiempo apretadas crean presión, lo que resulta en una reducción de la productividad.
  • El patrocinador del proyecto cambia arbitrariamente las líneas de tiempo y calendario de recursos.
  • El personal no está familiarizado con la nueva tecnología requerida para los entregables del proyecto.

Organización y gestión de proyectos

Para ejecutar el plan del proyecto, el gerente del proyecto necesita habilidades de gestión para abordar los problemas derivados de la materialización del riesgo. Los escenarios de riesgo incluyen:

  • El patrocinador del proyecto no es designado por el negocio, y el proyecto carece de apoyo de la alta dirección.
  • Las tareas toman más tiempo que las estimaciones pesimistas.
  • Los recursos dejan el proyecto a la mitad.
  • El presupuesto del proyecto es diferido/reducido.
  • Una tecnología específica propuesta no está disponible localmente.
  • Problemas personales existen entre los miembros del equipo.
  • Decisión/revisión por parte de la gerencia/ patrocinador en hitos es lento.
  • La infraestructura esperada/obligatoria no está disponible para prueba/implementación.
  • Una prueba de aceptación del usuario resultó en una falta de aceptación.
  • Las líneas de tiempo de salida al mercado son arbitrariamente propuestas por la gerencia, impactando la calidad.
  • Los cambios en los requisitos hacen que la revisión sea necesaria.
  • Hay retrasos en la adquisición de infraestructura requerido para proyecto/prueba/implementación.

Tercerización/Problemas de terceros

Para ejecutar el plan del proyecto, el gerente del proyecto necesita habilidades de gestión para abordar los problemas derivados de la materialización del riesgo. Los escenarios de riesgo incluyen:

  • El proceso de selección de terceros (proveedor) no considerar la capacidad del proveedor.
  • La calidad de los suministros del proveedor es muy baja.
  • El vendedor seleccionado no tiene los apropiados recursos especializados.
  • La administración de proveedores está fuera del alcance del gerente de proyecto.
  • Las herramientas/hardware/servicios suministrados por el proveedor tienen alta curva de aprendizaje o no son fáciles de usar.
  • El contrato y el acuerdo de nivel de servicio (SLA) con el tercero contienen debilidades tales como:
    • Ausencia de un acuerdo de no divulgación
    • Niveles de servicio no definidos o niveles de servicio no incluidos línea con líneas de tiempo del proyecto
    • Ausencia de control del tercero
    • No participación del departamento legal, lo que resulta en un acuerdo inaplicable
  • El costo de la contratación externa no se consideró en el presupuesto.

Especificaciones de los requisitos del proyecto

Casi todos los proyectos relacionados con TI sufren riesgos asociado con la corrupción del alcance debido a varios factores, incluyendo:

  • Los requisitos y el alcance no han sido congelados y firmados.
  • Las especificaciones de los requisitos están mal definidas, lo que resulta en cambios frecuentes.
  • Los requisitos técnicos se definen vagamente, lo que resulta en una brecha en la comprensión.
  • Las especificaciones de requisitos del proyecto están cerradas, pero el proceso de gestión de cambios no está definido.
  • Las especificaciones de requisitos de seguridad no son definidas en el alcance.

Entregables y requisitos de calidad

La calidad de los entregables depende en gran medida de las habilidades y la experiencia de los arquitectos, diseñadores y desarrolladores involucrados en el proyecto. Algunos de los problemas que enfrentan cuando los recursos no están a los niveles esperados son:

  • Los diseños dan como resultado productos propensos a error/defectuosos requiriendo retrabajo.
  • El software de mala calidad requiere diseño adicional, pruebas y esfuerzos de implementación.
  • Las especificaciones de la interfaz de usuario no se cumplen.
  • Las funciones extra/módulos que no son requeridos son incluido.
  • Requisitos de respuesta/velocidad de ejecución/capacidad no se consideran durante el diseño creando problemas.
  • Compatibilidad e interfaz con sistemas antiguos (Legacy) y otros sistemas requieren más esfuerzo para probar, diseñar e implementar.
  • El uso no probado, última tecnología resulta en cambios frecuentes en diseño y desarrollo.
  • Un requisito para una solución independiente de la plataforma toma más tiempo para satisfacer a los interesados.
  • El entorno de producción final no está disponible para pruebas e implementación.
  • El entorno de prueba/producción no es configurado según la política.
  • Los hitos entregables son poco realistas, afectando la calidad de los entregables.

Lea más sobre los factores de riesgo de proyectos relacionados con TI en la columna detallada de HelpSource que puede ser encontrada exclusivamente en línea (www.isaca.org/journal/archives/Pages/default.aspx).

Conclusión

Los escenarios de riesgo enumerados aquí son genéricos y uno puede usarlos como guía. No es una lista completa del riesgo relacionado con el proyecto. El gerente del proyecto necesita desarrollar una lista de posibles escenarios de riesgo dependiendo de los factores de riesgo asociados.

Notas finales

1 Project Management Institute, Project Management Body of Knowledge PMBOK Guide, Sixth Edition, USA, 2017, https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
2 ISACA, COBIT 5 for Risk, USA, 2013, www.isaca.org/cobit/pages/risk-product-page.aspx
3 ISACA, Risk Scenarios Using COBIT 5 for Risk, USA, 2014, www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/Risk-Scenarios-Using-COBIT-5-for-Risk.aspx

Sunil Bakshi, CISA, CRISC, CISM, CGEIT, ABCI, AMIIB, BS 25999 LI, CEH, CISSP, ISO 27001 LA, MCA, PMP
Ha trabajado en TI, gobierno de TI, auditoría de SI, seguridad de la información y gestión de riesgos de TI. Él tiene 40 años de experiencia en varios puestos en diferentes industrias. Actualmente, él es un consultor “freelance” y visita como miembro de facultad el Instituto Nacional de Administración de Bancos, India.

 

Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.