Siete tips para elaborar el Acta del Proyecto.

En la Guía de los fundamentos de la dirección de proyectos, el PMI define al Project Charter (Acta del proyecto) como “el documento que formalmente autoriza un proyecto o fase y que documenta los requerimientos iniciales para satisfacer las necesidades y expectativas de los interesados” (Project Management Institute, 2008).

Por otro lado, en el artículo “How to create Project Charter in 7 Easy Steps” (Patel) resalta la importancia del documento y sugiere siete pasos para redactarlo:

1.   Establecer en forma clara los objetivos del proyecto y su efecto en la organización. La importancia del proyecto para la compañía y sus clientes.

2.   Incluir la lista de todos los interesados y personas involucradas en el proyecto. Definir sus roles y responsabilidades.

3.   Desarrollar al acta del proyecto en grupo (con todos los interesados) y asegurar el apoyo de un patrocinador.

4.   Definir el contexto y el alcance del proyecto. Establecer quiénes serán afectados por el proyecto e incluir las expectativas de todos ellos.

5.   Documentar la forma en que se va a medir el cumplimiento de los objetivos.

6.   Describir la forma en que se analizarán los riesgos y como se planeará su mitigación. Debe incluir planes de contingencia para los riesgos posibles.

7.   Incluir en el acta del proyecto una lista de los recursos financieros, materiales y humanos.

Bibliografía

Patel, N. (s.f.). Blog de Nirav Patel. Recuperado el 08 de Marzo de 2008, de Nirav Patel’s Weblog: http://patelnirav.blogspot.com/2009/10/how-to-create-project-charter-in-7-easy.html.

Project Management Institute. (2008). Guide to the Project Management Body of Knowledge (4th ed.).

Balanced Scorecard y Administración de Proyectos

El Doctor Luis Amendola propone en su trabajo “Aplicación del BSC en el Project Management” algunas ideas que a continuación comparto.

El Balanced Scorecard es un “sistema equilibrado de medición estratégica, organizado en torno a cuatro perspectivas distintas –financiera, del cliente, de procesos internos y de aprendizaje y crecimiento”.

Es una herramienta que permite convertir la visión en estrategia determinado como se ve la organización desde el punto de vista de los interesados, que acciones se deben tomar para dar más valor y mejorar su desempeño.

El BSC busca el equilibrio armónico entre los objetivos de corto y largo plazo, las medidas financieras y las medidas no financieras, los indicadores de tendencia (leading) y los indicadores de ocurrencia (lagging), la perspectiva de desempeño externa y la perspectiva de desempeño interna.

Pero, ¿como se pueden integrar el BSC y la administración de proyectos?

Para implementar el BSC el Dr. Amendola recomienda iniciar un procesode cambio desde los niveles directivos de la organización, convirtiendo la estrategia en un conjunto de acciones medibles que a su vez se integraran en proyectos con gastos bien establecidos.

Estos proyectos alinean las actividades cotidianas de la organización con la estrategia logrando de esta forma que esta se implemente también desde los niveles operativos, no solo desde los niveles directivos.

Por último, la estrategia se puede actualizar constantemente usando la retro alimentación obtenida de la ejecución de los proyectos.

Amendola concluye afirmando que el BSC se puede usar como una herramienta para el despliegue estratégico del proyecto “ya que cada proyecto necesita establecer una dirección clara de lo que espera conseguir, precisando indicadores objetivos medibles que reflejan el desempeño del proyecto en cualquier etapa de su realización”.

Además permite visualizar la interconexión entre las cuatro perspectivas mencionadas convirtiéndose así en un insumo para la toma de decisiones del Project Manager: “puede decidir a qué proceso darle importancia, detectar cuál objetivo no se está cumpliendo y cuáles son sus consecuencias, precisar cuáles procesos están obteniendo los resultados esperados y sobre qué aspectos puede incidir para elevar el valor agregado del proyecto, así como la rentabilidad, productividad, calidad de sus productos y la satisfacción del cliente”.

Personalmente considero que el trabajo de Amendola es muy completo e invita a considerar el BSC como una herramienta mas en la evaluación y seguimiento de oficinas de proyectos.

Continúan los trabajos de la MexAPLN.

La segunda reunión de trabajo de la MexAPLN se llevó a cabo el 19 de enero en las instalaciones de IDS quiénes ahora fungieron como anfitriones.

El entusiasmo ha sido un ingrediente que ha estado presente en las dos reuniones que hemos tenido y lo mismo ha provocado que la lista de participantes sea mayor. En esta ocasión nos hemos reunido doce personas, dos de las cuales vienen de otros puntos geográficos: Morelia, Michoacán y San Francisco, California.

Gran parte de la sesión se enfocó en la parte del diseño y desarrollo de nuestros estatutos donde Masa K. Maeda aportó una primera definición que el grupo estará revisando y haciendo los comentarios que se consideren necesarios. La importancia de formalizar estos Estatutos es que a partir de que estos sean aprobados internamente, no permitirá entonces integrarnos como el capítulo mexicano en la APLN.

No deja de ser atractivo para los que hoy formamos parte de la MexAPLN, tener que revisar y discutir puntos tales como: visión, misión, valores, principios, objetivos, límites, recursos comprometidos, autorizaciones, entre otros puntos. El compromiso es que esta parte tan trascendente para el grupo, quede cubierta a más tardar en el mes de febrero. 

