Software Production Management

Last week I was participating of the “Jornada de Gerencia de Proyectos de TI” – IT project management conference. It was great. Probably in other countries it’s usual to have great congresses or events related to PM, but here in Colombia, even the PMI Colombian Chapter sucks -even the name is out of date. It is not about find great PMs here in Colombia, you can find PM Gurus as weel, but they fail on their limited sense of community, and it’s inability to set a decent conference or even as a non-profitable group.

ACIS, the Colombian Association of Systems Engineers -and other professionals around informatics- have been leading this conference for the last seven years. It is not the most popular event ever, but it is great. It was my first, hope not the last. I met a lot of PMs who work for big IT companies like IBM, HP and Dell. I listen experienced PMs about PM tactics and techniques, tips and how to deal with people – most of PMs and PM methodologies do not take care about people because it is competence of the PM to handle people to keep the project on its way. But, is it true? Should be the PM who handles all the “human” side of the project? Probably it is, because almost all the times, PMs are the bridge between the senior management (and their necessity of results), and the team (and their personal needs).

The bonus of this event was the unexpected visit and presentation of Tony Johnson, the CEO of Crosswind - He talked about Program Management, its difference with Project Management, but also, he talked about Agile and how PgM works Agile. I was shocked, to hear a guy who works helping people to get its PMI Certifications talking about Agile. Wow! The presentation took no more than 45 minutes, and I was amazed about Tony’s ability to link PMI and Agile -while most Agilist seems to feel offended with the PPM framework of the PMI.

BTW, I did my part too, doing a short presentation about how to choose the right PM software tool for your company/team/project.

Congrats to Martha Ardila, Beatriz Caicedo and the whole team behind the event. It was great.

David Pellis escribió en el editorial del PM WORLD TODAY de junio algo muy interesante sobre el auge de la gerencia de proyectos en el sector de tecnologías de información y comunicaciones. Dicho artículo argumenta una creciente demanda en la profesión de gerencia de proyectos, asociada inequívocamente al crecimiento de la inversión en dicho sector.

El Project Management Institute ha sido abiertamente reconocido por la mayoría de compañías del sector y desde luego su certificación profesional (PMP). En la última década el número de profesionales certificados ha crecido alrededor de un 550%, y se estima que un 80% de esos nuevos miembros estén vinculados directamente con proyectos de TI.

El artículo presenta 7 razones para dicho comportamiento de la industria, los enuncio y comento a continuación:

1. Inversión masiva en TI a nivel mundial. De USD$ 2 billones en 1999 a cerca de USD$3.3 billones en 2007 -nota: billones como millones de millones. Es de anotar que el crecimiento esperado para el primer trimestre del 2008 es superior al 5% según algunas fuentes y que este periodo tambien incluye un decrecimiento asociado al “dot-com bubble”. Según el WITSA -publicación Digital Planet 2008, de mayo de 2008- la inversión estimada para 2008 será de USD$ 3.7 billones.
2. La naturaleza orientada a proyectos de las TI. Esta industria esta naturalemente asociada a los proyectos, a todo nivel: desarrollo de nuevos productos o servicios, implementaciones de SW, cambios o renovaciones de HW, migraciones, etc.
3. El fracaso de muchos proyectos de TI. El riesgo de los proyectos de TI se considera superior y segun los estudios realizados, es definitivamente un desastre el desempeño general de la industria. De ahí, supongo yo, el éxito de muchos modelos de offshoring -The Chaos Report (1995), The OASI G Study (1995), The KPMG Canada Survey (1997), The Conference Board Survey (2001) y el The Robbins-Gioia Survey (2001)
4. La creciente complejidad de los programas y proyectos de TI. Creo que este punto no requiere mayor explicación, sin embargo una frase podría resumir esta situación: ante una mayor demanda tecnológicas, la especialización de las necesidades y sus soluciones, y la madurez de un mercado sólo podemos esperar un incremento exponencial en la complejidad de los proyectos -sólo por mencionar algunas de las variables.
5. La evolución acelerada de las tecnologías. Lo que hace unos meses era nuevo, hoy no lo es, lo que hace un año era innovación, hoy es un estandar. Creo es un círculo vicioso, el crecimiento de la demanda y evolución y renovación de la oferta han mantenido el crecimiento del sector, que se ve reflejado en los valores presentados al principio.
6. La era de la información – la Tercera Ola ha llegado. Esta explicación requeriría literalmente copiar el artículo original, pero les recomiendo leer un poco sobre Alvin Toffler el autor del libro La Tercera Ola (1979)
7. Las TI son transversales a toda industria, organización, programa o proyecto. Más que esto diria que las TI prestan los servicios públicos de nuestra era y son el agua y la electricidad de nuestro siglo. Las TI estan implicitas en casi todo nuestro actuar diario, más aún en nuestro trabajo dentro de un mundo globalizado.

