Los 7 pasos para salvar un proyecto

Rev.1














2009






Jaime Videla, PMP


>:sWDW



Asunto Legal

2009 Jaime Videla, PMP
http://www.jaimevidela.cl
Este libro es propiedad intelectual.
Ninguna parte de esta publicacin puede ser almacenada en ningn sistema, transmitida o reproducida en
ninguna forma, incluyendo pero no limitado a, copia digital, fotocopia e impresin, sin el acuerdo previo y del
permiso escrito del autor.
El autor ha hecho el mejor esfuerzo para asegurar que ste libro sea de gran calidad, informativo y til. Este
texto es una nica recomendacin; el autor no puede asumir la responsabilidad por el actuar de las personas,
sus acciones u omisiones fsicas o morales, como resultado del material presentado aqu.
































>:sWDW





Para Eu y nuestras tres hijas





































>:sWDW




Indice


Pgina
Indice 4
Introduccin 5
Captulo 1 7
Glosario 8
Captulo 2 11
Las 7 principales causas del fracaso de proyectos 11
Causa 1 13
Causa 2 14
Causa 3 15
Causa 4 16
Causa 5 16
Causa 6 18
Causa 7 18
Captulo 3 19
Cmo enfrentar un problema 20
Los 7 pasos para salvar un proyecto 20
Paso 1 - Organizacin 21
Paso 2 - Objetivos 23
Paso 3 - Interesados 24
Paso 4 - Alcance 26
Paso 5 - Gestin 29
Plan de Gestin del Proyecto 31
Paso 6 - Riesgos 33
Paso 7 - Comunicacin 34
Captulo 4 36
Conclusiones 36
Bibliografa 38



>:sWDW




Introduccin


La quinta parte del producto interno bruto (PIB) de todo el mundo se
gasta anualmente en el desarrollo de proyectos. El ao 2009 esta cifra
ascendi aproximadamente a US$ 12.000.000.000.000. Cada punto
porcentual que descendi la utilidad promedio de dichos proyectos por
causa de una gestin de proyectos inadecuada, represent una prdida
equivalente al PIB de Chile de todo un ao.

Dicha prdida terica que puede parecer descomunal a primera vista, en
realidad resulta un plido reflejo de la cruda y amarga realidad a que se
ven enfrentados nuestros proyectos, porque la prdida real representa
VARIAS veces el PIB de Chile debido a que la utilidad de los proyectos
desciende mucho ms que un punto porcentual, en promedio. Estudios
llevados a cabo por empresas especializadas en investigacin de
mercado de proyectos IT indican que el ao 2006 el 70% de los
proyectos se desviaron de sus planes ms del 20% y que el 54%
sobrepasaron sus costos en ms del 20%
1
.

Esa situacin es extrapolable para todo tipo de proyectos debido a que
las causas que las generan son comunes y transversales a todos ellos.

l 1 C C
1 S C CPACS 8
>:sWDW



Para lograr un proyecto exitoso el gerente de proyecto (PM) debe saber
cmo dirigir un proyecto, y esto que parece tan obvio no es suficiente
para obtener el xito porque en la mayora de los casos existe una
brecha entre la forma terica de dirigir un proyecto y el manejo real. El
saber terico se debe complementar con el conocimiento situacional o
aplicado recopilado tanto de buenas como de malas experiencias
(lecciones aprendidas) de los innumerables gerentes de proyecto que
han agregado valor a la profesin de Project Management con su aporte
respecto a cules son los problemas ms comunes que causan el mayor
dao a los proyectos, y las frmulas exitosas que han puesto en prctica
para evitar o minimizar la ocurrencia de dichos problemas.

Ok.

Pero. por donde debemos empezar? Bueno, lo primero que tenemos
que hacer es reconocer que existe el problema. Y esto que suena tan
simple, en la prctica no lo es tanto, porque si hay algo que todos los
proyectos problemticos tienen en comn es un cierto grado de
negacin de que el problema existe.

Debemos determinar asimismo la causa raz del problema o problemas
que afectan nuestro proyecto. Eso lo veremos en el captulo 2.

Finalmente, poner en prctica uno o ms pasos de los 7 pasos para
salvar un proyecto. Es lo que veremos en el captulo 3.


>:sWDW





Captulo 1

Ocupados apagando "incendios" olvidamos
hacer proyectos rentables.


Para comenzar con nuestro trabajo debemos ponernos de acuerdo en el
lenguaje que emplearemos, esto es, el usado por quienes manejamos
proyectos, a fin de evitar malas interpretaciones. Gracias a las horas
dedicadas a la docencia, al estudio de la gestin de proyectos y al
manejo de proyectos estoy ms familiarizado con las definiciones que
entrega la Gua del PMBOK
2
, que es el estndar en gestin de
proyectos desarrollado por el PMI
3
.

Sera muy aconsejable que leyeras estimado lector todo el glosario que
se incluye al final del PMBOK. Si lo haces, puedes ahorrarte el resto de
este captulo y saltar directamente al inicio del captulo 2.

