Put First Things First

The third habit of highly effective people, according to Covey is “put first things first”. The first habit says “you are the programmer”, the second says “you write the program”, the third says “you run the program”. The second habit addresses first creation, the mental creation, using imagination and conscience. The third habit addresses physical creation, using independent will. This is the habit of getting things done.

Effective people are used to getting what they mean. They usually apply discipline, pushing with big drive and effort. These people do the talk. They don’t necessarily like doing what they do, but their purpose is stronger than their disliking. When we say a person outstands at effectiveness, this doesn’t mean they do every task, or than they do much more tasks than the rest —don’t confuse efficiency with effectiveness. These people have developed the habit of getting done the things they consider important overall, but not just sometimes, but regularly.

According to Covey, effective people usually work on not urgent but important tasks —see quadrant II of figure next page. Any task could be categorized as: urgent and important (quadrant I); not urgent but important (quadrant II); urgent but not important (quadrant III) and not urgent and not important (quadrant IV). Tasks of quadrant I have to be done right now, they are needed. If you stay too much on quadrant I you get stressed and get the feeling of being reactive. Task of quadrant III should be delegated. If you work too much on quadrant III you get disappointed —these tasks maybe are important to others, not for you. Quadrant IV tasks should be avoided because they waste our precious time. You can get a simple performance indicator of your effectiveness just measuring how long and how many tasks you close on quadrant II.

How can you move your balance to quadrant II? You need to anticipate, to plan your time. You are familiar with to-do-list, aren’t you? You enumerate things ahead and you cross tasks out as you close them. When you get rid of the last item of the day gives you a feeling of achievement and personal satisfaction. This is our daily image of effective self-management.

Ponga primero lo primero

El tercer hábito de Covey se titula: "Ponga primero lo primero". El primer hábito dice "tú eres el programador", el segundo dice "escribe el programa", el tercer hábito dice "ejecuta el programa". El segundo hábito se ocupa de la primera creación, la creación mental, utilizando la imaginación y la conciencia moral. El tercer hábito se refiere a la creación física, utilizando el atributo humano de la voluntad independiente. Este es el hábito de hacer que las cosas se hagan (Getting Things Done, en inglés).

Las personas eficaces consiguen generalmente lo que se proponen, casi siempre con disciplina, empleando su máximo empeño y esfuerzo. Estas personas hacen lo que dicen (en inglés esto se dice: do the talk). No les tiene por qué gustar todo lo que hacen, pero es más fuerte su propósito que su disgusto. Cuando vemos que una persona destaca por su eficacia, esto no significa que termine todas las tareas, o que haga muchas más tareas que el resto (no confundir eficiencia con eficacia). Estas personas han desarrollado el hábito de conseguir hacer las cosas que ellas consideran verdaderamente importantes, y esto lo consiguen no puntualmente, sino de forma continuada.

Según Covey, las personas eficaces trabajan habitualmente en actividades importantes pero no urgentes (el cuadrante II). Cualquier actividad la podemos categorizar como urgente e importante (cuadrante I), no urgente e importante (cuadrante II), urgente y no importante (cuadrante III) y no urgente y no importante (cuadrante IV). Las tareas del cuadrante I no queda más remedio que hacerlas ya, son necesarias. Dedicar demasiado tiempo al cuadrante I resulta estresante y nos da la sensación de no ser proactivos, sino reactivos. Las tareas del cuadrante III se deberían delegar, trabajar en ellas nos provoca decepción. Quizá son tareas importantes, pero para algún otro, no para nosotros. Las del cuadrante IV deberían evitarse porque suponen desperdiciar o malgastar nuestro valioso tiempo. Un indicador de lo eficaces que somos es el tiempo empleado y el número de tareas que resolvemos en el cuadrante II.  

¿Cómo conseguimos orientar nuestra actividad diaria hacia el cuadrante II? La respuesta es la anticipación, la planificación del tiempo. Todos conocemos las ventajas de utilizar una sencilla lista de tareas pendientes (to-do-list). Enumeramos las tareas pendientes que tenemos por delante y las vamos tachando a medida que las vamos terminando. Tachar el último elemento de nuestra lista de tareas pendientes en el día nos produce una sensación de logro y satisfacción personal. Es nuestra imagen cotidiana de autogestión eficaz.

El Director de Proyectos Ágil

