Administracion De Proyectos Para Todos

Administración de Proyectos para Todos

Harold Maduro

Para todos los que hemos trabajado en proyectos

y hemos fallado

Administración de Proyectos para Todos Página 2 de 32

Indice

Introducción 4

El Problema 5

Administración de Proyectos 6

Fases de Proyectos 7

Concepto 8

Planeación 11

Implementación 19

Cierre 23

Administración de Proyectos en nuestra vida diaria 24

Recolectar 25

Procesar nuestro Inbox 25

Conclusión 30

Recomendaciones 31

Bibliografía 32


Introducción

Cada día ganamos mayor responsabilidad en nuestros trabajos, en el estudio y a nivel

personal. Cada uno de nosotros debe manejar un flujo de información, tareas,

pendientes y “cosas” que hacer que pareciera interminable; aunque quisiéramos

detenerlo, el flujo de nuevas acciones que debemos darle seguimiento no se detiene.

Sin embargo, se espera de nosotros la suficiente responsabilidad y capacidad para

lidiar con todo esto. Muchas de estas responsabilidades son acciones o tareas

independientes, cosas sencillas que podemos realizar si les disponemos tiempo; pero

en muchas situaciones, son un conjunto de tareas que se deben realizar para obtener

un resultado mayor, más complejo, elaborado.

Redecorar la terraza, terminar la tesis, irse de vacaciones a Aruba, entrenar al personal

en el uso del nuevo sistema de compras o migrar la data de contabilidad al nuevo

servidor son todos proyectos, que independientemente de su complejidad, se pueden

dividir o granular en una serie de tareas individuales que deben ser realizadas por

diferentes personas o recursos, dentro de un periodo de tiempo determinado y bajo

un presupuesto establecido.

Desde la década de los años 1950s, las organizaciones han comenzando a aplicar

sistemáticamente los procedimientos de la administración de proyectos para

desarrollar proyectos complejos. Y así ha ido evolucionando este campo, hasta tocar

todas las ramas y campos para dar un poquito de ayuda en el desempeño de las

tareas, buscando la eficacia y la productividad ante todo.

Como veremos, la administración de proyectos se basa en la comunicación, y para

ayudarnos a comunicar, nos brinda una serie de herramientas que podemos

implementar en nuestro proyecto, ya sea chico o millonario.


El Problema

Recordemos la última vez que contratamos a trabajadores para hacer una

remodelación en la casa: nos cotizaron un monto específico y nos garantizaron que en

una semana tendrían el trabajo listo. Un mes después y el triple del monto inicial más

tarde, aún no tenemos listo lo que queremos y ya hemos aceptado que nunca lo

tendremos, ya que nos costaría aún el doble.

Esta es una realidad en la mayoría de los proyectos que se realizan hoy día;

regularmente existe una tendencia a subestimar la complejidad del mismo y a dar

estimados muy apresurados y muy por debajo de que realmente costaría desarrollarlo.

El campo de la informática no es excepción; aunque no laboremos en informática,

todos hemos sido testigos de implementaciones de software que toman uno o dos

años más de lo planeado originalmente.

Malas estimaciones de tiempo, presupuestos muy bajos, riesgos encontrados en el

camino, personal poco capacitado o insuficiente cantidad de personal, objetivos poco

claros, mal entendidos, cambio del alcance original son algunas de las causas de

estos problemas; y sorprendentemente, son los mismos problemas que se dan en

otras ramas: la construcción, diseño web, arquitectura, etc.

Todas estas limitantes podemos atacarlas con un poco de planeación y mucha

comunicación; y en estos dos puntos es donde entra la administración de proyectos,

con sus procedimientos y herramientas.


Administración de Proyectos

Según el libro A Guide to the Project Management Body of Knowledge o PMIBOK,

como se le conoce por sus siglas, un proyecto es un emprendimiento temporario

dirigido a crear un producto o servicio único. Temporario y único son puntos

importantes, ya que un proyecto tiene un periodo de vida, tiene un principio y un fin,

aunque sea un “mega proyecto” que dure varios años en su ejecución, al final se debe

entregar el producto y entregar el proyecto. Por ejemplo: la construcción del Canal de

Panamá. El servicio o trabajo de mantenimiento de un sitio web, por ejemplo, no es un

proyecto, ya que es un emprendimiento contínuo que debe realizarse para mantener el

sitio web actualizado. Es cierto que luego de entregado el proyecto, pueden

desarrollarse nuevos proyectos o proyectos más chicos para actualizar el producto o

mejorarlo, pero cada uno de estos proyectos debe entregar un producto y debe tener

principio y fin.

Por último, el proyecto debe entregar un producto único; ya que sino, sería una

producción en masa. Como ejemplo, podemos comparar la producción de las

salchichas Kienner, que no es un proyecto ya que es una producción en masa

constante vs la elaboración de un nuevo sabor de salchicha Kienner, proyecto que

crearía un producto nuevo, el cual sería comercializado y producido masivamente a

futuro.

Estos dos puntos pueden sonar muy básicos; pero a nuestro concepto es importante

recalcar la diferencia, ya que en el ofrecimiento de nuestros servicios en el futuro,