Para aquellos gerentes de proyecto o Project managers en ingls (PM)
que como t no tienen tiempo o que les pica la curiosidad por saber en
qu termina este captulo, a continuacin incluiremos un breve glosario
de gestin de proyectos.

M8Ck: Project Management Body of Knowledge, 4

th
Edition

Ml Project Management Institute

>:sWDW




Glosario

Acta de constitucin del proyecto (project charter): documento
formal en el cual se indica el nombre del proyecto, el PM responsable,
los objetivos del negocio y del proyecto, los recursos pre-asignados, los
principales interesados, sus requerimientos, entregables, restricciones,
mtricas y riesgos. Es firmado por la gerencia, el sponsor y el gerente
del proyecto, al menos.

Actividad: tarea o parte del trabajo que se debe realizar para llevar a
cabo un proyecto. Una o varias actividades conforman un paquete de
trabajo.

Alcance: la totalidad de los productos o servicios que se deben
acometer en el proyecto.

Calidad: el grado de cumplimiento de los requisitos del producto o
servicio.

Direccin de Proyectos: es la aplicacin de los conocimientos y
tcnicas a las actividades para atender los requisitos del proyecto.

Entregable: un producto o servicio verificable de una etapa o proceso.

>:sWDW



Estructura de desglose de trabajo (WBS): familia de paquetes de
trabajo organizada, que incluye todos los entregables del producto y del
proyecto. Usualmente toma la forma de un organigrama.

Gerente de Proyecto (PM): es el responsable designado por la
organizacin ejecutante para llevar a cabo el proyecto.

Interesados: son las personas y organizaciones involucrados en el
proyecto y/o cuyos intereses pueden verse afectados por el proyecto.

Paquete de trabajo: el nivel inferior en que se descompone una WBS.
Son la base para estimar el proyecto.

Proceso: serie de acciones sistemticas.

Producto: es un elemento o componente cuantificable.

Proyecto: es un emprendimiento para crear un producto o servicio
nico, de elaboracin progresiva y que tiene una duracin definida.

Riesgo: un evento incierto que al producirse tiene efectos positivos o
negativos en el proyecto.

Solicitud de Cambio: lo que se realiza para modificar el alcance del
proyecto, tales como modificar costos, cronogramas, etc.

>:sWDW



Valor Ganado: es el valor del trabajo ejecutado, en funcin del
presupuesto asignado, para una actividad de la estructura de desglose
del trabajo.
























>:sWDW





Captulo 2


"Cmo logra un proyecto atrasarse un ao?
-Un da a la vez
(Annimo)


Las 7 principales causas del fracaso de proyectos

Existe el proyecto perfecto?

Ese que atiende el alcance, concluye a tiempo y cuesta (menos de) lo
esperado? Cuya calidad es innegable; que deja feliz al cliente externo y
ms an al interno; y a los interesados, y cuyo equipo de proyecto
recibe premios por buen desempeo?

Quin de nosotros no se ha preguntado esto alguna vez? Quien ha
vivido esa grata experiencia?

Existe una clave para hacer proyectos exitosos?

Y mejor, cul es la clave?

La respuesta es categrica.
>:sWDW




Si.

Existe el proyecto perfecto. Y t como gerente de proyecto puedes
disfrutar de esa experiencia. Puedes gestionar proyectos perfectos.
Puedes conocer las claves de su xito.

Y mejor, puedes usar esa informacin para corregir o mejorar el
desempeo de ese proyecto que ests manejando y que te est dando
tantos dolores de cabeza.

Slo tienes que aplicar las claves del xito de proyectos.

Cules son esas claves?

Es lo que vamos a ver a continuacin.

Tal como el ttulo indica, en este libro nos enfocaremos en analizar los
pasos que debemos seguir para salvar un proyecto en problemas y
transformarlo en un proyecto exitoso. Los problemas pueden deberse a
una infinidad de razones. Para optimizar nuestro desempeo
aplicaremos la ley del economista italiano Vilfredo Pareto y estudiaremos
las causas ms comunes que hacer el mayor dao a la mayora de los
proyectos. A continuacin discutiremos la solucin a cada uno de esas
causas.

>:sWDW



Algunas de las causas ms comunes del fracaso de los proyectos son las
siguientes:

Causas ms comunes del fracaso de proyectos

i. Escaso apoyo de la organizacin ejecutante
ii. Objetivos de los proyectos difusos
iii. Deficiente atencin a/de los interesados claves
iv. Cambios de alcance/proyecto
v. Escasos conocimientos de gestin de proyectos
vi. Escasa gestin de riesgos
vii. Problemas de comunicacin


Causa 1 - Escaso apoyo de la organizacin ejecutante

No es suficiente con dotar al gerente de proyecto con las destrezas y
tcnicas apropiadas para el manejo del proyecto. Se requiere asimismo
que la organizacin est sensibilizada con la cultura de proyectos, que
empodere al PM, y que reconozca y entienda las reales necesidades y
obligaciones del proyecto. La organizacin ejecutante tiene prioridades
estratgicas que no siempre estarn alineadas con el proyecto y sus
objetivos, ocasionando una falta de apoyo que impactar negativamente
al proyecto.

