Proyectos TI: Adopción de Estándares
Principios de la gestión de proyectos clásica (predictiva)
Los estándares de “Proyecto” corresponden a un conjunto de guías que buscan establecer un modelo de diseño y ejecución de proyectos, predecible, escalable y que cuente con un esquema de gobierno de los proyectos. Para esto existen diversos enfoques metodológicos pero me atrevo a decir que los más difundidos a nivel mundial el estándar PMI y estándar Prince2. Estos estándares proveen de guías para todo tipo de proyectos, sin importar su tamaño ni industria. Ambos tienen una terminología y un ciclo de vida de los proyectos diferentes, les recomiendo que analicen ambos y adopten uno de ellos.
Con la idea de entregar algunos elementos al momento de la selección de la metodología a utilizar, me parece adecuado dar algunos antecedentes de ambos métodos
PMI, es un estándar desarrollado en los Estados Unidos de Norteamérica, con el mercado americano en mente cuando se desarrolló, PMI desarrolló su metodología denominada PMBOK en cual ya va en su cuarta versión (recientemente lanzada) y cuenta con esquemas de capacitación y certificación. Adicionalmente cuenta con capítulo en cada país donde está presente en Chile, lo pueden ver en . En nuestro país esta metodología se ha utilizado con mucha fuerza en proyecto industriales en particular en el caso de proyectos mineros. No cubre las etapas de pre-proyecto y tiene un enfoque a las actividades (WBS), es decir es un “project management process”.
Project Management Body of Knowledge (PMBOK)
Prince2, se trata de un estándar desarrollado en Gran Bretaña, por la OGC, oficina del gobierno británico, su foco original fue el sector público, pero ha sido adoptada en otras industrias, tiene una fuerte presencia en Europa y en las zonas de influencia del Reino Unido. Los seguidores de este método le critican a PMI su excesivo enfoque comercial al momento de adoptar dichas prácticas y en los procesos de certificación. No cubre las etapas de adquisición, define roles estándares para los miembros de los equipos de trabajo y tiene un enfoque a producto más que a actividad, es decir es un product oriented process.
Les adjunto un documento que compara ambas metodologías, esto es a partir del PMBOK realiza un análisis de Prince2, es bastante interesante y permite tener una mejor visión de ambos métodos. Ver en A comparison of Prince2 vs PMBOK
Cualquiera sea su decisión de metodología a utilizar, es fundamental tener en consideración algunos elementos que pueden ayudar su adopción
- Instalar la nomenclatura, todas las metodologías de proyecto cuentan con sendas terminologías y glosarios (de hecho para certificarse PMI hay que aprenderse todos esos términos), los más importante es que sus equipos de proyecto al momento de utilizar el método entiendan todos lo mismo por un determinado concepto.
- Implementar el ciclo de vida de los proyecto para los nuevos proyectos, no tiene sentido insertarlo en los proyectos en curso. Esto logrará una mayor motivación el los equipos de trabajo y no afectará a los proyectos en curso.
- Utilice las guías y recomendaciones del estándar, evalúe las herramientas que el estándar provee y adóptelas en su proyecto, sea selectivo, recuerde que estos estándares están pensados en forma genérica y son para cualquier tipo de proyecto en cualquier industria, existirán etapas, prácticas que en sus proyectos no aplican “no fuerce su uso”.
- Realice importante esfuerzos de capacitación e inducción del método en su equipos de trabajo, debe contar con un proceso de entrenamiento constante de su personal.
- Utilice herramientas tecnológicas como apoyo, idealmente herramientas de gestión de proyectos, sea majadero en su uso ya que eso implica mayor orden en el proceso. Seleccione la mejor herramienta para el soporte (interna, comercial, Web u otra)
¿Seleccionó la metodología de su agrado?
En la compañía donde trabajo utilizamos el estándar PMI y nos ha dado buen resultado en implementaciones de infraestructura TI. Los de Prince2 lo he visto ya que también trabajamos con ITIL, pero no utilizamos ese estándar para la gestión de proyectos.
Interesante el documento que adjuntas para la comparación
Saludos
Gracias Samuel por el comentario, en general Prince2 es menos conocido en esta parte del mundo ya que hay una mayor influencia de PMI por su origen.
Saludos
Estimado Alejandro,
Muchas gracias por el documento de comparación, en mi organización estamos implementando ITIL V3, y por otro lado estamos queremos gestionar nuestros proyectos IT en base a Prince2.
Existe en Chile o Argentina un centro de capacitación de Prince2?
Saludos,
Gracias Héctor por tu comentario, no conozco centros de formación/certificación de Prince2 en Chile ni Argentina, existen en España, probablemente debido a que dicha metodología tiene mayor presencia en Europa, en nuestros paises tiene mayor presencia PMI
—————–
Alejandro Barros
Cordial saludo alejandro, existen otras herramientas diferentes al PMI y a PRINCE2 para la administracion de proyectos, debido a que estoy realizando una investigacion acerca de estos temas y las mas conocidas por decirlo de esa manera son esas dos herramientas, le agradeceria si usted me podria ayudar.
Gracias Julieth C.
Gracias Julieth por tu comentario, respecto de tu pregunta existen muchas metodologías además de Prince2 y PMI pero tienen menos difusión y son más acotadas, las métodologias Prince y PMI se han trasnfromado en un estándar de facto. Incluso he visto organizaciones que utilizan una mezcla de ambas.
Alejandro Barros
Hola como esta quisiera ponerme en contacto con usted, ya que me interesa conocer procesos sobre el pmi y ti, para un trabajo de investigacion que estoy haciendo, le agradezco mucho si me ayuda.
Great article indeed.
I thought you might want to know that prince2.com is not actually the official website for PRINCE2, which should be prince2.org.uk.
I thought you probably meant to link to prince2.org.uk originally. The official site would be more relevant and appropriate to readers.
Best regards,
Jay
Thanks Jay for the Prince2 reference, I jus changed the URL that you send me
Best regards,
—————–
Alejandro Barros
Alejandro. Tu artículo me parece muy bueno. La liga que agregas para ver un documento .pdf en donde se comparan ambas metodologías me parece muy práctico, sin embargo, necesito tu orientación en la búsqueda de mas información, sobre todo del Prince2. Actualmente realizo un ensayo de maestría y debido a la falta de referencias bibliogáficas, no te puedo citar.
Tienes trabajos publicados al respecto¿
Saludos
Gracias Fernando por el comentario, no conozco mucha más información, te recomiendo buscar información en sitios del gobierno inglés quienes son grandes usuarios de esta metodología, por este lado del mundo nos inclinamos más por el PMI
—————–
Alejandro Barros
Alejandro:
Buen blog, felicitaciones. Como una colaboración propongo a los participantes buscar una integración de la profesion de Gerente de Proyectos en el ambito LatinoAmerica, sin descuidar los aportes de otras naciones. He observado diversos esfuerzos y creo vale la pena, pues somos el unico continente con una lengua común e idiosincrasia similar, con mucha historia comun que nos une.
Slds
Señores, interesante artículo, lo estoy analizando, dado que tengo asignado implementar esta metodología de PMO a proyectos del área de TI. Me encuentro en pañales, pero gracias a esta información ya me encuentro encaminado. Por favor, si existe mayor información que me permita generar más sinergía y poder aplicar esto a un proyecto pequeño. Saludos, Guillermo.
No se debe tener duda que pmi o prince2 son excelente metodologías para proyectos que tienen los requerimientos claros y bien definidos, con lo cual podemos tener procesos precisos y estimaciones fiables. Por ejemplo para la construcción de un edificio, es un proyecto que debe ser predictivo, a nadie se le ocurriría pedir un edificio de 11 pisos y luego de estar terminado pedir que sea de 30.
Pero esto para un proyecto de software es una utopía, en general pasa todo lo contrario, los requerimientos no son claros, solo son buenas intensiones e ideas, a eso se debe agregar que los métodos de estimación del software siguen siendo poco precisos y mas aun la diferencia entre un desarrollador y otro puede llegar a ser de un 1000%.
Entonces tenemos que por un lado tenemos requerimientos no definidos, estimaciones poco predecibles y diferencias aberrantes entre un profesional y otro. A eso sumar que a mitad de camino te pueden pedir que el edificio de 11 pisos ahora solo tenga 5, pero que pareciera que tuviera 22.
Lo anterior suena a caos y hacer encajar eso en la gestión clásica es imposible, por lo que debemos cambiar nuestro método a una gestión evolutiva, scrum es excelente para estos casos, microsoft tambien tiene su msf for agile, pero esta demasiado ligado a su plataforma .NET.
En resumen la gestión clásica es excelente para proyectos que podemos meter en procesos, el producto final es el termino del proyecto y las personas que lo realizan no tienen un gran impacto en su ejecución, por ejemplo pegar ladrillos, un albañil a otro no varia mucho su productividad.
Pero para proyectos donde lo que importa es el capital humano, la innovación, ambientes cambiantes, el proyecto necesariamente debe ser evolutivo. Incluso muchos hablan de que no existe el producto final, solo existen las versiones.
Todos los días vemos nuevos productos desarrollados bajo el concepto de evolución, sin ir mas lejos iphone, esta en contaste evolucionado, lo mismo para galaxy de samsung y han obligado a nokia a doblar la rodia y meterse al mundo de los smartphone. Todos son basados en un proyecto común, un smathone, pero no tienen claro como sera este en 1 año mas, los consumidores y la competencia los obliga a estar contantemente modificando sus entregas.
Lo mismo pasa con la industria del software, un día todo es cliente/servidor, luego web, ahora es la nube, pero nadie puede decir que sera mañana, como debemos evolucionar nuestros proyectos.
No me he parado a analizar mucho lo escrito, así que puede que no quede claro del todo, pero ojala sirvar para explicar un poco que no todo es predecible y debo decir que yo seria el hincha numero 1 si estoy fuera así, pero lamentablemente muchos proyectos se levantan para enfrentar a la competencia.
http://es.wikipedia.org/wiki/Scrum
Como ultimo punto, la gestión clasica se apoya mucho en los procesos, le da demasiado valor a ellos, pero olvida a las personas. Estos últimos son quienes dan vida a nuestros proyectos, que en empresas de software o ti, las personas son al rededor del 70% del capital de la empresa. Así que talvez es hora de menos procesos y mas gestión del talento.
Hola a todos,
gracias por este espacio. Quisiera aportar a todos quienes piensen que adoptando PMI, PRINCE, CMMI, ITIL etc, resolverán sus problemas de gestión…. se están equivocando y mucho…. les dejo 2 tips, que he aprendido por tanto esfuerzo en trabajo de certificaciones..
1) el estándar XXi lo que sea, a menos que quieran comprar la chapa del certificado no es necesario, lo mejor es tomar lo más básico y elemental de cada modelo y adaptarlo siempre con sencillez y tino a la cultura de la empresa y la gente…. es la gente quien tiene que hace la metodología y perdonenme pero he visto consultores PMI tratando de evangelizar su estándar con insufribles templates que desaniman a cualquiera que tenga que “gestionarlos”…. tomar lo necesario y hacerlo simple.
2) generalmente los estandares parten desde la base que la “necesidad” está definida asi que demosle con el proyecto…. lo terrible es que la mayoría de las veces, los proyectos parten con pobres definiciones, con tiempos asignados sin un estudio o por comerciales motivados por sus propios intereses o metas…. el trabajo más duro es esta etapa, la de predefinición, desarrollo de propuestas, business case o como quieran llamarle, es necesario gastar tiempo acá y poner la metodología acá con el mismo énfasis que en proyectos….
Cuándo han ido al doctor y le han dicho… “Dr. Pérez tengo “problemas en el corazón” y quiero que me mejore en 3 meses…”
Sepamos hacer respetar nuestra experiencia y nuestros estudios de ingeniería
Esto tampoco resolverá sus problemas…. pero es la base para lograr una cultura de trabajo más ordenada y proyectos con un color un poco más “ecológico” tipo bandera de Libia
Gracias Christian por to comentario el que comparto en gran medida, pero muchas empresas van al modelo de certificaciones por un tema más de marketing (te “compran” más si tienes el sello) que de mejoramiento de prácticas.
Por otro lado estas metodologías son de “amplio espectro” y como tal deben abordar proyectos de de cientos sino miles de millones de dólares y otros muy pequeños, por lo que parametrización del método en función del problema a abordar en fundamental.
Saludos
PD: No se por que te pidió aprobación, se supone que pide aprobación para comentarios que vienen con URL, lamentable efecto del SPAM, es el filtro de Bligoo
—————–
Alejandro Barros
Hola, me puedes indicar si existe alguna metodología propia para gestión de proyectos TIC … PMBOK o PRINCE2 se las puede adaptar pero me dicen que mi trabajo investigativo debe estar con base a una metodología propia para este tipo de proyectos.
Gracias
FM
Existen algunas daptaciones de PMI/Prince2 a proyectos TIC, las cuales adoptan los conceptos de CMMi y Modelos Agiles del tipo Scrum y XP, te recomiendo las busques en la red hay bastante información al respecto
Saludos
—————–
Alejandro Barros
Hola Alejandro
Agradezco tu respuesta a mi consulta anterior.
Me encuentro en la búsqueda de un software libre que permita la gestión de metadatos, por favor si conoces de alguna herramienta hazmela saber.
Gracias y saludos,
FM
Saludos Samuel, me interesa contactarme con ud. para tratar una consulta acerca de su metodologia de pmi para TI. Porfavor me puede responder a mi correo xnauta69@yahoo.com
Gracias
Comparto tus ideas, sobre todo en que las personas son lo mas importante. El capital Humano, es lo que hace y hara la diferencia.
Buenas Noches;
Respecto al tema quiero realizar las siguientes observaciones y algunos errores en percepcion:
1- EL PMI: el PMI no es un estandar, es el Project Management Institute, es una instituticion americana.
2- PMBOK: No es una metodologia es una Guia y esta reconocida como estandar por la ANSI. No se debe tomar como una metodologia porque el PMBOK no dice el que y por que y el para que y nos dice el “COMO”. Las metodologias para proyectos como lo podria ser el marco logico si no dice como hacer las cosas; entre tanto el PMBOK esta compuesta de “PROCESOS” que cada organizacion debe evaluar cuales aplican a sus proyectos.
Buen artículo Alejandro, es bueno aclarar los diferentes estándares que existen
como se construye el estándar de u proyecto justificando la secuencia de pasos a considerar