30 de diciembre de 2012

Cronograma y Alcance del Proyecto en 5 pasos



En la práctica, para proyectos grandes, se recomienda trabajar la WBS antes que las actividades del cronograma: Es sensato ordenar qué hay que hacer y qué no, en primer lugar, y después descomponer los paquetes de trabajo en actividades con su información temporal. Sin embargo, si el proyecto no es muy complejo, mi recomendación es comenzar a pensar en términos de alcance (qué haremos y qué no haremos) directamente escribiendo la lista de actividades en Project.

El siguiente video muestra en una secuencia de 5 pasos cómo es posible preparar un Gantt con Microsof Project y después importar de Project a MindManager para elaborar la gráfica WBS casi automáticamente.


23 de diciembre de 2012

Microsoft Project con varios proyectos a la vez

¿Alguna vez ha tenido que preparar un Project que sirviera para visualizar a la vez varios subproyectos, también gestionados con Project cada uno? ¿Ha tenido la tentación de copiar y pegar tareas resumen, duraciones y fechas? ¿Lo ha hecho? ¿Por qué ha malgastado así su valioso tiempo?


16 de diciembre de 2012

Mis consejos iniciales con Microsoft Project

Microsoft Project es una herramienta con una larga historia. Véase esta entrada en Wikipedia. Desde la aparición de la primera versión de Project para Windows en 1990, hasta la última en 2010, se han liberado 8 versiones más.

Se trata de una herramienta que ha mejorado mucho continuamente y sólo los expertos dominan todas sus funcionalidades. Sin embargo, hay unas funcionalidades básicas que pueden hacernos ganar mucho tiempo y claridad.

El siguiente vídeo explica las 8 funcionalidades básicas que a mí más me han ayudado.


1 de diciembre de 2012

Microsoft Project y Critical Path Method

El camino crítico (o la ruta crítica) de un proyecto se define como el camino más largo compuesto por actividades dependientes, cuya duración coincide con la duración del proyecto.

En proyectos con muchos caminos posibles, es importante vigilar las actividades críticas en primer lugar porque un retraso en una de ellas retrasa igualmente la fecha de fin del proyecto.

Por ejemplo, imaginen este sencillo diagrama de Gantt. ¿Cómo saber qué actividades conviene vigilar mejor?



  

25 de noviembre de 2012

Los procesos de PMBOK con Microsoft Project

La Gestión del Tiempo del Proyecto incluye los procesos requeridos para lograr que el proyecto o fase finalicen en la fecha señalada. La fecha de término suele ser una de las restricciones más importantes en la gestión de un proyecto. La guía PMBOK® presenta los procesos de gestión del tiempo de manera muy estructurada, con el fin de facilitar su aplicación en proyectos grandes. El Director del Proyecto documentará sus decisiones sobre qué procesos aplican cómo se abordan. Un proyecto grande que tenga fuertes restricciones de plazo, tendría que seguir los 5 procesos de planificación, antes de llegar a producir la línea base del cronograma.

A continuación se describirán los 5 procesos, de forma muy resumida, al tiempo que se revisa el uso de la herramienta Microsoft Project que correspondería a cada proceso.


Proceso 6.1 Definir las Actividades

El primero de los procesos de gestión del tiempo del proyecto es el proceso 6.1 Definir las Actividades. Básicamente, consiste en transformar los paquetes de trabajo identificados en la Estructura de Descomposición de Trabajos (EDT) en una lista de actividades. En Project, esto equivaldría a rellenar la columna “Name” y ciertos atributos de las actividades en las pestañas de “Task Information” (especiamente el campo “Notes”).


 

18 de noviembre de 2012

¿Por qué hace falta un curso de Project?

Hace unos años hice un descubrimiento: Me tomé de vacaciones la semana de Semana Santa y alguien me había prestado un libro cuyo título era algo así como “aprenda Microsoft Project paso a paso”. Me dediqué concienzudamente a estudiarlo, hice todos los ejercicios, y así acabé entendiendo cómo funcionaba esta herramienta. Cuando volví a mi trabajo pude comprobar que me hacía ganar mucho tiempo, fundamentalmente a la hora de controlar mis proyectos, pero también a la hora de hacer propuestas de servicios profesionales (que para mí no son otra cosa que la “versión cero” de un plan de proyecto).