Asimismo, conforme avancemos en la integración de la MexAPLN como un capítulo de la APLN, podremos estar detonando otras tareas de reconocimiento y patrocinio así como asumir tareas mayores en lo que resta del 2010.

Nuestra tercera reunión se estará llevando a cabo tentativamente en la última semana de febrero y nuestros amigos de Software Guru estarán actuando como anfitriones.

Por último, mencionar a los que hemos asistido a esta reunión: Janet Gutiérrez, José de Jesús Hernández, Juan Ignacio Pineda, Sergio Durán, Ivan Rivera, Alejandro Escamilla, Licean Calderón, Anastasio Lara, Carlos Mondragón, Adriana Midence, Masa K. Maeda y quién redacta esta nota: Armando Peralta.

Implementando Project Server: lecciones aprendidas en el camino

Raymundo (Ray) Chapa ha dedicado varios años de su vida profesional a implementar la plataforma de Microsoft Project Server en varias organizaciones. Teniendo en cuenta esta experiencia lo hemos invitado a conversar a efecto de que comparta con la comunidad de Greatcomments!!! las distintas experiencias que ha enfrentado y desde luego las lecciones aprendidas que ha ido registrando en el recorrido de este camino.

¿Cuándo y cómo te inicias en la implementación de esta plataforma y cual tu formación técnica así como tus credenciales de especialización que has acumulado a través del tiempo?

Inicie con esta gran herramienta en el año 2006, en aquel tiempo laboraba en una empresa del giro de servicios consultoría tecnológica, por el cual se manejaba una gran cantidad de proyectos de desarrollo de software que a su vez era muy difícil de llevar a cabo una buena administración, se tomó la decisión de buscar herramientas que ayudaran en la administración de los proyectos y en la ejecución de los procesos de software que la empresa llevaba en cada uno de sus proyectos, en aquel entonces yo estaba a cargo del área de CM (Configuration Management ) por lo cual tenía una gran experiencia en sistemas de control de versiones, control de código etc., tuve el honor de encargarme de la tarea de investigación de herramientas de EPM, lo cual después de un tiempo de investigación  opte por implementar EPM Solutions de Microsoft  por la conectividad con herramientas de desarrollo como Team Foundation Server 2005, con esto tendría el beneficio de controlar y administrar mis proyectos y seguir dando el seguimiento al cumplimiento de los procesos de software (CMMI).

Implemente Microsoft Office Project Server 2003 en su primera fase y después de lograr un éxito en la administración de proyectos y al pasar un año decidí migrar a la nueva versión disponible en el mercado, Microsoft Office Project Server 2007 de esta forma es como me inicialice en este mundo de administración de proyectos. La empresa al ver que esta herramienta tenía un gran potencial fue cuando se decidió ofrecer los servicios de consultoría en Microsoft Office Project Server 2007.

Mi formación técnica se enfocó en tres grandes herramientas Team Foundation Server, Microsoft Office Project Server y Portfolio Server.

Mis credenciales actuales:

·         MCTS:  Microsoft Team Foundation Server, Configuration and Development

·         MCTS:  Microsoft Office Project 2007, Managing Projects

·         MCTS: Microsoft Office Project Server 2007, Managing Projects

·         MCTS: Microsoft Office Project Server 2007, Configuring

¿Cuál la importancia para las organizaciones de contar con una plataforma especializada en la administración de proyectos y con qué tipo de organizaciones te ha tocado interactuar?

La importancia de contar con una herramienta de gestión de proyectos tal como Microsoft Office Project Server 2007 en las organizaciones, es que puedan administrar y coordinar el trabajo y recursos de una forma más eficiente durante todo el ciclo de vida de los proyectos, ya sean proyectos sencillos o proyectos de mayor complejidad, reduciendo los costos de ejecución.

Un punto muy importante es la administración de los recursos, esta herramienta les permite tener a las organizaciones  control total de los recursos tanto como humanos, materiales y de costos.

Tipos de organizaciones:

·         Organizaciones en el sector tecnológico

·         Organizaciones en el sector de la construcción

·         Organizaciones en el sector industrial

·         Organizaciones de Gobierno

¿Cuáles son los mayores desafíos que una organización normalmente enfrenta al momento de implementar por vez primera una plataforma especializada como MS Project Server? ¿Podríamos decir que es indispensable que la organización haya cubierto de forma previa algunos prerrequisitos?

El mayor desafío para las organizaciones es el cambio cultural, el uso de nuevas herramientas tecnológicas en combinación  con la implementación de  nuevas metodologías de administración de proyectos, esto es el mayor desafío, existen otros como la inversión del hardware necesario y la inversión de licenciamiento del producto.

Claro es totalmente indispensable que la organización haya cubierto de forma previa ciertos prerrequisitos, tales como capacitación del uso de estas nuevas tecnologías en este caso Microsoft Office Project Professional, ya que en muchas de las organizaciones utilizan Ms Office Excel como el motor de la administración de proyectos y es difícil hacer este cambio de herramienta sin una previa capacitación, esto podría tomarse como el primer punto de rechazo y por otro lado la elaboración y capacitación de la metodología a cubrir en este nuevo mundo de administración de proyectos.

¿Cuándo si y cuándo no las organizaciones deberían implementar esta plataforma?