Imagine este caso: Usted es Director de Proyectos. Cuenta con mucha experiencia dirigiendo proyectos y siente verdadera vocación por esta actividad, que considera su profesión. Ya hace más de diez años que se certificó PMP®. Usted ha tenido continuas muestras de reconocimiento en sus proyectos, dentro y fuera de su empresa. Incluso ha impartido algún curso sobre fundamentos de gestión de proyectos, sobre gestión de riesgos, sobre la herramienta Microsoft® Project©, etc. También ha participado como voluntario en algún proyecto de PMI®, y le han invitado como ponente en un par de congresos. Todo parece indicarle que es un buen profesional, muy respetado. Cuando usted habla de algo relacionado con la gestión de proyectos, la gente le escucha con atención. Muchos colegas valoran su opinión experta.

Ahora acaba de cerrar su último proyecto y no está contento. Se trataba de un proyecto de consultoría para una gran empresa. El objetivo principal era posicionarse tecnológicamente por delante de la competencia. Los representantes del cliente tenían claro que no debían seguir igual, que debían cambiar, pero no sabían qué ni cómo. Asignaron un comité de expertos internos a la empresa, pero como no avanzaban se decidió contratar una empresa externa. Su empresa ganó el concurso gracias al enfoque orientado a la flexibilidad, adaptación y colaboración con el personal por parte del cliente y también gracias que los currículos de los miembros del equipo destacaban su experiencia en métodos ágiles.

En este proyecto, usted fue consciente desde el principio de que no iba a ser fácil elaborar un documento de requisitos completo, era improbable que el cliente lo aceptase formalmente. Tampoco podía comenzar trabajando una EDT, como es su costumbre. ¿Cómo evitar entonces la corrupción del alcance? La única información clara acerca del cronograma es que había ciertos hitos y el proyecto duraba nueve meses. Lo único claro sobre los costes era el número de horas contratado por perfil. Con tanta indeterminación, ¿cómo elaborar el plan para la dirección del proyecto? El cliente quería mantener reuniones de seguimiento bisemanales. ¿Cómo justificar los avances? Sus jefes le decían que no se preocupase porque los consultores de su equipo tenían mucha experiencia en proyectos parecidos, que confiara en que harían un buen trabajo.

Sin embargo, usted se preguntaba: Y entonces yo, ¿para qué estoy aquí?

Trabajando “a matacaballo”

El mantra empresarial “hay que darse prisa” nos dice que hagamos todo tan rápido como sea posible. De acuerdo, pero ¿cuál es nuestra velocidad máxima posible? ¿Cuánta prisa puede darse usted para hacer una determinada tarea? Usted se imagina a sí mismo trabajando furiosamente, cumpliendo escrupulosamente los plazos, sin tomarse un respiro. Va al límite, su pedal mental pisado a fondo. Es lo más rápido que un trabajador del conocimiento puede ir. Si estuviéramos hablando de progreso físico en lugar de progreso intelectual, este ritmo podría denominarse “ir a matacaballo”. 

El mantra empresarial “hay que darse prisa” nos exige hacer el trabajo intelectual “a matacaballo”.

¿En qué consiste“ir a matacaballo”? A esta velocidad, usted lo hace todo atropelladamente, con mucha prisa y sin poner cuidado (si lo hiciera, podría ir más rápido). Su velocidad le pone al borde del desastre. Un pequeño traspiés y todo se pierde. ¿Tiene esto algo que ver con gestión de riesgos?

Respuesta al Riesgo marca ACME

Los riesgos son consustanciales a cualquier proyecto. El proyecto más valioso para la organización ejecutante, para quien lo dirige, para quien lo ejecuta, para quien está involucrado de alguna manera, suele ser también el más incierto: hay mucho más en juego, mucho que ganar pero también mucho que perder. No obstante, en estos tiempos ya no vamos a ganar cuota de mercado o adelantar a la competencia sin arriesgarnos. Los proyectos que arriesgan poco, deberían ceder recursos a los que arriesgan mucho. Como dice Tom DeMarco: “Si un proyecto no tiene riesgos, no lo hagas”. 