Adicionalmente, la falta de apoyo de la organizacin puede ser un gran
problema para la bsqueda y disposicin oportuna de personal y
>:sWDW



recursos claves. No siempre es fcil obtener recursos y personal clave
que dependen de un gerente funcional fuera de la lnea de mando del
PM.

Si a lo anterior le sumamos un tardo requerimiento de recursos y/o
personal por falta de planificacin del PM y su equipo, se comprender
mejor el dao que causa al proyecto esta falta de apoyo.


Causa 2 - Objetivos de los proyectos difusos

Cmo llegar, si no sabemos a dnde vamos?

Adems, si los objetivos del proyecto no estn claramente indicados en
el acta de constitucin del proyecto (Project charter) se generar un
conflicto con los interesados o el cliente ocasionado porque el producto
del proyecto seguramente no estar a la altura de las expectativas de
los interesados.

Por otra parte, una mujer tarda 9 meses en tener un hijo, pero no es
posible que 9 mujeres juntas tengan un hijo en un mes. Si se ha
acordado formalmente un cronograma irreal o modificaciones al
cronograma que no son reales, el proyecto tendr que movilizar
recursos y personal extras para intentar cumplir con los compromisos.



>:sWDW



Causa 3 - Deficiente atencin a/de los interesados claves

Quines son los interesados claves? Son individuos u organizaciones
que estn activamente involucrados en el proyecto o quienes pueden
verse afectados por el. Son la gerencia, el patrocinador (sponsor), el
cliente externo, el equipo y el PM, entre otros.
No tomar en cuenta las necesidades o solicitudes del cliente, del sponsor
o del gerente funcional implicar serios problemas para el proyecto y su
PM por la influencia que aquellos poseen. Y los problemas no son
solamente de orden tcnico. Se ocasionan problemas de "egos

Con esto adems se sumarn cambios al proyecto y se desaprovechar
el conocimiento, bajar la calidad, no se considerarn todos los
requerimientos y aumentarn los conflictos.
Es ms, un deficiente manejo de las demandas cruzadas de los
interesados provocar una situacin de tensin que complicar an ms
el proyecto.

Por su parte, los interesados deben preocuparse tambin por el
proyecto. La organizacin tiene clara las relaciones entre distintos
proyectos? Cuenta con una oficina de proyectos (PMO) con la
responsabilidad, habilidad y autoridad para aportar una base
documental, establecer criterios, estndares y beneficios? Se hace
cargo la gerencia de los temas que afectan a proyectos relacionados?
Permite o da la gerencia independencia necesaria para el adecuado
manejo del proyecto? Esta carencia afecta negativamente el
desenvolvimiento del proyecto.
>:sWDW





Causa 4 - Cambios de alcance/proyecto

Este punto es quiz uno de los fciles de entender porque para muchos
resulta evidente que cambios al alcance que no son bien manejados
producen un dao directos al costo y plazo.

Un mal manejo del control de cambios implica costos y plazos extras
que impactarn negativamente al proyecto en caso de ocurrencia. Los
cambios de alcance pueden causar modificaciones de presupuesto,
plazos, servicios y entregables, junto con responsabilidades civiles y
legales extras.


Causa 5 - Escasos conocimientos de gestin de proyectos

El gerente del proyecto (PM) y su equipo conocen claramente sus roles
y responsabilidades? Este punto se refiere al know how que debe poseer
todo gerente de proyecto (PM) respecto al manejo de proyectos. En un
sentido holstico tiene que ver con el conjunto de conocimientos,
habilidades, herramientas y tcnicas de direccin de proyectos que el PM
ha acumulado a lo largo de sus aos de experiencia profesional y
vivencial, tanto desde un punto de vista terico como prctico.
El profesional debe planificar tambin su cultura de proyectos, buscando
trabajar en empresas o en proyectos que sean desafiantes, que le
>:sWDW



permitan obtener experiencia aunque sea desde la base de participar en
la segunda lnea de mando de los proyectos.

Muchos fracasos se deben a la falta de roce profesional del PM.

Debemos aclarar que una participacin de liderazgo en proyectos
complejos tambin es una fuente de fracaso, y en este caso el error es
cometido por la organizacin ejecutante que dispone del primer recurso
a su disposicin sin medir las consecuencias de la falta de experiencia.

Respecto al conocimiento terico, es importante que el PM conozca y
aplique las buenas artes, y que adems emplee las herramientas y
tcnicas que han sido probadas y que reflejan el estndar de la
industria.

Por otra parte tenemos una falta de adecuada planificacin.

Podemos buscar muchas razones para justificar esto. Proyectos que se
necesitan en forma urgente, plazos muy breves, necesidad de colocar
prontamente las rdenes de compra de servicios o suministros crticos,
otras tareas ms importantes o ms urgentes, etc., no te resultan
conocidas estas explicaciones?