Yo por aquel entonces dirigía un grupo de consultores, como el negocio no iba bien teníamos que responder a todas las peticiones de propuestas que pudiéramos. Había algunas semanas que teníamos que generar 2 y hasta 3 propuestas de servicios de consultoría. Mi frustración permanente tenía que ver con el tiempo que perdíamos con las herramientas ofimáticas.


11 de noviembre de 2012

Communication Patterns


I remember once when I opened my email inbox to find an email from my boss like this:
  • Jose, how do you happen to postpone the meeting with this client we are chasing for so long? Didn’t it worth making an effort?

You could not imagine how offended I felt by that short line “how do you happen to…” I hardly could keep on reading. I took this as a formidable lack of respect. He did not even say good morning! It’s really incredible how offensive certain phrases can be.


4 de noviembre de 2012

Games People Play



Should we Project Managers learn some Psychology? That wouldn’t do any harm. Following I will try to describe a psychological theory I have put into practice with good results. It allows me to explain “why people argue”. Even better, when it’s me the one involved in the argument, it allows me to take distance from emotion: I think there are situational patterns and common solutions. What happen to me has happened to much more people before. 

According Canadian psychiatrist Eric Berne, who developed the theory known as Transactional Analysis, published in 1964 within his famous book Games People Play: The Psychology of Human Relationships, when people communicate, they basically interact from three ego-states: the parent “me”, the adult “me”, and the child “me”. 

28 de octubre de 2012

“Afilar la sierra” dirigiendo proyectos

El séptimo hábito del modelo de Covey se titula: “afilar la sierra”. Las personas eficaces dedican su tiempo no solo a “cortar el árbol” (producción, huevos de oro) sino también a “afilar la sierra” (capacidad de producción, alimentar la gallina de los huevos de oro). El principio de la renovación, o lo que es lo mismo, la mejora continua, es importante para ser efectivo porque cada vez hay que saber más, hay que combatir el sedentarismo, dependemos mucho de los demás, y nuestro esquema de valores ha de ser reforzado constantemente.

El tiempo que dedicamos a la auto-renovación entra en la categoría de lo importante pero no urgente (cuadrante II, el cuadrante de la efectividad). Hay otras tareas importantes y no urgentes (grandes puntales, big rocks) que debemos resolver semana tras semana para tener una sensación de eficacia personal, pero es innegable que “estar mejor preparados” debe ser siempre uno de esos grandes puntales a tener en cuenta en nuestra planificación.


21 de octubre de 2012

El paradigma de "Equipo Completo"

 
En el post de la semana pasada “Apreciar las Diferencias”  decíamos que el Director de Proyectos depende totalmente de su equipo, y que lo único que puede hacer para sembrar el éxito en su proyecto, aparte de procurar que su equipo trabaje con las condiciones ambientales idóneas, es tratar de reclutar a las personas ideales para trabajar en equipo con el máximo desempeño en este proyecto.

Si queremos reclutar al equipo ideal, tenemos que perseguir que nuestro equipo sea completo y equilibrado. De lo contrario tendríamos que cubrir alguna carencia. Quizá no podamos forzar que el equipo se forme, depende de ellos, pero reclutar personas sí está en nuestro alcance de gestión.

Utilizando la analogía del paradigma de “Persona Completa”, el paradigma de “Equipo Completo” debería cubrir los 4 tipos de inteligencia:
  • Resultados (inteligencia física -cuerpo-): Que el equipo esté orientado a resultados. Disciplina y perseverancia para conseguir que las cosas se hagan.
  • Habilidades (inteligencia mental): Que el equipo esté orientado al conocimiento. Contar con la capacitación y habilidades necesarias para desarrollar los trabajos.
  • Colaboración (inteligencia emocional -corazón-): Que el equipo esté orientado a la colaboración entre las personas. Saber entenderse y coordinarse para trabajar en equipo.
  • Transcendencia (inteligencia espiritual):  Que el equipo esté orientado a  la transcendencia dentro de la organización. Llegar a ser un todo sinérgico capaz de auto-gestionarse y repetir la excelencia si esas personas vuelven a tener la oportunidad de trabajar juntas en otro proyecto.


14 de octubre de 2012

Mi nuevo libro

Estimados lectores,

Quería anunciarles que ya está a punto de salir mi nuevo libro "Los Hábitos de un Director de Proyectos Eficaz", que básicamente recopila de forma estructurada todos los posts que pueden ver en el blog y muchos otros que seguiré publicando. Saldrá publicado en español y en inglés.




Calculo que el libro podrá estar en las librerías en noviembre. Tengo que hablar con la editorial para estudiar si lo lanzamos también en formato e-book. Les seguiré informando.

