Introducción
Los proyectos a menudo son el medio para poner en práctica los planes estratégicos de una organización. Se prevén proyectos para desarrollar productos y servicios y aumentar la eficiencia operativa. Las empresas se están proyectando cada vez más y el gasto mundial en proyectos es del orden de muchos miles de millones de dólares anuales (Williams, 2005). Las razones son obvias. Los proyectos brindan la oportunidad de emplear prácticas de gestión de proyectos que promueven el uso eficiente y efectivo de los recursos. Sin embargo, a pesar de los avances en la disciplina y la profesión de gestión de proyectos, la experiencia común sugiere que muchos proyectos fracasan (Williams, 2005), lo que subraya la importancia y la necesidad de mejorar los procesos y el rendimiento de la gestión de proyectos.
En general, las organizaciones se esfuerzan por implementar las mejores prácticas de gestión de proyectos tradicionales, basadas en estándares PMI, para lograr los objetivos del proyecto y satisfacer las expectativas de los clientes. Sin embargo, no todos los procesos y prácticas recomendados del Cuerpo de Conocimiento de Gestión de Proyectos (Guía PMBOK®) pueden ser relevantes para cada proyecto. A menudo, un enfoque selectivo tiene sentido al adoptar procesos y prácticas de gestión de proyectos para satisfacer las necesidades específicas del proyecto en función de su tamaño, tipo, complejidad y la industria en la que se lleva a cabo el proyecto. Tal necesidad de un enfoque diferente para la gestión de proyectos de TI está bien documentada en la literatura de gestión de proyectos.
Los proyectos de desarrollo de software a menudo se enfrentan a desafíos conflictivos de desarrollar productos de software a un ritmo acelerado mientras los desarrollan con una solidez que los hace confiables (Boehm, 2002). Los proyectos de TI, cuyo objetivo es seguir el ritmo de los rápidos cambios tecnológicos, a menudo experimentan cambios de alcance durante las etapas de planificación e implementación. En consecuencia, los proyectos de TI tienen desafíos que son diferentes de los proyectos tradicionales. Se desarrollan y practican varios ajustes y modificaciones a las prácticas tradicionales de gestión de proyectos para proyectos de TI, introduciendo así nuevas metodologías de gestión de proyectos, como la gestión ágil de proyectos.
La metodología ágil de gestión de proyectos, con su mayor adaptabilidad al alcance que cambia con frecuencia, utiliza planificación iterativa o por fases e integración continua. El principio clave es mantener el alcance del proyecto suave. La metodología promueve la colaboración y da como resultado una mayor satisfacción del cliente. Sin embargo, agile no es una solución completa para desarrollar software a un ritmo rápido y al mismo tiempo satisfacer las demandas de robustez y fiabilidad de los clientes. En este contexto, Boehm (2002) recomendó una combinación de gestión de proyectos tradicional y metodología ágil de desarrollo de software que fuera factible y preferible. Un enfoque complementario sería desarrollar un enfoque basado en el riesgo que se adapte para conservar los beneficios de los métodos ágiles y basados en planes y, al mismo tiempo, mitigar muchas de sus debilidades (Boehm & Turner, 2003).
Este trabajo de investigación tiene como objetivo examinar las propuestas anteriores (Boehm, 2002; Boehm & Turner, 2003) de un enfoque combinado para la gestión de proyectos de consultoría de TI, que son diferentes de los proyectos de TI. Los proyectos de consultoría de TI están concebidos para gestionar y proporcionar apoyo a proyectos de TI. A menudo se inician en el sector gubernamental. Los proyectos de consultoría de TI no son proyectos de desarrollo de software, sino que proporcionan apoyo a proyectos de TI.
En este estudio, nuestro objetivo es desarrollar una comprensión de cómo las prácticas ágiles de gestión de proyectos son relevantes para los proyectos de consultoría de TI. Los objetivos del estudio son identificar los beneficios del uso de la gestión de proyectos ágil, su idoneidad y qué aspectos de la gestión de proyectos tradicional se pueden combinar con la gestión de proyectos ágil para proyectos de consultoría de TI a fin de mejorar el rendimiento del proyecto. En la siguiente sección, utilizando una extensa revisión de la literatura sobre la metodología de gestión de proyectos ágil, hemos identificado las características sobresalientes del método ágil y su enfoque único para la gestión de proyectos en comparación con la gestión de proyectos tradicional. La revisión de la literatura ha ayudado a desarrollar una comprensión de los conceptos clave y los beneficios del uso del desarrollo de software ágil. Además, sobre la base de los hallazgos de la revisión de la literatura, hemos desarrollado y presentado un método de investigación que utiliza un cuestionario estructurado para desarrollar una comprensión de los proyectos de consultoría de TI. El análisis y la discusión de los datos, presentados posteriormente, proporcionan información y conclusiones importantes del estudio. Concluimos el artículo con nuestros hallazgos de investigación y recomendaciones para proyectos de consultoría de TI.
Revisión de la literatura
Las prácticas tradicionales de gestión de proyectos, impulsadas por una planificación integral, se pueden utilizar cuando las especificaciones del proyecto están claramente definidas. Por otro lado, cuando las especificaciones están sujetas a cambios frecuentes durante la vida del proyecto, el enfoque tradicional para administrar los proyectos puede no funcionar de manera eficiente. Los proyectos de desarrollo de software a menudo se conciben con especificaciones mínimas, lo que provoca cambios frecuentes en estas especificaciones durante la implementación del proyecto. Además, la duración del desarrollo de proyectos de software es corta. Los métodos ágiles, en comparación con las técnicas tradicionales de gestión de proyectos, son adecuados para proyectos de desarrollo de software debido a la corta duración de desarrollo de estos proyectos (Hanakawa & Okura, 2004).
En general, varios métodos de desarrollo de software, como la gestión ágil de proyectos, prometen una mayor satisfacción del cliente, tasas de defectos más bajas, tiempos de desarrollo más rápidos y sirven como solución para los requisitos de proyectos que cambian rápidamente (Boehm & Turner, 2003). En contraste con la gestión de proyectos ágil, un modelo de etapa-puerta utiliza un proceso de trabajo desde la idea del concepto hasta un producto que finalmente se entrega. Este modelo desarrolla fases del ciclo de vida de la gestión de proyectos basadas en diferentes etapas de desarrollo de productos para la gestión de proyectos. Una distinción importante entre un modelo de etapa-puerta y una gestión de proyectos ágil es que el primero intenta minimizar los cambios de requisitos para que el producto se complete a tiempo (Karistrom & Runeson, 2005). Otro método para desarrollar software es SCRUM, que es un conjunto de principios de gestión de proyectos que emplean pequeños equipos multifuncionales y autogestionados (Schatz & Abdelshafi, 2005). SCRUM requiere que cada miembro del equipo y el propietario del producto trabajen juntos al principio de cada elemento de desarrollo y la metodología actúa como un envoltorio alrededor de los procesos de desarrollo existentes. Por lo tanto, Schatz y Abdelshafi argumentaron que SCRUM no tendrá un plan de referencia para medir el éxito del proyecto. Sin embargo, la gestión de proyectos ágil se considera para este estudio debido a su mayor flexibilidad y adaptabilidad a los proyectos de desarrollo de software.
Además de los beneficios mencionados anteriormente, la metodología ágil es aplicable a entornos turbulentos y en constante cambio (Highsmith & Cockburn, 2001). Además, el método ágil enfatiza la adaptabilidad al mercado, la tecnología y el proceso (Mellor, 2005). La metodología ágil es un enfoque que se centrará en las características importantes primero, y como resultado, buscará retroalimentación temprana sobre las características (Karistrom & Runeson, 2005). Una vez que se identifiquen las características importantes, el director del proyecto se asegurará de que no haya demoras. Karistrom y Runeson indicaron que el proceso ágil evitaría la acumulación de recursos, planes fijos y planes de apoyo a largo plazo.
Sin embargo, la metodología ágil no es adecuada para todos los proyectos de desarrollo de software. Citando a Scott Ambler, el desarrollador del método ágil, Boehm (2002) recomendó una metodología tradicional de gestión de proyectos basada en planes para el software de aseguramiento, como los sistemas vitales.
El método ágil, debido a su exigente entorno de proyecto caracterizado por el caos y la incertidumbre, necesita equipos de proyecto compuestos por personas talentosas para satisfacer necesidades y demandas desafiantes. Citando un estudio de investigación de Constantine (2001), Boehm (2002) sugirió que los métodos ágiles requieren personas altamente capaces. Además, agile no es adecuado para equipos más grandes (Highsmith & Cockburn, 2001), ya que requiere un trabajo en equipo estrechamente coordinado para tener éxito, y los equipos con más de 15 o 20 desarrolladores aumentan la dificultad de administrar el proyecto (Constantine, 2001).
Es obvio que el método ágil emplea equipos coherentes (Karistrom & Runeson, 2005). Karistrom y Runeson identificaron características ágiles adicionales, como tareas pequeñas y manejables, integración continua y pruebas automáticas. En consecuencia, los equipos de proyecto ágiles se caracterizan por una buena comunicación interna, una mayor calidad y una sensación de estar en control (Karistrom & Runas). Sin embargo, prevén un aislamiento potencial para el equipo ágil.
En términos de comunicación, gestión del progreso basada en documentos y control de calidad, una práctica común en la gestión de proyectos tradicional no coincide con el método de desarrollo de software ágil (Hanakawa & Okura, 2004). La interacción cara a cara para el reajuste continuo de los objetivos de desarrollo suele preferirse en las metodologías ágiles (Melnik & Mauer, 2004). Destacando la diferencia entre los métodos tradicionales y ágiles, Melnik y Mauer sugirieron que en el desarrollo de software se prefieren la transferencia de conocimientos a corto plazo y la comunicación y colaboración directas, en contraste con las prácticas tradicionales de gestión de proyectos, en las que se utilizan largas cadenas de transferencia de conocimientos, que a menudo son susceptibles de distorsión y pérdida de información.
Una de las diferencias importantes entre las prácticas de gestión de proyectos tradicionales basadas en planes y los métodos ágiles es que los métodos ágiles capturan la agilidad del conocimiento tácito del equipo del proyecto en lugar del conocimiento explícito, que a menudo se usa en forma de documentos y planes en la gestión de proyectos tradicional (Boehm, 2002).
Otra diferencia es la cantidad y el tipo de documentación creada para los proyectos. La gestión de proyectos tradicional basada en planes enfatiza la planificación detallada, el monitoreo y el control de los documentos. Los fundamentos de diseño, documentos que expresan razones y justificaciones, se crean mediante un procedimiento altamente automatizado y estos fundamentos de diseño sirven como documentación ágil (Sauer, 2003).
Coram y Bohner (2005) han identificado características comunes del método ágil: colaboración, equipos pequeños, horarios de lanzamiento cortos, boxeo de tiempo y pruebas constantes. El director del proyecto es responsable de garantizar un entorno altamente colaborativo. Para ello, el método ágil fomenta la colaboración entre equipos pequeños y algunos subequipos por proyecto. Como consecuencia, es probable que el método ágil requiera menos procesos y planificación para coordinar las actividades del equipo. El método ágil también utiliza horarios de lanzamiento cortos, que pueden variar de dos semanas a seis meses. El boxeo de tiempo es un concepto que impone una duración fija para el lanzamiento de los entregables del proyecto, lo que ayuda a reducir el chapado en oro y la fluencia del alcance. Las pruebas constantes garantizan la calidad y la integración del producto. Además, Coram y Bohner sugirieron que los gerentes de proyecto deben hacer un seguimiento del progreso y tomar decisiones de negocios con énfasis en responder al cambio en lugar de seguir un plan específico.
El boxeo de tiempo conduce a una planificación impredecible por mejor conjetura y las fechas fijas podrían traer sorpresas inesperadas durante la fase de desarrollo (Patton, 2003). Otro resultado de este proceso iterativo de planificación de proyectos es que el método ágil no puede monitorear el progreso basado en el porcentaje de finalización (Patton, 2003).
La participación de pequeños subequipos en la planificación dará lugar a ingenieros de desarrollo de software motivados; los problemas técnicos se plantean al principio del proyecto y habrá poca resistencia en la implementación (Karistrom & Runeson, 2005). Además, definir el alcance del proyecto con un enfoque ágil daría lugar a una reducción de los costos (Mcgovern, 2002). El método ágil utiliza una planificación basada en requisitos y también nos permitirá controlar el alcance (McGovern).
Utilizando todas las referencias y discusiones hasta ahora y otras (Little Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), la Tabla 1 proporciona una comparación resumida entre la gestión de proyectos tradicional y ágil prácticas.
Cuadro 1: Comparación entre la Gestión de Proyectos Ágil y Tradicional
| Fase de proyecto | Tradicional | Ágil |
| Iniciación |
|
|
| Planificación |
|
|
| Execution |
|
|
| Supervisión y Control |
|
|
| Liquidación |
|
|
Resumen de la Revisión de la literatura
La metodología de gestión de proyectos ágil se utiliza comúnmente para proyectos de desarrollo de software. Tiene una mayor adaptabilidad al alcance que cambia con frecuencia. Como consecuencia, la gestión ágil de proyectos utiliza la planificación iterativa o por fases y la integración continua a lo largo de la vida útil del proyecto. El principio clave en la gestión de proyectos ágil es mantener el alcance del proyecto suave. El método de gestión de proyectos ágil es diferente de un método de gestión de proyectos tradicional al asignar importancia a factores que tradicionalmente se consideran poco importantes. Agile asigna una importancia relativamente mayor a:
- Individuos e interacciones sobre procesos y herramientas
- Ejecución de proyectos sobre documentación completa
- Colaboración con el cliente sobre negociación de contratos
- Respuesta a cambios sobre un plan de proyecto
El método ágil enfatiza la flexibilidad para satisfacer las necesidades del proyecto. Además, se basa en los comentarios de los clientes para iniciar cambios en un plan de proyecto. La metodología utiliza el enfoque de identificar a los usuarios finales apropiados y sus objetivos para formular los entregables del proyecto y satisfacer las necesidades de ejecución de los procesos institucionales. Las ventajas de usar el método ágil incluyen una mayor satisfacción del cliente, tasas de defectos más bajas y tiempos de desarrollo más rápidos. Además, el método ágil es una respuesta a los requisitos que cambian rápidamente, ya que utiliza comentarios tempranos sobre las características tecnológicas de los entregables del proyecto. El método ágil garantiza que los requisitos no se abarroten. Las características clave del método ágil son la comunicación efectiva dentro y fuera del equipo del proyecto, y la flexibilidad demostrada para agregar más requisitos.
Estos beneficios ayudarían a las organizaciones a proporcionar un mejor servicio al cliente. Además, son relevantes en la economía actual, donde la globalización y una filosofía de libre marketing están afectando las percepciones de los clientes para aumentar las expectativas de entregar productos y/o servicios más rápido, más barato y mejor.
Sin embargo, el método ágil no está exento de deficiencias, como se puede ver en la Tabla 1. Los cambios frecuentes de alcance dificultan el seguimiento del progreso del proyecto. Además, no es fácil captar conocimientos tácitos en forma de lecciones aprendidas. El control de cambios de alcance, la documentación, el plan integral, la gestión de calidad y la gestión de riesgos son beneficios importantes de la gestión de proyectos tradicional de los que podemos privarnos al emplear el método ágil.
Metodología de investigación
Se utilizaron entrevistas personales y cuestionarios para recopilar los datos. Desarrollamos un cuestionario estructurado que consta de dos secciones. La primera sección fue diseñada para capturar detalles sobre el proyecto y sus características. Esta sección consta de 13 preguntas, que están relacionadas con la demografía del proyecto y las prácticas de gestión del proyecto. Se presentaron a los participantes del estudio con la opción de proporcionar respuestas abiertas cuando fuera necesario.
La segunda sección se centró en las declaraciones de prácticas de gestión de proyectos, y se pidió a los participantes que respondieran a estas declaraciones en una escala de cinco puntos, con 1 que denotaba «totalmente en desacuerdo» y 5 que denotaban «totalmente de acuerdo».»Las siguientes declaraciones se utilizaron para abordar principios comunes importantes de las prácticas de gestión de proyectos, así como para contrastar las prácticas de gestión de proyectos tradicionales y ágiles.
- Los criterios para medir el éxito del proyecto se basan en los objetivos y metas del proyecto.
- El proyecto está impulsado por requisitos.
- El proyecto es adaptable al cambio.
- En su opinión, los esfuerzos de gestión de proyectos lograron los resultados esperados
- Las interacciones cara a cara y las cadenas de comunicación más cortas tienen más importancia que los procesos y las herramientas.
- El enfoque del equipo se centra en la ejecución de proyectos a través de una documentación completa.
- La colaboración con el cliente sobre la negociación de contratos funciona mejor para su equipo.
- El proyecto tiene un alcance de proyecto bien definido.
- Las prácticas de gestión de proyectos siguen el ciclo de vida del proyecto de la Guía PMBOK®.
- Se sigue la planificación iterativa o por fases del proyecto para el proyecto.
- El proyecto tiene requisitos de documentación, como la adhesión a estándares como ISO9000, OMB 300.
- Los procedimientos de Prueba de Aceptación del usuario (UAT) se siguen durante todo el proyecto.
- El gerente de proyecto está facultado para tomar decisiones relacionadas con el proyecto sin intervención del cliente.
Las respuestas a estas afirmaciones se analizan junto con las preguntas apropiadas de la primera serie de 13 preguntas. En conjunto, las respuestas a ambas secciones proporcionaron una comprensión detallada del proyecto para un análisis significativo.
Resultados del estudio
El cuestionario se estructuró para capturar datos de 20 proyectos de consultoría de TI en curso en el momento de la investigación. De los proyectos, el 65% son proyectos de tipo contrato de tiempo y material y el resto son de tipo de precio fijo firme (FFP). Entre los proyectos de tiempo y materiales, el 55% tienen una duración de proyecto de más de dos años.
La mayoría de los equipos de proyecto son pequeños: solo el 15% tiene 10 o más miembros. Con respecto a la comunicación entre los miembros del equipo del proyecto, el 60% de los encuestados ha utilizado solo la comunicación formal para las necesidades del proyecto; el 30% utilizó la comunicación formal e informal, y el 10% restante se basó únicamente en métodos informales.
Uno de cada dos encuestados indicó que sus proyectos habían utilizado un plan de proyecto. En una pregunta relacionada, de los proyectos que no tenían un plan de proyecto, el 80% tampoco utilizó la planificación iterativa.
El cambio de alcance es un aspecto importante de este estudio. De los proyectos, el 70% ha experimentado un cambio de alcance al menos una vez. De los que experimentaron un cambio en el alcance del proyecto, el 60% lo experimentó más de dos veces. Mientras el cliente decide el cambio de alcance, el consultor, con el consentimiento del cliente, puede incluir el plan de control de calidad en el plan de gestión del proyecto. Cuando se les preguntó si tenían un plan de control de calidad para su proyecto, el 65% de los encuestados indicó que no utilizaba un plan de control de calidad.
Discusión y Análisis de resultados
Los resultados de la investigación se analizaron examinando cuidadosamente cualquier interrelación entre una pregunta y todas las demás preguntas, primero para validar los resultados y, segundo, para desarrollar estrategias de manejo efectivas. Además, estos resultados se analizaron con el fin de examinar qué prácticas de gestión de proyectos ágiles y tradicionales se pueden usar en combinación para desarrollar un enfoque sólido de gestión de proyectos para proyectos de consultoría de TI.
Criterios de éxito del proyecto Basados en sus Objetivos y Metas
Un proyecto se considera exitoso cuando cumple con sus objetivos y metas. Solo el 60% de los encuestados estuvo de acuerdo con la afirmación, «Los criterios para medir el éxito del proyecto se basan en los objetivos y metas del proyecto.»Alrededor del 30% de los encuestados no estaban de acuerdo. Un análisis más detallado ha demostrado que la razón del desacuerdo era que estos proyectos estaban experimentando condiciones y requisitos en constante cambio, o que el cliente no tenía claro el proyecto. En última instancia, estos proyectos experimentaban frecuentes cambios de alcance. En un caso en particular, las metas y objetivos del proyecto cambiaron.
Es interesante observar que no hay asociación entre el hecho de que los criterios de éxito de un proyecto se deriven de sus objetivos y cambio de alcance, tipo de proyecto y la existencia de un plan de proyecto. En otras palabras, la derivación de criterios de proyecto del plan estratégico de la organización no influye en el cambio de alcance ni en si el proyecto tiene un plan.
Requisitos del proyecto
Por lo general, se desarrolla un plan de proyecto detallado después de que se identifican claramente los requisitos del patrocinador del proyecto. El desarrollo del plan del proyecto y su ejecución, en principio, deben estar impulsados por estos requisitos. Por lo tanto, uno esperaría que los gerentes de proyecto estuvieran de acuerdo con la declaración, «El proyecto está impulsado por requisitos.»Los resultados del estudio muestran que solo el 60% de los encuestados dijo que sus proyectos están impulsados por requisitos. Alrededor del 20% de los encuestados que no estaban de acuerdo con la declaración indicaron que sus proyectos se ejecutan sin utilizar un plan de proyecto.
Aproximadamente el 20% de los encuestados que fueron neutrales en respuesta a esta afirmación son los gerentes de proyecto que no experimentaron ningún cambio de alcance en sus proyectos. Todos los demás encuestados, aquellos que estuvieron de acuerdo o en desacuerdo con la declaración, han experimentado un cambio de alcance al menos una vez en sus proyectos actuales.
En general, si un proyecto no se implementa de acuerdo con su plan, podemos suponer que no se identifican los requisitos o que se espera que los requisitos del proyecto cambien durante su ejecución. En este estudio, sin embargo, no podemos establecer tal asociación entre «implementar el proyecto sin usar el plan del proyecto» y el «el proyecto no está impulsado por requisitos», porque solo el 50% de los que estuvieron de acuerdo con la segunda afirmación también han gestionado proyectos sin usar un plan.
Adaptabilidad al cambio
Dieciocho de los 20 proyectos han respondido a los cambios en el proyecto con éxito. La adaptabilidad al cambio se considera una característica principal para que un proyecto sea candidato a usar una metodología de gestión de proyectos ágil. Los proyectos de consultoría de TI representados en este estudio han demostrado que tienen adaptabilidad para hacer frente al cambio de alcance.
Los esfuerzos de gestión de proyectos Lograron Resultados esperados
Los resultados sugieren que el cliente está satisfecho con el resultado en la mayoría de los proyectos (70%). Sin embargo, estas respuestas no se asociaron con las respuestas a otras preguntas importantes de la encuesta sobre el progreso del proyecto y el producto desarrollado desde la perspectiva del director del proyecto. Las razones son obvias. Los proyectos seguían experimentando sobrecostos de tiempo y costos. Si bien el resultado final en la entrega del producto de software es satisfactorio, los procesos de gestión de proyectos no se ejecutaron con éxito. La inferencia podría ser que la adopción de prácticas tradicionales de gestión de proyectos, como el desarrollo de hitos, el monitoreo y el control, habría ayudado a administrar el proyecto con éxito.
Importancia de la comunicación Cara a Cara frente a los Procesos
La comunicación es la clave para comprender los roles, las responsabilidades, las políticas y los procedimientos relacionados con los proyectos, y fomentar la colaboración. En última instancia, la comunicación conduce a un equipo de proyecto cohesionado y alienta a los miembros del equipo a colaborar y participar en la toma de decisiones. Siete de cada diez directores de proyecto que participaron en el estudio coincidieron en que las interacciones cara a cara y las cadenas de comunicación más cortas tenían más importancia que los procesos y las herramientas.
Los resultados muestran una fuerte asociación entre la importancia de la comunicación cara a cara y los medios de comunicación entre los miembros del equipo del proyecto. Aquellos que no estaban de acuerdo en que la comunicación cara a cara es más importante que los procesos del proyecto han utilizado la comunicación informal entre los miembros del equipo del proyecto, mientras que aquellos que consideraban que la comunicación cara a cara era más importante han utilizado la comunicación formal e informal.
Centrarse en la ejecución de proyectos por encima de la Documentación
La documentación de proyectos a menudo se pasa por alto y, en consecuencia, las organizaciones se ven privadas de importantes lecciones aprendidas en la planificación y ejecución de proyectos. Teniendo en cuenta que todos los proyectos representados en este estudio son proyectos del gobierno federal, es interesante observar que el 70% de los gerentes de proyecto que respondieron coincidieron en que sus equipos se centraron en la ejecución del proyecto en comparación con la creación de documentación completa. En unos pocos casos en los que los directores de proyecto han considerado que la documentación es más importante que la ejecución del proyecto, una investigación más detallada reveló que el cliente estaba indeciso sobre el proyecto en todos esos casos.
La colaboración con el cliente Sobre la Negociación de Contratos
La negociación de contratos es una característica esencial de los proyectos externos. Durante la negociación, ambas partes se centrarían en proteger sus propios intereses. La negociación del contrato puede tener lugar en diferentes etapas del proyecto. Es conveniente abordar estas cuestiones a través de la colaboración, específicamente durante la ejecución del proyecto; de lo contrario, dará lugar a problemas como la prórroga del contrato. Dado que todos los proyectos representados en este estudio son contratos, es alentador observar que más de la mitad de los gerentes de proyecto que respondieron (60%) consideran que la colaboración con el cliente es más importante que la negociación de contratos. Sugirieron que la colaboración funciona mejor para los equipos de proyecto.
Cuando hubo desacuerdo, lo que implica que la colaboración no es tan importante como la negociación, se asociaron dos hechos interesantes a esos proyectos. Todos los demás proyectos utilizaron el contacto directo como medio de comunicación con las partes interesadas del proyecto, pero estos proyectos utilizaron la comunicación de la cadena de mando y el cliente también se mostró indeciso sobre el proyecto. Ambos factores implican condiciones difíciles para la colaboración.
Proyecto y un Alcance de Proyecto Bien Definido
Los proyectos generalmente se asocian con incertidumbres y factores desconocidos, que conducen a la ambigüedad. En consecuencia, el alcance y las especificaciones detallados no se pueden desarrollar durante la fase inicial del proyecto. El alcance del proyecto cambia continuamente a lo largo del proyecto. A veces, los objetivos originales del proyecto también pueden cambiar. De los proyectos encuestados, el 40% tienen un alcance bien definido, mientras que otro 45% no lo tenía.
Sin embargo, el 80% de los proyectos experimentaron un cambio de alcance al menos una vez, lo que valida los argumentos presentados anteriormente.
Prácticas de Gestión de proyectos y Guía PMBOK® Ciclo de vida del proyecto
La Guía PMBOK ® ha desarrollado un elaborado proceso de ciclo de vida de gestión de proyectos; es exhaustivo y completo. Sin embargo, no es necesario que todos los procesos del ciclo de vida de gestión de proyectos de la Guía PMBOK® se apliquen a todos los proyectos. Su aprobación debería ser específica para cada proyecto. Como se esperaba, el 45% de los gerentes de proyecto siguieron las prácticas de gestión de proyectos del ciclo de vida del proyecto de la Guía PMBOK®, y otro 45% no lo hizo.
Planificación de proyectos iterativa o por fases
La definición del alcance y el plan de gestión del proyecto forman parte del plan del proyecto. Como se mencionó anteriormente, el desarrollo detallado del alcance y las especificaciones no se puede desarrollar al principio del proyecto. En consecuencia, el alcance del proyecto cambia continuamente a lo largo del proyecto, lo que subraya la importancia de la planificación iterativa o por fases del proyecto, una característica importante del método ágil. Cuando se le preguntó si se seguía o no la planificación iterativa o por fases del proyecto, la mitad de los encuestados indicó que sí, y solo el 15% no siguió la planificación iterativa del proyecto. Es interesante observar que todos los que no estaban de acuerdo con la práctica de la planificación iterativa de proyectos no tenían un plan de proyecto en primer lugar.
Documentación y Cumplimiento de Estándares
La documentación de proyectos sirve como referencia para el análisis de datos históricos y ayuda a las organizaciones a mejorar continuamente los procesos de gestión de proyectos y desarrollar estándares. La documentación también ayudará a determinar la experiencia adquirida y a modificar los sistemas de gestión de proyectos para lograr la madurez de la gestión de proyectos. OMB300 e ISO9000 sirven como guías en el diseño de sistemas de documentación de proyectos. En concreto, muchos proyectos gubernamentales deben cumplir las directrices de la OMB300. De los encuestados, el 80% dijo que los proyectos de TI que administraban tenían requisitos de documentación, como el cumplimiento de estándares como ISO9000 y OMB300. Sin embargo, estos requisitos para los proyectos de consultoría de TI son aplicables en una medida limitada.
Procedimientos de prueba de aceptación del usuario
La satisfacción del cliente es la medida principal de la calidad y el éxito de los artículos entregables del proyecto. Por lo tanto, los procedimientos de prueba de aceptación del usuario se consideran importantes. Incluso en el caso de entregables de proyectos menos tangibles, como el servicio, la medida subyacente del éxito del proyecto es la satisfacción del cliente. Sin embargo, es subjetivo. Solo el 30% de los encuestados dijo que siguió los procedimientos de prueba de aceptación de los usuarios durante todo el proyecto, y el 45% de los encuestados no lo hizo.
Empoderamiento para Tomar Decisiones relacionadas con el Proyecto
En general, los gerentes de proyecto deben tener mano libre para tomar decisiones relacionadas con el proyecto sin intervención del cliente, cuando estas decisiones no tengan un impacto importante en el alcance del proyecto o los entregables del proyecto. Solo el 15% estuvo de acuerdo en que el director del proyecto está facultado para tomar decisiones relacionadas con el proyecto sin intervención del cliente. Alrededor del 40% se mantuvo neutral, y el 45% restante dijo que el gerente del proyecto no tenía este poder. Dado que estos proyectos son externos y gubernamentales, estos resultados tienen sentido.
Conclusión
Los resultados de nuestro estudio muestran que la mayoría de los proyectos están impulsados por requisitos. Casi todos los proyectos representados en este estudio demostraron que son adaptables al cambio. La comunicación informal se considera más importante que los procesos y sistemas formales. Teniendo en cuenta que los proyectos del estudio están relacionados con el trabajo gubernamental, los resultados muestran que el equipo del proyecto se centró en la ejecución del proyecto a través de una documentación exhaustiva. Además, la colaboración con los clientes sobre la negociación de contratos funciona mejor para los equipos de proyecto. El cambio frecuente del alcance del proyecto significa la importancia de la planificación iterativa o por fases del proyecto; una característica importante de la gestión ágil de proyectos. Dado que todos los proyectos de consultoría de TI representados en este estudio son contratos, los resultados del estudio fomentan la adopción formal de una metodología ágil para los proyectos de consultoría de TI y su combinación con prácticas tradicionales de gestión de proyectos, como el desarrollo y monitoreo de hitos impulsados por planes, los procedimientos de aceptación de usuarios y las prácticas de gestión de calidad.
La idoneidad del método ágil para los proyectos es una obligación contractual relacionada con los documentos relativos a la planificación, el seguimiento y el control de los proyectos. Los proyectos asociados con el gobierno federal generalmente tienen requisitos de documentación significativos, como el cumplimiento de estándares como ISO9000 y OMB300; debemos tener precaución al modificar el método ágil para dichos proyectos.
El desafío es mantener la agilidad, la respuesta rápida al cambio, los planes flexibles y simples, la integración continua y otros beneficios del método ágil, al tiempo que incorpora algunos de los procesos integrales de las prácticas tradicionales de gestión de proyectos.