Pero la importancia de planificar primero y ejecutar despus ser una
verdad contra la cual nos estrellaremos tarde o temprano.


>:sWDW



Causa 6 - Escasa gestin de riesgos

En todos los seminarios y talleres que he dictado para profesionales con
experiencia en manejo de proyectos que desean certificarse como
profesionales PMP hago la pregunta de rigor: Cul es el asunto que
debe estar siempre y en primer lugar en la agenda de reunin de
revisin de proyecto?

Unos responden que es el avance del proyecto; otros, el cronograma;
algunos indican que son los costos, o el estado de los entregables. Salvo
contadas excepciones no se menciona el tema del riesgo. Esta gravsima
omisin es una de las responsables principales del fracaso de los
proyectos.

Espera lo mejor, pero preprate para lo peor.


Causa 7 - Problemas de comunicacin

No identificar a todos los interesados claves se traduce en una falta de
comunicacin con ese interesado, ocasionndose un impacto negativo
sobre el proyecto a causa de su influencia.
Adems, si no se asegura un comn acuerdo y entendimiento relativo a
las formas, contenido y calendario de las comunicaciones con los
interesados claves se producirn problemas de "egos que provocarn
serios inconvenientes al proyecto.

>:sWDW





Captulo 3


"Dadme un punto de apoyo y mover el universo
(Arqumedes de Siracusa, siglo 3 A.D.)


Hemos identificado en el captulo anterior los principales problemas que
pueden afectar a los proyectos. Veamos a continuacin cuales son los
pasos que debemos seguir para salvar un proyecto en problemas. Si nos
fijamos en los 7 problemas que resumimos al comienzo del captulo 2
podemos notar que hemos puesto en "negrita algunas palabras:

i. Escaso apoyo de la organizacin ejecutante
ii. Objetivos de los proyectos difusos
iii. Deficiente atencin a/de los interesados claves
iv. Cambios de alcance/proyecto
v. Escasos conocimientos de gestin de proyectos
vi. Escasa gestin de riesgos
vii. Problemas de comunicacin

Estas palabras y conceptos son los que nos ayudarn a descubrir los
pasos que debemos seguir para llevar a cabo un proyecto con xito, o
en el caso ms general, para enmendar el rumbo y salvar un proyecto.

>:sWDW




Cmo enfrentar un problema

Este sistema es una de las mejores tcnicas de resolucin de problemas
al interior del proyecto. Es muy importante. Vital. Si la conoces, por
favor aplcala. Si no la sabes, por favor memorzala.

Lo primero que debemos hacer como PM al enfrentar un problema es:

1. determinar el impacto que dicho problema tiene sobre el proyecto,
es decir, el efecto sobre el alcance, costo, plazo, calidad, etc.
2. buscar conjuntamente con el staff las alternativas de solucin del
problema.
3. plantear formalmente al cliente interno el problema junto con la
alternativa de solucin encontrada, quien dar o no su aprobacin.
4. Por ltimo, si el proyecto lo amerita, obtener aprobacin del
cliente externo.


Los 7 pasos para salvar un proyecto

Otro asunto que debemos recordar es que NO todos los pasos que
expondremos aqu son necesarios para salvar un proyecto. Cada
proyecto tiene su propia circunstancia y podra ser necesaria la
aplicacin de slo uno de estos pasos para corregir un proyecto. En un
caso particular podra ser necesario atender los 7 pasos.
>:sWDW



Dependiendo del grado de avance del proyecto y de la experiencia del
PM y de su staff, es perfectamente factible salvar un proyecto que deba
dar los 7 pasos.


Paso 1 - Organizacin

Conseguir el apoyo de la organizacin ejecutante es esencial para el
xito del proyecto. Es tan importante este punto que repetimos:
Conseguir el apoyo de la organizacin ejecutante es esencial para el
xito del proyecto.

Una vez que el sponsor de la organizacin firma el project charter
formalizando el inicio del proyecto, la organizacin y la gerencia
deberan prestar todo su apoyo al proyecto. Ese apoyo puede estar
condicionado a las prioridades estratgicas de dicha organizacin, las
cuales no siempre estn alineadas con las prioridades del proyecto.

En la eventualidad que las prioridades estratgicas de la organizacin no
coincidan con las del proyecto y el PM no encuentre respaldo en la
organizacin para llevar a cabo los servicios que le fueran
encomendados, es su responsabilidad plantear formalmente y de
inmediato al sponsor dicha situacin y registrando en un acta de reunin
firmada por los presentes el planteamiento y las decisiones que fueron
tomadas.
El grado de apoyo que la organizacin ejecutante decida brindar al
proyecto en funcin de su plan de negocio pasa a ser a partir de dicho
>:sWDW



instante un parmetro del proyecto que condicionar en ese mismo
grado el xito del proyecto.
Un proyecto que cuenta con cero grado de apoyo de la organizacin
ejecutante no puede pretender ms que un cero de xito del proyecto.
Por otra parte, un proyecto que cuenta con un 100% de apoyo, espera
con razn que el proyecto cumpla con todas sus expectativas. Lo mismo
aplica para una posicin intermedia.
El problema queda as resuelto.