Como también acabamos de superar la barrera de los 100 miembros, quería anunciarles que quiero regalar un ejemplar electrónico al miembro número 100. 

Ahora me dirijo al miembro número 100 "anipasa": Si quieres tener una copia de mi libro en primicia, sólo necesito tu dirección de correo electrónico y que me digas si lo quieres en español o en inglés. Mis datos de contacto están aquí.

A todos les agradezco el constante seguimiento y los comentarios que van compartiendo. Sigan haciéndolo, por favor. Me animan mucho para continuar.

Muchas gracias!!

Jose Barato.

Apreciar las Diferencias

Puede parecer muy reiterativo un mensaje que ya ha aparecido muchas veces a lo largo de este blog: El éxito de un Director de Proyectos depende casi enteramente de su equipo: Si su equipo no es eficaz, usted tampoco lo será.

Concretamente, en el post titulado “Me peleo por conseguir la gente que quiero”, decíamos que una señal de compromiso con el proyecto es luchar por adquirir al personal idóneo. También se han explicado algunos viejos paradigmas de ineficacia basados en considerar a los miembros del equipo como elementos sustituibles (ver posts “El overtime se compensa con undertime” y “Programar es un trabajo intelectual”).

Pues bien, por fin llegamos al hábito centrado propiamente en “reclutar a las personas adecuadas”, que se correspondería con el proceso del PMBOK® 9.2 Adquirir al Equipo del Proyecto.


7 de octubre de 2012

Gestionar Personas por Objetivos

 
Las personas asignadas a un proyecto no deberían gestionarse como si fueran trabajadores de una línea de montaje de una planta de producción industrial. Controlar cuántas horas trabajan, presionar para que trabajen más horas no remuneradas, ponerles mala cara cuando llegan tarde o se van antes que nosotros, imponer nuestro criterio sin darles explicaciones, decidir por ellos, “mostrar los galones” para que obedezcan ciegamente, etc. Todo esto no sirve para que trabajen mejor.

El trabajo que deben desarrollar estos “trabajadores del conocimiento” es de tipo intelectual. Presionando no conseguiremos que piensen más rápido o mejor. Los miembros del equipo que sobresalen, esos que son la razón de nuestro éxito, se motivan principalmente por su crecimiento profesional, que sólo es posible si: 1) su trabajo tiene un sentido para ellos, es decir, los objetivos a corto y medio plazo les son significativos y 2) mantienen un alto grado de autocontrol en su trabajo. Si les “robamos” gran parte de autocontrol, o si no “compran” los objetivos, entenderán que sus posibilidades de crecer se reducen, y entonces ya no hacen voluntariamente lo que queremos: Ya no nos siguen.


1 de octubre de 2012

The Denver Airport Case Study


The city of Denver, Colorado, set out in 1988 to build a new airport to replace the existing one, Stapleton Airport. Costs would be reduced, pollution and air-traffic delays would be eliminated, and growth would be assured. The new Denver International Airport (DIA) was scheduled to open on October 31, 1993. Finally it was partial opened in 1995, after 500 million dollars of cost overrun. What happened?


30 de septiembre de 2012

I have the habit of using Project Management Tools

Unfortunately, many good Project Managers, who has good experience, project management fundamentals and good professionals on their teams, encounter the problem that do not have good tools to seamlessly use their knowledge.

For them, passing the PMP® exam is like getting a driver's license and then realizing they can only walk. Sometimes, even worse, the performing organization requires them to go by bus, by imposing tools overloading them with huge bureaucracy.

Project Managers need to manage a project, not a tool. Especially, they need to manage expectations of all stakeholders, with an effective and efficient communication, providing information in the right format, at the right time, with the appropriate impact and only the necessary information. As regards their personal self-management and team management, they need to manage documentation, communication, changes, deliverables, schedule, cost, risks, issues, procurement, calendars, team members’ performance, etc.


23 de septiembre de 2012

A Regretful Personal Experience

Some years ago, the company I worked for won a very promising contract. The project consisted of developing a technological strategy plan for a Public Administration Organization. This project was considered “key” in an almost literal sense: we’d need it to be able to gain access to future projects.
High profile consultants needed were based in Madrid, but this project would be executed in the client offices in another city in Spain. Due to cost constrains, consultants would work remotely. Since this project was the most critical in this region, the Functional Manager was appointed as the Project Manager. I was leading one of the five subprojects in Madrid.