estos conceptos van a salir a flote.

Entonces, ¿Qué es Administración de Proyectos? Según el mismo libro, es la

aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades

de un proyecto con el propósito de cumplir con las necesidades y/o expectativas de

los interesados y/o afectados (stakeholders) en dicho proyecto.


Fases de Proyectos

Ciclo de vida de un proyecto

Dependiendo de la metodología, podemos dividir un proyecto en un sinnúmero de

fases; pero siguiendo la metodología del Instituto de Administración de Proyectos

(PMI, por sus siglas en inglés), podemos dividir un proyecto típico en 4 fases:

• Concepto o factibilidad

• Planeación

• Implementación y control

• Terminación y entrega (o lanzamiento)


ConceptoComo primer paso, se debe identificar una necesidad o un problema, la cual será

atacada con el proyecto. La conceptualización, planeación o fase de factibilidad

regularmente es realizada por la alta dirección en las empresas grandes, o por

nuestros clientes, en los casos que seamos contactados para cotizar o desarrollar el

proyecto en sí (en el caso del diseño de una casa por un arquitecto, o el rediseño de

un sitio web por una agencia; ya el cliente ha decidido que debe realizar el proyecto y

que de una forma u otra, es factible).

En esta fase, debemos responder las siguientes preguntas (a nivel macro):

• ¿Qué vamos a hacer?

• ¿Para quién lo vamos a hacer?

• ¿Por qué?

¿Cuántos de nosotros no nos hemos visto trabajando día a día en un proyecto,

enfocados en los detalles técnicos cuando repentinamente nace la pregunta en

nuestro interior: “¿por qué esta gente quiere implementar este software en su

organización? ¿qué ganan ellos con esto? ¿realmente, quién va a usar esto?”. Esta

es evidencia de que no están claros los objetivos o por lo menos, no se han

comunicado efectivamente a todos los miembros del equipo.

Al inicio de cada proyecto, se debe realizar un estudio de las necesidades que se

tienen:

• Definición clara de las necesidades por parte de los interesados

• Debemos confirmar con varios interesados

• Debemos investigar para entender la necesidad

• Documentar

Esto, con el fin de satisfacer las expectativas del cliente correcto (muchas veces la

persona que nos contacta para desarrollar un proyecto no será el usuario final con el

problema o la necesidad).


Luego de entender las necesidades y el público objetivo o cliente final, se deben

delinear los objetivos. Las personas interesadas, el administrador del proyecto, el

cliente final y los trabajadores del proyecto deben estar claros en cuáles son los

objetivos del proyecto para que todos trabajen con el mismo fin.

La razón para rediseñar un sitio web no sólo debe ser “porque ya está viejo”, o

“porque la competencia tiene un sitio web”; sino, deben existir metas claras de

negocio y de mercadeo por la cual emprender el proyecto: “reducir las llamadas al

departamento de atención al cliente en un 50% los próximos meses del año”, “ofrecer

una plataforma virtual donde el cliente pueda realizar sus transacciones desde casa,

de manera rápida e intuitiva”.

Un detalle importante de la fase inicial es que se debe decidir si el proyecto es rentable

o no. Esta es la factibilidad del proyecto o la relación costo / beneficio. Para

identificar esto, se utilizan varias herramientas financieras, que nos permiten calcular el

valor de nuestro dinero invertido el día de hoy, al futuro, cuando haya culminado el

proyecto. Estas herramientas nos permiten ver claramente si nos resulta mejor

simplemente no invertir en el proyecto y dejar el dinero en el banco. Algunas de estas

herramientas son:

• Recuperación

• Retorno de la Inversión, ROI por sus siglas en inglés (Return of Investment)

• Valor Presente Neto - VAN

• Tasa Interna de Retorno - TIR

• Valor Económico Agregado

El detalle de cómo calcular cada una de estas fórmulas se escapa del alcance de este

documento, pero queremos compartir con ustedes algunos enlaces que entran en

detalle:

http://es.wikipedia.org/wiki/ROI

http://es.wikipedia.org/wiki/VAN


http://es.wikipedia.org/wiki/Tasa_interna_de_retorno

http://es.wikipedia.org/wiki/Valor_económico_agregado

Hay un detalle que regularmente queda por fuera, pero es mencionado de manera muy

clara en el libro de Laudon: los objetivos del proyecto deben estar alineados con los

objetivos de negocios de la empresa y/o con su plan estratégico. Si no es así,

deberíamos optar por no realizar el proyecto.

El entregable: producir un acta de constitución del proyecto, que vendría siendo el

acta de nacimiento o enunciado de los lineamientos básicos de qué vamos a hacer.

Este documento debe ser compartido con todos los miembros del equipo de trabajo y

personas interesadas (stakeholders). No tiene que ser un documento muy extenso, de

hecho, con dos páginas contamos con el espacio suficiente. Contiene:

• Justificación (necesidades, requisitos)

• Descripción del proyecto a alto nivel

• Descripción del producto

• Listado de los entregables principales

• Tiempos y costos

• Retorno de la inversión

• Recursos a utilizar

• Listado de asunciones y restricciones.