Para el Director de Proyectos, cualquier cosa que no tenemos derecho a creer, es un riesgo. La palabra riesgo es sinónimo de incertidumbre. Gestionar riesgos consiste en anticiparse a esos eventos inciertos, para no tener que improvisar si es que ocurren. Es importante anticiparse a los problemas, gestionando los riesgos negativos o amenazas, y es importante anticiparse a los beneficios, gestionando los riesgos positivos u oportunidades. Al Director de Proyectos no le gusta verse sorprendido por los problemas, pero tampoco quiere que le sorprenda un éxito inesperado, quiere verlo venir. Queremos gestionar cuando hay tiempo, cuando tenemos opciones. En resumen: no confiamos en la improvisación. Improvisar es la peor manera de gestionar. 

Lo contrario a gestión de riesgos se llama gestión de crisis. 

Navegando los procesos del PMBOK

Desde que se publicó como borrador en 1983, la Guía de los Fundamentos para la Dirección de Proyectos (A Guide to the Project Management Body of Knowledge - PMBOK®) se ha reeditado ya cinco veces, la última en diciembre de 2012. Con más de 4 millones de copias circulando, es sin duda uno de los mayores best sellers en la categoría de libros técnicos. Un éxito reciente en la difusión del PMBOK es la gran influencia que ha tenido para el nuevo estándar ISO 21500, lo que le ha supuesto el espaldarazo definitivo como estándar para la gestión de proyectos, a nivel mundial.

Se asume que todo aquel que quiera hacer carrera como profesional de la Dirección de Proyectos, debería conocer esta guía en profundidad. Todas las personas que se han certificado PMP® o CAPM® (unos 600.000 en todo el mundo) lo han estudiado detenidamente para preparar su examen. Todos los socios de PMI® (unos 450.000) pueden descargarse gratuitamente una versión en PDF.

Pero ¿cuál es la utilidad del PMBOK  para el Director de Proyectos, desde un punto de vista práctico, en nuestros proyectos de cada día? Ahí va mi breve respuesta:

A los Project Managers, la guía PMBOK nos sirve para estructurar la cabeza.

Requisitos de un simulador de exámenes de PMI

Como sabe todo aquel que se haya preparado para obtener alguna certificación de PMI®, una vez se dominan los conceptos, es clave practicar tests parecidos a los del examen, cuantos más, mejor. Suelen ser exámenes con una restricción dura de tiempo, por lo que es vital haberse entrenado para responder las preguntas rápido y bien. Los que superan estos exámenes sin dificultad, comentan que los días previos realizan amplias baterías de tests que pueden equivaler a 2-3 veces la extensión del examen. Si hablamos del PMP, esto supone entre15-20 horas de esfuerzo para hacer y revisar unas 500 preguntas.

Si bien estos exámenes pueden practicarse en papel, es mucho más productivo utilizar alguna herramienta que permita realizarlos por ordenador. Si además hacemos la prueba CBT (Computer Based Testing) es importante que estos simuladores tengan una funcionalidad y apariencia lo más parecida posible a la aplicación que nos vamos a encontrar el día del examen.

En este post quiero compartir una forma de simulador de examen un tanto especial: No requiere instalar nada en el ordenador (PC o Mac). Tampoco requiere conexión a Internet. No hay que usar una base de datos ni programar.

A mí me sirve para preparar preguntas para mis alumnos y hacerles pruebas de nivel, para ensayar preguntas en clase, en webinars, etc. Como alumno, yo mismo he utilizado estos simuladores intensamente para preparar mi examen PMI-ACP.

A los Project Managers nos gustan las despedidas

Un project manager se distingue de un service manager (operation manager) principalmente por una razón: Lo que gestiona, es decir, el proyecto, se termina en un momento dado. Ya desde su inicio nace con ese objetivo: concluir antes de una fecha prefijada. Además del objetivo temporal, hay hay otros objetivos no menos importantes, como son terminar sin exceder un presupuesto, entregando una funcionalidad determinada, consiguiendo que el producto sea “bueno” desde el punto de vista del cliente, etc., pero quizá lo más distintivo de un proyecto es que empieza y acaba.

