¿Qué es la planificación de proyectos de TI?
La planificación de proyectos de tecnologías de la información, o la planificación de proyectos de TI, es el esfuerzo que realiza un equipo al principio de un proyecto para garantizar que el trabajo se desarrolle correctamente. Estos pasos también ayudan a garantizar que el proyecto cumpla su plazo y sus objetivos generales.
La planificación es la segunda fase de un proyecto informático, después del inicio del proyecto y antes de su ejecución. Más información sobre las fases de iniciación y ejecucióny gestión de proyectos informáticos. Para saber cómo priorizar estos proyectos, visite nuestra guía completa de priorización de proyectos de TI.
Cómo planificar un proyecto de TI
La planificación de un proyecto de TI requiere dar los primeros pasos clave. Estos incluyen ayudar a los miembros del equipo y a las partes interesadas a entender el objetivo general del proyecto. Además, hay que aclarar cómo el equipo definirá y supervisará el trabajo.
Pasos de la planificación de un proyecto de TI
Los expertos recomiendan una serie de pasos para planificar eficazmente un proyecto de TI. Empiece por convocar una reunión inicial con los miembros del equipo del proyecto y las partes interesadas para discutir las líneas generales y los objetivos del proyecto.
A continuación se detallan 13 pasos importantes en la planificación de un proyecto de TI:
Paso 1: Convocar una reunión de inicio
La reunión inicial es vital. Es una oportunidad para reunir a los miembros del equipo, los clientes y otras partes interesadas importantes para discutir los objetivos del proyecto y establecer las expectativas. Los participantes en la reunión también pueden conversar sobre los posibles riesgos.
"Lo que solemos hacer en esta reunión es pedir a todas las partes interesadas que estén presentes", afirma Shai Shandil, fundador de softsolutions consulting, que ofrece servicios de consultoría y capacitación para ayudar a las empresas en sus proyectos tecnológicos.
Shandil afirma que, en años anteriores, recomendaba a la gente que acudiera a la reunión aunque tuviera que volar para llegar a ella. Hoy en día, ese requisito se ha relajado. Pero todo el mundo debería asistir en persona o por video, porque la reunión es vital para que todos lleguen a un entendimiento común del proyecto y sus objetivos. "Intentamos llegar a un punto en el que tengamos un entendimiento estándar de lo que es entregable", señala Shandil.
Para obtener más información sobre la planificación de una reunión de inicio, lee nuestra guía completa de inicio de proyectos y descargue plantillas gratuitas de inicio de proyectos.
Paso 2: Asegúrese de contar con el apoyo y el compromiso de los directivos
La dirección de la empresa debe demostrar que está comprometida con el proyecto y que considera que el trabajo es importante. Los líderes también deben comprometerse con el proyecto. Deben asistir a las sesiones de actualización y hacer sus aportes.
La participación de los directivos "es el paso mínimo", afirma Shandil. "Hablo de un compromiso profundo de los dirigentes, y tiene que ser comparable al presupuesto que están dispuestos a aportar. Si ponen cinco dólares; entonces, si me equivoco, no pasa nada. Pero si ponen millones y es el 80 % del presupuesto total, entonces empiezas a pensar: “no puedo hacer que venga una vez al trimestre o al mes y mire algunos informes. Eso no es suficiente. Necesito que esté ahí con nosotros para orientarnos, porque usted aporta la visión'".
Shandil afirma que eso no significa que el liderazgo esté en cada reunión de Scrum u otra reunión de proyecto. "Pero lo que sí queremos es que aparezcan cada dos semanas y vean las cosas que estamos impulsando", afirma. "Sea cual sea la cadencia (si son dos semanas, cuatro semanas o tres semanas), la idea es: "Venga a vernos y mire el producto". No se trata de una representación del producto, ni de una presentación en PowerPoint, sino del producto real. Necesitamos que luego sean capaces de ir a la junta directiva, al cliente o al mercado y decir: “Oigan, esto es lo que estamos haciendo'".
Paso 3: Crear una carta de proyecto que incluya los objetivos
Antes de empezar a trabajar en un proyecto, es esencial crear una carta de proyecto. La carta proporciona detalles sobre el alcance, los recursos y los plazos. Y lo que es más importante, establece los objetivos principales del proyecto. Asegúrese de que usted y su equipo están seguros de que esos objetivos asumidos son los correctos.
"Uno de los aspectos más críticos de la planificación de un proyecto de TI es comprender claramente los objetivos del proyecto", afirma Alan Zucker, director fundador de Project Management Essentials, que cuenta con más de dos décadas de experiencia en la gestión de proyectos en empresas de la lista Fortune 100. "Los objetivosson el 'qué queremos' y el 'por qué lo queremos'. El alcance es el 'cómo vamos a conseguirlo'. Entender los objetivos es importante porque puede haber múltiples soluciones para resolver el problema y queremos entender el problema antes de decidir cómo resolverlo.
"Empezar con el por qué". Empiece por el objetivo. Haga preguntas. ¿Qué nos permitirá hacer el objetivo? ¿Qué esperamos conseguir?".
Paso 4: Establecer una prueba de inicio
Una parte importante de la comprensión y el establecimiento de los objetivos es entender completamente el producto que su proyecto de TI está destinado a desarrollar. Debe estar seguro de que el producto es técnicamente posible y merece la pena.
"Asegúrese de que hay claridad en torno a lo que quiere entregar", afirma Zucker. "Una prueba de inicio: eso va a tener un valor incalculable".
"Haga una prueba de concepto [para el producto]", afirma Patrick Sim, cofundador de RobustTechHouse, que desarrolla proyectos informáticos para clientes, y FacilityBot, que utilice tecnología para ayudar a gestionar instalaciones y plantas de fabricación. "Y hágalo primero. Si no puede hacerlo, olvídelo".
Si técnicamente no puede fabricar el producto, o tiene problemas para venderlo al precio que necesita para cubrir los costos, tiene que saberlo desde el principio, explica Sim. Y es posible que tenga que poner fin al proyecto. "Pase a otra cosa", recomienda.
Paso 5: Establezca un presupuesto (pero comprenda que puede tener que cambiar)
Querrá establecer un presupuesto amplio para el proyecto. Pero cree una estructura y unos procesos que permitan modificar el presupuesto cuando sea necesario. Esto es especialmente importante en los proyectos de TI, ya que los productos suelen evolucionar a medida que se desarrollan.
Los expertos también señalan que una característica clave de los proyectos (y productos) de TI es que el presupuesto aumenta a medida que el proyecto tiene éxito.
"Una cuestión clave es que los proyectos de TI que tienen éxito se utilizan mucho y suelen requerir nuevas funciones y mejoras continuas", afirma Sim. "Se seguirán produciendo costos adicionales, sobre todo en el caso de los proyectos informáticos de éxito. Todos los productos de éxito que ve por ahí... siempre están agregando funciones, ¿verdad? Por lo tanto, el presupuesto tiene que aumentar. Esto es parte de la aceptación que la dirección tiene que entender".
Paso 6: Establecer el alcance del proyecto
Una vez fijados el objetivo y el presupuesto provisional, es el momento de establecer el alcance exacto del proyecto. Fijará los parámetros de lo que el proyecto producirá o completará y lo que no hará.
"Una vez que entendemos lo que se quiere y por qué, podemos empezar a hacer preguntas sobre el alcance", comparte Zucker. "Podemos empezar a examinar el alcance del proyecto a alto nivel. ¿Qué es lo que está en el alcance? Y, a menudo igual de importante, ¿qué está fuera del alcance?".
Puede descargar una plantilla que le ayudará a detallar el alcance de un proyecto de TI.
Paso 7: Crear un plan de gestión de proyectos
Una vez que haya determinado los objetivos, el presupuesto y el alcance, puede completar un plan de gestión del proyecto. Este plan proporciona una estructura general sobre cómo realizar el trabajo.
"El plan de gestión del proyecto debe personalizarse o adaptarse al proyecto específico", afirma Zucker. "Es la guía del gerente de proyectos para ejecutar el proyecto".
Vea y descargue plantillas gratuitas de gestión de proyectos para ayudarle a crear un plan de gestión de proyectos.
Paso 8: Articular las responsabilidades de los miembros del equipo desde el principio
El plan de gestión del proyecto incluirá información básica sobre quién es responsable de qué tareas y plazos. Es fundamental que cada miembro del equipo entienda, desde el principio, las tareas de las que es responsable.
Paso 9: Decidir la mejor metodología para su proyecto
Al principio del proceso de planificación, querrá decidir qué metodología de gestión de proyectos va a utilizar. Probablemente será Agile o una versión modificada de esa metodología. Algunos proyectos de TI siguen utilizando métodos más tradicionales.
Zucker aconseja preguntarse "qué tipo de proyecto estamos ejecutando y qué tipo de metodología va a encajar bien con este proyecto". Para muchos proyectos de TI, eso significa Agile o alguna versión de ella, que permite los continuos cambios y adaptaciones que forman parte de un proyecto de TI.
Zucker agrega que "la decisión sobre si este proyecto va a ser Agile o tradicional puede tomarse por usted" porque muchas organizaciones tienen una preferencia por la metodología que utilizan para gestionar los proyectos.
Para una pequeña minoría de proyectos de TI, la gestión de proyectos tradicional, incluida la metodología cascada, podría ser la mejor, comparte Shandil. "Suelen ser los sectores verticales con menos cambios y muy regulados", explica. "La banca es un ejemplo de ello. Trabajé con una empresa que básicamente vendía empresas en línea. Con las regulaciones del mercado de valores... todas esas cosas apenas cambian. Para ellos, eran un nicho y les iba increíblemente bien. Y dijimos: 'Ustedes deberían seguir trabajando en cascada; funciona muy bien'".
Paso 10: Planificar la celebración de reuniones estratégicas periódicas
Es necesario realizar reuniones periódicas de control con todos los participantes en el proyecto, incluidos los clientes y las partes interesadas. Los expertos recomiendan celebrar esas reuniones al menos una vez al trimestre, o incluso mensualmente en el caso de equipos más pequeños.
Paso 11: Establecer las especificaciones del producto
En primer lugar, establezca sus objetivos y asegúrese de que el producto en el que está trabajando su proyecto es viable. A continuación, haga una lista de las especificaciones de su producto con mucho detalle.
"Lo más importante son las especificaciones", afirma Sim, de RobustTechHouse. "¿En qué consiste el proyecto? ¿Qué se va a producir? Le sorprenderá que muchos clientes, diría que el 60-70 por ciento, no tienen eso".
Los clientes que pueden tener menos conocimientos tecnológicos o menos experiencia en tecnología suelen establecer especificaciones a un nivel extremadamente alto y general. Necesitan ser más específicos sobre lo que hará el producto, cómo lo hará y las métricas sobre cómo lo hará, afirma Sim. "Sin un documento detallado de los requisitos, el presupuesto (tanto en tiempo como en costo) resulta muy difícil", afirma.
Mientras tanto, las organizaciones más grandes tienen un problema diferente: muchas personas con opiniones diferentes sobre el producto y lo que debe hacer. "A veces, las grandes organizaciones tienen toda esta burocracia y muchas personas tienen opiniones diferentes sobre lo que debe hacerse", agrega Sim. "No pueden llegar a ningún tipo de consenso sobre 'este es el producto que queremos construir'. Así que (es importante) llegar a la fase de buenas especificaciones".
Paso 12: Comprender y abordar los riesgos técnicos y de otro tipo
El equipo del proyecto debe comprender rápidamente los mayores riesgos para el éxito del proyecto (o del producto). Pueden ser riesgos técnicos o de otro tipo. El equipo querrá comprenderlos y abordarlos para evitar el fracaso.
Los riesgos técnicos (la tecnología no funcionará correctamente debido a limitaciones o problemas técnicos) son especialmente importantes en los proyectos de TI. Los expertos sugieren que los equipos identifiquen y trabajen en esos posibles riesgos con antelación para evitar malgastar dinero en un proyecto que está destinado a tener problemas.
"Detecte los riesgos técnicos con antelación y pruebe si (el producto) puede lograrse", sugiere Sim. "Se puede agregar personal adicional por el camino. Lo más importante es identificar los riesgos técnicos clave (cualquier área concreta en la que el equipo técnico no tenga mucha experiencia) y construir primero ese componente".
Shandil está de acuerdo. "Se toma lo más arriesgado que sea lo más importante para el cliente y se hace primero", explica. "Digamos que estamos construyendo un sistema de contabilidad. Una parte del riesgo es guardar los datos sensibles de un cliente. Entonces construiríamos primero esa parte del sistema de contabilidad, la sacaríamos y nos aseguraríamos de que funciona. Ha manejado el riesgo trayéndolo a menudo y temprano y asegurándose de que todas esas suposiciones que hizo sobre las leyes de privacidad, etc., en toda la organización o el país, se están abordando desde el principio. No se llega al final de un proyecto y se tienen problemas desconocidos, no tangibles".
Paso 13: Obtenga los comentarios de los usuarios con prontitud y frecuencia
Cuando su equipo está creando un nuevo producto informático, es crucial comprobar cómo funciona (o no) lo antes posible. Eso significa obtener la opinión de los usuarios a medida que se construye el producto.
Los expertos recomiendan crear el producto mínimo viable. Eso significa poner el nuevo producto en manos de los usuarios lo antes posible, aunque solo funcionen una o dos funciones básicas. Con sus comentarios sobre esa primera versión, los usuarios le ayudarán a seguir desarrollando el producto.
"Salga al mercado pronto y obtenga opiniones reales de los usuarios", agregue Sim. "Demasiados proyectos se quedan atascados en el infierno de la presupuestación y la sobreingeniería de características y nunca se ponen en marcha".
Shandil afirma que muchas empresas pagarán a los posibles usuarios para que prueben el nuevo producto con el fin de conocer sus reacciones. Con un nuevo sistema de contabilidad, por ejemplo, "su estrategia podría ser hablar con los contadores y decirles: “Miren, estamos sacando este producto. ¿Podrían venir a probarlo (pagando 20 dólares la hora o lo que sea) para jugar y darme sus opiniones concretas sobre cómo funcionaría en un entorno en la nube? A esto lo llamamos entrevistas con los usuarios. Pero, básicamente, es un circuito de retroalimentación que le permite mitigar el riesgo de forma rápida, barata y fácil".
Componentes tradicionales de gestión de proyectos que son diferentes en Agile para proyectos de TI
La planificación de una gestión de proyectos más tradicional, como la que utilice la metodología de cascada, incluye una serie de pasos y documentos. Estos esfuerzos son menos comunes o se aplican de forma diferente cuando los proyectos de TI utilizan la metodología Agile.
Por ejemplo, los equipos suelen utilizar una estructura de desglose del trabajo (EDT) en la gestión de proyectos tradicional. El diagrama detallado muestra todas las tareas que un equipo necesita marcar para completar un proyecto. Más información sobre cómo empezar con una estructura de desglose del trabajo.
Los proyectos Agile no utilizan estructuras de desglose del trabajo. Sin embargo, una cartera de productos Agile o una hoja de ruta de productos suelen tener propósitos similares.
La gestión tradicional de proyectos también puede incluir pasos y documentos para:
- Adoptar la planificación de la gestión de riesgos
- Gestionar la planificación de las comunicaciones para los miembros del equipo, los clientes y las partes interesadas
- Aplicar la planificación de la gestión del cambio
- Realizar la planificación del presupuesto
- Planificar los recursos y el personal necesarios
- Programar todas las actividades del proyecto
Cuando los equipos utilizan Agile para planificar y ejecutar sus proyectos de TI, siguen muchos de los mismos pasos anteriores, aunque de forma diferente y a menudo menos formal. En su lugar, estos pasos a veces forman parte de sprints e iteraciones.
Aquí hay más detalles para entender cómo funciona Agile, y si su equipo está usando Agile apropiadamente o solo está diciendo que está usando Agile.
Ejemplo de plan de proyecto de TI
Descargar el ejemplo de plan de proyecto Agile de TI: Microsoft Excel
Esta plantilla de ejemplo de plan de proyecto Agile viene ya completada para ayudarle a entender cómo planificar su proyecto de TI. La plantilla de ejemplo incluye entradas para sprints Agile específicos, junto con características dentro de esos sprints. También encontrará secciones para los miembros del equipo que son responsables de cada elemento, las fechas de inicio y finalización previstas y el estado actual.
Plantilla de plan de proyecto Agile
Download Agile Project Plan Template — Microsoft Excel
Puede personalizar esta plantilla de plan de proyecto Agile para planificar y supervisar su proyecto Agile de TI para sus propios fines. La plantilla incluye secciones en las que puede agregar tareas, responsabilidades para las tareas, fechas de inicio y finalización y estado. La duración de cada tarea se calculará automáticamente. Esta plantilla también incluye un diagrama de Gantt (una representación visual de la línea de tiempo de su proyecto), que se ajustará automáticamente cuando agregue sus propios datos a la tabla.
En qué se diferencia la planificación de un proyecto de TI de la de otro. Proyectos no informáticos
Los proyectos de TI destacan por la cantidad de ajustes y cambios que se producen desde el principio del proyecto hasta el final. Muchos proyectos que no son de TI tienen muchos menos cambios. Por lo tanto, la planificación de muchos proyectos de TI requiere enfoques diferentes.
He aquí dos diferencias principales:
- Los proyectos de TI son mucho menos propensos a utilizar métodos tradicionales de gestión de proyectos: Los métodos de proyecto tradicionales, como el de cascada, son opciones sólidas para algunos proyectos de construcción. Los cambios significativos en los planes son menos probables en estos proyectos. Pero el desarrollo de software y otros proyectos de tecnología de la información se enfrentan a cambios significativos en todo momento, por lo que es más probable que utilicen metodologías Agile o Agile modificadas.
- Es más probable que los presupuestos cambien: Los presupuestos de los proyectos de TI pueden cambiar cuando hay obstáculos o problemas imprevistos que requieren ajustes. Pero los presupuestos también pueden cambiar con el éxito del proyecto. Eso puede ocurrir cuando un nuevo producto informático (desarrollado en el transcurso de un proyecto) tiene éxito y es apreciado por los clientes.
"La diferencia entre el sector no informático y el informático es que cuando se termina un proyecto informático, en realidad es el comienzo de algo", afirma Shandil. "Cuando termina cualquier otro proyecto, es el final de algo".
Cuando los equipos de construcción terminan un edificio, también se acaba el presupuesto de la obra. Pero cuando los desarrolladores de software terminan un software y los clientes lo adoran, esos clientes sugieren continuamente cambios para mejorarlo. Eso significa que el presupuesto para el éxito del software y la TI crece cuando tiene éxito.
"Si se gastan 2 millones de dólares en software, se van a gastar 8 millones antes de retirarlo o ponerlo en marcha", explica Shandil.
Consejos para la planificación de proyectos de TI
Los expertos recomiendan capacitar y mantener equipos de proyecto. También hay que determinar los documentos de planificación que son necesarios y los que no lo son, así como la forma de mostrar el trabajo y el progreso.
He aquí algunos de los principales consejos de los expertos para la planificación de proyectos de TI:
- Mantener equipos de proyecto continuos: Algunas organizaciones pueden crear un equipo personalizado para cada proyecto específico. Sin embargo, Zucker afirma que mantener equipos continuos formados principalmente por los mismos miembros, llamados equipos persistentes, que trabajan en un proyecto tras otro tiene sus ventajas. Los miembros del equipo llegan a conocerse entre sí y a saber lo que cada uno hace mejor, lo que hace que el trabajo del proyecto se desarrolle con mayor eficacia.
"Los equipos persistentes pueden utilizarse en cualquier entorno: Agile o tradicional", afirma Zucker. - Asegúrese de que su objetivo es el correcto: Con demasiada frecuencia, los líderes de la empresa o del proyecto anuncian un objetivo para un proyecto e inmediatamente comienzan a planificar para alcanzarlo. Pero no siempre analizan si ese objetivo es el correcto o si su consecución permitirá alcanzar lo que desean para la organización.
"He visto muchas veces cómo se desarrolla todo esto", explica Zucker. "Dedican 15 segundos a lo que quiero conseguir, e inmediatamente profundizan en los detalles de cómo ponerlo en práctica. Asegurémonos de que eso es lo que queremos hacer". - Asegúrese de definir el éxito final de la manera correcta: El éxito en los proyectos de TI no tiene que ver con el número de funciones que se hayan agregado a un software o a un sistema digital, aconseja Shandil. Se trata de la felicidad del cliente.
"El mejor resultado es tener clientes contentos, así que normalmente pensamos: ¿Cuántas funciones has sacado este mes? En lugar de eso, deberíamos pensar: ¿Cuántos clientes satisfechos? ¿Hemos conseguido que estén contentos con las funciones que hemos sacado este mes?", pregunta. - No se centre demasiado en los documentos escritos detallados: La metodología Agile se centra menos en exigir documentos escritos formales que las metodologías más tradicionales. Pero incluso en Agile, es importante cierta documentación sobre el plan básico de gestión del proyecto y el alcance. Sin embargo, lo que no se quiere es perder el tiempo escribiendo documentación que inmediatamente se vuelve obsoleta e inhibe el progreso del proyecto.
"La contrapartida es que hace que sea menos Agile, porque lleva tiempo escribir estas cosas. Muchas veces usted se proyecta hacia el futuro. Puede que ni siquiera sepa exactamente cuál es su producto. Decida qué documentación es realmente necesaria y luego edítela. Esto también es una habilidad: decidir qué es absolutamente necesario y qué no lo es", aconseja Sims. - No se centre demasiado en la planificación previa: Este consejo está relacionado con la documentación limitada. No dedique demasiado tiempo a la planificación detallada antes de empezar a trabajar. Por supuesto, querrá establecer unos objetivos y una estructura básicos. Pero luego póngase a trabajar.
"Planifique ahora para planificar después", afirma Shandil. "Y mientras tanto, aprenda un poco más".
Eso significa que su equipo puede trabajar en el producto o proyecto durante un tiempo limitado: durante un sprint de una semana en Agile, por ejemplo. "Los miembros del equipo aprenderán más durante esa semana de trabajo, y luego podrían hacer planes rápidos para la siguiente semana de trabajo. Y simplemente se repite a partir de ahí", afirma Shandil. "La diferencia clave para nosotros es que tiene que entregar algo, porque si no, no está aprendiendo nada". - Cómo entender y utilizar el concepto de producto mínimo viable: Un producto mínimo viable es un concepto que anima a los desarrolladores a poner en manos de los usuarios una versión básica de un nuevo producto lo antes posible. Esto significa que no es el producto terminado, pero funciona a un nivel básico y puede dar al usuario una idea del concepto. Los primeros comentarios de los usuarios pueden ayudar a agregar otras funciones y a seguir desarrollando el producto.
"El mejor feedback es el de los usuarios reales", afirma Sim. - Establezca un acuerdo de trabajo sobre la cultura laboral: Al inicio de un proyecto, Shandil anima a los clientes a acordar un acuerdo de trabajo, que establezca las normas y principios básicos sobre la forma de trabajar juntos.
"Se trata de conseguir que la gente actúe más como un equipo y menos como un grupo de colaboradores individuales", afirma. "Así que, de hecho, elaboramos un reglamento para el equipo".
Las reglas pueden incluir, por ejemplo, que el silencio es un acuerdo. "Así, la gente entiende que debe contribuir a los debates, y si no lo hace, no puede decir después que no estaba de acuerdo", explica Shandil.
- Asegúrese de que todo el mundo pueda ver, supervisar y hacer un seguimiento del progreso de un proyecto: Todos los miembros del equipo, el cliente o las partes interesadas deben poder ver fácilmente el estado y el progreso de un proyecto. Los miembros del equipo pueden ver cuánto trabajo queda por hacer y las personas ajenas al proyecto entienden el trabajo que se está realizando. Esto puede ayudar a conseguir apoyo político, financiero y de otro tipo para este proyecto y los futuros.
Shandil recuerda un caso en el que trabajó en una organización de salud australiana que fue comprada. El director general de la empresa compradora visitó las oficinas y vio una gran pizarra con proyectos escritos en el departamento de TI.
"Miró la pizarra y dijo: 'Vaya, hacen mucho trabajo. No creo que mis chicos de Sídney trabajen tanto'. Sabíamos que eso no era cierto. Solo que no lo hacían visible. Esa idea es realmente clave para nosotros, porque podría pasar por delante de trabajadores del conocimiento y hay mucha cosas que están sucediendo en nuestras cabezas. Pero ella no tiene ni idea, ¿verdad? Poner eso a la luz y conseguir que personas que no tienen necesariamente una capacitación técnica se involucren en ese proceso es algo muy importante". - Piense en cómo va a abordar la ciberseguridad: La ciberseguridad es importante para todos los proyectos de TI. Para algunos proyectos de TI, puede ser el componente más importante a tener en cuenta al principio del proceso.
Esto significa que la ciberseguridad debe estar entre los primeros riesgos que un equipo evalúa y planifica. Sim afirma que ha visto proyectos en los que los jefes de equipo evaluaron lo que se necesitaría para garantizar la ciberseguridad necesaria para el producto. Y ese presupuesto de ciberseguridad acabó siendo cinco veces superior al presupuesto previsto para todo el proyecto.
"Usted sabe que (el proyecto) no tiene sentido, ¿verdad?", comenta. "Es mejor descubrirlo en las primeras fases del trabajo, en lugar de hacerlo más tarde".
La tasa de fracaso de los proyectos de TI
La tasa de fracaso de los proyectos de TI es bastante elevada. Desde 1994, el Grupo Standish ha publicado sus informes CHAOS sobre el éxito de los proyectos de TI. En su informe de 2015, encontró que el 36 por ciento de los proyectos de TI se completaron con éxito en 2015. Otro 46 por ciento fue "cuestionado", lo que significa que el proyecto se completó y fue operativo, pero se excedió del presupuesto, se completó más allá de la fecha límite, u ofreció menos características de las previstas originalmente. Otro 19 % de los proyectos fracasó por completo y se canceló.
El informe "Pulse of the Profession" de 2021 del Project Management Institute reveló una cierta mejora en el éxito de los proyectos de TI con respecto a años anteriores. Sin embargo, las cifras muestran que hay mucho margen de mejora. El informe reveló que el 64 % de los proyectos de TI se completaron dentro del presupuesto y el 59 % se completaron a tiempo. El informe reveló que el 33 % de los proyectos de TI fracasaron y perdieron su presupuesto.
Por qué fracasan los proyectos de TI
Los expertos afirman que los proyectos de TI fracasan por muchas razones. Entre las razones se encuentran la falta de claridad en los objetivos, la escasa comunicación entre los líderes de los equipos de proyecto y las partes interesadas, y la insuficiente retroalimentación de los usuarios en las primeras etapas del proceso.
A continuación se detallan las cuestiones específicas que causan problemas:
- Líderes de proyecto y miembros del equipo desincronizados entre sí y con las partes interesadas: En los proyectos que fracasan, los jefes de proyecto y los miembros del equipo no se comunican con suficiente frecuencia con los clientes y las partes interesadas. Cuando se comunican, lo hacen mal, y cada parte tiene una idea diferente de las metas y objetivos del proyecto.
- Responsabilidad confusa: Los líderes y los miembros del equipo también pueden estar confundidos acerca de quién es responsable de qué tareas y funciones generales en el proyecto.
- Requisitos poco claros: Un factor importante en el fracaso de los proyectos de TI es la falta de claridad en torno a los requisitos del producto en el centro del proyecto cuando se empieza.
- Demasiada segmentación del trabajo y malos traspasos: Los buenos equipos de proyecto incluyen miembros de varios departamentos de la empresa que pueden trabajar juntos y se aseguran de que ellos y sus equipos más grandes no trabajen en silos. Esos silos pueden causar grandes problemas en las tareas cuando se traslada un proyecto entre departamentos.
"La antigua forma de hacerlo era casi como en las películas de espías", afirma Shandil. "Alguien va a un banco del parque, pone algo debajo y se va. Luego viene alguien y lo recoge. Sabemos que eso no funciona".
Los miembros del equipo de diferentes departamentos deben trabajar juntos en equipos interfuncionales, aconseja Shandil. "Esa idea de tener un equipo multifuncional dedicado significa que no hay traspasos". - Tardar demasiado en realizar la planificación preliminar y trabajar en el producto: Las empresas suelen tardar demasiado en planificar y realizar el trabajo preliminar sobre el producto en su centro. Deberían realizar una planificación y un trabajo preliminares, pero poner una versión del producto en manos de los usuarios lo antes posible.
Una larga planificación y desarrollo conllevan otro peligro: que el mercado haya superado el producto que pensaban construir. "Si tardas un año en lanzar algo, eso ya es demasiado tiempo", afirma Sim. "Y la tecnología podría superar lo que estás tratando de hacer".
Agilice la planificación de proyectos de TI con Smartsheet
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.