En el caso que estemos cotizando con varios proveedores para el desarrollo del

proyecto, esta acta es lo suficientemente informativa para que ellos tengan una idea

clara de nuestras necesidades e identifiquen si están en la capacidad de atendernos,

antes de agendar una reunión inicial.


PlaneaciónLa fase de planeación, a mi concepto, es la más interesante del proceso. Se toman

todas las variables y se realizan estimaciones de qué tareas se deben realizar, cuánto

tiempo deben tomar cada una de las tareas, cuántos recursos (personas, maquinarias,

software, dinero) necesitamos para realizarlas.

La fase de planeación es para los que somos contratistas u ofrecemos un servicio a

otras empresas, la primera fase de trabajo de un proyecto; es el análisis inicial del

proyecto que desea el cliente y como resultado, generamos una cotización. Esto es lo

que lo hace tan interesante: es estudiar qué necesitan, para identificar qué podemos

ofrecerles y hacer un plan de trabajo.

¿Qué debemos contestar en esta fase?

• Requerimientos

• Alcance del proyecto

• Tareas a realizarse

• Costos

Los requerimientos son los detalles de qué debe llevar el producto final, cuáles son sus

especificaciones y cómo debe comportarse. Existen dos tipo de requerimientos:

• Requerimientos funcionales

• Requerimientos técnicos

Los requerimientos funcionales detallan cómo debe comportarse el producto final,

cuál debe ser su funcionalidad y cómo debe interactuar el usuario con el mismo. Esto

lo podemos ver de manera clara en cualquier proyecto de desarrollo de software: si

estamos por producir una aplicación de inventario, debemos detallar qué funciones

necesitamos que tenga (listado de productos, detalle de productos, alertas cuando la

cantidad de producto llega a ser menor a X, etc) como también tomar en cuenta la


facilidad de uso de la aplicación, por medio de un diseño de interfaz claro y usable,

acompañado de etiquetas, textos y mensajes de error redactados de manera clara.

Los requerimientos funcionales son importantes, ya que es uno de los puntos donde

se comienza a poner al usuario final en la mira. En el caso del software: debe ser lo

suficientemente amigable, claro y sencillo para que sea utilizado de manera intuitiva.

De nada vale realizar una implementación de un software sin tomar en cuenta al

usuario final, nos ponemos a la merced del rechazo e inclusive de la pérdida de

clientes; como sucedió cuando HSBC impuso su nuevo sistema de banca en línea, el

cual es excesivamente complejo y barroco, y esto ha ahuyentado a los clientes que

estaban acostumbrados al sistema de Banistmo.

Los requerimientos técnicos son todos los detalles de cómo funciona el producto

por dentro. En el caso de sistemas de información: sobre qué plataforma corre, qué

desempeño debe tener la computadora que lo corre, qué tipo de base de datos

debemos utilizar, en qué lenguaje se debe programar, etc. Estos son puntos clave en

el desarrollo de un proyecto; sin embargo, es totalmente transparente para el usuario

final, quien sólo ve el producto. Estos requerimientos van a variar dependiendo de

empresa, de su infraestructura de sistemas y de los sistemas que tengan ya

implementados. Estos servirán también para detectar los posibles proveedores que

puedan trabajar nuestro proyecto.

Un ejemplo que mezcle ambos tipos de requerimientos: un banco está buscando un

proveedor que desarrolle su Intranet, la cual debe ser fácil de usar y contar con

secciones como noticias, directorio de empleados y fechas de cumpleaños; pero esta

intranet debe correr sobre el software de colaboración Sharepoint, el cual corre sobre

servidores Windows.

Al tener esta información, podemos comenzar a planear cada una de las tareas que se

deben realizar para completar el proyecto. La experiencia en nuestra rama nos dará la


confianza para realizar estos estimados, como también información sobre proyectos

pasados como reportes de horas, cronogramas actualizados, vitácoras de trabajo, etc.

El trabajo debemos granularlo a las tareas o grupo de tareas que podemos supervisar

y dentro de lo posible, estimar cuánto tiempo va a tomar hacer cada una de estas

tareas. Este listado de tareas, ordenado jerárgicamente, se le conoce como Estructura

de Desglose de Trabajo o Work Breakdown Structure (WBS).

Ejemplo de WBS

La ventaja del WBS es que nos ofrece una alternativa muy sencilla a quienes

ofrecemos servicios para calcular cuánto podemos cobrar por nuestros servicios. En


mi caso personal, asigno un costo por hora y el WBS automáticamente calcula el

costo de cada una de las tareas a realizar, como vemos en la siguiente gráfica:

Cálculo de costos utilizando el WBS

El costo por hora de cada empresa o profesional va a variar mucho, pero una forma

rápida de calcularlo sería tomando el costo total de correr la empresa mensualmente y

dividirlo entre la cantidad de horas laborables y productivas que hay al mes. Aquí se

nos presenta un escenario interesante, ya que ningún empleado realmente labora o es

productivo las 8 horas del día; probablemente es realmente productivo unas 6 o 5

horas.

Otra forma de verlo es, dividir la cantidad de dinero que quisiéramos ganar en un mes