Gracias a todos los que me acompañaron en la presentación sobre Gerencia de Proyectos con Herramientas de Software Abierto, que dí hoy (sábado 28 de junio) en Campus Party Colombia. Tengo que admitir que tenía algún temor ya que el tema podría considerarse como un verdadero ladrillo. Sin embargo la acogida entre los asistentes y la participación con preguntas fue insuperable.

Gracias especialmente a Iván Sosa, quien me contactó con los organizadores y me ayudó a obtener un espacio para mi charla. Gracias a César Trujillo (jefecito), por apoyarme y colaborarme con los últimos detalles de la presentación. Gracias a mi familia -a mi esposa sobre todo- quién no me vió acostarme los últimos 3 días.

Pueden descargar la presentación usando el enlace disponible en la barra y bajo este artículo, o verla a través de Slide Share.

  Gerencia de Proyectos y herramientas de Software Libre (756.5 KiB, 835 hits)

De acuerdo con una encuesta realizada a 100 gerentes de IT en el Reino Unido las razones principales por las que los proyectos Web fracasan son:

• Demasiados cambios en los requerimientos
• Demasiados stakeholders para complacer
• Presupuesto y/o tiempo insuficiente.

Y agrega que si las compañías están predispuestas a aceptar fallas en el proceso de desarrollo de los proyectos pequeños, es mas probable que estas no definan adecuadamente los requerimientos y no eliminen la ambigüedad de los proyectos.

Algunos indicadores de la encuesta:

• El 24% de los proyectos no está dentro del presupuesto y el 5% no pude incluso determinar el costo total.
• El 21% no satisface los requerimientos esperados por los stakeholders.
• El 31% de los proyectos no se entrego dentro del tiempo acordado.
• Las causas principales asociadas a las fallas
  • Demasiados cambios en los requerimientos (55%)
  • Demasiados stakeholders a complacer (48%)
  • Presupuesto y/o tiempo insuficientes (31%)

Seria interesante incluir algunos factores de nuestra región para determinar si nuestra escala es diferente -acá en Latino américa.

El artículo sobre el cual basé este artículo fue publicado en PMFORUM

Este artículo es una traducción comentada de “Leading a Successful PMO: 10 Real-World Strategies” de Michael Wood, presentado el 17 de Marzo de 2008.

Gerenciar y administrar un portafolio de proyectos puede convertirse en un verdadero acto de malabarismo si no se es cuidadoso. Imagine la presión de tener 10, 30, 50 o más proyectos en curso, algunos de ellos activos, otros en la mitad de la implementación con un atraso siempre creciente. El secreto para liderar exitosamente una PMO (Oficina de Gerencia de Proyectos) es precisamente evitar concentrar la atención en los proyectos simultáneamente olvidando la PMO.

Antes de que las PMOs emergieran, la mayoría de las organizaciones veían al CIO (Chief Information Officer) como el administrador/gerente del portafolio de proyectos de IT. En la medida en que los líderes corporativos maduraban entendieron que eran pocos los proyectos de IT, pero sí muchos los que incrementaban la dinámica e innovación de la compañía, todos estos con una gran variedad de stakeholders -y no sólo a nivel interno, como suele ocurrir de IT. En ese momento, la PMO fue concebida.

Liderar exitosamente una PMO requiere una mezcla única de juicio prudente y delicadeza que es difícil de encontrar entre la multitud de CIO y CFO -sera por la multitud, la delicadeza o el juicio prudente?. Al mismo tiempo que mantiene una perspectiva completa del negocio y la compañía, y una sensibilidad inequívoca de las necesidades de las unidades de negocio locales y geográficamente dispersas. Todo esto puede abrumar y agotar si la mezcla no es debidamente balanceada.

¿Alguno sabe por qué muchas de las PMOs son disfuncionales o han asimilado las complejidades burocráticas? ¿Qué podemos hacer para transformar la PMO en un ente simplificado, orientado al servicio, facilitador, y que sea respetado por la dirección/gerencia, los stakeholders y IT?

Para empezar, debemos asumir lo siguiente como cierto en la mayoría de las organizaciones:

• Tienen recursos y capital limitado y pueden participar un número en un cierto número de proyectos en un momento dado -y quien no tiene recursos limitados? Y en caso que los tuviera, hay formas de analizar el costo de oportunidad para cada proyecto, ¿o me equivoco?
• No tienen personal que se pueda dedica exclusivamente a los proyectos, entorpeciendo y complicando la operación del día-a-día que demandan las actividades de los proyectos en curso.
• Tienden a perturbar los proyectos en curso cuando la reducción de costos se vuelve una prioridad -esto es muy común incluso en las organizaciones proyectizadas, cuando todos sabemos que los proyectos son independientes entre sí y por lo tanto es una política que causa más daño que alivio.
• Tienen gerentes de proyecto que en realidad son administradores de un proyecto pendientes del avance y generando reportes de estado -esto es muy común en casi todo el mundo, los gerentes de proyecto por defecto, no están asociados a la venta o negociación del producto o servicio y por lo tanto su capacidad de decisión sobre los recursos y el capital es limitado.
• Generan estimados demasiado optimistas en términos de tiempo de entrega, presupuesto y esfuerzo.

