¿Cuál es la receta para el éxito en la gestión de proyectos? Muchos profesionales TI concuerdan en que el compromiso y el apoyo de la alta gerencia, alcance y requerimientos claramente definidos, buena comunicación, y los recursos adecuados para el proyecto encabezan la lista de los ingredientes fundamentales.
Por su puesto, éstos no son los únicos factores que influyen en el resultado exitoso de un proyecto. Los profesionales de TI también consideran crucial la metodología (o el proceso o el marco de trabajo) de la gestión del proyecto, la necesidad de expectativas de gestión, y un gerente de proyecto con muchas habilidades.
Recientemente, 83 miembros de CIO Forum en LinkedIn desarrollaron una meticulosa guía de los factores de éxito de un proyecto mientras participaban en una discusión sobre las formas de asegurar el éxito en un proyecto de TI.
Algunos de los factores más importantes que se mencionaron eran obvios, otros, no tanto. Aquí, comparto algunos de los factores menos obvios, pero no menos importantes, que tienen influencia sobre el éxito del proyecto. (Y por menos obvios nos referimos a los factores que no se nos vienen de inmediato a la mente, son obviados fácilmente o que se desestiman cuando las cosas se complican en el proyecto). compilaron esta lista, que de ninguna manera es exhaustiva, basados en los comentarios que surgieron en la discusión del CIO Forum y durante entrevistas telefónicas con expertos en gestión de proyectos. Siéntase libre de dejar sus comentarios.
1. Definir con claridad qué es éxito
Uno no puede lograr el éxito si no sabe qué es, el éxito de los proyectos debe definirse en términos que sean significativos para el negocio.
“Con frecuencia, como profesionales de TI, asumimos que el éxito se define en base al cumplimiento de los plazos, del presupuesto y de los requerimientos definidos”,“Aunque esto es importante, es [igualmente] importante entender la propuesta de valor esperada del proyecto y dirigir los esfuerzos del mismo para asegurar que se logre”.
En otras palabras, incluso si el proyecto es concluido a tiempo, dentro del presupuesto y cumple todos los requerimientos, podría aún ser considerado que falló si no proporciona el valor de negocio esperado.
2. No temer a las decisiones impopulares
Bronnie Brooks, consultor de TI y gerente de proyectos que participó en la discusión del CIO Forum, le dijo a CIO que ella tuvo que tomar decisiones difíciles a lo largo de los años que fueron impopulares incluso para su cliente, su gerente o su equipo, para poder mantener los proyectos dentro del plazo, dentro del presupuesto, y con los recursos adecuados intactos. Por ejemplo, afirma que le tuvo que decir a un cliente que una característica que estaban esperando en un próximo release de un software no se daría y que tendrían que esperar hasta el siguiente release, un año después. En otra ocasión, tuvo que trasladar a un miembro del equipo que uno de sus clientes quería en el proyecto, hacia otro proyecto donde sus habilidades eran necesarias.
Tomar decisiones duras acerca de los recursos y prioridades del proyecto puede ser difícil para algunos gerentes de proyectos TI que quieren quedar bien con todos y que quieren creer, como todos los demás, que el proyecto va a funcionar, señala Brooks. Pero tomar ese tipo de decisiones es crucial.
“Algunas veces la mejor decisión no va a ser la más popular”, sostuvo Brooks, “pero te va a permitir avanzar”.
3. Capacitar y guiar al usuario final luego del Go-Live
Seguro piensa que capacitar a los usuarios finales en cualquier nuevo sistema que está siendo desplegado podría considerarse como un factor de éxito obvio y, para muchos profesionales, probablemente lo sea. Pero con frecuencia las implementaciones de los sistemas fallan, no porque se hayan entregado tarde o porque hayan superado su presupuesto, sino porque los usuarios finales no han sido adecuadamente capacitados. Consecuentemente, no adoptan el nuevo sistema.
“Nunca se puede decir que se ha puesto suficiente énfasis en la capacitación o que se ha dado suficiente atención a la guía que se debe realizar luego del go-live”, “Podría decir que la mayoría de las fallas en los proyectos TI se producen por una inadecuada capacitación del lado del usuario y una pobre administración de la fase más crítica: las posterior al go-live”.
4. Definir claramente los roles y responsabilidades
Algunas veces, las personas involucradas en un proyecto (el gerente de proyecto, los miembros del equipo, los miembros del comité de guía y los auspiciadores) no entienden sus roles y responsabilidades porque nadie las ha definido, señala Chet Ung, auditor TI de The Wood Group quien participó en la discusión del CIO Forum
Si, por ejemplo, los miembros del comité de guía del proyecto no entienden su rol, no sabrán con qué se supone que deben de contribuir, señala Ung. Ellos no se dan cuenta que tienen la capacidad de cambiar el curso de un proyecto. Consecuentemente, no contribuyen con nada en las reuniones porque no saben qué preguntar, e incluso no saben que pueden hacer preguntas. Los proyectos pueden fallar cuando el comité de guía no cumple con el rol supervisor que se supone tiene, señala.
“Los roles y las responsabilidades tienen que ser definidas y documentadas para establecer las expectativas y evitar la confusión sobre el nivel de contribución que cada miembro del proyecto realiza”, escribió Ung en el CIO Forum.
5. Hacer que los workflows sean transparentes
Cuando los workflows del proyecto son transparentes, todas las personas involucradas en el proyecto saben exactamente cuál es su rol y “que va hacia arriba o hacia abajo” en el trabajo, En otras palabras, ellos saben qué trabajo se ha hecho en el proyecto antes que el suyo y quién lo hizo, así como qué trabajo se hará después que el suyo.
Los workflows transparentes pueden ahorrar tiempo y mejorar la calidad del proyecto, “Si sabes que tienes algo de alguien que hace un trabajo excelente, no tendrás que llenar espacios vacíos. Te sientes cómodo aceptando lo que estás leyendo”, señala. En forma similar, si la persona a quien le envía su trabajo es muy diligente y detallista, pasará más tiempo perfeccionando su producto de tal forma que cumpla con las altas expectativas de la siguiente persona en el flujo.
6. Tener un proceso para administrar los cambios
Los usuarios finales de un sistema que está siendo desarrollado o de un nuevo proceso que está siendo implementado, generalmente quieren hacer cambios al sistema o al proceso a medida que éstos se van desplegando. No se dan cuenta que incluso los pequeños cambios pueden afectar significativamente el costo del proyecto y su plazo.
Algunas veces el gerente del proyecto o el equipo de implementación a los que se les pide que acomoden estos cambios adicionales en el alcance del proyecto no se dan cuenta de la forma, digamos, en la que añadir otros tres botones a la interfase de usuario puede impactar en el presupuesto del proyecto y en el plazo, especialmente en el caso de los consultores externos, Al satisfacer a los usuarios finales, añade Spivey, el consultor o gerente de proyecto acepta añadir los tres botones, afirmando que será un cambio sencillo, solo para luego encontrar que los equipos de diseño técnico le dicen que añadir esos botones demora al proyecto tres meses debido al trabajo adicional que ellos conllevan.
“Alguien tiene que volver con el usuario y decirle ‘realmente no sabíamos de lo que estábamos hablando. Pensábamos que éste iba a ser un cambio simple, pero va a agregarle tres meses al proyecto’”
Un proceso de control de cambios señala a todos que pedir nuevas características y funciones es algo que tiene que ser solicitado de manera formal, y que pasará por un proceso de examen formal para determinar cuánto trabajo requerirá y cómo va a afectar los costos y plazos del proyecto. Con un proceso de control de cambios formal, un gerente de proyecto puede decir con mayor precisión si un cambio en particular es realmente menor, o no, Más aún, el auspiciador del proyecto puede tomar una decisión mejor informada acerca de las características y funciones adicionales que realmente valen la pena asumir, dado que ampliarán los costos y plazos del proyecto.
Con un proceso de control de cambios formal, hay menos sorpresas, lo cual hace feliz a todos.
7. Gestionar el riesgo
“La gestión del riesgo es una parte fundamental de la gestión del proyecto, sin importar su tamaño”, “Debe ser parte de todos los niveles de planeamiento, ya se del planeamiento inicial del proyecto o del planeamiento de las fases o niveles de cada nueva parte del proyecto. Muchas veces veo que se hace por adelantado y luego no se revisa”.
La gestión del riesgo es muy crítica, porque proporciona a los gerentes de proyecto un panorama anticipado, tanto de las amenazas que pueden desbarrancar el proyecto como de las oportunidades para mejorarlo. Las prácticas de gestión del riesgo, también proporcionan a los equipos del proyecto la oportunidad para comprometer a las personas, tales como los auspiciadores del proyecto y a los usuarios finales, que podrían controlar los riesgos que podrían amenazar un proyecto, señala.
8. Tener la documentación adecuada
Sin una adecuada documentación, los equipos de proyectos podrían no alcanzar los requerimientos funcionales y técnicos correctos para un proyecto, señala el auditor TI Ung. Y sin una adecuada documentación de los muchos requerimientos, el equipo del proyecto podría gastar mucho tiempo, esfuerzo y dinero en un proyecto que no satisface las expectativas del auspiciador y de los usuarios finales.
Los equipos de proyecto también se arriesgan al avanzar con un proyecto que carece de un plan de ejecución o estatutos, documentos que son críticos para el éxito de los proyectos.
La falta de documentación, “crea mucha confusión e incertidumbre acerca de la dirección en la que el proyecto debería ir”. La confusión, a su vez, crea conflictos, demoras y sobrecostos.
9. Realizar un buen proceso de Quality Assurance (QA)
Las acciones de quality assurance como integration testing, black box testing, functional testing y stress testing generalmente reciben poca atención, Algunas veces esto se debe a que el gerente de proyecto no está familiarizado con los diferentes tipos de QA testing. En otras ocasiones, el gerente de proyecto tiene que ajustar los gastos para cumplir con el inminente plazo del proyecto. Debido a que la QA generalmente se deja para el final de un proyecto, es la víctima frecuente del recorte de costos. Sin importar la causa, el resultado es software, un sistema o un nuevo proceso que no funciona adecuadamente.
“Un buen proceso de QA es muy importante”, “Un equipo de QA se aseguraría que los requerimientos y funcionalidades se encuentran intactos antes que los usuarios finales toquen el producto. Solo se requiere de un error para que se esparza la sensación de que el proyecto ha fallado”.
Recomiendacion realizar demos iniciales para solicitar feedback de los usuarios. Obtener feedback inicial es una de las formas más efectivas de reducir el riesgo de que un proyecto no satisfaga las necesidades de los usuarios finales (y se considere por tanto una falla)
10. Establecer el gobierno del proyecto
El gobierno establece el marco de la forma en que un proyecto o programa se administrará, un entendimiento o lenguaje común para que siga el equipo del proyecto, Cuando uno tiene un buen gobierno del proyecto, las personas que se encuentran involucradas con el proyecto entienden lo que tienen que hacer.
Cuando no hay un gobierno del proyecto, el personal podría ejecutar un proyecto de forma inconsistente. Por ejemplo, el equipo de desarrollo podría usar un marco de trabajo de gestión de proyecto, mientras que los analistas de negocio podrían usar un proceso diferente. Una ejecución inconsistente del proyecto incrementa el riesgo de falla.
