capitulos 1 y 2 del libro de hallows

1. Equipo 10:
NIÑO SUAREZ VERONICA
USCANGA COLUNGA BRENDA YURIDIA

2.  En el capítulo 1, quot;Introducciónquot;, quot;El papel de
una Oficina de Gestión de Proyectosquot; se refiere
a un nuevo componente de la gestión del
proyecto y cómo se puede promover la
disciplina de gestión de proyectos. La sección
quot;Gestión y Participaciónquot; se describe cómo
evitar las trampas en la gestión de los
proyectos cuando no son sólo el director del
proyecto, sino también un equipo participante.
Esta sección también se ocupa de las
cuestiones en la gestión de múltiples
proyectos.
 Capítulo 2, quot;Comprensión del proyecto,quot; . quot;La
iniciación del proyecto.quot; Conseguir un proyecto
iniciado correctamente es una de las claves
para gestionar correctamente, y esta sección
se describe lo que un buen proyecto debe
implicar proceso de iniciación.

4. Felicidades. Se le ha dado su propio proyecto a

ejecutar. Si usted es como la mayoría de los
directores de proyectos, que es parte de eufórica que
su empresa le ha confiado una importante
misión, mientras que el resto de ustedes está
petrificado que pronto descubrirá la magnitud de su
error.
Si el proyecto es el primero y se le está quot;probandoquot;, o

que ha estado haciendo esto por años, pero nunca en
un proyecto de este tamaño, este libro está diseñado
para usted. Espero que te sean útiles.
Su contexto y las limitaciones son diferentes de los

de la línea de gestión, pero su preocupación es la
misma: dirigir un grupo de personas para lograr un
objetivo. Por lo tanto, los administradores de
proyectos necesitan saber cómo manejar
presupuestos, personas y procesos.

5.  Existencinco características hacen único el
contexto de la gestión de proyectos:
La responsabilidad sin autoridad

Su fuente de energía

Transitoriedad del Proyecto

La observación de que usted obtenga lo que

quiere conseguir
La necesidad de herramientas y técnicas

especializadas.

6. Como un director de proyecto, usted es responsable

de un proyecto. Si no cumple con su presupuesto, el
calendario, o las expectativas, que son los que
tendrán que rendir cuentas y que, como
mínimo, sufrirá la presión de la gestión y recibirá una
evaluación de la actuación profesional desfavorable.
Llevar el objetivo en un proyecto requiere de

recursos: las personas, equipos y servicios de apoyo.
Sin embargo, con raras excepciones, los directores de
proyectos no comandan sus recursos.
Usted no puede asignar arbitrariamente al personal a

sus proyectos, la adquisición de equipo como lo
necesite, contratar a personas, o el lugar a sus
necesidades en la parte superior de la lista de
prioridades empresariales. Usted no puede promover
o degradar incluso personal. Esas prerrogativas
pertenecen a los supervisores y los directivos.

7. El director del proyecto, a pesar de la falta de

autoridad formal, lleva consigo una posición de
poder considerable para los gestores de
proyectos que estén dispuestos a ejercerla.
 La fuente de poder es la realidad que el director
del proyecto es el único capaz de ofrecer valor
al proyecto, sin un director de proyecto, el
proyecto se encuentra en peligro extremo. El
ejercicio de este poder es el que el gerente del
proyecto está dispuesto a retirarse de un
proyecto en condiciones extremas.
 Hablando claro, usted tiene el derecho y la
obligación, para decir a un cliente o para su
gestión, quot;Este proyecto no puede tener éxito en
estas condiciones, y hasta que cambie, no voy a
continuar.quot;

8.  Los equipos ejecutan proyectos los proyectos
no los directivos.
 Una de sus principales tareas es la creación
de equipos. También es el caso de la línea de
gestión, pero la diferencia es que mientras
perduren los departamentos, los proyectos
son de carácter temporal.
 Usted debe solicitar la creación de equipos
un grupo de personas con habilidades que
pueden no tener compromiso con el
proyecto.

9. La gestión de los proyectos tiene su propio conjunto de

herramientas y técnicas. Conceptos tales como estructura de
desglose de trabajo, nivelación de recursos, y la finalización se
estima en gran medida desconocida fuera de la disciplina.
Técnicas, tales como diagramas de Gantt o análisis del camino

crítico, se han convertido en algo común en los negocios y se
utilizan en general la práctica empresarial como en la gestión de
los proyectos oficiales.
Además, es necesario que las mismas herramientas y técnicas

sean utilizadas por todos los buenos gerentes. Si usted es un
gerente de proyecto o de una jerarquía superior, lo que necesita
conocer es: marco de resultados, gestión de reuniones, reunir
información, construir equipos, comunicar y gestionar su tiempo.
Estas cinco características hacen que la gestión de los proyectos
requiera, la gestión de más habilidad que la mayoría de la línea
de gestión.
La gestión de proyectos es una disciplina que requiere su propia

aptitud, normas, y formación.

10. Un proyecto exitoso es aquel que ofrece los

resultados esperados.
 Estos incluyen tradicionalmente un
presupuesto, un calendario, y un ámbito de
quot;triple limitacionesquot; de la gestión de proyectos.
Todo proyecto que cumpla con estas medidas
es, por esta definición, un éxito. De
hecho, muchos gestores de proyectos se
consideran exitosos si son capaces de golpear a
dos de los tres.
Sin embargo, el presupuesto, cronograma, y el
alcance son técnicas que definen la forma
métrica y como fue gestionado el proyecto. Que
tienen poca relación con las preocupaciones
reales del cliente.

11. Una empresa con $10 millones presupuesto un

