Definicion de proyecto

1. ¿Qué es un proyecto?

Las organizaciones trabajan. El trabajo generalmente involucra operaciones o
proyectos, aunque las dos se puedan traslapar. Las operaciones y los proyectos
comparten muchas características; por ejemplo, ellas son:
•Desarrolladas por personas.
•Limitadas por recursos escasos.
•Son planeadas, ejecutadas, y controladas.

Las operaciones y los proyectos difieren principalmente en que las operaciones
son sucesivas y repetitivas mientras que los proyectos son temporales y únicos.
Un proyecto por lo tanto puede ser definido en término de sus características
distintivas— un proyecto es una tarea temporal desarrollada para crear un
producto o servicio único. Temporal quiere decir que cada proyecto tiene un
comienzo definitivo y una terminación definitiva. Único quiere decir que el producto
o servicio es diferente de alguna manera distintiva de todos los proyectos o
servicios similares.

Los proyectos son desarrollados en todos los niveles de la organización. Estos
pueden involucrar a una sola persona o a muchas miles. Y pueden requerir menos
de 100 horas para completarse o más de 10,000,000. Los proyectos pueden
involucrar a una sola unidad de una organización o cruzar muchas fronteras
organizacionales como en consorcios o sociedades de hecho. Los proyectos son
muchas veces componentes críticos de la estrategia de negocios de la
organización que los desarrolla. Ejemplos de proyectos pueden incluir:
•Desarrollar un nuevo producto o servicio.
•Efectuar un cambio de estructura, de personal, o de estilo en una organización.
•Desarrollar un nuevo vehículo de transporte.
•Desarrollar o adquirir un nuevo sistema de información.
•Construir o desarrollar una construcción.
•Administrar una campaña electoral.

2. •Implementar un nuevo procedimiento o proceso en un negocio.

Carácter Temporal

Temporal quiere decir que cada proyecto tiene un comienzo definitivo y una
terminación definitiva. El fin es alcanzado cuando los objetivos del proyecto han
sido alcanzados, o cuando se hace claro que todos los objetivos no pueden ser
alcanzados y que el proyecto tiene que ser terminado. Temporal no quiere decir
necesariamente corto en duración; muchos proyectos duran varios años. En cada
caso, sin embargo, la duración del proyecto es finita; los proyectos no son
esfuerzos sucesivos.

Adicionalmente, el término temporal no se aplica generalmente al producto o
servicio creado por el producto. Muchos proyectos son desarrollados para crear un
resultado duradero. Por ejemplo, un proyecto para crear un monumento nacional
creará un resultado que se espera dure por varios siglos.

Muchos desarrollos son temporales en el sentido en que van a terminar en algún
punto del tiempo. Por ejemplo, el trabajo de ensamble en una planta automotriz va
hacer eventualmente discontinuado, y la planta en si abandonada. Los proyectos
son fundamentalmente diferentes porque el proyecto cesa cuando sus objetivos
declarados han sido obtenidos, mientras que los desarrollos de no proyectos
adoptan una serie nueva de objetivos y continúan trabajando.

La naturaleza temporal de los proyectos se pueden aplicar a otros aspectos del
desarrollo tales como:
•La oportunidad de la ventana de mercado es usualmente temporal — La mayoría
de los proyectos tienen un marco de tiempo limitado en el que tiene que producir
su producto o servicio.
•El equipo de proyecto, como un equipo, rara vez dura más que el proyecto— la
mayoría de los proyectos son desarrollado por un equipo creado con el sólo

3. propósito de desarrollar el proyecto, y el equipo es desmantelado y sus miembros
reasignados cuando el proyecto se termine.

Producto o Servicio Único

Los proyectos involucran hacer algo que no se ha hecho antes, por lo tanto, es
único. Un producto o un servicio pueden ser únicos aunque la categoría a la que
pertenezca sea grande. Por ejemplo, muchos miles de edificios de oficina han sido
desarrollados, pero cada edificio en si es único — de distinto dueño, de distinto
diseño, diferente locación, y diferentes contratistas, y así etc. La presencia de
elementos repetitivos no cambia fundamentalmente la característica de ser único.
Por ejemplo:
•Un proyecto para desarrollar una vía comercial puede requerir múltiples prototipos
•Un proyecto para introducir una nueva droga al mercado puede requerir de miles
de dosis durante las pruebas clínicas.
•Un proyecto de desarrollo de bien raíz puede incluir cientos de unidades
individuales.

Debido a que el producto de cada proyecto es único, las características que
distinguen el producto o servicio deben ser elaboradas progresivamente.
Progresivamente quiere decir "Procedimientos en pasos; avance continuo por
incrementos" mientras que elaborados quiere decir "trabajado con cuidado al
detalle; desarrollado enteramente”. Las características distintivas serán definidas
de manera amplia, temprano en el proyecto y erán cada vez más y más explícitas
y detalladas a medida que el equipo del proyecto desarrolla un entendimiento
mejor y más completo del producto.

La elaboración progresiva de las características de un producto debe ser
cuidadosamente coordinada en concordancia con una apropiada definición del
alcance del proyecto, particularmente si el proyecto es desarrollado bajo un
contrato. Cuando definida propiamente, el alcance del proyecto - el trabajo a

4. realizar - deberá mantenerse constante aún en la luz del cambio las características
del producto que sea progresivamente elaborado.

Ejemplo. Una planta procesadora química empieza con un proceso de ingeniería
para definir las características de un proceso. Estas características serán usadas
para diseñar las unidades de procesamiento principales. Esta información se
convierte en la base del diseño de ingeniería que definirá tanto el detalle de layout
de la planta y de las características mecánicas de las unidades de proceso y
facilidades auxiliares. Todo esto resulta en los dibujos de diseño que serán
elaborados para producir dibujos de fabricación (isométricos de construcción)
durante la construcción, habrán interpretaciones y adaptaciones que serán hechas
a medida que se necesiten y estarán sujetas a una aprobación formal. Esta
elaboración adicional de las características es capturada por un dibujo "as built".
Durante los ensayos y entrega, un desarrollo adicional de las características es
muchas veces hecho en la forma de ajustes operacionales finales.

Los clientes y la gestión de proyectos

