Proyectos de TI: hechos para durar

Proyectos de TI

Puente de Brooklyn y Torre Eiffel: ¿Qué pueden aprender los gerentes de proyectos de TI de estas maravillas arquitectónicas? Este artículo de Gantthead proporciona la respuesta.

Por: Mark Mulally, PMP

En general, se acepta que los proyectos de construcción se gestionan mejor que los proyectos de TI. Curiosamente, no son solo los ingenieros los que piensan de esta manera. A menudo, los gerentes de proyecto en la industria de TI creen culpablemente lo mismo.

En mi trabajo de desarrollo de capacidades de gestión de proyectos en organizaciones de ambos campos, está claro que los proyectos de construcción tienen tantas posibilidades de salir mal como los proyectos de TI, y por razones similares. Sin embargo, existen algunas diferencias estructurales en la forma en que se gestionan los proyectos de construcción que pueden reducir este riesgo y, cuando se aplican a TI, pueden mejorar en gran medida la probabilidad de éxito.

necesita diseñar
Una de las mayores diferencias percibidas entre el mundo de TI y el mundo de la construcción es la capacidad de entregar proyectos a tiempo y dentro del presupuesto. Nuevamente, hay algunas razones estructurales para esto. El mayor costo de un proyecto de construcción está en los materiales utilizados en la construcción: acero, hormigón, vidrio, etc. Una vez que se completa el diseño, se conoce la cantidad requerida y el costo es fácil de calcular. El mayor punto de variabilidad en la estimación de cualquier proyecto son las personas; sin embargo, en los proyectos de TI, las personas representan un porcentaje mucho mayor del costo final.

Entonces, si el esfuerzo de las personas para hacer el trabajo es tan difícil de estimar, ¿hay alguna esperanza de que podamos mejorar las estimaciones de nuestro proyecto? La respuesta es un sí rotundo». Esta es la frase que salta del último párrafo: «Una vez que el diseño esté completo». tornillo. Sin embargo, en el mundo de los proyectos de TI, los costos a menudo se determinan antes de que se comprendan completamente los requisitos y, en muchos casos, ni siquiera se produce un diseño detallado.

Si queremos administrar mejor los proyectos de TI, debemos dedicar un tiempo valioso a comprender los requisitos y la planificación detallada del diseño. En un proyecto bien ejecutado, hasta el 45 % del trabajo del proyecto se puede gastar en estas dos fases; una de las principales razones por las que los proyectos de TI fallan es enmascarar los requisitos y los diseños para seguir construyendo. Muchos contratistas de la construcción no construyen hasta que tienen planos de trabajo detallados y especificaciones para explicar exactamente cómo hacerlo: se detalla cada unión, cada viga, cada estructura. Entonces, ¿por qué tantos equipos de proyectos de TI comienzan a trabajar sin confirmar que lo que están considerando se puede construir?

¿Se aplica la lógica?

¿Es posible aplicar estas lecciones de la industria de la construcción a proyectos de TI? Publique sus pensamientos a continuación.

Conoce tu rol
Luego está el propio equipo del proyecto. Una de las mayores diferencias entre los proyectos de arquitectura y los proyectos de TI es la estructura del equipo. En el mundo de la arquitectura, el equipo de diseño (arquitectos y consultores que diseñan y especifican el edificio) está completamente separado del equipo de construcción (el contratista general y la industria que realmente construyen el proyecto). Además de ser equipos separados, tienen obligaciones contractuales muy diferentes; los diseñadores continúan involucrados en el proyecto a lo largo de su ciclo de vida, gestionando los cambios de alcance, aclarando los problemas de diseño y realizando el control de calidad para garantizar que el diseño realmente se construya. La responsabilidad del contratista es solo construir el diseño. Esto obliga a que cualquier problema de diseño se resuelva formalmente y los dibujos se actualicen cuando se debe cambiar algo.

Incluso cuando existe un diseño detallado para un proyecto de TI, rara vez se actualiza para reflejar los cambios o la resolución de problemas. En cambio, tienden a ser simplemente cepillados debajo de la alfombra e idealmente olvidados.

Los cambios de alcance también suelen estar ocultos bajo la alfombra de los proyectos de TI. Asimismo, la falta de desarrollo de un alcance, una especificación y un plan detallados ha desdibujado la distinción formal entre lo que se prometió inicialmente y lo que finalmente resultaría. La naturaleza contractual del rol del arquitecto y del contratista general obliga a un enfoque formal para administrar los cambios de alcance; cualquier requisito adicional del cliente debe ser pagado por el cliente; sin embargo, cualquier deficiencia en el diseño pasa a ser responsabilidad del arquitecto. Imagine el impacto en su próximo proyecto de TI si los diseñadores pagaran por sus errores.

Satisfacción garantizada
Finalmente, el proceso de control de calidad se gestiona formalmente en el mundo de la construcción, y los proyectos de TI a menudo se ven como un lujo costoso y el primer costo que se sacrifica para cumplir con presupuestos poco realistas. Los clientes del proceso de construcción nunca aceptarán la cancelación de la fase de puesta en marcha, la fase de aceptación en la que el edificio se pone a prueba para garantizar que todo funcione como se espera. Y se toma las garantías muy en serio. Una garantía de un año no es poco común en grandes proyectos de construcción, y cualquier defecto dentro del período de garantía es responsabilidad del contratista general para resolver.

Incluso con todas estas estrategias y técnicas, no se puede negar que los proyectos de construcción aún pueden salir terriblemente mal. Los gerentes de proyectos de construcción todavía tienen que lidiar con expectativas poco razonables, clientes difíciles, problemas de personal y una tendencia a «pasar la pelota». Sin embargo, con estos métodos, las posibilidades de éxito del proyecto son mucho mayores que sin ellos. Al aplicar algunas de estas técnicas en el mundo de TI, las posibilidades de éxito de su próximo proyecto también serán mayores.

Obtenga más artículos y descargas de gantthead

Para obtener más información sobre este tema, consulte las siguientes descargas relacionadas:

Funciones y responsabilidades de la gestión de proyectos

Lista de verificación de evaluación de proyectos para la gestión de proyectos de TI

Plan de proyecto PACE

Lista de lecciones aprendidas

Siga los enlaces a continuación para acceder a artículos relacionados:

Proceso de gestión de proyectos PACE

Departamento de Gestión de Proyectos

Mida dos veces, venda una vez: defendiendo la gestión de proyectos

Nota: Los elementos en negrita son solo para miembros premium de gantthead.

Mark Mullaly es presidente de Interthink Consulting Incorporated, una firma de cambio y desarrollo organizacional enfocada en crear soluciones efectivas de administración de proyectos organizacionales. Escribe la columna mensual PMP: Project Management in Practice de Gantthead.

Este artículo se publicó originalmente en Gantthead el 31 de enero de 2001.