The project was closed seven months late (100% behind schedule), with a cost overrun as high as three times the original budget. Regarding personal relations, every consultant ended up burned out, not willing to deliver any high quality consulting product, nor keeping involved in future projects there, nor helping that Project Manager anyway (only if obliged).


7 de septiembre de 2012

Algo pasa con el Software



¿Qué tendrá la Ingeniería del Software que la hace tan diferente a las demás? He aquí algunas claves:


2 de septiembre de 2012

Los resultados del proyecto SRM



El proyecto terminó en fecha y coste. Un primer gran resultado del proyecto SRM fue el producto generado. Se cumplieron los requisitos de rendimiento y calidad. El producto fue certificado seis meses después de la entrega y el mantenimiento posterior fue mínimo.


26 de agosto de 2012

Delegando sin querer


Una mañana me llama Israel, esta vez no para hacerme ir, sino para darme la buena noticia de que iban a terminar en la fecha prevista.

Yo llamo al cliente y le propongo una reunión para la entrega formal. El cliente me dice que no es posible una entrega final, porque las otras partes implicadas no han empezado siquiera sus proyectos, y teme que cuando utilicen el SRM saldrán muchos defectos.

Acordamos una solución ganar/ganar: El cliente nos propone una batería de pruebas, si las superamos, podemos dar por finalizado el proyecto.

Al día siguiente me llama otra vez Israel: La batería de pruebas que propone el cliente son nada más y nada menos que ¡200 casos de prueba bloqueantes! (es decir, si falla el caso número 100, hay que reparar y volver a empezar desde el caso 1). Pienso que no van a poder cumplir la fecha prevista. Cancelo mis compromisos y decido ir a ayudarles.


19 de agosto de 2012

El hábito de SALirme del proyecto (3/3)


Coaching (selling)



Yo estaba muy identificado con lo que habíamos hecho (me sentía como el padre de la criatura) pero técnicamente, Israel me daba cien vueltas. Cuando discutíamos en el terreno técnico, siempre ganaba. Para poder avanzar, llegó un momento que decidí dejar de hablar del “cómo”, y empezar a hablar del “por qué” y del “para qué”. Así logré que nos entendiéramos mejor.
  

12 de agosto de 2012

El hábito de SALirme del proyecto (2/3)


El proyecto SRM

En el año 2000, una empresa de servicios de televisión interactiva de pago por visión (pay per view), nos adjudicó un proyecto para que sus usuarios pudieran recargar tarjetas monedero a través de los descodificadores de los televisores. Nosotros teníamos que implementar la parte central de intercambio de mensajes con las entidades financieras. Denominamos a este proyecto “Servidor de Recarga Monedero (SRM)”.


5 de agosto de 2012

El hábito de SALirme del proyecto (1/3)


Tradicionalmente había dos estilos de liderazgo bien diferenciados: El líder democrático (orientado a las personas) y el líder autoritario (orientado a los resultados). En 1972, los autores Paul Hersey y Kenneth Blanchard publicaron su libro “Management of organizational behavior: utilizing human resources”, que ya va por su décima edición, con la interesante idea de que el liderazgo es eficaz si se adapta al nivel de madurez del equipo.


29 de julio de 2012

Liderar Proyectos




¿Qué es lo único que se puede hacer para sembrar equipo, aparte de cruzar los dedos? Aplicar un liderazgo basado en principios. El paradigma de persona completa tiene una dimensión individual (cultivar cuerpo, mente, corazón y espíritu). Covey también aplica el paradigma de persona completa cuando describe el liderazgo basado en principios.


22 de julio de 2012

Liderar = Sembrar Equipo


El sexto hábito del modelo de Covey se titula: “sinergice”. La sinergia es un principio (otros principios son la responsabilidad, justicia, equidad, honestidad, integridad, dignidad, humildad, fidelidad, templanza, coraje, calidad, contribución, excelencia, paciencia, potencial, crecimiento, compasión, etc.).

El principio de la sinergia significa que el todo es más que la suma de las partes. Dos postes de madera unidos soportan más del doble de peso. Si dos plantas comparten el mismo suelo, las raíces se entremezclan y crecen con más vigor. Practicar la sinergia es el hábito de mayor jerarquía. Es la clave de las victorias púbicas.

Hay que tener mucha autoestima para saber que en este mundo interdependiente no llegamos lejos nosotros solos. No podemos silbar una sinfonía, debe tocar una orquesta. Los retos que merecen la pena se consiguen sólo trabajando en equipo.


