Algunos de los conferencistas nos presentarán casos reales vividos por ellos como gerentes de proyectos, otros nos explicarán algunas metodologías utilizadas y finalmente presentaremos la octava versión de la encuesta sobre el tema de gerencia de proyectos de TI en Colombia.

Queremos invitarlos a que nos acompañen en esta nueva versión de la Jornada donde tendremos dos días de actualización y de espacios de discusión sobre los diferentes temas de la Gerencia de Proyectos de Tecnología de la Información.

Para las personas certificadas PMP, la participación a este evento con su respectivo certificado, le permitirá registrar 16 PDUs en categoría 4, los cuales le servirán para la renovación de su certificación.

Marzo 11 y 12 de 2010 (8:00am a 6:00pm)
Auditorios CM
Cra 19C No 90 -30 Piso 6
Bogotá, Colombia

Más información en ACIS

Por eso, es común encontrar en el medio colombiano que, en las empresas proveedoras de servicios de desarrollo y producción de SW existe una resistencia común a las metodologías ágiles de producción de SW. En consecuencia expongo a continuación algunos tips para aquellos que confían en la aproximación ágil de desarrollo y temen aplicarla a proyectos de costo fijo.

• Asegurar un cliente comprometido. Un cliente comprometido seguramente entenderá el costo y la responsabilidad asociado a una ejecución ágil de la producción. Esta aproximación tiene muchas ventajas al reducir los riesgos, minimizar posibles problemas de “scope creep” y permitir un mayor control tangible sobre el avance. Desde luego significa un costo alto en compromiso. La administración del cambio es, en esencia una modificación al contrato y por lo tanto será seguramente un incremento en el costo. Un consejo, el compromiso del cliente es evidente desde las reuniones de pre-venta o lanzamiento del proyecto, si el cliente demuestra poco interés o tiene otras prioridades desde el lanzamiento, es seguro que este comportamiento persistirá a lo largo de toda la ejecución.
• Garantizar colaboración oportuna. En la ejecución ágil de proyectos asume un compromiso continuo sin descanso o pausa. La ejecución tradicional sólo presenta este nivel de compromiso en la ejecución de las actividades de la ruta crítica. En el desarrollo ágil no existe tal cosa y por tanto cada iteración o sprint debe por obligación ser administrado como ruta crítica. Una retroalimentación tardía o cualquier otro tipo de participación del lado del cliente que represente demora es, sin excepción una grave falta al compromiso y al dinamismo del proyecto.
• Dividir es vencer -muchos proyectos pequeños son mejores que un gran proyecto grande. En realidad esta es la verdadera razón de la existencia de las metodologías ágiles, es mejor pequeños adelantos incrementales a un gran salto tradicional -similar la fábula de “la liebre y la tortuga” de Esopo, donde cada iteración es un pequeño paso de la tortuga, y un gran ciclo de desarrollo tradicional es como un gran “pique” del conejo. Para garantizar una adecuada distribución del trabajo es importante siempre considerar los drivers del negocio y sobre aquello las historias de usuario que representen la mejor calidad y mayor cantidad posible de  requerimientos para la iteración planeada.
• Permitir que el cliente participe en la priorización de los requerimientos, de forma directa el cliente quien visualiza efectivamente los sacrificios funcionales y de tiempo que se deben tomar para garantizar la continuidad y éxito del proyecto-recuerde el primer consejo, un cliente comprometido compartirá responsabilidades con el proveedor.
• Definir los requerimientos como historias de usuario con el cliente. Este punto puede tener gran discusión, pero en su defensa, estas cortas descripciones pueden ser apoyadas por elementos detallados en los casos que así se requiera. Las historias de usuario son, por defecto, simples y cortas, y así son fáciles de entender. Las historias de usuario pueden ser derivadas de los drivers del negocio. Así mismo, se asume que en grupos auto-organizados, el entendimiento de los drivers de negocio asociados al desarrollo del producto son razón suficiente para garantizar un adecuado factor de “cumplimiento/satisfacción”.
• Intercambiar requerimientos. Cuando en un proyecto se detecta un incremento sustancial en los requerimientos de cambio o nuevas solicitudes, significa que el resultado obtenido no es el esperado y/o es probable que cumpla con las especificaciones originales pero sea insuficiente para cubrir las necesidades actuales. Introducir nuevos requerimientos al sistema es, en un proyecto de costo fijo, restrictivo en tiempo -por la conocida triple restricción, por eso, más allá del “control de cambios” piense siempre en “intercambio de requerimientos”. Las habilidades de negociación son críticas, ya que el control de cambios debe ser estricto para garantizar la finalización oportuna y sobre el costo planeado, así como minimizar el impacto en la planeación continua de las iteraciones. Recuerde que en la metodología ágil no se debe interrumpir una iteración.
• Proponer fases futuras. Tras la negociación de los requerimientos es importante considerar que no todos los requerimientos puedan ser resueltos en el tiempo y costo (que casi siempre son fijos), por lo tanto es saludable documentar los requerimientos y proponer, en pro de una sana relación cliente-proveedor, nuevas fases de proyecto.
• Evaluar antes de iniciar otras fases. El punto anterior asume un cierre de proyecto. El objetivo de posponer entregables no se debe interpretar como una extensión del proyecto actual o nuevas iteraciones a nuevo costo. Este cierre es saludable y permite la evaluación -a blanco y negro- del producto entregado. En ese periodo es prudente evaluar con el uso, la calidad del producto, el grado de completitud de los requerimientos, y satisfacción del cliente.
• Involucrar presencialmente al cliente. Esto es algo muy complejo y sólo ocurrirá cuando el proyecto sea crítico, sin embargo algunos métodos ágiles definen roles al interior de sus grupos de trabajo para garantizar una adecuada representación en todo momento de los intereses del cliente y de las necesidades del negocio.
• Documentar y evaluar las lecciones aprendidas. Algunas metodologías no hacen suficiente énfasis en este punto, sin embargo es algo que nunca debemos olvidar, documentar lo aprendido a nivel de proceso, de producto, de manejo de cliente, de negocio, y demás.

