Professional Documents
Culture Documents
Harold Maduro
Pgina 2 de 32
Indice
Introduccin
El Problema
Administracin de Proyectos
Fases de Proyectos
Concepto
Planeacin
11
Implementacin
19
Cierre
23
24
Recolectar
25
25
Conclusin
30
Recomendaciones
31
Bibliografa
32
Pgina 3 de 32
Introduccin
Cada da ganamos mayor responsabilidad en nuestros trabajos, en el estudio y a nivel
personal. Cada uno de nosotros debe manejar un flujo de informacin, tareas,
pendientes y cosas que hacer que pareciera interminable; aunque quisiramos
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, ms 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 dcada de los aos 1950s, las organizaciones han comenzando a aplicar
sistemticamente los procedimientos de la administracin 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 desempeo de las
tareas, buscando la eficacia y la productividad ante todo.
Como veremos, la administracin de proyectos se basa en la comunicacin, y para
ayudarnos a comunicar, nos brinda una serie de herramientas que podemos
implementar en nuestro proyecto, ya sea chico o millonario.
Pgina 4 de 32
El Problema
Recordemos la ltima vez que contratamos a trabajadores para hacer una
remodelacin en la casa: nos cotizaron un monto especfico y nos garantizaron que en
una semana tendran el trabajo listo. Un mes despus y el triple del monto inicial ms
tarde, an no tenemos listo lo que queremos y ya hemos aceptado que nunca lo
tendremos, ya que nos costara an el doble.
Esta es una realidad en la mayora de los proyectos que se realizan hoy da;
regularmente existe una tendencia a subestimar la complejidad del mismo y a dar
estimados muy apresurados y muy por debajo de que realmente costara desarrollarlo.
El campo de la informtica no es excepcin; aunque no laboremos en informtica,
todos hemos sido testigos de implementaciones de software que toman uno o dos
aos ms 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 construccin, diseo web, arquitectura, etc.
Todas estas limitantes podemos atacarlas con un poco de planeacin y mucha
comunicacin; y en estos dos puntos es donde entra la administracin de proyectos,
con sus procedimientos y herramientas.
Pgina 5 de 32
Administracin de Proyectos
Segn 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 aos en su ejecucin, al final se debe
entregar el producto y entregar el proyecto. Por ejemplo: la construccin 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 contnuo que debe realizarse para mantener el
sitio web actualizado. Es cierto que luego de entregado el proyecto, pueden
desarrollarse nuevos proyectos o proyectos ms 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, sera una
produccin en masa. Como ejemplo, podemos comparar la produccin de las
salchichas Kienner, que no es un proyecto ya que es una produccin en masa
constante vs la elaboracin de un nuevo sabor de salchicha Kienner, proyecto que
creara un producto nuevo, el cual sera comercializado y producido masivamente a
futuro.
Estos dos puntos pueden sonar muy bsicos; 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 Administracin de Proyectos? Segn el mismo libro, es la
aplicacin de conocimiento, habilidades, herramientas y tcnicas a las actividades
de un proyecto con el propsito de cumplir con las necesidades y/o expectativas de
los interesados y/o afectados (stakeholders) en dicho proyecto.
Administracin de Proyectos para Todos
Pgina 6 de 32
Fases de Proyectos
Ciclo de vida de un proyecto
Pgina 7 de 32
Concepto
Como primer paso, se debe identificar una necesidad o un problema, la cual ser
atacada con el proyecto. La conceptualizacin, planeacin o fase de factibilidad
regularmente es realizada por la alta direccin 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 diseo de una casa por un arquitecto, o el rediseo 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 quin lo vamos a hacer?
Por qu?
Cuntos de nosotros no nos hemos visto trabajando da a da en un proyecto,
enfocados en los detalles tcnicos cuando repentinamente nace la pregunta en
nuestro interior: por qu esta gente quiere implementar este software en su
organizacin? qu ganan ellos con esto? realmente, quin va a usar esto?. Esta
es evidencia de que no estn 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:
Definicin 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).
Administracin de Proyectos para Todos
Pgina 8 de 32
Pgina 9 de 32
http://es.wikipedia.org/wiki/Tasa_interna_de_retorno
http://es.wikipedia.org/wiki/Valor_econmico_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 estratgico. Si no es as,
deberamos optar por no realizar el proyecto.
El entregable: producir un acta de constitucin del proyecto, que vendra siendo el
acta de nacimiento o enunciado de los lineamientos bsicos 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 pginas contamos con el espacio suficiente. Contiene:
Justificacin (necesidades, requisitos)
Descripcin del proyecto a alto nivel
Descripcin del producto
Listado de los entregables principales
Tiempos y costos
Retorno de la inversin
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 estn en la capacidad de atendernos,
antes de agendar una reunin inicial.
Pgina 10 de 32
Planeacin
La fase de planeacin, a mi concepto, es la ms interesante del proceso. Se toman
todas las variables y se realizan estimaciones de qu tareas se deben realizar, cunto
tiempo deben tomar cada una de las tareas, cuntos recursos (personas, maquinarias,
software, dinero) necesitamos para realizarlas.
La fase de planeacin es para los que somos contratistas u ofrecemos un servicio a
otras empresas, la primera fase de trabajo de un proyecto; es el anlisis inicial del
proyecto que desea el cliente y como resultado, generamos una cotizacin. 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, cules son sus
especificaciones y cmo debe comportarse. Existen dos tipo de requerimientos:
Requerimientos funcionales
Requerimientos tcnicos
Los requerimientos funcionales detallan cmo debe comportarse el producto final,
cul debe ser su funcionalidad y cmo 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 aplicacin 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 tambin tomar en cuenta la
Pgina 11 de 32
Pgina 12 de 32
confianza para realizar estos estimados, como tambin informacin sobre proyectos
pasados como reportes de horas, cronogramas actualizados, vitcoras de trabajo, etc.
El trabajo debemos granularlo a las tareas o grupo de tareas que podemos supervisar
y dentro de lo posible, estimar cunto tiempo va a tomar hacer cada una de estas
tareas. Este listado de tareas, ordenado jerrgicamente, 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 cunto podemos cobrar por nuestros servicios. En
Administracin de Proyectos para Todos
Pgina 13 de 32
El costo por hora de cada empresa o profesional va a variar mucho, pero una forma
rpida de calcularlo sera 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 ningn empleado realmente labora o es
productivo las 8 horas del da; probablemente es realmente productivo unas 6 o 5
horas.
Otra forma de verlo es, dividir la cantidad de dinero que quisiramos ganar en un mes
entre la cantidad de horas que quisiramos trabajar. Este es un escenario ms utpico
Pgina 14 de 32
Como vemos, podemos agregar otros costos indirectos a la produccin del proyecto
como la administracin, tomar en cuenta los riesgos (veremos detalles sobre riesgos
ms adelante), para finalmente agregar nuestro margen de utilidad porcentual. El
precio de venta es el precio final que le daremos al cliente por la produccin 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 administracin de proyectos es la comunicacin, y existe una
forma fcil de poder mostrar el plan del proyecto al equipo: por medio de las grficas
de Gantt.
Pgina 15 de 32
Las grficas de Gantt nos permiten imaginarnos el desarrollo de las tareas a lo largo
del paso del tiempo. Son una representacin grfica 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.
Ms informacin de Gantt:
http://en.wikipedia.org/wiki/Gantt_chart
Pgina 16 de 32
en otras palabras, la serie de tareas que si presentan algn tipo de demora, atrasaran
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 nmero;
acompaamos la identificacin del cuadrito o tarea con la duracin de la misma (A - 2
horas, por ejemplo).
Debemos marcar el inicio y final de cada una de las tareas, segn la informacin 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 haban sido de los tiempos ms tempranos en que podemos
comenzar a trabajar una tarea y los tiempos ms tempranos en que podemos
terminarla. Habamos trabajado hasta la fecha con los tiempos optimistas. Estos
tiempos tempranos son los nmeros que vemos a arriba de cada cuadrito, a la
izquierda va el inicio temprano y a la derecha, el final temprano.
Pgina 17 de 32
Al terminar de calcular estos tiempos, hacemos los clculos de inicio y final de las
tareas pero recorriendo el grfico hacia atrs, comenzando por el final, tomando
como punto de partida la cantidad de horas totales que dur el proyecto y restando la
duracin de cada una de las tareas. Esto nos da los late start y late finish, que son
los tiempos mximos que podemos esperar para comenzar a trabajar la tarea y el
tiempo mximo que podemos tomar hacindola. 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 tardo del fin temprano;
o el inicio tardo del inicio temprano (es lo mismo, el resultado va a ser igual al restar
cualquier juego de tiempos). Sper, ahora tenemos la informacin de cunto nos
podemos demorar en cada parte del proceso sin impactar la duracin 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 causaramos un impacto negativo en el proyecto. Esta se le conoce como
la ruta crtica y nos brinda una alerta temprana de tareas donde debemos aplicar
mayor control, supervisin o asignarles ms recursos (gente o dinero).
Para ms informacin del PERT:
http://es.wikipedia.org/wiki/PERT
http://en.wikipedia.org/wiki/Pert
Dependiendo del tamao del proyecto, su complejidad o las polticas establecidas por
el cliente, podemos generar an 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 mayora de
los casos, es mejor irse por la segunda opcin.
Pgina 18 de 32
Implementacin
Todos los planes estn 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 cmo desarrollamos los mejores planes,
siempre habrn imprevistos, problemas, riesgos y desviaciones. Esta fase de
implementacin involucra mucho seguimiento, supervisin y una habilidad
extraordinaria de comunicacin; caractersticas 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, ms que un calvario que debamos sobrellevar, es una
herramienta ms a nuestra disposicin (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 da trabajamos con equipos heterogneos y
geogrficamente distantes; esto no debe ser una limitante para nuestras reuniones, si
aprovechamos las tecnologas disponibles de conferencia, chat o video conferencia.
Es recomendado que peridicamente el administrador de proyectos agende una
reunin de seguimiendo o follow up con el cliente, para darle una actualizacin 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
Pgina 19 de 32
no haya una desconexin entre las expectativas del cliente y las del equipo de trabajo.
Estas reuniones pueden ser peligrosas, ya que el cliente podra 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 diplomticamente al
cliente que dicha funcionalidad no es parte del alcance original. El trabajo del
administrador de proyectos incluye diplomacia, comunicacin, psicologa, docencia,
planeacin, finanzas, paternidad y prediccin 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 revisin de cmo va cada
miembro del grupo con su(s) tarea(s) asignadas, comparar el plan del proyecto con la
realidad y estimar cundo 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 aceptacin del proyecto y su producto final, por parte de los usuarios
finales (esto se puede realizar con presentaciones, entrenamiento y disponibilidad de
informacin)
Tres tips para reuniones efectivas:
Preparar una agenda de temas a tocar en la reunin, para no traer a bordo a todos y
luego improvisar en la reunin.
Administracin de Proyectos para Todos
Pgina 20 de 32
Pgina 21 de 32
Pgina 22 de 32
Cierre
El da que todos esperaban y nadie crea que llegara 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 todava no podemos pasar la
pgina y olvidarnos del proyecto. Para tener un poco de formalidad al concluir el
proyecto, se recomienda:
Preparar un documento que sirva como aceptacin 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 reunin 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 informacin y
comunicacin (Extranet), realizar backups de los archivos, etc. Todo depende de la
empresa y la metodologa 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 organizacin, en otro proyecto o con otro empleador.
Celebrar el xito del proyecto con una reunin o fiesta con el equipo de trabajo.
Pgina 23 de 32
Pgina 24 de 32
Recolectar
Primero, debemos encontrar la herramienta que nos resulte ms cmoda para la
recoleccin 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 agnstico 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
ms, no importa en qu orden las escribamos; en este momento slo estamos
recolectando todo lo que est en nuestra cabeza.
Al terminar de recolectar todo lo que tenemos en la mente, vamos a sentir una
sensacin de tranquilidad que no tenamos antes, ya que podemos ver fsicamente
TODO lo que tenemos que hacer. Paso uno: cumplido, ahora:
Pgina 25 de 32
Pgina 26 de 32
Ejemplos:
Quiero aprender a hablar portugus: va para el Tal vez / algn da 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 soar con
hacer cosas diferentes.
Se va a casar mi exnovia: pa la basura.
Yordano viene para Panam: para la basura, tambin
En Language Center dan cursos de hablar Portugus - 226-1950: para Referencia
futura.
Pgina 27 de 32
Pgina 28 de 32
Pgina 29 de 32
Conclusin
La administracin de proyectos no es una ciencia oculta reservada para un grupo de
personas. Aunque nuestro rol en la organizacin no sea especficamente de
administrador de proyectos, hay cabida y gran valor en que adoptemos los principios
de la administracin de proyectos para organizar mejor nuestro trabajo, estructurar
nuestras tareas y tener una misin un poco mayor de lo que est pasando alrededor
nuestro y de la importancia de las tareas que nosotros desempeamos en el esquema
mayor del proyecto que estamos trabajando.
Si simplificamos la administracin de proyectos, nos damos cuenta que son una serie
de herramientas y mtodos 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, slo basta con hacer una lista de las tareas que
conforman un mini proyecto y darle seguimiento peridico. A nivel de un proyecto
para un cliente, podemos elaborar el WBS y Gantt, por ejemplo. Para un proyecto de
una corporacin, ser necesario una documentacin an ms estricta, como un acta
de proyecto, procesos de control de cambios, acta de cierre de proyecto.
Este documento busca presentar una introduccin bsica y escrita en un lenguaje
accesible al tema de administracin de proyectos. Pero es slo un aperitivo a un
mundo mucho ms amplio y rico que lo presentado en estas pginas. Si le pareci
interesante el tema, todava hay mucho que recorrer.
Pgina 30 de 32
Recomendaciones
Ningn proyecto es demasiado chico, podemos aplicar estructura y orden hasta en
el proyecto de renovacin 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 comunicacin y el manejo de expectativas es 75% de la administracin de
proyectos (a nuestro humilde concepto).
El administrador de proyecto debe ser un lder, no un mero administrador o jefe.
Debe motivar a su equipo de trabajo a cumplir las metas; no estar pisndole los
talones a la gente.
Recomendamos empowerment en vez de micromanagement. Esto se refleja desde
el momento de hacer los WBS.
El cronograma o grfica 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 revolucin del web y las redes sociales, se han desarrollado un gran nmero
de aplicaciones de colaboracin remota, administracin de proyectos y extranets
basadas en web. Aunque su equipo de trabajo no est geogrficamente disperso,
recomedamos el uso de alguna de estas aplicaciones para centralizar la
comunicacin y tener registro y documentacin de lo que se solicita y lo que se
entrega.
Pgina 31 de 32
Bibliografa
Alberto Lpez, PMP e instructor de cursos de administracin de proyectos. Gracias
por toda su paciencia, dedicacin, comentarios y experiencias que se ven reflejados
en este trabajo.
Sistemas de Informacin Gerencial - Administracin de la Empresa Digital. Kenneth
Laudon y Jane Laudon. Pearson Prentice Hall. 2008
A Guide to the Project Management Body of Knowledge (PMIBOK). PMI
Metodologa de Direccin de Proyectos. Alberto Lpez, 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
Pgina 32 de 32