En algunas ocasiones, a la hora de ejecutar un proyecto, nos podemos encontrar
con personas, equipos dentro de algunos clientes que a la hora de ejecutar un
proyecto no valoran lo suficiente las actividades de gestión dentro del proyecto.
Esto supone un problema ya que, por desgracia, la gestión suele ser, junto con las
actividades de calidad, una de las principales afectadas por recortes (presupuesto

5. o, por la concepción errónea de que quitan tiempo), primando las actividades
meramente técnicas. De poco valen los esfuerzos que puedan hacer las empresas
proveedoras de servicios para mejorar las actividades de gestión entre sus
profesionales, si es el propio cliente el que no valora dicha función, y no es
consciente o no percibe el valor que aporta al proyecto.
 Por eso creo que las empresas y profesionales que desarrollan su actividad
dentro del ámbito de la gestión de proyectos tienen que ser conscientes que
también deben “formar” y concienciar a sus clientes, hacerles entender la
importancia de la gestión, del proceso de gestión, como pieza fundamental
(necesaria aunque no suficiente) para minimizar el riesgo de fracaso en los
proyectos. Y esa función de “concienciación” y “formación” se tiene que hacer
con responsabilidad, sin excesos y haciendo ver (de forma cuantitativa y no
solo con buenas palabras) los beneficios que ha aportado al proyecto dicha
gestión. A veces incluso esa labor de pedagogía se alarga en el tiempo, y no
se consigue el propósito rápidamente, en el primer proyecto, pero no por ello
se debe desistir.

Gestionar Proyectos: ¿Arte o Ciencia?

6. Responder a este simple pregunta no es tan fácil como pueda parecer a simple
vista, y prueba de ello es la diferencia de opiniones que podeis encontrar en la red:
desde los que apuestan por ciencia con el argumento de que incluye existen
técnicas, herramientas, y procesos que nos ayudan a la labor, hasta los que
apuesta por el arte debido a las interacciones que un jefe de proyecto tiene que
tener con los stakeholders de un proyecto -clientes, proveedores, los gestores,
etc...

Para dar respuesta a esta pregunta vamos a echar un ojo a las responsabilidades
que debe tener un buen jefe de proyecto:

 Asegurar que todos los hitos y resultados sean alcanzados cumpliendo las
restricciones de tiempos, costos y respetando los estándares de calidad.
 Alcanzar los objetivos contractuales.
 Trabajar conjuntamente con los Responsables Funcionales para asegurar que
los recursos se empleen en forma eficaz y eficiente.
 Actuar como el punto principal de comunicación entre el cliente (externo),
patrocinador, la alta dirección y las direcciones funcionales (internos).
 Preparación de planes realistas.
 Mantener informados a stakeholders en forma completa.
 Tomar todas las decisiones necesarias, ya sean para alternativas o para la
terminación.
 Proponer o iniciar acciones correctivas.
 Responsabilidad final total.
 Resolver todos los conflictos, si es posible.

Para poder responder con éxito a dichas responsabilidades, un Director de
Proyecto tiene que tener o adquirir una serie de capacidades y habilidades, que se
pueden catalogar de la siguiente forma:

 Capacidades Técnicas. Conocimiento de procedimientos, métodos y procesos.

7.  Capacidades Humanas. Habilidades que permitan trabajar con personas
(comunicación, trabajo cooperativo,…).
 Capacidades Conceptuales y de Diseño. Capacidad de entender el entorno,
analizarlo y adaptarse.

Con este planteamiento, la dirección de proyecto se puede considerar una ciencia,
ya que se basa en métodos, procesos, datos empíricos, aunque sin embargo no
es un factor suficiente ya que se necesitan una serie de habilidades sociales.

Entonces, ¿como definiriamos la Dirección de Proyectos? Después de mucho
buscar/leer, la definición con la que me encuentro más cómodo se resumen en
esta frase:


Gestionar un proyecto es un Arte que se basa en conocimientos Científicos

Decimos que es un “arte” puesto que las decisiones no están unívocamente
determinadas por cada situación (cada proyecto varía significativamente en
función del entorno, con lo que podríamos aplicar la fase de José Ortega y Gasset:
“Yo soy yo y mi circunstancia”) y utilizamos el término “ciencia” puesto que el
director de proyecto debe utilizar todas las experiencias, procesos, herramientas y
técnicas conocidas y científicamente válidas.

En resumen, para ser un buen Director de Proyecto no sólo es necesario aprender
(o chapar) una serie de técnicas o usar unas buenas herramientas, es condición
necesaria pero no suficiente. Para dirigir correctamente un proyecto necesitamos
una serie de habilidades y experiencias que nos ayuden a la interacción con el
entorno.

8. ¿Tenemos claro cuál es la función de un Jefe de Proyecto?

En los distintos cursos de gestión de proyectos que he impartido el perfil de los
asistentes siempre ha sido el mismo: profesionales, consultoras o proveedores de
servicios de distintos sectores que tienen un creciente interés en mejorar sus
conocimientos y técnicas relacionadas con la gestión de proyectos. A pesar de los
esfuerzos por parte de todos, y que en el último año (quizá por el propio efecto de
la crisis) se ha incrementado notablemente el interés por mejorar en todo lo
relacionado con la gestión, todavía queda mucho camino por recorrer.

Los profesionales y las empresas tienen que ser conscientes de lo que significa
ser Jefe/Director de Proyecto: no es un simple jefe o coordinador técnico de los
equipos de trabajo, es mucho más. Sin embargo, y a la vista de algunas ofertas de
empleo, parece que no todo el mundo entiende cual es el rol de un Director (Jefe)
de proyecto. ¿por qué digo esto? Según PMBok® el Director de Proyecto es una
persona donde reside la responsabilidad del proyecto, con dedicación al proyecto
en sí en lugar de aspectos técnicos, pero viendo algunas ofertas de empleo no
todo el mundo tiene tan claro esta función: “se busca jefe de proyecto Java/J2EE”,
“se busca jefe de proyecto .Net”,... No es que diga que el Jefe de Proyecto no
tenga que tener una base técnica, ya que considero imprescindible que entienda el
entorno en el que se desarrolla su proyecto, pero su función trasciende esos
aspectos. Ojo, hablamos de roles, otra cosa es que distintos roles (Analista, Jefe

9. de Proyecto) sean desempeñados por la misma persona, cosa por otro lado muy
normal en las pequeñas empresas, donde prima el hombre orquesta. Creo que
uno de los problemas es que muchas veces se confunde el Jefe de Proyecto con
el perfil de un Jefe/Coordinador Técnico donde priman mucho más los
conocimientos técnicos, y en un proyecto hay que prestar atención a los aspectos
técnicos, pero también a otros aspectos mas relacionados con la perspectiva de
negocio, que necesita otras habilidades.>