Un caso particular de este paso es la necesidad de apoyo para obtener
recursos y personal claves. El procedimiento que tenemos que aplicar en
ese caso es el mismo que ya describimos arriba. Tenemos que plantear
formalmente y de inmediato al sponsor dicha necesidad de recursos y/o
personal clave. Nuevamente se registra en acta firmada el
planteamiento y las decisiones tomadas. El grado de apoyo pasa a ser el
parmetro del grado de xito. El primer paso para salvar el proyecto se
ha dado con xito.

Desde el punto de vista de la organizacin es importante destacar que
tanto la necesidad de apoyo como la necesidad de recursos y personal
deben efectuarse en forma oportuna. De nada sirven las solicitudes
extemporneas sobre hechos consumados. Esta oportunidad debe ser
resuelta a la mayor brevedad.

La buena noticia aqu es que quien debe dar la alarma es el PM, es
decir, nosotros. Como nosotros sabemos dar esa alarma en forma
oportuna, el problema aqu tambin est resuelto.
>:sWDW





Paso 2 - Objetivos

Ante todo debemos indicar que en este punto en particular cuando
decimos "objetivos nos referimos en su forma ms amplia a los
objetivos, alcances, plazos, etc., y restricciones del proyecto.

Cmo conocer con suficiente grado de profundidad los objetivos?

Respuesta: desarrollando el WBS en forma conjunta con el staff.

Ya vimos que el charter debe incluir claramente los objetivos del
proyecto, entre otros asuntos. La buena noticia aqu nuevamente es la
siguiente: no obstante que es en el charter que se asigna al PM, en la
generalidad de los casos es el mismo PM quien edita dicha acta de
constitucin, lo cual significa que los objetivos del negocio y del
proyecto, los requerimientos, entregables y restricciones han sido
definidos all claramente por el PM, con lo cual el problema de los
objetivos difusos desaparece.

En el supuesto caso que el PM detectare problemas de objetivos poco
claros con posterioridad a la firma del Acta, deber actuar como se
expuso en la primera parte de este captulo: detectando el problema y
su impacto, buscando las soluciones y alertando al cliente interno (y
externo). De esa forma se acta sobre el charter emitiendo una revisin
formalmente aceptada. Se resuelve as el problema.
>:sWDW




En el caso que la organizacin haya cambiado al PM con posterioridad a
la firma del charter, el nuevo project manager tendr que conocer dicha
acta y estudiarla junto a todos los documentos contractuales. En dicha
oportunidad tendr la posibilidad de detectar cualquier problema de
indefiniciones, en cuyo caso deber actuar como ya indicamos:
detectando el problema y su impacto, buscando las soluciones y
alertando al cliente interno (y externo). De esa forma se acta sobre el
charter emitiendo una revisin formalmente aceptada. Se resuelve as el
problema.

Un caso particular que debemos mencionar es la importancia de
determinar si se ha asignado uno o varios proyectos al PM. El problema
no radica en determinar si el PM y su equipo tienen disponibilidad para
atender varios proyectos. Ello no es problema porque el PM y su staff
verificarn la factibilidad de cumplir dicho requerimiento y formalizar
su aceptacin o rechazo a la gerencia. Aqu la clave est en determinar
si se trata de uno o ms proyectos.
Dos o ms proyectos pueden perfectamente manejarse, pero la clave es
manejarlos como proyectos independientes, con sus propio Charter,
WBS, etc.


Paso 3 - Interesados

Nuevamente una buena noticia. La solucin al problema de atencin a
los interesados est en manos del PM. Qu significa esto? Significa que
>:sWDW



el problema tiene una solucin casi inmediata. No importa que avance
tenga el proyecto en ese momento. No obstante, insistimos en sealar
que mientras ms temprano se acte para enmendar un proyecto, ms
fcil y productiva ser la solucin.

En este paso, lo primero que debemos hacer es descubrir si hemos
dejado de lado algn interesado clave. Para ello revisamos la
informacin existente en nuestro proyecto. En el supuesto caso que no
tengamos compilada dicha informacin procederemos a reunirla
empleando para ello los formularios del Registro de Interesados con que
cuenta la Oficina de gestin de proyectos (PMO).

Antes de continuar es importante destacar aqu que si tu empresa no
tiene una PMO es muy aconsejable que sea creada. Dicha oficina se
encarga entre otras cosas de coordinar diferentes proyectos, mantener
la biblioteca de procedimientos y estndares corporativos, normas,
formularios, protocolos y mtricas; mantener la documentacin de los
proyectos, lecciones aprendidas, etc.; promover los mtodos y procesos
de planificacin y control; ser el nexo del proyecto con la alta gerencia y
supervisar el desarrollo de los proyectos. Existen empresas en el
mercado local que te pueden ayudar a implementar esta oficina, o
puedes contar con nuestros servicios, envindome un correo a la
direccin contacto@jaimevidela.cl