inventario de $100.000 para un sistema de control de
inventario, con la esperanza de reducir el inventario
en un 20%, o $2 millones. En el 10% de interés, el
sistema hace un recorte de costes de $200.000 por
año. El proyecto sufre un 100 por ciento de los
sobrecostos.
Si la empresa no aplica el sistema o lo hace pero no

para reducir su inventario, ha perdido 200.000
dólares-del costo presupuestado más el
rebasamiento.
Pero si la empresa no aplicara el sistema de

inventario y los cortes como se esperaba, se
recuperara el costo de ese rebasamiento en apenas
seis meses, y se pagará por todo el sistema en un
año. Esto no es raro: Los beneficios de un sistema
normalmente supera incluso devastadores
sobrecostos. El alcance es que el sistema y los
beneficios realizados deben aplicarse.

12.  Elmás comúnmente culpable es la mala
estimación.
 Existen tres motivos recurrentes que los
proyectos fracasan:
Cambios de alcance,

La mala planificación del proyecto

La tecnología.


13. Una medida de las posibilidades de éxito de

cualquier proyecto es el medio ambiente para la
gestión de proyectos dentro de la organización.
 Muchas empresas simplemente parten de
proyectos a ejecutar y esperan que las cosas se
vallan a trabajar fuera, o al menos que tengan
un conveniente chivo expiatorio.
 Las empresas en las que los proyectos tienen
más probabilidades de éxito son aquellas que
han establecido estructuras y
procedimientos, similares a los siguientes, con el
apoyo de sus directores de proyectos.

14. ¿Qué requisitos para la presentación de informes del

estado del proyecto se establecen a los administradores de
proyectos? ¿A quién van los informes sobre la situación?
¿Con qué frecuencia? ¿Qué tiene que decir? ¿Qué
seguimiento se llevará a cabo sobre las cuestiones
planteadas en los informes de situación? ¿Por quién?
Hasta que estas preguntas son respondidas, la situación

será la presentación inadecuada de informes ad hoc. La
existencia de buenas normas de información es un indicio
de que la administración se preocupa por el avance de los
proyectos y, en consecuencia, está dispuesta a ayudar
cuando sea necesario.
Otro componente de los informes de estructura es la
escalada procedimientos. Cuando los problemas van
aumentando, ¿cuál es el procedimiento para hacerlo?
¿Quién debe abordar la cuestión? ¿Cómo? ¿Con qué
expectativas?
Las empresas que han definido los procedimientos de
escalada reconocen algunas cuestiones que requieren la
intervención de alto nivel y han definido un mecanismo
para proporcionarlas.

15. Las empresas cuenta la gestión de proyectos como

una importante responsabilidad para las personas. Se
aseguran de que los directores de proyectos tienen
una clara y conveniente de carrera que incluye la
formación, los criterios de promoción, el
reconocimiento de los logros, y la oportunidad de
progreso a los más altos ejecutivos niveles en la
organización.
Además, estas empresas, por su reconocimiento de

la gestión del proyecto, reconocen que la gestión de
proyectos es una disciplina, que es necesaria, y que
es digna de fomento. Estas son las empresas que, a su
vez, atraen, desarrollan y retienen a los mejores
profesionales de la gestión de los proyectos y las
capacidades disponibles.

16. Cuando la gente habla de los

proyectos, normalmente significa que es
largo, caro, evidente, son las decenas de
características que distinguen a un sistema de
desarrollo de proyectos.
 Algunos dirán que estos no requieren de un
cierto nivel de gestión. ¿Pero qué pasa con las
pequeñas actividades, las que obviamente no son
tan arriesgados o crítica a la organización?
¿Cuando se hacen estos proyectos que requieren
la atención de un director de proyecto?

17. El anexo 1.1 proporciona un conjunto de criterios y

una lista de verificación que debe ayudar a dar una
respuesta.
Las actividades involucran a más de dos personas.
Las actividades se requieren más de dos semanas
de esfuerzo.
Las actividades se requieren más de un
mes, transcurrido el tiempo.
Las actividades implican un riesgo.
Si fracasan las actividades, habrá un impacto
significativo.
Las actividades requieren la coordinación de dos o
más departamentos.
Las actividades implican socios de fuera.
Las actividades se involucran nuevas tecnologías.
Las actividades quedan fuera del alcance de las
operaciones normales.
Si dos o más casillas son comprobadas, las actividades son un proyecto. Puede que
no sea grande, ni podría ocupar gran parte del tiempo de un experimentado gestor
de proyectos, pero si no se gestionan adecuadamente, la empresa está en algún
grado de riesgo.

18. Hasta hace poco, la mayoría de las organizaciones de

gestión de proyectos eran tratadas como si la gestión
de los proyectos fuera una cuestión de preferencia
individual.
Las organizaciones han llegado a apreciar que existen

dos principales problemas con este enfoque:
La gestión de proyectos es una disciplina. Aquellos que
1.
no hagan uso de los principios de la disciplina se verán
en una lucha de proyectos y, a menudo un colapso. Por
lo tanto, la eficacia de la gestión de proyectos es tan
irregular como las variaciones en la formalidad.
Cuando los directores de proyectos se transfieren a
2.
otro proyecto o salen de la organización, es
sumamente difícil para sus reemplazos que se hagan
cargo de todo, porque la documentación del proyecto
se ajusta a las preferencias personales del gestor, en
lugar de a un nivel de organización.

19. Algunas organizaciones, intentan crear