entre la cantidad de horas que quisiéramos trabajar. Este es un escenario más utópico


y tal vez más conveniente para un profesional independiente, pero de igual forma,

presenta una alternativa de cálculo interesante.

Si somos observadores, notamos que no hemos incluido el margen de utilidad en

ninguno de los dos cálculos. Algunas personas se inclinan por agregar el margen en el

costo por horas, mientras que otros prefieren calcularlo al final del costo total del

proyecto. Me inclino por la segunda opción, y pueden ver en la siguiente gráfica cómo

lo calculo:

Costos totales por desarrollo y precio de venta

Como vemos, podemos agregar otros costos indirectos a la producción del proyecto

como la administración, tomar en cuenta los riesgos (veremos detalles sobre riesgos

más adelante), para finalmente agregar nuestro margen de utilidad porcentual. El

precio de venta es el precio final que le daremos al cliente por la producción del

proyecto y ya incluye nuestra ganancia.

El WBS es una excelente herramienta de uso interno; pero es importante recordar que

uno de los pilares de la administración de proyectos es la comunicación, y existe una

forma fácil de poder mostrar el plan del proyecto al equipo: por medio de las gráficas

de Gantt.


Las gráficas de Gantt nos permiten imaginarnos el desarrollo de las tareas a lo largo

del paso del tiempo. Son una representación gráfica del WBS. Un concepto que se

introduce al ver el proyecto desde este punto de vista es el de la dependencia:

comenzamos a estructurar el proyecto de tal forma que disponemos las tareas que

pueden ejecutarse a la vez para que todas inicien al mismo tiempo; mientras que

organizamos las tareas que dependen del cumplimiento exitoso de una anterior para

que inicie al terminar dicha tarea.

Ejemplo de gráfica de Gannt

Más información de Gantt:

http://en.wikipedia.org/wiki/Gantt_chart

Otra herramienta que nos brinda la administración de proyectos es el diagrama de

PERT (Program Evaluation Review Technique), que nos permite calcular la ruta crítica

utilizando la información anteriormente generado por el WBS y el cronograma sobre la

cantidad de tareas que debemos realizar, sus dependencias y cuánto tiempo toma

cada una. Esta gráfica nos muestra de manera muy sencilla (luego de haber sido

diagramada y los cálculos realizados) cuál es la serie de tareas que no tienen holgura,


en otras palabras, la serie de tareas que si presentan algún tipo de demora, atrasarían

el proyecto entero.

A manera muy introductoria, podemos mencionar que en el PERT se representa cada

tarea como un cuadrito, el cual está identificado por una letra o número;

acompañamos la identificación del cuadrito o tarea con la duración de la misma (A - 2

horas, por ejemplo).

Diagrama de PERT que muestra la ruta crítica

Debemos marcar el inicio y final de cada una de las tareas, según la información que

obtuvimos del cronograma. Aquí introducimos un concepto nuevo, el “early start” y

“early finish”. ¿Qué significa esto? Que los estimados de tiempo que hemos estado

realizando hasta ahora habían sido de los tiempos más tempranos en que podemos

comenzar a trabajar una tarea y los tiempos más tempranos en que podemos

terminarla. Habíamos trabajado hasta la fecha con los tiempos optimistas. Estos

tiempos “tempranos” son los números que vemos a arriba de cada cuadrito, a la

izquierda va el inicio temprano y a la derecha, el final temprano.


Al terminar de calcular estos tiempos, hacemos los cálculos de inicio y final de las

tareas pero recorriendo el gráfico “hacia atrás”, comenzando por el final, tomando

como punto de partida la cantidad de horas totales que duró el proyecto y restando la

duración de cada una de las tareas. Esto nos da los “late start” y “late finish”, que son

los tiempos máximos que podemos esperar para comenzar a trabajar la tarea y el

tiempo máximo que podemos tomar haciéndola. Estos valores son los que se colocan

abajo de cada cuadrito.

Podemos calcular la holgura o el tiempo que podemos demorarnos antes de comenzar

a trabajar en cada tarea sin atrasar el proyecto, restando el fin tardío del fin temprano;

o el inicio tardío del inicio temprano (es lo mismo, el resultado va a ser igual al restar

cualquier juego de tiempos). Súper, ahora tenemos la información de cuánto nos

podemos demorar en cada parte del proceso sin impactar la duración del mismo.

Al calcular todos estos tiempos, vamos a encontrar una serie de tareas donde ninguna

de sus tareas tiene holgura; lo que significa que no podemos atrasarnos en ninguna de

ellas; sino causaríamos un impacto negativo en el proyecto. Esta se le conoce como

la ruta crítica y nos brinda una alerta temprana de tareas donde debemos aplicar

mayor control, supervisión o asignarles más recursos (gente o dinero).

Para más información del PERT:

http://es.wikipedia.org/wiki/PERT

http://en.wikipedia.org/wiki/Pert

Dependiendo del tamaño del proyecto, su complejidad o las políticas establecidas por

el cliente, podemos generar aún mayor cantidad de planes o lineamientos antes de

desarrollar el proyecto: plan de recursos humanos, plan de comunicaciones, plan de