Con estos puntos en mente, considere las siguientes estrategias y tácticas para desarrollar una PMO efectiva y exitosa.

1. Proveer soporte administrativo a los gerentes de proyecto. Tomar esta carga pesada de la gerencia del proyecto le permitirá a los PMs liderar de manera adecuada y efectiva el equipo del proyecto, resolver problemas, y sobreponerse a los obstáculos del camino. Asumir la función administrativa de los proyectos por parte de la PMO hace posible estandarizar de procesos y procedimientos de más fácilmente.
2. Justificar el presupuesto, el cronograma y el esfuerzo de los proyectos con base en los “peores escenarios” -No puedo estar más en desacuerdo con este numeral, estimar y planear puede ser complicado y seguramente muy doloroso (costoso) al comienzo, pero no por ello la solución es estimar el peor caso.
3. Desplegar técnicas estandarizadas y herramientas formales para estimar, reportar y evaluar. Utilizar un enfoque pragmático para resolver los problemas de estimación, planeación y reporte puede conducir a resultados acelerados y replicables. Adicionalmente, tener un enfoque consistente y previsible incrementa la credibilidad de la PMO.
4. Racionalizar el papeleo. La mayoría de las PMO son intensivas en papeleo. Muchos documentos que agregan poco valor pueden ser unificados. La estrategia de unificación y/o consolidación de documentos no sólo reducirá el esfuerzo, sino también la persecución asociada a la firma oficial de los mismos.
5. Responsabilizar a los dueños del proyecto por el éxito del mismo. En la mayoría de los casos los gerentes de proyecto escapan de su responsabilidad al delegarla en el gerente/director técnico. Es bueno considerar asociarlos a ambos como responsables e incluso vincular sus incentivos -bonos-. Entre más estrecho sea este vínculo entre los dos, menos problemas políticos sucederán.
6. Transformar los PM en gerentes de ejecución. Los PM excepcionales son expertos en desplegar tácticas y logística ganadoras. Estos PM van adelante de su equipo resolviendo los obstáculos que pudieran distraer al equipo o afectar negativamente el avance. Entre tanto, mantienen a su equipo productivo y enfocado mientras garantizan que el proyecto es realizado tan pronto como es cuidadosamente posible. Esta aproximación es, desde luego muy diferente al modelo de sentarse y quejarse y ubica al PM en el centro del campo de batalla.
7. Desarrollar un repositorio de plantillas, listas de chequeo y recursos de expertos. Entre más herramientas pueda proveerle a los PM mejor. Hay grupos de tareas que pueden ser estandarizadas a lo largo de los proyectos. Muchas de tareas pueden ser consolidadas en sola con un soporte en una lista de chequeo -esto es especialmente cierto cuando las tareas son realizadas por una sola persona de forma lineal y toman menos de ocho horas. Tener una base de datos de expertos en diferentes áreas  puede reducir el tiempo de investigación y ayudar a los PMs durante el proceso de planeación.
8. Adoptar la política de “una vez aprobado, nunca se detiene” en los proyectos aprobados. Tal vez la táctica más compleja de ejecutar es obtener el verdadero compromiso de la gerencia para permitir que el proyecto se complete una vez ha iniciado. Muy a menudo las compañías inician y detienen los proyectos con base en eventos que poco tienen que ver con la viabilidad del mismo o los requerimientos de la compañía sobre los flujos de efectivo. Este síndrome de detener e iniciar los proyectos se presenta cuando las iniciativas de reducción de costos son implementadas o la “tiranía de lo urgente” canibaliza recursos asignados. Se puede pensar que un proyecto aprobado tiene un compendio completo de casos de uso con un ROI superior, y que detenerlo sólo debe ocurrir bajo condiciones específicas y muy contundentes.
9. Limitar el número de tareas que puede hacer una persona activa en un momento dado. La mayoría de las personas no es consciente que cada cambio de actividad durante el día representa una reducción valiosa de su productividad; típicamente de 10 a 15 minutos. Por lo tanto, si una persona tiene una lista de cosas por hacer de seis elementos, probablemente pierda entre hora y una hora y cuarto de productividad. Muchas de estas personas sobreponen este déficit al trabajar 10 horas diarias y/o 60 horas a la semana, y al final de la semana se sienten agotados, mal pagos, sobrecargados de trabajo. Un buen PM monitorea la forma como el equipo planea y administra su tiempo, ayudándolos a ser más productivos con menos esfuerzo.
10. Desplegar una metodología pragmática para evaluar, aprobar y priorizar proyectos. La última cosa que una PMO necesita es tener personas que crean que los proyectos son aprobados subjetivamente. Cuando esto pasa, los PMs tienden a eludir que los canales formales para lograr que los proyectos sean aprobados, resultando en un incremento

Liderar una PMO puede ser una experiencia intimidante incluso en los mejores momentos. Al seguir las estrategias y tácticas antes mencionadas, quizá  la PMO y la experiencia de gerenciar proyectos esten tan libres de molestias como sea posible.