En conclusión el costo fijo no es una restricción excluyente de los procesos de desarrollo ágil de producto, sin embargo si debe asumirse una relación gana-gana entre el cliente y el proveedor ya que, como en todo, esta decisión tiene sus PROs y sus CONTRAs. El desarrollo de software es, por naturaleza, un “salto de fe”, y en mi concepto, el desarrollo iterativo es por lo tanto una reducción de la distancia de “este salto de fe”, al incluir el desarrollo iterativo y la producción de entregables de valor en cada iteración.

Objetivo 1: Terminar a tiempo

Este es el más antiguo y enredado de los objetivos mencionados. Es el más difícil puesto que los requerimientos muy probablemente cambiaran durante el ciclo de vida del proyecto y, como nos pasa a todos, el cronograma original era en “algo” optimista.

Para garantizar el éxito deberá, como gerente de proyecto, gestionar el alcance con suma precaución. Implementar un proceso de control de cambios adecuado para incluir propiamente todos los nuevos requerimientos y cambios. Mantener siempre actualizado su plan de proyecto/trabajo, evaluar el progreso del proyecto (planeado vs. real). Identificar las desviaciones del plan y corregir el rumbo del proyecto lo más pronto posible.

Objetivo 2: No exceder presupuesto

Asegurar los costos del proyecto de acuerdo al presupuesto -o en muchos casos, por debajo- no es tarea fácil. Para ello establecer líneas base de presupuesto permitirán comparar y hacer seguimiento en todo momento a la ejecución de dicho presupuesto. Es muy importante incluir todos los costos relacionados con el proyecto, ya sea de forma directa o indirecta -como son entre otros: personal, equipos, proveedores, materiales. Esto logra que, al establecer el plan de ejecución -las tareas por hacer- se pueda asociar con mayor certeza un plan de ejecución presupuestal.

No debemos olvidar que es posible balancear el gasto realizado, si para algunas tareas tenemos sobrecosto y para otras ahorro.

Objetivo 3: Satisfacer los requerimientos

Este objetivo es intrínseco ya que es por los requerimientos que se definió el proyecto para el cual estamos trabajando o vamos a trabajar. Sin importar cuales sean estos requerimientos, nuestro objetivos como gerentes es garantizar que estos requerimientos se cumplen en un 100%.

El truco es garantizar que la información detallada de algunos requerimientos es suficiente al inicio de la ejecución. Si los requerimientos son ambiguos, de seguro existirán diferencias entre las expectativas e interpretaciones, y es ahi donde “un requerimiento” se convierte en todo un “subproyecto”, lo que en otros términos en una asignación de personas o consumo inesperado de recursos.

Objetivo 4: Hacer felices a los clientes

Es curioso pero cierto, usted puede terminar su proyecto a tiempo, dentro del presupuesto estimado y habiendo alcanzado el 100% de los requerimientos, y esto no garantiza que el resultado sea un cliente contento/agradecido. Esto se debe en la mayoría de los casos a que los requerimientos no concuerdan con las expectativas, y esto significa desde luego que las expectativas deben ser gestionadas de forma similar a los requerimientos.