En realidad toda organización que maneje proyectos  o tenga planeación interna de operación debería de contar con una plataforma como Ms Office Project Server para la administración de proyectos, el factor que puede ser detonante es la inversión en estas plataformas, muchas organizaciones son pequeñas y es difícil poder invertir en Hardware y en el licenciamiento de estas plataformas.

Haciendo un lado el efecto comercial, qué deberían hacer las empresas que cuentan con distintas versiones de MS Project, previa a la versión 2010 teniendo en cuenta el impacto financiero y el impacto en la actualización de versiones que se requieren a nivel de aplicativos y base de datos? ¿Cuándo y cómo cambiar?

Para las organizaciones que siguen trabajando con la versión 2003 será necesario antes de migrar a esta nueva versión de Microsoft Project Server 2010 migrar forzosamente a la versión de MOPS 2007 y posterior a esto hacer la migración a la versión 2010, o bien tomar la decisión de iniciar desde 0 en la nueva versión 2010, para aquellas organizaciones que ya cuenta con la versión 2007 operando, la migración a la versión 2010 es transparente, ya que sigue manteniendo el esquema y estructura de base de datos, por esto en específico es la razón de no ser posible el brinco de la versión 2003 a la 2010.

Hablando un poco de esto de migraciones y las implicaciones que tiene, Microsoft Project Server 2010 funciona únicamente con Microsoft SharePoint Server 2010 en versión Enterprise y con el servidor  de base de datos de SQL Server 2008 en 64 bits, esta versión ya no funcionara más en versiones de 32 bits, por lo cual ya estamos hablando de una inversión más fuerte.  Requerimientos (Windows Server 2008 64x, SQL Server 2008 64x, Microsoft SharePoint Server 2010 Enterprise 64x) se espera que en la liberación del producto en Julio al comprar Microsoft Project Server 2010 el costo de licenciamiento de Microsoft SharePoint Server 2010 Enterprise sea mucho menor al que se considera en la compra normal de este servidor.

Al hablar de OS en 64x implica por supuesto en equipos que soporten esta tecnología y como tal exige más capacidades de memoria y procesamiento.

¿Cuándo y cómo cambiar? Cambiar de versión de plataformas implica costos como ya lo mencione anteriormente, las ventajas hoy en día es adquirir los paquetes de licenciamiento escalables de versiones por lo tanto es lo primero validar que contamos con ese tipo de licenciamiento, por otro lado la decisión de cambiar de versión no creo que exista un medidor como tal, como todo los productos tienen un ciclo de vida al igual el soporte que ofrecen los dueños de los productos, en este caso el soporte para una versión 2003 es casi nula hoy en día, para una versión 2007 es más factible contar con ayuda del dueño del producto, la decisión de cambiar puede ser ya por la salud de nuestro servidor o bien por la necesidad de cubrir ciertas características que los productos de mayor versión ya manejen.

¿Cuáles serían las buenas noticias que se desprenden con la nueva versión 2010 de MS Project Server para las empresas y para los usuarios?

Pues bueno como muchos de ustedes ya sabrán, liberaron en versión Beta Microsoft Project Server 2010, ahora de su nombre eliminaron la palabra “Office” al igual sucedió para la versión 2010 de Microsoft SharePoint Server 2010. La liberación del producto se espera sea para el mes de Julio de este año 2010 esperemos que así sea, actualmente pueden instalar la versión Beta que está disponible en el sitio oficial del producto en la siguiente liga:

http://technet.microsoft.com/es-es/evalcenter/ee410540.aspx

Hablando un poco de los cambios significativos de Microsoft Project Server 2010, ahora Microsoft retira del mercado de EPM Solutions la versión de Portfolio Server y ahora forma parte de la suite de Microsoft Project Server 2010, a lo que me refiero es que esta nueva versión de Project Server es también ahora Portfolio Server, los dos en un solo producto “Microsoft Project Server 2010”, esto quiere decir que con la licencia de Project Server 2010 está incluido Portfolio Server, incluye toda la funcionalidad que teníamos con Portfolio Server ahora también tendremos todos los elementos necesarios para saber y determinar la rentabilidad de ciertos tipos de proyectos y poder tomar decisiones a tiempo.

Esta nueva versión inicia con todo un flujo de aprobación de proyectos, podemos definir costos máximos de inversión, si contamos con los recursos necesarios, etc. y antes de iniciar con la ejecución del proyecto estos flujos nos pueden determinar si el proyecto es factible y si no simplemente no ejecutarlo, estos flujos son muy importantes para la toma de decisiones y lo mejor es que son fácil de configurar y modelarlos a nuestras necesidades, ahora con esto también podemos tener de forma visible o en una vista en que parte del flujo vamos operando, esto les encantara a las empresas que dictan flujos para cada una de las parte de los ciclos de vida del proyecto, ya que podrán crear flujos para cada fase y mientras estos no se cumplan no podrán proseguir con la operación del proyecto, ejemplo de esto si para una fase tienes determinado entregables y estos no se han  documentado el proyecto no podrá continuar, de esta forma podremos determinar en donde están nuestro deficiencias en los proyectos y tomar acciones correctivas o mejorar los procesos.

Por otra parte muy importante es que se eliminó por completo los controles ActiveX,  a las personas que les tocó sufrir con esto por tiempo excesivo de carga de información o bien errores de cargar de los ActiveX en las vistas, pues ahora ya es más ágil ya que ahora están desarrolladas las vistas en otro leguaje que permite la carga de información más rápida sin necesidad de instalar controladores en las maquinas cliente.