1 de julio de 2012

Stakeholders informívoros


Los seres humanos nos distinguimos de los animales en muchos aspectos, por supuesto, pero quizá sea uno de los más relevantes nuestra necesidad de comunicarnos, sobre todo cuando hay algo que nos inquieta especialmente porque lo vemos como un peligro, o un cambio sustancial.

Necesitamos consumir información (somos “informívoros”). 

Cuando tenemos “hambre de información”, nos ponemos en lo peor, pensamos que algo va mal. Nunca faltan las propias experiencias pasadas, rumores y malentendidos, para alimentar nuestras expectativas negativas y peores temores. 


24 de junio de 2012

Gestionando las expectativas de calidad


El efecto final de satisfacción de cliente no se improvisa, hay que sembrarlo y trabajarlo continuamente. Cuando decimos que “la calidad se planifica”, esto tiene que ver con que hay que imaginar los criterios de aceptación, idear los procesos de aseguramiento y control de calidad que hacen más probable que dichos criterios de aceptación se cumplan.

Sin embargo, es muy frecuente que los clientes no nos firmen los requisitos. ¿Qué podemos hacer entonces para gestionar las expectativas del cliente?


17 de junio de 2012

Gestionando las expectativas de cambio


Los proyectos se llevan a cabo para producir cambios en las organizaciones. Al implantar el producto, servicio, o resultado final en la organización ejecutante, es muy posible que estemos cambiando la forma de trabajar de muchas personas, cuyo lógico rechazo al cambio es una seria amenaza para el buen fin del proyecto. 

Un Director de Proyectos eficaz debe visualizar la transformación que supone el proyecto para estas personas (y las sucesivas transformaciones que seguirán en fase de operación). El cambio no debería “venderse” a las personas que cambian sobre la base de los méritos del escenario futuro. La gente, cuando ha de cambiar, no abandona tan fácilmente su zona de confort. Se comportan de manera más emocional que racional (ver el post: Todo el mundo odia el cambio).

Mejor que elogiar lo bueno del escenario futuro después del proyecto, es más eficaz evidenciar los problemas de no cambiar, o lo que es lo mismo, de que el proyecto no llegue a buen término.


27 de mayo de 2012

El cliente debe estar contento con todo


Para un Director de Proyectos eficaz, la gestión de los interesados debería ser el área de gestión más importante, porque el proyecto terminará si y sólo si los interesados alcanzan o superan sus expectativas. Es decir, el proyecto termina cuando están contentos.

Si bien en todo proyecto hay una amplia gama de interesados, con quien más se necesita practicar el hábito de “gestionar las expectativas” es con el cliente, que por definición es quien paga el proyecto. 
  
Podemos extender este grupo de especial interés a los usuarios que habrán de usar el producto, servicio o resultado final.
  
En las empresas de servicios, es frecuente que el comercial que ha vendido el proyecto quiera seguir centralizando la interlocución con el cliente. Un Director de Proyectos Eficaz tratará de gestionar las expectativas del cliente por él mismo, sin intermediarios.

Si no logramos que a nuestro cliente le interese el proyecto durante su ejecución, o bien al final le sorprendemos con un resultado contrario a sus intereses, el proyecto será un rotundo fracaso.

Como decía uno de mis jefes: “En los proyectos, el cliente debe estar contento con todo, menos con el precio”. Que “el cliente esté contento con todo”, es más fácil decirlo que hacerlo. 


20 de mayo de 2012

Patrones de comunicación

Recuerdo una vez que abrí mi buzón de correo electrónico para encontrar un e-mail de mi jefe parecido a este:
  • Jose, ¿cómo se te ocurre aplazar la reunión con este cliente que llevamos tanto tiempo persiguiendo? ¿Es que no podías hacer un esfuerzo por atenderle?

No se imaginan cómo me ofendió aquella expresión tan corta “cómo se te ocurre…” Apenas si podía seguir leyendo, me pareció una tremenda falta de respeto. ¡Ni siquiera me daba los buenos días! Resulta increíble el poder ofensivo que tienen algunas frases.

13 de mayo de 2012

¿Por qué discutimos?


A continuación voy a tratar de describir una teoría cuya aplicación a mí me ha dado muy buenos resultados. Me sirve para explicar “por qué las personas discuten” y, mejor todavía, cuando discuto yo, me sirve para tomar distancia de la emoción porque me hace pensar que hay patrones y soluciones comunes, y lo que me ocurre en ese momento le pasa también a todo el mundo.