riesgos, plan de calidad, plan de compras o plan de contrataciones. En este punto,

nos vemos en la diatriba de seguir planeando o arrancar a trabajar; y en la mayoría de

los casos, es mejor irse por la segunda opción.


ImplementaciónTodos los planes están hechos, los costos estimados y el proyecto aprobado. Es hora

de comenzar a trabajar. En el momento que el caucho choca contra el cemento,

comenzamos a realizar que no importa cómo desarrollamos los mejores planes,

siempre habrán imprevistos, problemas, riesgos y desviaciones. Esta fase de

implementación involucra mucho seguimiento, supervisión y una habilidad

extraordinaria de comunicación; características que muchos carecemos, lo que lleva a

problemas sobre la marcha en los proyectos.

Indudablemente, el administrador de proyectos se verá envuelto en todo tipo de

reuniones. Las reuniones, más que un calvario que debamos sobrellevar, es una

herramienta más a nuestra disposición (igual que los Gantt y PERTs). Existen tres tipos

de reuniones que podemos listar:

• Kickoff

• Follow up

• Pendientes

Las reuniones de lanzamiento o kickoff son la oportunidad del administrador de

proyectos para traer a bordo a todos los miembros del equipo, comunicar todos los

planes desarrollados en la fase anterior, dejar claro los objetivos y alcance del proyecto

y motivar al personal para que sientan pertenencia y propiedad del proyecto y del

trabajo que deben realizar. Hoy día trabajamos con equipos heterogéneos y

geográficamente distantes; esto no debe ser una limitante para nuestras reuniones, si

aprovechamos las tecnologías disponibles de conferencia, chat o video conferencia.

Es recomendado que periódicamente el administrador de proyectos agende una

reunión de seguimiendo o follow up con el cliente, para darle una actualización del

estado de su proyecto, presentarle el producto en el estado que se encuentre a la

fecha para recibir feedback y escuchar cualquier comentario que brinde el cliente.

Estas son de importancia, para que el cliente esté informado de la salud del proyecto y


no haya una desconexión entre las expectativas del cliente y las del equipo de trabajo.

Estas reuniones pueden ser peligrosas, ya que el cliente podría solicitar cambios o

funcionalidad que no estaba delineada en el alcance del proyecto; pero el

administrador debe ser lo suficientemente profesional para manejar estas situaciones,

realizando lo que se conoce como una solicitud de cambio, la cual tiene un impacto

sobre el tiempo y costo total del proyecto, o debe informarle diplomáticamente al

cliente que dicha funcionalidad no es parte del alcance original. El trabajo del

administrador de proyectos incluye diplomacia, comunicación, psicología, docencia,

planeación, finanzas, paternidad y predicción del futuro, entre otras.

Todos ganan con las reuniones de pendientes y el administrador debe ser lo

suficientemente estricto y consistente para realizarlas religiosamente, ya sea una vez a

la semana, o diarias. En estas reuniones hacemos una revisión de cómo va cada

miembro del grupo con su(s) tarea(s) asignadas, comparar el plan del proyecto con la

realidad y estimar cuándo podemos tener listos los diferentes entregables. Estas

reuniones son una buena oportunidad para traer a todos los miembros del equipo para

que compartan sus problemas y retos, probablemente otra persona pueda ayudarlo

con sus problemas.

Como mencionamos en las reuniones de follow up, el administrador de proyectos

debe manejar expectativas para que:

• El proyecto no cambie en su alcance

• Que no sobrepase el presupuesto

• Que no sobrepase en tiempo

• Que haya aceptación del proyecto y su producto final, por parte de los usuarios

finales (esto se puede realizar con presentaciones, entrenamiento y disponibilidad de

información)

Tres tips para reuniones efectivas:

• Preparar una agenda de temas a tocar en la reunión, para no traer a bordo a todos y luego improvisar en la reunión.


• Tomar nota de todo lo comentado y acordado en la reunión.

• Enviar un email a todos los presentes con las minutas de lo acordado.

• Tan predescible como el caer de la noche, en cada reunión siempre habrá alguien que sugiera ideas y funcionalidades nuevas o traiga a la mesa temas que se alejan un poco de la agenda. Para no descartar sus ideas o apagar su creatividad, pero poder llevar control de la reunión, recomendamos el concepto del parking lot o estacionamiento, que consiste en tomar su idea, escribirla en un papel y pegarla en un tablero destinado a ser el parking de ideas que podemos usar en un futuro, pero que no vamos a elaborar en el presente.

Existen diferentes medios de llevar control y seguimiento del proyecto y su presupuesto. El uso de estas técnicas va a variar mucho del proyecto, su tamaño y cultura organizacional. Lo importante es tener en cuenta que para administrar efectivamente proyectos, el administrador debe estar atento y presente; no puede gestionar el plan del proyecto y desconectarse hasta la fecha de entrega, esto es una receta para el fracaso.

Más información sobre técnicas de control y seguimiento:http://es.wikipedia.org/wiki/Valor_ganadohttp://en.wikipedia.org/wiki/Earned_Value_Management