normas, metodologías de compra para proporcionar
la estructura y coherencia a los proyectos. Una vez
más, sin embargo, las buenas intenciones son
víctimas de tres problemas:
La mayoría de estas metodologías se centran en las
1.
actividades de los proyectos propios, como el
desarrollo, cómo los proyectos se gestionan. Como
tal, su utilidad en el establecimiento de normas de
gestión de proyectos es mínima.
Las metodologías se ocupan principalmente de los
2.
proyectos de desarrollo de aplicaciones, haciendo
caso omiso de los proyectos de TI en otras áreas
tales como las infraestructuras o la planificación
estratégica.
Cualquier metodología es tan buena como el grado
3.
de su uso. Cuando los administradores no hacen
cumplir el uso de una metodología, los directores
de proyectos lo aprueban incompatible, en todo
caso.

20.  ¿Cómo hace una organización para crear y
hacer cumplir las normas? La respuesta que
está ganando una amplia aceptación es la
oficina de gestión de proyectos, u OGP
(PMO).
 Una empresa encargada de la disciplina y la
práctica de la gestión de proyectos dentro
de la organización, o al menos en esa parte
de la organización que está bajo su control.

21.  Las funciones de una OGP puede variar, pero
generalmente se dividen en tres categorías:
Funciones de desarrollo. Son los que
1.
construyen un grupo de gestores de
proyectos eficaces.
Funciones de apoyo. Son las que ayudan los
2.
gestores de proyectos a ser más eficaz en
la gestión de sus proyectos.
Funciones de control. Son aquellos que
3.
proporcionan la línea de gestión a los
directores de proyectos.

22. El desarrollo del ciclo de vida se refiere a cómo se ha

efectuado el trabajo; la gestión del proyecto se
ocupa de hacerlo.
Ciclo de vida de desarrollo de sistemas (SDLC) o

enfoque de desarrollo.
La gestión de proyectos no depende de ningún SDLC o

enfoque de desarrollo.
Además, asociar la gestión de proyectos con un SDLC

es ignorar (o rechazar) la evolución de las formas de
desarrollar sistemas.
El método convencional quot;cascadaquot; está siendo

sustituido por conceptos tales como el rápido
desarrollo de aplicaciones, la evolución de
prototipos, diseño de refinamiento iterativo, y la
quot;espiralquot; de enfoque. Incluso SDLCs convencionales
están siendo utilizados con mayor flexibilidad.
Por último, SDLCs están destinados principalmente a

proyectos de desarrollo de los sistemas.

23. En muchas organizaciones, el quot;jefe de proyectoquot; es

también un equipo participante, que espera producir
los proyectos, así como gestionar el proyecto. Como
si no fuera suficiente carga, el director del proyecto
también se espera para participar en la gestión de
varios proyectos a la vez.
El problema de pedir a un técnico para la gestión de

un proyecto, participar como miembro de un equipo
es que las personas tienden a hacer lo que les
interesa, y qué intereses técnicos tiene la gente de la
tecnología.
Cuando el proyecto sufre visitas inconvenientes y el

equipo está empezando a poner en tiempo extra para
mantenerse al día con el calendario, ¿cómo se puede
criticar a un superior jerárquico de un empleado por
no preparar un informe de situación cuando esa
persona es la creación de sesenta horas semanales en
el desarrollo técnico?

24. Experimentados gestores de proyectos más

pequeños pueden gestionar varios proyectos
simultáneamente sin afectar a la calidad de su
trabajo.
 Los principios que se aplican a la gestión de los
proyectos individuales se aplican a la gestión de
los múltiples. Estos proyectos todavía necesitan
buen inicio, la planificación, gestión y
liquidación. El único problema adicional que
usted se enfrenta en la gestión de más de un
proyecto es la determinación de aquel en el que
gastar su tiempo. En otras palabras, tendrá que
ser capaz de establecer prioridades entre sus
proyectos y prioridades en su lista de trabajo.

25. El cliente es la empresa o departamento que especifica lo que se

llevara a cabo en el proyecto, paga la factura, y acepta la
entrega del sistema. El cliente puede ser un cliente
externo, como el de una empresa de consultoría, o un
departamento interno.
El director del proyecto es la persona responsable de la

programación, presupuesto, funcionalidad y aplicación de un
proyecto o subproyecto. Muchas organizaciones diferencian entre
los directores de proyectos y jefes de proyecto, pero la
diferencia es la nomenclatura y, a veces, el tamaño del proyecto.
Un proyecto es un conjunto de actividades que ha definido

claramente un inicio y final y que produce un producto tangible.
Un proyecto puede producir un nuevo sistema de solicitud o de
una importante mejora. También puede proporcionar un paquete
de software implementado, hardware actualizado, informes y
análisis, tales como los requisitos de las aplicaciones, una
tecnología de arquitectura, un plan tecnológico estratégico, o de
un plan de reingeniería.
Los usuarios son las personas que realmente utilizan los

resultados de un proyecto. Para la mayoría de los proyectos, los
usuarios forman parte del equipo del cliente, encargado de
especificar los requisitos del proyecto.

26. Cualquier proyecto tiene cuatro fases distintas: la comprensión
del proyecto, la definición de que, la planificación, y gestión. En
todas estas etapas, se deben ejercer las competencias generales
de gestión y conocimientos especializados de gestión de
proyectos dentro del contexto de la gestión de los proyectos
descritos anteriormente. Una imagen de la gestión del proyecto
sería similar a lo que se ve en el Anexo 1.2.

29. La gestión de los proyectos requiere la toma de

decisiones, que, a su vez, requiere que usted entienda
el medio ambiente de proyecto, de fondo, y las
personas. En otras palabras, usted necesita entender el
contexto cultural y político del proyecto. Por duro que
sea admitirlo, la gente es parte más importante de los
proyectos que el aspecto técnico.
Para gestionar un proyecto, usted necesita entender