El interfaz ahora es más dinámica, si no conocen aun la suite de Office 2010 pues les comento es algo similar a la interfaz que tenemos con Office 2007, por lo tanto vuelve su interfaz más dinámica y de fácil uso y personalización.

Esto les va a encantar a los Project Managers, ahora desde la interfaz de la central de proyectos, podemos modificar  nuestros calendarios sin necesidad de tenerlos que abrir en Project Professional, podemos modificar, asignar recursos, establecer líneas bases, guardar y publicar todo desde la misma interfaz.

La sección muy utilizada pero no de mucho gusto por todos, la sección de Data Analysis en esta versión desaparece por completo, ahora contiene un dashboard donde podremos generar nuestros reportes con Excel Services, Reporting Services e incluso con Performance Point, ya no tendremos que estar batallando más con los controles de Web de Office ni con los famosos Active X, ni tener que instalar en la máquina de los clientes; todos es Web. En esta nueva sección ya cuenta cargado con las conexiones a los cubos y algunos reportes de Excel Services cargados para hacer más fácil su armado y entendimiento de los usuarios finales.

Ahora también en la sección de configuración de servidor cuenta con una nueva sección de flujos de trabajo, donde podemos definir todos los flujos que queramos de una forma sencilla, además a esto en la nueva versión de Visio 2010 ya podremos generar los flujos de trabajo mediante diagramas y estos los exportamos a Project Server y ya tendremos nuestros flujos de trabajo.

Lo que a muchos les dio dolor de cabeza es la separación de My Work y Timesheets, espero estos términos ya los tengan conceptualizados, no voy a explicar a detalle el porqué de esta forma de trabajo en la versión de MOPS 2007, lo que si es que ahora el ingreso de los tiempos de los usuarios lo tendrás en una sola pantalla que esto si era un dolor de cabeza, pero no se ha eliminado la forma de trabajo de la versión 2007, podemos trabajar en una sola pantalla o bien como la versión 2007 o igual deshabilitar los timesheets etc.

Conectividad con otros sistemas, como es el caso de los ERP, esta nueva versión tiene interacción directa con AX 2009, con el conector podemos trabajar con SAP. Existen otras herramientas, como herramientas de desarrollo, la conexión directa sin requerir herramientas de terceros es con Team Foundation Server 2010, esta última es muy importante para las empresas que desarrollan Software, ya que tener cada requerimiento, Bug, Issues y Riesgos asociados y controlados desde un gestor de proyectos a tareas y recursos específicos y todo su tracking,  sin perder el punto exacto de versión de código que corresponde, esto es sumamente útil.

En fin, estas son algunas de las nuevas características del producto a grandes rasgos, les aseguro que les va a encantar esta nueva versión de Microsoft Project Server 2010 y también la nueva versión de Microsoft Project Professional 2010. En esta nueva versión también podrán tener los flujos de forma visible aparte del Gantt Chart.

Planificación Gradual (Rolling Wave Planning)

El administrador es asignado a un proyecto recién autorizado y debe iniciar a la brevedad, a pesar de que el alcance total del mismo aun no ha sido definido. Esta situación es más o menos común dependiendo de la madurez de la organización y de su apego a las mejores prácticas de administración de proyectos y ocurre que aunque están claros los siguientes pasos (la primera fase del proyecto, el primer entregable), no se puede planear mucho más adelante. Para estos casos puede resultar útil una mejor práctica denominada Rolling Wave Project Planning (RWPP).

Gregory D. Githens, PMP  define el RWPP como un mecanismo iterativo para desarrollar un proyecto que es aplicable a proyectos en los que se desarrollan nuevos productos y proyectos de TI.  Rupen Sharma, PMP recalca el aspecto de la planeación iterativa similar a lo que se hace en metodologías Agiles como SCRUM. La técnica de Rolling Wave Planning se recomienda cuando no se tiene la claridad necesaria para planear en detalle todo el proyecto. Esta falta de claridad en el alcance se puede deber a requerimientos nuevos, cuando no se pueden obtener respuestas claras de parte de los interesados. La idea es realmente simple: se planea hasta donde se tiene visibilidad, se implementa y luego se vuelve a planear. Para esto se debe partir de una WBS –Work Breakdown Structure-  que considere todas las etapas y objetivos del proyecto. Se deberá entonces detallar el WBS y las actividades de la primera fase. Conforme avanza el proyecto se adquiere conocimiento. Al concluir la fase, este conocimiento se usará para detallar el WBS y las actividades solo de la fase siguiente, en un ciclo que se mantiene hasta concluir el proyecto. Esto es, se debe planear con frecuencia, pero solo el trabajo de la siguiente fase. Este mecanismo permite al equipo tener certeza sobre cómo se debe desarrollar el proyecto atendiendo también al requerimiento de los interesados de iniciar la ejecución del proyecto e ir completando el alcance del proyecto sobre la marcha. Solo se debe tener presente que cada una de las etapas del proyecto (y sus fechas de inicio y fin) deben estar claramente establecidas y reconocidas por todos los involucrados en el proyecto. A continuación enlisto las referencias mencionadas así como otros materiales de interés sobre el tema.