Continuemos. Ya vimos que los interesados claves son los individuos u
organizaciones que estn activamente involucrados en el proyecto o
quienes pueden verse afectados por el. Una vez identificados todos los
>:sWDW



interesados claves debemos actuar proactivamente para conocer sus
requerimientos y expectativas respecto del proyecto, y saber con qu
frecuencia y en qu grado requieren recibir informacin relativa al
proyecto. Para ello, con el Registro en mano procedemos a solicitar
reuniones con cada uno de los interesados claves. Podremos as
balancear adecuadamente los intereses de los interesados y atender y
hacer seguimiento a sus requerimientos.

Cabe destacar que el PM tambin es un interesado, y como tal deben
ser satisfechas tambin sus requerimientos y expectativas. Si ello no
ocurre, es deber del mismo PM acudir a la gerencia para proactivamente
buscar solucin a sus inquietudes. Cmo lo hace? Aplicando lo indicado
en el Paso 1.


Paso 4 - Alcance

El control que se obtiene sobre el proyecto al aplicar lo que indicaremos
a continuacin en este Paso 4 es una de las razones que me impuls a
escribir este libro. Al comienzo de mi vida profesional me vi enfrentado a
varias situaciones de "gold plating de proyectos, esto es, a "tener que
ejecutar servicios o requerimientos del cliente que estaban fuera del
alcance del proyecto. Es evidente que cualquier suministro o servicio
que ejecutemos que no haya sido considerado impactar negativamente
los plazos, o lo que es peor, los costos del proyecto. Estoy seguro que a
ti amigo lector te pasa o te ha ocurrido algo muy similar.

>:sWDW



Es necesario puntualizar aqu que por "alcance nos referimos en este
punto a los cambios que se solicitan o experimentan durante el
transcurso del proyecto respecto del Project charter. Fundamentalmente
nos referimos a cambios de alcance y plazo del proyecto.

Pues bien, cmo resolvemos este cambio de alcance? Y mejor, cmo
lo solucionamos sin entrar en conflicto con nuestro cliente? Lo primero
que debemos entender es que el conflicto es inherente a nuestra
profesin, lo cual significa que la forma de resolver las modificaciones de
alcance no es evitando el conflicto, sino que por el contrario
enfrentndolo proactivamente.

El mtodo probado ms efectivo en este caso es obtener un profundo
conocimiento del alcance del proyecto mediante el desarrollo de la WBS
con nuestro equipo. El tiempo y costo gastado desarrollando dicha
herramienta es lejos la mejor inversin que puede hacer un PM para su
proyecto. Recordemos que la WBS incluye todos y slo todos los
servicios y entregables materia del proyecto en cuestin.

Si el proyecto est en desarrollo y la WBS no ha sido creada an, es lo
primero que debes hacer para resolver el problema relativo al alcance.
Posteriormente, se debe contrastar los servicios desarrollados o en
ejecucin con los servicios agrupados en la WBS. Los servicios que estn
en la WBS pero que no hayan sido contemplados an por el proyecto
deben ser atendidos con la prioridad que dicha situacin amerite. Los
servicios que estn en ejecucin pero que no forman parte de la WBS
deben ser nuevamente estudiados para asegurar que no se cometi un
>:sWDW



error al desarrollar la WBS. Si se verifica que dichos servicios no forman
parte del alcance del proyecto, su ejecucin debe ser interrumpida de
inmediato, dando oportuno aviso de ello al cliente interno o externo.

Se procede a continuacin a evaluar el impacto del cambio, a buscar las
alternativas y a comunicar formalmente al cliente. Si nos ponemos por
un momento en el lugar del cliente nos daremos cuenta que al cliente le
gustara conocer lo ms oportunamente posible cualesquier situacin de
cambio que afecte al proyecto y a sus intereses. Adems, si
reconocemos que el actuar del cliente es tan tico como el nuestro,
tampoco querr recibir un producto o servicio que no ha solicitado o no
ha cotizado formalmente o por el cual no tendra que pagar nada, salvo
en el caso que nuestra organizacin est dispuesta a asumir
formalmente dicho impacto.

Lo que resta es negociar para ponerse de acuerdo con el cliente
respecto al alcance, costo y plazo de los cambios. La mejor manera es
trasparentar toda la informacin disponible y sus costos, incluidas las
utilidades que por derecho le corresponde a la organizacin ejecutante.
Existen tcnicas de negociacin que pueden ayudar al PM a sensibilizar
al cliente respecto a los cambios de alcance y sus repercusiones.
Tambin hay buena y variada literatura. Si necesitas ayuda al respecto
no dudes en contactarme. Nuestro grado de calidad de servicio lo
demostramos desde el primer instante brindando 30 minutos de
asesora gratuita a nuestros prospectos.


>:sWDW



Paso 5 - Gestin

Este paso es el ms difcil de dar, porque se refiere a la falta de
experiencia y/o conocimientos tcnicos del gerente de proyecto.