cuatro cosas:
¿Por qué este proyecto se está realizando? ¿Qué es lo
1.
que el cliente espera obtener de ella?
¿Cuál es el trasfondo de este proyecto? ¿Cómo hemos
2.
llegado a donde estamos?
¿Quiénes son los actores? ¿Quien ha luchado por este
3.
proyecto? ¿Quien ha luchado en contra de el? ¿Quién es el
patrocinador ejecutivo?
¿Cuáles son las prioridades del cliente para este
4.
proyecto?
Estas preguntas reflejan distintas maneras de obtener

una comprensión del proyecto, pero no son exhaustivas.
Los proyectos incluyen una mezcla dinámica de las
personas con intereses
diferentes, filosofías, valores, enfoques y prioridades.

30. La gestión del proyecto no es suave, ni dependen

de manera agradable al cliente. A veces, el bien
del proyecto requiere que el cliente desafié
decisiones o acciones y oponerse a aquellos que
ponen el proyecto en situación de riesgo.
 Como gestor del proyecto, usted es el
representante del proyecto: Si pudiera
hablar, ¿qué dice? Esta función es común en las
empresas y ejecutivos de los miembros de la
junta puede ser considerados legalmente
responsable por ejercer su quot;responsabilidad
fiduciariaquot; para actuar en nombre de su
empresa.

31. El objetivo de el proyecto es crear un estado de la técnica, en

línea, en tiempo real, crear un sistema de inventario que nos
permitirá gestionar nuestro inventario más de cerca al mismo
tiempo para satisfacer las demandas de nuestros clientes.
La declaración de este objetivo, a pesar de la alta tecnología de

moda, es clara: Vamos a construir un sistema que la
administración de inventarios. Lo que no nos dice es si el
proyecto se justifica-es decir, si va a ahorrar o ganar más de lo
que costará.
Una justificación es un análisis de los costos versus los beneficios

que muestran que los beneficios son mayores. (Si el análisis
revela que los costes son mayores, entonces es una justificación
para el desguace del proyecto, no para continuar.)
Una justificación describe exactamente donde la mejora de los

ahorros o ingresos se producirán.
Muchos están llenos de justificaciones vagas nociones tales como
la flexibilidad, servicio al cliente, la integración, el estado de la
técnica, la maternidad y otros valores que siguen siendo
indiscutibles e indefinidos. Una verdadera justificación, tiene dos
características necesarias: Se trata de cuantificar en dólares, y
es tratado como un objetivo o meta.

32. Una justificación describe los beneficios que se

derivarán de hacer un proyecto en beneficio de
lado un análisis coste-beneficio. Debe ser
cuantificados, y si no lo es, nadie sabe si en un
principio el proyecto vale la pena o al final si se
ha realizado correctamente.
 Las justificaciones se cuantifican sólo cuando se
expresan en términos de dólares (u otra
moneda).
 Las justificaciones deben ser cuantificadas de
manera que puedan ser evaluadas y los
proyectos pueden ser aprobados sobre la base
real de beneficios financieros.

33. Una predicción es una conjetura sobre lo que

sucederá, una meta es un objetivo a alcanzar.
 Con una predicción, los resultados del proyecto
se dejan a la suerte.
 Con un objetivo, la justificación se convierte en
una cuestión de política, prevista dentro del
proyecto global. Se convierte en parte del plan
de aplicación del sistema, entra en su ámbito, y
se convierte en un conjunto de actividades más
que una esperanza de inactividad.
 Su trabajo es asegurarse de que las
justificaciones que las metas de gestión se
acepta la responsabilidad de lograr.

34. Las justificaciones de los proyectos por lo general

incluyen una larga y predecible lista de quot;beneficios
intangiblesquot;.
El problema es que no hay tal cosa, y todos los

beneficios se concretan en términos de costes o
ingresos.
Si llaman un beneficio quot;intangiblequot; simplemente

significa que nadie ha podido-o se ha molestado a
adjuntar duros números a la misma. Por
ejemplo, considere la posibilidad de flexibilidad.
Con un sistema flexible, una de las mejoras es tener

menos esfuerzo, produciendo beneficios tangibles de
menores costes de mantenimiento y más rápida
entrega de las solicitudes de mejora. Además, los
departamentos se darán cuenta de los beneficios
tangibles que se derivan de las mejoras cuanto antes.
La flexibilidad es una ventaja debido a que conduce a

resultados reales. El problema es cómo medir los
resultados de lo que será.

35. La mejor manera de cuantificar un beneficio intangible

es formular tres preguntas: quot;¿Qué tanto?quot;, quot;¿Cuánto?quot;, Y
quot;¿Qué hace que el trabajo se lleve a cabo en dólares?“
He aquí un breve ejemplo:

Cliente: El sistema será flexible.
Project Manager: ¿qué tanto?
Cliente: Entonces, vamos a ser capaces de modificarlo
con mayor facilidad.
PM: ¿qué tanto?
Cliente: Bueno, eso significa que nuestro tiempo de
mantenimiento se reducirá.
PM: ¿Cuánto?
Cliente: Eso es difícil de cuantificar.
PM: Haga una conjetura. (¿Cuánto?)
Cliente: Bueno, quizá un 15 por ciento.
PM: ¿Y qué hace que el trabajo se lleve a cabo en
dólares?
Cliente: Bueno, tenemos tres programadores de
mantenimiento de $ 60,000 por año. Eso es $ 180.000
por año total, por lo que probablemente podría ahorrar
aproximadamente $ 27,000 cada año.