Por esto tenemos que seguir reforzando el rol de Director de Proyecto en las
empresas, dándole valor, en resumen, PROFESIONALIZAR LA GESTIÓN DE
PROYECTOS.
Hacia un cambio de modelo: de Jefe de Proyecto a Lider de Proyecto


Tradicionalmente nos referimos a ese perfil de Responsable/Coordinador como
Jefe de Proyecto y, tras esa denominación existe, subyacente, toda una cultura de
cómo se estaba dirigiendo los equipos tradicionalmente. La acepción de Jefe tiene
una connotación de mando/autoridad impuesta que, si bien podía funcionar en
entornos más industriales, en una sociedad como la actual, basada en el
conocimiento, no tiene tanta cabida. Las empresas actuales no necesitan tantos
"controladores", más bien necesitan facilitadores, líderes que ayuden a los equipos
a alcanzar el objetivo común: el éxito en la actividad o proyecto.

10. Esta nueva forma de dirección nos llevará a entornos laborales más flexibles,
dinámicos y estructuras organizativas mucho más planas, sin tantos mandos
intermedios y donde las personas tienen que ser capaces de asumir una mayor
responsabilidad.
Este modelo encaja perfectamente con la visión de proyecto donde un Líder de
Proyecto (remarco la palabra Líder frente a Jefe o Director) es el encargado de
coordinar los distintos engranajes que conforman el proyecto, haciendo de
facilitador que ayuda a resolver conflictos, guía al equipo, ayuda a resolver
incidencias, sirve de interlocutor (de paraguas) con personas ajenas al equipo
(clientes, proveedores, responsables de la organización,...), cohesiona el propio
equipo y le aporta una visión global del conjunto del proyecto. En estos ambientes
cobra especial relevancia la comunicación, el feedback (retroalimentación), la
motivación, la escucha activa... en definitiva HACER EQUIPO.

Sin embargo, para que esto sea posible, todavía nos queda mucho camino por
recorrer en cuanto a formación en las propias organizaciones y de los propios
empleados, y se hace cada vez más necesario orientarnos hacia un sistema
basado meritocracia, el esfuerzo y la responsabilidad.

Aquí os dejo el enlace al artículo de Expansión: ¿Es mejor un mundo sin jefes?

Era un buen albañil, pero pésimo capataz: no es lo mismo técnico que gestor

11. Seguro que esa frase la hemos oído todos en algún momento. Esa o una de sus
variantes: era un buen técnico, pero pésimo jefe de proyecto; o era una buena
enfermera, pero una pésima jefa de enfermeras. Todas esas frases tienen como
trasfondo una mala práctica que está muy implantada en una sociedad como la
nuestra, donde la única forma de progresar salarialmente en muchas profesiones
es "subir en el escalafón" sin tener en cuenta las habilidades
personales/profesionales (esto pasa mucho en profesiones tecnológicas). En esa
huida hacia adelante, llena de buenas intenciones para poder promocionar al
trabajador, en muchas ocasiones, quizá demasiadas, obtenemos el efecto
contrario al deseado, causando mucho daño, tanto al propio trabajador, como a la
empresa y a los compañeros. Porque al final, un buen trabajador, a base de
"empujones" en el escalafón, puede acabar convirtiéndose en un trabajador
ineficiente. O dicho de otro modo: "Un profesional podrá seguir ascendiendo hasta
alcanzar su nivel máximo de incompetencia".

Las causas por la que ocurre esta mala práctica son muchas: cultural, planes
profesionales excesivamente rígidos, mal entendimiento de lo que es una
evolución profesional, etc... Pero en el fondo lo que hay es una mala comprensión
de lo que es ser un Jefe de Proyecto. Las habilidades que tienen que tener todo
Jefe (ya hablemos de jefatura de proyecto, gerente, coordinador,...) son distintas a
las que tiene que tener un técnico, y eso es debido a las nuevas funciones que se
tienen que asumir, porque no es lo mismo ejecutar que delegar la ejecución. Un
Jefe de Proyecto tiene que saber combinar las habilidades técnicas de su
profesión, con un mayor peso de las habilidades humanas (comunicación,
negociación, liderazgo, ...) a medida que aumenta se nivel de responsabilidad. Al
final un Jefe de Proyecto, o un responsable, o un coordinador (como queráis
llamarlo) es un profesional cuya función principal se tiene que centrar en el propio
proyecto más que en los aspectos funcionales o técnicos del mismo. En un post
anterior "Las habilidades de un buen Director de Proyecto", ya presentaba cuales
son las habilidades que tiene que tener un buen Jefe de Proyecto, como
Capacidad de comunicación y liderazgo.

12. Por todo esto, tanto las organizaciones como los propios profesionales,
deberíamos ser conscientes que la evolución hacia un perfil gestor es un paso
muy importante, que se tiene realizar después de asegurarnos que poseemos las
habilidades y la formación necesarias para cumplir nuestro nuevo cometido. Y,
complementariamente, deberíamos promocionar los buenos técnicos dentro del
propio perfil, y permitir desarrollar su carrera profesional dentro de las funciones
técnicas, sin obligar a dar el salto a la gestión para poder progresar
económicamente, porque si hacemos eso, es muy probable que todos perdamos y
llegue la desmotivación.

PMI publica las nuevas categorías para obtener PDUs dentro del programa CCR
Recientemente, PMI (Project Management Institute) ha comunicado los cambios
que van a producirse en las categorías de PDU (Professional Development Units)
para la renovación de la certificación PMP, dentro del programa CCR (Continuing
Certification Requirements).