Según el psiquiatra canadiense Eric Berne, que desarrolló la teoría conocida como Análisis Transaccional, publicada en 1964 en su famoso libro “Games People Play: The Psychology of Human Relationships”, cuando hablamos con otras personas, utilizamos uno de estos tres estados del ego: yo padre, yo adulto, o yo niño.


9 de mayo de 2012

The Project Manager’s essential body parts


In his bestselling book  The Deadline, Tom DeMarco describes the most important parts of the anatomy of any Project Manager: gut, heart, soul and nose. According to Tom DeMarco, good Project Managers must develop a habit of trusting their gut, leading with the heart, building soul into the organization and last, but not least, to have a nose capable of smelling problems.



6 de mayo de 2012

Con las personas, despacio es rápido



La comunicación eficaz se fundamenta en la buena escucha, y la buena escucha tiene como base la capacidad de empatizar, para comprender al otro poniéndose en su lugar. Empatizar no significa estar de acuerdo con la otra parte, simplemente queremos ver la realidad desde su punto de vista, para comprenderle mejor.


29 de abril de 2012

Un Director de Proyectos Eficaz es buen comunicador


Todo Director de Proyectos concede mucha importancia a la comunicación. PMI nos dice que “más de un 90% del tiempo hay que dedicarlo a comunicar”. Es decir, casi todo el tiempo, un Director de Proyectos debe dedicarse a redactar e-mails, informes, memorandos y otros documentos, revisar, distribuir y almacenar dicha documentación, etc.  

Pero hay que tener en cuenta que la comunicación no es sólo por escrito: el mayor porcentaje del tiempo se invierte en llamadas, chats, videoconferencias, presentaciones, reuniones con el equipo, con el cliente, con los jefes y resto de interesados, con cada miembro del equipo para orientarle y darle feedback, por no mencionar la comunicación informal que tiene lugar en los pasillos, en el comedor, frente a la máquina del café, etc.


22 de abril de 2012

Interview to hire a Project Manager



If you are about to hire a Project Manager, you may like to know if he is familiar with project management tools, his academic background, if he is a PMP® certified since when, how many projects has he managed, his industry expertise, etc. One candidate may score high at these topics, yet I would hesitate if hiring him or not. 

Conversely, sometimes you don’t need to ask anything. Someone else comes along, and a little voice inside you sings out, “It’s her! She is the one! Grab her and put her in charge of the whole works and leave her alone”. That’s the gut speaking. Her résumé don’t say much, but she start talking… and you already know for sure. You want her to manage the project. It is a critical project, and if it goes wrong it is going to make a great loss for everybody, but in some way, you know you have made the right decision.


Procure primero comprender y después ser comprendido


El quinto hábito de Covey se titula: “Procure primero comprender y después ser comprendido”. En una comunicación efectiva, habría que utilizar las orejas el doble que la boca, pero generalmente hablamos el doble que escuchamos. Tendemos a escuchar sólo para buscar nuestra respuesta, no para comprender. Si nos cuentan un problema, tendemos a prescribir la solución que nos ha servido a nosotros, asumiendo que nuestra biografía es suficientemente representativa y válida para los demás. Le decimos al miope que se ponga nuestras gafas


15 de abril de 2012

El caso del Aeropuerto de Denver


En 1988 se decidió reemplazar el aeropuerto de Denver: El nuevo aeropuerto reduciría costes, ruido y polución, eliminaría retrasos y permitiría el crecimiento de la ciudad. La fecha estimada de apertura era el 31/10/93. Finalmente, se abrió parcialmente en marzo de 1995, después de unas pérdidas por retrasos de unos 500 millones de dólares. ¿Qué pasó?


8 de abril de 2012

Ganar/ganar o no hay trato gestionando riesgos


Los riesgos son consustanciales a cualquier proyecto. Como dice Tom DeMarco: “Si un proyecto no tiene riesgo, no lo hagas. Si sólo tienes tiempo para gestionar una cosa: gestiona riesgos”. Los proyectos que merecen la pena para la organización ejecutante, para quien los dirige, para quien los ejecuta, para quien está involucrado de alguna manera, son aquellos en los que hay algo en juego, hay mucho que ganar y también mucho que perder. En definitiva, hay mucha incertidumbre. Un Director de Proyectos sabe que en su proyecto habrá problemas, incidentes e imprevistos también positivos. Quiere tener problemas, pero no quiere crisis. El antídoto para las crisis en los proyectos es gestionar riesgos.