36. Si el cliente no identificar los
beneficios, encontrará difícil tomar
decisiones que mejoren el proyecto y la
justificación la encontrará más difícil para
mantener el proyecto en el ámbito de
aplicación.

37. Crear una quot;declaración de prestaciones de

trabajoquot;, un conjunto de beneficios que se
derivan de su comprensión del proyecto y que le
parece razonable. Esta será su declaración de
beneficios privados, no tendrá la fuerza de una
verdadera declaración, sino que le permitirá
actuar día a día como si los beneficios estuvieran
claramente definidos.
Definir el alcance del proyecto en un mucho
mayor nivel de detalle de lo normal, y velar por
que alcance un sólido mecanismo de cambio está
en su lugar. Esto debería ayudar a sobrellevar la
dificultad de gestionar el alcance del proyecto
sin una declaración clara de los beneficios.

38.  Si el cliente define las prestaciones pero no
las metas establecidas, encontrará difícil
ejecutar el proyecto de tal manera que los
beneficios se pueden lograr.

39. Calcular el nivel de prestaciones que serían

necesarias para justificar el proyecto.
 Por ejemplo, si el cliente quiere reducir niveles
de inventario, se debe determinar el nivel de las
reducciones necesarias para recuperar el costo
del proyecto.
 Si el nivel de beneficios es razonable, proponer a
los clientes como un grupo de trabajo conjunto
de las prestaciones, para ser examinado y
revisado cuando se ejecuta el proyecto.
 Si el cálculo de las niveles de prestaciones es
razonable, considere la posibilidad de aplazar la
fijación de los objetivos de beneficio hasta que
usted está planeando para la aplicación en la
expectativa de que el cliente esten más
familiarizados con el proyecto, la fijación de
objetivos será más fácil.

40.  En este caso, el proyecto se justifica
únicamente por su capacidad para gastar el
presupuesto de alguien, no tiene
justificación intrínseca. Sin embargo, esto no
significa que no puede ofrecer valor a la
organización.

41.  En este tipo de proyectos, siempre hay una
justificación aparente. Pocas empresas
ejecutan proyectos abiertamente sin excusa
alguna. Actuar en la forma descrita
anteriormente para la situación en la que el
objetivo del proyecto es real, pero el cliente
no identificar los beneficios.

42.  La consecuencia más evidente es que no
tenga una justificación para trabajar con en
el proyecto. Sin embargo, hay una cuestión
más grave: su papel. Con el fin de gestionar
el proyecto, tendrá que estar activamente
comprometido con aspectos de su
negocio, no sólo desde el punto de vista de
la funcionalidad, pero en términos de su
contexto en la organización del cliente.

43.  Si es posible, piense en ejemplos, como el
proyecto en el que recomendó un cambio
importante en la dirección debido a su
comprensión del contexto del proyecto y ha
creado un producto de más valor como
resultado.
 Informar a su cliente por qué usted lo necesita
para comprender la justificación. Describa su
papel en la gestión y alcance en los esfuerzos
por lograr día a día las decisiones.
 Si estos intentos fallan, esta claro que las
actitudes del cliente obstaculizan la capacidad
del proyecto para tener éxito.

44.  Algunos directores de proyecto argumentan que
los proyectos no justifican su preocupación, una
vez que un proyecto ha sido aprobado, su
trabajo es simplemente para obtener
resultados.
 Sin embargo, la obtención de resultados
significa garantizar que el cliente disfruta de los
beneficios utilizados para justificar el proyecto.
 También significa ser capaz de defender el
proyecto en contra de los recortes y los
números o cuando los costes cambien.

45. La planificación del proyecto incluye la creación de planes de

ejecución, que normalmente consisten en la
capacitación, pruebas paralelas, traspaso y eliminación
progresiva de los sistemas existentes.
Sin embargo, para realmente obtener resultados, el plan de

aplicación también debe describir, en detalle, cómo el
cliente se debe dar cuenta de los beneficios descritos en el
proyecto de justificación.
Por ejemplo, si el proyecto se justifica por la capacidad de

reducir el inventario en un 15 por ciento, ¿Cuál es la rapidez
con que se reduzca el inventario? ¿En cuánto? ¿Cómo
participarán los proveedores? ¿Cuál es el papel del sistema en
la toma de decisiones sobre la reducción de inventario? ¿Qué
medidas son necesarias para garantizar que el servicio al
cliente no se pondrá en peligro? El plan de ejecución debe
responder a estas y otras cuestiones similares para todos los
objetivos que se fijaron cuando se realizo la justificación del
proyecto.

46.  Con frecuencia, los nuevos ejecutivos, o los
convertidos al evangelio de la reducción de
costos, desafían un proyecto en curso. Si la
justificación original estaba bien preparada, es
razonable, y, lo más importante, en realidad
justifica el proyecto, será fácil de defender.
 El director del proyecto lo justifica de las
protestas que alguien más. Pero terminará sin
armas para defenderse en contra de la
reducción de costes, y es poco probable que el
proyecto sobreviva.

47.  Los costos, beneficios y el cambio de alcance
de un proyecto: Los costos por lo general
suben, los beneficios suelen ir hacia abajo, y el
alcance crece normalmente. En algún
momento, los costos pueden crecer a superar
los beneficios.
 Una de sus responsabilidades consiste en
identificar ese punto y que informe al cliente si
las condiciones ya no justifican la continuación
del procedimiento. Sin una buena
justificación, la tarea es imposible, y el
proyecto devora recursos, esfuerzo y mucho
tiempo después de que debería haber sido
terminado.

48. Cuando una justificación del proyecto está bien

definida, se puede aplicar a las solicitudes de
cambios de alcance. Por ejemplo:
 Durante el análisis de un proyecto de desarrollo de