El cambio viene derivado, principalmente y según detallan en el anuncio enviado a
los asociados, por la complejidad del modelo anterior (basado en una estructura
de 5 categorías) que se reflejó en un estudio realizado por el propio instituto. El
cambio propuesto consiste en una simplificación mediante la agrupación en 2
grandes divisiones: Formación (sin número máximo de PDU's) y Contribución a la
Profesión (con un máximo de PDU's en cada ciclo de certificación -3 años-). A

13. continuación se describen las actividades más importantes dentro de cada
división:

Formación.
 Categoría A. Cursos ofertados por proveedores registrados de PMI (PMI's
R.E.P.), o ofertados por comunidades o capítulos.
 Categoría B. Educación continuada, ofertada por Universidades,
instituciones no registradas como proveedores PMI o por profesionales o
miembros de la asociación.
 Categoría C. Auto-Formación a través de libros, artículos, videos, etc.

Contribución a la profesión.

 Categoría D. Crear nuevos conocimientos en gestión de proyectos,
mediante la elaboración de artículos, libros, orador en seminarios-talleres,
etc...
 Categoría E. Servicios de voluntariado no remunerado como trabajo en la
elaboración de algún estándar, participando como miembro de una
asociación, o en la organización de un congreso, etc..
 Categoría F. Trabajar como profesional en gestión de proyectos
(experiencia demostrable como jefe de proyectos).

Al parecer, estas nuevas divisiones y sus categorías han sido valoradas
positivamente: un 82% de los encuestados están satisfechos con las nuevas
categorías propuestas y un 76% piensa que será más positivo.
La nueva Estructura de Categorias empieza a implantarse a partir del 1 de Marzo
de 2011. Antes de esta fecha, teneis que tener en cuenta los siguientes pasos:

 Registrar los PDUs obtenidos en el sistema CCR bajo las categorias
actuales.

14.  Después del 1 de Marzo de 2011, se deberá reportar cualquier PDUs
obtenido que no hayan sido registrado usando las nuevas categorias.
 Durante esta transición no se perderá ningún PDU.

15. Hasta aquí el cambio pero, y valga la redundancia, ¿hay algún pero? Al principio
me pareció un error limitar el número máximo de PDU's en la categoría de
contribución a la profesión, ya que, si compartir experiencias es la mejor forma de
aprender y promocionar la profesión, ¿por qué limitar el número de PDU's?
Posteriormente, y tras una breve reflexión, creo que para continuar avanzando
individualmente en la profesión, sí que es necesario potenciar dos aspectos base:
formación y experiencia. Estas son, precisamente, las nuevas categorías del
programa de certificación continua. Sin embargo, es aqui donde encontré una
inconsistencia en el nuevo modelo de categorías: si para renovar la certificación
no podemos centrarnos solo en la contribución a la profesión (con seminarios,
artículos, ...) y nos obligan, de algún modo, a formarnos (obtener 15 PDU's en la
división de formación), ¿por qué si que puedo renovar las credenciales (PMP,
PMI-SP, PgMP,...) sólo con acciones formativas y sin niguna contribución y/o
experiencia demostrable? Si PMI propone que obtener las credenciales es tener
un compromiso con la profesión, para renovarla debería ser necesario obtener
PDU's de las dos categorías para poder renovar las credenciales (por ejemplo con
una relación 1/3 entre formación y experiencia/contribución). Aunque pueda
resultar difícil aportar artículos, o impartir sesiones formativas o realizar acciones
de voluntariado (categorias D y E), ya que estas actividades puede que no estén al
alcance de todos, la categoría F nos permite obtener PDU's mediante el "trabajo
como profesional en gestión de proyectos". De esta forma no sería un
impedimento poder obtener PDU's de las dos categorías: un profesional que
demuestre su actividad como Jefe de Proyecto y demuestre que sigue formándose
(con un cursos formales o auto-estudio) podría obtener los PDU's necesarios para
renovar las credenciales.

Las habilidades de un buen Director de Proyecto

Según la definición de PMBok (Project Management Body of Knowledge), el Jefe
de Proyecto (Director de Proyecto) es la persona que tiene la responsabilidad

16. total/integral del proyecto (accountability). Entre sus funciones principales hay que
destacar:

 Se dedica al proyecto en sí y no a los aspectos funcionales del proyecto
 Se encarga de la coordinación de los integrantes del equipo de proyecto
 Utiliza de forma apropiada e integral las actividades de planificación y
control
 Es el responsable de asegurar que todos los hitos y objetivos se alcancen
 El punto principal de comunicación, tanto hacia el equipo, como hacia los
clientes y proveedores (en definitiva, stakeholders)
 Tomar las decisiones necesarias y proponer acciones correctivas
 Para poder hacer todo ello, el Director de Proyecto tiene que tener una
serie de habilidades muy concretas:
 Liderazgo
 Capacidad de comunicación
 Capacidad de Negociación
 Capacidad de resolución de conflictos

Por último, y no menos importante, tiene que ser capaz de mantener el foco del
equipo en el objetivo final del proyecto. A lo largo de la vida de todo proyecto
siempre surgirán problemas y situaciones difíciles que pueden desmoralizar al
equipo, sobre todo en proyectos complejos. Por eso creo que un buen Director de
Proyecto tiene que ser un poco psicólogo y tener la capacidad de sobreponerse a
sus frustraciones y ser capaz de motivar al equipo. La motivación, algo que
estamos cansados de oír en diversos ámbitos (entrenadores deportivos, ...) pero
es una capacidad muy difícil de encontrar, una "rara avis", pero que no debemos
perder de vista. La mejor forma de motivar es "empatizar" con el equipo, dar
ejemplo, y focalizarse en pequeños objetivos a corto plazo, que nos permitan
mantener al equipo "alerta" y alineados y concienciados con la consecución del
objetivo final que perseguimos.

17. La Gestión de Proyectos como Pilar de la Calidad

Siempre hablamos de Calidad y, la mayoría de las veces, nuestro entendimiento
de la calidad se circunscribe al producto sin defectos. Sin embargo, calidad es
algo más que hablar de cero defectos. Calidad es que nuestro producto cumpla las
expectativas del cliente y ahí, en las expectativas, está lo realmente difícil porque,
muchas veces, las expectativas son claras pero en otras ocasiones, no tanto: son
lo que se llaman expectativas implícitas. Y ¿cómo hacemos para asegurar la
calidad en nuestros productos/servicios? La respuesta no es sencilla, pero creo
que un buen proceso de Gestión de Proyectos nos puede ayudar en esa labor.
Tenemos que ser conscientes que la Gestión de Proyectos es una pieza
fundamental a la hora de ofrecer un buen producto/servicio, y por ello tenemos
que profesionalizar la gestión, darle valor (sobre todo en un mercado como el
tecnológico -TIC- donde priman los aspectos técnicos, muchas veces ininteligibles
para el cliente), con el objetivo de reducir el ratio de fracaso de proyectos.

Mejorar la situación actual de muchos proyectos es una labor muy compleja, sin
embargo, creo que al menos deberíamos destacar los siguientes aspectos, clave
para reducir el riesgo de fracaso en los proyectos:

1. Supervisar no es suficiente. Gestionar un proyecto no es usar un Project, es
mucho más.
2. Hay que gestionar las restricciones (gestión continua).
3. Los objetivos del proyecto tienen que ser claros y estar comunicados.
4. Definamos procesos simples y claros. La Metodología no puede ser un fin en si
mismo.
5. Tenemos que estar alineados con negocio. En general, la tecnología no es un
fin en sí mismo, es un medio para alcanzar un objetivo mayor.
6. Los requisitos del proyecto tienen que ser completos, estar documentados y,
sobre todo, acordados con el cliente.

18. 7. Es importante saber manejar los conflictos (siempre habrá: con el equipo, con
otros departamentos, incluso con el cliente)
8. Hay que implicar a todos los afectados/interesados (stakeholders) por el
proyecto.
9. Hay que gestionar constantemente la incertidumbre (gestionar los riesgos
evitando improvisaciones).
10. Hay que tomar decisiones en base a datos medidos: pero ojo, hay que medir
datos relevantes, no medir por medir.
11. Piensa antes de actuar: la planificación no es una pérdida de tiempo.

¿Qué herramientas de planificación usan los Jefes de Proyecto?


Recientemente he leído un post que hacía mención a una encuesta sobre el tipo
de herramientas que suelen usar los Jefes de Proyecto. Podéis acceder a la
encuesta a través de este enlace: PM Survey results project schedule. Al igual que
indica el autor, la mayoría de los resultados no me han sorprendido y, sin entrar en
consideraciones del ámbito de la encuesta, en lineas generales creo que refleja
bastante bien la realidad de la función de gestión de proyectos.

19. Estas son las conclusiones de la pequeña encuesta:

Microsoft Project es la herramienta de planificación más utilizada.

 La mayoría de los Jefes de Proyecto no comparten el cronograma con el
equipo de proyecto.
 La gestión de costes no se hace de forma integrada con la herramienta de
planificación, y se realiza mediante otras herramientas (como puede ser
Microsoft Excel).
 El esfuerzo de los recursos no se gestiona de forma integrada en la propia
herramienta de Planificación.

Esta pequeña muestra saca a la luz lo que a mi entender son algunas de las
grandes debilidades (malas prácticas) que actualmente tienen muchos jefes de
proyecto:

 Muchos proyectos fallan estrepitosamente en la comunicación, y en muchas
ocasiones es culpa de una mal entendida política de privacidad y
confidencialidad. La labor de dirección de proyectos tiene que ser una labor
compartida por todo el equipo de proyecto, aunque la responsabilidad
recaiga sobre el director de proyecto, y para ello es necesario que la
información fluya dentro del equipo. El cronograma es una pieza
fundamental durante la gestión del proyecto, ya que nos permite tener una
visión global de lo que hay que hacer y cual es la situación actual. Cada
miembro del equipo de proyecto no solo tiene que conocer sus tareas, sino
entender como encajan dentro del plan global.
 Si ya es difícil de por si es gestionar un proyecto, más difícil será si tenemos
toda la información desagregada en distintas herramientas que hacen que
el trabajo de actualización de información sea un trabajo laborioso. El
problema es que muchas veces el Project simplemente es usado como una
herramienta para "pintar" el calendario (como si fuera un Excel de registro

20. de tareas y fechas), cuando realmente es un potente gestor (exagerando un
poco podríamos decir que es un pequeño ERP) con el que podemos
gestionar de forma integrada, el tiempo, el esfuerzo y los costes de nuestro
proyecto, pudiendo realizar un seguimiento cuantitativo utilizando modelos
con el EVA (Earned Value Analysis - Análisis del Valor Ganado). Las
causas de este problema seguramente son muy variadas, pero la
formación, o más concretamente, el desconocimiento de la funcionalidad
del project, nos lleva a esta situación.

A la vista de estos datos, y de lo que podemos constatar a nuestro alrededor, se
hace cada vez más importante potenciar la función de gestión de proyecto, y
remarcar que es algo más que realizar una gestión técnica de las tareas de un
proyecto. Tanto las organizaciones como los propios interesados tienen que
preocuparse de cubrir estos gaps en la función de dirección de proyectos, y
aprender a utilizar todo el potencial que las herramientas nos aportan. Pero ojo, no
nos centremos solo en las herramientas, esto solo sería el segundo paso. El
primer paso sería tener la base teórica necesaria sobre la función de dirección de
proyectos que nos aportan guías como el PMBOK (Project Management Body of
Knowledge).

La importancia de la gestión de costes como elemento integrador en las
compañías

No sé si tenéis la misma sensación que yo, pero la ausencia del enfoque en la
gestión de costes es muy acusada en la mayoría de los proyectos, al menos en el
ámbito TIC. Cuando hablas con alguien de un proyecto, siempre destaca las
bondades técnicas, la nueva tecnología o arquitectura que van a usar, la
funcionalidad que va a cubrir, pero nunca se habla de los costes o aspectos
financieros (lo rentable que va a ser para la organización, etc.,...). Muchas veces
parece que la gestión económica es considerada, por muchos jefes de proyecto,
como ese mal necesario para hacer lo que realmente les gusta (normalmente

21. experimentar con nuevas tecnologías, herramientas o arquitecturas). Muchos
hemos tenido esa "deformación" profesional (y me incluyo).

En este breve post, me gustaría resaltar la importancia de la gestión económica en
cualquier actividad, y no lo voy a hacer con la clásica perspectiva de los beneficios
(una empresa tiene que ganar dinero y, si se dedica a hacer proyectos, los
proyectos tienen que ser rentables). La perspectiva que le quiero dar es que la
gestión de costes es como un factor integrador dentro de la compañía. Me explico.
Muchas veces en las organizaciones cada uno de nosotros vivimos en el micro
mundo (departamento) en el que trabajamos y hablamos con nuestros
compañeros de temas comunes, que todos entendemos porque somos del "mismo
entorno". El problema viene cuando tenemos que interactuar con otros
departamentos: os suena las expresiones, "ya están aquí los raros de los
informáticos, no hay quien entienda lo que dicen" o "el usuario no sabe lo que
quiere y solo se fija en las pantallitas", etc. etc. etc. El problema es que en raras
ocasiones nos ponemos en la piel del de enfrente e intentamos hablar su mismo
idioma. ¿Os imagináis una reunión con un abogado, un economista, un informático
y un psicólogo hablando en su propio "idioma" y "jerga"? Saldríamos todos con un
buen dolor de cabeza, después de muchas discusiones y malos entendidos.

Al final es necesario encontrar un lenguaje que todo el mundo entienda, y que nos
permita explicar los proyectos, sus ventajas e inconvenientes, desde un punto de
vista que desde el abogado al economista de la empresa puedan entender, y el
lenguaje económico nos puede ayudar. Por eso, en todos los cursos y seminarios
en los que participio remarco lo importante que es en la actualidad que los equipos
de proyectos, sus miembros, sepan entender el lenguaje económico, gestionen
costes, y sean capaces de vender las bondades de un proyecto desde todos los
puntos de vista: funcional, técnico y, también, económico. En cuantas reuniones
de presentaciones de proyecto habéis estado en las que salís con la sensación de
que nadie os ha entendido, o lo que es peor, con vuestra idea de proyecto
rechazada. Es necesario vender las bondades de un proyecto desde todas las

22. perspectivas, incluso la económica, y que los interlocutores nos comprendan. Por
ello tenemos que familiarizarnos con términos como: VAN (NPV - Net Present
Value), TIR (IRR - Internal Rate of Return) , Rentabilidad, Retorno de Inversión
(ROI - Return on Investment), etc... y tienen que empezar a formar parte de
nuestros indicadores de gestión en los proyectos como un "must be", uno más de
los distintos indicadores de gestión de un proyecto.

Por qué fracasan los proyectos

 Corrupción del Alcance
 Ignorar los Riesgos del Proyecto
 Falta de Implicación de los participantes (usuario, equipo proyecto,...)
 Requisitos Ambiguos
 No se gestionan las expectativas
 Objetivos poco claros
 Ausencia de Planificación formal
 Roles no definidos y/o comunicados
 Estimaciones errores/poco realistas
 Ausencia de metodologías, plantillas y documentación
 Falta de recursos
 Falta de Formación
 Poco o nulo soporte de dirección

23. Principales causas del fracaso de los proyectos
No es fácil enumerar las razones por las que fracasan los proyectos y el motivo es
que son muy diversas. Sin embargo, y después de participar en múltiples
proyectos, yo destacaría las siguientes:
 Falta de implicación/compromiso de los participantes. Equipos
desmotivados por objetivos inasumibles, usuarios del cliente que no creen
en el proyecto y, o no participan o, lo que es aún peor, entorpecen el normal
desarrollo del proyecto, etc... Para que un proyecto salga adelante es muy
importante la participación activa de todos sus implicados.
 Pobre comunicación. Muchos problemas vienen determinados por una falta
de entendimiento incluso, y a veces esto es una crítica a los "técnicos", no
somos capaces de ponernos en la piel del usuario y nos encerramos en
jergas excesivamente técnicas que confunden más que ayudan. Otros
problemas vienen derivados de la falta de fluidez de la información. Muchas
personas llevan a rajatabla la teoría de "la información es poder" y se
convierten en auténticos cuellos de botella en la comunicación del proyecto.

24.  La falta de definición de roles y responsabilidades. Es imprescindible que al
principio del proyecto quede claramente identificado quien es responsable
de cada parte, tanto por parte del cliente como por parte del equipo de
proyecto. El objetivo es evitar el uso de la técnica "balones fuera".
 Gestión de las expectativas. Más allá de una simple definición de requisitos,
a veces falla realmente entender que es lo que espera el usuario/cliente de
este proyecto. Lo difícil es identificar las necesidades no declaradas
formalmente.
Estas y otras situaciones ponen en peligro el normal desarrollo de los proyectos lo
que incrementa el riesgo de fracaso. Pero al final todas estas causas las podemos
resumir en una: POBRE GESTIÓN. Metodologías como el PMBOK (Project
Management Body of Knowledge) definido por el PMI (Project Management
Institute) identifican los procesos y las herramientas que ayudarán a reducir el
riesgo de fracaso de un proyecto


Cuando hablamos de CALIDAD ¿entendemos todos lo mismo?

¿Cómo definirías la calidad? Cuando se habla de calidad lo primero que se nos
viene a la cabeza son defectos/errores, y una serie de procesos y metodologías
que tienen dicho enfoque como Six Sigma (defecto 0), Lean, Metodologías de
Pruebas/Testing,…
Pero... ¿realmente la calidad son solo defectos? Si nos atenemos a como define
el IEEE la Calidad de Software, esta tiene que ser medible y predecible (es decir,
no reactiva) y se basa en tres pilares:

1. Ausencia de defectos
2. Satisfacción del usuario
3. Conformidad con los requisitos

Dicho de otro modo, hablar de calidad es algo más que hablar de errores. El
segundo punto es especialmente importante ya que tiene que ver con

25. percepciones del usuario: la aplicación, el producto entregable, puede funcionar
correctamente pero no satisfacer al usuario, incluso aunque concuerde con lo que
estaba redactado en los documentos de especificación (me viene a la cabeza un
ejemplo clarísimo: seleccionamos la pintura con el pintor, no dudamos, pero
cuando tenemos toda la habitación pintada.... no nos gusta).

Entonces, ¿Qué es la calidad? Calidad es satisfacer las expectativas de nuestros
clientes o, de una forma más amplia, satisfacer las expectativas de los
interesados/participantes (stakeholders) en el proyecto.

Con estas consideraciones, podríamos definir la calidad como:

 La capacidad o aptitud de un producto o servicio para satisfacer las
necesidades y expectativas del cliente, declaradas o implícitas.
Y aquí ha salido otro aspecto especialmente relevante. Las expectativas del
cliente no siempre son explicitas, están ocultas y es labor del jefe de proyecto y
del especialista funcional hacerlas aflorar, aspecto realmente complicado pero
clave para conseguir enfocar bien el proyecto.

¿Qué es la Administración de Proyectos?

La administración de proyectos es la aplicación de conocimiento, habilidades,
herramientas, y técnicas a actividades de proyectos de manera que cumplan o
excedan las necesidades y expectativas de partidos interesados de un proyecto.
Cumplir o exceder las necesidades o expectativas de los partidos interesados
invariablemente involucran balancear demandas que compiten entre sí, tales
como:
•Alcance, tiempo, costo y calidad.
•Partidos interesados con diferentes necesidades y expectativas.
•Requerimientos identificados (necesidades) y requerimientos no identificados
(expectativas).

26. El término administración de proyectos es a veces usado para describir una
aproximación organizacional a la administración de operaciones sucesivas. Esta
aproximación, más propiamente llamada administración por proyectos, trata
muchos aspectos de operaciones sucesivas como proyectos para poder aplicar la
administración de proyectos a ellas. Aunque un entendimiento de la administración
de proyectos es obviamente crítica para una organización que está administrando
por proyectos, una discusión detallada de esta aproximación esta fuera del
alcance de este documento.

El conocimiento acerca de la administración de proyectos puede ser organizado
de muchas maneras. Este documento tiene dos secciones principales y doce
capítulos como se describe a continuación.

El Marco de la Administración de Proyectos

Parte I, el Marco de la Administración de Proyectos, provee la estructura básica
para entender la administración de proyectos.

Capítulo 1, Introducción, define los elementos claves y provee una vista del resto
del documento.

Capítulo 2, El Contexto de la Administración de Proyectos, describe el ambiente
en el cual los proyectos operan. El equipo de administración de proyectos debe
comprender este contexto más amplio — administrar las actividades día a día de
un proyecto es necesario para su éxito pero no es suficiente.

Capítulo 3, Los Procesos de Administración de Proyectos, describe una vista
generalizada de como los procesos varios de la administración de proyectos
interactúan comúnmente. Entender estas interacciones es fundamental para
entender el material que se presenta del Capítulo 4 al 12.

27. Las Áreas de Conocimiento de la Administración de Proyecto

Parte II, las Áreas de Conocimiento de la Administración de Proyecto, describen
conocimiento y prácticas de la administración de proyectos en término de sus
componentes de proceso. Estos procesos han sido organizados en nueve áreas
de conocimiento.

Capítulo 4, Administración de la Integración de Proyectos, describe los procesos
requeridos para asegurar que los elementos varios de un proyecto están
coordinados apropiadamente. Consiste del desarrollo de un plan de proyecto,
ejecución del plan de proyecto, y el control de cambios en general.

Capítulo 5, Administración del Alcance del Proyecto, describe el proceso requerido
para asegurar que el proyecto incluye todo trabajo requerido, y sólo el trabajo
requerido, para completar el proyecto de manera exitosa. Consiste de la iniciación,
planeación del alcance, definición del alcance, verificación del alcance, y control
de cambio al alcance.

Capítulo 6, Administración del Tiempo del Proyecto, describe los procesos
requeridos para asegurar la terminación a tiempo del proyecto. Consiste en la
definición de las actividades, secuencia de las actividades, estimación de duración
de las actividades, desarrollo del cronograma y control de la programación.

Capítulo 7, Administración de los Costos del Proyecto, describe los procesos
requeridos para asegurar que el proyecto es completado dentro del presupuesto
aprobado. Consiste en la planificación de recursos, estimación de costos,
presupuestario de costos, y control de costos.

Capítulo 8, Administración de la Calidad del Proyecto, describe los procesos
requeridos para asegurar que el proyecto satisfacer las necesidades para lo cual

28. fue desarrollado. Consiste en la planeación de la calidad, a seguranza de la
calidad, y control de calidad.

Capítulo 9, Administración de los Recursos Humanos del Proyecto, describe los
procesos requeridos para hacer el uso más eficiente de las personas involucradas
en el proyecto. Consiste en la planeación organizacional, adquisición de staff, y
desarrollo del equipo.

Capítulo 10, Administración de las Comunicaciones del Proyecto, describe los
procesos requeridos para asegurar la generación apropiada y a tiempo, colección,
diseminación, almacenamiento, y la disposición final de la información del
proyecto. Consiste en la planeación de la comunicación, distribución de la
información, reportes de desempeño, y el cierre administrativo.

Capítulo 11, Administración de Riesgo del Proyecto, describe los procesos
concernientes con la identificación, análisis, y respuesta a el riesgo del proyecto.
Consiste en la identificación del riesgo, cuantificación del riesgo, desarrollo de la
respuesta al riesgo, y en el control de la respuesta al riesgo.

Capítulo 12, Administración de la Procuración del Proyecto, describe los procesos
requeridos para adquirir bienes y servicios de fuera de la organización ejecutora.
Consiste en la planeación de la gestión de la procuración, planear la solicitación, la
solicitación, selección de proveedores, administración de contratos, y cierre de
contratos.
El Contexto de la Administración de Proyectos

Los proyectos y la administración de proyectos operan en un ambiente más amplio
que el del proyecto mismo. El equipo de administración de proyectos debe
entender este contexto más amplio - administrar día a día la actividades del
proyecto es necesario para el éxito de este, pero no suficiente. Este capítulo

29. describe aspectos claves del contexto de la administración de proyectos, que no
están descritos en otras partes de este documento. Los tópicos incluidos aquí son:

2.1 Fases del Proyecto y el Ciclo de Vida del Proyecto

2.2 Los Partidos Interesados del Proyecto

2.3 Influencias Organizacionales.

2.4 Habilidades Claves de Administración General

2.5 Influencia Socioeconómicas

Fases del Proyecto y Ciclo de Vida del Proyecto

Porque los proyectos son tareas únicas, involucraran cierto nivel de incertidumbre.
Las organizaciones ejecutaras de proyectos generalmente dividirán cada proyecto
en fases del proyecto para poder administrar mejor los enlaces apropiados con las
operaciones de la organización ejecutara. De manera colectiva, estas fases se
conocen como el ciclo de vida del proyecto.

Características de las Fases del Proyecto

Cada fase del proyecto es marcada por la terminación de una o más entregas.
Una entrega es un tangible, un producto de trabajo verificable tal como un estudio
de factibilidad, un detalle de diseño, o un prototipo que trabaje. Las entregas, y por
tanto las fases, son parte generalmente de una secuencia lógica diseñada para
asegurar una definición apropiada del producto del proyecto.

La conclusión de una fase de proyecto es generalmente marcada por la revisión
de tanto las entregas como del desempeño del proyecto para poder (a) determinar

30. si el proyecto debe continuar a su próxima fase y (b) detectar y corregir errores de
manera eficiente. Estas revisiones de final de fase generalmente se llaman salidas
de fase, puertas de fase o puntos muertos.

Cada fase de proyecto normalmente incluye una serie definida de productos de
trabajo diseñados para establecer el nivel deseado de control administrativo. La
mayoría de estos ítems están relacionados con la entrega de la fase primaria, y las
fases típicamente toman sus nombres de estos ítems: requerimientos, diseño,
construcción, texto, comienzo, entrega, y otros como sea apropiado.

Características del Ciclo de Vida del Proyecto

El ciclo de vida del proyecto sirve para definir el comienzo y el final de un proyecto.
Por ejemplo, cuando una organización identifica una oportunidad a la que le
gustaría responder, autorizará un estudio de factibilidad para determinar si debe
adoptar el proyecto. La definición del ciclo de vida del proyecto determinará si el
estudio de factibilidad es tratado como la primer fase de vida del proyecto o como
un proyecto independiente.

La definición de ciclo de vida del proyecto determinará también que acciones de
transición se incluirán al final del proyecto y cuáles no. De esta manera, la
determinación del ciclo de vida del proyecto puede ser usado para enlazar el
proyecto a operaciones sucesivas de la organización ejecutora.

La secuencia de fase definida por la mayoría de los ciclos de vida del proyecto
generalmente involucra algún tipo de transferencia en tecnología o intercambios
tales como los requerimientos para diseñar, construcción para operaciones o
diseño para manufactura. Entregas de la fase precedente son usualmente
aprobadas antes que comience el trabajo en la fase siguiente. Sin embargo, una
fase subsiguiente es a veces comenzada antes de la aprobación de las entregas

31. de la fase anterior cuando los riesgos involucrados se tornan aceptables. Esta
táctica de traslapo de fases muchas veces es llamada "Fast Tracking".

Los ciclos de vida del proyecto generalmente definen:
•Qué trabajo técnico debe ser hecho en cada fase (ej. ¿Es el trabajo del arquitecto
parte de la fase de definición o de la fase de ejecución?).
•Quién debe estar involucrado en cada fase (e.g. ingeniería concurrente requiere
que los implementores estén involucrados con los requerimientos y los diseños).

Las descripciones de los ciclos de vida del proyecto pueden ser o muy generales o
muy detallados. Las descripciones altamente detalladas tienen muchas formas,
tablas y lista de chequeo para proveer estructura y consistencia. Tales
aproximaciones de detalle son llamadas a veces metodologías de administración
de proyectos.

La mayoría de las descripciones de ciclo de vida del proyecto comparten un
número de características comunes:
•Los niveles de empleados y costos son bajos al comienzo, más altos hacia el
final, y caen rápidamente a medida que se llega a la finalización. Este patrón se
ilustra en la Figura 2-1.


•La probabilidad de completar exitosamente el proyecto es más bajo, y por lo tanto
el riesgo e incertidumbre son altos, al comienzo del proyecto. La probabilidad de
completar exitosamente generalmente se vuelve progresivamente más grande a
medida que el proyecto continúa.
•La habilidad de los partidos interesados para influenciar las características finales
del producto del proyecto y su costo final son más altas al comienzo y se vuelven
progresivamente más bajas a medida que el proyecto continúa. La contribución
más grande de este fenómeno es que los costos de cambio y de corrección de
errores generalmente se incrementan a medida que el proyecto continúa.

32. Se debe tener cuidado para distinguir entre el ciclo de vida del proyecto y el ciclo
de vida del producto. Por ejemplo, un proyecto desarrollado para introducir una
nueva computadora al mercado es solo fase del ciclo de vida de un producto.

A pesar de que muchos ciclos de vida del proyecto tienen nombres de fases
similares con trabajo similar requerido para los productos, muy pocos son
idénticos. La mayoría tienen cuatro o cinco fases pero algunos tienen nueve o
más. Aún dentro de una sola área de aplicación pueden haber variaciones
significativas - un ciclo de vida de desarrollo de software de una organización
puede tener una sola fase de diseño mientras que la de otra organización puede
tener fases distintas para el diseño funcional y de detalle.

Los subproyectos dentro de proyectos pueden también tener ciclos de vida de
proyectos distintos. Por ejemplo, una firma de arquitectura contratada para diseñar
un nuevo edificio de oficinas está primero involucrada con la fase de definición del
dueño cuando está elaborando el diseño y en la fase de implementación del dueño
mientras que da soporte al esfuerzo de construcción. El proyecto de diseño del
arquitecto, sin embargo, tendrá sus propias series de fases que van desde el
desarrollo conceptual pasando por la definición, implementación y cierre. El
arquitecto puede inclusive tratar el diseño y el soporte a la construcción como
proyectos separados con sus propias fases distintas.

http://www.liderarproyectos.com/