http://en.wikipedia.org/wiki/Present_valuehttp://en.wikipedia.org/wiki/Direct_labour_cost_variance

Un tema que no podemos dejar de mencionar es la administración de riesgos. No importa qué tan buenos sean los planes, sobre la marcha siempre vamos a descubrir imprevistos. Menciona Robert Charette: “Un riesgo no es un problema.. El problema es un riesgo que ha acontecido”. El concepto de administración de riesgos es aceptar que encontraremos riesgos sobre la marcha, y tener el procedimiento para poder identificarlos, medir la probabilidad de que ocurran y el impacto que puedan tener, planear cómo vamos a gestionarlos, incorporar una gestión de riesgos dentro del proceso de planeación.


Existen dos tipos de riesgos:

• Positivos: los cuales podemos explorar, aceptar o mejorar

• Negativos: los cuales podemos evitar, manejar, transferir o aceptar

También existen riesgos conocidos (identificados) y desconocidos (no identificados).

Muchos administradores separan un porcentaje del presupuesto al inicio del proyecto (WBS) para tener un “colchón” o fondo de reserva que sirva como herramienta para manejar los riesgos. Esta es una forma aceptable de ver el problema, sólo que debemos tomar en cuenta que esto va a aumentar el costo total del proyecto, y entre más porcentajes agreguemos, menos probable sea que nos consideren para la implementación del mismo y que el cliente seleccione a otro proveedor. También debemos tomar en cuenta que los clientes probablemente pidan descuentos o mejoras al precio y estos porcentajes de riesgos se van a ver reducidos.


CierreEl día que todos esperaban y nadie creía que llegaría ha llegado: el cliente ha

aprobado todos los entregables, hemos concluido desarrollando el producto final,

entregado el proyecto y el cliente está contento y a la vez ocupado con un nuevo

proyecto: el lanzamiento de su nuevo producto. Pero todavía no podemos pasar la

página y olvidarnos del proyecto. Para tener un poco de formalidad al concluir el

proyecto, se recomienda:

• Preparar un documento que sirva como aceptación formal del proyecto por parte del

cliente, firmado por el mismo y que sirva como el cierre contractual entre el cliente y

el contratista.

• Realizar una reunión post-mortem para comentar detalles del proyecto, comentar las

lecciones aprendidas y planear los pasos a futuro.

• El cierre de contratos con todos los proveedores que nosotros hemos contratado

para el proyecto.

• Un documento que liste el cumplimiento exitoso de los objetivos planeados

originalmente. No tiene que ser extenso, puede ser una “matriz” o una tabla en Excel

que liste los requerimientos, si fueron probados y verificados, y si los cumple.

• Realizar el cierre administrativo: facturar, pagar, cerrar los sistemas de información y

comunicación (Extranet), realizar backups de los archivos, etc. Todo depende de la

empresa y la metodología de trabajo.

• Se recomienda realizar un documento de “lecciones aprendidas” que sirva como un

resumen de lo aprendido por el equipo (éxitos y fracasos) luego de haber realizado

este proyecto.

• Dar recomendaciones a los integrantes del grupo de trabajo y ayudar a reubicarlos,

ya sea dentro de la organización, en otro proyecto o con otro empleador.

• Celebrar el éxito del proyecto con una reunión o fiesta con el equipo de trabajo.


Administración de Proyectos en nuestra vida diariaEn un día típico, nos encontramos conque debemos recordar una gran cantidad de

cosas que hacer: comprar pan para la casa, limpiar el baño, terminar los reportes para

la gerencia, responder a las preguntas enviadas por email de los clientes, comprar el

regalo de cumpleaños de la novia, llamar a nuestro ex compañero de trabajo que

botaron la semana pasada, etc. Todas estas “cosas” se van acumulando en nuestra

memoria a corto plazo, la cual no tiene ninguna forma de identificar en qué momento

del tiempo debe recordar estos detalles, así es que nos lo recuerda constantemente, o

en el peor momento: ¿a quién no le ha pasado que en el momento que se dispone a

trabajar en una tarea que necesita concentración, recuerda un detalle insignificante de

algo que debe hacer en su casa - “tengo que pagar CableOnda”, por ejemplo? Esta

oleada de cosas que hacer, dando vueltas en nuestra cabeza es una de las causas del

stress en muchos, ya que nuestra mente no es la mejor herramienta para guardar estas

acciones a ejecutar.

David Allen, en su libro Gettings Things Done, nos enseña una metodología de

organización personal basada en los principios de administración de proyectos, pero

destilado y simplificado para poder ser aplicada en nuestra vida diaria,

independientemente de nuestro estilo de vida. Allen menciona que estas “cosas” que

tenemos en la cabeza quedan como círculos abiertos o nudos sin atar que quedan

huérfanos y nos continúan molestando hasta que decidamos hacer algo al respecto.

Lo malo es que, no recordamos ninguna de estas cosas cuando realmente lo

necesitamos: cuando estamos en La Arrocha, no recordamos que tenemos que

comprar baterías AAA para el control remoto, lo recordamos cuando estamos en el

carro en el tranque viajando hacia la casa. La mente es ineficiente como un sistema

de organización personal, ya que la mente es una herramienta para generar ideas