ventas, los usuarios solicitan un cambio a las
pantallas que le costará $ 10000. En caso de que el
cambio se haga.
 Si el proyecto se justifica por el aumento de los
ingresos, la pregunta es quot;¿Cómo y por cuánto, el
cambio de la pantalla contribuye a un aumento de
ingresos por ventas?quot; Si la respuesta es más de
$10000, quot;el ámbito de aplicación justifica el cambio.
 En caso contrario, olvídalo.

49. Una de las razones por las que las personas se

resisten a establecer objetivos es el que no se
logren.
 Es fundamental entender que su responsabilidad no
es para entregar beneficios, pero sólo para
asegurarse de que se han definido y que el trabajo
que ha producido se puede utilizar para alcanzarlos.
 Al discutir los beneficios con sus clientes, usted
debe dejar claro que, mientras usted les ayudará a
planificar, hacer realidad estos beneficios les
corresponde a ellos y que, a menos que estén
dispuestos a hacer que el gerente sea considerado
responsable de los resultados.
 Su función es doble: asegurarse de que existe un
beneficio y para producir un producto que se puede
utilizar para realizar dicha prestación.

50. Si el cliente no se da cuenta de los beneficios
del plan, no funcionara y será en vano

51. Averigüe las razones del cliente. Normalmente, serán ya

sea financiera (quot;no quiero gastar dinero no tengo
quequot;), de organización (quot;Eso no es de su competenciaquot;), o
basado en programas(quot;No tenemos tiempo para perder
con esas cuestionesquot;).
Si es de organización. Lleguen a un acuerdo y pídale a

otra persona que elabore el plan de acción.
Si las preocupaciones del cliente son financieras o de

horario base, preparar un conjunto de argumentos para
demostrar que la planificación de beneficios no es
irrelevante, pero es fundamental para el proyecto. Revise
la lista de personas involucradas con el proyecto y
encuentre una que esté en un puesto de alto nivel y que
ha manifestado un gran interés en los beneficios.
Si ninguna de estas acciones son eficaces, indique al

cliente, preferiblemente por escrito, que el proyecto no
se puede llevar a cabo ya que depende de la prestación
de los beneficios utilizados para justificarla.

52.  Si el proyecto de justificación ya no aplica
porque los costos han aumentado o han
desaparecido los beneficios, de continuar
con el proyecto sería un desperdicio de más
tiempo y dinero del cliente, así como el
desvío de valiosos recursos de personal en
una pérdida de esfuerzo.

53. Revise el análisis de costo-beneficio para tratar de

encontrar algunos beneficios adicionales o para aumentar
los revistos. Esto puede sonar como esquivar los
números, pero los nuevos beneficios suelen surgir
durante un proyecto.
Si la revisión de los números son favorables al

proyecto, informe al cliente y continúe. Si no es así, el
proyecto ya no está justificado, y debe tratar de
convencer al cliente para poner fin al proyecto.
Revise el análisis de costo-beneficio para reflejar la

posición actual. Indique la pérdida a la empresa si el
proyecto se dobla en este momento y la pérdida
potencial si se lleva a término.
Trate de señalar el lado positivo de poner fin al proyecto.

No permita que el cliente tome la posición de que el

proyecto ha fracasado. Cambie las condiciones que han
hecho aconsejable retroceder antes de que se agoten los
recursos y se convierte en un fracaso.

54. Los gestores de proyectos no suelen participar en el inicio de

este.
En el momento en que aparecen en la escena, por lo general el

proyecto ha adquirido su propia historia y su impulso. Para
entenderlo, es necesario pedir a las seis preguntas siguientes:
¿Cuáles fueron las condiciones comerciales que le piden a alguien
1.
que proponga el proyecto?
¿Cómo fue presentado el proyecto de gestión, y cómo se evalúa y
2.
aprueba?
¿Cuáles son las alternativas de proyecto con que cuenta el cliente?
3.
¿Cuáles fueron (y son) los argumentos contra el proyecto?
4.
¿Cómo ve el cliente el proyecto dentro de la empresa o
5.
departamento? ¿Qué tan importante es?
¿Cuáles son las actitudes hacia el proyecto?
6.
En concreto:
¿Es acogido como deseable, aceptado como necesario, o
condenado como malo?
¿Es considerado como fácil, difícil, o imposible?
¿Es visto con entusiasmo, renuncia, o temor?

55. Una de las consecuencias de preguntar sobre los

antecedentes del proyecto es que es posible
descubrir cosas que hubiera preferido no saber.
 Por ejemplo, usted puede descubrir que algunas
personas que apoyan el proyecto, son pocos los que
piensan que tendrá éxito, y que, para muchos, su
fracaso en general se consideraría como una señal de
que todos tiene razón.
 Es necesario determinar si este proyecto es
realmente una mala idea.
 Si, después de un examen, se determina que la
conclusión de el proyecto es inviable o
injustificada, entonces, como gestor de
proyectos, es su responsabilidad de señalar al cliente
que los detractores son correctas y que el proyecto
no debe o no se puede hacer.

56.  Si por el contrario e proyecto esta bien
justificado y es viable tiene que saber porque la
gente normalmente se opone a un nuevo
sistema:
Lo ven como derivados de las necesidades de otro

departamento sin hacer referencia a ellos.
Ellos lo ven una imposición.

Tendrán que cambiar los hábitos de trabajo cómodo.

Sospechan que se trata de una estrategia para alterar

la gestión de un equilibrio de las relaciones
laborales.
Sospechan que no va a funcionar y que su fracaso

será culpa de ellos.
Reconocen que en el desarrollo y la aplicación será