Un sabio refrn seala que 100 gacelas lideradas por un len son ms
peligrosas que 100 leones liderados por una gacela.
Un equipo inexperto puede hacer maravillas si el lder del proyecto es un
PM con experiencia terica y prctica. Lamentablemente lo contrario no
aplica. Un equipo experimentado no llega lejos si el gerente del proyecto
no domina la gestin profesional de proyectos.

Cules son los conocimientos y habilidades que debe poseer un PM?
Debe ser un especialista de la disciplina? En particular pienso que es
preferible que el gerente de proyecto domine varios temas con un cierto
grado de profundidad a que domine un solo tema a fondo. Las
habilidades "soft son asimismo vitales al momento de interrelacionarse
con los interesados y para monitorear la labor de los miembros de su
equipo de trabajo y/o negociar las ordenes de cambio. Veamos la
siguiente lista:

gestin de proyectos
conocimientos tcnicos de la industria
financieros
herramientas de monitoreo y control
tcnicas de gestin de procesos
manejo de conflictos
>:sWDW



de negociacin
capacidad de gestin en funcin de objetivos
saber qu comunicar y a quienes
poder de delegacin
formacin de equipos
de recompensa
liderazgo
gestin poltica
manejo de riesgos y prevencin de problemas
saber motivar al equipo
saber influir en us organizacin
innovador
saber priorizar temas
organizacin del proyecto y del equipo

Si quieres profundizar ms al respecto, te sugiero leer el PMBOK o
algunos de los libros electrnicos que ofrecemos en nuestro sitio web
www.jaimevidela.cl

La clave para iniciar este paso son los procesos. Los procesos de
direccin de proyectos han sido diseados para proyectos cuyo
presupuesto supera el milln de dlares, con una duracin mnima de un
ao y que requiere un staff de al menos 20 personas. En el supuesto
caso que tu proyecto sea de menor envergadura a lo anteriormente
indicado, es muy probable que no requiera cumplir con todos los
procesos de gestin que las buenas artes aconsejan. No obstante, hay
procesos que no pueden ni deben ser soslayados por el PM si quiere
>:sWDW



tener xito con su proyecto. An cuando el objetivo de este libro no es
profundizar sobre cuales procesos deben ser atendidos para ejecutar un
proyecto en tiempo y forma, no podemos dejar de mencionar que
muchos proyectos fracasan por no haber emitido un charter, no haber
ejecutado la WBS, no tener un sistema de control de cambios, y no
tener un plan de gestin del proyecto que incluya un plan de
comunicaciones y de riesgos, entre otros, y que sea formalmente
aceptado por el sponsor y la organizacin.

Plan de Gestin del Proyecto

El otro aspecto importante a considerar es la adecuada planificacin del
proyecto. Sin un plan definido puedes por cierto llegar a alguna parte
menos a donde quisieras llegar. El PM junto a su staff debe realizar un
Plan de Gestin del Proyecto. Este plan de gestin explica como el PM
estimar, planificar, manejar y controlar el proyecto. Este plan es
una de las herramientas ms poderosas que tiene el PM para lograr un
desempeo impecable.

Qu debemos considerar? Qu nos debemos preguntar para hacer el
plan? Respuesta: Cules son los requerimientos? Quines deben
involucrarse? Cmo saber si los entregables estn listos? Cules son
los roles y responsabilidades? Cul es el alcance, tiempo, costo, plazo,
etc, del proyecto? Qu trabajos adicionales al proyecto debe hacer el
PM y el staff para cumplir con el proyecto? A quienes comunicar el
estado del proyecto? Cmo controlar los costos? Cmo minimizar los
costos? Quines son los interesados? Qu procesos debemos realizar?
>:sWDW



Cmo controlaremos los cambios? Quines autorizarn los cambios?
Qu planes de respuesta a los riesgos tenemos? Etc., etc.

El plan de gestin debe incluir al menos los siguientes sub-planes:
Plan de gestin de alcance
Plan de gestin de tiempo
Plan de gestin de costo
Plan de gestin de calidad
Plan de gestin de RRHH
Plan de gestin de comunicaciones
Plan de gestin de riesgo
Plan de gestin de adquisiciones
Plan de gestin de cambios
Plan de mejora de procesos

Si el plan de gestin no es realizado en la etapa de planificacin, para
un proyecto ya en desarrollo debe ser desarrollado de inmediato! La
profundidad con que se tratan cada unos de estos planes depender de
la envergadura del proyecto.

El segundo aspecto a considerar aqu son los procesos de monitoreo y
control. Nos referimos al adecuado seguimiento a los paquetes de
trabajo para verificar que los entregables se ejecuten en tiempo y
forma. De lo contrario se pierde valioso tiempo del proyecto en
correcciones o en rehacer servicios. Esta labor debe ser realizada por los
miembros del equipo del proyecto, y el trabajo del staff debe ser
>:sWDW



supervisado por el PM. As, el PM se asegura de enfocar adecuadamente
los esfuerzos del equipo en donde realmente se requiere.

