¿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.

•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

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

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

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?

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.

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.

¿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

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.

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

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.

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

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.

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.

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

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.

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.

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.

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

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

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

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

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.

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

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).

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.

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

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

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

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

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.

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/