creativa.

De manera muy resumida, podemos comentar que el sistema de GTD consiste en una

serie de pasos muy sencilla:


RecolectarPrimero, debemos encontrar la herramienta que nos resulte más cómoda para la

recolección de todas las tareas que tenemos dando vueltas en nuestra mente. Se

recomienda que las primeras veces, simplemente usemos una hoja de papel y pluma

para apuntar todo; y con el tiempo, podemos ir perfeccionando nuestro sistema para

utilizar un archivo de textos en nuestra computadora, el listado de To Do de Outlook o

nuestro Blackberry. Lo llamativo de GTD es que es agnóstico a plataformas, cada uno

lo adapta a su gusto.

Tomamos una hoja de papel y comenzamos a hacer un “download” de todas las cosas

que tenemos que hacer que en el momento tenemos dando vueltas en la cabeza. A

esta hoja de papel o listado desordenado de cosas por hacer le llamaremos Inbox de

ahora en adelante. No importa si son grandes o chicas, si son importantes o

mundanas, si son relacionadas al trabajo, a la universidad o a la vida personal. Es

más, no importa en qué orden las escribamos; en este momento sólo estamos

recolectando todo lo que está en nuestra cabeza.

Al terminar de recolectar todo lo que tenemos en la mente, vamos a sentir una

sensación de tranquilidad que no teníamos antes, ya que podemos ver físicamente

TODO lo que tenemos que hacer. Paso uno: cumplido, ahora:

Procesar nuestro InboxEl siguiente paso es ir revisando uno a uno cada “cosa” escrita en el lista y

preguntarnos ¿qué es esto?

Este paso es truculento, ya que vamos a encontrar muchas cosas que realmente no

son acciones a tomar; sino, proyectos: un proyecto es simplemente un listado o

conjunto de acciones que debemos realizar para cumplir un fin, por ejemplo:

acomodar el depósito. Acomodar el depósito no es una tarea, es una lista de muchas


más tareas: comprar cartuchos de basura jardineros, comprar pintura, recoger la

basura, barrer, botar las cosas viejas, sacar la basura, pintar, etc. Uno de los

problemas que muchos tenemos (incluyéndome en primer lugar) es que podemos

estar claros con lo que tenemos que hacer, pero al encontrarnos con una tarea muy

grande o compleja, nos da pereza hacerla, así es que comenzamos a hacer cuánta

tarea tengamos que hacer con tal de no hacer esa: limpiamos el cuarto, vamos a

comprar el supermercado, reinstalamos Windows 3.11 en la computadora de la

abuela, defragmentamos los discos duro, cortamos la hierba, etc.

Esto es procrastinar y lo hacemos ya que no tenemos claro cuál es la siguiente acción

que debemos tomar en un proyecto. Para evitar esto, debemos tratar de granular o

llevar las tareas o proyectos a tareas aún más simples y básicas. Digamos que quiero

instalar Internet de Cable Onda en mi casa. ¿Cuál es la siguiente acción? “Instalar

Internet de Cable Onda” seguramente no lo es. “Llamar a Cable Onda para preguntar

planes” suena como una buena segunda acción, pero yo no tengo el teléfono de cable

onda; así es que cuando lea esta tarea en mi to do list, me va a dar pereza realizarla, la

verdadera siguiente acción sería “Entrar al sitio web de Cable Onda y buscar el número

de teléfono de atención al cliente”. Suena demasiado básico para ser verdad, pero es

así, debemos hacernos la vida más fácil y delinear nuestras tareas de la manera más

simplificada; sino, no las haremos.

De vuelta a procesar el inbox: debemos revisar cada una de las tareas y preguntarnos

¿Qué es esto?

¿Es algo accionable o algo que genere una acción?

No

En caso negativo, podemos:

• Botarlo, borrarlo, tacharlo.

• Ponerlo en una nueva lista llamada “Someday / Maybe” o “Tal vez / algún día”

• Ponerlo en una lista, folder o archivo llamado “Reference” o “Referencia”


Ejemplos:

• Quiero aprender a hablar portugués: va para el “Tal vez / algún día” ya que ahorita

mismo no voy a hacer nada al respecto, pero es algo que me interesa lo suficiente

como para no ignorarlo del todo. Hey, todo el mundo tiene derecho a soñar con

hacer cosas diferentes.

• Se va a casar mi exnovia: pa’ la basura.

• Yordano viene para Panamá: para la basura, también

• En Language Center dan cursos de hablar Portugués - 226-1950: para Referencia

futura.

¿Es algo accionable o algo que genere una acción?

Sí

En caso positivo, nos preguntamos:

¿Cuál es la siguiente acción?

• Si es una tarea compleja que involucra muchos pasos, ya sabemos que esto en

realidad es un proyecto; así es que hacemos una lista especial para ese proyecto y

tratamos de granular lo más posible todas las tareas que debemos hacer para

completarlo. El “project plan” le podríamos llamar, muy parecido a un WBS, pero

súper sencillo, a nivel personal.

• Si es una tarea individual, nos hacemos la siguiente pregunta:

¿Lo puedo hacer en menos de dos minutos?