Lo contrario a Gestión de Riesgos (intentar descubrir qué hacer con los problemas después de que ocurren) se llama Gestión de Crisis.

Un Director de Proyectos eficaz no debería tener miedo a los riesgos, sino todo lo contrario. Hay que ver los riesgos como oportunidades, incluso cuando se trata de amenazas.


1 de abril de 2012

Ganar/ganar o no hay trato dentro del equipo



Si bien hay pocas certezas en esta profesión, una de las pocas que comparten todos los Directores de Proyectos con experiencia es que en los proyectos se producen muchos conflictos. 

Un conflicto ocurre cuando los intereses de dos o más personas son incompatibles. Los proyectos están plagados de intereses y de interesados dispares.

Por otra parte, los miembros del equipo, esos trabajadores del conocimiento responsables finales de que las actividades de realicen y los productos se construyan con buena calidad, también son muy propensos a discutir. 


25 de marzo de 2012

Ganar/ganar o no hay trato con clientes y proveedores (2/2)


No me hizo falta insistir mucho para convencer a Manuel de que lo mejor que podía hacer, cuanto antes, era ir a hablar directamente con Luis. La mejor alternativa de Manuel no era litigar. En los juicios, hasta el que gana sale perdiendo. La compensación es siempre inferior a la dedicación, durante un periodo extraordinariamente largo, de abogados y personal especializado. Eso sin tener en cuenta los costes intangibles, bastante más importantes por lo general. Como todo el mundo sabe, los litigios, como las guerras, son acuerdos de tipo perder/perder.


18 de marzo de 2012

Ganar/ganar o no hay trato con clientes y proveedores (1/2)

Una vez recibí una llamada de Manuel, un colega. Manuel es un Director de Proyectos muy sénior, con mucha experiencia. Si bien llevaba poco tiempo con nosotros, tenía un gran bagaje dirigiendo muchos proyectos. El motivo de su llamada era claro y conciso: Quería saber la mejor manera de comunicarle al cliente que dejábamos de prestarle nuestros servicios. El contrato tenía una cláusula que permitía hacerlo por incumplimiento en los pagos. Así que había tomado la decisión de hacer volver a las 3 personas desplazadas para ese cliente. 

Yo dejé lo que estaba haciendo y fui a la oficina a hablar con Manuel. Esta es, más o menos, la conversación que mantuvimos:


14 de marzo de 2012

Los tres hábitos para la victoria pública


Cuando un Director de Proyectos integra en su carácter los hábitos 1, 2 y 3, podemos decir que consigue ser eficaz en su autogestión personal. Tiene principalmente una satisfacción personal con su trabajo, que disfruta y sabe hacer. Sin embargo, esta victoria privada no es suficiente para lograr el éxito en un proyecto.


Uno puede ser muy proactivo e identificarse totalmente con los objetivos (comprometerse con el proyecto -hábito 1-), puede visualizar continuamente y con anticipación todos los detalles (planificar progresivamente -hábito 2-) y también puede llevar un control férreo para corregir desviaciones (autogestión -hábito 3-). Puede hacer todo esto, y sin embargo, fracasar como Director de Proyectos.


11 de marzo de 2012

Uso herramientas para el seguimiento

Desafortunadamente, muchos buenos Directores de Proyecto, con buena experiencia y fundamentos de gestión de proyectos, y con buenos profesionales en sus equipos, se encuentran con el problema de que no tienen buenas herramientas donde usar de forma fluida esos conocimientos.

Es como sacarse el carné de conducir y luego darse cuenta de que sólo se puede ir a pie. A veces, peor aún, la organización ejecutante le obliga a ir en autobús, imponiéndole ciertas herramientas contrarias a la buena gestión y que le sobrecargan extraordinariamente.

Un Director del Proyecto necesita gestionar un proyecto, no una herramienta. Especialmente, necesita gestionar las expectativas de todos los interesados, con una comunicación eficaz y eficiente, suministrando la información en el formato adecuado, en el momento oportuno, con el impacto apropiado y únicamente la información necesaria. Por lo que se refiere a su autogestión personal y del equipo, necesita gestionar la documentación, las comunicaciones, los cambios, los entregables, los tiempos, los costes, los riesgos, los problemas, las subcontrataciones, los calendarios, los incurridos, el desempeño de los miembros del equipo, etc.

7 de marzo de 2012

Sé decir que no