Uno de los hábitos que se le pide a un Director de Proyectos Eficaz es que comience “con el fin en la mente”. Desde el primer día del proyecto debe visualizar el destino y el camino para llegar al mismo. Nos imaginamos cómo será esa situación final en que los interesados “han alcanzado o superado sus expectativas” y queremos hacer todo lo posible para navegar a ese puerto. Un Director de Proyectos Eficaz reconoce que el proyecto que acaba de iniciar es un “bonito lío” que desconcertará y molestará a mucha gente que tendrá que cambiar, en el que ocurrirán muchos problemas, conflictos, crisis inesperadas; en el que dependerá de un grupo de personas que no han trabajado juntas acaben siendo un equipo cohesionado y sinérgico; en el que los contratos que su empresa firmará con terceros para que hagan ciertas partes del proyecto podrían terminar en los tribunales...

Todo este “entuerto” debe deshacerlo el project manager, por tanto es muy natural que se imagine ese último día en que ocurre el cierre efectivo y por fin termina todo: Ha convocado al patrocinador y un subconjunto representativo de interesados. Ha elaborado una presentación powerpoint que ha ensayado a conciencia. Se ha puesto su mejor traje, ha preparado la sala, el proyector, los interesados ya han llegado, es la hora. Comienza por fin esa ceremonia llamada “presentación de fin de proyecto”, pero en su cabeza, esta presentación tiene este otro título: “Adiós, me voy”.

Yo creo que esta forma de pensar debe tener también implicaciones psicológicas. ¿No resulta un poco alienante que eso que nosotros hemos creado con tanta ilusión, “nuestro proyecto”, queramos hacerlo morir desde el primer día? Sin embargo, esto es precisamente lo que se espera de nosotros: comenzamos, ejecutamos y cerramos proyectos. Cuando has pasado por esto muchas veces, te acabas acostumbrando a esta última parte, que es la más dura. En cualquier caso, conviene estar preparado.

Hace poco he visto la película Los Lirios del Valle, con Sidney Poitier. Lo que transcurre en la película se parece mucho a un proyecto “Construir una Capilla”, pero la parte más elocuente es sin duda el final: A mi juicio, un proyecto debería cerrarse justo así.

A continuación analizaré algunas claves de lo que a mí me parece un buen cierre de proyecto. Les advierto que voy a “destripar” el final de esta buena película, así que si aún no la han visto, por favor, no sigan leyendo ;-)

Managing Change Expectations

Quite often, projects are performed to set up change in organizations. When implementing a product, service or any other final result into the performing organization, chances are we are introducing big changes in the daily work of much people, whose natural fear to change can be a serious threat to project goals. 

Effective Project Managers should foresee how the transformation components of a project will affect these people —and also the subsequent changes in operation phases after the project. Changes should not be “sold” to people who are going to change on the merits of the new status quo. People don’t leave easily their comfort zone. They act more emotional than rational (see the post: everybody hates change).

Better than praising the advantages in the new future scenario after the project, it is much more effective if you focus on how bad is the situation now, to get people aware of the inconveniences of keeping the same. Can we afford not doing the project? This rationale serves to get the project buy in, and anyone involved have to be aware of it. Then you have to sell not the long term advantages of the new scenario, but the short term convenience of the project you are executing right now. In this stage, it is not important for them to visualize that long term future (although it is useful for you).

El rol del Product Owner en la práctica

El Product Owner es un rol muy importante en los proyectos ágiles: Representa nada menos que la voz del cliente. Se asegura de que el equipo conozca la perspectiva del negocio. Gestiona las historias de usuario, las prioriza, y las mantiene en el product backlog. En un proyecto ágil, no es menos importante la figura del “coach” o ScrumMaster, ocupado principalmente en asegurar que se sigue el proceso y evitar impedimentos.

Personalmente, me interesa mucho el papel nos toca a los Project Managers en un proyecto ágil, pero no está claro si debe ser ScrumMaster, Product Owner, una mezcla de ambos, o bien depende del caso concreto. En las referencias más utilizadas no parece haber una opinión consensuada: En este post se comenta que el Project Manager podría ejercer cualquier rol, dependiendo del caso. Este otro va más en la línea de que el Project Manager debe corresponderse con el rol de Product Owner.

Para arrojar luz sobre el tema, lo primero es conocer en detalle qué se supone que debe hacer el Product Owner en la práctica. Con este fin les recomiendo que visiten este famoso vídeo titulado Agile Product Ownership in a Nutshell. También pueden ver esta otra versión del mismo vídeo subtitulada en español: El rol del Product Owner en la práctica.

A continuación pueden leer una transcripción traducida al español.