Para garantizar que el patrocinador del proyecto (sponsor), los clientes y otros interesados (stakeholders) están contentos al final del proyecto, es vital gestionar y manejar las expectativas de cada uno de forma cuidadosa. Para ello, es importante mantener un contacto regular con ellos, informando sobre el avance. Este informe de avance no puede ser otra cosa más que real, claro y sencillo de entender. También es importante darles un espacio regularmente para comentar sus dudas e inquietudes. Y, desde luego, es importante poner la cara cuando se presenten problemas, retrasos, o se deban tomar decisiones importantes. La realidad, abierta y honesta, es siempre la mejor herramienta para gestionar las expectativas de los interesados.

Objetivo 5: Mantener un equipo alegre y motivado

Para terminar, si ha todos los objetivos anteriores les suma, la idea de lograrlos con un equipo alegre y motivado, no podemos esperar otra cosa que el interés de volver a trabajar juntos en el siguiente proyecto. Y así es como su equipo deberá sentirse al final del proyecto. La satisfacción del equipo es crítica para el éxito del proyecto.

Mantenga a su equipo de trabajo contento, recompensando sus éxitos y reconociendo el esfuerzo. Asigne el trabajo garantizando que aquellos que tienen la responsabilidad de hacer algo, tienen las competencias para hacerlo. Actividades de construcción de equipo (team building) son necesarias para elevar la moral del equipo. Con un equipo motivado y alegre es posible lograr todo objetivo.

Estos son, Los 5 Objetivos Genéricos que debe establecer para cada proyecto.

Artículo publicado por Method123 en su lista de correo -yo me tomé el tiempo de “traducirlo”.

Depende de la estructura y la naturaleza de la organización y del negocio, cómo y dónde se debe ubicar la oficina de proyectos a nivel jerárquico. Por ejemplo, esta puede puede hacer parte de la unidad de tecnología e informática de una compañía tradicional, cuya cadena de valor no esta soportada en proyectos (grandes superficies, manufactura de bienes de primera necesidad); o puede hacer parte estratégica de las unidades de negocio (empresas de construcción, de investigación, e incluso publicidad). Su ubicación dentro de la jerarquía de la organización incide directamente en la magnitud del impacto sobre la operación.

La cultura organizacional por su parte incide directamente en la postura que adoptará la recién creada oficina de proyectos frente a los proyectos nuevos y en curso. En una organización funcional, la capacidad de intervención de una oficina de proyectos es limitada, debido a que en la mayoría de los casos, no tiene el poder suficiente para incidir en las decisiones de las unidades funcionales, y por lo tanto la oficina de proyectos tendrá un cáracter orientado al soporte y resolución de elementos puntuales (oficina consultiva). En el caso contrario, una compañía proyectizada, tiene mayor oportunidad y espacio para constituir una oficina de proyectos en niveles gerenciales y/o estratégicos de la compañía, consolidando por su parte un herramienta de poder y persuación que le permitirá a la oficina ejercer labores directivas y de control más estrictas (oficina de dirección).

Con el fin último de simplificar la implementación de una nueva oficina de proyectos, es necesario analizar las metodología existenes y su flexbilidad para adaptarse a la organización. Definir el proceso y los comportamientos de los individuos en el tiempo de vida de los proyectos hará todo más fácil de entender y transmitir. Metodologías, muchas, metodología aplicada en la organización, sólo una.

Un error común es pensar que el PMI es una metodología y que el PMBoK la describe, cuando en realidad, el PMBoK sólo describe todas aquellas herramientas contempladas dentro de las labores de administración y gestón de proyectos, que, en su momento serán evaluados por la organización para determinar su relevancia dentro del caso específico.

Las metodologías no son tampoco un producto de software, o un proveedor. Las metodlogías son los procesos definidos de las organizaciones, con claridad y certeza. Una metodología se asume estándar cuando varias organizaciones la implementan y soportan -caso puntual de PRINCE2, o el PPM, o incluso el mal conocido SDP21. Sin embargo, la implementación de una metodología, asistida de forma automática por un producto de software, es sin duda mucho mas simple que aquella que delega la responsabilidad administrativa de la información y su confiabilidad, en las personas que además deben interiorizar el cambio en los procesos.

Las oficinas de proyectos responden a las necesidades de las organizaciones, y en tiempos económicos difíciles, donde todos son susceptibles a cambios, estructuras de organización flexibles y proyectizadas tienden a emerger como alivio a la lentidud organizacional de la cual muchas empresas adolecen. 

