El documento discute las diferencias entre las metodologías PMI (Project Management Institute) y SCRUM para la gestión de proyectos de software. Señala que SCRUM es útil para proyectos medianos pero no para todo tipo de proyectos, mientras que PMI provee más herramientas para control de costos y estimación de riesgos. También describe la experiencia del autor migrando de PMI a SCRUM, notando beneficios como reuniones diarias que mejoraron la colaboración del equipo.

1. 
El equipo de desarrollo participa en la planeación
SCRUM resulta útil en proyectos de software (mediano), pero no lo veo aplicable a todo tipo
de proyectos. En SCRUM falta definir tareas/actividades dentro de las funciones del equipo
de desarrollo. El impacto de los cambios en el proyecto es la misma pero la dinámica de
SCRUM hace mas flexible su aceptación.

Con PMI estimaciones, definición de
cronograma, proyecciones

Participación activa y permanente de todo el
equipo

Actividades/ funciones pre-establecidas de
comienzo a fin.

Control de costos y gastos

No son claras las directrices de control

El product owner conoce y aprueba entregas

2. 
Se obtiene mayor productividad del equipo de
trabajo, cuando se exigen resultados mas
cortos

Problemas de documentación
Un proyecto que exige un riguroso control presupuestal o estimación de riesgos se gestiona
mejor a través de un framework que brinde herramientas para ello.

Con PM se obtiene mayor visibilidad y mejor
estimación de riesgos

Detección temprana de errores

Requiere monitorear la productividad del
equipo de trabajo

Los errores en el proyectos suelen detectarse
muy tarde

3. PMI vs. SCRUM
Mi experiencia básicamente ha sido en proyectos gestionados utilizando la metodología del PMI:
•
En proyectos de consultoría utilizábamos la carta de proyecto, WBS, gantt en MS Project, matriz de
riesgos, lecciones aprendidas; estas herramientas nos permitían cierto orden y formalidad ante
proyectos grandes y complejos. Adaptábamos los artefactos dependiendo de la magnitud del proyecto.
•
En mi experiencia actual, he participado en proyectos gestionados con la metodología del PMI,
usualmente la empresa tiene cierta flexibilidad de adaptar los artefactos, sin embargo, hay una PMO
que dicta las pautas para los proyectos y utilizamos el software PPM para la gestión de los proyectos,
control y visibilidad de la información de los mismos a toda la organización.
•
No tengo experiencia de gestión de proyectos con la metodología SCRUM, sin embargo, en la empresa
se gestionan de esta forma proyectos de alcance acotado, en el que se busca una solución expedita y
que no hay inversión de dinero, ni gran cantidad de recursos.
•
Luego de estudiar un poco sobre estas metodologías, ahora me parece que en algunos casos
trabajamos de esa forma para la entrega de requerimientos, ya que involucramos al equipo
desarrollador, el analista de negocio y el funcional, de forma tal que trabajan muy cercanos para
solucionar conflictos, revisar alcance, validar, reuniones con cierta frecuencia para revisar avance y
próximos pasos, siempre con un líder identificado.
Luego de lo revisado, puedo intuir que se puede tomar lo mejor de cada uno, me parece que
independientemente de la metodología a utilizar debemos evaluar algún alcance inicial, un caso de
negocio que justifique la inversión, identificar a los stakeholders, liderazgo, equipos de trabajo
identificados, gestionar los riesgos latentes. Luego como se desarrolla si me parece que podemos ir a
células de trabajo mas pequeñas, en los tracks, involucrando a los funcionales.

5. PMI vs. SCRUM (Continuación)
• En mi trabajo conviví con el cambio de metodologías más tradicionales (PMI), a Scrum. En un
principio hubo que cambiar y adaptarse a realizar reuniones diarias, que se volvían más largas
de lo necesario y que se tornaban un poco tediosas. Luego nos fuimos acostumbrando a hablar
solo de los temas pertinentes y comenzamos a cumplir con los tiempos esperados (entre 15 y
20 min). Estas reuniones nos fueron sirviendo para integrarnos más como equipo dado que
nos permitía saber que estaba haciendo el otro y poder ofrecer ayuda cuando había algún tema
bloqueante o dar sugerencias de como resolver algún problema. Por otro lado, los clientes
internos (el área de operaciones) quedaron más conformes con los resultados porque podían ir
viendo prototipos de las aplicaciones, y pedir cambios o dar su conformidad más rápidamente.
También nos sirvió para poder ir midiendo mejor nuestra velocidad como equipo y ver los
desvíos que íbamos teniendo. Como conclusión puedo decir que el cambio fue acertado por la
forma de trabajar en la empresa y por la composición de nuestro equipo, 7 personas todas
alocadas en el mismo lugar de trabajo.

6. PMI vs. SCRUM (Continuación)
• En mi trabajo conviví con el cambio de metodologías más tradicionales (PMI), a Scrum. En un
principio hubo que cambiar y adaptarse a realizar reuniones diarias, que se volvían más largas
de lo necesario y que se tornaban un poco tediosas. Luego nos fuimos acostumbrando a hablar
solo de los temas pertinentes y comenzamos a cumplir con los tiempos esperados (entre 15 y
20 min). Estas reuniones nos fueron sirviendo para integrarnos más como equipo dado que
nos permitía saber que estaba haciendo el otro y poder ofrecer ayuda cuando había algún tema
bloqueante o dar sugerencias de como resolver algún problema. Por otro lado, los clientes
internos (el área de operaciones) quedaron más conformes con los resultados porque podían ir
viendo prototipos de las aplicaciones, y pedir cambios o dar su conformidad más rápidamente.
También nos sirvió para poder ir midiendo mejor nuestra velocidad como equipo y ver los
desvíos que íbamos teniendo. Como conclusión puedo decir que el cambio fue acertado por la
forma de trabajar en la empresa y por la composición de nuestro equipo, 7 personas todas
alocadas en el mismo lugar de trabajo.