necesario un esfuerzo adicional que no desean.
Sospechan (y esto es lo que asusta a la mayoría de

ellos) que se traducirá en despidos.

57. Si no entiende la importancia del
background, se arriesga realizando
operaciones que ponen en riesgo no solo
el proyecto sino su capacidad para
dirigirlo.

58.  Formular preguntas que se refieren a incidentes
específicos de las personas. Por ejemplo, quot;Fred
no parece entusiasmado con este proyectoquot;, o
quot;¿Por qué el departamento de finanzas que no
esta representados en el comité de dirección?quot;
 Si se encuentra con una cuestión de fondo que
podría obstaculizar seriamente el proyecto, se
plantean con el cliente en dos contextos: como
una cuestión que debe resolverse, y como un
ejemplo de los problemas que pueden producirse
cuando se disuade de realizar su trabajo.

59. El fondo o el inicio del proyecto suele ocasionar

problemas ya que al no estar en el desde esa
instancia puede ocasionar distorsiones en la
información que se recibe al respecto.
 Por ejemplo: Fred le dice que María esta en
contra del proyecto, pero George dice que ella
es una de sus más firmes defensoras-no se tiene
información, se tiene un rumor. El riesgo es que
se hacen inadecuado, tal vez peligroso, tomar
las decisiones.

60.  En el ejemplo que se acaba de dar, usted
probablemente aprendido más acerca de la
actitud que tienen hacia el proyecto Fred y
George y de su actitud hacia María.
 En esta circunstancia se puede aclarar el
rumor directamente con María diciendo:
 “Entiendo que usted tiene algunas
preocupaciones acerca de este proyecto.” sin
tener que mencionar a Fred ni a George.
 Se puede saber que el proyecto es objeto de
una lucha de poder.

61.  Si dos o mas departamentos tienen conflicto
de opinión con el propósito del proyecto, el
alcance o la justificación, tendrá dificultades
para gestionarlo y sin importar lo que haga
se tendrán oponentes.

62. Identificar al cliente y los administradores de

departamento. Esto puede parecer simple, pero en
muchos proyectos, las líneas de responsabilidad son
difusas.
Por ejemplo, un director de operaciones puede insistir

en que el proyecto es responsabilidad de las
operaciones, ya que es el departamento que se deben
poner en práctica, mientras que el director financiero
está reclamando la propiedad debido a que el
departamento de finanzas está pagando por ello.
Su trabajo es identificar a un solo cliente: el gerente

propietario del proyecto y que será responsable de todas
las decisiones.
Si no está clara la propiedad del proyecto. Esta demanda

probablemente desencadenara maquinaciones internas
dentro de la organización del cliente, pero siempre y
cuando haya realizado su demanda clara, es probable
que terminemos con un proyecto efectivo.

63.  quot;Esto sería un gran proyecto,quot; se lamentan a
menudo, quot;si no fuera por los usuarios.quot;
 El personal del proyecto anhelan el proyecto
de oro en que los usuarios están
conformes, las recomendaciones
técnicas, normas y quot;políticasquot; perfectas no
existen.

64. La política se refiere a la astucia con que se

resuelven las problemáticas del proyecto.
 La sociología se refiere a la parte de las
relaciones humanas a la hora de gestionar el
proyecto.
 Para ver una situación de conflicto o desagrado
con políticas es atribuir mala fe a las personas
implicadas.
 Sin embargo, para interpretar la misma
situación desde el punto de vista sociológica se
debe reconocer que diferentes personas pueden
llegar a conclusiones diferentes, pero comparten
objetivos y preocupaciones.
 Evidentemente, la segunda opinión es más
probable que lleve a la
discusión, aclaración, negociación y resolución.

65. Para llevar a los participantes en un proyecto de manera

eficaz, usted debe comprender quiénes son y cuales son
sus actitudes hacia el proyecto.
En concreto:

¿Quiénes son los campeones de proyectos, los que han

apoyado el proyecto desde el principio y se han
entusiasmado con la conclusión de su servicio? ¿Por qué
son entusiastas?
¿Quiénes son los detractores del proyecto, los que han

luchado en contra del proyecto? ¿Por qué se oponían?
¿Quiénes parecen ganar si el proyecto tiene éxito? ¿Quién

van a ganar realmente?
¿Quiénes parecen perder si el proyecto tiene éxito?

¿Quién pierden realmente?

66.  El patrocinador ejecutivo es miembro de la
dirección que está comprometido con el
proyecto y que tiene influencia suficiente para
llenar su función primordial.
 El patrocinador no está implicado en los
detalles y puede ser incluso invisible para el
equipo del proyecto, pero cualquier proyecto
que no tiene un patrocinador está en riesgo.

67. El comité directivo del proyecto, no es un foro

de resolución de problemas o un lugar para una
discusión de cuestiones de detalle.
 Su trabajo es hacer cumplir, desde el punto de
vista del cliente, el mandato del proyecto. El
comité directivo también debe aprobar o negar
las solicitudes de recursos adicionales o cambios
en el alcance o el calendario.
 Esto no significa que los miembros del comité de
dirección son variables ficticias que no tienen
conocimientos especiales que ayuden al
proyecto. Los que desean participar a un nivel
más detallado se debe permitir que lo haga, pero
mantener las funciones por separado.

68. El grupo de usuarios es el conjunto de personas

que serán responsables del día a día los detalles y
decisiones en el proyecto.
 En el mejor de los grupos de usuarios, una persona
tiene la autoridad para tomar decisiones y la
voluntad de hacerlo en la cara de la oposición.
 En el peor de los casos, la quot;democraciaquot; prevalece