Como les comenté, el simple hecho de que la ciudad se presente como Bogota, Columbia, me expresa el sentido de seriedad y veracidad del mismo.

La concepción moderna de la gerencia ágil de proyectos surge a mediados de los 90’s como respuesta a las metodologías sobrecargadas que presentaban muchas falencias y un deterioro de la percepción y relación entre los clientes y los desarrolladores de software debido a, entre otras cosas, la regulación excesiva, el incorporado micro-management del modelo de desarrollo en cascada (waterfall) ,y extremadamente estricto. La excesiva burocracia y lentitud no era consecuente con la manera como los desarrolladores trabajan, por tanto el rendimiento y capacidad productiva se veía negativamente impactada.

El desarrollo de software era originalmente ágil, y por tanto la regulación excesiva del proceso puede, entenderse como una evolución inadecuada en busca de la perfección -que todos sabemos no existe en términos de software. Estos procesos definidos de desarrollo ágil originales eran conocidos como metodologías livianas y existían antes de los modelos pesados como SDP21 y CMM.

El Manifiesto Ágil

A inicios del 2001, varios detractores de los modelos tradicionales que habían apoyado y desarrollado metodologías livianas se reunieron y definieron lo que, en su momento los identificaba como un grupo. El resultado de esa reunión fue el documento conocido como el Manifiesto Ágil.

Estamos  poniendo  al  descubierto  mejores métodos  para  desarrollar  software,  haciéndolo  y ayudando  a  otros  a  que  lo  hagan.  Con  este trabajo hemos llegado a valorar:

• A  los  individuos  y su  interacción, por encima de los procesos y las herramientas.
• El  software  que  funciona,  por  encima  de  la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La  respuesta  al  cambio,  por  encima  del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Apoyando el manifiesto se presentaron 12 principios mencionados a continuación:

• Nuestra más alta prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor
• Son bienvenidos los requisitos cambiantes, incluso en etapas avanzadas del desarrollo. Los procesos ágiles se adaptan y aprovechan del cambio como ventaja competitiva para el cliente.
• Entregar software que funcione frecuentemente, en periodos desde un par de semanas hasta un par de meses, con preferencia en escalas de tiempo breves.
• Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a lo largo del proyecto.
• Proyectos definidos y llevados a cabo en torno a individuos motivados. Proveerles el ambiente y el respaldo que necesitan para realizar sus labores, y confiar en que son capaces de de realizar las tareas asignadas.
• La forma más eficiente y efectiva de comunicar información al interior del equipo de desarrollo es mediante la conversación cara a cara.
• El software que funciona es la principal medida del progreso.
• Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica enaltece la agilidad.
• La simplicidad, definida como arte de maximizar la cantidad de trabajo no realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados -self-organized teams.
• En intervalos regulares, el equipo reflexiona sobre formas de ser más efectivo y ajusta su conducta en consecuencia.

La gerencia ágil de proyectos se fundamenta en la iniciativa definida por los desarrolladores de software, y adopta el término trabajo ágil -agile work. Dentro de las metodologías ágiles utilizadas para gerencia de proyectos no asociados a desarrollo de software se encuentran Scrum y eXtreme Programming.

Más información:

• Agile Manifesto @ Official Website
• Scrum @ Wikipedia

Acostumbrado a los grandes eventos, con muchas horas para relacionarse -PR y networking-, calidad cuestionable en las presentación y de poca asistencia en las conferencias de la mañana, que es lo usual en el medio de la publicidad y el mercadeo, este evento pequeño y con un grupo muy interesado en el tema fue sin lugar a dudas enriquecedor.

Mis sinceras felicitaciones a Martha Juliana Ardila, a Beatriz Caicedo y en general a todo el grupo de ACIS que estuvo detrás de la logística del evento.

Dato curioso y una válida la anotación: ¡Es notable la falta de convocatoria del capítulo del PMI de “Santafé de Bogotá” que no tuvo la más mínima presencia!

Todo cambio genera cierta incertidumbre, más aún por el desconocimiento de la dimensión y el impacto de estos sobre lo que ya conocemos. A continuación, presento un resumen general de los cambios presentados en esta cuarta edición del PMBOK.