Gregory D. Githens, PMP. “Rolling Wave Project Planning” http://www.catalystpm.com/NP02.PDF

Rupen Sharma, PMP. “Basics of Rolling Wave Planning” http://www.brighthub.com/office/project-management/articles/48953.aspx

Johanna Rothman. “Starting With Rolling Wave Planning” http://www.ayeconference.com/starting-with-rolling-wave-planning/

Johanna Rothman. “Rolling Wave Planning” http://jrothman.com/blog/mpd/2004/05/rolling-wave-planning.html

Glen B. Alleman. “Rolling Wave Planning” http://herdingcats.typepad.com/my_weblog/2005/04/rolling_wave_pl.html

John Goodpasture, PMP. “Rolling Wave Planning” http://www.projectsmart.co.uk/rolling-wave-planning.html

John Reiling, PMP. “Rolling Wave Planning and Progressive Elaboration” http://pmcrunch.com/project_management_process/rolling-wave-planning-and-progressive-elaboration/

Jose Moro. “Rolling Wave Planning o planificacion gradual” http://www.gedpro.com/Comunidad/Blogs/tabid/69/EntryId/311/Rolling-Wave-Planning-o-planificacion-gradual.aspx

Tres razones por las cuales las empresas no alcanzan a ser ágiles

Corresponde a Mary Poppendieck, desarrollar el prólogo del libro “Becoming Agile” que durante este año 2009 que está por terminar publicaron Greg Smith y Ahmed Sidky.

Sirva lo anterior para destacar que en dicho prólogo encontramos el razonamiento de Poppendieck que apunta a que son pocas las empresas de desarrollo de software que logran convertirse en organizaciones ágiles: “Over the years I have seen a lot of software development organizations try to become agile. Some have succeeded beyond their wildest dreams and continue to improve to this day. But those are the exceptions. In a more typical scenario, agile development shows some initial success, but once the low-hanging fruit has been picked, it doesn’t seem to deliver that much sustained value over time. (Sidky xvii)“

Estas razones se pueden caracterizar en términos de:

Perspectiva limitada. El desarrollo ágil muchas veces se impulsa como un movimiento que surge desde las bases –nivel operativo- para alcanzar un mejor desarrollo del software sin involucrar a otros jugadores importantes tales como gerentes de desarrollo o a la organización del cliente. Según Poppendieck “This is a mistake, because dramatic improvements from agile development require a different mindset on the part of both development managers and the organizations for which the software is being developed. (Sidky xvii)”

Errores de aplicación. Estos errores pueden derivar de iniciativas que se enfocan en desarrollar un “unmaintainable code base” o bien en crear “an unsupportable set of expectations in the minds of development teams or customers” o bien como Mary Poppendieck comenta “sometimes the implementation is perfect for some people in the company (developers, for

instance), but it doesn’t take into account the needs of others (testers, for example)” (Sidky xvii) lo cual a todas luces es una restricción seria si es que pretendemos contar con una implementación ágil exitosa.

Subestimación del esfuerzo. Como todo enfoque o metodología novedosa, se parte de una idea equivocada al creer que la nueva medicina curará todos los males habidos y por haber. La autora nos dice: “agile development might be considered a silver bullet—a quick and easy fix

to problems that plague software development. In this case, the hard work required to

make agile successful is ignored, and when companies come to the realization that agile

is not going to be as easy as they anticipated, all too often commitment dissipates. (Sidky xvii)”

Sin lugar a dudas los tres señalamientos anteriores son temas que deben ser tomados en consideración si verdaderamente aspiramos a que nuestras empresas emprendan con éxito la implementación de enfoques basados en metodologías ágiles.

Bibliografía

Sidky, Greg  y Smith, Ahmed. Becoming Agile in an imperfect world. Greenwich: Manning, 2009.

¿Por qué fracasan los proyectos de TI? Segunda parte. Las razones del Standish Group.