Algunas frases espontáneas cuando integramos en nuestro carácter el hábito 2.3) Sé decir que no:
  • "Esta petición debe rechazarse porque, como puede ver en la declaración del alcance que se consensuó, este punto se decidió excluir explícitamente y dejarlo para una siguiente fase". 
  • "Su petición es muy interesante, pero causaría este rechazo en estos usuarios, y además duplicaría estos costes de mantenimiento..." 
  • "Si retrasamos esta actividad, esta otra, en manos de este proveedor, entraría en el camino crítico, con lo que cualquier retraso en su entrega provocaría un retraso en la fecha de finalización".
  • "El proyecto puede terminar 2 semanas antes, a condición de que Ricardo siga en el equipo al 100% una semana más".
  • "Se ha estudiado el impacto de esta solicitud de cambio: Aparece un nuevo riesgo cuya mitigación costaría 2.000€ y provocaría 1 semana de retraso. Si se opta por contenerlo y no mitigarlo, se necesitaría una reserva de 10.000€ y se tardaría 3 semanas en ejecutar el plan de recuperación, en caso de que ocurra".


4 de marzo de 2012

Siempre tengo un plan actualizado y creíble


Algunas frases espontáneas cuando integramos en nuestro carácter el hábito 2.2) Siempre tengo un plan actualizado y creíble:
  • Estos supuestos iniciales han resultado no ser ciertos, aquí les envío la nueva planificación .
  • En los principales paquetes de trabajo y cuentas de control, la programación sigue inalterada. Se ha profundizado para detallar las actividades de bajo nivel y los hitos del próximo mes .
  • Si el proyecto se cancelara a finales del próximo mes, habría dado tiempo a producir los siguientes entregables... .
  • “Terminar antes de marzo es imposible, la fecha más probable para entregar un producto aceptable es el 31 de marzo, pero incluso esta fecha no es muy creíble (30%), hay que esperar al 15 de abril si se quiere publicar una fecha límite con el 50% de confianza, pero si se quiere probabilidad de retraso virtualmente nula, hay que publicar como fecha de fin de proyecto el 1 de junio”.


29 de febrero de 2012

Visualizo el destino y el camino

Algunas frases que surgen espontáneamente cuando integramos en nuestro carácter el hábito 2.1) Visualizo el destino y el camino

  • "Los usuarios afectados necesitarán esta formación antes de la semana 15. Los resultados serán tomados en cuenta en el resto de las actividades de gestión del cambio".
  • "En la primera iteración se tomarán todas las decisiones de arquitectura tecnológica, que se validarán mediante un prototipo. La segunda iteración entregará toda la funcionalidad del subsistema de recibos, que es el más crítico. La tercera iteración cubrirá el resto de funcionalidades".
  • "El equipo independiente de pruebas se incorporará con una carga de 5 FTEs en junio, 8 en septiembre y 10 en enero".
  • "Deberíamos negociar los derechos de explotación del producto del proyecto. Nuestra empresa podría incorporarlo en esta línea de negocio".


26 de febrero de 2012

Planificar progresivamente


En su día a día, un Director de Proyectos eficaz debe ser un especialista en visualizar su proyecto. Empezar con un fin en la mente, en el ámbito de los proyectos, significa algo muy concreto: planificar.

Antes de insistir en la importancia de una buena planificación para el éxito de cualquier proyecto (como se dice en inglés, fail to plan is plan to fail), pensemos qué ocurre cuando un Director de Proyectos no tiene el hábito de planificar. Cuando observamos que alguien gestiona un proyecto haciendo lo que le manda el cliente, reaccionando a los problemas y crisis que surgen en el día a día, ¿de verdad podemos llamar a eso gestionar un proyecto? 


22 de febrero de 2012

Ética del carácter para el Director de Proyectos


Un carácter de efectividad personal se construye con 7 hábitos, según el modelo de Covey:


La efectividad no es algo que se pueda imponer desde afuera. Uno mismo cambia porque quiere (la puerta del cambio se abre desde dentro) y hay un camino secuencial de dentro-afuera, desde la dependencia a la interdependencia:


19 de febrero de 2012

Dirección de Proyectos centrada en principios



A lo largo de la ejecución de un proyecto, el Director de Proyectos ha de tomar muchas decisiones, todos los días. Que estas decisiones sean correctas o no, dependerá, en gran medida, de lo eficaz que sea el Director de Proyectos, tanto en el plano personal como en el interpersonal. Voy a intentar explicar esto sobre un ejemplo real.