• Estándar internamente consistente. El objetivo fundamental es homogenizar la publicación principal del PMBOK -para que parezca escrita por una única persona, aún cuando sabemos que es un gran equipo el que trabaja en el documento. El impacto es a nivel interno del PMBOK y se extiende a los documentos (estándares) antes mencionados. Este cambio se consolidó con la integración de los primeros dos capítulos de todos los documentos mencionados -y cabe anotar que aunque no tienen exactamente el mismo contenido, sí utilizan plantillas similares y estructuras consecuentes que se apoyan o complementan sin entrar en contradicciones.
• Una gran mejora al framework es que todos los procesos que lo componen tienen una estructura consecuente en el nombre: verbo-sustantivo.
• Las entradas y salidas han sido “organizadas” de modo tal que siempre aparecen en orden similar -para facilitar su recordación. Ejemplos y datos importantes han sido incluidos para ilustrar de mejor manera estos conjuntos de elementos. Es importante resaltar la utilización y ubicación del Plan de Gerencia del Proyecto (en inglés: Project Management Plan) que ha sido “convenientemente” incluído como entrada sólo en aquellos procesos donde su utilización es crítica -y necesaria- e incluso hay anotaciones que hacen referencia específica al capítulo o contenido del plan que debe ser revisado.
• Se creó la definición de Documentos del Proyecto, que hacen referencia a todos los documentos de apoyo que utilizamos los gerentes de proyecto en nuestra labor y que desde luego no hacen parte del Plan de Gerencia del Proyecto. Ejemplos: Registro de Errores o Incidencias, Registro de Cambios, Diagrama Burn-Down, entre otros.
• Es clara la diferencia y el alcance entre la Carta del Proyecto y la Declaración del Alcance del Proyecto (en inglés: Project Charter y Project Scope Statement).
• Las solicitudes de cambio (en inglés: Change Requests) consolidan lo que antes era denominado: solicitud de cambio, acción correctiva, acción preventiva y reparación de defecto. Esto es muy útil pues simplifica la terminología y fortalece el proceso al simplificarlo -para bien. Toda modificación requerida es una “solicitud de cambio” que incluye la naturaleza de la solicitud -corrección, mejora, acción preventiva.
• La ilustración que acompaña el libro es una gran mejora, y permite la consolidación del conocimiento y los términos a través de diagramas claros, imágenes pertinentes y flujos de procesos claros.

Toda la información relacionada con los cambios incluidos en el PMBOK cuarta edición pueden ser revisados en la página del PMI

Sin importar el estándar seleccionado, acá se presentan algunos consejos prácticos para tener en cuenta durante este difícil proceso:

1. Definir la terminología. La utilización de una terminología basada en un estándar parte fundamental del trabajo de adopción. Definir y revisar la terminología a usar con el grupo de trabajo y la organización reduce el riesgo de inconsistencias y al mismo tiempo simplifica la comunicación al interior de los equipos de proyecto.
2. Implementar ciclo de vida de los proyectos. Todos los estándares de manejo de proyectos incluyen un ciclo de vida de proyecto. Esta serie de pasos son necesarios para planear, ejecutar y cerrar proyectos -ciclo de inicio a fin. Definir y garantizar la utilización de los pasos del ciclo para todos los proyectos nuevos es vital para consolidar el ciclo, no obstante no debe ser una camisa de fuerza para aquellos proyectos en curso, ya que esto generará confusión y problemas para los equipos y gerentes de proyecto.
3. Seguir las directrices. Cada estándar define su grupo de directrices, y la aplicación adecuada de todas o algunas de ellas permite incrementar las posibilidades de éxito en la adopción del estándar. se debe garantizar que son estrictamente cumplidos -en función de estar alineado con el mismo estándar. Al leer y entender los estándares, también se puede determinar que directrices aplican o pueden contribuir al proceso y cuales no. Una vez se ha seleccionado el conjunto de directrices, es necesario comunicarlo a los grupos de trabajo y proveer acompañamiento durante el proceso de integración de estos principios a la cultura de la organización.
4. Ser selectivo. La adopción del estándar debe ser natural y no impositiva. No todos los procesos y procedimientos definidos en un estándar aplican para todos los tipos de organización y negocios. La selección de los procesos, procedimientos, directrices y documentos es lo que consolida la adopción y su éxito. Un estándar no es una metodología, y por lo tanto no es una camisa de fuerza.
5. Asegurar la alineación. Tras una adopción exitosa, parte del proceso ha sido completado. Sin embargo, el seguimiento riguroso de la metodología resultante tras la adopción debe ser estrictamente utilizada. La continua revisión y chequeo de los proyectos  para validar que cumplen con la terminología, el ciclo del proyecto y las directrices son el mecanismo para garantizar que la adopción del estándar es completa.

Este es un artículo traducido de la lista de correo de Method 123

Dan McCarthy escribió hace algunos dias 10 tips sobre la administración de equipos virtuales, y me tomé el atrevimiento de traducir, adaptar y comentar su artículo.