Un segundo artículo titulado “Why a project fails?” de Amit Sarkar (http://www.linkedin.com/pub/amit-sarkar/8/2a2/767) refiere a un estudio de Standish Group (http://www.standishgroup.com/) cuyos resultados muestran que las diez razones más frecuentes por las que fallan los proyectos de TI son:

1. Mala planeación. Los administradores tienden a pensar en la planeación como una pérdida de tiempo con el argumento erróneo de que es mejor ocupar el tiempo actuando que planeando.

2. Objetivos y metas poco claras. Esta causa también aparece en el listado anterior (http://ivanrivera-pmp.blogspot.com/2009/11/por-que-fracasan-los-proyectos-de-ti.html#more). En este caso la causa se atribuye a que muchos proyectos de TI se elaboran en forma progresiva y se planea por oleadas.
Si al principio la toma de requerimientos es incompleta, el alcance del proyecto puede no ser claro y provocar que toda la evolución del proyecto (desde la elaboración del cronograma) esté fundada en bases erróneas. Definir claramente los requerimientos del proyecto requiere de mucho tiempo y buena comunicación.
Si los objetivos del proyecto se modifican se pueden producir cambios no controlados en el alcance del proyecto o en las características del producto final, impactando al proyecto en forma negativa.

3. Manejo inadecuado de los intereses de los stakeholders. Cuando hay interesados que no son identificados desde el principio del proyecto, es de esperarse que soliciten cambios que a su vez provoquen atrasos.
Además, cualquier cambio tardío es más costoso y difícil de integrar pudiendo incluso provocar que todo el proyecto falle.

4. Estimaciones de tiempo o recursos que son irreales. Es frecuente que los administradores cometan costosos errores cuando estiman recursos o tiempo.
Un error común se comente durante la creación de la WBS, asumiendo que la duración de una tarea es el tiempo que tarda en completarse, sin considerar que se presentarán interrupciones.
La duración de una tarea es el tiempo que tarda en completarse incluyendo las interrupciones.
Otro problema común es usar aproximaciones lineales al estimar los tiempos. Por ejemplo, integrar el doble de programadores no va a reducir la duración del proyecto a la mitad.

5. Asignación inapropiada de tareas y responsabilidades. Ocurre cuando el administrador no asigna tareas y responsabilidades en forma adecuada según las capacidades de los miembros del equipo, provocando confusión y (eventualmente) re-trabajo.

6. Falta de apoyo gerencial e involucramiento de los usuarios. Los administradores de proyectos de TI enfrentan muchas dificultades cuando controlan proyectos. Si el administrador trabaja coordinando y facilitando el avance del proyecto pero sin al apoyo de la gerencia entonces no podrá tomar decisiones propias o reforzar las decisiones del equipo.

7. No comunicar en forma adecuada y no actuar como un equipo integrado. Los proyectos fallarán si la comunicación no es adecuada.

8. Falta de una administración de riesgos apropiada. Otra potencial causa de falla es la falta de habilidad de los administradores para categorizar cuantitativa y cualitativamente los riesgos e implementar medidas correctivas.

9. No contar con el equipo humano adecuado. Los rápidos cambios tecnológicos hacen difícil predecir las capacidades que se requerirán del equipo de TI, agregando dificultades al proyecto.

10. Capacidades inadecuadas del administrador.

Algunas recomendaciones que se extraen del artículo de Amit para enfrentar estas situaciones son:

· Involucrar a administradores de proyecto con la experiencia adecuada desde la etapa de planeación.

· Identificar a los interesados desde el principio del proyecto.

· Tratar de obtener (y entender) todos los requerimientos antes de iniciar el trabajo.

· Delimitar el alcance, preparar la WBS tomando en cuenta todos los requerimientos al elaborar la línea base del proyecto.

· Establecer un control de cambios de alcance efectivo, incluyendo los cambios en la línea base, analizando el impacto de cada cambio de alcance en términos de costo, calendarios, planeación de recursos, entregables, etc.

· El plan de administración de alcance debe incluir un proceso de control de cambios y este debe seguirse para identificar su origen y minimizar los efectos.

· Cuando se está preparando el detalle del enunciado de alcance del proyecto hay que trabajar en un ambiente colaborativo con el equipo, consultando con los interesados siempre que sea posible.

· Usar técnicas adecuadas para estimar la duración de cada tarea.

· Organizar al equipo de forma que cada quien trabaje en su área de especialización.

· Identificar riesgos (pasados, presentes, potenciales), clasificarlos cuantitativa y cualitativamente e implementar acciones correctivas.

· Asignar el rol de “dueño o responsable de los riesgos” a una o dos personas deberán identificarlos, discutirlos con el equipo y sugerir e implementar soluciones.

· El administrador debe inspirar al equipo, compartir la visión y crear un ambiente que motive al equipo, por lo que se sugiere integrar al proyecto administradores que tengan capacidades de comunicación, planeación y organización adecuadas.

Finalmente, algunas notas personales.

La única sugerencia contra la mala planeación es… planificar. Tomando todo el tiempo que sea necesario, hacerlo en forma iterativa a lo largo de todo el proyecto, ajustando lo que se deba ajustar, etc. El plan de proyecto nos dice hacia dónde vamos, por lo que más vale que sea claro desde el principio.
Se debe escuchar con cuidado a la gerencia y al patrocinador del proyecto para conocer sus puntos de vista sobre el proyecto. Por otro lado, para crear soluciones que sirvan a los usuarios, estos deben estar involucrados en todo el proceso de planeación.
En otros post he destacado ya la importancia de la comunicación (aquí -http://ivanrivera-pmp.blogspot.com/2007/02/valor-que-aporta-el-pmp-las_26.html- y un poco aquí -http://ivanrivera-pmp.blogspot.com/2009/09/como-administrar-la-presion-que-ejercen_13.html-). Se debe comunicar a loa interesados en forma regular y efectiva: los hechos relevantes, los temas que puedan provocar preocupación, el progreso, los cambios y actualizaciones al plan de administración. Se deben considerar la forma en que cada uno de ellos puede afectar al proyecto.

Por último, hay que prevenir los cambios fuera de control. Si un cambio es necesario, todos deben conocer su impacto en el proyecto y estar de acuerdo con ello.

Agile Project Leadership Network en México: MexAPLN

El 8 de diciembre por la noche tuvimos nuestra primera reunión de grupo en la Cd. de México, siendo convocados previamente por el siempre entusiasta y buen amigo, Masa K. Maeda, quién radica en el área de la Bahía de San Francisco y quien con cierta regularidad viaja a México.

Se planteó como propósito inicial, alcanzar un acercamiento entre los convocados, llevar a cabo un intercambio de experiencias en la parte de proyectos y de manera particular en el despliegue de metodologías ágiles y lean así como tomar conocimiento del alcance de la APLN y de la visión y misión de lo que la MexAPLN pretende a raíz de su integración en nuestro país.

Fue una reunión interesante donde Masa K. Maeda fue detallando el alcance de la APLN y de las razones de fundar la MexAPLN: desarrollar actividades de networking, aprender y profundizar en agile-lean, promover la práctica como tal en nuestro medio con lo cual será viable alcanzar una mayor visibilidad y organizar eventos donde podamos incorporar a figuras reconocidas en la práctica.

Asimismo, el grupo tuvo la oportunidad de abordar los factores de éxito que se identifican desde ahora y sobre los cuales tendremos que trabajar en el corto plazo: estatutos que estarán rigiendo al grupo, la participación activa de sus miembros en distintas tareas que se consideren necesarias para ir sentando las bases del grupo, promoción del grupo que nos permita crecer y proyectarnos en el ámbito mexicano y latinoamericano, la obtención de patrocinios y el networking como actividad primordial.

Como toda iniciativa que recién inicia, el grupo es relativamente pequeño en cuanto a número de miembros sin embargo estamos plenamente seguros que lo podremos consolidar en poco tiempo, gracias a la fuerza de sus integrantes de inicio y por los valores que el grupo aporta.

Nuestra próxima reunión la estaremos llevando a cabo el 19 de enero en las instalaciones que uno de los miembros nos ha ofrecido. Vale comentar que también ya contamos con el ofrecimiento de otro compañero para utilizar sus instalaciones para la reunión que estaremos llevando a cabo en febrero. Como se podrá observar, hemos iniciado con gran energía, fuerza, ideas y espíritu de colaboración y camaradería que son ingredientes esenciales en este tipo de iniciativas.

Cabe señalar que ya contamos con el registro de un grupo donde nos pueden visitar (http://finance.groups.yahoo.com/group/mexapln/). Como miembros de inicio asistimos a esta reunión: Masa K. Maeda, Iván Rivera González, Martín Villalba Paredes, Alejandro Escamilla, Jesús Flores, Jennifer Vazquez, René Molina, Sergio Durán y Armando Peralta Díaz.

Por último y para aquellos que quieran tomar un mayor conocimiento de que es la APLN pueden visitar su página (http://www.apln.org/). De igual forma, pueden visitar la página de Agile Alliance (http://www.agilealliance.org/) desde donde por cierto pueden tener acceso al ya famoso “Manifesto for Agile Software Development”. A continuación una breve descripción de la APLN con base a información que hemos tomado de su sitio:

¿Qué es la APLN?

El Agile Project Leadership Network es una organización sin fines de lucro que se enfoca en lograr que sus miembros sean “great project leaders” teniendo en cuenta: Valores, Equipos, Contexto, Clientes, Individuos e Incertidumbre. Estos aspectos el APLN los detalla en su “Declaration of Interdependence” que fue redactada por sus miembros fundadores en un contexto donde reinan los proyectos en un mundo caótico.

El 2004 es el año de su fundación por un grupo que tiene en común, ser un grupo de personas activas que escriben, practican y evangelizan el movimiento hacia un enfoque flexible, rápido, orientado al cliente para liderar proyectos de muchos tipos, trabajando de la mano con la “Agile Alliance” dentro de la comunidad del software, considerando también personas y compañías fuera del software y de las TI para ayudarlos a que sean mejores líderes.

El propósito, visión y misión que el APLN definió desde un inicio se resume en: conectando, desarrollando y soportando grandes líderes de proyectos. En una revisión reciente, se define como misión de corto plazo:

· Que la red, llegue a ser operacionalmente adecuada

· Dar soporte a los capítulos locales

· Conducir sesiones cumbres de liderazgo

· Comunicarse regularmente con los miembros

· Desarrollar una visión y misión de largo plazo.

El significado de ser un Administrador de Proyectos experto en negocios.

Transformation Time. Hablando de nuevas competencias, Gary R. Heerkens, señala que los Administradores de Proyectos que sean capaces de entender el mundo de los proyectos y el mundo de los negocios, seguramente serán altamente apreciados por parte de las empresas. En este mismo sentido, otro especialista en la Administración de Proyectos y viejo conocido en este campo –Harold Kerzner- señala sobre el particular que “a world full of business-savvy project managers represents the future of project management.” (Heerkens 23).

¿Cuál entonces el significado de ser un Administrador de Proyectos experto en negocios?

En una primera instancia el significado se circunscribe a que el Administrador de Proyectos entiende cómo y por qué aplicar la perspectiva de negocios en cada decisión que efectúa. Al hablar de la perspectiva de negocios señala: “It describes a project manager who exploits every opportunity to optimize a combination of positive financial and strategic outcomes throughout the entire project investment life cycle—both before and after the classic project execution life cycle we typically focus on. “ (Heerkens).

Para tal efecto, el Administrador de Proyectos debe al menos poseer: Conocimiento de Negocios: entendimiento de que principios y conceptos de negocios tienen relevancia para el proyecto y para la práctica de administración de proyectos. Se menciona por ejemplo que el Administrador de Proyectos debe tener conocimiento de los conceptos financieros y cómo aplican en la justificación financiera de los proyectos; Competencias de Negocios: el Administrador de Proyectos debe ser capaz de conducir la preparación y documentación de casos de negocios y; Visión de Negocios: significa saber cuándo y cómo aplicar el conocimiento y competencias de negocios dado una situación particular en un proyecto. En este sentido, el Administrador de Proyectos debe saber que si un riesgo aflora debe ser capaz de basar su respuesta en un rango amplio de factores incluyendo impactos económicos y financieros, costos versus beneficios, optimización entre otros.

¿Por qué Ud. querría llegar a ser un Administrador de Proyectos experto en negocios?

Según Heerkens los Administradores de Proyectos muchas veces son vistos y tratados como meros “task managers”. En este sentido, una forma de superar lo anterior es agregando conocimiento de negocios, competencias y visión de negocios, lo cual permitirá alcanzar satisfacción personal y profesional para seguir avanzando en este campo. Por fortuna algunas empresas han empezado a reconocer el valor de apalancarse con administradores expertos en negocios dando como resultado de que sean invitados a participar en una variedad de funciones de alto nivel tales como planeación estratégica, selección y evaluación de proyectos, análisis financiero de proyectos y administración de portafolios.

La reflexión final sería en el sentido de que la administración de proyectos se fundamenta en buenas prácticas que se expresan en metodologías que distintas agrupaciones abanderan, llámese PMI, IPMA, APM por mencionar algunas. De igual forma, el vasto campo de la formulación y evaluación de proyectos se fundamenta en buenas prácticas que distintas entidades tienen bien definidas. Hoy sin lugar a dudas, el Administrador de Proyectos debe ser capaz de transitar en cada uno de estos campos a efecto de ser profesionalmente más completos y que se exprese en un mayor aporte a favor de las organizaciones donde se encuentren participando.

Bibliografía:

Heerkens, Gary R. «Transformation Time.» PM Network (December, 2009): 23.

¿Por qué fracasan los proyectos de TI? Primera parte.

Recientemente Computer Weekly publicó un artículo de Tony Collins llamado: Las 5 causas por las que fracasan los proyectos de IT, desde el punto de vista del asegurador.

Tony menciona una mesa de trabajo organizada en Londres por la publicación y una empresa aseguradora el pasado 24 de noviembre, en la que se discutieron las 5 causas de fracaso en proyectos de TI según los registros de la aseguradora Hiscox, especializada en reclamos por proyectos de TI fallidos.

Al final del resumen me he permitido agregar algunas notas en base a mi propia experiencia.

Los expertos concluyeron que las 5 causas más frecuentes de fracaso son:

1. Empezar a trabajar muy pronto. Iniciar el proyecto respondiendo a presiones y sin tomar todas las previsiones necesarias puede provocar problemas que extiendan la finalización del proyecto.

2. Un contrato ambiguo puede provocar problemas si no define adecuadamente el objetivo del proyecto, así como los roles y responsabilidades de los interesados.

3. No establecer en forma adecuada el alcance preliminar del proyecto. Frecuentemente las partes acuerdan iniciar el proyecto aun sin tener claro cuál es el producto final que se espera del proyecto, lo que puede provocar que no se determine adecuadamente su complejidad y no se asignen los recursos adecuados.

4. Administración inadecuada del proyecto y del contrato. El no dar seguimiento puntual al contrato durante la ejecución del proyecto (ignorar las clausulas del contrato) provoca que los reclamos sean difíciles de resolver. También se dificulta aplicar los procesos de control de cambios. Además, acordar el costo y tiempo de re trabajo en forma satisfactoria para las partes resultará más complicado.

5. No involucrar a la gente adecuada en el momento adecuado. Es usual que las partes no acerquen a los usuarios finales con el equipo de desarrollo desde las etapas iniciales del proyecto. También ocurre que las negociaciones las realicen el equipo gerencial del cliente y el equipo de ventas del proveedor, provocando que el cliente no solicite con precisión lo que requiere y que el proveedor ofrezca de más o confunda lo que el cliente solicita. Para el momento que se involucra al equipo adecuado ya se ha gastado grandes cantidades de recursos económicos y tiempo.

Es muy interesante observar que los problemas mencionados no son exclusivos de un país o región, sino que parecieran ser globales.

El escenario descrito de arranque rápido es frecuente, sobre todo en situaciones de crisis económica como la presente, ya que los vendedores y la gerencia del proveedor de servicios buscarán que se empiece a cobrar al cliente a la brevedad, sin haber completado las definiciones que conforman el enunciado de alcance preliminar.

Y si el cliente no puede definir con claridad lo que espera del proyecto, si no es posible expresar claramente en qué condiciones el proyecto se considera concluido, el proyecto tendrá pocas oportunidades de terminar en forma exitosa.

Por otro lado, parece obvio que el contrato debe ser totalmente claro y específico, sin embargo reiteradamente ocurre que en etapas avanzadas del proyecto se descubre que hay elementos (fechas, entregables) que no fueron claramente definidos o que hay frases en el contrato que se prestan a interpretación provocando diferencias en el equipo de trabajo. Una opción para resolver estas dificultades es aprovechar el enunciado de alcance del proyecto para aclarar todas las indefiniciones del contrato. Puede resultar oportuno involucrar al administrador (y/o a los expertos) desde la negociación del mismo.

Finalmente, es recomendable acordar con el cliente y documentar los procesos para asignación de recursos en general, particularmente la administración de los recursos humanos, la administración de contratos, el manejo de expectativas de los interesados y un apropiado control de cambios.