y nadie está dispuesto a tomar una decisión.
 Independientemente del tipo de grupo de
usuarios, cuando se necesita una
decisión, asegúrese de documentar con claridad los
problemas y alternativas. Distribuir la
documentación antes de la reunión, y garantizar
que nadie sale de la habitación hasta que se
alcance una decisión.

69.  El cliente director de proyecto es de los
principales miembros del grupo de usuarios
del cliente y es el contacto principal entre
usted y la organización del cliente.
 El cliente director del proyecto debe tener la
autoridad para aprobar los resultados o para
resolver los problemas. Este papel en su
proyecto es fundamental.

70. El proyecto no tendrá a nadie buscando en
niveles altos, lo que significa que va a ser
vulnerables a la reducción de costes o de un
cambio de prioridades y será difícil competir
con otros proyectos por los escasos recursos.

71.  Cuando usted solicita un ejecutivo
patrocinador al inicio del
proyecto, determina la antigüedad que
necesita (quot;Esta persona debe ser de al menos
un vicepresidente que quiere ver el éxito del
proyectoquot;).
 Cuando lo haga, procure no molestar al
cliente, o tendrá problemas reales.

72.  Lasdecisiones importantes, en particular las
que afectan a cuestiones tales como el
presupuesto, los recursos, o el alcance del
proyecto, serán casi imposibles de conseguir.

73.  Identificar un grupo de representantes del
cliente a quien usted piensa que debería
estar en el comité de dirección y, a
continuación, convocar una reunión para
discutir una serie de cuestiones para que
usted los necesita a todos los presentes.
 Después de la reunión, manifieste su
intención de reunirlos de nuevo cuando
surjan problemas en el futuro. Se crea un
comité informal, que nunca serán
llamados, pero que tendrá la autoridad
colectiva para tomar las decisiones que usted
necesita.

74. Cualquier cliente razonable lo quiere todo: el tiempo, sobre

el presupuesto, y en pleno funcionamiento. Nadie quiere
iniciar un proyecto con la actitud que uno de estos tendrá
que ir, pero hay momentos en reunión de todos ellos es
imposible, y es prudente a entender de antemano lo que
puede ser sacrificado.
Estas no son las invitaciones a pasar por alto el

presupuesto, abandonar el programa, la funcionalidad o la
basura, sino que son realistas las declaraciones de las
prioridades del cliente, y deben ser respetados.
Si el cliente no tiene claras las prioridades, asegúrese de que

usted entiende por la comprensión de los antecedentes y la
justificación para el proyecto. ¿Cuáles son las consecuencias
de desaparecer el calendario? ¿Qué sucede si usted excede el
presupuesto? ¿Cuál es el impacto si el sistema no está
completo?
Una advertencia: No olvidar preguntar al cliente

directamente por estas prioridades. quot;¿Cuál de estos tres se
pueden descartar sin que la situación empeore? “

75. Va a encontrar dificultades para establecer
prioridades dentro del proyecto, incluso si
está en condiciones de cumplir el plan.
Además, esto debería ser una señal de
peligro para su proyecto ya puede
convertirse en un objeto de la discordia
dentro de la organización del cliente.

76.  Al
discutir la contradicción con el cliente o el
gerente del proyecto y con cada uno de los
miembros del comité de dirección. Puede
obtener información sobre la organización
del cliente que le ayudará a gestionar el
proyecto.
En general, se debe evitar anunciar este tipo
de problema en una reunión donde las
personas no han tenido la oportunidad de
evaluarlo.

77. Los proyectos son costosos, por lo que ninguna organización

debe comenzar uno sin antes cerciorarse de que dará valor. Sin
embargo, en muchas organizaciones, los proyectos parecen
surgir de alguna manera.
La solicitud se ha convertido en un proyecto encubierto, que es

un problema por un período de cinco motivos:
1. No existe ninguna evaluación para determinar cuánto
esfuerzo se requiere.
2. No existe ninguna evaluación para determinar si el proyecto
apoya o retrasa la estrategia de la dirección.
3. No existe una definición clara del ámbito de aplicación.
4. No hay ningún análisis de beneficios, ninguna posibilidad de
garantizar que el proyecto ofrece un valor a la organización.
5. Los proyectos regulares de personas que se han extraído de
sus horarios y exceder sus presupuestos, aumento de los costos
y retrasar la realización de beneficios.

78. Como un director de proyecto, no es su

responsabilidad establecer un proceso de
iniciación del proyecto: que es el trabajo de
gestión o de una oficina de gestión de proyectos.
 Sin embargo, tiene otras dos funciones. La
primera es asegurar que cualquier proyecto que
se le pide que la gestión ha pasado por algún
tipo de evaluación para garantizar tres cosas:
1. Que apoya la orientación estratégica de la
organización
2. Que tiene una clara declaración de alcance
3. Que se tiene una clara declaración de
beneficios

79. ¿Entiende los costes del proyecto y los beneficios?

¿Las justificaciones del proyecto son cuantificables?

¿El cliente acepta la justificación del proyecto como

objetivos?
¿Tiene una clara comprensión de los antecedentes del

proyecto?
¿Se puede clasificar cada uno de los participantes en

términos de su apoyo u oposición al proyecto?
¿Ha encontrado el ejecutivo patrocinador?

¿Existe un comité de dirección?

En caso afirmativo, ¿ha establecido que fijará el orden del

día de las reuniones?
¿Ha escrito su comprensión del

proyecto, justificación, antecedentes, y la gente? (Si no es
así, que lo hagan, aunque sólo sea para su propia
referencia.)
¿El proyecto se ha iniciado correctamente?