Si lo puedes hacer en menos de dos minutos, pon un poquito de tu parte y hazlo de

una vez. Vas a ahorrar más tiempo haciéndolo inmediatamente que escribiendo en

una lista y llevando control futuro de que debes hacerlo. Sal de eso. Sal de eso

rápido.


Ejemplo: recoger el libro de Javascript que está tirado en el suelo y guardarlo en el

mueble de mi cuarto.

Para las tareas que toman más de dos minutos, tenemos dos opciones: delegarlas

para que las haga otro (en el caso de que otra persona sea la indicada para hacerla), o

agendarlo para hacerlo en otro momento, y en este caso, la agregamos en nuestra lista

de siguientes acciones (Next Actions), que es la evolución del To Do List.

Parece un sistema complejo, pero en realidad se hace natural: lo importante es:

• Constantemente recolectar lo que tenemos en mente

• Botar todo lo que no sirve

• Redactar nuestras siguientes acciones a hacer de manera más inteligente

• Identificar mini proyectos de los cuales somos responsables

• Tener un lugar para guardar todo lo que nos gustaría hacer en algún futuro: “viajar al

Machu Picchu”

• Regularmente revisar nuestros listados para ir actualizándolo y saliendo de acciones

En fin, entre menos dependamos de nuestra mente para recordar cosas que tenemos

que hacer, vamos a vivir una vida más tranquila, tener menos presión para poder

sentarnos a hacer el trabajo que realmente importa y poco a poco iremos terminando

las tareas y pendientes que siempre seguirán llegando a nuestras manos.



ConclusiónLa administración de proyectos no es una ciencia oculta reservada para un grupo de

personas. Aunque nuestro rol en la organización no sea específicamente de

administrador de proyectos, hay cabida y gran valor en que adoptemos los principios

de la administración de proyectos para organizar mejor nuestro trabajo, estructurar

nuestras tareas y tener una misión un poco mayor de lo que está pasando alrededor

nuestro y de la importancia de las tareas que nosotros desempeñamos en el esquema

mayor del proyecto que estamos trabajando.

Si simplificamos la administración de proyectos, nos damos cuenta que son una serie

de herramientas y métodos de trabajar. Dependiendo del proyecto que trabajemos y

su complejidad, podemos decidir usar algunas de estas herramientas e ignorar otras.

Ya vimos que a nivel personal, sólo basta con hacer una lista de las tareas que

conforman un mini proyecto y darle seguimiento periódico. A nivel de un proyecto

para un cliente, podemos elaborar el WBS y Gantt, por ejemplo. Para un proyecto de

una corporación, será necesario una documentación aún más estricta, como un acta

de proyecto, procesos de control de cambios, acta de cierre de proyecto.

Este documento busca presentar una introducción básica y escrita en un lenguaje

accesible al tema de administración de proyectos. Pero es sólo un aperitivo a un

mundo mucho más amplio y rico que lo presentado en estas páginas. Si le pareció

interesante el tema, todavía hay mucho que recorrer.


Recomendaciones• Ningún proyecto es demasiado chico, podemos aplicar estructura y orden hasta en

el proyecto de renovación de nuestro guarda ropa.

• Evaluar las diferentes herramientas descritas aquí e implementarla en los casos

particulares de cada uno.

• Recomendamos el concepto de cobrar por hora a quienes ofrecen servicios. El WBS

puede ser de gran ayuda en poder asignarle un precio a su trabajo.

• La comunicación y el manejo de expectativas es 75% de la administración de

proyectos (a nuestro humilde concepto).

• El administrador de proyecto debe ser un líder, no un mero administrador o “jefe”.

Debe motivar a su equipo de trabajo a cumplir las metas; no estar pisándole los

talones a la gente.

• Recomendamos empowerment en vez de micromanagement. Esto se refleja desde

el momento de hacer los WBS.

• El cronograma o gráfica de Gantt es una forma útil de comunicar el plan de proyecto

a los interesados. Ojo: al momento de imprimirlo y repartirlo, es probable que ya

esté desactualizado.

• Con la revolución del web y las redes sociales, se han desarrollado un gran número

de aplicaciones de colaboración remota, administración de proyectos y extranets

basadas en web. Aunque su equipo de trabajo no esté geográficamente disperso,

recomedamos el uso de alguna de estas aplicaciones para centralizar la

comunicación y tener registro y documentación de lo que se solicita y lo que se

entrega.


Bibliografía

Alberto López, PMP e instructor de cursos de administración de proyectos. Gracias

por toda su paciencia, dedicación, comentarios y experiencias que se ven reflejados

en este trabajo.

Sistemas de Información Gerencial - Administración de la Empresa Digital. Kenneth

Laudon y Jane Laudon. Pearson Prentice Hall. 2008

A Guide to the Project Management Body of Knowledge (PMIBOK). PMI

Metodología de Dirección de Proyectos. Alberto López, PMP. Manual del curso

impartido por ADR

Gettings Things Done, The Art of Stress-Free Productivity. David Allen.Penguin

Putnam. 2001

Wikipedia. http://wikipedia.org


Education

Administracion De Proyectos Para Todos