El plan establece tambin las mtricas y las lneas base contra las cuales
se podr comparar los entregables.


Paso 6 - Riesgos

Tal como vimos en el paso anterior, como parte del Plan de gestin del
Proyecto se incluye el plan de gestin de riesgos. Hemos dejado el
riesgo aparte, con su propio Paso, debido a la enorme importancia que
tiene el tema del manejo del riesgo en los proyectos. Hemos
anteriormente sealado la escasa o nula importancia que las
organizaciones, el staff y el PM le dan normalmente al tema del riesgo.
No nos referimos a que se desconozca el tema del riesgo. No. Nos
referimos a que no existe una cultura organizacional que maneje en
forma profesional y sistemtica el tema del riesgo.

En consecuencia, basta con activar los procesos y el plan de gestin de
riesgos y poner el asunto del riesgo en el lugar que le corresponde: el
primer lugar, para que se origine un cambio notable en la calidad de
gestin de los proyectos.

No vamos aqu a enumerar la gran cantidad de documentos,
formularios, grficas de control, sistemas y bibliografa que existe al
>:sWDW



respecto. Basta con sealar el principal beneficio del manejo de riesgos:
el ahorro de tiempo, que implica menor gasto de recursos y dinero.

Cmo vamos a determinar los riesgos y sus impactos? Nuevamente nos
dirigimos al WBS y sus paquetes de trabajo. Esta menor unidad de
servicio nos permite determinar los eventos positivos y negativos y sus
impactos.


Paso 7 - Comunicacin

Hemos dejado para el final este paso porque las comunicaciones son el
problema nmero uno de los proyectos. Por suerte para nosotros es
muy simple de resolver este problema.

Seguro que te ha ocurrido que has preferido enviar un correo en vez de
reunirte o conversar con alguien. Esta actitud de escoger anticipar una
explicacin o excusa a futuro en vez de gastar tiempo y resolver
adecuadamente y de inmediato un asunto hoy, forma parte de los malos
hbitos del manejo de proyectos que podemos y debemos evitar.

El plan de manejo de las comunicaciones es la principal herramienta
para combatir y resolver este problema.

Es bueno destacar que no todos los interesados deben o quieren recibir
el mismo nivel de informacin del proyecto.

>:sWDW



Cul es el beneficio inmediato del Plan de comunicaciones? Disminuir
los conflictos, definir los responsables de las comunicaciones, la cantidad
y calidad de informacin y a quienes va dirigida. Minimizar los
problemas de comunicaciones.

Los Project managers gastan el 90% de su tiempo comunicando, segn
el PMI, con lo que estamos plenamente de acuerdo.




















>:sWDW





Captulo 4


"No te tomes tan en serio la vida; al fin y al
cabo, no saldrs vivo de ella


Conclusiones

Si quisiramos resumir en pocas palabras lo que tenemos que hacer
para salvar un proyecto en problemas, podramos usar las siguientes:

"Reconozcamos que el problema existe. Busquemos la causa
raz. Planifiquemos la solucin en equipo y pongmosla
proactivamente en prctica. No menospreciemos a los
interesados o a las circunstancias y busquemos ayuda en juicio
experto"

Muvete! Planifica! Evala! Pide ayuda! Invierte! Agradece!

No temas equivocarte de camino. Lo importante es contar con un plan
del proyecto y avanzar para cumplirlo. Si te desvas, bueno, es cosa de
corregir el rumbo.

>:sWDW



Espero que el tiempo que has invertido en la lectura de este libro te
sirva amable lector para elevar el nivel del desempeo de tus proyectos,
para beneficio de nuestro pas, nuestras organizaciones, nuestros
equipos de trabajo y de ti mismo.

A mi pesar debo reconocer que no todo lo que digo aqu es
verdaderamente cierto. Tuya es la responsabilidad de descubrir los
desaciertos y perfeccionar estos conocimientos que son fruto de la
experiencia participando activamente o dirigiendo proyectos que
sumados superan los 222 millones de dlares.

Si tienes algn comentario que hacer te agradecer enviarme un correo
electrnico a: contacto@jaimevidela.cl Estar encantado de compartir
conocimientos y experiencias que nos engrandezcan.













>:sWDW




Bibliografa

Advertising Secrets of the Written Word, Joseph Sugarman
Confidential Internet Intelligence Manuscript, Mark Joyner
El rbol del conocimiento. Francisco Varela, Humberto Maturana
Managing Oneself, Peter Drucker
McKinsey Quarterly, Diversos artculos
PMNetwork magazine, Noviembre 2008
PMP Exam Prep. Quinta edicin, Rita Mulcahy
Seven Habits of Highly Effective People, Stephen R. Covey
Successful negotiating, Grant E. Mayberry
The Gartner Group, Diversos artculos
The PMBOK Guide, 4th Edition (2008), PMI
Theory Z: How American Business Can Meet the Japanese Challenge.
Ouchi, William
This I Believe! - Tom's 60 TIBs, Tom Peters