I TEMA

Administración de Proyectos

Aunque suene a cliché la popular frase que dice "todo en la vida en un proyecto", puede resultar verdadera
hasta cierto punto, pues la mayoría de las veces nos encontramos planificando actividades tomando como
base lo que queremos lograr con dicha labor, asegurándonos de disponer de los recursos adecuados para
alcanzar el objetivo deseado, obviamente midiendo factores de riesgo que podrían afectar la consecución de
la meta.

Aunque no todo puede plantearse como un proyecto, pues hay que recordar que existen rutinas o tareas
rutinarias que sin duda no se les puede considerar como proyectos.

De acuerdo a la máxima organización de administración de proyectos del mundo, el Project Management

Institute (PMI®) en su Project Management Body of Knowledge (PMBOK®) "Un proyecto es un esfuerzo
duradero que se lleva a cabo para crear un producto, servicio o resultado único. La naturaleza temporal de los
proyectos indica un principio y un final definidos. El final se alcanza cuando se logran los objetivos del
proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos, o
cuando ya no existe la necesidad que dio origen al proyecto".

Observando esta definición, tenemos varios factores a destacar:

Esfuerzo; se emplean una serie de elementos, recursos, energía y vigor con miras a lograr el fin planteado.

Temporal; tiene un inicio y un fin claramente definido, aunque obviamente puede variar de proyecto a
proyecto, ya que algunos pueden durar 2 ó 3 meses, mientras que otros de acuerdo a su naturaleza llegan a
demorar varios años.

Creación; el fin de todo proyecto es la generación de algo ya sea tanginble o intangible.

Único; el resultado del proyecto tiene como característica la singularidad, es decir, lo generado por el
proyecto es distinto a lo ya existentes. Obviamente, existen proyectos de mantenimiento o de creación de
productos cuyos productos finales son muy similares, pero siempre habrá algún elemento, característica o
actualización que le dará la cualidad de unicidad.

Una vez vista estas características, vale la pena destacar que la administración de proyectos consiste en la
implementación de todos los conocimientos, capacidades, habilidades, técnicas, metodologías, herramientas y
todos los recursos que se dispongan para desarrollar las actividades y trabajos inherentes a un proyecto,
permitiendo cumplir con los requerimientos por los cuales el proyecto se está llevando a cabo.

La administración de proyectos es sin duda un concepto muy amplio cuya aplicación óptima dependerá de la
experiencia del administrador de proyectos y su equipo; complejidad del proyecto; participación e intervención
de los interesados del proyectos; administración de riesgos; disponibilidad de recursos; buen entendimiento
del alcance real que se pretende con el proyecto; aplicación de procedimientos de aseguramiento y control de
la calidad; seguimiento al cronograma establecido; entre otros múltiples factores que intervienen en la
administración de proyectos.

Si te estás iniciando o ya formas parte del apasionante mundo de la administración de proyectos te

recomendamos inscribirte al boletín quincenal de LiderDeProyecto.com, en el cual podrás obtener
contenido valioso sobre los acontecimientos más actuales en administración de proyectos. Además tendrás
acceso a las secciones exclusivas de videos, manual de administración de proyectos y áreas de
conocimiento.

Del mismo modo puedes acceder a LiderDeProyecto.com a través de Facebook y Twitter, para que le des
seguimiento a las últimas actualizaciones que tenemos preparadas para ti.
Proyecto y administración de proyectos

Antes de involucrarnos en el apasionante tema de la administración de proyectos, es necesario conocer de

manera clara el significado de las palabras que le componen.

A manera de introducción a continuación les presentamos las definiciones de administración y proyecto, para
luego entonces, enumerar las características y áreas que componen la administración de proyectos.

Qué es la administración:

Es el proceso de planear, organizar, dirigir y controlar, las actividades y el uso de los recursos con el fin de
lograr uno o más objetivos.

Qué es un proyecto:

Es un trabajo o esfuerzo que se ejecuta una sola vez y que persigue un fin específico, y tiene como
característica principal producir resultados únicos como un producto o un servicio.

Para alcanzar el fin establecido, es necesario definir objetivos o metas (qué hacer) y actividades o procesos
(cómo hacer) que deberán cumplirse en un tiempo asignado, considerando para ello el inicio y termino del
mismo.

Necesario es entonces también, la asignación y organización de todos los recursos involucrados para su
ejecución.

Para su ejecución y éxito, el proyecto debe seguir una serie de pasos realizados por roles involucrados, para ir
cumpliendo objetivos y/o desarrollando/utilizando productos y recursos.

En consecuencia podemos decir que los principales parámetros de un proyecto son:

 Alcance
 Recursos (costo del esfuerzo principalmente)
 Tiempo

Dichos parámetros reúnen las 2 características siguientes:

1. Cada parámetro es función de los otros 2

2. Mover un parámetro implica cambios a los otros (por lo menos a 1)

En conclusión podemos decir que un proyecto es la ejecución en un momento determinado de un proceso o

actividades con un tiempo, un costo y un alcance definido y es el principal objetivo del líder de proyecto el
planearlos y controlarlos.

Perfil del Líder de Proyecto

El líder de proyecto, o administrador de proyectos, es responsable de administrar proyectos desde que inicia
hasta que se completa.

Entre sus responsabilidades se incluye:

 el desarrollo del plan del proyecto,

 la identificación de los requerimientos y el alcance del proyecto,
 la comunicación,
  la administración de los recursos humanos y materiales,
 el control de tiempos,
 identificación y control de riesgos,
 administración de los costos/presupuesto, el aseguramiento de la calidad,
 el reporte y evaluación del desempeño del proyecto.

El líder de proyecto debe mantener su foco en asegurar que el proyecto se termine en el tiempo y presupuesto
planeado, y muy frecuentemente con tiempos limitados.

Algunas de las cualidades que uno debe tener para convertirse en un buen líder de proyecto son las
siguientes:

 Organizado y metódico
 Facilidad para relacionarse con gente
 Buena comunicación oral y escrita
 Liderazgo
 Conocimientos técnicos básicos
 4 Consejos prácticos sobre administración de proyectos
 Por Gerardo Ornelas
 En esta ocasión me gustaría proporcionar algunos consejos prácticos, dirigidos a aquellos
compañeros que comienzan a trabajar en la administración de proyectos.
 Cuando hacemos referencia a la terminología y al término de administración de proyectos, en
ocasiones nosotros mismos nos bloqueamos, pensando que si no estamos certificados no podemos
retomar un proyecto y mucho menos cumplir la meta, que es lograr los resultados con la menor
desviación en costo y tiempo de lo planeado.
 La teoría de lo que nos recomienda el PMI® y las técnicas que podemos aplicar en la ejecución de
un proyecto, en este caso, se convierten en nuestros aliados y en nuestra referencia más próxima
para lograr el objetivo.
 Es por ellos que para comenzar lo primero que hay que tener en cuenta es que queremos lograr
nuestro objetivo y sacar de esto un resultado tangible y para eso sugiero los siguientes consejos.
 Primer consejo
Si aun no eres un PM certificado, lo que recomiendo es que no trates de implementar y controlar
TODAS las áreas que se tocan en el PMBOK®. Es decir, solo trata de explotar y de aprender de un
grupo de ellas. Date tiempo de aprender y dominarlas. Una vez que vayas aplicando esas y sientas
que ya las dominas, aplica otras diferentes, así hasta que hayas tocado todas las áreas.
 Segundo consejo
Con el tiempo, te vas a dar cuenta de que no tienes la misma habilidad para todas las áreas, es
decir, tal vez seas muy buen comunicador, pero se te dificulta llevar bien el control de la
retroalimentación de las actividades de los integrantes de tu equipo, o eres muy bueno para prevenir
y manejar los riegos pero se te dificulta controlar o como se dice comúnmente –tener ojo clínico- en
la parte de los recursos humanos. Para esos casos, es bueno que ya sepas que son importantes
esas áreas, pero también es muy bueno, que conozcas cuales son tu limitantes y en esos casos, lo
que aconsejo es que te apoyes de uno o varios colaboradores que sean buenos haciendo lo que a ti
se te dificulta mas. Eso será mucho mejor para el proyecto, que seguir empeñado en que las cosas
las tengas que hacer y controlar siempre tu.
 Tercer consejo
Una de las cosas que se nos recomienda mucho es que documentemos, que documentemos y que
sigamos documentando. Cuando apenas haz participado en dos o tres proyectos, seguro que
recuerdas todo lo que se ha documentado y podrás en poco tiempo retomar las lecciones
aprendidas. Pero que pasa cuando ya son mas de 5 o 6, y de repente te topas con otro proyecto mas
y quieres ver lecciones aprendidas sobre la gestión de permisos de construcción o de como se
registra un dominio web. El tercer consejo va en relación a que todo o que documentes lo ordenes y
lo clasifiques en algún medio que te permita hacer consultas por dicha clasificación, pudiendo ser
desde una hoja electrónica hasta una sofisticada bases de datos. Esto es porque una vez que tú
tengas todo documentado de esa forma, cuando quieras consultar, solo haces un filtro por el tipo de
asunto que quiere obtener y tendrás mejores resultados en tiempo.
 Cuarto Consejo
Adapta de las herramientas y técnicas lo que a ti te acomode más, según el tipo y restricciones del
 proyecto. Esto quiere decir que no hay que poner en práctica al pie de la letra TODO lo que el PMI®
nos sugiere, porque tal vez no tenemos todos los recursos necesarios, en tiempo, ni financieros para
ponerlos en práctica.
Entonces solo hay que tomar lo que podamos manejar según el presupuesto y el alcance. De no
hacer esto, podemos caer en le error de no continuar con proyectos viables, solo por decir que no
podemos tener a los recursos humanos y financieros deseados, pero tal vez podemos hacer ajustes
en algunos roles y en algunas formas de llevar el proyecto con algunas limitantes o restricciones.
 Bueno, me despido de ustedes esperando que estos sencillos y prácticos consejos les sean útiles
para aquellos que empiezan en este fascinante mundo de la administración de proyectos.


 Qué se requiere para ser mejor administrador de proyectos-

¡yendo más allá de la administración de proyectos!
Por Suresh Malladi [ acerca del autor ]
 Los Administradores de Proyectos aseguran una ejecución exitosa de proyectos, planeando,
organizando, dirigiendo, monitoreando, controlando y cerrándolos. Los administradores de proyectos
exitosos utilizan diversas herramientas, técnicas, metodologías, marcos y procesos para monitorear
de cerca los proyectos y llevarlos a cabo en su totalidad. Lo que los hace mejores Administradores
de Proyectos es su habilidad para ver mas allá de los proyectos y crear un ambiente donde los
valores son valuados, la integridad es aplaudida y donde la competencia personal y profesional
prospera. El propósito de este artículo es remarcar una media docena de áreas que pueden hacer la
diferencia.


 Crea el Ambiente del Proyecto

El crear un ambiente del proyecto donde todos los stakeholders pueden participar libremente es
esencial para una administración de proyectos exitosa. Los Administradores de Proyectos deben
identificar a todos los stakeholders y sus necesidades en cuanto a información. Balancear los
requerimientos de varios stakeholders e involucrándolos en el momento adecuado ayudará a definir
los objetivos del proyecto. También se debe asegurar que los stakeholders recibirán oportunamente
información del proyecto y en el formato deseado.
Los proyectos de hoy en día están siendo ejecutados en un contexto geográfico mucho mas amplio;
A veces debido al outsorcing. En éste caso, múltiples factores como el lenguaje, zonas de tiempo,
cultura, estilos de comunicación, etc entran en escena. Los Administradores de Proyectos deben
asegurar que todos estos factores son tomados en cuenta dentro de las metodologías de
administración de proyectos.
Líneas de comunicación claras , roles y responsabilidades bien definidas son vitales para el éxito en
tal contexto. Durante el proyecto, los administradores deberían crear un ambiente donde los
miembros del equipo puedan interactuar uno con otro para compartir libremente ideas sobre el
proyecto. Esto ayuda a los miembros del equipo a trabajar eficazmente y a ejecutar mejor. Los
clientes o stakeholders tendrán gran sabiduría y los administradores deberían de pensar en formas
para absorber el conocimiento y sabiduría de tales stakeholders. El administrador de proyectos
debería también asegurarse de que toda la información y artefactos necesarios del proyecto están
disponibles para el equipo de manera oportuna. Deberá procurar las herramientas, plantillas y
documentación necesaria para que el proyecto despegue y siga sin problemas. El deberá asegurarse
de que todas las políticas, leyes, reglas y normas sean publicadas y respetadas.
 Asesore el equipo y fomente el trabajo en equipo
 Los administradores deberían de proporcionar asesoramiento y liderazgo de pensamiento a los
miembros del equipo. Estos consideran que el administrador es más experimentado en dominios de
funcionalidad, negocios y técnicos y los administradores de proyectos deberían ayudarlos en estas
áreas de competencia personal. Los administradores deberían asegurarse de que los miembros del
equipo están contribuyendo eficazmente al proyecto. Los administradores deberían identificar las
eficiencias y deficiencias de los miembros del equipo y deberían trabajar con ellos para definir los
 objetivos personales y los medios para alcanzarlos.
Los Administradores deberían asegurarse que las aspiraciones profesionales de los individuos se
están cumpliendo, que el entrenamiento necesario es identificado y atendido y debería mantener
entre los miembros del equipo, un sentimiento de que alguien está cuidando sus necesidades y
aspiraciones
 Los administradores también deberían darle al equipo confianza en que tienen alguien a
quien respetan y admiran.
Llevando a cabo revisiones y proporcionando retroalimentación al final de casa fase o proyecto es
una responsabilidad crucial de un Administrador de Proyectos. Los administradores de proyectos
deben asegurarse de que los individuos reciban retroalimentación acerca de su rendimiento. El
reconocer las contribuciones de los miembros del equipo también ayudará a que el equipo haga
contribuciones mas eficaces y que tenga una participación más activa. Además de esto, la
disponibilidad del administrador de proyectos para aprender y escuchar a los demás aumentará su
capacidad personal y promoverá un sentimiento de que las ideas individuales y contribuciones serán
solicitadas y apreciadas.
 Comparte tu sabiduría y experiencia
 Los Administradores de proyectos obtienen conocimiento y experiencia de sus proyectos pasados y
presentes. Las prácticas de proyectos deberían ser registradas y una vez que el proyecto culmina
exitosamente, todas las buenas prácticas se volverán las “mejores prácticas” cada vez que se
repliquen en proyectos subsecuentes.
Los administradores de proyectos deberían estar al tanto de sus prácticas exitosas y debería
compartirlas con otros en la organización. Registrar la información en un tipo de Oficina de
Administración de Proyectos ayudará a esparcir el conocimiento. Los administradores de proyectos
también deberían de contribuir en diarios o boletines con artículos de administración de proyectos
para que la sabiduría y experiencia pueda ser de ayuda para otros. La documentación y
almacenamiento de artefactos de proyectos, llevar a cabo sesiones de lecciones aprendidas, etc.
creará un repositorio de información relacionada a proyectos incluyendo artefactos, éxitos y fracasos.
 Se honesto y enfócate en el cliente

Los Administradores de proyectos deberían de promover la honestidad e integridad. Proporcionando

información honesta acerca del proyecto ayudará a entender el estatus, planear riesgos,
salvaguardar errores, etc. Los administradores deberían proporcionar actualizaciones verdaderas
acerca del estatus del proyecto aunque esto signifique malas noticias. Esto ayuda a trabajar con los
stakeholders y brinda los mecanismos de corrección necesarios a donde deben estar. Los reportes
de estatus, juntas y otras discusiones del proyecto deberían proporcionar una imagen clara de que es
lo que está sucediendo.
Cuando se trabaje como un administrador de proyectos local o vendedor, es muy importante proteger
la propiedad intelectual y asegurar la confidencialidad, garantía y seguridad de los activos de
información
El cliente es lo principal y todas las actividades en el proyecto deberían estar basadas en los
intereses del cliente puesto que el está por arriba de todo lo referente al proyecto, equipo u
organización. Cuando se trabaje con clientes, es mejor proporcionar al cliente de frente el estatus de
posibles dificultades y buscar medidas junto con el cliente, para reducirlas. Esto ayudará no solo al
proyecto, sino también cultivará una relación de confianza con el.

Sea humano, Ético y legal

Como se menciona en las secciones anteriores, un Administrador de Proyectos debería

Cuidar las necesidades del equipo y tener empatía con los individuos. El debería estar listo para
tomar acción cuando una crisis emerja, debería ser capaz de proteger al equipo contra los factores
negativos que impactan en el proyecto, debería asegurar que el equipo está al tanto de las normas y
costumbres que sean contrarias a lo irrespetuoso y debería medir si hay alguna barrera especial en
términos del lenguaje, cultura y costumbres.
Esto toma importancia en un escenario de outsourcing donde los proyectos abarca varias áreas
geográficas. En tal caso, el Administrador del Proyecto debería asegurar que todas las barreras de
comunicación sean derribadas y que si se realice en caso de existir, algún entrenamiento especial
para eliminar las diferencias culturales y lingüísticas.
 El administrador de Proyectos debería ser proactivo y tomar la responsabilidad por errores en vez de
culpar a otros; particularmente el equipo del proyecto. El debería tomar la responsabilidad de cumplir
todos los niveles de servicio a los cuales se comprometieron y a las obligaciones por contrato. El
debería constantemente motivar al equipo y ayudar a realizar sus aspiraciones y ambiciones. El
debería asegurar la capacidad personal y del equipo. El es responsable personalmente de guiar el
 proyecto para asegurar que todos los requerimientos legales, éticos, contractuales y de cumplimiento
son cubiertos. La regla es nunca desviarse de lo que es correcto.
 Solucione Conflictos y Contradicciones

Los proyectos tienen muchos stakeholders y la diversidad aumenta si los proyectos están esparcidos
geográficamente. Los intereses de diversos stakeholders debería ser considerada y balanceada. En
un escenario global, los administradores de proyectos se encuentran con diversidad cultural y
deberían tener sensibilidad con otros grupos, sus costumbres sociales y su forma de hacer negocios.
Esta diversidad de stakeholders, sus expectativas y sus orígenes, abre la posibilidad de que haya
conflicto y el administrador del proyecto debe balancear esta situación mediante la negociación
apropiada y la resolución con el uso de discusiones y balance de intereses. De la misma manera, el
debería identificar las cualidades necesarias para triunfar en un escenario de varias culturas y
asegurar que los mecanismos de comunicación cumplen con esas cualidades.
 Conclusión
 En resumen, un Administrador de Proyecto debería proteger los intereses de los stakeholders,
debería hacer siempre lo que es correcto para el proyecto y lo que es éticamente y legalmente
correcto, debería ser humano y apoyar los requerimientos del equipo y debería asegurarse de que
los mecanismos apropiados se lleven a cabo para atender un ambiente mas amplio donde se tienen
los proyectos. Su disponibilidad a aprender, su generosidad para admitir y la inclinación por compartir
con los demás harán que se incremente su capacidad personal y se ganará el respeto de otros.

Siete razones para pertenecer a la elite de los PMP®

Por Serge

Hoy en día, la mayoría de los que supervisan o administran proyectos importantes, o los que gustan de
mantenerse a la vanguardia en las buenas prácticas de administración de proyectos, han escuchado o leído
acerca de la certificación PMP® para administradores de proyectos. Quizás algunos no entiendan del todo de
qué se trata, pero por lo menos ya conocen de su existencia.

Para no dedicarle demasiado tiempo en explicarlo, para aquellos que aún no entienden de que se trata.
Consiste en una certificación otorgada a los profesionales en administración de proyectos, por parte del
organismo más importante de administración de proyectos en el mundo (el PMI®). Es considerada como uno
de los principales reconocimientos que puede tener un profesional en el conocimiento de las buenas prácticas
de administración de proyectos. Prácticas que se encuentran recopiladas en el PMBOK®.

Según algunas encuestas, la opinión que se tiene con respecto a las certificaciones en administración de
proyectos es la siguiente: son populares, cada vez más reconocidas en el mercado, no reflejan
completamente las habilidades de la persona, pero lo diferencian del resto de los candidatos a una oferta de
trabajo en su currículum vitae.

La popularidad es clara, cuando vemos que ya son alrededor de 270,000 las personas certificadas en el
mundo. Y entonces parecería obvia la pregunta de si vale la pena obtener dicha certificación. Pero, vamos a
analizar a continuación las razones por las cuales la mayoría de la gente decide invertir un esfuerzo especial
en obtener dicha certificación para que tú mismo puedas decidir si te motivaría realizar el esfuerzo que esto
implica.

Algunas de las principales causas que se me ocurren en este momento, y por las cuales la gente se motiva a
buscar esta certificación son enlistadas y explicadas a continuación:

 Reconocimiento
  Seguridad económica
 Desarrollo profesional
 Estatus social
 Ventaja competitiva individual y empresarial
 Nivel de vida
 Éxito profesional y económico

Reconocimiento. Es normal que busquemos que nuestro trabajo sea reconocido por los demás. Y esta
certificación nos pone una “estrellita en la frente” que nos distingue de entre el resto de los profesionales. Por
supuesto, eso no es suficiente, pues habrá que demostrar en los proyectos nuestra capacidad, para mantener
dicho reconocimiento.

Seguridad económica. Al comparar algunos de los sueldos de líderes/administradores de proyecto con

certificación y sin certificación; nos encontramos que las ofertas de empleo de administradores de
proyectos muestran una obvia diferencia entre los certificados y los no certificados, por lo menos en países
como México. Así que si quieres ganar más como administrador de proyecto, una forma casi segura sería
obteniendo esta certificación.

Desarrollo profesional. Los administradores de proyectos suelen empaparse de nueva información y

conocimiento de manera constante. Esto los mantiene al día en los sucesos en el mundo y en las posibles
oportunidades. Como consecuencia, no es raro que su panorama abra y se sientan motivados a ir
evolucionando en el campo profesional, buscando nuevas responsabilidades y retos que les permitan
desarrollarse cada vez más; incluso en el extranjero. Por supuesto que hay excepciones, y hay gente que se
conforma rápidamente en su vida con alguna posición y no hace un mayor esfuerzo por seguir avanzando.
Pero, para los que buscan esa evolución constante, la certificación PMP® traza un camino claro en este
sentido y abre nuevas oportunidades para quien desea explorarlas.

Estatus social. De forma natural el ser humano es un ente social, y tiene la necesidad del satisfacer un
sentimiento de pertenencia. Pertenencia a un grupo: familiar, de amistades, político, intereses, etc. Y en este
sentido, nos sentimos tentados a la exclusividad de pertenecer a un grupo especial en el que sabemos que no
cualquiera puede entrar. Por extraño que parezca, y quizás de una forma no tan consciente, una gran
proporción de certificados obtienen en este sentido una de sus principales satisfacciones como consecuencia
de la certificación.

Así como pocas son las personas que compran un BMW realmente por sus especificaciones técnicas, sino
por el estatus que les brinda, muchos esperan diferenciarse del resto de los administradores al contar con una
certificación de este nivel. En primer lugar, logran sentirse parte del grupo exclusivo de PMP®s, pero después,
para muchos de ellos se abre la posibilidad de pertenecer al grupo de los líderes de proyecto, al grupo de los
líderes de proyecto senior, al grupo de los gerentes de proyecto o incluso al súper exclusivo grupo de los
directores de proyectos. Y tú ¿a qué grupo quieres pertenecer?

Ventaja competitiva individual. Vivimos en un mundo donde la competencia es cada vez más fuerte. Incluso
ya no sólo para sobresalir, sino tan sólo para sobrevivir. La cantidad de profesionales que salen de las
universidades es cada vez mayor, y suelen salir cada vez más preparados en las últimas tendencias.
Profesionales de amplia experiencia, y ya no tan jóvenes desde la perspectiva moderna de las empresas
(…digamos de 35 años en adelante), tienen que competir contra jóvenes sin tanta experiencia, pero que son
preferidos por las empresas por precio, tipo de conocimiento, por considerarlos menos problemáticos
laboralmente, y por Dios sabe cuántas otras razones. El profesional tiene que mostrar con la mayor cantidad
de elementos posibles que hay una ventaja real e importante al elegirlo a este sobre los demás. La
certificación PMP® es hoy en día un punto que resalta en los currículos de la gente, y quien busca a un
administrador de proyectos, en la mayoría de las ocasiones suele colocarlo en la lista de las principales
opciones.

Ventaja competitiva empresarial. Las empresas hoy en día buscan a los PMP®s por la crisis que se suele
vivir en los proyectos, y reconocen que muchos de los problemas podrían haberse solucionado con la
aplicación de buenas prácticas de administración de proyectos. Saben que institucionalizar la preparación de
sus líderes de proyecto internos para certificarlos implica una fuerte inversión en tiempo y dinero por lo que en
muchos casos prefieren contratarlos ya certificados.

Además, las empresas que subcontratan el desarrollo de proyectos exigen ahora a sus proveedores de
proyectos ciertos requisitos que demuestren que siguen buenas prácticas, pues son pocas las empresas que
no han vivido dolorosos fracasos en sus proyectos que ya no están dispuestos a vivir. Las certificaciones a
nivel empresa o individual son una de las formas más simples de asegurar que, por lo menos, se conocen las
buenas prácticas dentro de la empresa proveedora. Cada vez son más las licitaciones a proyectos
importantes donde se exige, simplemente para competir, que el líder del proyecto ostente la certificación como
PMP®.

Nivel de vida. La presión en los proyectos es muy grande y en ocasiones desgastante. Ser líder de proyecto,
al contrario de lo que muchos pensarían, mantiene a la gente en jaque gran parte del tiempo, en especial
cuando se acercan las fechas de entrega, ya sea al final de las fases o del proyecto. O ahora que los
proyectos se dividen en pequeñas iteraciones, resulta que en cada iteración viene nuevamente la presión (sin
pretender desvirtuar los beneficios de dicho esquema de trabajo, por supuesto). Esto ocasiona que los
profesionales de proyectos tengan poco tiempo para su vida personal, fuera de su trabajo. El tiempo con la
familia y los amigos es sacrificada al tratar de salvar al proyecto de una crisis; y por supuesto al tratar de
salvar el empleo por un fracaso en un proyecto.

La aplicación de las buenas prácticas recomendadas en las áreas de conocimiento del PMBOK®, fuente de
estudio y preparación para la certificación del PMP®, ha demostrado en miles de proyectos que las cosas
pueden ser más fáciles o menos estresantes de lo que para muchos administradores resulta. Y que la gente,
como efecto secundario benéfico, puede tener tiempo para ellos mismos y no sólo para arreglar problemas del
proyecto. Así que quien decide certificarse como PMP® se ve obligado a aprender estas buenas prácticas, y
al irlas aplicando descubre este tipo de beneficios.

Éxito profesional y económico. Para muchas personas, parte del éxito, está asociado al desarrollo profesional
y económico, y como ya vimos la certificación como PMP® nos abre puertas a las cuales de otra forma sería
difícil tener acceso. Podemos aspirar a puestos importantes y a sueldos más interesantes dentro de las
empresas. Además, cuando la aplicación de las buenas prácticas nos permite completar exitosamente nuestro
trabajo logrando los objetivos de nuestros proyectos es en sí una gran satisfacción para quienes nos
involucramos en este tipo de esfuerzos. Es cuando decimos: ¡valió la pena el esfuerzo!

Razones para no buscar la certificación

Por supuesto, habrá unos pocos que pondrán como pretexto que el costo en tiempo y dinero para lograr la
certificación es un impedimento para buscarla. La verdad es que el ser humano tiende a sabotearse a sí
mismo en la búsqueda del éxito e inventa mil razones para no lograrlo. El subconsciente del ser humano suele
estar programado con razones equivocadas por las cuales no es bueno escalar al siguiente nivel. Por lo que
para esas personas cualquier pretexto será suficiente para evitar el esfuerzo, y muy dentro, quizás la
verdadera razón no tenga que ver con el esfuerzo mismo o el costo, sino por el miedo a “las alturas”.

Ahora sólo le queda a analizar a cada quien si alguno de los puntos mencionados puede ser la motivación
para buscar este tipo de certificaciones. Y si decides iniciar tu plan personal de certificación, comprométete
contigo mismo para alcanzarlo, pues no es un camino fácil. Ya sea que te apoyes en liderdeproyecto.com o en
cualquier otro, lo importante es que logres tu objetivo.

A nosotros (liderdeproyecto.com) sólo nos resta ofrecerte nuestra ayuda para así cumplir nuestra misión de
apoyar a los profesionales en la administración de proyectos a desarrollarse profesionalmente. Con todo gusto
podremos acompañarte y asesorarte en el camino para lograr tu certificación. Ya sea que necesites tips,
preparación en las áreas de conocimiento del PMBOK® por medio de algún curso o con nuestro manual de
administración de proyectos, o si necesitas prácticar en la aplicación del examen de la mano de un
experto, nos sentiremos honrados en poder apoyarte y enterarnos en algún tiempo que has conseguido tu
objetivo de certificarte o simplemente de mejorar el resultado de tus proyectos.
 Cualquier información que necesites para que te apoyemos en la búsqueda de tu desarrollo profesional, ya
sea con la certificación o con la aplicación de las buenas prácticas, con gusto buscaremos la manera de
apoyarte. Ya sea buscando en este sitio o escribiéndonos para cualquier duda a
[email protected], con gusto te responderemos.

El Triángulo de Administración de Proyectos

El concepto básico que todo administrador de proyectos debe de manejar es el referente al triángulo de
administración de proyectos. Se trata de tener muy claro desde un principio cuál es el alcance del proyecto, el
tiempo requerido y los recursos/presupuesto necesario para completarlo.

Son los tres parámetros básicos con los que tendrá que lidiar el administrador de proyectos y que, al final,
determinarán en gran medida si el proyecto fue o no exitoso.

En un principio hay que identificar cuál es el alcance del proyecto, es decir cuáles son los requerimientos a
satisfacer en el proyecto. Con base en esta información podemos determinar cuántos recursos (gente,
herramientas, presupuesto) necesitamos para poder desarrollarlo. Pero, esto dependerá del tiempo en el que
se requiera completar el proyecto. Si tenemos disponibilidad de recursos, entonces podremos reducir el
tiempo. Si no hay presión de tiempo entonces podremos disponer de menos personal y recursos para poderlo
completar.

Si se nos da flexibilidad en cuanto al alcance a cubrir, entonces podremos reducir tiempos y/o recursos para el
proyecto.

Nuestro cliente en el proyecto nos puede restringir dos de los tres parámetros, pero nunca los tres. Cuando
inicies un proyecto dale a escoger 2 de 3: alcance, tiempo o costo. Si pretende imponerte los 3 la probabilidad
de tener un proyecto exitoso será cercana a cero.

Determinar los tiempos y costos es una tarea de por sí complicada. Y si decides aceptar una fecha límite con
recursos limitados con un objetivo o alcance no negociable, entonces estás en serios problemas.

Y si se da el caso de que tú y tu equipo sobrevivan al proyecto y lo terminen bajo estas condiciones, muy
probablemente el nivel de calidad del producto terminado dejará mucho que desear. Comenzar un proyecto
con un plan de trabajo irreal es la mejor fórmula para fracasar en la administración de tu proyecto.

Claro que también existe la posibilidad de dar atole con el dedo diciendo que sí a todo lo que pide el usuario
(incluyendo tiempos y costos). Y al final del proyecto no le importe cómo se terminó. Aunque corres el riesgo
de ser señalado como el culpable principal del fracaso del proyecto con las consecuencias correspondientes.

La importancia de la carrera profesional de administración de proyectos

Por Jaime González [ acerca del autor ]

Los proyectos son la forma como se aterrizan y concretan los planes tácticos y estratégicos en todas
las ramas de la economía. Ni más ni menos.
Prácticamente la totalidad de las personas que lean estas líneas han llegado a desarrollar un interés en la
administración de proyectos como carrera profesional. Muy probablemente, este interés esté motivado por el
deseo (quizás en distintos grados, pero se trata de un legítimo y sano deseo) de superación de su calidad de
vida tanto personal como de trabajo.

Me va a disculpar la Secretaría de Educación Pública (estoy hablando de la de México, aunque se podría

tratar de un organismo equivalente en otro país), y en especial su Dirección General de Acreditación,
Incorporación y Revalidación, para las cuales “carrera profesional” tiene un significado muy preciso,
profundamente ligado con el reconocimiento de estudios en instituciones de educación superior debidamente
acreditadas. Con todo mi respeto y aprecio por la labor de estas instituciones, es indispensable reconocer un
fenómeno que tiene ya varias décadas, y que en los hechos ha venido a afectar profundamente la forma como
se concibe, se realiza y se evalúa una rama de actividades muy altamente calificadas, en el mismo meollo de
las actividades productivas: me estoy refiriendo al manejo, o gestión, de proyectos.

Los proyectos son la forma como se aterrizan y concretan los planes tácticos y estratégicos de toda la
economía (sí: lo estoy diciendo con plena conciencia de lo que esto implica). Cuando una parte substancial de
los proyectos que se realizan en un país están bien fundamentados, planeados y ejecutados, se ven
incrementados tanto la productividad como la calidad de vida de los beneficiados.

Las razones, formas y métodos mediante los cuales un gobierno (a nivel nacional o local), o bien una empresa
(desde una micro, hasta un conglomerado transnacional) elaboran sus iniciativas tácticas y estratégicas
trascienden enteramente lo que deseo tratar en este artículo; pero lo que no voy a dejar de subrayar es que el
éxito o fracaso de estas iniciativas depende críticamente del desempeño de los proyectos en que queden
concretados. Desde la antigüedad, los ingenieros (o los expertos equivalentes) de las grandes civilizaciones
estaban familiarizados con la importancia de realizar sus proyectos en tiempo y forma adecuados: en Egipto,
China y Mesopotamia (por mencionar sólo tres ejemplos muy destacados), la organización social y política fue
girando cada vez más en torno a las grandes obras de canalización y control de las aguas para la irrigación
agrícola, el transporte fluvial y el abastecimiento de agua potable. En los primeros capítulos del primer y
segundo tomos de su monumental History of Egypt, Chaldea, Syria, Babilonia, and Assyria (The Grolier
Society, London, 1900), Gaston Maspero (1848-1916) describe con toda claridad cómo es que hace más de
cuatro mil años fueron surgiendo los primeros “principados” (los nomes) de Egipto, en torno a la organización
del trabajo de construcción de diques y canales para controlar las aguas, así como para preparar las tierras
para el cultivo. Las obras, que eran de tamaño considerable, debían estar listas conforme al ciclo anual de
desbordamiento del río Nilo, por lo cual (y guardando toda proporción de las diferencias con respecto a la
organización social y la economía de la época actual) dicha construcción debió estar sujeta a la triple limitante
de alcances, recursos y tiempo.

Los egipcios buscaban mejorar la productividad agrícola mediante sus obras hidráulicas, así como los
gobiernos romanos y sus ingenieros que construyeron los grandes acueductos de hace alrededor de dos mil
años buscaban mejorar los servicios y la salud de las ciudades mediante llevar agua potable desde fuentes de
alta pureza y calidad. Las formas como hoy se emprende un proyecto, por supuesto, difieren mucho de las de
la antigüedad, pero el problema de concretar un objetivo económico o político mediante establecer una
iniciativa con determinados alcances, tiempo y recursos sigue siendo, en esencia, el problema de la
realización de proyectos.

Desde principios del siglo veinte, diversas profesiones como la ingeniería civil, la arquitectura y la ingeniería
mecánica ya habían acumulado un gran cuerpo de conocimientos y de prácticas relativas al manejo de
proyectos, muy ligadas a las disciplinas de administración en general. Por poner un ejemplo, en forma
independiente y paralela, el ingeniero y economista polaco Karol Adamiecki y el ingeniero estadounidense
Herny Gantt habían desarrollado diagramas de dependencia de tareas como técnicas de planeación y
seguimiento.

Es curioso, sin embargo, que la necesidad de desarrollar todo un cuerpo de estándares y disciplinas
específicamente enfocados al manejo de proyectos no haya sido puesta de relieve sino hasta 1969, con la
fundación del Project Management Institute (PMI®). En 1983, este instituto emitió su primera versión aprobada
de estándares para seis áreas de conocimiento en el manejo de proyectos: manejo (o gestión) de alcances,
de costos, de tiempo, de calidad, de recursos humanos y de comunicaciones. Asimismo, y en conjunto con las
definiciones de estas áreas de conocimiento, aprobó un código de ética y una serie de elementos guía para la
acreditación de programas académicos y la certificación de individuos. Estas áreas son comunes a una amplia
gama de áreas de aplicación: desde la industria de la construcción, pasando por las industrias aeroespacial,
farmacéutica, química y del petróleo, hasta la informática, la administración pública y la administración de
negocios.
Las seis áreas originales de 1983 se han desarrollado hasta convertirse en las nueve áreas de conocimientos
de la edición actual del Project Management Body of Knowledge (PMBOK®Ò). Pero lo más importante, lo más
relevante de todo, es el impacto real que está teniendo la aplicación de estos conocimientos y buenas
prácticas en la realización de proyectos en las instituciones de gobierno y en las empresas. En el ramo de la
informática, según los estudios (apropiadamente titulados Chaos) del Standish Group, los proyectos exitosos
(que terminaron dentro de tiempo y presupuesto, con la funcionalidad y características acordadas) pasaron del
16% del total en 1994, al 29% en 2004; los proyectos fracasados, en cambio, disminuyeron del 31% del total
al 18% (cifra que es, no obstante el progreso alcanzado, realmente alarmante). El hecho que el porcentaje
que representa a los proyectos cuestionados (que terminaron con desviaciones significativas en cuanto a
funcionalidad, costo y/o tiempo) se haya mantenido en 53% del total en los estudios de 1994 y 2004, muestra
la inmadurez y los problemas que aún padecen los proyectos informáticos: el grueso de estos proyectos
cuestionados no ha aprovechado aún las buenas prácticas en ingeniería de software y en manejo de
proyectos.

El siguiente hecho relevante es que, a escala mundial, tanto a nivel empresas como a nivel gobierno ha
habido un reconocimiento de la importancia del manejo de proyectos como práctica profesional. Esto se
manifiesta, de manera inequívoca, en las ofertas de remuneración económica para las personas que cuenten
con la credencial de Profesional en Manejo de Proyectos (PMP®Ò) del PMI®, así como en la exigencia de
niveles de madurez, conforme al modelo CMMIÒ del Software Engineering Institute. (Cabe aclarar que las
áreas de conocimiento del PMI® y la credencial PMP® aplican a todo tipo de proyectos, mientras que el CMMI
aplica básicamente a proyectos de desarrollo de sistemas informáticos.)

Esta creciente importancia del manejo de proyectos como un grupo de disciplinas de las que dependen tan
críticamente el éxito o el fracaso de las iniciativas tácticas y estratégicas, sin embargo, no se ve reflejada en la
formación profesional de los egresados de las instituciones de educación superior en México; lo que es más,
el Catálogo de Áreas de Conocimiento de la Asociación Nacional de Instituciones de Educación en
Tecnologías de la Información, AC ni siquiera menciona el manejo de proyectos como área o tema primario, y
me temo que en los planes de estudio la riqueza de conocimientos y técnicas para este renglón se encuentra
relegada dentro del tema de la administración en general. Es innegable que en el ambiente académico existe
interés en el tema, y que de dicho ambiente han surgido iniciativas importantes; pero persiste el hecho que
tanto entre las instituciones gubernamentales como entre las empresas, los reconocimientos más importantes
son hacia la credencial PMP® (cuando se trata de individuos), o bien hacia niveles como los del CMMI
(cuando se trata de organizaciones). ¡Cómo nos gustaría escuchar que los directivos de una gran empresa o
institución dijeran: “Tenemos que contratar egresados de la Universidad ... o del Instituto ..., porque salen muy
bien preparados en manejo de proyectos y en CMMI”!. Lo que está sucediendo, sin embargo, es que el
desarrollo de la carrera profesional en manejo de proyectos está teniendo lugar principalmente fuera de las
instituciones de educación superior, sea a nivel empírico o bien a niveles mucho más formales como los del
PMI® y del SEI.

Sobra decirlo, en LiderDeProyecto damos la bienvenida tanto a quienes provienen del medio académico como
a quienes han hecho su carrera en la profundidad de las trincheras de los proyectos. Continuémonos
comunicando, pues.

La Administración de Proyectos ¿Arte o Ciencia?

por Fumiko Kondo [ acerca del autor ]

Resumen

¿Cómo pueden las organizaciones desarrollar gente con habilidades sólidas y efectivas de administración de
proyectos? ¿Un administrador de proyectos es aquel cuyo potencial puede ser identificado y desarrollado
sistemáticamente? Este artículo presenta un mapa para identificar futuros administradores de proyectos y una
propuesta para desarrollar su capacidad.

En la mayoría de las organizaciones, la administración de proyectos es una disciplina no reconocida; la gente

suele asumir que puede llegar a ser administrador de proyectos(PM) después de demostrar talento, por
ejemplo, como desarrollador de software o analista de negocio.

De esta forma, un empleado ejemplar puede volverse PM con poco conocimiento de lo que se necesita para
administrar proyectos eficazmente. Con frecuencia, el resultado es que los nuevos PMs descubren que no
están preparados para ocupar dichas responsabilidades. Su primer proyecto no cumple los objetivos y se
comienza a dudar de si el neófito PM podrá encargarse de futuros proyectos.

Hay una mejor forma de conseguir buenos PMs. Las organizaciones deberían entender las cualidades que
hacen a un buen administrador de proyectos, identificar la gente adecuada para el trabajo y prepararlos para
ocupar dicho rol.

El Líder de Proyecto: ¿nace o se hace?

¿Puede la gente ser entrenada para ser un PM?, o ¿las habilidades necesarias para administración de
proyectos son algo que se tiene de nacimiento y no puede ser enseñado?
Para un buen PM, la combinación correcta está formada de dos partes. Como en la mayoría de las
profesiones, la administración de proyectos requiere un conjunto de habilidades técnicas que uno puede
aprender con entrenamiento, pero también requiere un conjunto particular de rasgos que presentan un desafío
para los programas de entrenamiento. La parte relacionada con el comportamiento puede llegar con la
experiencia, pero no todo mundo tiene las cualidades personales como para ser excelentes prospectos. Las
organizaciones necesitan entender esto si es que quieren contar con una administración de proyectos de
primera.

Habilidades Técnicas
Para ser un PM eficaz se requiere habilidades en planeación de proyectos, evaluación de estatus de
proyectos y reconocimiento de posibles riesgos. Estas son habilidades que una persona puede aprender por
medio de capacitación.

Planeación. La habilidad para planear significa ser capaz de identificar tareas que necesitan realizarse,
incluyendo las diferentes dependencias incluidas en la tarea, y desarrollar estimados de tiempo y recursos
necesarios para completar un proyecto. La habilidad de planeación puede requerir el saber como usar
software disponible, Microsoft® Project u otra herramienta de administración de proyectos [ Nota LP: ver curso
de Estimación de proyectos, PM con CMMI y UP o Certificación en PM ]

Evaluación del estado del proyecto. Cada PM debe saber como determinar el estatus de un proyecto en
desarrollo comparado con los detalles de su plan.. Las metodologías y técnicas concernientes—earned value
analysis (EVA), Índice de schedule, performance index (SPI) analysis, y cost performance index (CPI)
indicators — son herramientas que se pueden aprender. [Nota LP: ver cursos de Seguimiento de proyectos,
certificación en PM, PM con CMMI y UP ]

Manejo de riesgos. A los PMs se les puede enseñar a identificar riesgos

mediante el uso de un contrato que aclare los objetivos, alcance, recursos y tiempos para el— y luego a usar
técnicas de administración de proyectos para manejar estos riesgos. Las organizaciones deberán estar
preparadas para proporcionar cursos de certificación, entrenamiento en sitio ó algún tipo de entrenamiento de
alta calidad en habilidades requeridas por nuevos o posibles Pms. [Nota LP: ver cursos de certificación en
PM, PM con CMMI y UP ]

Habilidades de comportamiento: el arte de la administración de proyectos.

El componente conductual dentro de la habilidad para administrar proyectos incluye tres elementos cruciales:
la capacidad de anticipar, atención a los detalles y la habilidad para persuadir a otros. Estas cualidades
constituyen una especie de “arte” dentro del arsenal de talentos de un administrador. En parte son cualidades
personales intrínsecas, en parte son producto de la experiencia y en otra parte muy pequeña son cuestión de
aprendizaje.
Un paso adelante. Algunas personas son buenas para concentrarse en la tarea actual y no se preocupan por
lo que vendrá más adelante. Por ejemplo, los técnicos de helpdesk deben responder preguntas inmediatas,
arreglar problemas existentes y cerrar la solicitud, pero no se espera que ellos prevean lo que vendrá
después. En cambio, un administrador de proyectos necesita anticipar lo que encontrará a la vuelta de la
esquina. En el ejemplo del helpdesk, el trabajo del PM es anticipar el tipo de llamadas de asistencia técnica
que van a entrar. Y lo mismo aplica para otro tipo de proyectos. Aun con la planeación mas exhaustiva, los
problemas pueden surgir durante la ejecución de un proyecto que podría descarrilarse si estos problemas no
son anticipados y atendidos. Un PM debe pensar en el futuro y estar listo para cualquier contingencia.

Atención a los detalles. La mayoría de los proyectos se conforman de varias piezas que se tienen que
acoplar, requieren que mucha gente trabaje en conjunto y parten de varios requerimientos que tienen que ser
cumplidos. El PM debe poder ver no solo el bosque, sino también los detalles (los árboles del bosque), y como
estos encajan unos con otros. La persona que solo piensa en la perspectiva general no puede ser un PM
eficaz, puesto que la administración de proyectos requiere la habilidad de pensar a diferentes niveles de
detalle sin descuidar la fotografía completa.

Habilidad para Influenciar. Sin importar que tanta planeación se lleve a cabo para un proyecto, la habilidad
de un PM para dar buenos resultados depende en su habilidad para influenciar a la gente. Los miembros del
equipo deben entender sus tareas y saber por qué son importantes, y a los “stakeholders” del proyecto (Ej.,
los clientes y patrocinadores ejecutivos del proyecto) se les debe de mantener informados del progreso para
que las decisiones que tomen se alineen con las metas del proyecto.
Un PM de poder comunicarse con todos los interesados y manejar las expectativas durante el camino de la
culminación exitosa del proyecto.

¿Cómo lograrlo?

Cómo puede una organización preparar a sus administradores de proyectos para sus roles?

No es difícil salir adelante en el aspecto de habilidades técnicas, mediante cursos y entrenamiento [ ver
sección de cursos de liderdeproyecto.com ], pero en la parte conductual de la ecuación, el “arte” de la
administración de proyectos, presenta un desafío complicado.

La propuesta de experiencia. Una organización no puede tan solo darles un curso a los PMs y esperar que
aprendan a anticiparse al futuro, pongan atención a los detalles, o influencien a la gente. Lo que se necesita
es identificar a aquellos que tienen los rasgos de conducta adecuada que puedan hacerlos buenos PMs y
después darles experiencia.

Si una organización utiliza el concepto de competencias para describir sus roles, deberá incorporar la
habilidad para anticipar, atender a los detalles e influenciar a la gente, como competencias que aplican a los
administradores de proyectos. Si hay planeación de sucesión, las mismas competencias deberían ayudar a
identificar a las futuras estrellas de la administración de proyectos.

A los PMs potenciales se les puede asignar la administración de proyectos pequeños y de bajo riesgo,
idealmente con la ayuda de mentores. Un ejemplo de este tipo de proyectos puede ser algo como preparar un
reporte que requiere un número de gente trabajando de manera conjunta — alguien que junte los datos y los
inserte en una hoja de cálculo, alguien que cree fórmulas matemáticas y estadísticas, y otro con habilidades
de escritura.

Un prospecto de PM puede encargarse de un proyecto así para obtener experiencia y probar sus habilidades
conductuales. Conforme PMs potenciales demuestren sus competencias, pueden entonces ser entrenados en
habilidades técnicas necesarias para llegar a ser administradores de proyectos completos.

Conclusión

Es crítico para las organizaciones el desarrollar planes de proyectos y ejecutarlos de manera exitosa,
mostrando resultados que demuestren el valor de la administración de proyectos. Sin administradores de
proyectos completos y eficaces que tengan el conjunto de habilidades adecuado, resulta imposible lograr
proyectos exitosos.
Hay un camino mucho mejor para desarrollar administradores de proyecto que simplemente elegir personas
que son buenas en lo que ya están haciendo y aventarlos a tomar un rol para el cual puede que estén o no
preparados. Esto se logra identificando candidatos en términos de competencias conductuales relevantes,
cultivándolos al proporcionarles experiencia y finalmente entrenándolos en las habilidades técnicas
requeridas.

Guía Básica para Administrar un Proyecto

Has sido asignado para coordinar un proyecto, pero posiblemente no tengas una preparación formal al
respecto. Si piensas que administrar un proyecto significa seguir haciendo lo mismo que has hecho hasta
ahorita y esperar las alabanzas de tu equipo de trabajo, estás muy equivocado.

Puede ser que tengas que seguir realizando en parte algunas de las actividades que has realizado hasta el
momento (por ejemplo programar parte de la aplicación de software). Pero, eso sólo significa que tienes
responsabilidades de otros roles, además de la del administrador de proyectos. Las tareas del líder de
proyecto son muy diferentes a las de un operativo.

Seguramente te servirá contar con una guía rápida para tener una visión de por dónde avanzar dentro del
proyecto. A continuación te mostramos esta guía que no pretende más que mostrar los elementos y tareas
básicas de las cuales tendrás que responsabilizarte dentro del proyecto.

1. Conoce tu proyecto.

En primer lugar debes de tener claro qué es lo que se busca con este proyecto. Cuál es el objetivo a cumplir.
¿Desarrollar un software de control de recursos? ¿Construir una casa? ¿Diseñar un automóvil? ¿Organizar
una boda? Identifica quiénes son todas las personas que te pueden proporcionar información respecto a lo
que se necesita. Hay proyectos en los que una sola persona cuenta con toda la información, o es quien debe
quedar satisfecho con el resultado. Pero, en la mayoría de los proyectos son varias las personas interesadas
en el resultado del proyecto. Ubícalos bien y cuestiónalos sobre el mayor detalle posible de lo que esperan.
Determina claramente los requerimientos del proyecto.

Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML
Curso de administración de requerimientos con casos de uso

2. Planea las actividades, tiempos y recursos.

Una vez que determinas con la mayor claridad y detalle posible lo que debes de desarrollar durante el
proyecto (las funciones del software, las características de la casa, los detalles de la boda, etc), entonces
puedes iniciar el trabajo de planeación. Planeas las actividades necesarias, planeas la cantidad de gente y el
perfil necesario para realizar las actividades, planeas el esfuerzo que cada una de ellas tendrá que realizar,
planeas los tiempos necesarios para completar cada tarea y para completar el trabajo completo, cuidando que
no haya tiempos muertos ni ningún tipo de desperdicio de recursos. Si el proyecto sale mal, lo peor que
puedes hacer es echarle la culpa a tu equipo de trabajo, finalmente tú debes de poder decidir si es el personal
que podrá cumplir el trabajo o no.

Mucha gente comienza a trabajar en cuanto tiene una idea leve de los resultados que se esperan, sin
detenerse a pensar cómo llegará a ese objetivo ni cuándo lo hará. Si nadie te presiona por los recursos o
tiempo que consumas para lograrlo, esta puede ser una fórmula cómoda, aunque no esperes que confíen en ti
cuando se trate de proyectos estratégicos para la empresa donde el control de los recursos sea importante.
Es bastante probable que en realidad simplemente estés ejecutando, y no administrando el proyecto.

Temas relacionados:
Curso de estimación de proyectos de software
Curso de administración de proyectos con CMMI 2, El Proceso Unificado y UML
Curso de certificación PMP® en administración de proyectos
3. Ejecuta y monitorea el proyecto, manteniendo la visibilidad hacia el exterior.

He conocido proyectos que terminan mucho más tarde de lo que se planeó, pero con clientes contentos. Y he
conocido proyectos que terminan a tiempo, pero donde los clientes terminan odiando al equipo de trabajo.
Una razón importante para esto es la forma en que se haya monitoreado el proyecto y generado visibilidad
hacia el exterior. Una vez diseñado el plan hay que seguirlo, y para lograr esto debes de monitorearlo
constantemente para reaccionar oportunamente. ¿Ya inició la gente el trabajo que le corresponde? ¿Ya
terminó el trabajo que debía de terminar? ¿Por qué se está atrasando? ¿Cuánto se está desviando? ¿Qué
puedes hacer para que no se siga retrasando? Monitorear el proyecto significa mantenerse al pendiente de lo
que ocurre. No esperes que por el simple hecho de que ya elaboraste un plan, éste se va a cumplir
mágicamente. Si no hay nadie que le dé seguimiento, difícilmente se cumplirá. Además, no sólo tú, como líder
de proyecto quieres mantenerte informado de lo que ocurre. También tu jefe y el cliente quieren saberlo, así
que es mejor que los mantengas continuamente informados de lo que ocurre para que juntos vayan tomando
decisiones para corregir las desviaciones contra lo planeado, y evitar sorpresas en los resultados.

Temas relacionados:
Curso de análisis y diseño orientado a objetos con UML
Curso de administración de proyectos con CMMI 2, El Proceso Unificado y UML
Curso de certificación PMP® en administración de proyectos

4. Aprende de tus errores.

En todo proyecto ocurren cosas buenas que deberías de volver a repetir en tus proyectos futuros, y cosas
malas que deberías de evitar. Es parte del aprendizaje, y es lo que te ayudará en gran medida a que tus
resultados sean cada vez mejores. Si compartes este conocimiento, tus compañeros y tu empresa crecerán
profesionalmente sin necesidad de enfrentarse a los mismos problemas que tú. Einstein dijo alguna vez que
no hay nada peor que hacer las cosas igual y esperar resultados diferentes. Si ya descubriste que hay cosas
que ocasionan retrasos y problemas en tus proyectos, no lo vuelvas a repetir. Y si viste que hubo actividades
que ayudaron al éxito del proyecto entonces procura volver a realizarlas. Claro que no se trata de redescubrir
el hilo negro, hay muchas buenas prácticas allá afuera que puedes aprender de bibliografía, internet y cursos
que te ayudarán a realizar cada día un mejor trabajo.

Requisitos para la Certificación PMP®

De acuerdo con el Project Management Institute (PMI®) la certificación que acredita a una persona como
Project Management Professional (PMP®) reconoce que ésta ha demostrado conocimientos y habilidades en
la dirección de equipos de proyectos y en la entrega de los resultados esperados tomando en cuenta las
limitaciones de tiempo, presupuesto y recursos.

El PMI® cuenta entre sus filas con otro tipo de certificaciones, pero la credencial PMP® es la más difundida y
codiciada en todo el mundo por aquellos quienes de una forma u otra están vinculados a la administración de
proyectos, gracias a que ésta tiene reconocimiento global dado el alcance universal del Project Management
Institute como la organización de dirección de proyectos de mayor prestigio en todo el planeta.

La credencial PMP® no se limita en absoluto a alguna carrera o rama de la industria específica, pues en todas
las áreas hay proyectos, de allí que hoy por hoy esta certificación goce de un prestigio muy alto entre toda la
comunidad de profesionales a nivel mundial orientados a la administración de proyectos.
Por tratarse de una institución seria y rigurosa, el PMI® ha establecido una serie de requisitos que le
permitirán a quienes lo deseen, poder optar y finalmente conseguir la certificación como Project Management
Professional, las puede analizar seguidamente:

Para el caso de ser Profesional y contar con título profesional

- Contar con 3 años/36 meses de participación en proyectos durante los cuales al menos 4,500 horas fueron
utilizadas en liderar y dirigir tareas del proyecto.
Para el caso de no ser Profesional y contar con Preparatoria y Certificado de estudios
- Contar con 5 años/60 meses de participación en proyectos durante los cuales al menos 7,500 horas fueron
utilizadas en liderar y dirigir tareas del proyecto.
- Para los dos casos anteriores
- Puede ser miembro o no del PMI®
- Ser elegible para presentar el examen de certificación. La elegibilidad está en función de la información de la
experiencia que presenta el candidato al PMI® y en la verificación que el Instituto realiza. El 20% de las
solicitudes pasan por un proceso de auditoria en 2 niveles. Cuando la solicitud se hace en línea, el tiempo de
respuesta es de 5 días hábiles. Para las solicitudes por correo tradicional el tiempo de respuesta es de 10 a
14 días hábiles después de haber recibido la documentación.

- Contar y proporcionar una dirección de correo electrónico válido, ya que todas las notificaciones se hacen
por esta vía.

- Tener 35 PDUs (Professional Development Units), es decir 35 horas de educación presencial o en línea,
comprobando que fueron completadas de forma satisfactoria por medio de un certificado o diploma. Los temas
aceptados por el PMI® son: Administración de la Calidad, Alcance, Tiempo, Costo, Recursos Humanos,
Comunicación, Riesgos, Adquisiciones y/o Integración del proyecto.

- Al ser elegible, se debe pagar y agendar a través de Internet la fecha para presentar el examen de
certificación.

Es importante mencionar que al momento de agendar el examen se solicitará una identificación oficial con
fotografía y número. Esta misma identificación será requerida al momento de presentarse al examen.

- Tomar el curso de preparación y cumplir al 100% los compromisos de asistencia y dedicación necesarios
para concluirlo con éxito.

- Presentar y acreditar el examen de certificación. El examen es de opción múltiple (4 opciones por pregunta)
con 200 preguntas que deben ser contestadas en 4 horas. El examen es en computadora y se realiza en un
centro de certificación Prometric.
TEMA II

Ejecución del Proyecto

Por Eduardo Navarro, MBA, PMP® [ Acerca del autor]

y Maximiliano Paredes, PMP® [ Acerca del autor]

La administración de proyectos pretende concretar un objetivo, en general de alta complejidad (el desarrollo
de un nuevo producto, por ejemplo: una represa hidroeléctrica o nuestro casamiento), dentro de los límites
presupuestados de tiempo y dinero, a la vez que se minimiza el nivel de riesgo y conflicto dentro del equipo de
proyectos y con otros posibles involucrados.

Entonces, el "baile" realmente empieza con la ejecución. Aquí, nos encontraremos con infinidad de
problemáticas de índoles totalmente diversas.

Por ejemplo, las materias primas consideradas en la evaluación para desarrollar nuestro prototipo han sido
discontinuadas y las nuevas nunca han sido probadas por nosotros; nuestra "desarrolladora estrella" está
embarazada y no podrá participar de esta fase crítica; los propietarios del edificio ideal para instalar nuestra
antena de transmisión ahora se niegan a darnos la autorización.

Estos problemas deberán ser resueltos justamente con las habilidades especiales que tienen los buenos
administradores de proyectos: pensamiento sistémico y visión de negocio, excelentes organizadores y muy
buenos en la negociación y el manejo de conflicto.

Ahora bien, el "grupo de procesos de ejecución" comprende los siete procesos que materializan lo que hemos
propuesto y definido en el Plan de Gestión del Proyecto. Es a través de estos procesos que comenzaremos a
producir los entregables y/o resultados esperados del proyecto.

A continuación, presentaremos los procesos más relevantes del grupo Ejecución:

Dirigir y gestionar la ejecución del proyecto

Es el proceso necesario para dirigir las diversas interfases técnicas y organizacionales que existen en el
proyecto y ejecutar el trabajo definido en el Plan de Gestión del Proyecto.

El Líder de Proyecto debe tener una visión integradora y llevarla a cabo ejecutando el plan. Dirigirá el uso de
los recursos materiales y humanos necesarios para completar las actividades, llevará a cabo reuniones con el
equipo e interesados y supervisará el cumplimiento de las normas de calidad, entre otras tareas.

Aquí es importante resaltar la integración necesaria para dirigir y gestionar la ejecución del proyecto.

En un proyecto para la provisión de una red de alguna tecnología de telecomunicaciones el project manager,
en un día cualquiera, se podrá encontrar discutiendo, con el supervisor del área de integración de la solución,
los detalles finales de la implementación de dicho paquete de trabajo.
Aquí se volverán a revisar los requerimientos de equipos que, según el plan de gestión, deben haber llegado
al país, el hardware que el cliente necesita tener instalado para poner en marcha el sistema y los recursos
humanos (de nuestra organización y del cliente) que deben estar disponibles.

El Líder de Proyecto deberá asegurarse, con el resto de los involucrados, de que todos los elementos y
recursos estén disponibles en el momento adecuado.

Otras actividades típicas de esta fase son: discutir con el cliente sobre un nuevo pedido para incorporar un
nuevo sitio en la red, lo que implicará un cambio en el alcance acordado del proyecto (scope changes) y sus
impactos en tiempos, dinero y recursos; resolver conflictos entre los integrantes del equipo de proyectos o de
ellos con el cliente.

Realizar el aseguramiento de la calidad

Es el proceso necesario para realizar las actividades planificadas y sistemáticas de calidad a fin de garantizar
que el proyecto utilice todos los procesos necesarios para satisfacer los requisitos que se han planteado. Aquí
debemos velar por el cumplimiento de los procesos y estándares que hemos definido para llevar a cabo
nuestro proyecto.

Es muy común confundir este concepto y/o proceso con el de control de calidad, que tiene como objetivo
verificar que los entregables se ajusten a las especificaciones o el proyecto produzca resultados satisfactorios.

Otras actividades comprendidas aquí son los procesos de mejora continua. De naturaleza iterativa, apuntar a
mejorar los procesos, eliminar actividades que no agreguen valor y a reducir el desperdicio. Una metodología
muy utilizada en este terreno es la de Six Sigma.

Por ejemplo, podríamos definir a la calidad de un casamiento como el resultado de todos los factores que
contribuirán a la satisfacción de la pareja, de los familiares, de los amigos y demás invitados. Entonces, para
que el casamiento cumpla con la calidad requerida, debemos asegurarnos del buen desempeño de todos
estos factores.

Así, la calidad estará asociada al desempeño del salón, del disc-jockey, etc. Como Líderes de Proyecto,
debemos asegurarnos de que todos los factores que contribuyen a la calidad adhieran a buenas prácticas (o
normativas).

Puntualmente, verificar que el salón cumpla con las normas de seguridad e higiene, que disponga de grupos
electrógenos para sobrellevar eventuales cortes de energía, que el disc-jockey cuente con equipos de
repuesto, etc.

Construir y desarrollar el equipo de proyecto

Si bien son dos procesos, a fin de resumir, diremos que ambos tratan de la constitución de nuestro equipo de
proyecto y el desarrollo de sus competencias.

La adquisición de nuestro equipo de proyecto definitivo contempla facetas tales como la negociación y gestión
de recursos humanos compartidos, la contratación de terceros, la definición de roles y el plan de gestión del
personal.

El segundo proceso (desarrollo) nos permitirá optimizar el desempeño de nuestro equipo. Sus premisas
fundamentales son el desarrollo de habilidades y competencias (capacitación) así también como la de generar
un sentido de cohesión a través de sesiones de team-building.

En el caso de un proyecto de desarrollo de un nuevo producto, el project manager deberá terminar de

negociar con las áreas funcionales o terceros (en las fases previas, debería haber tenido un primer
acercamiento con los sectores proveedores de los recursos para evaluar la disponibilidad) la provisión de los
recursos humanos que participarán, la dedicación necesaria, cómo coordinarán el reporting de las personas a
cada uno de los dos jefes (funcional y matricial, este último es el PM), cómo manejarán la cuestión si existiese
un conflicto, etc.

Por otro lado, el administrador del proyecto deberá tener planificadas e ir ejecutando las actividades
necesarias para que el equipo y los terceros involucrados se conozcan y entiendan el trabajo de los demás.

Una buena forma de empezar es organizar un evento en un hotel. Luego, se realizarán sesiones informativas
de avance del proyecto (reuniones semanales en la oficina o reuniones más largas y profundas en un lugar
afuera de la empresa), y eventos de trabajo y festejo para mantener alta la moral y la sinergia de equipo (por
ejemplo, un día de remo con el equipo por el río más cercano, con almuerzo incluido para socializar).

Distribución de la información

La distribución de la información implica asegurarse que ésta se encuentre a disposición de los interesados en
el proyecto de manera oportuna. Así, es necesario implementar el plan de gestión de las comunicaciones y
responder a las solicitudes inesperadas de información.

Ahora bien, ¿de qué manera llevaremos a cabo la comunicación?

Independientemente de las formas (escrita/oral, formal/informal, interna/externa, vertical/horizontal), la

información debe ser recopilada y distribuida. Es en la correcta ejecución de nuestro plan de administración de
las comunicaciones donde nos aseguraremos de que nuestro modelo "emisor-receptor" funcione
contribuyendo al éxito del proyecto.

¡Cuidado con el efecto "conference call"! Distribuir la información necesaria y de manera oportuna no es
directamente proporcional a la cantidad de datos suministrados y reuniones programadas. Por eso, hay que
enfatizar en el aspecto cualitativo: proveer información (no datos crudos) y dirigida a los que puedan accionar
sobre ella.

En un caso de desarrollo de un nuevo producto, podremos organizar reuniones semanales con el equipo de
proyectos permanente (reemplazables por conference calls si el equipo es total o parcialmente virtual) para
presentar el avance de los hitos principales del plan, identificar/presentar y discutir problemas, proponer y
evaluar alternativas de solución, repasar las actividades futuras y asegurar la coordinación entre las áreas
intervinientes.

Luego, podremos tener reuniones mensuales con los trabajadores de la planta (miembros no permanentes del
equipo de proyectos) para mantenerlos al tanto de avances o cuestiones de relevancia, detectar necesidades
y problemas en forma temprana.

La actualización del Plan de Gestión y del cronograma del proyecto deberá enviarse con diferente nivel de
detalle según el público receptor. La alta gerencia podría recibir un documento general de estado de todo el
portafolio de proyectos mientras que los miembros permanentes recibirán los documentos en el máximo nivel
de detalle.

Una buena práctica consiste en mantener un blog interno con artículos de utilidad general para el proceso de
desarrollo de productos y notas específicas de interés sobre cada proyecto puntual.
Asimismo, es conveniente fomentar el uso del teléfono y el contacto personal para resolver cuestiones que
puedan ser fuentes de conflicto. Los correos electrónicos deberían utilizarse para cuestiones del día a día
(siendo estrictos en la lista de distribución para no involucrar a gente que no tenga necesidad, en ese
momento, de opinar o recibir la información).

Solicitar respuestas y seleccionar proveedores

Estos son dos procesos que se ajustan a los proyectos que precisan de provisiones externas. Contemplan las
actividades necesarias para aplicar criterios de selección y evaluar distintos oferentes.

En el caso de la organización de un casamiento, los involucrados en la decisión de la comida del evento, con
el aporte de información económico-financiera del project manager, discutirán sobre lo que esperan del
servicio, propondrán alternativas, analizarán requerimientos, evaluarán las propuestas de cada una las
preseleccionadas y, tras las pruebas, tomarán la decisión final.

Hasta aquí hemos revisado, con cierto grado de formalidad, las pautas que el Project Management Institute
establece para los procesos de ejecución.

Desde luego, la implementación se refiere a realizar las distintas actividades que han sido identificadas en el
Plan de Gestión del Proyecto. Pero también habrá que gestionar obstáculos imprevistos y contar con la
suficiente habilidad para identificar rápidamente acciones correctivas y cambios.

En estos casos, el project manager podrá recurrir a ciertos momentos de aislamiento para idear alternativas
de solución, evaluando pros y contras e interacciones de las mismas con otros elementos del proyecto. Luego,
podrán celebrarse sesiones de brainstorming con los miembros del equipo para encontrar la mejor opción.

Para finalizar, es importante remarcar un aspecto del día a día de la implementación. Muchas veces
observamos al Líder y su equipo desbordados en resolver problemas que impiden el avance del proyecto.

Si bien eso puede dar la sensación de que se está ejecutando, en realidad, podría ser un indicador de bajo
rendimiento. Esto podría manifestar la existencia de fallas en la planificación, escasez de recursos, alcance
mal definido, etc. Como analogía, podríamos decir que estamos en un auto que se encuentra en un pantano y
a su vez estamos imprimiendo más potencia a nuestro motor sin resultados...

Es en la ejecución, donde también debiéramos prever los problemas. Volviendo a la analogía, pronosticar
caminos alternativos.

En definitiva, aquí hemos presentado los principales aspectos vinculados con los procesos de ejecución en
Project Management

Green Project Management ¿Nueva tendencia en administración de

proyectos?

Por Dave Shirley [ Acerca del autor]

y Rich Maltzman [ Acerca del autor]

Hablar de Green Project Management es mucho más que salvar al medio ambiente (no quiere decir que esto
no sea un noble esfuerzo). Los administradores de proyectos siempre han sido verdes, tal vez sin que ellos lo
sepan. Por definición, los project managers están intentando constantemente reducir costos, incrementar el
valor para los stakeholders y proteger los escasos recursos, lo que quiere decir que ellos han asumido una
postura verde. En nuestra mente, todos los procesos que se emplean para cumplir los objetivos de la
administración de proyectos, han sido simplemente fragmentados y les falta la etiqueta de medioambiente.
¿Recuerdan cuando la administración de proyectos fue considerada una “profesión accidental?. Con la ayuda
de organizaciones como el Project Management Institute (PMI®) y el trabajo duro de una gran cantidad de
personas, los project managers están encabezando los cambios necesarios para continuar con la viabilidad
del negocio, de allí que la administración de proyectos hoy por hoy es una opción profesional muy
demandada.

Con la tendencia hacia los negocios verdes, sentimos que el project manager es “accidentalmente verde”, y
no necesita serlo. Las mismas disciplinas, estándares y métodos que han hecho del administrador de
proyectos una parte integral de los entornos de negocios pueden ser aplicadas en ambientes de negocios
verdes, lo que resulta en un enfoque estructurado para el green project management. Solamente veamos con
un poco de profundidad dentro de la administración de proyectos verde y lo que encontraremos será lo que es
hoy en día un project manager.

Si la administración de proyectos es más que salvar al medio ambiente ¿por qué la administración de
proyectos necesita tener una etiqueta que lo califique como “verde”?. Si eres un amante de los árboles o
escéptico, hay una creciente “ola verde” de ambientalismo. Tú puedes navegarla o simplemente mirarla desde
la orilla y ésta no va a desaparecer. Los project managers ven a sus proyectos a través de muchos lentes:
finanzas, calendario, calidad. Muchos expertos y conocedores de la materia creen que un proyecto también
debería ser visto a través del lente medioambiental para que el project team incremente su forma de pensar a
largo plazo y aprovechen la ola verde. También tiene sentido simplemente desde un punto de vista
profesional. Sólo en los Estados Unidos, 130 billones de dólares se han dispuesto para proyectos
relacionados con la energía como parte del estímulo del gasto del gobierno.

Pero ¿qué es lo que miras cuando ves a través del lente medioambiental?. ¿Cómo
esa ayuda define el green project management?. Mirar a través de este lente, le
permite a los project managers buscar y ver las oportunidades dentro de un proyecto
para ahorrar en los recursos escasos y plantearse preguntas como: ¿En qué parte
de los procesos como diseñar, planificar, ejecutar , cerrar y más allá podemos
ahorrar energía?. No estamos hablando solamente de las emisiones de carbono.
También nos referimos a la energía humana, aunque esto puede traducirse de nuevo
como la huella de carbono. Por ejemplo, es más eficiente tener juntas virtuales que
tener que trasladarse para sostener reuniones cara a cara. Con todos los avances
tecnológicos existentes en la actualidad, realizar una videoconferencia es muy fácil,
económico y hasta divertido, es casi como estar allí en persona, excepto que se
ahorra tiempo en traslado, dinero y por supuesto, el consumo de combustibles
fósiles.

Si las posibilidades lo permiten, ¿debería de equiparse a los miembros del equipo del proyecto con e-readers
para que ellos puedan descargar todos los documentos y de ese modo se ahorraría papel?. ¿Eso no haría
más conveniente mantener y revisar los últimos documentos sin tener que hacer el esfuerzo de prender la
computadora, ahorrado así energía humana y de otros tipos?.

Esas son solamente un par de cosas a considerar por el equipo del proyecto, específicamente si ellos trabajan
de forma remota (como parece ser la tendencia en estos días). Sin embargo, hay muchas más razones que
ayudan a ser verdes a los project managers.

Nosotros no creemos que el green project management esté limitado al manejo de aspectos
medioambientales de un proyecto. Sentimos que está conectado con la responsabilidad social corporativa, la
triple línea de fondo, los cuatro rasgos de sustentabilidad de Natural Step, y las 4 Ls en inglés (Lean, Learn,
Linked and Lasting; Reducir, Aprender, Vincular y Durabilidad).

La administración de proyectos verde se trata de personas, el planeta y rentabilidad, pero también es acerca
de: eliminar nuestra contribución a la acumulación de químicos tóxicos (DDT, PCB), erradicar nuestra
contribución a la destrucción de la naturaleza y eliminar nuestra contribución a quitar la capacidad de los seres
humanos para satisfacer sus necesidades.

Finalmente, la administración de proyectos verde es: reducir desperdicios y hacer que las operaciones sean
más eficiente; compartir las lecciones aprendidas para el crecimiento organizacional; conectar a las empresas
con el plan de administración medioambiental y pensar a largo plazo. Hacer esto, por supuesto que ayuda al
planeta, pero este tipo de pensamiento también repercutirá en el éxito del proyecto y de la organización.
Sin duda, eso suena a mucha responsabilidad puesta sobre los hombros del project manager. Pero los
administradores de proyectos ya cuentan con las habilidades inherentes y la experiencia para realizar sus
proyectos con una intención verde. Esto es lo que hay que hacer, porque afectará de forma positiva la triple
línea de fondo y ayudará al equipo del proyecto a hacer las cosas correctas.

La importancia de las “mejores prácticas” en administración de proyectos

Por Adrián Anex

La ausencia de la aplicación de las mejores prácticas se ha

traducido en proyectos que no agregan valor a sus dueños o
accionistas, generalmente están fuera de plazo, fuera de
presupuesto y que no cumplen con las expectativas de los
interesados. Esto se traduce en la falta de formación
concreta en la Dirección de Proyectos Empresariales.

Debido a la complejidad de la economía y del mercado en la

actualidad, las empresas trabajan por proyectos que integran a
profesionales muy diversos, con diferentes procedencias y
culturas empresariales. Estos proyectos implicarán cada vez más
a diversas organizaciones. Además, los cambios tecnológicos, la
globalización del mercado y la aparición de nuevos competidores
hacen que las empresas exijan agregar valor para sus interesados. Esto ha cambiado la forma de Dirigir y
Gestionar Proyectos.

Las recomendaciones que aquí se presentan tienen la pretensión de ser una crítica constructiva a la Dirección
y Gestión de Proyectos Empresariales.

1. Los proyectos no terminan mal… ¡parten mal!

Generalmente los objetivos establecidos son ambiguos, por ende el alcance del proyecto no es claro. No se
identifican lo riesgos; y si se identifican no se controlan ni se aplican planes de contingencia cuando éstos se
plasman. El equipo del proyecto no participa en construcción de la estructura detallada de trabajo (EDT /
WBS). No se identifican los interesados (stakeholders) y su grado de compromiso con el proyecto (los más
peligrosos son los indiferentes, ojo con ellos). No se establecen los criterios de aceptación, sume y siga.
¿Terminal mal?, por favor, a otro perro con ese hueso.

2. Entre la teoría y la práctica

En el pasado leí una frase que con el correr del tiempo la hice mía: “No hay nada más práctico que una buena
teoría”. Generalmente las teorías son desechadas, por la alta dirección, en pos de la prisa. Si quiero hacer
algo bien, a la primera, siempre digo, “No me apuren que tengo prisa”. Siempre me he preguntado ¿Por qué
hay tiempo para hacer dos veces las cosas y generalmente no hay tiempo para hacerlas bien a la primera?
¿Tiene usted la respuesta?

3. Las mejores prácticas

Las técnicas que sustentan las buenas prácticas (por ejemplo, PMBOK® del PMI® y Prince2 y otras), han
demostrado que son la forma eficiente para Dirigir y Gestionar Proyectos, cuando existe restricciones
relacionadas tales como el alcance del proyecto, el tiempo relacionado con el inicio y termino del proyecto, la
calidad esperada por los interesado y el costo autorizado para el desarrollo del proyecto y una nueva variable,
el medio ambiente.

4. En el camino no se arregla la carga. Planificar o no planificar he ahí el dilema.

Esta frase tan socorrida y tan chilena, no tiene cabida en la Dirección de Proyecto. La planificación detallada
(proyectos medianos y grandes) resulta fundamental para la ejecución y el control; esta última fase es la
garantía del éxito del proyecto, por su puesto si se ejecuta correctamente.
Si el proyecto es pequeño, igualmente planifique. En la Dirección de proyecto no existe argumento válido que
lo exima de la planificación.

5. Gestión de Riesgos

La gestión de riesgos rara vez se aplica. En algunas ocasiones de planifica, sin embargo, no se controla.

En contexto ideal la incertidumbre no sería una variable relevante en la toma de decisiones, el éxito estaría
garantizado. La realidad es bastante diferente al ideal expuesto. Toda decisión implica un riesgo. El riesgo se
produce cuando quien toma las decisiones carece del “conocimiento perfecto - el ideal -”. El gerente del
proyecto es el responsable identificar y mitigar los riesgos inherentes a un proyecto y reducir al mínimo
razonable sus efectos negativos.

6. Liderazgo en la Dirección y Gestión de Proyectos

Mucho se ha escrito sobre Liderazgo, casi tanto como sobre Estrategia Negocios, sin embargo el Liderazgo
efectivo se sustenta en 4 pilares (“El liderazgo al estilo de los jesuita”, Chris Lowney):
1. Conocimiento de sí mismo: entender sus fortalezas, sus debilidades, sus valores y su visión del mundo,
2. Ingenio: innovar confiadamente y adaptarse a un mundo cambiante,
3. Amor: tratar al prójimo con amor y una actitud positiva y,
4. Heroísmo: fortalecerse a sí mismo y a los demás con aspiraciones heroicas.

7. Equipo de trabajo

Generalmente el liderazgo aplicado es de carácter autoritario, por cierto no participativo. Para que un equipo
se sienta motivado debe tener claro los objetivos del proyecto, participar activamente en la construcción del
programa de trabajo que finalmente se traduce en la estructura detallada de trabajo y ser responsable de la
calidad del producto / servicio final.
III TEMA

Primera conferencia del PMI® en octubre de 19691

Planificar, Calendarizar y Controlar los Esfuerzos de los Trabajadores del
Conocimiento

Por Russell D. Archibald [ Acerca del autor]

I. Introducción

¿Por qué estamos aquí?

El primer factor común el cual nos trajo a este encuentro, el cual yo

espero que sea el primero de muchas sesiones productivas de este
tipo, es nuestro interés en proyectos. A medida que nos
conozcamos entre sí en estos dos días, encontraremos que
nosotros representamos una muy amplia variedad de
organizaciones, industrias, agencias, fondos especiales e intereses
personales específicos. Sin embargo, todos estamos interesados en
los proyectos, y es por eso que estamos aquí: para hablar de
proyectos y la administración de proyectos.

¿Qué son los proyectos?

Ya que los proyectos son el centro de nuestro interés, creo que es

pertinente hacer esa pregunta en este punto, pues todos los
oradores y en los paneles de discusión que van a seguir se van
tratar algunos aspectos de proyectos y de project management.

Los proyectos son esfuerzos complejos:

 Para lograr los resultados especificados ajustados a un

calendario y presupuesto
 Que típicamente trascienden las líneas funcionales y organizacionales
 Que son únicos y no completamente repetitivos del esfuerzo anterior

Esta definición acerca de los proyectos ha erosionado una importante exposición, pero me gustaría recibir su
reacción (por parte del público) y las mejoras que se le pueden hacer. Tal vez éste es un proyecto en el cual el
Project Management Institute debería encargarse: del desarrollo de una definición adecuada de proyecto en
términos sistemáticos.

El manejo de proyectos

La administración de proyectos es, sin duda, un trabajo difícil. Es poco frecuente que una organización en
estos días esté satisfecha con su desempeño en proyectos en cuanto al cumplimiento de los tiempos y el
presupuesto, logrando la calidad deseada del resultado final y controlando el esfuerzo sin derramar tanta
sangre en la sala de juntas

Manejar proyectos es considerablemente diferente del manejo de organizaciones estáticas. Los conceptos
tradicionales que aprendemos en la escuela de negocios no aplican muy bien cuando de proyectos se trata.
De hecho, ocurren severos conflictos entre la organización o la línea de dirección por un lado, y la
administración de proyectos por el otro. El project management necesita conceptos especiales, herramientas,
procedimientos y sistemas, y estaremos escuchando algo sobre eso más adelante en la conferencia.
Debemos tener cuidado de desarrollar en exceso estas áreas sin un desarrollo proporcional de un
conocimiento sólido de ellas y de las habilidades necesarias para utilizarlas eficazmente.
La administración de proyectos requiere de dos categorías básicas de habilidades las cuales son
relativamente nuevas, al menos en algunas industrias. Éstas son:

 Habilidades en la dirección de proyectos

 Habilidades para operar y desarrollar sistemas de administración de proyectos los cuales apoyarán
las actividades del project manager

Esas habilidades deben ser desarrolladas en cada organización al mismo tiempo que los sistemas, pero
frecuentemente hemos fallado en reconocer este hecho. La administración de proyectos está surgiendo como
una importante área de especialización en Dirección en el ámbito institucional, gubernamental, de negocios e
industrial. El algunas industrias o agencias, es bien sabido y bien establecido (aunque no siempre cae bien o
es bien entendido); mientras que en otras, es una idea completamente nueva. Me atrevo a predecir que la
administración de proyectos tomará su legítimo lugar en los organigramas de la mayoría de las organizaciones
en los próximos pocos años, junto con la gestión financiera, de producción, marketing, ingeniería y la dirección
en general

¿Qué es project management?

La administración de proyectos está fundamentada en tres conceptos clave:

 La responsabilidad central por el esfuerzo total es ostentada por el administrador del proyecto
 La planificación central y el control del esfuerzo total es lograda por varias funciones de apoyo de
administración de proyectos que colaboran con el project manager y utilizan herramientas
especializadas, técnicas y sistemas.
 El desempeño descentralizado del trabajo por varias personas en diversas organizaciones en
respuesta a ciertos tipos de directrices del project manager

II. Proyectos y los Trabajadores del

Conocimiento

Existen muchos tipos de proyectos

En el grupo de asistentes a esta conferencia, nosotros

representamos diferentes tipos de proyectos. En su mayoría
son diferencias asombrosas relacionadas a la naturaleza de
los resultados finales o productos de proyectos. Éstas incluyen
plantas de energía, nuevos productos para el consumo,
sistemas de software, rascacielos y muchos otros productos.
Pero es sorprendente ver que las características
fundamentales de gestión de todos los proyectos son muy
similares.

Trabajadores Manuales vs Trabajadores del Conocimiento

Una característica común de los proyectos es que utilizan

muchos tipos diversos de habilidades humanas. Al pensar en
estas habilidades, podemos hacer una diferenciación clave,
entre los trabajadores o habilidades manuales y los
trabajadores o habilidades del conocimiento:

 Los trabajadores manuales obviamente trabajan principalmente con sus manos, cuerpos y músculos,
ellos crean productos físicos (hardware), operan máquinas y usan herramientas físicas
 Los trabajadores del conocimiento usan principalmente sus mentes más que sus manos ellos crean
productos que no son físicos (software), tales como ideas, datos, informaciones, reportes, diseños,
planos, sus productos salen de sus bocas o mediante la escritura
Acordado esto, los trabajadores manuales utilizan su conocimiento en sus labores y en muchos casos son
más inteligentes que los trabajadores del conocimiento. Quiero aprovechar la diferenciación anterior (por la
cual estoy en deuda con Peter Drucker, como una cuestión de hecho, para señalar esta diferencia
fundamental en su libro “El Ejecutivo Efectivo”), a efectos de nuestra discusión y con la esperanza de que no
hay ninguna inferencia peyorativa en las definiciones establecidas.

En la mayoría de los proyectos, encontramos que una proporción mucho mayor de los trabajadores del
conocimiento están vinculados a las fases iniciales del proyecto, mientras que en las fases finales podría
haber una mayor proporción de trabajadores manuales (si es que el proyecto utiliza algún trabajador manual).
La conceptualización, diseño, suministro, construcción, puesta en marcha, arranque y operación inicial de una
planta de proceso es típico de muchos proyectos que usan ambos tipos de trabajadores. No habrá ningún
trabajador manual al inicio, pero sí habrá varios cientos durante la fase de construcción. Los trabajadores del
conocimiento permanecerán involucrados en todo el proceso.

Planificación Total del Proyecto

Mi experiencia indica que muchos de los fracasos de la administración de proyectos se remontan a la falta de
una planificación total del proyecto. Por lo general, abordamos una fase particular de un proyecto, como la
construcción de campo. Incluso podemos argumentar que abordamos la fase que tiene el mayor índice de
actividad manual para los trabajadores del conocimiento.

La planificación total significa la integración de todas las fases del ciclo de vida del proyecto, concepto,
definición, diseño, desarrollo (construcción), implementación (arranque). Sin embargo, esta integración
requiere de la planificación y la programación de los esfuerzos de los trabajadores del conocimiento. Esto
significa el regreso al origen del proyecto, e interrelacionar la fase del trabajador del conocimiento con la
posterior, más fácilmente en las fases planificadas. He encontrado que una gran cantidad de tiempo es
desaprovechado en estas fases iniciales y en las fases finales hay que exprimirse y sufrir las consecuencias.
Nosotros queremos que la ruta crítica registre todo el camino de regreso al punto de origen del proyecto, en el
caso de que sea posible.

Únicamente cuando un enfoque del proyecto total es utilizado se conseguirán beneficios óptimos de gestión
de proyectos. Por lo tanto, debemos desarrollar las capacidades necesarias para planificar y programar los
esfuerzos de los trabajadores del conocimiento

III. Necesario: Una nueva visión de la planificación y calendarización para los

trabajadores del conocimiento

Nuestros intentos por planificar y calendarizar los esfuerzos de los trabajadores del conocimiento,
frecuentemente no son muy exitosos. Todos hemos oído la dolorosa reacción de nuestros colegas
trabajadores del conocimiento:

 “No puedes programar creativamente”

 “No tengo tiempo para planificar – Tengo algo de trabajo hecho”
 “Buena idea para todos los demás, pero no para mí, yo soy diferente”
 “Tú no entiendes nuestros problemas”

Creo que nuestras dificultades provienen de dos fuentes

 La naturaleza inherente de la gente ligada a planificar

 Nuestro enfoque a la planificación y a la calendarización

Dificultades de planificación inherentes a las personas

Intrínsecamente, la mayoría de las personas no les gusta planificar abiertamente en coordinación con otros.
Es difícil el trabajo creativo; es revelador, y a la mayoría de las personas no les gusta poner sus técnicas o el
alma de sus negocios al desnudo para quedar al descubierto y ser abusados por otros. Me temo que si yo
produzco un plan, estaré irrevocablemente comprometido con éste y perderé mi libertad de acción profesional.
Creo que la planificación de algún modo eliminará mi habilidad para crear, inventar y dejar mi marca en el
esfuerzo.

Finalmente y muy importante, la palabra “calendario” connota una tienda o un campo, sin actividad
profesional. Si la palabra “planificar” es mala, la palabra “calendario” es infinitamente peor. No me agrada
guiarme bajo un calendario, porque me molesta que mi profesionalismo sea tratado de la misma manera que
un trabajador de una línea de producción. También considero a cualquier persona, incluso si parece ser un
profesional que está en al negocio de la calendarización, como alguien quien es muy sospechosa, al menos.

Nuestro enfoque a planificar y calendarizar agrava las dificultades

Además de las dificultades inherentes de las personas, nosotros –aquellos o nosotros quienes estamos en la
administración de proyectos y en general en los negocios de gestión- acrecentamos los problemas y las
dificultades por el enfoque que le damos a la planificación y a la programación de los esfuerzos de los
trabajadores del conocimiento. En la mayoría de los casos, no en todos, nuestro enfoque es:

 No reconocer suficientemente las aversiones inherentes a los seres humanos que están involucradas
 No reconocer las diferencias entre la planificación y la calendarización del trabajo manual y el de
conocimiento
 Utilizar a la misma gente de la misma parte de la organización para planificar y calendarizar tanto el
trabajo manual como el de conocimiento
 Poner esta parte de la organización en el lugar equivocado y arrastrar esta importante función al nivel
de control de la tienda

El resultado de todo esto es que los planificadores y programadores de los proyectos no son vistos como
profesionales. Ellos a su vez, se involucran más en las mecánicas de los sistemas de administración de
proyectos, probando quizá su profesionalismo. Esto a su vez amplía la brecha con los trabajadores del
conocimiento, y las personas que apoyan el proyecto continúan perdiendo contacto con las personas que
hacen el trabajo en el proyecto.

Debemos romper esta cadena de eventos desarrollando una nueva visión de la planificación y calendarización
del trabajo de conocimiento, llevándonos al reconocimiento de la naturaleza profesional de esta función.

IV. Un enfoque recomendado

Estudio de la función

En el desarrollo de una nueva visión que es necesaria, el primer paso sería estudiar la función de los
esfuerzos de planificación y programación de los trabajadores del conocimiento, con los siguientes propósitos:

 Reconocer la naturaleza verdadera de esta función

 Identificar sus características primarias
 Identificar los problemas humanos subyacentes

Describir la función

Con base en los estudios realizados, describir esta función y sus características básicas, de tal manera que
todos los afectados comprendan más cabalmente su naturaleza.

Diferenciar esta función del trabajo manual de planificación y programación

Un objetivo principal del estudio y descripción sería diferenciarlo del trabajo manual de planificación y
calendarización, por lo que un enfoque mejorado podría ser desarrollado.

Reconocer y promover la naturaleza profesional de esta función

Como consecuencia de la diferenciación y separación del trabajo manual de planificación y programación,
nosotros seremos capaces de reconocer y promover efectivamente la naturaleza profesional de esta función.

Utilizar al Project Management Institute

El Project Management Institute proporciona el potencial para lograr un número de cosas en este sentido,
como un medio para:

 Desarrollar el estudio y análisis requerido

 Documentar un cuerpo común de conocimiento en ésta y otras áreas de la administración de
proyectos
 Desarrollar el profesionalismo de los planificadores de proyectos
 Incentivar a los trabajadores del conocimiento para que entren en este campo
 Desarrollar habilidades mejoradas, herramientas, técnicas y sistemas
 Promover los intereses de las personas desempeñando esta función
 Transmitir un conocimiento sólido de esta función al resto del mundo

V. Dónde se integra el control

Hasta este punto, hemos estado discutiendo sobre la planificación y la programación, casi de manera
exclusiva. Pero, qué hay del control.

Control del trabajo de conocimiento

Este control es ejercido tanto por el project manager como por la organización o los directores funcionales. El
plan y el calendario proporciona el marco para el control y la información o el sistema de administración del
proyecto brinda la información que los directores necesitan para el control. El sistema no ejerce directamente
el control, como tampoco el planificador del proyecto quien está sirviendo al project manager.

La función de planificación de proyectos es análoga a la función de interventor financiero

La planeación y el control del proyecto son análogos en muchos sentidos para el interventor financiero. El
contralor financiero planifica el gráfico de cuentas con las directrices del director general, desarrolla los
sistemas de soporte y maneja el departamento de contabilidad el cual opera el sistema de información
financiera. Pero los gerentes de la organización o en la línea de control de sus propios departamentos, usan
información (y tal vez responden a presiones) proporcionadas por el contralor financiero.

En una forma similar, el jefe planificador del proyecto (o quizá el contralor del proyecto) planifica el proyecto
con las directrices del director general, desarrolla los sistemas de soporte y maneja el departamento el cual
opera el sistema de administración de proyectos. Pero el project manager de hecho controla sus propios
proyectos, en cooperación con los gerentes de la organización, utilizando información (tal vez respondiendo a
la presión) proporcionada por el planificador del proyecto.

La función del auditor, bien conocida en el área financiera, es bastante confusa en la administración de
proyectos. Tal vez algunas de nuestras dificultades se derivan de nuestros intentos por hacer que el
planificador del proyecto audite sus propias funciones
El control del conocimiento viene desde adentro

Salvo por ciertas raras excepciones, el project manager debe lograr el control en un entorno de gestión
participativo. Él no puede dictar a la fuerza y no tiene autoridad total, por muchas razones.

En un ambiente como éste, el control viene desde adentro. Esto es especialmente cierto con los trabajadores
del conocimiento. Por lo tanto, si el proyecto está bien planificado y programado, y los trabajadores del
conocimiento han participado en esta función mediante la cooperación con sus hermanos profesionalmente
reconocidos (los planificadores del proyecto), van a ejercer el control individual de sus actividades para que se
ajuste al plan y el programa .

En esta situación deseable, el project manager anticipa los problemas generados por circuntancias
imprevistas, cambios que vienen desde afuera y así sucesivamente, permitiéndole alertar a todos los
afectados de la necesidad de revisar el plan y el calendario con la antelación del evento como sea posible.
Los gerentes de la organización entonces se preocupan por la dirección de las tareas en su área de
especialización, el manejo y la supervisión de su gente, el desempeño de su departamento y los conflictos con
otros proyectos.

VI. Comentarios finales

Iniciamos enfocándonos en proyectos y su administración como nuestra causa común en esta conferencia y
brevemente discutimos las características básicas de los proyectos y la administración de proyectos. Creo que
todos nosotros estamos de acuerdo que el project management está creciendo en importancia o ninguno
estaría hoy aquí. Para resumir varios de los puntos fundamentales, me gustaría comunicar lo siguiente:

 La administración de proyectos requiere diferentes habilidades para:

Manejar proyectos
Planificar y programar proyectos
 Los proyectos implican tanto trabajadores manuales como de conocimiento
 La planificación y programación integrada y total de un proyecto es vital para la consecución de los
beneficios de la administración de proyectos
 Se requiere la planificación y calendarización del trabajado de conocimiento para lograr la
planificación total del proyecto
 Es necesaria una nueva visión de esta función para superar las dificultades que se presenten
 Debe ser reconocida la naturaleza profesional de la planificación y calendarización del trabajo de
conocimiento
 El Project Management Institute puede ser valioso en este sentido
 El control del trabajo de conocimiento se desarrolla a partir del plan

Creo que el planteamiento expuesto puede ser de gran valor para el campo de la administración de proyectos,
y pueden contribuir a acelerar el reconocimiento adecuado del project management como un área importante
dentro de la especialización en dirección.

Este texto corresponde al Seminario en Conceptos Avanzados de Administración de Proyectos Co

patrocinado por La Escuela de Ingeniería Industrial y Sistemas del Instituto de Tecnología de Georgia y El
Project Management Institute 9-10 de Octubre, 1969, Atlanta, Georgia, Estados Unidos. (Volver al inicio del
artículo)
Categorías para obtener PDUs

Ofreciendo mayores herramientas que permitan el crecimiento de la administración de proyectos, el Project

Management Institute (PMI®), reestructuró la forma en la cual las personas que ya cuentan con una
certificación, podrán conseguir PDUs o Unidades de Desarrollo Profesional, las cuales no son más que las
valoraciones oficiales respecto a las actividades de project management que alguien realiza para continuar
con su crecimiento profesional.

Esta propuesta surgió debido a que el PMI® notó que las personas no suelen comprender muy bien las
categorías de PDUs y cómo reportar la obtención de éstos correctamente. Dada esta circunstancia, desde
este primero de marzo de 2011 el Project Management Institute presenta una estructura más amigable y un
mejor servicio a las personas que cuentan con una certificación y desean mantenerla.

Visión global de los cambios a la estructura de las categorías de PDUs:

 La estructura de las categorías del CCR ha sido simplificada, de ese modo se reduce el número de
categorías de 18 a únicamente 6.
 Las categorías han sido ampliadas en su ámbito de funcionamiento para incluir las oportunidades de
aprendizaje que hoy en día proporciona la Web 2.0.
 Habrá límites en ciertas categorías, en cuanto a las exigencias a las personas certificadas, de tal
forma que sigan con una formación continua en project management como parte del mantenimiento
de la credencial.

También es importante tener en cuenta lo que no se modifica en este programa:

 El ciclo de renovación de cada tres años y el número de PDUs requeridos para mantener la
credencial quedará de la misma forma que funciona actualmente.
 La estructura de costos por re-certificación seguirá siendo la misma.

Anteriores categorías Nueva modalidad

Categoría 1 Categoría B
Educación Académica Formal. Educación Continua

Categoría 2 A
Categoría D
Autor/Coautor de un artículo en una revista.
Aporte al Project Management (incluye las
30/20 PDUs por artículo.
categorías 2A hasta 2G, y nuevas por
creación de webinars, podcasts y otras
Categoría 2 B formas de publicación).
Autor/Coautor de un artículo en un medio (no revista) 45 PDUs máximas en categorías D, E y F si
15/10 PDUs por artículo. se sostiene una credencial PMP® o
PgMP®.
Categoría 2 C 20 PDUs máximas en categorías D, E y F si
Orador, maestro en conferencias, simposios, workshop o se sostiene una credencial PMI®-RMP o
curso formal. PMI®-SP.
10 PDUs por actividad.
Categoría 2 D
Orador de un tópico de Project Management en un PMI®
Component Meeting.
5 PDUs por actividad.

Categoría 2 E
Miembro o moderador de un panel de discusión en Project
Management.
5 PDUs por actividad.
Categoría 2 F
Autor/Coautor de un libro de texto
40/20 PDUs por actividad.
Categoría 2 G
Desarrollador de un material de curso
10 PDUs por actividad
Categoría F
Trabajar como profesional en Project
Management.
15 PDUs máximas en esta categoría (F).
Categoría 2 H
45 PDUs máximas en las categorías D, E y
Practicante en servicios de Project Managenent
F en total si se sostiene una credencial
15 PDUs máximos
PMP® o PgMP®.
20 PDUs máximas en categorías D, E y F si
se sostiene una credencial PMI®-RMP o
PMI®-SP.

Categoría C
Autoaprendizaje.
Categoría 2 SDL
30 PDUs máximas en total si se sostiene
Autoaprendizaje
una credencial PMP® o PgMP®.
15 PDUs máximas
15 PDUs máximas en total si se sostiene
una credencial PMI®-RMP o PMI®-SP.
Categoría A
Categoría 3
Cursos ofrecidos por R.E.P.s o Capítulos
Cursos en REP o Componentes del PMI®
PMI® o Comunidades

Categoría 4 Categoría B
Cursos ofrecidos por otros proveedores de educación Educación Continua

Categoría E
Categoría 5 A
Servicio Voluntario
Servicio Voluntario-Officer Electo
Incluye todas las viejas categorías 5A, 5B,
20 PDUs como máximo en todas las Categorías 5
5C más voluntariado directamente para el
 PMI®.
Categoría 5 B 45 PDUs máximas en las categorías D,E y
Voluntario/Miembro de Comité F en total si se sostiene una credencial
20 PDUs como máximo en todas las Categorías 5 PMP® o PgMP®
20 PDUs máximas en categorías D, E y F si
Categoría 5 C se sostiene una credencial PMI®-RMP o
Voluntario en servicios relacionados al Project PMI®-SP.
Management.
20 PDUs como máximo en todas las Categorías 5
IV TEMA

Estructura del PMBOK®

Por Mauricio Morales, PMP® [ Acerca del autor]

El Project Management Institute (PMI®) creó, en 1996, la primera edición de “A Guide to the Project
Management Body of Knowledge” llevando al mundo un documento que, poco a poco, fue calando en las
industrias y en la administración de proyectos, convirtiéndose en un estándar avalado por ANSI en el año
2000 con su segunda edición. Actualmente, en su cuarta edición de 2008, el PMBOK® es el documento de
referencia obligado para cualquier persona que desee mejorar su gerencia de proyectos, certificarse o
simplemente incrementar el éxito de sus proyectos; y para cualquier organización que desee implementar
procesos y metodologías eficaces para lograr el éxito de sus proyectos.

El boom del PMBOK® se da desde el año 2000 cuando tuvo lugar una fuerte importante evolución del
estándar (y cuando se empezó a cobrar, ya que el de 1996 había sido gratuito).

El PMBOK® compite con otros modelos de gerencia de proyectos como el de la Association for Project
Management (APM) y Prince (en Reino Unido); sin embargo, se ha posicionado a nivel mundial como
estándar de gerencia de proyectos y las certificaciones otorgadas sobre este, como Certificate Associate in
Project Management (CAPM®) y Project Management Professional (PMP®) son las más reconocidas por las
empresas y las más buscadas por los practicantes.

El PMBOK® es un compendio de mejores prácticas, agrupadas de cierta manera, heredadas de diversas

industrias y disciplinas que conforman un modelo metodológico. El PMBOK® en sí no es una metodología que
“deba” ser seguida al pie de la letra; de hecho, el mismo documento, indica que los procesos y sus relaciones
deben ser personalizados a las necesidades del proyecto y de la empresa. El PMBOK® es sólo una guía, muy
completa y elaborada, de lo que normalmente un gerente de proyectos debe llevar a cabo, explicado en un
buen nivel de detalle y separando procesos que normalmente se llevan a cabo de forma simultánea.

Como modelo, el PMBOK® no nos indica cómo se hacen las cosas, al igual que CMMi® pero es más explícito
que éste en la definición de los procesos o prácticas a llevar a cabo, estableciendo una serie de entradas,
técnicas y salidas para cada uno.

ESTRUCTURA

El PMBOK® establece la administración de proyectos como un conjunto de nueve áreas de conocimiento que
deben ser dominadas por el project manager y que contienen una serie de procesos que corresponden a los
pasos necesarios para que sean completamente cubiertas. Cada proceso establece unas entradas
(documentos), técnicas (mejores prácticas) y salidas (nuevamente documentos). Tanto las entradas como las
salidas conectan a los diferentes procesos entre sí para formar una completa red sobre la que se puede
establecer una metodología.

El PMBOK® puede verse de dos formas diferentes, cual si fuera una matriz que puede leerse por columnas o
filas. La forma estándar como está estructurado el documento establece áreas de conocimiento. La forma útil
para el gerente de proyectos y la organización es, sin embargo, por grupos de procesos de Inicio, Planeación,
Ejecución, Control y Cierre.

REPRESENTACIÓN POR ÁREAS DE CONOCIMIENTO

Las áreas de conocimiento definidas en el PMBOK® son:

 Gestión de Integración – Procesos requeridos para integrar todas las actividades, documentos y
recursos del proyecto.
  Gestión de Alcance – Procesos requeridos para identificar todo el trabajo requerido y sólo el trabajo
requerido para obtener los entregables del proyecto y cumplir los objetivos.
 Gestión de Tiempo – Procesos requeridos para asegurar que el proyecto es finalizado a tiempo.
 Gestión de Costos – Procesos requeridos para asegurar que el proyecto es finalizado dentro de un
presupuesto aprobado.
 Gestión de Calidad – Procesos requeridos para asegurar que el proyecto cumple los requerimientos
y necesidades por los cuales fue emprendido.
 Gestión de Comunicaciones – Procesos requeridos para asegurar la generación, distribución,
almacenamiento y disposición última de toda la información del proyecto, a tiempo y de forma
adecuada.
 Gestión de Recursos Humanos – Procesos requeridos para administrar eficientemente la gente
que participa en el proyecto.
 Gestión de Riesgos – Procesos requeridos para identificar, analizar y responder efectivamente a los
riesgos del proyecto.
 Gestión de Adquisiciones – Procesos requeridos para adquirir bienes y servicios fuera de la
organización del proyecto.

Cada área de conocimiento incluye varios procesos que se presentan en la siguiente tabla:
 Ilustración 1 - Áreas de Conocimiento de la Gerencia de Proyectos con sus Procesos Internos

REPRESENTACIÓN POR GRUPOS DE PROCESO

Como se puede apreciar en el segmento anterior, la estructura del PMBOK® por áreas de conocimiento da
una interesante clasificación de procesos y conocimientos a ser dominados por el líder de proyectos pero,
seamos honestos, es difícil seguir esta estructura a lo largo de un proyecto. Es como intentar armar un
rompecabezas con las piezas hacia abajo, cuando no se aprecia una conexión entre las mismas, más allá de
su forma.

Debido a la aparente desconexión entre procesos y áreas, el PMBOK® también define una estructura por
grupos de procesos. Estos grupos son simplemente la secuencia lógica que sigue cualquier proyecto: Inicio,
Planeación, Ejecución, Control y Cierre.

La secuencia de los grupos de procesos varió de la planteada en PMBOK® 1996 y 2000 a la descrita en las
ediciones 3ª y 4ª. A continuación presentamos ambas representaciones.

Ilustración 2 - Representación de Grupos de Procesos en PMBOK® 1996 y 2000

En esta representación el énfasis se encuentra en las interrelaciones de los grupos de procesos, en donde se
evidencia un ciclo permanente entre planeación, ejecución y control que claramente indica que la planeación
no está escrita sobre piedra y que debe ser modificada de acuerdo a la situación del proyecto en un momento
particular.

Ilustración 3 - Representación de Grupos de Procesos del PMBOK® 2004 y 2008

En esta última representación se ha llevado la estructura de procesos a una forma acorde con el modelo de
mejoramiento continuo de Edward Deming, PHVA, promulgado desde la versión 2004. Evidencia también un
ciclo entre planeación y ejecución pero siempre sobre una base permanente de seguimiento y control.
Dentro de cada uno de los grupos de proceso se encuentran ahora los procesos de las áreas de
conocimiento, conectados entre sí de una manera secuencial y lógica, que permite un seguimiento natural por
parte del gerente de proyecto y determina una forma de evolución del proyecto y de los documentos.
A continuación presentamos los procesos subyacentes dentro de los grupos de procesos:

Ilustración 4 - Procesos de Inicio del Proyecto según el PMBOK® 2008

Ilustración 5 - Procesos de Planeación del Proyecto según el PMBOK® 2008

 Ilustración 6 - Procesos de Ejecución del Proyecto según el PMBOK® 2008

Ilustración 7 - Procesos de Control del Proyecto según el PMBOK® 2008

Ilustración 8 - Procesos de Cierre del Proyecto según el PMBOK® 2008

La implementación de CMMI® desde la perspectiva del PMBOK®

Por Mauricio Morales, PMP® [ Acerca del autor]

CMMi® y PMBOK®. Dos de las más reconocidas siglas a nivel mundial y sinónimo de calidad, organización,
proceso, formalismo, reconocimiento, mejoramiento. Sin embargo, también representan, para muchas
empresas o personas algo complejo, difícil, largo, costoso, impráctico. Sobre todo, costoso.

Por un lado, CMMi® ha sido renombrado a nivel mundial como estándar de medición de calidad de los
procesos de una organización, desde que en 1987 el Departamento de Defensa de los EE.UU. (DoD) logró su
definición (CMM en ese momento) por parte del patrocinado Software Engineering Institute (SEI) de la
Universidad de Carnegie-Mellon. Recientemente empezó a regir la versión 1.2 del modelo integrado CMMi®
que, curiosamente, nuevamente se ha desintegrado para entregar varios sabores, a saber, CMMi® for
Development, CMMi® for acquisition y últimamente CMMi® for Services, permitiendo, con este último, cubrir
cualquier tipo de organización que produzca servicios y no productos.

Por otro lado, PMBOK®, siglas de Project Management Body of Knowledge, término acuñado por el Project
Management Institute (PMI®) y que indica que su contenido se extrae del conocimiento global sobre el tema;
lanzado en 1996 como un abrebocas al boom que se avecinaría con su segunda edición del año 2000 y que
ya se encuentra en su cuarta edición. Orientado a personas que se han especializado en gerencia de
proyectos y que busca formalizar y profesionalizar las actividades, un tanto oscuras hasta hace poco, del
administrador de proyectos de cualquier industria.

La primera, orientada a empresas, la segunda orientada a personas. ¿Cómo se pueden relacionar? ¿Cómo se
pueden aprovechar? ¿Pueden ser complementados, acoplados o diferenciados en la implantación? ¿Me sirve
uno para llegar al otro?.

CMMi® y PMBOK® son dos modelos que se han convertido en estándares de mejoramiento e
implementación de buenas prácticas enfocados, el primero a mejoramiento organizacional, ingeniería y
proyectos de ingeniería, el segundo a proyectos de cualquier índole a cualquier nivel en una organización, sin
obligar a una implantación a través de la misma.

CMMi® y PMBOK® tienen puntos importantes de encuentro en donde PMBOK®, con sus procesos, apoya la
consecución de metas específicas y genéricas de CMMi® en los niveles de madurez 2 a 4 con obvias
diferencias en áreas de ingeniería o aspectos de proceso que no son competencia del PMBOK®.

El nivel de acoplamiento de las prácticas de CMMi® y metas tanto específicas como genéricas con los
procesos, entradas, técnicas y herramientas y salidas del PMBOK® es alto, permitiendo llegar a grandes
fortalezas en el primero, a través del segundo.

Un proceso de mejoramiento llevado a cabo sobre las mejores prácticas definidas por el PMBOK® permite
cerrar la brecha entre lo que se debe hacer y cómo se debe hacer pues establece un adecuado nivel de
detalle que permite seleccionar las prácticas pero con la libertad de determinar la formalidad de la
implementación.

Se puede llevar a cabo un proceso de mejoramiento hacia CMMi® partiendo desde PMBOK® con un cierre
adicional de brechas en prácticas de ingeniería y procesos en niveles superiores de madurez.

Para todo el mejoramiento se requerirá un fuerte componente de entrenamiento a nivel organizacional para
lograr la mayor concientización posible sobre lo que se espera y se requiere desarrollar.

OPM3® ¿Qué le depara el futuro?

Por Marcelo Tedesco, PMP® y MIB [ Acerca del autor ]

El nacimiento

En 1983, a 14 años de su creación, el Project Management Institute (PMI®) publicó su primer estándar,
denominado el Reporte Especial en Ética, Estándares y Acreditación (ESA). Este fue el primero de una
fructífera producción y aporte de valor agregado a las prácticas definidas para la Gestión de Proyectos en
cualquier tipo de industria.
 Siguiendo con la cronología, en 1987 se publicó lo que sería la guía de
facto en la práctica de la gestión de proyectos a nivel mundial, el
PMBOK® Guide, el cual con los aportes de miles de profesionales fue
evolucionado hasta lo que hoy conocemos como 3rd Edition. Dado el
éxito y el crecimiento de la aplicación del estándar y la fabulosa
contribución de los miembros del PMI® se han desarrollado marcos de
referencia complementarios con el fin de robustecer la práctica. De estas
iniciativas nacieron “Project Manager Competency Development
Framework” (2002), “The Standard for Program Management” (2006),
“The Standard for Portfolio Management” (2006) del cual está por
liberarse la segunda edición en los últimos meses de este año, y del que
tuve la honrosa oportunidad de colaborar como Deputy Communication
Team Leader, y del que particularmente considero es uno de los pasos
más significativos en la práctica, ya que integra de manera definitiva la
Gestión de Proyectos al punto medular de una Organización, su
Estrategia.

El siguiente paso lógico después de la publicación del “Project Manager

Competency Development Framework” era acercar la práctica a las organizaciones y es así como en 2003 se
publica el “Organizational Project Management Maturity Model” más popularmente conocido como OPM3®
que tiene como principal objetivo tender un puente entre la Gestión de Proyectos y la Estrategia de la
Organización.

Qué es la Gestión de Proyectos Organizacional

De acuerdo al mismo estándar, es la alineación sistemática de la gestión de Proyectos, Programas y

Portafolios (PPyP) con el logro de las metas estratégicas de la Organización; ya que intenta ayudar a lograr
los objetivos de una empresa a través de la gestión de proyectos.
El concepto está basado en la idea de que hay una clara correlación entre las capacidades en Gestión de
PPyP que existen dentro de una Organización y la efectividad en la implementación de las estrategias de ésta,
por consiguiente la madurez en la gestión de proyectos dentro de una Organización depende del grado con el
cual se implementan las mejores prácticas en PPyP.
Qué es OPM3®

Es el Modelo estándar que tiene como propósito proveer un camino para que las organizaciones entiendan y
midan su madurez contra una serie de mejores prácticas establecidas. Igualmente, ayuda a alcanzar una
mayor madurez a través del desarrollo de un plan de mejora.

Así funciona

OPM3® resalta tres elementos básicos en los cuales sustenta el

avance del Modelo, éstos son “Conocimiento” (Knowledge),
“Evaluación” (Assessment), y “Mejora” (Improvement), cada unos
de estos pasos se deben ir repitiendo periódicamente para ir
“madurando”.
El Modelo establece que “Conocimiento” es el provisto por el
PMBOK®, así lo estipulaba en su momento el OPM3® que fue
publicado en 2003, sin embargo, ahora se suma y enriquece con
el Standard for Program Management y Portfolio Management.
Estos tres estándares son la base del conocimiento con los que
tienen que contar los integrantes de los equipos de proyectos de
la Organización. Claro que no es necesario la aplicación de
todos, finalmente el Modelo de madurez es para las tres
verticales de PPyP y se puede ir madurando en cada una de
ellas, empezando por Proyectos luego Programas y terminando
con Portafolio, o hacerlo en paralelo, dependerá mucho del nivel
de conocimiento con el que cuenten los integrantes de la Organización al iniciar un proyecto de OPM3®.

La “Evaluación” o Assesment consiste en aplicar un test de 500 (quinientas) preguntas, sí, leyeron bien, son
500 (quinientas) preguntas relacionadas con la práctica dentro de una Organización en Gestión de PPyP.

Esta evaluación ayuda a la Organización a

entender cuál es su estado actual de madurez y
cuáles son las mejores prácticas o grupo de
mejores prácticas en las que deben trabajar con
el objetivo de mejorar su competencia y
capacidades.

Una vez finalizado el proceso la Organización

puede decidir realizar una investigación más
profunda, continuar con un plan de “Mejora” o
simplemente si cree que el costo de “madurar”
es demasiado alto comparado con los beneficios,
entonces puede decidir terminar el proceso.
Ahora bien en el entendido de que la
Organización decidió continuar con un proceso
de “Mejora” o Improvement entonces podrá usar
la lista de “Capacidades” que de acuerdo a la
Evaluación aún no se encuentran desarrolladas
para confeccionar el plan de “Mejora”, es
importante aclarar que si bien la “Evaluación” arrojará cuáles son las prácticas a mejorar en orden de
prioridad, el Plan de Mejora dependerá de la Organización, y éste puede incluir cambios organigrámicos,
cambios de gerentes, reestructuraciones y
otras iniciativas que van más allá de lo que
OMP3 abarca.

Para evitar confusiones quise dejar hasta el

final de ésta sección lo que en realidad debe
ser el primer paso. La aplicación de OMP3
en una Organización no requiere de
consultores expertos en el Modelo ni mucho
menos, sin duda esto contradice los taboos
que a los PMP®s nos encanta formar
alrededor de la práctica, sin embargo si es esencial la adquisición de lo que se denomina OPM3® Product
Suitev, una plataforma desarrollada por el PMI® para ayudar a las Organizaciones a la implementación del
Modelo, ésta plataforma contiene toda la información, guías, y por supuesto la “Evaluación”, así como la
resultante para el Plan de Mejora. Este componente puede ser adquirido en CD u On-Line, el costo es
moderado, 695.00 USD (Seiscientos noventa y cinco dólares) en la versión Single-User, o 4,495.99 USD
(Cuatro mil cuatrocientos noventa y cinco dólares) la versión para máximo 15 usuarios; los cuales se definen
por la cantidad de personas que tendrán una implicación directa en el proyecto de la implementación del
Modelo.

Mi recomendación a los que estén interesados en comenzar con un proyecto de éste tipo es que adquieran
primero la versión Single-User para realizar la “Evaluación” y luego determinan la viabilidad del proyecto.

El Futuro

Tratar de determinar el futuro de cualquier Modelo de mejores prácticas puede ser poco menos que una tarea
agorera, como dice un colega mío “Todos los Modelos son modas, lo importante es que te dan una lista de
prácticas que nunca debes olvidar”, esto se comprueba en que muchas de las mejores prácticas consideradas
para ITIL (Information Techbology Infraestructure Library) ya las había establecido Tomas Edison en el siglo
XIX para su sistema de Generación y Distribución de Energía, los modelos siempre tendrán su inicio, auge y
maduración para luego dar lugar a uno nuevo, seguramente basado en otro anterior.

Lo que no se pueda negar es la juventud del Modelo OPM3® con apenas 5 (cinco) años, otros modelos
similares como ITIL o CMMI (Capability Maturity Model Integration) han necesitado un par de décadas para
comenzar a popularizarse en las organizaciones, ITIL ha requerido poco menos de 20 (veinte) años, y CMMI
cerca de 15 (quince), no obstante, la ventaja con la que cuenta OPM3® es que la práctica de la Gestión de
Proyecto ya está muy difundida a nivel mundial lo cual facilita la expansión del Modelo de Madurez y
seguramente el punto de auge llegará más rápido que con los modelos anteriormente mencionados.

No hay registro de un número claro de empresas que han comenzado a adoptar el Modelo, sin embargo
existen en el mundo sólo 98 Consultores/Asesores certificados , esto nos da una idea de la baja adopción que
ha tenido hasta ahora, en Latinoamérica sólo existen 3 (tres), ustedes mismos pueden sacar las conclusiones.

Estoy seguro que en nuestra región el paso lento está dado por la misma concepción del Modelo, y es algo
que se presta a mucha confusión y decepción: NO se certifican empresas, ni organizaciones, solamente se
pueden certificar personas. Si comparamos el éxito de adopción que ha tenido CMMI que sí certifica
empresas o el aumento exponencial que ha tenido la implementación de ITIL cuando éste pasó a ser un
estándar ISO (ISO2000), entonces el argumento es claro y contundente.

La razón por la cual es tan alto el impacto cuando un Modelo de estas características le entrega un certificado
a una empresa se debe al marketing que ésta puede realizar con el “papelito”, y así obtener beneficios
tangibles del esfuerzo titánico que pueda significar embarcarse en un proyecto como de tal magnitud.

Nadie niega que el valor real de OPM3® esté dado en las mejoras que se consiguen dentro de la
Organización y cómo impactan en la productividad, eficiencia, nuevos clientes, entre otros beneficios, sin
embargo, para la mayoría de las empresas esto no es suficiente. Hace poco un colega, Director de Proyectos
de una de las empresas de desarrollo de Software más grandes de Sudamérica me contactó debido a que
tenían interés de comenzar un proyecto de OPM3®, cuando comentamos que el Modelo no certificaba a
empresas su respuesta fue: “Rescato de tus comentarios el hecho que no se puede certificar una
Organización, lo cual era el objetivo de este proyecto que estábamos evaluando. Dado esto, sólo podemos
avanzar en obtener la herramienta y mirarnos cómo estamos”; por cierto, la empresa es CMMI Nivel 5, una
certificación que rondará en Latinoamérica los 300,000.00 USD (Trescientos mil dólares) de gasto directo,
llegar al máximo nivel de madurez de OPM3® puede rondar los 50,000.00 USD (Cincuenta mil dólares), en
ninguno de los dos casos estoy tomando en cuenta el tiempo hombre invertido internamente.

Por lo mismo el progreso y futuro de OPM3® será directamente proporcional a la iniciativa del PMI® para
transformarlo en un Modelo certificable, no es difícil, de hecho sólo se debe crear la infraestructura de
Consultores y Asesores para tal fin, tal y como existen para CMMI o cualquier norma ISO, pero el PMI® tiene
39 años de existencia y previo a que esto suceda, debería tocar su Misión: “Servir a su comunidad de
asociados y profesionales interesados, desarrollando el arte de dirigir y llevar a la práctica la Dirección de
Proyectos, como disciplina profesional”, algo que se torna mucho más complicado.

¿Cómo se traduce el PMBOK® al español?

Por Luis Ernesto Matos

Editorial LiderDeProyecto.com

El primero de julio de 2009 es un día crucial para todos los hispanoparlantes vinculados a la administración de
proyectos, y que es a partir de esta fecha entra en vigencia la traducción al español de la 4a edición del
Project Management Body of Knowledge (PMBOK® Guide).

La 4a edición del PMBOK® salió publicada en inglés a finales del 2008, lo que también marcó la actualización
de los exámenes para certificación en este idioma y lo mismo ocurrirá con su similar en español, porque a
partir de la fecha antes mencionada, las pruebas para alcanzar las credenciales otorgadas por el Project
Management Institute, serán modificadas en base a los cambios del Cuerpo de Conocimiento de
Administración de Proyectos.

Llevar a cabo la revisión e interpretación del PMBOK® Guide representa un proyecto realmente interesante y
de gran responsabilidad, porque en esta versión en español estarán fundamentados todos los conocimientos
teóricos de la comunidad de administradores de proyectos de las personas hispanohablantes.

Fue a través de un grupo multicultural y virtual que se logró concretar la revisión del contenido, poniendo de
manifiesto la importancia de las tecnologías para el éxito de los proyectos; pero sobre todo el trabajo arduo y
responsable de los 21 miembros del equipo quienes desde un principio asumieron la responsabilidad de sacar
este trabajo adelante.

El proyecto reunió a Project Managers Professional de comprobada experiencia, provenientes de México,

Puerto Rico, Argentina, Chile, Costa Rica y Uruguay; todos bajo la dirección de la PMP® Jessica González,
quien actualmente es Vicepresidenta de Programas de la mesa directiva del PMI® Capítulo Puerto Rico y de
manera exclusiva para LiderDeProyecto.com dialoga acerca de todo el proceso de validación de la traducción
de la 4a edición del PMBOK® Guide.

¿Cómo y cuándo fue el inicio del proyecto de validación de la traducción al español de la 4a Edición
del PMBOK®?

La revisión de la traducción al español de la 4a Edición del PMBOK® comenzó en agosto del 2008 cuando fui
llamada por un colega para ser la Directora del Proyecto y el PMI® aceptó la nominación. La selección se me
notificó por teléfono y por correo electrónico a finales de ese mes.
¿De qué manera y bajo qué criterios fue seleccionada como Administradora de este Proyecto, así
como los miembros de su equipo?

Éste, al igual que muchos otros proyectos del PMI®, es una oportunidad pública de voluntariado en la que
cualquier socio del PMI®, que se sienta capaz y que pueda aportar valor, puede solicitar su participación. De
acuerdo a lo informado por el PMP® Enrique Capella, en aquel momento Mentor de la Región Norte de
Latinoamérica, fui seleccionada por mis aportes como voluntaria, mi experiencia pasada manejando equipos
interdisciplinarios y dirigiendo proyectos, así como el dominio del inglés como segunda lengua.

Pero, seleccionar el equipo fue un reto interesante y a la vez un elemento motivador para mí. El PMI® solicitó
que el grupo fuera sólo de 10 participantes, incluyéndome a mí. Consideré que limitarlo a este número de
personas amenazaría lograr una versión del PMBOK® en español que fuera clara y comprendida fácilmente
por la mayoría de los socios de los países hispanoamericanos. Así que decidí romper la regla y aventurarme a
la creación de un equipo de trabajo más diverso. Por ese lado, el PMI® no tuvo ningún inconveniente con esta
medida siempre y cuando me sintiera cómoda con los retos que trae dirigir un grupo virtual más grande.

Seguidamente, hice un llamado de voluntarios a todos los capítulos de Hispanoamérica a través de sus
Presidentes y recibí alrededor de 110 Curriculum Vitae. Para formar el equipo me auto impuse los siguientes
requisitos:

1. Contar con al menos una persona de cada país interesado en la participación.

2. Balancear el equipo entre géneros, trasfondos y años de experiencia.

Obviamente esto fue aunado a las exigencia del PMI® en cuanto a habilidades de comunicación y
negociación, experiencia en administración de proyectos, excelente dominio del inglés, disposición para lograr
consensos, entre otras muchas cualidades.

Me siento extremadamente orgullosa de lo sucedido todos los días entre nosotros – fuimos un equipo
excepcional – y aunque distantes, percibí mucho calor humano y amistad en los correos que intercambiamos
y en nuestras reuniones. Creo que dirigir y desarrollar equipos virtualmente es posible cuando éste se
compone de personas de un nivel de profesionalismo y peritaje sobresaliente.

¿Qué actividades implicó la revisión de la Guía PMBOK®?

El alcance del proyecto se resumió en validar la traducción del PMBOK® al español. La traducción per se fue
hecha por un suplidor contratado por PMI®. La validación del contenido se realizó a todo el PMBOK® y no
sólo a las partes nuevas o modificadas en la versión cuatro. Este alcance estuvo compuesto principalmente de
las siguientes actividades:

Actividad Principal Entregable Criterio de Aceptación

Validar la traducción del Glosario Validado Los comentarios provistos mejoran la
Glosario calidad de la traducción y no cambian el
contexto del contenido
Validar la traducción de Capítulo validado usando la Los comentarios provistos mejoran la
los Capítulos técnica establecida por el PMI® calidad de la traducción y no cambian el
contexto del contenido
Responder a preguntas Formulario del cuestionario en Contestado y devuelto a PMI® en 5
del traductor español días calendario
Acta de Constitución del
Proyecto

Dirigir la validación de la Plan para la Dirección del

El proyecto se efectúa y entrega según
traducción del PMBOK® Proyecto
el plan
al español Órdenes de Cambio y Registro
de Órdenes de Cambio
Registro de Incidentes/Asuntos
 Informes de Progreso
Registro de Riesgos
Registro de Aceptación
Minutas de Reuniones
Notificación de Cierre
Informe de Lecciones
Aprendidas
Repositorio centralizado de
información del proyecto

Para la validación de la traducción de los capítulos, quisimos darnos la oportunidad de revisar al menos un
capítulo entre todos para asegurar que todos entendíamos y efectuábamos igual la tarea y para comenzar la
dinámica de estandarización de criterios de validación de calidad. Tal como ocurrió con los términos
estándares que usaríamos a través del PMBOK®, reglas gramaticales, etc. Luego, y debido a que el PMI®
enviaba dos capítulos a la vez o bien cercano uno de otro para su revisión, implementamos la división del
equipo en dos células (equipo para capítulos pares y equipo para capítulos nones).

Cada célula estaba coordinada por un Líder y estos micro grupos tenían la responsabilidad de revisar un
capítulo y todos sus anexos. El Líder fue responsable de recoger los comentarios de los participantes en la
fecha estipulada, dar el seguimiento que era requerido y consolidar los comentarios que recibía de sus
colaboradores. Para la selección de los Líderes, tomamos en consideración la cercanía y la confianza tanto
mía como de Jorge Valdés (Co-Líder) con personas ubicadas en nuestros respectivos países, incluso para
eventualmente poder tener reuniones presenciales con ellos, en el caso de que fuesen necesarias.

¿Cómo fue el proceso de coordinar un grupo de trabajo multicultural, los cuales en su totalidad son
PMP®s, a través de la utilización de medios electrónicos y sin contacto cara a cara?

Efectuar esta tarea ha sido una experiencia bien gratificante en mi carrera. Debido al reto que la misma
representó para mí, pude aprender muchísimo acerca de la dirección de equipos virtuales y sobre la clave
detrás del éxito de los mismos… el calibre de sus integrantes.

El hecho de ser multicultural fue un reto divertido para mí puesto que lo asumí como una oportunidad para
adquirir una idea o un sentir sobre el estilo de trabajo en estos países. Además percibí que todos estábamos
conscientes de este hecho y por lo tanto respetábamos a conciencia nuestras diferencias.

La complicación fue encontrar un medio de comunicación efectivo para nuestras reuniones. Algo en lo que sí
me impuse disciplina fue en mantener las reuniones de estatus bisemanales aunque fueran de sólo 15
minutos. Estos encuentros nos daban la oportunidad de escuchar nuestras voces y más o menos imaginarnos
los tonos de voz y entonación al leer los correos electrónicos, así la relación no era impersonal.

Además la comunicación por correo electrónico de los líderes del proyecto siempre fue sumamente cariñosa y
respetuosa, promoviendo de esta manera la confianza y amistad entre las partes. Y por qué no mencionar a la
herramienta de chat que me hizo quedar mal en la reunión de lanzamiento (se caía la llamada cada 10
segundos y en ese momento tuve que conseguir un teléfono de conferencia internacional a través de uno de
los participantes del equipo), pero esta herramienta fue mi salvación en los primeros capítulos.

Al principio del proyecto me mantenía siempre en línea y siempre alguien entraba para hacerme preguntas
sobre la validación que en el momento estaban llevando a cabo; o yo rápido consultaba con Jorge Valdés
sobre alguna decisión que debía tomar. Luego del capítulo tres ya teníamos acuerdos establecidos relativos a
los términos que usaríamos a través del PMBOK® y ya no tuve que usar tanto el chat. Después de la reunión
de lanzamiento, el PMI® me proveyó un número de conferencia a través de Webex que pude usar para
efectuar las reuniones de estatus bisemanales. Por un tiempo usábamos Webex y la otra herramienta, para
llamada y chat respectivamente. Luego aprendí como hacer chat en Webex y sólo usamos Webex. El chat
siempre fue necesario porque no todos los participantes podían llamar sin cargo a la reunión.
¿Cómo calificaría el trabajo realizado por ustedes durante este proyecto?

Fue un esfuerzo bien arduo así que verdaderamente confío en que el compromiso que tuvimos con la tarea se
vea reflejado en la calidad del producto y le guste mucho a su audiencia. Espero que ayude a todos los
candidatos a PMP® y a los PMP® actuales a ser mejores Directores de Proyectos.

¿Qué retos y riesgos han debido de enfrentaron en este proceso de revisión de la traducción al
español de la 4a Edición del PMBOK®?

Los principales según definimos en nuestro registro de riesgos fueron los siguientes:

1. Disponibilidad de participantes.
2. Dificultad de comunicación por ser un equipo virtual.
3. Falta de integración del equipo por ser un equipo virtual.
4. No lograr consenso en el manejo de términos.
5. Falta de motivación del equipo.
6. Generar la MEJOR versión en español del PMBOK® desde su lanzamiento.

Dada las acciones establecidas evitamos el tres y el seis; y mitigamos el uno y el dos. Si fuimos exitosos en
generar la MEJOR versión en español del PMBOK®, ya esto lo definirá la audiencia. No obstante fuimos muy
disciplinados en seguir los procesos que nos precisamos para hacer la validación, así que espero que el
producto sea excelente y más importante que todo, que sea de mucho valor para su audiencia.

¿Este proyecto de validación estuvo acorde con el cronograma original

o vivió alguna variación?

El proyecto tenía una fecha de implementación original de 30 de marzo de 2009 y terminamos todas las
validaciones el 25 de mayo de 2009. El proyecto mantuvo un paso agresivo y firme durante la traducción de
los primeros tres capítulos.

Luego, por razones que desconocemos, dejamos de recibir capítulos por parte del PMI® hasta principios de
marzo. Una vez que notamos que ya estábamos en ese mes y apenas habíamos recibido el capítulo cuatro
para validar, el equipo completo se puso a la orden para hacer lo que fuera necesario para terminar lo antes
posible.

Nuestro nuevo reto era terminar antes del 30 de mayo para así otorgárselo a nuestra audiencia desde el
primero de junio, a través de www.PMI.org , el PMBOK® completo traducido al español en formato digital;
porque pensamos en aquellas personas que quieren tomar el examen a partir del primero de julio, de tal
manera que lo pudieran hacer habiendo ya estudiado con la nueva versión del PMBOK®. Nuevamente estaba
sumamente orgullosa del compromiso del equipo; y resultó que las alternativas de solución que proveímos a
PMI® para atacar el cronograma eran más agresivas que lo que se nos era permitido, pero sí encontramos
una que era cómoda para todas las partes y cumplía con nuestro interés de proveerle un PMBOK® funcional a
la audiencia hispanohablante el primero de julio.

A su juicio, ¿cuáles han sido las modificaciones más importantes que ha tenido esta 4a Edición del
PMBOK® con relación a la tercera?

1. Añadir el sub-proceso de Gestión de Requerimientos: Ya era hora que aceptáramos que en la industria son
pocas las compañías que separan el rol de Analista de Negocio y el de Director del Proyecto. La mayoría de
las veces los Directores de los Proyectos también fungimos como analista y nos faltaba conocimiento teórico
en este aspecto.
2. Legibilidad: El PMBOK® es ahora mucho más fácil de leer y entender. El lenguaje es más sencillo y la
redacción más clara y concisa.
3. Añadir un anexo para explicar las Habilidades Interpersonales que los Directores de los Proyectos deben
tener.

¿Qué tema o asunto le faltó a esta 4a Edición del PMBOK® que usted hubiera incluido?
En el Anexo G: Habilidades Interpersonales, hubiese profundizado más en las áreas de “Influencia” y
“Conocimientos Políticos y Culturales” puesto que son temas que aprendemos a golpes o porque nos
encontramos con un buen samaritano que llamamos mentor que nos adelanta la malicia necesaria para poder
abordar estos temas. Además sería bueno en todos los temas del anexo atar la habilidad a las herramientas
provistas a través del PMBOK® que nos ayudan a aplicar mejor estas destrezas.

¿Qué recomendación tiene para aquellas personas que han estudiado la 3era edición del PMBOK® y
que por alguna razón ya no alcanzaron el examen basado en ésta y ahora tendrán que afrontarlo con
una nueva guía?

1. Leer el Anexo A y entender los cambios entre la 3era y 4a edición.

2. Leer la 4a Edición, aunque sea una vez, con un enfoque agresivo en asimilar los cambios mencionados en
el Anexo A.

¿Qué fue lo más difícil de este proyecto y qué le hubiese gustado mejorar durante todo este proceso?

Lo más difícil para mí fue conseguir que los 21 participantes estuviesen alineados en las decisiones de
terminología que lográbamos, luego conservar el equipo de validación y la compañía de traducción alineados
en estos acuerdos. Aunque en el equipo de validación generamos un documento llamado “Acuerdos de
Palabras del TVC” y lo compartíamos con la Directora del Programa y la compañía traductora, parecía que los
acuerdos eran un moving target (blanco móvil).

En una ocasión llevamos 12 términos a votación y acuerdo por mayoría, puesto que no logramos consenso en
la traducción de los mismos. Sin embargo, de la validación del capítulo seis en adelante pudimos mejorar el
alineamiento significativamente con la introducción del “Terminology List” (Lista de Términos) publicado por
PMI® y la “Guía de Estilo” de la compañía traductora utilizada para la versión del PMBOK® al español. En una
próxima ocasión estas herramientas deben ser compartidas con el equipo de validación desde el inicio del
esfuerzo debido a que a partir de este punto las comprobaciones corrieron mucho más suaves.

¿Qué mensaje desea transmitirle a la comunidad de LiderDeProyecto.com?

Les invito a estudiar la nueva versión del PMBOK® ya que hay cambios de impacto y avance en la disciplina.
Hemos trabajado con mucho esmero y compromiso para ayudarles a mantenerse al día con las mejores
prácticas a nivel mundial de la dirección de proyecto. Espero disfruten el resultado y que les sea muy útil.

Gestión de la Integración

Planeación del Proyecto

El administrador del proyecto, una vez que comienza el proyecto y recopila la información básica de
requerimientos en la fase inicial, realiza un plan de trabajo especificando los diferentes aspectos en cuanto a
la forma de trabajo, llenando las diferentes secciones del documento correspondiente.

Utilizando el ciclo de vida elegido desarrolla el desglose de actividades en un plan (por ejemplo en un Gantt) al
máximo detalle posible, procurando que las actividades duren en promedio 2 a 3 días, dependiendo del
tamaño del proyecto. En proyectos pequeños las actividades deberían de ser de unas cuantas horas.

En dicho desglose estima el esfuerzo apoyándose con los recursos que llevarán a cabo dichas actividades. A
las actividades les asigna responsabilidades y dependencias de acuerdo a la cantidad de recursos y al ciclo
de vida. Para facilitar el desarrollo de este Gantt se recomienda utilizar un formato ya establecido con las
fases y actividades típicas para el proyecto.

Una vez desarrollado el plan debería registrar la versión de dicho plan en el control de versiones
correspondiente. Pues, es importante llevar un control de la evolución del plan. Recordemos que el plan es
algo vivo que está en constante cambio y evolución.
Procesos Claves en la Administración de Proyectos

Por Norberto Figuerola, PMP® [ Acerca del autor ]

El Dr. Roger Kaufman señaló en uno de sus artículos (“Benchmarking”) que es casi universalmente popular
tomar como referencia a otras organizaciones y buscar en ellas las mejores prácticas que utilizan para que la
propia organización pueda copiarlas y ser más eficaz, previo a un análisis de las mismas. Un error común es
creer que los procesos en sí mismos deben ser la base para determinar la mejor práctica, sin relacionar a
éstos a la creación interna de valor. Si uno busca una organización o metodología como referencia, debería
asegurarse de que las metas y objetivos de la institución referente sean similares a la suya y que los procesos
que se tomarán como modelo sean adecuados y funcionarán dentro de su organización.

Si los procesos que actualmente utiliza para la gestión de proyectos o los que se propone implementar
resultan en más trabajo que el proyecto mismo, evidentemente usted necesitará repensar o simplificar dichos
procesos.

Eso ocurre frecuentemente con procesos propietarios o metodologías desarrolladas que no tienen en cuenta
aspectos más ágiles del negocio. Recuerdo un proyecto en donde me tocó trabajar con otros consultores de la
ex Arthur Andersen quienes utilizaban “Method/1”. Si bien ellos me dieron acceso a dicha metodología
francamente nunca la leí, pero puedo asegurar que ocupaba toda una biblioteca, y uno debería tener mucho
tiempo para poder leer todos esos libros en menos tiempo del que se necesitaba para llevarlos a la práctica.
No discuto el proceso sino su usabilidad. Cualquier proceso o metodología que ayude en el trabajo es bueno,
con tal que, genere valor al cliente y no sea excesivamente pesado.

Para asegurar el éxito en la gestión de proyectos se necesita recurrir a las mejores prácticas del mercado y no
re-inventar la rueda. Los procesos o métodos de mejores prácticas deberían ser una biblioteca de toda la
experiencia pasada de una organización en la ejecución de sus proyectos. Estos deberían ser modulares de
manera de poder adaptarlos a los distintos tamaños o complejidades de los proyectos. La biblioteca de las
mejores prácticas se construye realizando los análisis post-mortem o lecciones aprendidas y documentando
esa información para la mejora continua de los mismos.

Para las organizaciones que no tienen información histórica de proyectos anteriores o desean desarrollar la
propia basándose en las mejores prácticas del mercado de metodologías existentes para la administración de
proyectos, el material de referencia estándar es el PMBOK® del Project Management Institute con información
muy detallada acerca de los procesos para la gestión de proyectos. Otras normas o metodologías tales como
ISO, CMMI, Prince 2, APM, etc., son otras fuentes de información aunque en algunos casos son propias de
determinadas industrias (IT) y otras no tan difundidas o completas. El PMBOK® distribuye las mejores
prácticas en 42 procesos y nueve áreas de conocimiento o disciplinas. En la práctica muchos proyectos no
utilizan ni la mitad de esos 42 procesos, sin embargo a los efectos educacionales el PMBOK® provee la más
clara y profunda explicación de las distintas áreas que envuelven a la gestión de cualquier proyecto. La
flexibilidad es muy importante aquí.

Primero se trata de otro BOK (Body of Knowledge) por lo que no se espera encontrar todas las respuestas allí
sino que cada profesional deba consultar infinidad de otras fuentes relacionadas con cada proceso y
disciplinas descriptas. Segundo, utilizar el sentido común, la experiencia y la intuición para decidir qué
procesos son los que conviene aplicar en cada proyecto que vamos a encarar.

Tomando como base el PMBOK®, a mi criterio el documento que sigue siendo más importante como
referencia para la gestión de proyectos, en este artículo vamos a detallar algunos conceptos muy importantes,
advertencias y temas claves que se deben contemplar en la administración de todos los proyectos y que
normalmente suelen pasarse por alto o no darles la importancia necesaria en la gestión de los mismos.

1 - Seguir un proceso de iniciación estructurado: realizar un estudio de factibilidad financiero, tecnológico,

de recursos, impactos, estratégico y de negocio del proyecto, para prevenir inconvenientes, priorizarlo y
obtener el soporte y justificación de negocio necesario para poder implementarlo. Durante la fase de inicio o
arranque, una correcta valoración de riesgos, asunciones, obstáculos y restricciones deben ser
convenientemente evaluados y el factor crítico es realizar un adecuado proceso de valoración de
requerimientos (RM) para clarificar objetivos, necesidades y alinear las expectativas. En muchos casos los
procesos de RM pueden automatizarse pero siempre es conveniente mantener sesiones y reuniones con los
stakeholders para aclarar los puntos grises. Todas las metodologías de administración de proyectos recalcan
la importancia de una fuerte relación con los stakeholders y su proceso de análisis, dado que con ellos
podremos lograr más fácilmente el éxito y romper diversas barreras en los proyectos. Un error frecuente es
que muchos proyectos pueden tener un gran número de stakeholders y el team sólo dialoga con aquel más
sociable y entusiasta sin evaluar las expectativas de los otros que directa o indirectamente están involucrados
y son precisamente los que pueden ponernos los palos en la rueda. Un factor común para el éxito de los
proyecto es poseer la habilidad de negociar y manejar las expectativas y necesidades de los stakeholders
afectados por el proyecto. La relación con el sponsor y los stakeholders es vital y la clave es establecer una
buena “relación” lo que implica más que identificar y manejar sus expectativas, manejar una conexión
emocional con la gente. El PM debe focalizarse en mejorar sus habilidades interpersonales, y asegurarse de
que todos los stakeholders están a bordo del proyecto manteniendo fluida comunicación con ellos. El análisis
de los stakeholders debería permitir al PM no sólo identificarlos sino categorizarlos bajo distintos aspectos:
relación y actitud hacia el proyecto, están a favor o en contra del proyecto, cuál es su poder e influencia,
existen conflictos entre ellos, etc.

2 - Planificación del Proyecto: de acuerdo a la industria donde se realice el proyecto, la planificación podrá
tomar diferentes matices. Los proyectos para el desarrollo de software son bastante particulares, tan es así,
que surgieron metodologías propias para los mismos (“Agil Development”) diferentes a las tradicionales como
el PMBOK®. Algunos aspectos de las metodologías ágiles pueden ser utilizados en cualquier otro proyecto.
Actualmente está de moda hablar también de Lean Six Sigma Project Management, otra aproximación a la
gestión efectiva de proyectos. Independientemente de que se utilice una metodología tradicional, ágil o lean;
una buena planificación siempre es necesaria. En la metodología tradicional la planificación es exhaustiva y
completa, en los ciclos más acelerados y livianos (ágil o lean) la planificación se concentra en delimitar los
bordes del proyecto para crear una lista priorizada de entregables que serán liberados en fases de tipo
iterativa. Planes comprensivos, realistas y bien comunicados son imprescindibles en todos los proyectos, aún
con cortos ciclos de vida. Involucrar no sólo al team sino a los stakeholders en el desarrollo de los planes,
discutir acerca de todos los objetivos y entregables del proyecto y explicar claramente los riesgos involucrados
son también factores esenciales. Como corolario final el consejo es no embarcarse en planificaciones
extensas, construir planes a corto plazo y detallados (elaboración progresiva según el mismo PMBOK®), e ir
elaborando los requerimientos sobre la marcha en una aproximación de tipo iterativo.

3 - Utilizar auditorías: para evaluar la salud del proyecto, deberían realizarse auditorías y reuniones de
“quality assurance” en forma frecuente para chequear no sólo los entregables sino el estado y progreso del
proyecto. Medir el progreso real versus el costo y tiempo estimado es muy importante, al igual que realizar
mediciones de calidad respecto del cumplimiento de los requerimientos y el alcance de los entregables. No
podemos controlar y mucho menos mejorar si no tenemos métricas. Debemos desarrollar criterios estándar de
medición tanto de calidad como de productividad y eficiencia, para saber no sólo dónde estamos sino qué y
cómo debemos mejorar. El PM debe desarrollar todas las actividades y procesos definidos dentro del grupo
de Monitoreo y Control del Proyecto que involucra el control del progreso del mismo (tiempo y tareas), el
control del alcance (cambios), control del rendimiento (performance), control de los costos (método del valor
ganado) y el control de calidad. De dichos controles surgirán reportes y medidas correctivas o preventivas.

Las auditorías también pueden ser efectuadas por personal externo al proyecto, y se denominan “peer
reviews”, realizadas por colegas o el departamento PMO o de Aseguramiento de Calidad. El alcance de la
misma debería ser similar al comentado más arriba. Toda auditoría consta de las siguientes etapas:
  Planificación: Elección del tipo de auditorías a realizar (costos, performance, calidad, etc.),
determinar los procedimientos a utilizar, elección del personal, fijación de su periodicidad (mensual,
anual, esporádica, etc.).
 Realización de auditorías según procedimiento y plan definidos: Es conveniente desde el punto
de vista práctico que la realización de auditorías sea sistemática, y el propio director o responsable
del área a auditar transmita a sus subordinados afectados las fechas concretas en las que estas
auditorías sistemáticas van a realizarse para que presten su mayor colaboración. Los documentos
que recaben los resultados de las auditorías, es decir, respuestas, comprobaciones, resultados de
medidas y ensayos, etc., han de estar consensuados entre auditor y auditado, de tal forma que
recojan la conformidad de ambos, evitándose discusiones inútiles. Se trata de auditar la efectividad
de la gestión del proyecto, tanto a través del grado de cumplimiento de los procesos, como a través
de la calidad del producto obtenido.

 Evaluación de los resultados de la auditoría: Toda auditoría ha de realizarse para obtener una
nota final que sirva, aunque sólo sea comparativamente, para medir la evolución y progreso del
proyecto. Lo que se pretende es la obtención de una valoración totalmente objetiva por lo que el
sistema de valoración ha de ser consensuado, y además, experimentado durante cierto tiempo, para
poder fijar las señales de alerta, índices de ponderación, etc.
 Redacción de un informe y propuesta de medidas correctivas de ser necesario, con expresión
de su grado de urgencia: Una vez valorada la auditoría y antes de la redacción del informe final y
propuesta de las medidas correctoras, es conveniente la reunión con el PM afectado por la auditoría
para que sea el primer informado y pueda incluso colaborar en la propuesta de medidas correctoras
así como la decisión sobre la urgencia de las mismas, pues es conveniente que tanto el informe de la
auditoría como la propuesta de medidas correctoras, lo asuma como algo propio, entre otras cosas
porque a veces, podrá ejercer más presión sobre la Gerencia que el propio auditor, sobre todo si
alguna de las medidas propuestas corresponden o requieren inversiones.

4 - Utilización de recursos humanos: la correcta utilización de las “técnicas blandas” y el uso adecuado de
las habilidades interpersonales son factores críticos en el manejo de todos los proyectos. Un tema
controversial que suele traernos dolores de cabeza se refiere a las horas que cargan los recursos al proyecto:
¿deben ser las reales o teóricas?. En las organizaciones en las que trabajé, como ocurre con muchas
consultoras o empresas de servicios, al cliente se le cobra de acuerdo al proyecto un “precio fijo” o “time &
material” (por hora de consultoría). En ambos casos se toma para la formación del precio el “cost rate” de los
recursos que trabajarán en el proyecto, independientemente de que el recurso pertenezca o no a la
organización ejecutante. Si pertenece a la organización y trabaja más de 40 horas a la semana, su salario
será siempre el mismo, pero a los efectos de cobro al cliente en el caso de time & material podríamos cobrar
las horas “overtime”, algo que, en la práctica sólo se le paga al recurso si es externo a la organización. En los
casos de precio fijo, durante la planificación normalmente calculamos en la herramienta de scheduling 40
horas de trabajo semanal. Si observamos que existen recursos con sobre alocación (más de 8 horas por
semana) la técnica más común a utilizar sería el resource-leveling algo que generalmente terminará por
enviarnos el final del proyecto al lado oscuro de la luna. En la práctica normalmente no se hace nada dado
que el recurso si es parte de la plantilla de la organización, trabajará esas horas extras que por lo general y
debido a su rango no son pagadas en la práctica dado que recibe su sueldo mensual fijo. El problema se
presenta cuando existen sistemas de control de costos y productividad que no toma en cuenta esta realidad
(dado que se maneja con planillas separadas). En estos casos es frecuente que se le obligue al recurso a
cargar las horas que realmente trabaja en el proyecto en algún sistema para su registro. De ser así,
estaremos en un aprieto desde el punto de vista de costos, dado que las horas cargadas y costeadas
superarán lo que estaríamos facturando. La única solución en este caso será que no cargue sus horas extras,
bajando su nivel de “billability”, algo que no sólo puede perjudicar al recurso sino también al mismo gerente
(problemas de utilización y productividad). Otro tema importante es la no disponibilidad de los recursos claves
(algo frecuente en los proyectos de alta tecnología). La demanda puede ser superior a la oferta y los planes
suelen subestimar el tiempo requerido para adquirir estos recursos, lo mismo que el tiempo necesario para
organizar el grupo (“team building”).

5 - Estimación en los Proyectos: las estimaciones de costos y tiempos en un proyecto constituyen la parte
más difícil en la planificación, y es más un arte que una ciencia. Como consultor tuve que realizar una revisión
a un proyecto que estaba con un sobrecosto muy elevado y querían un análisis de la causa de la variación del
mismo. Mi primera pregunta fue “cuál era el método que utilizaban para las estimaciones”, la respuesta clásica
fue el proyecto tiene que estar listo para Octubre y se vendió en este precio considerando una determinada
carga de recursos. Mi segunda pregunta fue “¿si la base de estimación es una ficción, como quiere que la
varianza en el costo tenga algún significado?”. Lamentablemente muchas organizaciones venden sus
proyectos de acuerdo a lo establecido por Ventas y no tienen tiempo de realizar una estimación bottom-up o
utilizar buenas técnicas de métodos cuantitativos de administración de proyectos para al menos estimar las
variaciones e incertidumbres con los buffers de contingencias necesarios. Cuanto más largos en recursos,
tiempo, costos o complejidad son los proyectos mucho más complicada resultará la realización de las
estimaciones. El Standish Group a través de sus estudios empíricos nos arroja estos resultados de
éxito/fracaso de proyectos en su relación con su tamaño y duración.

Tamaño del proyecto Personas Tiempo (meses) Porcentaje de éxito

Debajo de $750K 6 6 55%

$750K-$1.5M 12 9 33%

$1.5M-$3M 25 12 25%

$3M-$6M 40 18 15%

$6M-$10M +250 +24 8%

>$10M +500 +36 0%

Esto nos demuestra una vez más que los mega-proyectos pasaron de moda y que el desarrollo iterativo es el
mejor método para mitigar riesgos y una estrategia buena para estimar mejor el alcance, costo y tiempo de los
entregables a distribuír en el proyecto.

6 - Practicar un estricto control de cambios: independientemente del tamaño del proyecto y para evitar el
“Scope Creep” se deberá ser muy riguroso en lo que respecta al control y seguimiento de los cambios al
proyecto, utilizar herramientas automáticas de RM (Requirement Management) y CM (Configuration
Management). Tener muy claro el procedimiento para solicitar los cambios, el tipo de formulario, cómo debe
ser completado y el método para aprobación respectivo. Si el Gerente de Proyecto no ha definido bien el
alcance inicial del proyecto, será tremendamente difícil administrar el mismo. El propósito de la administración
de cambios es proteger la viabilidad de la definición del proyecto ya definida y aprobada. Cuando se solicita
formalmente un cambio implica que dicho cambio está fuera del alcance acordado en la definición del
Proyecto o de los requerimientos o solicitudes detallados durante el análisis. Si dicho alcance es confuso,
poco claro, o deja lugar a interpretaciones, entonces el cliente dirá que el cambio está dentro del alcance, y el
Gerente de Proyecto encontrará difícil apegarse a un proceso formal de Gestión de Alcance. En algunos
proyectos es posible anticipar todas las solicitudes y requerimientos durante el proceso de análisis. No
obstante lo cual, siempre podrá existir la posibilidad y la necesidad de incorporar cambios durante el ciclo de
vida. Estos cambios pueden ser muy necesarios para la solución, y pueden existir razones poderosas de
negocio por las que deberían incorporarse. El Gerente de Proyecto y el equipo de trabajo, deben reconocer el
momento en que los cambios son requeridos y deberán seguir un proceso predefinido de gestión del alcance.
Este proceso, eventualmente, proporcionará información para que el sponsor tome las decisiones pertinentes
y también le permitirá decidir si la modificación deberá aprobarse en base al valor e impacto en el proyecto en
términos de costo y tiempo. Debe ser claro para todas las partes que cumplir estos nuevos requerimientos con
los mismos recursos de la definición anterior, es prácticamente imposible.

7 - Buffers: incertidumbre, probabilidades: son temas que hacen a la gestión cuantitativa de los proyectos.
Primero y fundamental es necesario no mezclar (al menos sin identificar claramente) las contingencias que
nos tomamos en las estimaciones con la duración puesta a cada tarea. Esta contingencia debe ser claramente
identificada y manejada para evitar el efecto de la famosa “Ley de Parkinson”. El método de la Cadena Crítica
coloca todas estas contingencias en un buffer compartido para todo el proyecto de uso exclusivo del PM. De
no utilizar este método el PMBOK® nos aconseja utilizar contingencias o buffers por las incertidumbres en las
estimaciones utilizando CPM/PERT, MonteCarlo, Varianza de la media, o simplemente un porcentaje del total
de costo o tiempo adicional. El cálculo del tamaño del buffer debe tener en cuenta muchos factores. Hablar de
incertidumbre en riesgos o en las estimaciones no es exactamente lo mismo que hablar de cuál sería la
probabilidad de ocurrencia. En forma simple, al arrojar una moneda existe una incertidumbre respecto de si
saldrá cara o ceca. Pero no hay incertidumbre respecto de las probabilidades de que salga cara dado que
ambas tienen un 50%. Si la probabilidad de un evento se acerca más al 100% estaremos mucho más
tranquilos porque reducimos su incertidumbre, pero inevitablemente aumentaremos su rango. Por ejemplo, si
tenemos una pieza mecánica que a través de mediciones hechas durante 5 años sabemos que puede causar
daños humanos en un impacto con rango del 35% al 45% (10%) y esto no es aceptable, lo que ocurrirá es que
se realizarán tareas de ingeniería para mejorar dicha pieza y reducir ese impacto negativo. Supongamos que
logramos armarla de otra forma y que ahora las probabilidades de que ocurra algo malo son del rango entre
5% y 25% (20%). Hemos reducido significativamente la probabilidad de un accidente pero como no hay
historia pasada el rango de la incertidumbre es más alto (del 10 al 20%).

8 - Subcontratar desarrollos externos (“Outsourcing”): muchas veces he trabajado como “prime

contractor” en proyectos en donde teníamos muchos proveedores involucrados (en algunos casos, su
desarrollo era más importante que el nuestro). En este aspecto son válidas todas las recomendaciones del
PMBOK® sobre adquisiciones, además de tener en cuenta todas las modalidades contractuales y de
mantener el “pari passu” (mismas condiciones de obligaciones y responsabilidades contractuales) de las
cláusulas del cliente con nuestros proveedores. En este caso me referiré a un tema muy corriente en el
ambiente de IT que es la exigencia de ciertos niveles de calidad (CMMI) que se suele requerir cuando se
contrata o se hace un outsourcing. La mayoría de las empresas hoy en día pregonan ser certificadas en
CMMI. Esto es imposible dado que CMMI no es una certificación, el SEI no certifica organizaciones como el
ISO o el ITSMF, sino que autoriza a personas denominadas “lead appraisers” a conducir auditorías para
determinar el grado de madurez de la organización respecto del modelo. El SEI no confirma la certeza del
nivel de madurez reportado, sino que su foco es más bien la calidad continua de la organización, que
identifique en qué nivel se encuentra y que realice todos los esfuerzos necesarios para mejorar su calidad y
hacer sus procesos repetibles.

Datos de desempeño

Estados Europa y
India Japón Total
Unidos otros

Número de proyectos 24 27 31 22 104

Programador LOC/MO 209 469 270 436 374

Mediana de índice por

.263 .020 .400 .225 .150
defecto/KLOC

El gráfico mostrado más arriba es un informe del IEEE Software que documenta un estudio sobre 104
proyectos de software en el mundo. India es el país que proclama tener la mayoría de sus empresas con Nivel
5 de CMMI y sin embargo está en el tercer lugar en cuanto a programas con errores (el informe incluye
empresas como Motorola India, Infosys, Tata Consulting), ¿algo como para tener en cuenta no?. No estoy
desmereciendo la evaluación del modelo de madurez sino que debería preguntarse mucho acerca de cómo se
obtuvo y otras cuestiones de la empresa a contratar tales como:

 ¿Cuándo fue publicado su último assessment? (dura 2 años)

 Copia de la documentación donde figura ¿qué áreas son las más fuertes y cuáles con las más
débiles?.
 ¿Quién desarrolló el lead assessment?
 ¿Cuáles son sus planes de mejora continua?
 ¿Con qué otros clientes trabaja?

Otra característica asociada a la inmadurez de nuestro mercado es el error de escuchar a un gerente decir:
“esta tarea ya no representa un problema porque la hemos subcontratado”. Esto es falso, fundamentalmente
porque la inestabilidad de nuestro mercado hace que sea muy difícil desarrollar relaciones cliente –
proveedores que perduren en el tiempo. Por otro lado, esta inestabilidad y lo pequeño del mercado generan el
problema que los proveedores en gran medida sean Pymes, y éstas permanentemente deben de tener una
muy agresiva actitud de venta, sobre todo si son proveedores que dependen de la aparición de proyectos en
el mercado para tener trabajo y resulta muy difícil su evaluación porque no hay una manera simple de saber el
estado en que se encuentra dicho proveedor. Es posible analizar los contratos que tiene en ejecución, pero no
es posible analizar los contratos que “están a la firma”, y muchas veces la concreción de uno, genera mejores
condiciones en las Pymes para enfrentar las negociaciones con los otros contratos, y se produce una cascada
de contratos que se firman, una cantidad de compromisos simultáneos que este proveedor tiene que cumplir,
y como generalmente no cuenta con reservas de recursos humanos ni con una planificación previa tiene como
resultados crisis de recursos y falta de cumplimiento en todos los contratos. En el caso a su vez que el
contratista sub-contrate el servicio en otra organización se le suma a la inestabilidad propia del contratista,
que tiene sus crisis internas, las que potencian a la de los subcontratistas. Cuando bajamos de nivel, nos
encontramos con empresas más pequeñas, más inestables, más riesgosas y más difíciles de predecir, con
grandes inconvenientes para tomar buenas decisiones.

9 – Project Manager, Líder o Facilitador: Un Gerente de Proyecto debe desarrollar diferentes roles por lo
que es importante la óptima aplicación de sus habilidades personales. Normalmente un PM debe cumplir con
su rol de Gerente pero además debe también ser el Líder del grupo de trabajo, aspectos que tienen distintos
objetivos. El lector debería conocer la importancia del proceso de “Team Building” y cómo los grupos van
madurando a lo largo del desarrollo del proyecto. Actualmente también podemos clasificar a los equipos de
trabajo conforme a su capacidad técnica y resolutiva, llegando a tener equipos de trabajo denominados de
Alto Desempeño en donde los conflictos los resuelven entre ellos, toman decisiones propias y pueden
autogestionarse. En estos casos el rol del PM más importante es el de Facilitador donde lo que prima es dejar
trabajar con libertad y preocuparse más en eliminar los problemas u obstáculos del equipo. Las características
de los facilitadores son: Lideran pero no dominan; utilizan mucha escucha activa; motivan a la participación y
trabajo cooperativo; lideran con el ejemplo; mantienen al sponsor activamente involucrado pero se aseguran
que no interfiera en el trabajo; documentan al nivel necesario. Estamos hablando de gente de alta confianza y
estima que demuestran carisma, empatía, respeto y sensibilidad por el grupo de trabajo. Podemos decir
entonces que otro factor clave en la gestión de los proyectos es colocarse el sombrero adecuado teniendo en
cuenta el tipo de proyecto, el team de trabajo o las circunstancias especiales que estemos controlando.

LÍDER MANAGER FACILITADOR

Focalizado en hacer que se Focalizado en lograr el Focalizado en ayudar a la

haga bien el trabajo trabajo correcto gente en el logro del trabajo

Se concentra en el qué y el Se concentra en el cómo Ayuda a la gente a

por qué concentrarse

Establece la Dirección y Establece el Plan Ayuda a la gente a entender

Metas la Dirección y Metas

Se asegura que los otros Ordena a los otros a Se asegura que los otros se
respondan y lo sigan completar sus tareas comprometan en las tareas

Inspira, motiva, incita Ejecuta, controla, gestiona, Ayuda a la gente a resolver

creación e innovación resuelve problemas sus problemas eliminando
barreras

10 – Project Management Estratégico: el tema se basa en asegurarse de que todos los proyectos están
estratégicamente alineados y fueron previamente analizados por la PMO o un proceso de PPM. Se debe
definir un criterio contra el cual todos los proyectos pueden ser priorizados que incluya el impacto en las
estrategias corporativas y los clientes, y confeccionar una lista de todos los proyectos, sus metas y objetivos
estratégicos. Después, tratar de identificar el criterio de éxito de los mismos y determinar el impacto esperado
que cada proyecto tendrá en la organización y sus clientes. Asignar un rango para cada proyecto
cuantitativamente y determinar su nivel de prioridad. Alinear los proyectos con los planes estratégicos
corporativos y departamentales, y ejemplificar cómo la ejecución exitosa de cada proyecto apoyará la
estrategia corporativa o departamental. En ciertos casos no queda otra salida que cancelar los proyectos que
son de baja prioridad o que no están ligados al plan estratégico de la corporación o del departamento. ¿Qué
se puede hacer para implementar las mejores prácticas de Project Management Estratégico?: la retención del
conocimiento es uno de los mayores beneficios para las organizaciones ya que contribuye al aprendizaje
continuo y ayuda a evitar la repetición de errores. Con objeto de retener el conocimiento sobre la
implementación efectiva de proyectos y que puedan ser pasados como lecciones aprendidas hacia equipos de
proyectos a futuro, la PMO debería tener una reunión de cierre de proyecto tan pronto como haya terminado,
mientras el conocimiento sobre la administración del mismo aún está fresco en las mentes de todos. El
propósito de esta reunión es revisar qué sucedió durante el transcurso del proyecto y qué puede aprender el
equipo y la organización de lo sucedido. El sponsor del proyecto, el responsable del proyecto y el equipo de
trabajo deberán estar presentes así como cualquier recurso exterior o “stakeholders” quienes quisieran
contribuir con ideas. El resultado final de esta reunión de cierre del proyecto será la creación de un documento
formal de “lecciones aprendidas” para ser llevadas a proyectos futuros, a los gerentes y a sus equipos de
trabajo. El establecimiento de mediciones de proyectos exitosos desde el punto de vista estratégico también
ayudará a proveer a la alta dirección de información relevante y necesaria para tomar decisiones que afecten
el proyecto. Por ejemplo, la presentación estratégica de las medidas del éxito del proyecto puede convencer a
la alta dirección de re-priorizar proyectos o de re-asignar recursos. Las medidas del éxito del proyecto
proveerán a la PMO de la información necesaria para que venda el impacto de la efectividad al nivel gerencial.
Los criterios para el éxito en la medición de los proyectos estratégicos deben incluir:

 La utilización de un criterio de calidad especificado.

 La habilidad para enfrentar cambios en los requerimientos.
 El número de recursos usados actualmente contra el número de recursos anticipados originalmente.
 La habilidad del proyecto para alcanzar sus objetivos y entregables específicos.
 Las encuestas de satisfacción de clientes que indican su conformismo con el producto o la entrega
del servicio del proyecto.
 La puesta en producción o lanzamiento exitoso y sin problemas.
 Mediciones financieras adecuadas y dentro de los límites.

Finalmente, para las organizaciones que están considerando en definir cuál es la mejor metodología para
administrar sus proyectos, o cómo adaptar la metodología del PMBOK® a sus propias necesidades, la
recomendación es considerar un buen programa de entrenamiento de sus PM y considerar su posible
certificación, que ofrezca una revisión de la metodología y las áreas claves para su organización: costos,
tiempos, riesgos, calidad, junto con una visión más amplia, crítica y realista. Otra alternativa es contratar a una
organización con consultores especializados y certificados PMP® para que colaboren en la implementación de
los proyectos y realicen la transferencia de conocimientos y prácticas necesarias.

Gestión del Alcance

Apostando al caballo ganador
Por Jorge Aguirre [ acerca del autor ]

Planear el proyecto es una actividad muchas veces menospreciada, o por lo menos mal entendida. Un líder de
proyecto tiene la responsabilidad, aún en etapas muy tempranas, de usar la información recabada por su
equipo o personalmente, para poder decir con la mayor certeza posible lo que se tiene que hacer, para
proveer una solución de valor para los involucrados. Deben especificarse también los recursos humanos y
materiales necesarios, así como las restricciones y dependencias propias del proyecto.

Una representación de este plan inicial podría ser tan simple como una lista de lo que se debe de hacer.
Partiendo de esta lista habrá que hacer nuestras estimaciones, es decir, algo así como predecir qué caballo
ganará la carrera. Como podemos darnos cuenta, aún con la información completa, predecir qué caballo
ganará no es algo cien por ciento seguro.

El plan no es un Gantt
Este punto para algunos resultará demasiado obvia, sin embargo estoy seguro que más de uno se preguntará
sorprendido: ¿Entonces qué es el plan de proyecto?

Simplificando las cosas, podríamos decir que el plan de un proyecto debiese especificar:

1. Lo que el cliente nos solicitó.

2. Lo que el equipo a cargo del proyecto entiende a partir de dicha solicitud.
3. Lo que pensamos hacer al respecto para atender la solicitud en el marco de las diferentes
restricciones y expectativas de los involucrados.
4. Deberemos establecer explícitamente los recursos que se usaran en cada momento del proyecto e
5. Indicar los puntos de control o hitos que existirán a lo largo del proyecto.

Fácil, ¿No es cierto?

Pero, antes de establecer esos puntos, y para poder contar con un buen plan es necesario conocer la
siguiente información:

1. El problema u oportunidad que se atiende.

Rara vez el cliente tendrá como problema: “no tener una presencia en internet” o “construir un edificio”,
simplemente por el gusto de tener dicha presencia o de construir dicho edificio. En ambos casos existe una
razón de negocio o una meta de la organización que debe atenderse. Esa meta se debe conocer y hacer
explícita para poder constatar que lo que se entregará realmente cubre dicho objetivo. Si nos quedamos con
la idea de que el cliente simplemente “quiere un edificio de departamentos” estamos cayendo en un error
común: “expresar soluciones en lugar de requerimientos”.

2. El alcance y el esfuerzo
A partir de la meta, el equipo responsable deberá considerar dependencias, restricciones y recursos
disponibles, para establecer claramente lo que se puede entregar y lo que no se puede entregar. Si
planeamos bajo un esquema iterativo, entonces es posible que se hable del conjunto de características que
pretendemos completar en cada ciclo o iteración.

Para poder llegar este punto se deben conocer las tareas a realizar, descomponiendo las de más alto nivel
para identificar de la manera más precisa el esfuerzo requerido. Cuando no realizamos una adecuada
descomposición de tareas se corre el riesgo de caer en otro error común: “que la suma de las partes sea
mayor al total”.

3. El cronograma
Una vez que tenemos suficientemente claro el alcance y el esfuerzo, debemos distribuir ese esfuerzo entre
nuestros recursos para obtener un cronograma o calendario de actividades. Y si, lo admito, se puede
representar como un Gantt, aunque no es la única representación, a pesar de ser tan popular.

Este es un vistazo rápido y simple a la planeación, cada rubro mencionado aquí se puede abordar a mayor
profundidad e incluso hay consideraciones adicionales, que espero poder revisar con ustedes más adelante.
Por lo pronto espero que esta breve explicación les sirva para comenzar su labor de planeación.

Los requerimientos de un proyecto

Por Joaquín Ibáñez, PMP® [ Acerca del autor]

El propósito de la gestión de requerimientos es asegurar que el proyecto cumple con las expectativas de sus
clientes y de sus interesados, tanto externos como internos, siendo el proceso que garantiza el vínculo entre
lo que esperan los clientes y usuarios, y lo que los equipos de proyecto tienen que desarrollar.

Si bien muchos de sus principios pueden ser adaptados a todo tipo de proyectos, es en los proyectos de
desarrollo de software donde adquieren todo su sentido, garantizando el proceso y sirviendo de referencia
para asegurar y controlar los cambios que en el proyecto puedan surgir (trazabilidad). A menudo, incluye la
elaboración de planes específicos para diferentes aspectos como la recolección, gestión e integración de los
requerimientos.
Definición de requerimiento y Stakeholders (Interesados)

Según la definición del PMBOK®, un requerimiento es la condición o capacidad que debe tener un sistema,
producto, servicio o componente para satisfacer un contrato, estándar, especificación, u otros documentos
formalmente establecido.

Son todas aquellas características observables que cualquier interesado desea que estén contenidas en el
sistema. Como requisitos se incluyen las necesidades, deseos y expectativas del patrocinador, cliente,
usuarios, y otros interesados.

Como requerimiento se podría establecer:

 Una capacidad necesaria para un cliente o usuario que soluciona un problema o consigue un
objetivo.
 Una capacidad que debe incluirse en un sistema para satisfacer los objetivos del proyecto.
 Una restricción impuesta por algún interesado

Definiendo el concepto de stakeholder (interesado) como alguien que está afectado por el proyecto que se
desarrolla, podremos encontrar que hay de dos tipos:

 Usuarios: Aquellos que utilizaran el sistema.

 Clientes: aquellos que requieren el sistema y son los responsables de su validación o aprobación.

Es importante distinguir entre estos dos grupos de interesados, dado que muchas veces podremos
encontrarnos que hay un conflicto entre los requerimientos de ambos. En la mayoría de los casos, los
requerimientos de los clientes tienen prioridad sobre los requerimientos de los usuarios.

Características de los requerimientos

Un requerimiento debe cumplir ciertos criterios y características:

 Único: El requerimiento debe poder ser interpretado inequívocamente de una sola manera.
 Verificable: Su implementación debe poder ser comprobada. El test debe dar como resultado
CORRECTO o INCORRECTO.
 Claro: Los requerimientos no deben contener terminología innecesaria. Deben ser establecidos de
forma clara y simple.
 Viable (realístico y posible): El requerimiento debe ser factible según las restricciones actuales de
tiempo, dinero y recursos disponibles.
 Necesario: Un requerimiento no es necesario si ninguno de los interesados necesita el requerimiento
o bien si la retirada de dicho requerimiento no tiene ningún efecto

Además de los criterios para los requerimientos individuales, para el conjunto de ellos debe cumplirse:

 Independiente: Para comprender el requerimiento no debe ser necesario el conocimiento de otro.

 Consistente: No debe existir ningún conflicto entre requerimientos. Los conflictos pueden ser:

- Directos: Cuando ante una misma situación, cabe esperar comportamientos diferentes.
- Indirectos: Se produce cuando no es posible cumplir con dos requisitos al mismo tiempo, aunque
describan funcionalidades distintas.

 No redundante: Cada requerimiento debe ser formulado una sola vez, y no sobreponerse con otros
requerimientos.
 Completo: Un requerimiento debe ser especificado teniendo en cuenta todas las condiciones que
puedan ocurrir.
Organización y estructura de la gestión de requerimientos

Según el origen y características, los requisitos pueden dividirse en diferentes tipos., que pueden
representarse en forma de pirámide, en cuyo nivel superior se sitúan las necesidades de los interesados. En
los niveles más bajos son características, casos de uso y requisitos complementarios tal como se muestra en
la figura:

 Necesidad: Un interesado demanda un requerimiento.

 Característica: Un servicio proporcionado por el sistema, por lo general formulado por un analista de
negocios.
 Caso de uso: Una descripción del comportamiento del sistema descrito como una secuencias de
acciones.
 Requisito complementario: Otro requisito (generalmente no funcional) que no puede ser
contemplado en los casos de uso.
 Caso de prueba: Una especificación de las entradas necesarias para una prueba, las condiciones
de ejecución y resultados esperados. Tiene el papel de comprobar si los casos de uso derivados de
los casos de prueba y los requisitos complementarios se aplican correctamente.
 Escenario: Una secuencia específica de acciones o una ruta de acceso específica a través de un
caso de uso. Ayudan a derivar en casos de uso a partir de los casos de prueba y facilitan el diseño e
implementación a través de los casos de uso.

Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican diferentes niveles de detalle.
Cuanto menor sea el nivel, más detallado es el requisito. Sin embargo, corresponde a los analistas de negocio
decidir el nivel de detalle en cada nivel, aunque no sería incorrecto establece requisitos muy detallados en el
nivel de necesidades.

Trazabilidad

La trazabilidad de los requerimientos se refiere a la documentación de la vida de cada uno de ellos, y debe
permitir seguir el historial desde su formulación original hasta el momento actual. Cada cambio realizado debe
por tanto ser documentado para conseguir dicha trazabilidad. Incluso la implementación de las características
determinadas por los requerimientos debe poder ser trazada.

Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario final, etc... Todas y cada una
de ellas tienen diferentes requerimientos para el producto. Utilizando la trazabilidad, puede seguirse el historial
de una característica implementada hasta las personas o grupos que la solicitaron durante la generación de
los requerimientos, permitiendo un rápido análisis en cada fase del proyecto para:

 Determinar la visión original y permitir una discusión controlada de los cambios en el alcance.
 Determinar qué elementos se verán afectados cuando consideramos agregar un nuevo requerimiento
o modificar uno ya existente.
 Verificar que el requerimiento contempla todos lo que el interesado solicitó.
 Evitar el Gold Platting: Verificar que la aplicación no implementa funcionalidades no demandadas
por el cliente.
 Actividades en la Gestión de Requerimientos
 Por Joaquín Ibáñez Marimón, PMP® [ Acerca del autor]
 La gestión de requerimientos, entendida como el conjunto de actividades que abarcan la
recopilación, control, análisis, filtrado y documentación de los requisitos del sistema, consiste en tres
actividades fundamentales:
 Generación de requerimientos:
Es la habilidad de entender las necesidades de los interesados, y recopilarlos en un repositorio para
futuros análisis. Las necesidades pueden ser expresadas de forma abstracta y en términos de
problemas (Quiero reducir mis ratios de error en un 35%) o bien concretos y en términos de una
solución (Debe haber un botón rojo de paro en la consola).
 En ambos casos las necesidades son conocidas como características
 Evaluación de requerimientos:
Es la habilidad de discernir qué características son apropiadas para incluir en el producto, dado que
raramente es posible satisfacer todas las características demandadas por cada uno de los
interesados. La evaluación tiene en consideración todas las realidades del mercado y toma la
decisión acerca de qué características se implementarán, cuales lo serán en la próxima versión, y
cuales se aplazarán hasta más tarde.
 Especificación de requerimientos:
Es la habilidad de detallar el comportamiento de un sistema. En cada estadio del proceso de
desarrollo, variaran la forma y el nivel de detalle en la especificación de los requerimientos. Para
ilustrarlo, considérese un proceso estándar de desarrollo en cinco fases: Investigación, Viabilidad,
diseño, construcción y test, lanzamiento.


Investigación
En la fase de investigación, se recopilan requerimientos entre los usuarios y los miembros del equipo
de desarrollo. Para cada uno de ellos se formulan cuestiones similares acerca de cuáles son los
logros, las restricciones y las herramientas o procesos disponibles…Sólo cuando estos
requerimientos sean bien entendidos, se pueden desarrollar los requerimientos funcionales.
 Hay que tener muy presente que los requerimientos no pueden ser completamente definidos al inicio
del proyecto. Algunos cambiarán, bien porque sean simplemente suprimidos, o debido a los intereses
y modificaciones que afecten al ciclo de vida del proyecto.
 Por ello, la flexibilidad en los planteamientos y las operaciones, son condiciones para el éxito.
 El entregable del estadio de investigación es un documento de requerimientos que haya sido
aprobado por todos los miembros del equipo. Después, y durante el desarrollo, este documento será
clave para prevenir la corrupción del alcance o los cambios innecesarios.
 Mientras que muchas organizaciones todavía utilizan solo documentos para gestionar los
requerimientos, otras gestionan a partir de herramientas de software. Estas herramientas permiten
gestionar los requerimientos en una base de datos y acostumbran a tener funciones para automatizar
la trazabilidad, como por ejemplo permitir la vinculación electrónica entre la jerarquía de
requerimientos, el control de versiones y la gestión de cambios
 Viabilidad
Durante el estudio de viabilidad, se determinan:
 Los costes de los requerimientos: Para los requerimientos de usuario, se comparan los costes
actuales con los futuros, una vez se haya implementado el nuevo sistema.
  Los costes de operación: Indicarán qué departamento tiene presupuesto para ello y cuál es el
retorno de inversión para este producto, incluyendo la reducción de costes si se desarrolla un nuevo
sistema más fácil de utilizar.
 Los costes técnicos: Están relacionados con los costes de desarrollo de software y los costes del
hardware. El equipo debe indagar si los nuevos equipos y herramientas añadirán suficiente potencia
de procesamiento para transferir suficiente carga de trabajo del usuario al sistema que permita un
ahorro significativo de tiempo y costes al personal
 El entregable para el estadio de estudio de viabilidad son la programación y el presupuesto para el
proyecto.
 Diseño
Asumiendo que los costes han sido determinados con precisión y que los beneficios a obtener son
suficientemente importantes, el proyecto puede pasar al estadio de diseño. En dicho estadio, la
actividad principal de la gestión de requerimientos es comparar los resultados del diseño con el
documento de requerimientos, para asegurarse de que el trabajo está contemplado dentro del
alcance.
 Implementación y test
En el estadio de implementación y test, la actividad principal de la gestión de requerimientos, es
asegurar que el trabajo y el coste se desarrollan de acuerdo con la programación y el presupuesto, y
que las nuevas herramientas cumplen de hecho con los requerimientos. La herramienta principal
utilizada en este estadio es la construcción de prototipos y el test iterativo. Para una aplicación de
software, la interfaz de usuario puede ser creada en papel y probada con los usuarios potenciales,
mientras está siendo creado el entorno de software. Los resultados de dichos test son archivados en
una guía de diseño de interfaz de usuario y trasladado al equipo de diseño, cuando este esté listos
para desarrollar la interface. Esto ahorra tiempo y hace el trabajo mucho más fácil.
 Lanzamiento
Podría pensarse que la gestión de requerimientos finaliza al entregar el producto, pero no es del todo
cierto. Desde este punto, se recopilan los datos provenientes de la aceptación de la aplicación, y
utilizados posteriormente en la fase de investigación de la nueva generación o versión. Entonces, el
proceso empieza de nuevo.

Pasos de la Gestión de Requerimientos

Por Joaquín Ibáñez Marimón, PMP® [ Acerca del autor]

Una descripción simplificada de la gestión de requerimientos contiene los siguientes pasos principales:

Establecer un plan de gestión de requisitos

Una de las primeras tareas en el proyecto es desarrollar un Plan de gestión de requerimientos (RMP son sus
siglas en ingles). El RMP describe el enfoque general para gestionar los requerimientos del proyecto. El
documento detalla cómo se generan, organizan, modifican y trazan los requerimientos en el ciclo de vida del
proyecto. También describe todos los tipos de requerimientos y los atributos utilizados en el proyecto. Algunas
cuestiones que debe clarificar el RPM son:

 ¿Cómo deben usarse las herramientas de gestión de requerimientos?

 ¿Qué tipos de requerimientos serán trazados en el proyecto?
 ¿Cuáles son los atributos de estos requerimientos?
 ¿Dónde se crearan los requerimientos-en una base de datos o solo en documentos?
 ¿Entre cuales requerimientos necesitamos implementar trazabilidad?
 ¿Qué documentos se requieren?
 ¿Qué requerimientos y documentos serán utilizados como contrato con un proveedor? ¿Qué
metodología será utilizada?
 ¿El cliente necesita algún documento específico para cumplir con su proceso de desarrollo?
 ¿Cómo se implementará la gestión de cambios?
 ¿Qué proceso garantizará que todos los requerimientos serán implementados y comprobados?
 Qué requerimientos u opiniones necesitamos para generar informes?
Técnicas para la recopilación de requerimientos
La recopilación de requerimientos es un paso muy importante. Un error o mala interpretación de un requisito
en esta etapa propagará el problema a través del ciclo de vida de desarrollo.

En muchos proyectos es más fácil agrupar todas las entradas de los interesados en un mismo tipo de
requerimiento,. En otros proyectos, puede haber la necesidad de distinguir entre "necesidades de los
interesados", que describen los requisitos iniciales, y "solicitudes de los interesados ", que pueden incluir las
solicitudes de cambio posterior.

Entrevistas: Son utilizadas para recopilar información de los interesados. Sin embargo, la predisposición y
experiencias de la persona entrevistada influirán en la obtención de resultados. Es conveniente la utilización
de preguntas abiertas que no sugieran una determinada respuesta.

Análisis de Documentos: Todo establecimiento de requisitos implica un cierto estudio de los documentos
que definen la razón de ser del proyecto, tales como planes de negocio, estudios de mercado, contratos,
etc.…

Tormenta de ideas: Es una técnica eficaz porque las ideas más creativas y efectivas, son a menudo, el
resultado de la combinación de ideas aparentemente inconexas. Además, esta técnica alienta el pensamiento
de ideas inusuales.

Talleres de Requisitos: Pueden estar diseñados para alcanzar la unificación de criterios en cuanto a los
requisitos de una capacidad en concreto. Conviene que sean dirigidos y coordinados por un experto, y son
normalmente cortos (uno o varios días). Otras ventajas que a menudo consiguen es alentar el compromiso de
los participantes con el proyecto, fomentando el espíritu de grupo

Creación de prototipos: Consiste en la creación de una versión rápida y poco depurara de un sistema o
partes del mismo. Con dicho prototipo, los usuarios y diseñadores tendrán una idea clara de las capacidades
del sistema., aunque podría tener la percepción de que los desarrolladores están en un estadio del diseño
más avanzado de lo que realmente están, sugiriendo una impresión de los plazos de finalización demasiado
optimista.

Casos de uso: Es una representación gráfica de las acciones que debe realizar un sistema. Deben
complementarse siempre con atributos de calidad y otras informaciones tales como características de la
interfaz.

Los casos de uso por sí sola no proporcionan suficiente información que permita actividades de desarrollo.

Guiones gráficos: Son un conjunto de dibujos que representan un conjunto de actividades de usuario que
describen las que se producen en un sistema o capacidad existente o prevista. Los guiones gráficos son una
especie de prototipos de papel. Los clientes, usuarios o desarrolladores dibujan pantallas, cuadros de diálogo,
barras de herramientas y otros elementos que creen que deberá proporcionar el software. Los guiones
gráficos son baratos y permiten eliminar los riesgos y costos más elevados de creación de prototipos.

Análisis de interfaces: El diseño incorrecto de las interfaces es a menudo una de las principales causas de
sobrecoste y fracaso del producto. La identificación temprana de las características de las interfaces externas
clarifica el ámbito de aplicación de producto, ayuda en el proceso de evaluación del riesgo, reduce los costos
de desarrollo del producto, y mejora la satisfacción del cliente.

Modelado: Es una representación de la realidad que pretende facilitar la comprensión. El uso de prototipos y
modelos ayuda a eliminar ambigüedades y contradicciones, contribuyendo de forma notable al éxito del
proyecto.

Desarrollo el documento de visión

Es un documento de visión es un documento que describe la 'visión', o plan general, para un determinado
proceso de software. Pretende ser un documento de alto nivel más breve y general que un documento de
requisitos de producto, y en él se describe lo que se espera llevar a cabo y las características que no están en
el alcance, pero que se prevé agregarán al producto en posteriores etapas del desarrollo de éste

El propósito del documento es recopilar y analizar las ideas que han surgido para el futuro del producto, y
asegurarse de que los interesados clave tienen una visión clara y compartida de los objetivos y alcance del
proyecto. Identifica alternativas y los riesgos asociados con el proyecto. Por último, presenta un presupuesto
para la fase de planificación.
Durante el desarrollo del documento de visión, uno de los logros principales del análisis de negocio es que se
deriven características para las necesidades de los interesados. Las características deben tener todos los
atributos de un buen requerimiento: Verificable, no redundante, claro….

El documento de visión debe contener la información esencial acerca del sistema que está siendo
desarrollado. Además de listar todas sus características, debe contener:

 Una descripción general del producto.

 Un sumario con las capacidades del sistema.
 Toda la información que pueda ser requerida para comprender el propósito del sistema.

También pueden listarse todas las necesidades de los interesados que no fueron recogidas en otros
documentos

Crear casos de uso

Los requerimientos funcionales se describen mejor en forma de casos de uso, que se derivan de las
características. Un caso de uso es una descripción de un sistema en términos de una secuencia de acciones.
Debe ser un resultado observable o un valor para el actor (un actor es alguien o algo que interactúa con el
sistema).

Los casos de uso:

 Son iniciados por un actor

 Modelan la interacción entre el interesado y el sistema
 Describen una secuencia de acciones
 Capturan los requerimientos funcionales
 Proporcionan algún valor para un actor
 Representan un completo y significativo flujo de eventos.
Especificación suplementaria
Las especificaciones suplementarias recogen aquellos requerimientos no funcionales (usabilidad, fiabilidad,
rendimiento,..) y algunos requerimientos funcionales internos del sistema que, por tanto, son difíciles de
contemplar en los casos de uso.

Creación de casos de prueba a partir de casos de uso

Tan pronto como se recopilan todos los requisitos, deberíamos diseñar una forma de comprobar si se
implementan correctamente en el producto final. Los casos de prueba mostrarán a los evaluadores qué pasos
deben realizarse para probar todos los requisitos. En este paso nos concentraremos en la creación de casos
de prueba a partir de casos de uso.

Creación de casos de prueba a partir de especificaciones complementarias

El enfoque utilizado en el paso anterior no se aplica a las pruebas de los requisitos complementarios. Dado
que estos requisitos no se expresan como una secuencia de acciones, el concepto de escenarios no se les
aplica, y debe desarrollarse un enfoque individual a cada uno de los requisitos complementarios.

En este paso, también se diseñarán pruebas de infraestructura y cuestiones relacionadas con la plataforma.

Diseño del sistema

Los requisitos son la base para el diseño del sistema, que a menudo se ve facilitada por el uso del lenguaje
unificado de modelado (UML)

Introducción a la Recopilación de Requerimientos

El líder de proyecto debe utilizar cualquier medio posible para obtener los requerimientos del sistema. Esto lo
realiza en especial durante la primera fase del proyecto. Aunque es normal que siga haciéndolo en las demás
fases en menor medida, pues difícilmente se podrán tener los requerimientos totalmente estables ni completos
desde un principio.

Una de las principales formas de obtener dicha información es mediante reuniones donde el analista debe
guiar la entrevista y documentar todos los puntos importantes que allí se vayan mencionando.

Se deben de analizar los documentos con los que se cuente para preparar una agenda y cuestionarios para
cada entrevista y así obtener mejores resultados.

Debe de tomar en cuenta la opinión de los diferentes stakeholders del proyecto, desde el responsable del área
a la cual se le está desarrollando el sistema hasta el usuario final para obtener los requerimientos más
completos posible.

Durante las reuniones se deben de elaborar minutas con los acuerdos y enviarlas a los participantes para su
validación. Si no responden en un tiempo acordado con sus observaciones se considerará como aceptado lo
allí escrito.

Se recomienda utilizar mecanismos que faciliten la retroalimentación y participación de usuarios, como es el

caso de modelos, prototipos no funcionales y casos de uso.

La información documentada en las minutas no reemplaza a los documentos formales de requerimientos,

como podrían ser la visión, la especificación y matriz de requerimientos, las especificaciones de casos de uso
o la especificación suplementaria.

Durante la fase preliminar (Concepción en el caso del Proceso Unificado) hay que identificar los
requerimientos de alto nivel del sistema en un documento de Visión y detallarlos en Especificaciones de casos
de uso y especificación suplementaria durante la fase de Análisis (fase de Elaboración para el caso de UP).

Los requerimientos documentados son la base para que el administrador realice las estimaciones y el plan del
proyecto en general. Para lo cual necesitará la validación del usuario a todos los documentos donde se
especifiquen los requerimientos.
El administrador no debería asumir nada. Es importante que se asegure que está entendiendo correctamente
lo que el usuario quiso decir, por lo que debe validar la información escrita y de preferencia formalizarla por
medio de firmas de aprobación de los usuarios.

Validar Requerimientos con el Usuario

Parte indispensable del proyecto consiste en asegurar que el equipo de desarrollo entiende adecuadamente
las necesidades del usuario para así desarrollar un sistema que cumpla con sus expectativas. Para facilitar
esto, el usuario debe revisar y firmar de autorizado los documentos donde estén especificados los
requerimientos, como son los casos de uso, el documento de Visión y/o cualquier otro documento donde
hayan quedado documentados.

El documento de visión debe validarlo el usuario al completarse la fase de concepción, y los requerimientos a
detalle al completar la fase de elaboración. El líder de proyecto debe asegurarse que se realice dicha
validación.

Control de Cambios a los Requerimientos

Dicen que lo único constante en los proyectos son los cambios. Debemos de acostumbrarnos a ellos y
aceptarlos como algo normal. Cambios que solicitan los usuarios porque comprenden mejor lo que necesitan,
o porque cambian las necesidades del negocio, porque se identifica una mejor forma de hacer las cosas o por
cualquier otra razón.

El problema no son los cambios a los requerimientos, sino el hecho de que se agreguen a la lista de
requerimientos del proyecto sin considerar el impacto que tendrán sobre el plan. No hacerlo significa que
cuando el proyecto se termine en una fecha posterior a la acordada originalmente, o con un presupuesto
mayor al considerado, se le podría achacar al líder del proyecto como un fracaso.

El control de cambios es el proceso mediante el cual se asegura que no se realicen cambios que afecten el
éxito del proyecto, y que aquellos que se implementen sean analizados, negociados y planeados de una
manera adecuada.

Estando dentro de la fase de Elaboración o después de haber negociado el alcance y el plan de trabajo, si el
usuario llegara a solicitar un cambio a los requerimientos establecidos, el administrador u otra persona
debería de llenar una solicitud de cambio con la descripción del cambio.

El cambio es analizado y se evalúa el impacto en costo y tiempo, y si es algo aceptable para los recursos
disponibles y el tiempo que se le puede asignar a dicho proyecto, además de ser aceptado por el usuario y
autorizado por la gerencia, entonces se acepta la solicitud. En caso contrario debe registrarse como una
solicitud rechazada.

El impacto del cambio debe ser estimado por lo recursos involucrados en las actividades relacionadas con
dicho cambio para después negociarlo con el cliente. Dicho impacto puede significar tiempos o costos
adicionales, por lo que requiere la aprobación correspondiente del gerente y del cliente.

Independientemente de que la solicitud sea aceptada o rechazada debe registrarse en el control de cambios
del proyecto con un identificador único y algunos datos básicos de acuerdo al formato establecido para ello, o
de acuerdo a la herramienta de control de cambios que se utilice.

Ciclo de vida - Fases del proyecto

Por Miguel Armas

Antecedentes
Para facilitar la comprensión del ciclo de vida de un proceso y de un proyecto, los procesos dividen su ciclo de
vida en fases, donde cada fase tiene un propósito en particular y generalmente un responsable principal del
hito (milestone) que marca el fin de cada fase. En los procesos mas populares las fases van desde cuatro en
el Unified Process (UP) hasta seis en el Enterprise Unified Process (EUP), pasando por las cinco del Microsoft
Solutions Framework (MSF), en esta ocasión nos quedaremos en el punto intermedio de MSF para tener una
mejor perspectiva sin tanta complejidad.

Cascada + Espiral = Iterativo e Incremental

Los tres procesos anteriores comparten la estructura general de sus ciclo de vida al combinar el ciclo en
cascada con el espiral, logrando un ciclo de vida iterativo e incremental, que es el modelo utilizado por la
mayoría de todos los procesos.

Fases
Este ciclo de vida se divide en distintas fases, coincidiendo los procesos mencionados anteriormente en las
primeras tres, con algunas diferencias en las ultimas fases. Estas fases fueron diseñadas con un enfoque
orientado a algunos hitos principales, usados para planear y monitorear el avance del proyecto, marcando
estos hitos la transición de una fase a otra. Las fases tienen distintos nombres de acuerdo a cada proceso,
pero básicamente son las mismas, estas fases y sus hitos principales son los siguientes:

Concepción (visión)
En la concepción lo mas importante es determinar la visión y el alcance del proyecto, logrando para ambos
elementos una aprobación de los principales involucrados en el proyecto.
La visión nos dice hacia donde dirigirnos, planteando claramente cual es el problema y que es lo que
debemos hacer para solucionarlo. Un elemento esencial en esta fase para alinear los objetivos de negocio con
la estrategia tecnológica es también cuestionarnos por que estamos haciendo las cosas, para conseguir
verdaderas soluciones de negocio no basta saber qué hay que hacer, también es importante conocer por qué
es importante el proyecto y de que manera ayuda a la organización a conseguir sus objetivos de negocio.
El alcance del proyecto indica que partes de la visión se pueden cumplir bajo las restricciones de tiempo y
recursos del proyecto en cuestión, lo que nos ayuda a determinar la viabilidad del proyecto, donde tal vez
encontremos un proyecto muy rentable pero que no es posible desarrollarlo en el momento por que la
organización no cuenta con los recursos suficientes, un proyecto muy interesante en el cual la relación costo-
beneficio no amerita el esfuerzo ni el riesgo implícitos o un proyecto que representa una oportunidad
estratégica de posicionamiento en el mercado para la organización, a pesar del alto costo de los recursos
necesarios.
Sabemos que la concepción ha terminado cuando tenemos una visión clara con un alcance bien delimitado
por el tiempo y los recursos estimados para el proyecto, lo cual nos indica la viabilidad del proyecto.

Elaboración (planeación)
Una vez establecido el que y por que en la concepción, durante la fase de elaboración establecemos quien,
como, cuando y donde construirá la solución.
En esta fase terminamos el análisis y establecemos la arquitectura principal de la solución, elaborando los
planes detallados del resto de las fases, indicando recursos y tiempo necesarios para concluir el proyecto. En
esta fase también se determina el equipo de trabajo necesario, al cual se le asignan las actividades
enumeradas en el plan de trabajo. En esta fase el administrador del proyecto tiene las actividades mas
importantes, ya que aquí se define el plan que garantizara el éxito del proyecto para cumplir con las tres
variables principales: Características, Recursos y Tiempo.
Esta fase concluye con una definición a detalle del problema, la arquitectura necesaria para la solución y un
plan maestro aprobado por todos los principales involucrados.

Construcción (desarrollo)
Esta fase concluye cuando el equipo de desarrollo termina de construir todo el alcance especificado durante
la elaboración, y aunque este es el hito principal de la fase no es el único, durante la construcción también se
planean las pruebas que se aplicaran al finalizar la construcción. Esta fase es la que generalmente involucra
el mayor numero de riesgos, recursos y tiempo del proyecto.

Estabilización
El hito principal de la estabilización es lograr que el producto o servicio construido pase las pruebas de
calidad planeadas en la fase anterior. Esta fase concluye cuando las pruebas de aceptación son aprobadas
por clientes y usuarios. Durante esta etapa el equipo de calidad ejecuta las pruebas planeadas entregando
reportes de errores al equipo de construcción el cual los corregirá para realizar las pruebas nuevamente. Y
aquí enfrentamos un hecho de la vida: No existe ningún producto o servicio perfecto. Es por esto que esperar
a corregir todos los errores para terminar esta fase nos llevaría a un proyecto interminable, no es pecado
liberar un producto o servicio con errores, pero si lo es hacer una liberación sin ubicar todos y cada uno de los
errores, es por esto que el fin de la estabilización se da cuando el producto o servicio cumple con los
estándares de calidad establecidos y se tiene una lista de todos los errores conocidos siempre y cuando estos
sean permitidos por el estándar de calidad.

Despliegue (implementación)
El despliegue contempla la instalación de una versión liberada en el ambiente de producción y la
capacitación de todos los usuarios. Se define como una fase aparte ya el ambiente de producción puede
llegar a extremos tales como incluir 60 ciudades, 150 sucursales y 200 usuarios, lo cual puede implicar otro
proyecto completo por el nivel de tiempo y recursos necesarios. Esta fase termina cuando al solución se ha
desplegado completamente en el ambiente de producción y todos los usuario han sido capacitados.

Conclusiones
Cualquier proyecto pasa por estas fases, lo reconozcamos o no, ser conscientes de esto marca la diferencia
hacia los proyectos exitosos, si por darle gusto al cliente y ganar un proyecto solo contemplamos la fase de
elaboración y construcción terminaremos asumiendo y sufriendo el costo de todas las fases omitidas, además
de perder la confianza de clientes y usuarios al no terminar el proyecto con las funcionalidad, tiempo y
recursos acordados al inicio del proyecto, así que lo mejor que puedes hacer es tomar conciencia de las fases
del ciclo de vida de un proyecto y plantearte una estrategia para que tus clientes y usuarios entiendan la
importancia de cada una para garantizar el éxito de la solución.

Administración de la Configuración

Se debe contar con un directorio con una estructura estándar establecida para los proyectos, dentro de un
repositorio de administración de la configuración (p.ej. CVS). Si es un proyecto o módulo nuevo se creará un
nuevo directorio en el repositorio. Si se trata de mantenimiento se utilizará el que ya exista para ese proyecto.
Se deben de establecer y controlar los permisos necesarios para el acceso y mantenimiento de dicha
información para el equipo de trabajo y la gente involucrada en su elaboración.

Este repositorio puede estar en el servidor central de proyectos y lo debe de crear el administrador de la
configuración al comenzar un nuevo proyecto en la fase de concepción, a solicitud del líder de proyecto.

El líder del proyecto debe asegurarse que los miembros del equipo mantengan actualizados sus respectivos
productos/documentos del proyecto en el repositorio de administración de la configuración del proyecto,
dentro del subdirectorio que les corresponda y utilizando los estándares para la identificación de los archivos y
sus versiones.

El repositorio de trabajo debe ser creado por soporte bajo solicitud expresa del administrador de proyectos, y
todos los documentos y archivos del proyecto se manejarán de forma centralizada en dicha librería,
incluyendo el código y librerías ejecutables.

Las Tres Principales Ventajas de la Línea Base de un Proyecto

Por Linda Russell [ Acerca de la autora ]
Traducción por Editorial LiderDeProyecto.com

Cuando se ha finalizado la planeación de un proyecto y se tienen previstas las fechas, horas y costos
acordados, sin duda, resulta buena idea almacenar estos valores. Es por ello que en el siguiente artículo
revisaremos por qué es positivo e importante realizar la Base de Medidas Fundamentales de Comparación o
la Línea Base en un proyecto.

¿Qué es una Línea Base?

Primeramente veremos que una Línea Base es un conjunto de valores almacenados, tales como:

 Calendario original con fechas de inicio y terminación.

 Esfuerzo planificado (puede ser expresado en horas).
 Costo presupuestado.
 Ingresos presupuestados.

¿Por qué una Línea Base?

Las ventajas principales de tener una Línea Base de proyecto son:

 Capacidad de evaluar el desempeño.

 Cálculo del valor devengado.
 Estimación exacta del futuro mejorado.

Evaluación del desempeño

Si tenemos los conocimientos sobre una planificación anterior, podemos compararla con los planes actuales y
hacer una estimación para sondear si estamos o no en el camino correcto. Para tener más certeza respecto a
esto, el software utilizado por el líder de proyecto puede contener una metodología que así lo indique, lo que
proveerá de discrepancias de información, las cuales pueden ser útiles para estimaciones futuras.
Por ejemplo, una tarea que fue planeada para empezar la semana pasada y la planificación
Esfuerzo/Duración fue de 10 días, debería concluir a finales de la presente semana. No obstante, si
consideramos que dicha tarea inició el miércoles pasado y actualmente nos encontramos en el día lunes de la
segunda semana, habiendo revisado la tarea, podríamos estimar que nos tomará otros ocho días completarla.

Comienzo planificado Lunes Semana 1 Comienzo real Miércoles Semana 1

Finalización planificada Viernes Semana 2 Finalización lista Miércoles Semana 3

Duración planificada 10 días Duración modificada 11 días

Por consiguiente, sobre la estimación actual observaremos que la tarea tomará un día extra para completar y
estará tres días tarde.

Esta es una forma un tanto rudimentaria de hacer la evaluación del desempeño, la cual podría realizar
cualquier persona. Si le agregamos un valor para mejorarlo, podremos basarnos en el uso de una mejor
medida como lo es la utilización del Valor Devengado. Si se registran las horas reales ocupadas en una tarea,
el software usado por el líder de proyecto puede ser capaz de calcular el valor completo del porcentaje.

Valor Devengado

Con esta técnica existe la posibilidad de comparar las horas y los costos planeados de un proyecto anterior,
en contraste con los costos y el tiempo de un trabajo actual, tomando en cuenta el avance de cada tarea y el
proyecto como un todo. Frecuentemente éste incluye el cálculo de un indicador de desempeño.

Esto permitirá observar las tendencias en el desempeño y de este modo predecir los recorridos potenciales.
En un nivel de tarea individual, el valor devengado es un buen indicador para conocer el tiempo y costo
utilizado hasta el momento; comparado con la cifra tiempo/costo que en realidad ha sido gastada.
Sin embargo, se aconseja no transmitir demasiada confianza sobre tales previsiones, sobre todo en las etapas
iniciales del ciclo de vida del proyecto, ya que pocas tareas han sido iniciadas o completadas; a medida que el
tiempo avanza la exactitud de las predicciones se irán incrementando gradualmente.

Cuando una tarea es completada, el valor devengado calculado será igual a las cifras planificadas, de manera
que esta medida no puede ser utilizada para mejorar la exactitud de la estimación.

Estimación mejorada

Cuando se crea un plan se estima cuánto tiempo tomará la realización de cada tarea y cuánto esfuerzo
requerirá completar cada una de éstas. El líder de proyecto también puede calcular los costos probables, y si
está cobrando por el trabajo hecho podrá conocer cuál será el ingreso. Pero ¿cómo hacer esto?. Las
herramientas más comúnmente usadas están basadas en la experiencia previa, como si se tratara de mirar a
través de una bola de cristal.

Podemos mejorar la exactitud de la estimación si contamos con un registro de estimaciones previas

comparadas con los resultados actuales. Esto puede darnos un margen de error (tal vez en porcentaje) el cual
puede incorporar todas las estimaciones futuras.

Si nuestro software de administración de proyectos tiene una plantilla instalada, al final de cada proyecto
podemos usar los datos de discrepancia para actualizar dicha plantilla de tareas con las estimaciones ya
revisadas.

Conclusión

Teniendo una línea base en cada proyecto, el líder de proyecto puede monitorear constantemente el
desempeño del mismo, así como mejorar la exactitud de estimaciones futuras.

Identificar Stakeholders... ¿Por qué molestarse en esto?

Por Mary Ann Crow, PMP® [ Acerca de la autora]

Bajo el nombre “Identificar Stakeholders”, el PMI® decidió exaltar esta actividad como un nuevo proceso en la
Cuarta Edición del PMBOK®, ya que es uno de los más importantes para establecer las bases tempranas
dirigidas a la posterior planificación, ejecución, así como monitoreo y control de la información y comunicación
del proyecto, para alcanzar el éxito en éste.

Este proceso debe hacerse en la fase de inicio del proyecto para que las salidas claves del Registro de
Stakeholders y la Estrategia de Administración de los Stakeholders sean usadas asociativamente en el
proceso de Gestión de la Comunicación conocido como Manejo de las Expectativas de los Stakeholders.

Primero, revisemos algunas cosas básicas para entender la administración de los stakeholders:

 Los stakeholders son todas aquellas partes que podrían ser impactados positiva o negativamente al
término del proyecto
 Los stakeholders pueden ganar o perder a través del éxito o fracaso del proyecto
 Los stakeholders pueden tener diferentes niveles de autoridad, los cuales afectarán su forma de
ejercer influencia sobre el proyecto y sus entregables
 Los stakeholders serán afectados por los resultados del proyecto

Es imperativo identificar a todas las personas y organizaciones que serán impactadas por el proyecto y
posteriormente documentar la información relevante respecto a sus intereses, participación e impactos sobre
el éxito del proyecto. En este ámbito, el PMBOK® sugiere usar dos salidas tempranas para la identificación de
stakeholders en el proyecto:
  La primera disponible es la salida proveniente del desarrollo del Acta Constitutiva del Proyecto, la
cual puede contener una lista de los clientes, patrocinadores, ejecutivos, equipo del proyecto o
entidades que son externas al desarrollo de la organización participante en el proyecto. Aquí es
recomendable sostener un encuentro por separado con los personajes identificados en el acta y
preguntarles si conocen de otros que puedan figurar como stakeholders.

 Si el proyecto es el resultado de una actividad de aprovisionamiento o está basado en un contrato

establecido, es importante usar los documentos de adquisición para identificar todas las partes
dentro del contrato que podrían ser stakeholders claves para el proyecto. Los proveedores que
participan en el contrato también podrían ser considerados para la identificación de los interesados
en el proyecto. Usar un contrato hace el proceso un poco más fácil, ya que las diferentes interfases
del contrato deberían ser enlistadas.

El acta constitutiva del proyecto y las indicaciones de los documentos de aprovisionamiento de los interesados
solamente pueden darse al grupo de stakeholders. Por lo tanto, procederemos a definir con mayor precisión
otras posibilidades de stakeholders y lo que se necesita para saber sobre éstos. El PMBOK® sugiere usar una
herramienta de Análisis de Stakeholders y una técnica para recoger información que determine quién de los
interesados debería ser considerado a lo largo del proyecto.

Analizar a los interesados ayuda a definir el lugar para cada stakeholder, así como sus funciones. El anáslisis
de stakeholders es una herramienta de modelo de clasificación que ayuda identificar y determinar el impacto o
apoyo que cada stakeholder podría generar y entonces es utilizado para clasificar a éstos y así precisar la
información para la Estrategia de Administración de los Stakeholders, la cual es una de las salidas de este
proceso.

¿Qué necesitamos saber sobre los stakeholders?, se requiere conocer diferentes niveles de datos acerca de
los interesados identificados para poder manejar apropiadamente las relaciones con ellos y establecer un Plan
de Comunicaciones. Estos son los factores claves que se deben recoger de los stakeholders:
  ¿Quién es el stakeholder por su nombre?; No identificar a algún stakeholder como una clase dentro
de un grupo de personas, tal como: Gerente Funcional o Ejecutivo Senior. Se tiene que solicitar el
nombre, información de contacto y posición adentro de la organización.

 ¿Cuál es la naturaleza de su interés en el proyecto? ¿Personal o profesional?, Identificar qué

ganarán con el éxito o con el fracaso, estableciendo claramente cuánto y de qué forma. Hay que
capturar sus principales necesidades, expectativa principal e influencia potencial en el proyecto o
fase dentro del ciclo de vida.

 ¿Qué esperan los stakeholders del administrador del proyecto?; La mejor forma de determinar esto
es teniendo un encuentro cara a cara con los stakeholders claves, tales como clientes o
patrocinadores. Esto puede resolver cualquier diferencia entre lo que ellos esperan y lo que el project
manager cree que debería esperar.

 ¿Qué esperar de los stakeholders?, Este es el lado contrario de la pregunta previa. Es

definitivamente necesario establecer las expectativas y darse cuenta que no se trata de decirle al
stakeholder, lo que debe hacer o cómo actuar. Si se hace correctamente se le estará proporcionando
al stakeholder una descripción del apoyo que el project manager necesita.

 ¿Cuáles son las prioridades de vigilancia de los interesados? Esto significa que de los principales
elementos de éxito y control, el stakeholder desea mayor monitoreo sobre el calendario, costos,
desempeño y/o calidad.

A continuación revisaremos la clasificación del desempeño de los stakeholders en grupos internos o externos
y los papeles que juegan dentro de un proyecto.

Stakeholders internos: La mayoría de los stakeholders claves son personas que laboran dentro de la
organización sobre la cual se va a desarrollar el proyecto. En este grupo encontramos:

 Clientes internos: Normalmente son personas para quienes el project manager está haciendo el
trabajo y tienen una necesidad particular en que el proyecto pueda ser dirigido a feliz término. A
menudo, los clientes internos pagan por el proyecto y por lo tanto reciben impactos en sus negocios
a partir de los entregables del proyecto.

 Patrocinador del proyecto: Normalmente, no es una posición específica dentro de la organización,

más bien es un rol jugado en un proyecto. El papel del patrocinador es típicamente un representante
de alta jerarquía quien tiene un gran interés en los resultados del proyecto. Este rol puede ser
invalorable para el project manager cuando enfrenta problemas o asuntos que van más allá de su
ámbito de influencia. El sponsor puede facilitar decisiones y contribuir con la asignación de recursos.
Un patrocinador puede ser un miembro de la dirección quien tiene un interés en el éxito o fracaso en
el proyecto. Hay que describirles sus roles, así como las expectativas del administrador del proyecto.
Después de todo, la dirección de la empresa debería estar muy dispuesta a contribuir con el éxito.

 Equipo central del proyecto: Generalmente están ligados cercanamente para hacer el trabajo. En
la mayoría de los casos el equipo principal es un grupo relativamente pequeño compuesto a partir de
diferentes departamentos de trabajos necesarios para completar el proyecto.

 Proveedores de recursos funcionales: Asegurar los recursos puede depender del tipo de
estructura de la organización que requiere el proyecto. En los proyectos se debe solicitar recursos de
otros departamentos, pidiéndoselos al gerente funcional adecuado.

 Supervisor del administrador de proyectos: Simplemente es el jefe del project manager y tiene un
gran interés en el éxito del proyecto. El líder del proyecto debe mantenerlo informado en todo
momento y protegerlo para que no reciba sorpresas desagradables.

 Diferentes grupos de apoyo: Esos grupos existen dentro de la organización y son los relativos a la
parte legal, contabilidad, procesamiento de datos y recursos humanos de la empresa. El papel de
éstos hacia el proyecto es más de apoyo que trabajo activo, dependiendo de las necesidades
 específicas del proyecto. Aquí hay que considerar si uno de eso grupos debería tener un
representante en las reuniones del equipo principal.

Stakeholders externos: Los de este grupo tienen interés intrínseco en el proyecto más, aunque no formen
parte de la organización. En este grupo encontramos:

 Clientes externos: Se caracterizan típicamente por los contratos.

 Grupos de usuarios: Se debe considerar a los grupos de usuarios si el proyecto desarrolla o fabrica
un producto que será comercializado y vendido a los consumidores. El líder del proyecto puede
consultar al stakeholder externo acerca de gustos, desagrados, preferencias y elecciones que tal vez
su estrategia de marketing ha asilado para el futuro o para un producto producido similarmente.

 Proveedores: El proyecto puede requerir materiales que deben ser conseguidos a partir de
compañías externas. El project manager debe utilizar la lista de proveedores principales en el caso
de que la empresa tenga una.

 Contratistas y consultores: Al igual que ocurre con los materiales, los cuales son adquiridos a
proveedores, el líder del proyecto también puede utilizar tanto a contratistas como consultores para
realizar ciertas labores o requerir de algunos servicios. En este caso es recomendable usar un
criterio basado en el desempeño y un registro verificable al momento de seleccionar a estos
stakeholders.

Hay que colocar, como mínimo, nombre, información de

contacto, posición dentro de la organización, rol dentro
del proyecto, su expectativa primordial, su principal
requerimiento, e influencia potencial en el proyecto o
fase durante el ciclo de vida. Por último, se debe incluir
una identificación de los stakeholders, ya sean internos o
externos.

El resto de la salida es la Estrategia de Administración

de Stakeholders la cual define el enfoque que debería
ayudar para obtener el apoyo y reducir los impactos
negativos de la identificación de los stakeholders. Una
forma común de representar este dato es dentro de una
matriz de Análisis de Estrategia de los Stakeholders, a
fin de que los elementos como: la lista de los
stakeholders claves quienes pueden afectar
significativamente al proyecto; el nivel de participación
deseado para cada uno de los stakeholders claves
identificados y la estrategia potencial para ganar el
apoyo o reducir obstáculos.

Puesto que la Estrategia de Administración de

Stakeholders puede contener algún dato que es
subjetivo y podría ser considerado sensible, el líder del
proyecto debe asegurarse de ser discreto al momento de
comunicar o compartir los datos sobre los documentos
con acceso de lectura o incluido en un documento
compartido.

El Registro de Stakeholders y la Estrategia de Administración de Stakeholders serán insumos esenciales para

los procesos de Plan de Comunicación y Manejo de las Expectativas de los Stakeholders.

Como última recomendación, solamente les puedo decir que tengan cuidado con otras interfases que
ciertamente no son humanas y que no pueden llamarse stakeholders, pero pueden afectar el proyecto, al
menos tanto como cualquier interfaz humana. Éstas incluyen políticas de la organización, procedimientos,
cultura y otras normatividades.
Lidiando con un “Scope Creep” en proyectos de desarrollo de software

Por Linda Russell [ Acerca de la autora ]

Un Scope Creep es un riesgo significativo en proyectos de

desarrollo de software. Ahora veremos por qué sucede y cómo
evitar o mitigarlo.

¿Qué es un Scope Creep?

El desarrollo de un nuevo software surge generalmente como

resultado de la identificación de una necesidad de un cliente, quien
puede ser interno o externo a una organización. El paso siguiente es
especificar cómo el software cumplirá con esa necesidad,
específicamente, qué funcionalidad será desarrollada.

Lo anterior es el “scope” o alcance del proyecto. En esta fase los

planes del proyecto están preparados y basados en la estimación
para el desarrollo y entrega de una funcionalidad determinada, por
lo que una fecha de finalización es acordada.

Pero, puede ocurrir que cuando comienza el desarrollo y parece que

el proyecto está progresando de manera adecuada, el cliente se da
cuenta que hay requerimientos adicionales que olvidó mencionarlos o elementos extras de funcionalidad que
necesita. Frecuentemente, añadiendo estos suplementos generará que la duración de proyecto sea ampliada,
omitiendo los plazos límites e incrementando los gastos; conduciendo al menoscabo del margen en el
proyecto y potencialmente a la insatisfacción del cliente y pérdida de la credibilidad generada por una entrega
tardía.

¿Cómo lidiar con un Scope Creep?

Es importante que una especificación funcional esté producida desde el principio, escrita en términos que el
cliente pueda entenderla. Por ejemplo, un paseo por el proceso donde el software apoyará, tal vez ilustrado
con una simulación a través de diapositivas, lo que ayudará a clarificar cómo trabajará el nuevo sistema desde
el punto de vista del usuario.

La especificación funcional debe ser acordada y firmada por el cliente y debería incluir una Definición de
Alcance. Esto expresa que solamente la funcionalidad, la cual está explícitamente descrita en la
especificación está incluida en el alcance del proyecto y que algo no descrito está “fuera de alcance”.

Cuando posteriormente el cliente identifica elementos adicionales, dicha referencia es hecha en la

especificación: ¿La funcionalidad requerida es descrita o aludida a:?. Si no lo es, el nuevo desarrollo está
fuera de alcance.

El próximo paso es elaborar el impacto del desarrollo de la nueva funcionalidad: ¿Qué esfuerzo extra será
requerido?, ¿Qué efecto tendrá sobre la totalidad de duración del proyecto?, ¿En qué costos adicionales se
incurrirá y cómo afectará esto al margen del proyecto?.
Si el impacto es insignificante, puede ser acordado para incluir la nueva funcionalidad en el proyecto existente,
pero lo ideal debería ser la realización de la definición por escrito de una especificación revisada. El peligro
aquí es que el cliente creerá que se ha sentado un precedente, por lo que puede pensar que futuras
revisiones serán realizadas de la misma forma; por eso es importante comunicar las razones para permitir la
revisión en esta instancia.

Es más probable que el desarrollo adicional genere retraso y/o costos extras. El cliente necesita estar
conciente de las implicaciones de la revisión en términos del impacto de éstas sobre las escalas de tiempo y
costos; y una especificación de las adiciones y cambios deberían escribirse (con la propia Definición de
Alcance). Entonces será el cliente quien decidirá si está dispuesto a pagar más y si acepta la fecha final
revisada del proyecto. Si está de acuerdo, la nueva especificación debería ser firmada como antes.

¿Realmente necesitamos una Definición de Alcance?

Uno puede pensar que escribir una especificación lo suficientemente detallada puede generar que la
realización de la Definición de Alcance conlleve más tiempo (y costo) del que está garantizado por el valor del
proyecto como un todo. Por ejemplo, si se tiene previsto que todo el proyecto tome únicamente unas pocas
semanas y toma cinco días escribir una especificación detallada, un análisis costo/beneficio mostraría que no
vale la pena hacerlo.

Si es el caso, hay que evaluar la probabilidad del riesgo (basándonos en el conocimiento del cliente y qué tan
seguro se está de todos los requerimientos que han sido identificados) y el posible impacto del aumento en
contingencia suficiente en las estimaciones de tiempo y costos para cubrir todo excepto la mayor parte de las
revisiones principales a la especificación.

Gestión del Tiempo

Cuando el Cliente Quiere Todo para Ayer

Por Bas de Baar [ acerca del autor ]

No todos los clientes son iguales. No me lo van a creer, pero he llegado a escuchar historias donde los
clientes ¡piden sus proyectos en fechas realistas! Como líder de proyecto que eres, probablemente pienses
que la mayoría de los clientes quieren fechas imposibles de cumplir. ¡Quieren el producto para mañana! De
hecho lo quieren para ayer, pero hasta los clientes entienden que esto es imposible.

Si la persona que te contrata para realizar el trabajo pareciera no tener idea de temas como el alcance,
presupuesto o requerimientos, puede que sea por pura ignorancia o irreparable necedad; en todo caso no
vamos a discutir ese punto sino en otro diferente.

El cliente sabe que es imposible lo que pide, y de todas formas exige metas irreales, o por lo menos,
demasiado riesgosas. ¿Por qué razón entonces alguien querría pedir algo que sabe que no puede cumplirse,
e incluso que ni siquiera necesita, para la fecha en que lo está pidiendo?

La culpa la tiene, por lo menos en parte, un autor llamado C. Norticote Parkinson. Quien hizo una afirmación
que hoy en día es conocida como “la Ley de Parkinson”: “el trabajo se expande para llenar el tiempo
disponible para ser completado”. Traduciéndolo, significa que si le asignas a un recurso una cantidad de
tiempo para realizar un cierto trabajo, terminará utilizando todo el tiempo del que dispone, independientemente
de si necesitaba o no todo ese tiempo para realizarlo.

Esto aunado a la idea del “Síndrome del Estudiante” no pinta muy bien para la moral de los empleados. Este
síndrome se refiere al hecho de que los estudiantes suelen pedir tiempo extra para realizar las tareas que se
les asignan en la escuela, para “poder hacer un mejor trabajo”, cuando en realidad el incumplimiento de la
fecha de entrega suele ser principalmente por desidia. Al igual que lo es estudiar para el examen en el último
minuto.

Esta sabiduría popular expresada en estas afirmaciones es la que ocasiona que algunos clientes soliciten
tiempos demasiado apretados. “Si la gente utiliza todo el tiempo que se les da, ¿por qué no darles menos? De
cualquier forma harán el trabajo”. Si la gente desperdicia su tiempo y comienza a trabajar cuando ve que se
acerca la fecha de entrega, el riesgo de retrasarse cuando algo salga mal será inminente. Si le das a alguien 5
días para hacer el trabajo de 3 días, se supone que tienes 2 días “para cualquier imprevisto”: es decir, tienes
un colchón. Pero, si los primeros tres días se desperdician y en los últimos dos surge un problema, será
inevitable retrasarse. Para evitar esto, solemos decirle a nuestros recursos que lo necesitamos antes, para
ponerles más presión.

Un gerente “inteligente” conoce estas leyes y síndromes y posiblemente te dará, a ti como líder del proyecto,
menos tiempo del disponible. De esta manera tiene su “colchón secreto” y evita que tú y tu equipo
desperdicien el tiempo en Internet o chateando, en lugar de trabajar en el proyecto. ¡Qué tipo tan listo! Pero,
como tú no eres nada tonto aplicas el mismo truco, y antes de que nadie se dé cuenta, el pobre recurso tiene
asignado tan sólo un 40% del tiempo disponible. Como resultado de la aplicación de esta sabiduría popular en
todos los niveles superiores del organigrama.

Pero, ¿esta táctica funciona? ¿El recurso es más productivo cuando se le asigna menos tiempo? Adivina…

¡No!
Si la fecha de entrega es percibida como irreal y cumplir lo imposible TIENE que cumplirse, la moral de los
recursos se va al hoyo junto con su productividad. Parece ser que los niveles más altos de productividad se
generan cuando las estimaciones son percibidas por los recursos como precisas y factibles. Todo parece
indicar que apretar el calendario genera efectos contraproducentes y por lo tanto NO ES UNA BUENA
PRÁCTICA.

Pero, ¿por qué estas ideas se hicieron tan populares? Yo crecí con estas ideas como líder de proyecto.
Siempre le daba a mis recursos fechas diferentes a las que acordaba con mi cliente. Parkinson formuló su
“Ley” basado en algunas anécdotas ficticias de la burocracia. Se volvió bastante popular porque tenía algo de
curioso y quizás algo de cierto. La esencia de estas anécdotas radica en el hecho que de la gente en ciertas
organizaciones ficticias estaban de lo más aburridos y desmotivados con su trabajo. Y lo mismo aplica para el
“Síndrome del Estudiante”. Piensa por qué holgazaneabas en la escuela. No es fácil saltar de la diversión al
estudio o a terminar tu tarea. Lo que solemos hacer es posponerlo lo más posible. En realidad la clave para
ambos “problemas” parece ser una falta de motivación para realizar el trabajo.

Esta sabiduría administrativa es bastante conocida. Y está tan arraigada en el dominio público, que incluso se
aprovecha más allá de los niveles gerenciales. Suele ocurrir
que el resto del mundo conoce también el secreto y suele anticiparse a los gerentes. Todos parecen saber
que la fecha asignada nunca es la definitiva y que seguramente habrá oportunidad de negociarla. Lo cual, al
final hace que el efecto neto de la aplicación de estos principios resulte prácticamente inútil, pues la gente
termina no preocupándose demasiado por las fechas.

De acuerdo con DeMarco y Lister: “La decisión de aplicar presión en las fechas del proyecto se necesita hacer
en la misma medida en que decides aplicarle un castigo, o no a tus hijos: si lo aplicas en el momento
adecuado y se justifica fácilmente, puede ser que sea de utilidad. Pero, si lo aplicas todo el tiempo, dejará de
ser creíble y perderá eficacia.”

¿Cómo es que este pedazo de sabiduría se hizo tan popular? Como lo mencioné antes, es contagioso,
curioso y tiene algo de cierto. Aunque, dentro de la sociedad de administradores, en especial entre la elite de
“Administradores Científicos”, suelen creer que hay una diferencia entre ellos y “sus recursos”. Suelen pensar,
equivocadamente, que los administradores hacen la parte inteligente, el razonamiento, la planeación, y los
empleados simplemente ejecutan las tareas que se les asignan. Pero, la verdad es que cualquier suposición
de que los recursos no son capaces de planear el trabajo, es tan sólo un mito.

Si los planificadores están separados de la gente que ejecuta el trabajo y tiene el conocimiento, las
estimaciones seguirán siendo erróneas e irreales, llevando al equipo a un mal desempeño, alimentando así y
“evidenciando” erróneamente la Ley de Parkinson.

Al final, si el cliente quiere su producto para mañana, terminará obteniéndolo dentro de un mes. Quizás si
hubiera estado de acuerdo en que se le entregara en dos semanas, lo hubiera tenido en esas dos semanas.

Estimación de Esfuerzo del Proyecto

Cuando hablamos de estimación de esfuerzo podríamos confundirnos con estimación de tiempos. Y no es tan
raro, pues hay una relación importante. El esfuerzo se refiere a la suma de los tiempos que le dedicarán los
diferentes recursos a cierta actividad o al proyecto. Se mide en horas/hombre, días/hombre, semanas/hombre,
etc. No importa que el trabajo se haga de forma secuencial por un solo recurso o en paralelo por diferentes
personas. Se suman los tiempos de cada uno de ellos para obtener el esfuerzo total.

En cambio, cuando hablamos de tiempos del proyecto, normalmente nos referimos al periodo en el calendario
que será necesario para poder cumplir ciertos objetivos. Por ejemplo, para terminar el proyecto podríamos
determinar un tiempo necesario de tres meses, mientras que el esfuerzo para dicho proyecto podría ser de
seis meses/hombre si trabajaran todo ese tiempo dos personas en paralelo.

Si el proyecto sigue un ciclo de vida iterativo incremental, al estilo de UP (Proceso Unificado), se debe realizar
una estimación inicial en la fase de concepción, pero dicha estimación debe ser refinada al completar la fase
posterior, la de elaboración. Justamente cuando se tiene mayor detalle de los requerimientos y la arquitectura
del sistema, información que permite estimar con mayor precisión.

Cada participante del equipo de trabajo debería de estimar el esfuerzo de sus actividades, desglosando
dichas actividades a un nivel de granularidad tal que las actividades tengan un esfuerzo menor a 2 o 3 días, y
que incluso puede ser de sólo unas pocas horas.

Tal estimación debe ser revisada por el administrador del proyecto para validar que los tiempos sean
razonables y realistas y que no falten actividades dentro del desglose del trabajo.

A continuación algunas recomendaciones para realizar la estimación del esfuerzo del proyecto.

 No des una estimación sin antes haber analizado tranquilamente todo el trabajo que implica
 Incluye en tu plan tiempo para realizar la estimación
 Usa datos de proyectos anteriores
 Estimación por consenso
 Asigna niveles de complejidad a los casos de uso y asocialos con tiempos de acuerdo a tu
experiencia (complejo, medio y simple)
 Granulariza al máximo nivel de detalle tus actividades del plan
 No omitas tareas necesarias, básate en las plantillas de plan o en planes anteriores de proyectos
exitosos
 Confirma tu estimación con la opinión de otras personas o comparándola contra alguna técnica como
serían Puntos de Función o Puntos de Casos de Uso
 Cuantifica el impacto que podrían tener los riesgos de tu proyecto

La estimación del esfuerzo queda plasmada en el plan del proyecto, por ejemplo en el Gantt.

Gestión de Costos

Métodos de Estimación de Costos de Software para Grandes Proyectos

Por Capers Jones [ Acerca del autor ]

El software ha alcanzado una mala reputación pues ha sido considerado como una tecnología perturbadora.
Los grandes proyectos de software han tendido a tener una muy alta frecuencia de exceso de calendarización,
costos, problemas de calidad e indiscutibles cancelaciones. Mientras esta mala reputación a menudo es
merecida, es importante notar que algunos grandes proyectos de software finalizan a tiempo y con el
presupuesto estimado, además funcionan satisfactoriamente cuando éstos son desplegados.
Los grandes proyectos exitosos difieren en muchos sentidos de los fracasos y desastres (Jones 2004). Una
diferencia importante es, cómo los proyectos exitosos concluyen a tiempo, dentro de los costos, recursos y
estimación de calidad prevista en un primer término. De un análisis de resultados de las herramientas de
estimación usadas, publicado en “Estimación de Costos de Software” (Jones 1998), el uso de instrumentos de
estimación automatizados conduce a estimaciones más exactas. A la inversa, los métodos informales o
manuales de llegar en estimaciones iniciales son generalmente inexactos y a menudo excesivamente
optimistas.

Una comparación de 50 estimaciones manuales con 50 estimaciones automatizadas para proyectos en el

rango de los 5000 puntos de función, mostró resultados interesantes (Jones 1998). Las estimaciones
manuales fueron creadas por administradores de proyectos quienes usaban calculadoras y hojas de cálculo.
Las estimaciones automatizadas también fueron creadas por administradores de proyectos o por sus
asistentes de estimación, usando varias herramientas de estimación comercialmente diferentes. Las
comparaciones fueron hechas entre las estimaciones originales presentadas a clientes y ejecutivos
corporativos, y los resultados acumulados al final cuando las aplicaciones fueron puestas en práctica.

Solamente cuatro de las estimaciones manuales estuvieron dentro del 10% de los resultados reales.
Aproximadamente 17 estimaciones eran optimistas entre el 10% y el 30%. Una consternación, 29 proyectos
fueron optimistas por más del 30%. Es decir, las estimaciones manuales rindieron costos bajos y calendarios
cortos que lo ocurrido verdaderamente, a veces por cantidades insignificantes. (Por supuesto varias
estimaciones revisadas fueron creadas a lo largo del camino. Pero la comparación fue entre la estimación
inicial y los resultados finales).

Por contraste 22 de las estimaciones generadas por herramientas de estimación comercial estuvieron dentro
del 10% real de los resultados. Aproximadamente 24 fueron conservadoras entre 10% y 25%. Tres fueron
conservadoras por más que 25%. Únicamente una automatizada fue optimista, por cerca del 15%.

Uno de los problemas con los estudios desarrollados tal como es el hecho de muchos proyectos grandes con
estimaciones imprecisas fueron cancelados sin haber culminado. De ese modo, para que los proyectos
estuviesen incluidos en todo, ellos tendrían que haber finalizado. Este criterio eliminó muchos proyectos que
usaron tanto estimación manual como automatizada.

De modo interesante, las estimaciones manuales y las automatizadas eran equitativamente cercanas en
términos de predicción del esfuerzo de programación o codificación. Pero las estimaciones fueron muy
optimistas cuando predecían el crecimiento de los requerimientos, esfuerzo del diseño, esfuerzo de
documentación, esfuerzo de administración, esfuerzo de evaluación y esfuerzo de revisión y reparación. La
conclusión de la comparación fue que tanto las estimaciones manuales como las automatizadas eran
equivalentes para la programación real, pero las estimaciones automatizadas eran mejores para predecir
actividades de no codificación.
Este es un asunto importante para la estimación de grandes aplicaciones de software. Para proyectos de
software por debajo de aproximadamente 1000 puntos de función en tamaño (equivalente a 125,000
declaraciones C), la programación es el mayor costo de manejo, la exactitud de estimación para codificación
es un elemento clave. Pero para proyectos sobre los 10,000 puntos de función en tamaño (equivalente a
1,250,000 declaraciones C), tanto la eliminación de defectos como la producción de documentos son más
costosas que el código por sí mismo. Por lo tanto la exactitud en la estimación de esos tópicos es un factor
clave.

Las estimaciones de tiempo y costo deberían ser exactas, naturalmente. Pero si ellas difieren de los
resultados reales, es más seguro ser ligeramente conservador que ser optimista. Una de las principales
quejas sobre los proyectos de software se refiere a su tendencia alarmante de exceder gastos y calendarios
planificados. Desafortunadamente, tanto clientes como ejecutivos superiores tienden a ejercer presiones
considerables en los administradores de proyectos y en el personal encargado de realizar las estimaciones.
Por consiguiente un colorario oculto de estimación acertada es aquel en donde éstas deben ser defendibles.
La mejor defensa es una buena colección de datos históricos de proyectos similares.

Debido a que el crecimiento de la estimación de costos es una actividad compleja, existe un crecimiento
industrial de compañías dedicadas a ofrecer diferentes marcas comerciales de herramientas de estimación de
costos en el mercado. A partir del 2005, algunas de esas herramientas de estimación son: COCOMO II,
CoStar, CostModeler, CostXpert, KnowledgePlan®, PRICE S, SEER, SLIM y SoftCost. Algunas de las
herramientas de estimación de costos más antiguas, no están activamente en el mercado pero todavía son
utilizadas, tales como: CheckPoint, COCOMO, ESTIMACS, REVIC y SPQR/20, ya que su uso no es apoyado
por los vendedores, por lo que su utilización está en declive.

Mientras estos instrumentos de estimación fueron desarrollados por empresas diferentes y no son idénticos,
ellos realmente tienden a proporcionar un núcleo de funciones comunes. Los rasgos principales de
instrumentos de estimación de software comerciales en incluyen estos atributos:

• Lógica de dimensionamiento para especificaciones, código fuente y casos de evaluación

• Nivel de fase, nivel de actividad, y estimación de nivel de tarea
• Ajustes para períodos de trabajo específicos, vacaciones y horas extraordinarias
• Ajustes para salarios locales e índices de carga
• Ajustes para varios proyectos de software como militares, sistemas, comerciales, etc.
• Apoyo para métricas de puntos de función, métricas de líneas de códigos o ambas
• Apoyo para “backfiring”, es decir, convertir líneas de códigos a puntos de función
• Apoyo tanto para nuevos proyectos como a proyectos de mejora y mantenimiento

Algunas herramientas de estimación también incluyen funciones más avanzadas como:

• Estimación de fiabilidad y calidad

• Análisis de valor y riesgo
• Retorno de Inversión
• Posibilidad de compartir datos con herramientas de administración de proyectos
• Medios de medición para reunir datos históricos
• Costo y tiempo para completar estimaciones que combinan datos históricos con datos proyectados
• Apoyo para evaluaciones de procesos de software
• Análisis estadístico de múltiples proyectos y análisis de cartera
• Conversión monetaria para acordar proyectos en el exterior

Las estimaciones para grandes proyectos de software necesitan incluir muchas más actividades que
solamente codificar o programar. La Tabla 1 muestra un modelo de actividad típica para seis clases diferentes
de proyectos: aplicaciones web-based, sistemas de información gerencial (MIS), software outsourced,
software comercial, software de sistemas y proyectos de software militares. En este contexto los proyectos
“web” son aplicaciones diseñadas para apoyar sitios web corporativos. Las letras (MIS) son las siglas en
inglés para Mangement Information Systems. El “Outsource” en software es similar al MIS, pero realizado por
una contratista externa. El software de “sistemas” es aquel que controla los dispositivos físicos como sistemas
de telecomunicaciones o computadoras. El software militar constituye todos los proyectos los cuales son
obligados para seguir varios estándares de índole militar. El software comercial se refiere a paquetes
ordinarios como procesadores de palabras, hojas de cálculo y otros por el estilo.

Tabla 1: Actividades típicas de desarrollo de software de seis tipos de aplicaciones

(Los datos indican que el porcentaje de esfuerzo de trabajo por actividad)
Actividades realizadas Web MIS Outsource Comercial Sistema Militar
01 Requerimientos 5.00% 7.50% 9.00% 4.00% 4.00% 7.00%
02 Prototipo 10.00% 2.00% 2.50% 1.00% 2.00% 2.00%
03 Arquitectura 0.50% 1.00% 2.00% 1.50% 1.00%
04 Planes del proyecto 1.00% 1.50% 1.00% 2.00% 1.00%
05 Diseño inicial 8.00% 7.00% 6.00% 7.00% 6.00%
06 Diseño en detalle 7.00% 8.00% 5.00% 6.00% 7.00%
07 Revisiones de diseño 0.50% 1.50% 2.50% 1.00%
08 Codficación 30.00% 20.00% 16.00% 23.00% 20.00% 16.00%
09 Adquisición Reutilización 5.00% 2.00% 2.00% 2.00% 2.00%
10 Compras de paquetes 1.00% 1.00% 1.00% 1.00%
11 Inspecciones de código 1.50% 1.50% 1.00%
12 Validación y verificación 1.00%
13 Administración de la
3.00% 3.00% 1.00% 1.00% 1.50%
configuración
14 Integración formal 2.00% 2.00% 1.50% 2.00% 1.50%
15 Documentación del usuario 10.00% 7.00% 9.00% 12.00% 10.00% 10.00%
16 Prueba de unidad 30.00% 4.00% 3.50% 2.50% 5.00% 3.00%
17 Pruebas de función 6.00% 5.00% 6.00% 5.00% 5.00%
18 Pruebas de integración 5.00% 5.00% 4.00% 5.00% 5.00%
19 Pruebas de sistemas 7.00% 5.00% 7.00% 5.00% 6.00%
20 Pruebas de campo 6.00% 1.50% 3.00%
21 Pruebas de aceptación 5.00% 3.00% 1.00% 3.00%
22 Pruebas independientes 1.00%
23 Aseguramiento de la calidad 1.00% 2.00% 2.00% 1.00%
24 Capacitación/Instalación 2.00% 3.00% 1.00% 1.00%
25 Administración de proyecto 10.00% 12.00% 12.00% 11.00% 12.00% 13.00%
Total 100.00% 100.00% 100.00% 100.00% 100.00% 100.00%
Actividades 7 16 20 21 22 25

La Tabla 1 es simplemente ilustrativa, y los números reales de actividades realizadas y los porcentajes de
esfuerzo para cada actividad pueden variar. Para estimar proyectos reales, el instrumento de estimación
presentaría el conjunto más probable de actividades para ser realizadas. Entonces el Project Manager o el
especialista en estimación de costos ajustaría el conjunto de actividades que corresponden a la realidad del
proyecto. Algunos instrumentos de estimación permiten a los usuarios añadir actividades adicionales que no
son parte del conjunto de actividades originales.

Generadores de Costos para Grandes Sistemas de Software: Trabajo Administrativo y Eliminación de

de Defectos

En conjunto, los grandes proyectos de software dedican más esfuerzo a la producción de documentos y a la
eliminación de defectos que la producción de un código fuente. De este modo, la estimación exacta para
grandes proyectos de software debe incluir el esfuerzo para producir documentos, y el esfuerzo para
encontrar y reparar los defectos, entre otras cosas.

La invención de métricas de puntos de función (Albrecht 1984) ha hecho de la lógica de evaluación completa
para documentos un característica estándar de muchas herramientas de estimación. Una de las razones para
el desarrollo de las métricas de puntos de función fue proveer un método de evaluación para documentos
entregables. Para información adicional sobre puntos de función, pueden entrar al Sitio Web www.ifpug.org.

Tabla 2: Ilustra ejemplos de tamaño de documentación seleccionada a partir de sistemas, proyectos web, MIS,
Outsource, Comercial, Sistemas y dominios de software militar.

Tabla 2: Páginas de documento por punto de función para seis tipos de aplicaciones
(Datos expresados en términos de páginas por cada punto de función)
Web MIS Outsource Comercial Sistema Militar Promedio
Requerimientos 0.25 0.5 0.55 0.3 0.45 0.85 0.48
Especificaciones de
0.1 0.55 0.55 0.6 0.8 1.75 0.73
función
Especificaciones de lógica 0.5 0.5 0.55 0.85 1.65 0.81
Planes de prueba 0.1 0.1 0.15 0.25 0.25 0.55 0.23
Guías de usuario 0.05 0.15 0.2 0.85 0.3 0.5 0.34
Referencia 0.2 0.25 0.9 0.34 0.85 0.51
Informes 0.15 0.5 0.6 0.4 0.65 2 0.72
Total 0.65 2.5 2.8 3.85 3.64 8.15 3.6

Al menos una herramienta comercial de estimación de software puede incluso predecir el número de palabras
en inglés en el conjunto de documentos y también los números de diagramas que probablemente están
presentes. La estimación de documento puede también cambiar basada o empapelar el tamaño tal como el
papel A4 europeo. De hecho, ahora es posible estimar los tamaños basados en texto e incluso estimar los
costos de traducción de un idioma a otro para los proyectos que son desplegados internacionalmente.

Potenciales de Defecto de Software y Niveles de Eficacia de Eliminación de Defecto

Un aspecto clave de la estimación de costo de software es predecir el tiempo y el esfuerzo que será necesario
para revisiones de diseño, inspecciones de código, y todas las formas de pruebas. Para estimar la eliminación
los costos de eliminación de defecto y calendarios, es necesario conocer cuántos defectos son susceptibles
de ser encontrados.

La secuencia típica es estimar los volúmenes de defecto por un proyecto y entonces estimar la serie de
revisiones, inspecciones y pruebas que utilice el proyecto. La eficiencia en la eliminación de defecto de cada
paso también serán estimada. Los costos y esfuerzo para la preparación, ejecución y reparación de defectos
asociados con la actividad de eliminación también serán estimadas.

Tabla 3: Ilustra la distribución global de errores de software entre los seis mismos tipos de proyectos
conocidos en la tabla 1. En la Tabla 3, los defectos son mostrados a partir de cinco fuentes: errores de
requerimientos, errores de diseño, errores de codificación, errores de documentación de usuario y
reparaciones malas. Una mala reparación es un defecto secundario inyectado accidentalmente en un defecto
reparado. En otras palabras una mala reparación es una intención fallida para reparar un defecto previo que
por casualidad contiene un nuevo defecto. Por regla general, aproximadamente el 7% de las reparaciones de
errores accidentalmente inyectarán un nuevo defecto, aunque la gama es de menos del 1% más que el 20%
de inyecciones de mala reparación.

Los datos en la Tabla 3 y en las otras tablas en este escrito, están basadas en un total de aproximadamente
12,000 proyectos de software evaluados por el autor y sus colegas alrededor de 1984-2004. Información
adicional sobre las fuentes de datos puede ser encontrada en (Jones 1996), (Jones 1998), and (Jones 2000).
También pueden ver a (Kan 2003).

Tabla 3: Potenciales defectos promedios para seis tipos de aplicaciones

(Datos expresados en términos de "defectos por puntos de función")
Web MIS Outsource Comercial Sistema Militar Promedio
Requisitos 1 1 1.1 1.25 1.3 1.7 1.23
Diseño 1 1.25 1.2 1.3 1.5 1.75 1.33
Código 1.25 1.75 1.7 1.75 1.8 1.75 1.67
Documentos 0.3 0.6 0.5 0.7 0.7 1.2 0.67
Mala reparación 0.45 0.4 0.3 0.5 0.7 0.6 0.49
Total 4 5 4.8 5.5 6 7 5.38

La Tabla 3 presenta valores de promedio aproximados, pero en el rango de cada categoría de defecto es más
que 2 a 1. Por ejemplo, los proyectos de software desarrollados por compañías que están en el nivel cinco
sobre su modelo de capacidad de madurez, pudieran tener menos de la mitad de los defectos potenciales
expuestos en la Tabla 3. Igualmente, para las compañías con varios años de experiencia con el “Six Sigma”,
la calidad aproximada también tendría potenciales de defectos bajos que están mostrados en este cuadro.
Varias herramientas comerciales de estimación hacen ajustes para cada factor.

Un factor clave para la estimación exacta involucra la eliminación de defectos a través de revisiones,
inspecciones y evaluación. La medida de remoción de defectos es de hecho bastante sencilla y muchas
empresas ahora hacen esto. El promedio de los Estados Unidos es aproximadamente 85%, pero las
empresas destacadas pueden promediar más del 95% de niveles de eficiencia de eliminación de defectos
(Jones 1997).

Es más fácil estimar proyectos de software que utilizar controles de calidad sofisticados y tener altos niveles
de eliminar el defecto en el 95% de las posibilidades. Esto es porque generalmente no hay ocurrencias tardías
de desastres en desarrollo cuando aparecen defectos inesperados. Así los proyectos realizados por
compañías en los más altos niveles de CMM o por compañías con amplia experiencia en "Six Sigma" para
software, frecuentemente tienen muchas más precisión que el promedio.

La Tabla 4 ilustra las variaciones en prevención de defectos típicos y métodos de remoción de defectos entre
los seis dominios ya discutidos. Por supuesto, muchas variaciones pueden ocurrir en esos modelos.

(Los valores de eficiencia acumulativos en la Tabla 4 son calculados así: Si el número de partida de defectos
es 100, y hay dos etapas de prueba consecutivas que cada una elimina el 50% de los defectos presentes,
entonces la primera prueba removerá 50 defectos y la segunda prueba quitará 25 defectos. La eficacia
acumulativa de ambas pruebas es de 75%, porque 75 de los 100 defectos posibles fueron eliminados.)

Tabla 4: Patrones de la prevención de defectos y eliminación de actividades

Web MIS Outsource Comercial Sistema Militar
Actividades de
prevención
Prototipos 20.00% 20.00% 20.00% 20.00% 20.00% 20.00%
Cuartos limpios 20.00% 20.00%
Sesiones JAD 30.00% 30.00%
Sesiones QDF 25.00%
Subtotal 20.00% 44.00% 44.00% 20.00% 52.00% 36.00%
Pre-pruebas de
eliminación
Revisión de
15.00% 15.00% 15.00% 15.00% 15.00% 15.00%
escritorio
Revisión de requerimiento 30.00% 25.00% 20.00% 20.00%
Revisión de
40.00% 45.00% 45.00% 30.00%
diseño
Revisión de
20.00% 20.00% 20.00%
documentos
Inspección de
50.00% 60.00% 40.00%
código
Validación y
20.00%
verificación
Pruebas de
10.00%
corrección
Laboratorios de
25.00%
usabilidad
Subtotal 15.00% 15.00% 64.30% 89.48% 88.03% 83.55%
Actividades de
evaluación
Prueba de
30.00% 25.00% 25.00% 25.00% 25.00% 25.00%
unidad
Nueva prueba
30.00% 30.00% 30.00% 30.00% 30.00%
de función
Pruebas de
20.00% 20.00% 20.00% 20.00%
regresión
Pruebas de
30.00% 30.00% 30.00% 30.00% 30.00%
integración
Pruebas de
15.00% 15.00% 15.00%
desempeño
Pruebas del
35.00% 35.00% 35.00% 40.00% 35.00%
sistema
Pruebas
15.00%
independientes
Pruebas de
50.00% 35.00% 30.00%
campo
Pruebas de
25.00% 25.00% 30.00%
aceptación
Subtotal 30.00% 76.11% 80.89% 91.88% 92.69% 93.63%
Rendimiento
52.40% 88.63% 96.18% 99.32% 99.58% 99.33%
global
Número de
3 7 11 14 16 18
actividades

La Tabla 4 simplifica demasiado la situación, ya que las actividades de eliminación de defecto tienen
eficiencias variables para los requerimientos, diseño, codificación, documentación, y categorías de defectos
mal reparados. Del mismo modo, las malas reparaciones durante la evaluación serán colocadas detrás del
conjunto de defectos no detectados.

La baja eficiencia de la mayoría de las formas de la eliminación de defectos explica por qué una larga serie de
actividades de remoción de defectos son necesarias. Esto explica por qué la estimación de eliminación de
defecto es crítica para la exactitud total de la estimación de costos de software para grandes sistemas. Debajo
de los 1000 puntos de función las series pueden incluir más de una docena de tipos de revisión, inspección y
actividad de evaluación.

Cambios de requerimientos y estimación de software

Un aspecto importante de estimación es la relación con el índice en el cual los requerimientos "se corrompen"
y por consiguiente generan que los proyectos crezcan más durante el desarrollo. Por suerte, la métrica de
punto de función permite la medición directa del índice en el cual este fenómeno ocurre, ya que tanto los
requerimientos originales como los requerimientos modificados tendrán cuentas de puntos de función.

El cambio de requerimientos puede ocurrir en cualquier momento, pero los datos en la Tabla 5 van desde del
final de la fase de requerimientos al inicio de la fase de codificación. Este período de tiempo por lo general
refleja aproximadamente la mitad de del calendario de desarrollo total. La Tabla 5 presenta el pago mensual
aproximado de requerimientos que se corrompen para seis clases de software, y el volumen total de cambio
que podría ser esperado:

Tabla 5: Indíce mensual de cambios en los requerimientos para seis tipos de

aplicaciones
(Desde el final de los requerimientos hasta el inicio de las fases de
codificación)
Web MIS Outsource Comercial Sistema Militar Promedio
Índice mensual 4.00% 2.50% 1.50% 3.50% 2.00% 2.00% 2.58%
Meses 6 12 14 10 18 24 14
Total 24.00% 30.00% 21.00% 35.00% 36.00% 48.00% 32.33%

Para estimaciones hechas tempranamente en el ciclo de vida, varias herramientas de estimación pueden
predecir el crecimiento probable en funciones imprevistas sobre el resto del ciclo de desarrollo. Este
conocimiento entonces puede ser usado para refinar la estimación, y ajustar los costos finales en la respuesta.

Por supuesto, la mejor respuesta a una estimación con un volumen significativo de cambios de requerimientos
proyectado debe mejorar la reunión de requerimientos y los métodos de análisis. Así los proyectos que usan
prototipos, el Desarrollo de una Aplicación en COnjunto (JAD), inspecciones de requerimientos, y otros
métodos de requerimientos sofisticados pueden reducir cambios posteriores a una pequeña fracción de los
valores mostrados en la Tabla 5. Incluso, las estimaciones iniciales hechas para proyectos que usan JAD
predecirán los volúmenes reducidos de exigencias que se cambian.

Factores de Ajuste para Estimaciones de Software

Cuando son usadas para verdaderos proyectos de software, las suposiciones básicas de falta de
herramientas de estimación deben ser ajustadas para emparejar la realidad del proyecto que está siendo
estimado. Estos factores de ajuste son una porción crítica del uso de herramientas de estimación de software.
Algunos de los factores de ajustes disponibles incluyen:

- La experiencia de personal con proyectos similares

- La experiencia de cliente con proyectos similares
- El tipo de software para ser producido
- El tamaño del proyecto de software
- El tamaño de los elementos entregables (documentos, casos de prueba etc.)
- Los métodos de requerimientos usados
- Inspecciones y revisión de los métodos usados
- Diseño de métodos usados
- Programación de los lenguajes usados
- Disponibilidad de materiales reutilizables
- Métodos de evaluación usados
- Sobretiempo pagado
- Sobretiempo no pagado

Las herramientas de estimación automatizadas proporcionan a los usuarios con habilidades para “afinar” los
parámetros de la estimación para emparejar las condiciones locales. Efectivamente, sin tal afinación la
exactitud de la estimación automatizada es reducida significativamente. El conocimiento de cómo ajustar las
herramientas de estimación en respuesta a varios factores es el verdadero corazón de la estimación de
software. Este tipo de conocimiento puede ser mejor determinado por mediciones acertadas y regresión
múltiple de análisis de verdaderos proyectos de software.
Resumen y Conclusiones

La estimación de software es simple en teoría, pero difícil y compleja en realidad. Mientras más grande el
proyecto, más factores habrán que deben ser evaluados. La dificultad y la complejidad requerida para las
estimaciones acertadas de proyectos de software grandes exceden las capacidades de la mayoría de los
project managers de software para producir estimaciones manuales efectivas. En particular, la estimación
acertada de proyectos grandes tiene que abarcar el trabajo de no codificación.

Las herramientas comerciales de estimación de software están lejos de ser perfectas y ellas también pueden
equivocarse. Pero la estimación automatizada frecuentemente supera a las estimaciones humanas en
términos de exactitud y siempre en términos de velocidad y rentabilidad. Sin embargo, ningún método de
estimación está completamente libre de error. La actual “mejor práctica” para la estimación de costos de
software debe usar una combinación de herramientas de estimación de costos de software acoplados con las
herramientas de administración de proyectos de software, bajo la dirección cuidadosa de project managers de
software experimentados y especialista en estimación.

El presente escrito titulado “Métodos de Estimación de Costos de Software para Grandes Proyectos” fue traducido al
español a partir del artículo “Software Cost Estimating Methods For Large Projects” con autorización expresa de su
autor para fines instructivos.

Seguimiento del Proyecto mediante Earned Value

Por Joaquín Ibáñez, PMP® [ Acerca del autor]

El término de EARNED VALUE o valor ganado se refiere a una metodología para medir el rendimiento del
proyecto contra la línea base del mismo, indicando posibles desviaciones de costo y tiempo del proyecto.

Muchos administradores de proyecto administran el rendimiento de sus proyectos comparando la planificación

con los resultados reales. Con este método, se corre el riesgo de estar dentro del tiempo previsto, pero por
encima de los costes planificados. Mediante la técnica del valor ganado, se integra costo, tiempo y trabajo
realizado (o alcance), y puede utilizarse para pronosticar futuras fechas de terminación, rendimientos y costos
del proyecto.

EARNED VALUE también permite la unificación de criterios en el análisis de los resultados del proyecto, dado
que se obtienen valoraciones diferentes al requerir información del rendimiento de diferentes miembros o
equipos, derivado del hecho que probablemente calculan de manera diferente su tiempo y su progreso.
Utilizando EARNED VALUE se establece un método uniforme para determinar del progreso y grado de
cumplimiento del plan hasta la fecha.

En la actualidad, la técnica del EARNED VALUE tiene defensores y detractores, influidos ambos tanto por
experiencias previas como por los comentarios e influencias de otros miembros de la profesión.

Los opositores, por lo general, citan el costo y el esfuerzo para que funcione, y el beneficio limitado derivados
de su aplicación. Los defensores del método, citan los ahorros de costos para el proyecto, unos análisis de
rendimiento más riguroso, y sobre todo, una mejor comunicación y control derivados de su aplicación.

Historia

EARNED VALUE es un concepto que en los últimos tiempos ha alcanzado una notable popularidad en el
mundo de la gestión de proyectos, pero fue desarrollado realmente en el siglo XIX, momento en que surgió la
necesidad de medir los rendimientos de las factorías. Sin embargo, no fue hasta 1962 que el departamento de
defensa de los Estados Unidos lo adoptó como una metodología estándar para medir el rendimiento de los
proyectos.

Surgió originalmente como una extensión de la metodología de planificación de la época, pero se convirtió en
su propia metodología en 1967 con la introducción de los criterios y políticas de control de coste/tiempo sobre
la adquisición de sistemas.
Estos han ido evolucionando a lo largo del tiempo hasta la presente norma ANSI/EIA 748. Durante el proceso,
algunos de los acrónimos han cambiado y los criterios han sido racionalizados, pero prevalecen los
fundamentos.

Concepto de EARNED VALUE

Cuando hablamos de EARNED VALUE, generalmente hablamos de una metodología a la vez qué dicho
término es también el elemento clave de esta metodología. Es la forma más sencilla de equiparar el valor
ganado con el progreso físico. Como su propio nombre indica, es algo que se obtiene a través de un esfuerzo.
En la gestión del proyecto, este valor es el obtenido cuando las actividades se llevan a cabo, y nos permite:

 Establecer un método para determinar cuál es el estado del proyecto y el progreso conseguido hasta
la fecha respecto a lo planificado previamente
 Proporcionar la base para el análisis de rendimiento de costos.
 Permitir conocer el costo del proyecto antes de este se complete, al poder determinar cuál era el
coste planificado y el costo del trabajo realizado en cualquier momento del proyecto.

En consecuencia, el EARNED VALUE es también una medida de progreso. Hay una relación directa entre
EARNED VALUE y tanto por ciento completado. Se podrían determinar los atributos de este como:

 Una medida del progreso del proyecto total o para cualquier subelemento del proyecto.
 Un método coherente para el análisis de los logros del proyecto y los resultados.
 Una base para el análisis de rendimiento de costo de un proyecto.

Utilización del EARNED VALUE

Para poder obtener un análisis que nos determine correctamente el estado y rendimiento del proyecto
mediante EARNED VALUE, es crítico el diseño de la WBS, dado que la aplicación del EARNED VALUE
supone la medición de lo actualmente conseguido contra una base de referencia. Sin la línea de base, no
puede haber ninguna medida significativa.

Preparar una WBS completa para el proyecto presupone que cada tarea de la misma cumple con los
siguientes requisitos:

 Deben estar definidas las fechas de inicio y fin.

 La tarea debe producir un resultado tangible, cuya finalización se puede evaluar objetivamente.
 Cada tarea debe tener asignados unos costos, aunque sean sólo los costos de mano de obra para su
realización.
 Configurar el tamaño de los paquetes de trabajo de las cuentas de costes. Los
 Paquetes de trabajo son las unidades más pequeñas de trabajo de la WBS y se agrupan en cuentas
de costes. Estas son normalmente el nivel más bajo en la WBS donde se realizan asignación y
seguimiento de los costo.

Se hace necesario también disponer de un medio para recopilar la información acerca de los costes reales,
dado que la parte más difícil en la aplicación del EARNED VALUE es la determinación del coste real asumido
en un momento dado.

Indicadores y principales términos de Earned Value

La metodología del EARNED VALUE maneja su propia simbología y conceptos, los cuales son los siguientes:

EV (Earned Value): Valor monetario del trabajo conseguido en el período de evaluación.

AC (Actual Cost): Coste actual del trabajo realizado. El valor monetario es independiente del valor monetario
determinado en el PV.
PV (Planned Value): Valor monetario previsto en el plan de proyecto para una tarea determinada de la WBS.
CV (Cost Variance): Medida para indicar la desviación de los costes respecto del presupuesto previsto.
CPI (Cost Performance Index): Índice del rendimiento de cada unidad monetaria invertida en el proyecto.
SV (Schedule Variance): Medida histórica para indicar el porcentaje de avance respecto del plan previsto.
SPI (Schedule Performance Index): Índice de eficiencia relativa a cuánto valor se ha conseguido realmente
respecto del que está programado para ser llevado a cabo. Porcentaje de avance respecto del plan previsto.
BAC (Budget at Completion): Presupuesto PREVISTO y aprobado para la TODO el esfuerzo proyecto.
EAC (Estimate at Completion): Previsión del coste total al finalizar el proyecto según los datos actuales. Su
cálculo dependerá de la previsión en la evolución del BAC.
ETC (Estimate to Complete): Estimación del coste necesario desde el momento actual hasta finalizar el
proyecto.
VAC (Variance at Completion): Desviación final prevista del presupuesto.

Podremos ver en el siguiente gráfico de coste/tiempo el significado de cada uno de los términos:

Fórmulas de cálculo

Acrónimo Fórmula Interpretación

NEGATIVO: Costes por encima de lo previsto
CV EV - AC
POSITIVO: Costes por debajo de lo previsto
<1: Costes por encima de lo previsto (MAL)
CPI EV / AC
>1: Costes por debajo de lo previsto (OK)
NEGATIVO: Tiempo invertido por encima de lo previsto
SV EV - PV
POSITIVO: Tiempo invertido por debajo de lo previsto
<1 : Tiempo invertido por encima de lo previsto
SPI EV / PV
>1: Tiempo invertido por debajo de lo previsto
 No hay variación del BAC. Hay previsión de continuar con el mismo
BAC / CPI
ratio de gastos
Utilizar cuando la estimación original del BAC estaba completamente
AC + ETC
errada
EAC
Utilizar cuando las variaciones actuales del BAC NO se van a
AC + (BAC - EV)
mantener en el futuro (CPI=1)
AC + (BAC -EV) Utilizar cuando las variaciones actuales del BAC SI se van a mantener
/ CPI en el futuro
ETC EAC - AC
NEGATIVO: Costes por encima de lo previsto
VAC BAC - EAC
POSITIVO: Costes por debajo de lo previsto

Manejo Financiero, un factor de éxito en la ejecución de un proyecto1

Por Juan José Miranda Miranda [ Acerca del autor ]

La gestión financiera es una función que permite unificar

la planificación, presupuestación, contabilidad, pagos,
informes financieros, controles internos, auditoría,
adquisiciones y desembolsos para respaldar la
ejecución. Es un elemento crítico en el éxito de un
proyecto.

Contar con información financiera oportuna y relevante

permite construir una base firme para tomar mejores
decisiones, lo que a su vez facilita el avance físico del
proyecto al contar con la necesaria disponibilidad de
fondos, reduciendo el riesgo de demoras o cuellos de
botella. En un proyecto, una buena gestión financiera
proporciona la información esencial para los que realizan
las tareas de ejecución y supervisión, lo que facilita la
detección de errores accidentales o deliberados,
facilitando la prevención de fraude y corrupción, ya que posibilita los controles internos y la capacidad de
identificar con rapidez los sucesos inusuales y los desvíos que comprometen el presupuesto asignado al
proyecto. Es pues la función financiera una de las más idóneas herramientas con que cuenta un líder de
proyecto para apuntalar su éxito.

Etapas en la administración financiera de la ejecución

El desarrollo de todo tipo de proyectos y en especial aquellos de alguna magnitud, que son los que concentran
nuestro mayor interés, precisan apelar a diferentes fuentes internas y externas (nacionales e internacionales)
para su cabal financiamiento. En efecto, son muchas y muy variadas las modalidades utilizadas en el
financiamiento de proyectos de diferente tipo, que determinan pautas o formatos distintos en la programación
y organización financiera para la ejecución de un proyecto.
Tres etapas se deslindan o distinguen en la administración financiera para éste propósito: identificación de
una estrategia de financiación; la planificación financiera y el cierre financiero. En consecuencia el líder del
proyecto y los responsables del tema deberán abordarlas con suficiente rigor:

 Identificación de una estrategia de financiación: La posibilidad de adelantar una adecuada

maniobra de financiamiento se basa principalmente en el conocimiento exhaustivo del proyecto y sus
necesidades de recursos, de las fuentes disponibles con sus limitaciones y restricciones, y
especialmente de la capacidad de gestión del equipo responsable de la negociación. Cabe anotar
que la mejor fuente de información radica en los estudios de preinversión que sirvieron de base para
tomar la decisión de ejecutar el proyecto, y facilitó la estructuración del “plan de negocios” con el fin
de adelantar las primeras pesquisa en busca de dinero.

La estrategia financiera debe conjugar y hacer valer todas las fortalezas potenciales y mitigar el
efecto y la importancia de las debilidades observadas, con el fin de lograr una negociación
equilibrada que favorezca a las partes. Es oportuno anotar que en algunos casos se nombra
tempranamente al gerente responsable de la ejecución del proyecto, con el fin de comprometerlo
activamente en la negociación con los potenciales inversionistas, lo mismo, que en los acuerdos en
montos y condiciones de créditos con banqueros y proveedores de equipos, insumos y suministros.

Este escenario resulta particularmente interesante, puesto que, en el diseño y elaboración de

contratos y en la exigencia del cumplimiento de los mismos, estará el gerente del proyecto, quien
podrá coordinar con mayor seguridad las necesidades de recursos financieros demandados por las
diferentes actividades y las fuentes comprometidas en valores y fechas. No obstante, la selección de
la firma o el profesional que asumirá la responsabilidad de la gerencia del proyecto, suele hacerse en
la mayoría de los casos, después de haber negociado las condiciones de participación de
inversionistas y de proveedores de crédito, más aún, en muchas ocasiones éstos tienen activa
participación en la selección del gerente del proyecto, suele ser una decisión de consenso entre los
involucrados. La razón en muy sencilla, tanto inversionistas como las agencias de crédito son muy
suspicaces con el manejo de los recursos que comprometen y exigen garantías de idoneidad en
todos los agentes que se vinculen al proyecto, con el fin de mitigar cualquier riesgo que ponga en
peligro la ejecución del proyecto y por ende sus inversiones.

En fin, la identificación de una estrategia financiera es el resultado de un trabajo en equipo, formado

por los propietarios del proyecto o sus gestores, los proveedores de recursos financieros interesados
y el grupo de gerencia (cuando éste ya se ha nombrado), todos ellos, conciliarán intereses para
establecer un plan y un cierre financiero exitosos. Es claro, que la dinámica de la negociación y la
posibilidad de lograr acuerdos depende de la confiabilidad y rigor de los estudios de preinversión,
que para proyectos de alguna magnitud deben alcanzar el nivel de factibilidad.
  La planeación financiera: Desde luego que solamente tiene sentido una planificación financiera
rigurosa cuando el estudio de preinversión se ha desarrollado, a nivel de factibilidad, reiteramos, y se
tienen suficientes evidencias para pensar en que el proyecto se ejecutará, por lo tanto los diseños
definitivos avanzan hasta el nivel de ingeniería de detalle que permita respuestas adecuadas y
suficientes en torno a los siguientes aspectos:

Programación de actividades y sus necesidades de recursos monetarios.

Información relativa a los fabricantes de equipos y proveedores y las condiciones de negociación.
Cronología de las operaciones.
Definición de moneda y condiciones de pago.
Requisitos documentarios y garantías exigidas.
Fuentes alternativas disponibles y sus respectivos costos, plazos y condiciones.
Organización y direccionamiento (usos) de los fondos gestionados y comprometidos.

La desagregación tecnológica del proyecto (EDP) nos permite identificar plenamente las actividades que se
deberán realizar (alcance), el momento de su ejecución y los recursos de todo orden necesarios para
terminarlas adecuada y oportunamente. Los recursos financieros deberán planearse para procurarlos en el
momento adecuado, habida cuenta de los requisitos exigidos por proveedores, banqueros e inversionistas que
no entregarán recurso alguno hasta no llenar a plenitud las condiciones y obligaciones establecidas en los
contratos.

Es claro que el reto de los gestores de proyectos es atender armónicamente los intereses de los diferentes
agentes que participan. Los prestamistas reclamarán mayor seguridad, menos riesgo y el pago oportuno de
las acreencias y en las mejores condiciones de tasa de interés y de garantías. Los propietarios perseguirán
los créditos más baratos, en condiciones más flexibles y la asunción mayor de riesgos por parte de los
acreedores. Se trata pues de conciliar en un punto en el cual las partes se manifiesten satisfechas.

Dada la magnitud de la mayoría de proyectos aquí referenciados, se precisa la concurrencia necesaria de una
serie de agentes que aporten dinero, asuman riesgos y se beneficien de los resultados, por lo tanto la
estructuración jurídica y la formulación financiera del proyecto, deberá ser de tal rigor y transparencia que los
participantes potenciales puedan ponderar adecuadamente los costos y beneficios que se derivan hacia ellos,
y especialmente corroborar la capacidad autónoma del proyecto durante la operación, para generar los
recursos que permitan atender los compromisos tributarios, los del servicio de la deuda y, desde luego,
aquellos valores que a manera de utilidades satisfagan las expectativas de los agentes involucrados.
 El plan financiero debe atender entre otros los siguientes
requisitos:

 Los patrocinadores o gestores del proyecto deberán

garantizar la consecución de los recursos suficientes
para la instalación, montaje y puesta en marcha, ya
que de no ser así no encontrarán respuestas en
ninguno de los eventuales participantes, sean estos
compradores o proveedores de insumos, o
inversionistas externos que solamente participan
siempre y cuando les ofrezcan suficientes y
confiables garantías que respalden el pago de las
acreencias a través de la operación.
 Los gestores del proyecto deberán orientar las
pesquisas en los mercados de capitales para buscar
financiación al menor costo posible.
 También los gestores deberán reducir al mínimo la
exposición al riesgo de insolvencia por parte de los
patrocinadores o propietarios.
 Mediante modelos de ingeniería financiera se
diseñarán formas de repartición de dividendos que
optimicen la tasa de rendimiento de las acciones de
los patrocinadores, teniendo en cuenta los
condicionamientos exigidos por los prestamistas y el
flujo de efectivo derivado de la operación del proyecto.
 Los responsables de la planeación financiera deberán identificar y exigir por parte de las autoridades
el reconocimiento de los beneficios fiscales a que tenga derecho el proyecto.También deberán
conseguir un tratamiento regulatorio adecuado dentro de las normas vigentes.
 Además deberán garantizar la mejor sincronía entre el flujo de efectivo generado por el proyecto y la
programación del pago del servicio de la deuda y el reconocimiento de las demás acreencias.

Se trata de concertar fuerzas antagónicas mutuamente dependientes que buscan mejorar su posición. La
estrategia del gestor del proyecto es lograr un nivel de equilibrio a través de fórmulas conciliatorias que
armonicen los riesgos con los aportes, y que permita sacar adelante el proyecto y por ende beneficiar
sustancialmente a cada uno de los participantes. En efecto, el diseño del plan para la financiación del proyecto
incluye la consecución de recursos tanto para la ejecución como para garantizar la sostenibilidad; por lo tanto,
requiere de la identificación y análisis de las fuentes potenciales de fondos y su disponibilidad periodo por
periodo y, obviamente, la programación de la producción y las ventas para la presupuestación de los ingresos
en cada año de operación del proyecto.

 Cierre financiero: Quizá uno de los retos más difíciles para los propietarios de un proyecto de
alguna magnitud es precisamente garantizar la llegada oportuna de los recursos financieros
suficientes para la realización de todas y cada una de las actividades programadas durante la
ejecución, vale decir, estructurar el “cierre financiero”. Aquí surgen dos modalidades extremas: por un
lado el propietario se encarga de conseguir los recursos y contrata a una firma especializada para la
ejecución del proyecto. Una tendencia más moderna es que la firma ejecutora sea también la
responsable de gestionar los recursos y hacerse responsable de su devolución o pago a través de
los flujos generados durante la operación. En cualquier circunstancia e independiente de quien
asuma la responsabilidad, es preciso protocolizar el cierre financiero, para lo cual es preciso diseñar
y aplicar refinados modelos de ingeniería financiera, puesto que se necesita tomar decisiones en
torno a:

Monto de endeudamiento requerido: el estudio de factibilidad y los diseños definitivos

ofrecen toda la información pertinente para dimensionar las necesidades de capital para la
financiación del proyecto tanto en el periodo de ejecución como durante la operación. La
determinación del nivel de endeudamiento apropiado se establece a partir de:

Monto de las inversiones fijas y diferidas necesarias para la ejecución.

El monto de las necesidades del capital de trabajo que proscriba cualquier conato de parálisis
por falta de recursos.
 Costos financieros que hay que asumir por la financiación de la ejecución y los demás egresos
derivados de la administración del crédito.
Un margen de seguridad que permita cubrir eventuales situaciones no previstas.

Si las circunstancias de orden técnico lo permiten en algunos proyectos se puede programar el

inicio de operaciones antes de la terminación total del proyecto (crecimiento en forma modular), lo
que origina la disponibilidad temprana de ciertos ingresos que alivien las cargas derivadas de los
créditos. Dado que esto afecta directamente la cronología y ejecución presupuestal el gerente del
proyecto debe tener especial interés en esta estrategia que debe ser analizada e impulsada si
resulta válida y es concurrente a los propósitos del proyecto.

Determinación del grado máximo de apalancamiento: la razón deuda/capital que determina

el nivel máximo de apalancamiento depende de:

La rentabilidad esperada y los riesgos de operación del proyecto.

Capacidad de los patrocinadores de cubrir con capital adicional.
Interés que manifiesten los potenciales inversionistas de aportar capital.
La participación como inversionistas de los eventuales compradores del producto o servicio.
La intención de participación como inversionistas de proveedores de insumos.
Nivel de cubrimiento de las garantías.
Solvencia de las partes interesadas en la compra del producto o servicio manifiesta en la
suscripción de sólidos contratos de compra de mediano y largo plazo.

El nivel de apalancamiento corresponde a un equilibrio entre la capacidad del proyecto de

convocar y emplear recursos ajenos y la posibilidad real de pagarlos con los flujos derivados de la
operación. Un apalancamiento exagerado pone en peligro el proyecto al no producir los flujos
suficientes que requiere el servicio de la deuda, pero el no aprovechar adecuadamente la
capacidad de endeudamiento puede acarrear, al mismo tiempo, costos de oportunidad. En
resumen, la capacidad de endeudamiento corresponde al nivel de deuda que el proyecto es capaz
de servir por completo durante el periodo de amortización del préstamo. Se suele calcular a partir
del flujo de efectivo descontado año por año.

Se trata pues de establecer la cantidad máxima de apalancamiento a la cual se puede

acceder, teniendo en cuenta las características financieras del proyecto y las condiciones
establecidas por los prestamistas. Uno de los trabajos que deben realizar los asesores financieros
de los propietarios del proyecto o de los gestores del mismo, es la elaboración de modelos que
garanticen la inclusión de toda clase de variables pertinentes relacionadas con los flujos de caja
previstos en diferentes escenarios, que permitan argumentar válidamente ante los prestamistas
las solicitudes de crédito correspondientes, basadas en la capacidad de endeudamiento. La
experiencia y el conocimiento de estos expertos permiten valorar diferentes paquetes de
financiación que brinde el costo de capital más atractivo, asumiendo diferentes niveles de riesgo.

Aplicación de capital propio como garantía de la solvencia del proyecto: el programa de

utilización de fondos a largo plazo debe concordar con las erogaciones necesarias para la
construcción, instalación y puesta en marcha. Los prestamistas suelen ser un tanto desconfiados
y requieren que los patrocinadores o propietarios y los inversionistas de capital apliquen una
cantidad significativa de recursos a la inversión inicial (como prueba de confianza en su propio
negocio) antes de comenzar a irrigar el proyecto con sus recursos. Este requisito asegura que los
prestamistas, propietarios e inversionistas de capital adquieren un compromiso firme desde los
primeros momentos.

Estimación del flujo de caja periodo por periodo: desde luego, que un plan financiero
técnicamente concebido debe compaginar armónicamente la necesidad de recursos financieros
para realizar las diferentes actividades y los flujos de ingresos derivados de los compromisos
acordados con prestamistas e inversionistas, de lo contrario el proyecto tendrá que apelar a
financiaciones costosas de corto plazo. En principio la información financiera derivada de los
estudios de factibilidad suele presentarse en períodos anuales, sin embargo, los asesores de
las partes tendrán que corroborar en escala mensual o semanal según el caso, el comportamiento
de los flujos de caja.

Selección de monedas para financiar el proyecto: cuando se acuerda recibir dinero por
concepto de aporte o crédito o recursos originados en las ventas, y también se acuerda el pago
de acreencias en diferentes monedas se puede incurrir en un riesgo de tipo de cambio que es
 preciso mitigar, por esa razón, los patrocinadores o propietarios negociarán basados en algún
modelo multimoneda que mitigue y controle este riesgo.

Estimación del horizonte del proyecto o su vida útil: es claro que el vencimiento de la
deuda de un proyecto no debe exceder su vida útil. Algunos proyectos de extracción de minerales
o petróleo, según la tasa de producción pueden determinar con precisión su vida útil y ajustar a
propósito el esquema de financiación. Si bien es cierto que el gerente del proyecto solamente
tiene que preocuparse por los sucesos de todo orden acaecidos durante la ejecución, también es
cierto que además de la nueva capacidad instalada, el gerente es responsable de entregar al
operador unas finanzas sanas, respaldadas por una capacidad de producción o de prestación de
servicios que genere recursos suficientes para atender las acreencias originadas en las
grandes inversiones de la ejecución.

De lo anterior se desprende que el dimensionamiento del monto requerido, la estimación del grado máximo de
apalancamiento soportable, la disponibilidad de recursos propios como garantía de solvencia y seriedad, la
estimación detallada de flujos de caja a escala mensual, la selección de monedas fuertes para recibir y
entregar recursos, y la estimación rigurosa del horizonte del proyecto y su vida útil son argumentos que es
preciso analizar para garantizar un cierre financiero confiable y exitoso.

La Función Financiera en la Ejecución del Proyecto

Dentro del concepto de proyecto en ejecución la función

financiera ocupa un lugar estratégico, cuyo objetivo principal
es utilizar toda su capacidad operativa y analítica para
atender eficientemente a sus "clientes internos", vale decir, su
respaldo oportuno y eficaz a las áreas de producción,
recursos humanos, procedimientos administrativos y
adquisiciones.

Las principales tareas encomendadas a la función financiera

son las siguientes:

 Elaboración y proyección de presupuestos y flujos

de fondos acordes con las diferentes actividades
programadas.

 Fijación de políticas en torno al comportamiento de

los activos: en cuanto a los circulantes, definiendo procedimientos con respecto a caja y bancos y al
control de los inventarios. En lo que respecta a los activos fijos, se tendrá que definir procedimientos
de depreciación con fines contables y tributarios, y en lo tocante a los activos diferidos, se definirán
las normas que rigen los procesos de amortización.

 Definición y planeación de la estructura de endeudamiento 2: la función financiera debe buscar un

permanente equilibrio entre los niveles de endeudamiento y la solidez y autonomía del proyecto; en
efecto, la utilización intensiva del crédito mejora la rentabilidad, siempre que su costo sea inferior al
rendimiento, por eso se suele afirmar que en las circunstancias anotadas "mayor apalancamiento"
beneficia a la empresa propietaria del proyecto; sin embargo, se precisa de una actitud ponderada al
respecto, ya que un exceso de endeudamiento apareja cuotas mayores para el cubrimiento del
servicio de la deuda (capital más intereses), que deberán ser respaldadas desde luego, por mayores
niveles de ventas cuya responsabilidad es ajena a la diligencia del gerente del proyecto.

 Por otro lado, la imagen de solidez corporativa se resentirá y la confianza por parte de terceros
(bancos y corporaciones) también se afectará, pero además la autonomía de la firma y su operación
podrá quedar comprometida.

 Si bien es cierto que la política de financiamiento la define la empresa matriz, los directivos del
proyecto decidirán si acuden directamente al mercado de capitales con la emisión de bonos, o si se
aproxima al ahorro primario mediante la colocación de acciones. Debemos insistir en que los
recursos propios tienen un "costo de oportunidad" cuya estimación es una de las tareas primordiales
y permanentes de la función financiera.
 La asunción de compromisos financieros con agencias, bancos, fabricantes y proveedores
nacionales e internacionales requiere estudio, organización y notable trabajo de detalle para
consolidar y apuntalar los contratos correspondientes y el cierre financiero. Cabe anotar que entre las
cartas de intención y los primeros giros pueden transcurrir algunos meses especialmente si se trata
de agencias internacionales que exigen autorizaciones y avales de parte de las respectivos
gobiernos o entidades nacionales, lo cual supone por parte del proyecto contar con profesionales con
conocimiento e iniciativa para garantizar la culminación exitosa de los diferentes trámites.

 Esta función se encarga también de las operaciones financieras de rutina que hacen referencia a un
cúmulo de actividades cotidianas programadas, y otras imprevistas o accidentales, que desarrolla el
equipo de tesorería como: la tarea diaria de revisar las disponibilidades y requerimientos de fondos;
ordenar traslados, consignaciones y pagos; la elaboración de los presupuestos de caja semanales; el
manejo de las cuentas corrientes; instrucciones de remesas de fondos, compras de divisas, giros al
exterior para cumplir compromisos programados; negociación y apertura de créditos; documentación
de garantías, colocación y pago de pólizas de seguros, entre otras.

 Garantizar la elaboración oportuna y confiable de los estados financieros y sus análisis

correspondientes.

 Estudio y colocación de pólizas de seguro que garanticen su cabal cubrimiento en todo tipo de
riesgos.

 Elaboración de listados actualizados de los bienes del proyecto que pueden servir de garantía ante
terceros. Es claro que entre más avance la ejecución, el patrimonio del proyecto se irá
incrementando y por ende su capacidad de respaldar acreencias.

 Adelantar las estrategias adecuadas de cubrimiento del proyecto en ejecución en contra de los
procesos de devaluación e inflación.

 La política financiera está afectada continuamente por situaciones no financieras, como: el

comportamiento del mercado tanto de insumos como de productos, los cambios continuos de la
legislación (comercial, laboral, de comercio exterior, de aduanas, etc.), los desarrollos tecnológicos,
los riesgos políticos, etc., que se deben tener en cuenta en el momento de hacer los presupuestos de
corto y mediano plazo.

 Una de las tareas más importantes de la administración financiera del proyecto son las tareas de
control de las fuentes y usos previstos en el plan, y las exigencias surgidas de la misma dinámica de
la ejecución del proyecto. El control de las fuentes se ocupa de la magnitud de los desembolsos, del
cálculo de intereses, comisiones, primas de compromiso y de riesgo, saldos por utilizar y todas las
relaciones financieras contractuales con los proveedores. El control de usos, corresponde al registro
del flujo de caja por rubros diferenciales y en alguna medida a la comprobación física de su
aplicación según lo convenido en la programación respectiva.

 En resumen la función financiera incluye todas las acciones encaminadas a determinar el nivel de
recursos necesarios, su distribución entre los distintos usos, y localización y ponderación de fuentes
para garantizar la ejecución del proyecto.
 Aplicación Práctica de la Técnica del Valor Ganado con Software
 Por Ricardo Villarroel Carriel, PMP® [ Acerca del autor]
 Siglas como EAC, SAC, CPTP, IDA, BCWP, AC, SV, IRC, BAC y muchas más son términos
recurrentes cuando se pretende usar la Técnica del Valor Ganado o Earned Value, lo que en primera
instancia daría la impresión de ser una herramienta muy compleja, y por lo tanto, aleja a los
potenciales interesados en usarla.
 Lo anterior proviene de que se puede encontrar que en algunos libros en español se usa terminología
en inglés (formato antiguo y actual) y en otros se puede notar que se utiliza terminología en español.
Por lo tanto, se tienen dos y hasta tres formas para reflejar el mismo parámetro.
 Por ejemplo, para indicar el índice de atraso o adelanto en la programación se puede encontrar con:
SPI (Schedule Performance Index), IRP (Índice de Rendimiento de Programación) e IDA (Índice de
Desempeño de Agenda).
 Pues bien, a pesar de que son muchos parámetros con los que se puede encontrar, los conceptos
son sólo tres que se combinan y los software de programación los usan.
 Para explicar como los software usan esta técnica, imagine una tarea de 10 días con un recurso a 8
horas diarias y con un costo de $100/hora y que se planifica con un comportamiento normal, es decir,
al final del tercer día habrá avanzado un 30%.

Obviamente, hay tareas que no tienen este comportamiento, pero lo que nos interesa es el
comportamiento del proyecto como un todo, a nivel de resumen del proyecto, por lo que las pocas
tareas de comportamiento anormal tienen una baja ponderación en el resultado global del proyecto,
dado que debiera existir una gran cantidad de tareas de comportamiento normal.
 Lo más probable es que el avance a cierta fecha de control sea inferior a lo programado y los costos
sean superiores a lo presupuestado.
 Imagine entonces que ahora estamos parados al final del día 4, que el avance fue sólo de un 30% y
el costo real fue de $ 110/hora (aquí presumimos órdenes de cambio aprobadas).


 Ahora podemos calcular:
 1. Al final del día 4 debiera hemos avanzado un 40% y hemos gastado (40%*80h)*$100/h=$3,200
2. Para un avance real de 30% debiera haber gastado (30%*80h)*$100/h=$2,400
3. Para este avance de 30% gasté realmente (30%*80h)*$110/h=$2,640
4. Por simple regla de tres el proyecto demorará 13,3 días o 10d/(2,400/3,200)
5. Por simple regla de tres el proyecto costará $8,800 o $ 8,000/(2,400/2,640)
 • Los $3,200 es lo que se llama Costos Presupuestado del Trabajo Programado (CPTP) o Budgeted
Cost of Work Scheduled (BCWS) o Planned Value (Valor Planificado).
• Los $2,400 es lo que se llama Costos Presupuestado del Trabajo Real (CPTR) o Budgeted Cost of
Work Performed (BCWP) o Earned Value (Valor Ganado).
• Los $2,640 es lo que se llama Costos Real del Trabajo Real (CRTR) o Actual Cost of Work
Performed (ACWP) o Actual Cost (AC).
 Hay algo que se asume en el cálculo anterior de 2 y 3 y que pasa desapercibido, cálculo que se hace
posterior al día de inicio del proyecto: se asume que se sabían cuántas horas duraba el proyecto y
que se sabía el costo presupuestado por hora. El avance real es una observación del momento y el
costo real es al momento de realizar el cálculo.
 Esta información que ya se conocía es la que requieren todos los software para poder trabajar con la
Técnica del Valor Ganado. Es la información de programación y presupuestación previa y que se
guarda en lo que se llama Línea de Base.
 Qué cuidados debemos tener:
 1. Hacer la programación desagregando hasta el nivel en que humanamente pueda llevar un control
(estimar un porcentaje de avance físico de la tarea y un costos real)
2. Generar la hoja de recursos con sus costos
3. Asignar los recursos a las tareas
4. Ajustar plazos y costos
5. GUARDAR LA LÍNEA BASE (que no es más que copiar esta información en paralelo para ocuparla
a futuro y compararla con lo real que voy ingresando en cada fecha de control)
 Una vez guardada la Línea de Base y de haber ingresado a la fecha de control el avance real por
tarea y el costo real por tarea, estamos en condiciones de pedirle al software cualquiera de los datos
siguientes:
 1. El índice de rendimiento de programación del proyecto
2. La duración estimada del proyecto
3. El índice de rendimiento de programación del proyecto para terminarlo dentro de lo programado
4. El índice de rendimiento de costos del proyecto.
5. El costo estimado del proyecto.
6. El índice de rendimiento de costos del proyecto para terminarlo dentro de lo presupuestado.
7. Otros
 Es increíble como ingresando spolo 2 datos por tarea (avance y costo real) obtengo información
valiosa para tomar acciones correctivas en aquellas tareas que se están alejando de lo previsto.
 Estos análisis se deben hacer durante todo el proyecto, pero en particular al 5% de la duración del
proyecto, al 10% y al 15%. ¿Por qué?: son las instancias en que las buenas prácticas indica que
todavía puedo “enderezar” el proyecto. Si el cálculo lo hago más adelante y mis índices no son
buenos, difícilmente podré “enderezar” el proyecto, dado que si mi planificación no fue buena tan
cerca del inicio del proyecto, por qué debiera serlo más lejos del inicio del proyecto?. De otra forma,
si no veo bien a 10 metros, no puedo pretender ver bien a 1000 metros.
 En resumen, esta técnica utiliza sólo 3 conceptos claves:

1. Costo Presupuestado del Trabajo Programado (CPTP) o Budgeted Cost of Work Scheduled
(BCWS) o Planned Value (Valor Planificado).
2. Costo Presupuestado del Trabajo Real (CPTR) o Budgeted Cost of Work Performed (BCWP) o
Earned Value (Valor Ganado).
3. Costo Real del Trabajo Real (CRTR) o Actual Cost of Work Performed (ACWP) o Actual Cost (AC).
 Los combina como se muestra a continuación y entrega información del estado del proyecto a la
fecha de control y el comportamiento que tendrá el proyecto a futuro si no se toman acciones
correctivas (si no tratamos de “enderezarlo”). Esta información los software la entregan a nivel de
tareas, fases y proyecto.
 Un punto importante: las fases o tareas de resumen son tareas de resumen de tareas, por lo tanto,
para que no correr el riesgo de duplicar costos, no hay que asignar recursos a las tareas de resumen.
Las tareas de resumen son eso: de resumen y aglutinan ponderando adecuadamente las tareas
anidadas.

PARÁMETROS DE LA TÉCNICA DEL VALOR GANADO

CPTP Costo Presupuestado del Trabajo Programado
BCWS Budgeted Cost of Work Scheduled
PV Planned Value
CPTR Costo Presupuestado del Trabajo Realizado
BCWP Budgeted Cost of Work Performed
EV Earned Value
CRTR Costo Real del Trabajo Realizado
ACWP Actual Cost of Work Performed
AC Actual Cost
CRONOGRAMA
Variación de
VP CPTR-CPTP
Programación
 Scheduled
SV EV-PV BCWP-BCWS
Variance
% de Variación
%VP (VP/CPTP)x100%
de Programación
Índice de
IRP Rendimiento de CPTR/CPTP
Programación
Índice de
IDA Desempeño en CPTR/CPTP
Agenda
Schedule
SPI Performance EV/PV BCWP/BCWS
Index
Duración
DPF Prevista a la
Finalización
Schedule At
SAC
Completion
Duración
Estimada a la
DEF DPF/IRP
Finalización
(SMC)
(Time) Estimate
(T)EAC SAC/SPI
At Completion
Variación (de
(T)VAF Tiempo) A la DPF-DEF
Finalización
(Time) Variance
(T)VAC SAC-TEAC
At Completion
Índice de
Rendimiento de (CPF-CPTR)/(CPF-
IRPPC
Programación CPTP)
Para Completar
Schedule
(BAC- (BAC-
Performance
SPITC EV)/(BAC- BCWP)/(BAC-
Index To
PV) BCWS)
Complete
COSTO
Variación de
VC CPTR-CRTR
Costo
CV Cost Variance EV-AC BCWP-ACWP
% de Variación
%VC (VC/CPTR)x100%
de Costo
IRC Índice de CPTR/CRTR
 Rendimiento de
Costo
Índice de
IDC Desempeño en CPTR/CRTR
Costos
Cost
CPI Performance EV/AC BCWP/ACWP
Index
Costo Previsto a
CPF
la Finalización
Budget At
BAC
Completion
Costo Estimado
CEF a la Finalización CPF/IRC
(SMC)
(Cost) Estimate
(C)EAC BAC/CPI
At Completion
Variación (de
(C)VAF Costo) A la CPF-CEF
Finalización
(Cost) Variance
(C)VAC BAC-EAC
At Completion
Índice de
Rendimiento de (CPF-CPTR)/(CPF-
IRCPC
Costo Para CRTR)
Completar
Cost
(BAC- (BAC-
Performance
CPITC EV)/(BAC- BCWP)/(BAC-
Index To
AC) ACWP
Complete

Caso del sector minero peruano

Análisis de costo/beneficio como una
herramienta de Administración de Proyectos

Por José Carlos Machicao Valencia, PMP® [ Acerca del autor]

Durante las últimas décadas, el sector minero en el Perú ha crecido continuamente, principalmente debido al
incremento precios internacionales de los minerales, lo que ha desencadenado un acento en la exploración y
consecuentemente un aumento en el descubrimiento o reactivación de zonas enormemente rentables. En
paralelo con este proceso, el Perú ha estado envuelto en un proceso de descentralización del Estado, que ha
retado al Estado Nacional a transferir efectivamente las funciones a otros niveles de gobierno sub-nacional,
tales como los Gobiernos Regionales1 y Gobiernos Locales. Este aspecto ha cobrado particular importancia
debido a que, de improviso, las abundantes inversiones mineras empezaron a elevar el nivel de demanda de
servicios de parte del Estado Nacional, al mismo tiempo que éste estaba tratando de organizar el
conocimiento mínimo para transferirlo a los Gobiernos Regionales y Locales.

Para poder tener una perspectiva de qué actores intervienen en el sector minero nacional, es necesario
conocer a los tres grupos principales: el sector privado (integrado por inversionistas, operadores mineros,
proveedores del mercado minero, entre otros), la sociedad civil (comunidades nativas, organizaciones de
interés social, organizaciones no gubernamentales, sindicatos de trabajadores, entre otros), y el Estado
(Gobierno Nacional, Ministerio de Energía y Minas, Gobiernos Regionales, Gobiernos Locales, reguladores,
entre otros). Todos estos actores involucrados tienen diferentes intereses en el sector minero, pero la visión
común es todavía un asunto pendiente. Lo que ha ocurrido durante la última década es que mientras el sector
minero ha crecido en volumen e influencia en la economía peruana, cada actor (o grupo de actores) ha
actuado de acuerdo a una visión propia.

Las corporaciones mineras empezaron a invertir siguiendo sus propias reglas para su establecimiento en el
país, construyendo su propio tipo de relación con las comunidades alrededor de los proyectos mineros, y
siguiendo las regulaciones ambientales de sus estándares internacionales (puesto que la mayoría de
empresas mineras son inversiones externas), usualmente debido a la carencia de suficientes regulaciones
peruanas. Por su lado, las comunidades en los alrededores de los proyectos mineros empezaron a entender
el crecimiento de la actividad minera como una amenaza contra la actividad económica local (agricultura,
pesca, comercio de pequeña escala, minería de pequeña escala), y debido a algunos errores (a veces graves
y con impacto en la calidad de vida de los pobladores) de algunas de las corporaciones mineras, la hostilidad
de los actores sociales creció contra las actividades mineras en general.

En cuanto a los actores gubernamentales y el Estado en general, el problema fue, sobre todo al inicio, el
excesivo enfoque en los problemas de corto plazo solamente: el Gobierno Nacional se centró en resolver
conflictos puntuales entre las corporaciones mineras y las comunidades de los alrededores, cohibiendo el
enfrentamiento, pero sin mucho éxito en reparar la imagen de la actividad minera, aunque con fuerte
intensidad en la creación o mejoramiento de las regulaciones ambientales y de seguridad, para orientar el
comportamiento de las corporaciones.
El comienzo de una solución real se concretó cuando los sectores público y privado se hicieron conscientes
de las diferencias entre sus visiones: el sector privado necesitaba tener un contexto cómodo para invertir en
los proyectos mineros, con estabilidad jurídica, y los actores sociales necesitaban tener seguridad personal y
operativa alrededor de las áreas de los proyectos mineros, asegurando su salud y la calidad del medio
ambiente. Al mismo tiempo, el Estado reconoció que necesitaba una visión para su papel dentro del sector
minero, asegurando la habilidad de convertir la inversión minera en desarrollo local, regional y nacional. La
habilidad de estos tres involucrados principales (sociedad civil, Estado y sector privado) dentro del sector
minero, para reconocer sus diferencias entre las visiones particulares, ha permitido que encuentren una visión
común con base en aspectos comunes entre las tres visiones.

Todos los actores han sido gradualmente incorporados en un diálogo (ciertamente difícil especialmente por lo
nuevo) acerca de cuáles son los beneficios de las actividades mineras y cuáles son los costos de la minería
para cada uno de ellos. Esto ha permitido progresar en la identificación de casos tales como el enorme interés
de muchas corporaciones mineras en la protección ambiental debido a que éstas han descubierto el enorme
prestigio global e imagen positiva que se genera cuando se contribuye de manera verificable al desarrollo
económico y social de las comunidades locales y del país donde se invierte, encontrando más opciones de
financiamiento para hacer más inversiones y descubriendo que el costo de trabajar en un ambiente no
conflictivo es mucho menor al costo de trabajar en un entorno con conflictos.

Las comunidades también entienden que priorizar el diálogo con las corporaciones en lugar de siempre
recurrir a la protesta o las medidas de fuerza en primer lugar, pueden tener más autoridad para poder decidir
sobre los montos de apoyo de parte de las corporaciones y sobre los alcances en los cuales invertir,
reforzando la capacidad de producir de la misma manera que venían produciendo de tal manera que no se
causa disrupciones culturales en la economía local, pero se accede ordenada y progresivamente a mayores
volúmenes y opciones de mercados para un desarrollo integral. El Estado por su lado, entiende que muchas
de las políticas de desarrollo (educación básica local y programas de salud básica y preventiva) que son muy
difíciles de implementar sin apoyo social y con bajos recursos, encuentran más opciones de cofinanciamiento
con corporaciones privadas creando asociaciones público privadas en un entorno armónico con los actores
sociales.
El hecho concreto es que esta nueva forma de pensar (lo que podría llamarse una nueva cultura de gestión),
basada en herramientas adecuadas de análisis de costo/beneficio 2, permiten crear acuerdos entre el Estado
(como autoridad representante de la sociedad como un todo) y las corporaciones mineras. Esto ha sido inicial
pero exitoso en Perú, debido a que la administración pública (o por lo menos una gran cantidad de entidades
que han renovado su gestión) ha empezado a abrir su mente tanto como las corporaciones privadas más
lúcidas, así como los líderes comunales y nativos basados en sus intuiciones culturales de gestión de sus
comunidades (aun cuando probablemente los documentos técnicos recién empiezan a reconocer los enormes
avances en gestión integral de muchas de las comunidades nativas o rurales), apostando a visiones
aterrizadas, integrales y de más largo plazo.

Operativamente, las tareas principales en las cuales las corporaciones y el Estado han estado participando en
conjunto han sido3: (i) el mejoramiento de la infraestructura del Vice Ministerio de Minas para procesar el
registro y la información recolectada acerca de las actividades mineras y todos los procesos de aprobación
alrededor de ellas, (ii) el mejoramiento de los procesos mismos y los servicios de parte del Estado a las
comunidades, ciudadanos y corporaciones (reingeniería), (iii) el mejoramiento de las regulaciones y normas,
así como la capacidad de monitoreo del cumplimiento de estas y (iv) la capacidad de abrir procedimientos
para hacer más flexibles los acuerdos de financiamiento para la implementación de políticas de desarrollo
sostenible, especialmente en las comunidades locales alrededor de los campamentos mineros 4.

Sin embargo, el impacto logrado todavía no es suficiente. El nivel de conflicto entre las corporaciones y
comunidades todavía es importante aunque sea menor en el Perú. La legislación todavía está más enfocada
en los procesos técnicos de minería y necesita ser más precisa en los mecanismos de “aterrizaje” de las
corporaciones en el territorio de explotación y más detallada en las relaciones con las comunidades y los
actores sociales, además de instructiva en la relación con todos los niveles de gobierno. Mucho más se
requiere hacer sobre la comunicación para todos los actores, particularmente contra el enorme
desconocimiento que todavía hay de cuál es el rol del Estado, cuál de la empresa, cuál el de los actores
sociales, además de identificar, discutir, acordar, y difundir cuáles son los deberes de cada uno. El nivel de
protección ambiental es mejor que la década pasada pero todavía muchos ciudadanos están fuertemente
afectados por la polución y algunas corporaciones son más que negligentes acerca del cumplimiento de la
legislación existente, sin contar la existencia y proliferación de pequeños productores mineros informales sin
mucha capacidad de monitoreo de su impacto.
Una de las tareas más importantes, pero tal vez menos visibles, es definir y escribir formalmente la visión de
cada uno de los actores, y finalmente la visión conjunta de la minería peruana (sector minero peruano). Aún el
Gobierno Nacional necesita entender que las actividades mineras sólo son la expresión más concreta de un
sistema mucho más complejo, que necesita ser entendido y definido como un sistema de “producción” de
desarrollo sostenible, y necesita usar todas las herramientas de gestión disponibles en el mercado, tales como
la estructuración de visión, el análisis de costo/beneficio alrededor de la visión definida, el desarrollo de
programas de mejoramiento y mucho más importante, la habilidad de comunicar resultados a los ciudadanos y
corporaciones, acerca del avance en la construcción de la visión planificada. En pocas palabras, el Estado
debe desarrollar y traducir las mejores prácticas de gestión de proyectos para aplicarlos a un “proyecto”
grande y complejo en el cual la visión común sea el “alcance” y la construcción una “operación” de desarrollo
sostenible basada en las actividades mineras sea la tarea principal.

Si todos los niveles del Estado (pero con el liderazgo del Estado Nacional) no comprenden que el
mejoramiento y clarificación de las visiones es una función del Estado, no podrá alentar la definición de una
visión conjunta, y estará siempre atareado con la resolución de conflictos de corto plazo entre las partes. Si
todos los niveles del Estado participan activamente en el proceso de reconocimiento, construcción,
mejoramiento y comunicación de la visión, no serán capaces de tomar las decisiones correctas. Si la visión del
sector minero peruano es finalmente definida, cada ciudadano, cada corporación y cada agencia de gobierno
serán más exitosos en la contribución a dicha visión común. En el Perú, esperamos que las herramientas de
gestión disponibles5 contribuyan a acelerar la mejora de la comprensión de un cambio de variables de
medición del estado del sector minero: debemos abandonar las variables que miden como éxito estatal el nivel
de exportaciones de mineral o la cantidad de conflictos resueltos, se debe definir indicadores de desarrollo
(satisfacción sostenible) de los ciudadanos y corporaciones en climas de mayor diálogo y construcción
conjunta: todo un reto de las herramientas de gestión.
_____________________________

1 Perú tiene 25 regiones internas y 1830 municipios (gobiernos locales)

2 El análisis adecuado del costo/beneficio se diferencia del análisis costo/beneficio simple debido a que el
primero incluye factores de desarrollo sostenible y no solamente balances monetarios. Si bien es cierto al final
del cálculo el análisis adecuado de costo/beneficio arrojará un balance financiero, el cuidado puesto en la
monetarización de los conceptos ayudará a no restringirse a un simple criterio de rentabilidad.
3 Ministerio de Energía y Minas: http://www.minem.gob.pe
4 Muchas de las mejoras implementadas entre el año 2000 y 2008 han sido alentadas o desarrolladas por el
Proyecto PERCAN (http://www.percan.ca), iniciativa de la Cooperación Técnica Canadiense en el Perú
5 La mayoría de herramientas de gestión aludidas en este artículo están publicadas en el sitio web de la
Metodología GOAL©, Gestión Organizacional de Acciones y Logros: http://www.metodologiagoal.7p.com

Gestión de Calidad

El seguimiento del proyecto:

En Dios confiamos, los demás traigan sus datos
Por Sergio Orozco

Imagina el plan de proyecto perfecto, un plan basado en necesidades y objetivos reales y precisos de tu
cliente y usuarios, una estimación con técnicas formales basadas en estadísticas de productividad de tu
equipo y empresa, y un equipo de trabajo sumamente capaz. Todo parece perfecto, no hay razón alguna por
la que este proyecto pudiera fallar, ¿o si?

Planear no es todo

Malas noticias, tu proyecto podría fallar a pesar de las ventajas de lo mencionado anteriormente. Si tú, como
líder de proyecto, no eres capaz de mantener una clara y precisa visión con respecto a la situación real del
proyecto en todo y cada momento, y/o si no eres capaz de reaccionar oportunamente y de manera eficaz ante
las desviaciones del proyecto, éste podría ser parte de las estadísticas de proyectos fallidos.

Para mantener esa visibilidad sobre lo que ocurre en el proyecto necesitas contar con información precisa de
lo que está ocurriendo en todo momento. Es mejor escuchar al padre de la calidad, Deming, cuando dice “En
Dios confiamos, los demás traigan datos”. Ten cuidado si piensas confiar en un simple “vamos bien”, como
respuesta por parte de tus recursos cuando te reportan el estado del proyecto.

Parámetros de control

Es conveniente ponernos de acuerdo en el significado del concepto “proyecto fracasado”. Normalmente nos
hace pensar en proyectos que terminan en situaciones como las siguientes:

 No incluía todas las características que el cliente quería

 No le resolvió al cliente sus necesidades
 No alcanzó el dinero para pagarlo
 No se terminó cuando se esperaba

Es decir, nos referimos a que alguno(s) de los parámetros básicos de planeación y control del proyecto no se
cumplió, por ejemplo alcance, tiempo o costo.

Así que si piensas que ser líder de proyecto se limita a identificar el objetivo del proyecto, armar el equipo,
girar instrucciones y confiar en que tu equipo las va a seguir al pie de la letra, permíteme decirte que estás
equivocado. Es muy importante hacer todo eso, pero tu plan puede empolvarse y descomponerse más pronto
de lo que te imaginas si no tienes el cuidado necesario para que éste se cumpla. Es aquí donde entra la
actividad conocida como SEGUIMIENTO o MONITOREO del proyecto.

¿Y a qué se refiere este seguimiento o monitoreo del proyecto? Va mucho más allá de simplemente
asomarse a ver cómo van las tareas asignadas.

De acuerdo a ciertas definiciones formales, el seguimiento del proyecto consiste en:

Proveer una adecuada visibilidad a la administración sobre la situación del proyecto para identificar
oportunamente cualquier desviación contra lo planeado con el objetivo de tomar decisiones oportunas para
corregirlas.

Visibilidad

Tú, como líder o administrador del proyecto eres responsable de conocer en todo momento qué pasa con el
proyecto; a eso se refiere la visibilidad. Para lograr esto debes de mantenerte muy atento a todo lo que
sucede en el proyecto, debes realizar las preguntas adecuadas a los participantes y buscar y analizar los
datos importantes del mismo.

Preguntas a resolver

Algunas preguntas fundamentales que debes poder contestar:

 ¿Cuál es el avance en las tareas de los recursos contra lo planeado? (cuánto deberían de haber
logrado hasta ahora y cuánto han logrado)
 ¿Cuál es la desviación en tiempo de las tareas? (y del proyecto)
 ¿Cuál es la desviación en costo de las tareas? (y del proyecto)
 ¿Cuánto más se va a desviar el proyecto considerando el nivel de retraso que se está teniendo en
las tareas? (te recomiendo que leas acerca de técnicas como valor devengado o “earned value”)
 ¿Cuál es la desviación en rentabilidad del proyecto?
 ¿Cuáles y cuántos han sido los cambios al alcance original del proyecto?
 ¿Se están logrando los objetivos del proyecto?

No permitas que aumente la desviación

Cuando identifiques las desviaciones hazlo con las unidades de medición correspondientes, tales como
tiempo de retraso, dinero, funciones o características, pero también hazlo en porcentaje para cada uno de
estos parámetros. Identifica el porcentaje de desviación de lo real contra lo planeado para poder identificar si
hay una oportunidad real de corregir el camino y alcanzar el objetivo del proyecto de manera exitosa.

Es importante saber que el proyecto ya se retraso 5 días, pero también debes de saber si eso implica un 5%
de desviación o un 50% de desviación contra lo planeado. Es importante saber si el proyecto tiene una
desviación de $ 70,000 en costos, pero también es muy importante si eso representa un 2% del proyecto o un
80%. La diferencia entre mantener tu trabajo o ser despedido del proyecto, podría recaer en este “simple”
hecho .

Frecuencia del monitoreo

Entre más pronto identifiques las desviaciones del proyecto, más factible será corregirlas. Es por eso que
debes de buscar y analizar los datos con la suficiente frecuencia. La recomendación es que por lo menos una
vez a la semana realices las actividades de seguimiento para tu proyecto.

Aunque, si notas que las cosas se están poniendo feas en tu proyecto, aumenta la frecuencia con que realices
el seguimiento. Quizás tengas que estar revisando con detalle el estado del proyecto todos los días, o incluso
varias veces al día, para evitar que las cosas se pongan peor.
Créeme, si las cosas se pueden poner mal, hay grandes probabilidades de que así sea. Pero, además,
siempre se pueden poner peor. Así que es mejor hacer algo para evitar que esto suceda.

Técnicas de seguimiento

¿Y cómo deberías de realizar el seguimiento? A continuación las técnicas básicas que normalmente
utilizamos para este fin:

1. Reuniones. Reuniones con el equipo de trabajo de manera grupal y/o individual para revisar el
progreso de su trabajo.
2. Revisiones. Revisiones de los productos elaborados de acuerdo al plan de trabajo para validar que
los avances sean reales y los productos tengan la calidad suficiente como para considerarlos
completados.
3. Reportes. Reportes individuales de los integrantes del equipo de acuerdo a una frecuencia
especificada (por ejemplo: semanal o diaria)
4. Software de Administración. Reportes de los avances y el trabajo realizado por medio de alguna
herramienta de planeación y administración de proyectos.

Evita la burocracia documental

La gente en los proyectos suele odiar la documentación y por lo tanto los reportes, pero si no tenemos
información precisa será más difícil identificar oportunamente las desviaciones del proyecto y por lo tanto
aumentará el riesgo de fracaso en el proyecto. Conviene que el equipo se acostumbre a reportar la situación
del proyecto y tú, como líder de proyecto, a revisarla y analizarla. En este caso un documento puede hacer la
diferencia entre un proyecto exitoso y uno que no lo es.

Lo desafortunado del asunto es que los reportes generados suelen representar burocracia que en lugar de
beneficiar ocasiona pérdida de tiempo. No es necesario contar con una plantilla o formato sumamente
elaborado y complicado de llenar para obtener un reporte útil. Lo importante está en identificar y reportar
claramente la información valiosa con respecto a la situación del proyecto.

Si tienes los recursos económicos para invertir en una buena herramienta de software para controlar los
proyectos y explotar la información, entonces te recomiendo que la adquieras. La automatización puede
ahorrarte una buena cantidad de esfuerzo y dinero en reportar la información del estado de tu proyecto.

¿Qué debería de incluir un reporte de estado del proyecto?

Para obtener un reporte valioso tenemos que recordar cuáles son los parámetros que hacen de un proyecto
algo exitoso (si se cumplen) o que lo convierten en un fracaso (si no se cumplen). Y usar esos parámetros
como los elementos o secciones a reportar.

Recomiendo que por lo menos se incluyan estas secciones, puede ser un documento formal, una herramienta
que automatice la explotación de los datos del proyecto o simplemente un correo electrónico, pero asegúrate
que tenga por lo menos esta información:

 Progreso. ¿Ya terminamos lo que teníamos que terminar a la fecha? ¿cuánto no falta? ¿cuánto se
ha retrasado? ¿en qué se ha retrasado? ¿por qué nos hemos retrasado?
 Alcance. ¿Se identificó lo que se requiere hacer? ¿ha pedido cambios el cliente? ¿se han negociado
los cambios? ¿el cliente va a pagar los cambios? ¿cuánto ha cambiado el alcance original?
 Tiempos. ¿Cuál es el retraso del proyecto en tiempo y porcentaje? ¿cuál ha sido el cumplimiento de
los hitos (milestones) del proyecto? ¿cuál es el retraso del proyecto?
 Costos. ¿Cuánto se ha gastado? ¿cuánto se debería de haber gastado? ¿cuánto se va a gastar?
¿nos va a alcanzar?
 Rentabilidad. ¿estamos ganando lo que queríamos? ¿estamos perdiendo? ¿cuánto estamos
ganando o perdiendo? ¿cuánto vamos a ganar o perder si seguimos así?
 Riesgos. ¿Cuáles son los principales riesgos? ¿qué vamos a hacer para eliminarlos?
  Problemas. ¿Cuáles son las situaciones problemáticas actuales? ¿Qué se está haciendo para
resolverlas?
 Calidad. ¿Se está obteniendo el producto que el cliente quiere y necesita? ¿cuántos defectos
tenemos? ¿cuáles son los principales defectos? ¿se están cumpliendo los estándares? ¿el cliente
está quedando satisfecho con los resultados?
 Recursos Humanos. ¿Tenemos a la gente adecuada? ¿contamos con los suficientes recursos?
¿hay recursos problemáticos?
 Recursos Materiales. ¿Tenemos lo necesario para trabajar?

Toma de decisiones

Si consigues mantenerte informado oportunamente de lo que ocurre con el proyecto ¡felicidades! llevas la
mitad del camino recorrido para realizar un buen seguimiento. Pero, no te confíes, no por tener esta
información significa que saldrás airoso en el proyecto. Para lograrlo, además requieres tomar buenas y
oportunas decisiones. Es con esas decisiones donde se decide el temple y la efectividad del líder.

El liderazgo y la toma de decisiones

El seguimiento es otra oportunidad para demostrar el verdadero liderazgo de la persona que administra el
proyecto. Y es que una vez obtenida la información precisa con respecto al estado del proyecto y habiendo
identificado desviaciones contra lo planeado, lo que se requiere es TOMAR DECISIONES para corregir dichas
desviaciones.

El líder de proyecto debe analizar la situación, identificar las causas por las cuales el proyecto se enfrenta a
una desviación o situación problemática y plantear o buscar soluciones para resolverlo antes de que siga
ocasionando más desviaciones, retrasos o problemas.

Aquí de lo que se trata es de actuar, ¡y rápido! Recuerda que el tiempo es oro, y entre más tardes en resolver
las causas de los problemas las desviaciones seguirán aumentando y por lo tanto el éxito del proyecto se irá
alejando cada vez más de tu vista.

Si no actúas rápido el proyecto se retrasará más de lo que ya está, costará más de lo que ya está costando, y
tu cliente pensará dos veces antes de volver a contratarte.

Analiza y elimina las causas de las desviaciones

Recuerda analizar con cuidado y buscar las causas reales por las cuales el proyecto se está desviando de su
rumbo y entonces elimina dichas causas lo antes posible.

Como ejemplo, uno de los integrantes de tu equipo puede estar retrasándose porque:

 no tiene la información suficiente para trabajar (¡proporciónasela!)

 no entiende lo que se le está pidiendo (¡infórmaselo!)
 no sabe lo que se espera de él (¡díselo!)
 no se le han dado las instrucciones correctamente (¡instrúyelo!)
 no se le ha transmitido adecuadamente el plan (¡transmíteselo!)
 no se le asignan suficientes actividades (¡asígnaselas!)
 no comprende su lugar en el proyecto (¡explícale!)
 no cuenta con los recursos y herramientas necesarias (¡consígueselas!)
 no tiene las habilidades requeridas (¡capacítalo… o cámbialo!)
 no tiene una buena actitud o no está suficientemente interesado (¡habla con él y si no lo corrige
reemplázalo!)
 no está suficientemente motivado (¡motívalo!)
 está sobreexplotado y cada vez rinde menos (¡mándalo a descansar un tiempo!)
 no está trabajando en suficiente colaboración con el equipo (¡intégralo!)
Asumiendo responsabilidades

Uno, como líder del proyecto, es responsable de identificar correctamente las causas y tener la suficiente
madurez para asumir la responsabilidad de sus propias acciones. En muchas de las ocasiones los recursos,
por más buenos que sean, no reciben por parte del líder de proyecto todo lo que necesitan para poder
desempeñar adecuadamente su trabajo.

Puede sonar un poco agresivo, pero piénsalo dos veces antes de regañar (o castigar, penalizar, despedir,
etc.) a un recurso por no hacer su trabajo adecuadamente, pues podría ser que quien no está haciendo su
trabajo adecuadamente seas tú mismo; el líder de proyecto.

Recuerda que un carro de carreras sin alguien que lo maneje eficientemente nunca va a ganar una carrera, y
tú eres quien maneja este carro, si no tomas buenas decisiones en la pista, por más bueno que sea el motor,
las llantas y el resto de la maquinaria, nunca tendrás una carrera exitosa. Por más bueno que sea tu equipo, si
no lo administras y lideras adecuadamente no podrás llevarlos a un proyecto exitoso.

Recuerda que ser líder (administrador, gerente o director) de proyectos no consiste en sentarse en un trono
esperando a que sus súbditos cumplan con su trabajo y de vez en cuando le rindan homenaje. Ser líder de
proyecto significa que tienes que trabajar muy duro, y sobre todo muy inteligentemente para tomar decisiones
adecuadas en los momentos más oportunos.

Ser un líder de proyecto requiere ciertas habilidades, pero también conocimiento formal. Por lo tanto no
dudes en invertir en tu preparación. Una buena capacitación será la que te garantice el éxito en tu carrera
como administrador de proyectos. Cada vez son más las empresas que deciden dejar de tomar tantos riesgos
y contratar líderes de proyecto con preparación formal. Así que búscate un buen curso, asesoría o libro y
prepárate para tener una carrera exitosa como líder de proyecto. Sitios como liderdeproyecto.com son una
excelente fuente para encontrar opciones al respecto.

Seguimiento del Proyecto

El objetivo del seguimiento consiste en contar con una visibilidad adecuada en el progreso del proyecto para
que el administrador del proyecto y/o la gerencia responsable puedan tomar acciones correctivas cuando el
desempeño del proyecto se desvía de manera significativa del plan del proyecto.

El administrador del proyecto debe de reunirse con cierta frecuencia planeada (por ejemplo una vez a la
semana) con los miembros del equipo para comparar los avances contra lo planeado, identificar problemas
que pudieran poner en riesgo el proyecto y planear las acciones correctivas necesarias para garantizar el éxito
del proyecto.

Para contar con un proyecto exitoso es indispensable mantener un control o seguimiento a todos los
parámetros básicos del proyecto:

 Alcance. Cantidad y Estado de los requerimientos, número de cambios

 Tiempo. Cumplimiento de las fechas y retrasos contra lo planeado.
 Progreso. Avance real vs planeado, desviación de fechas compromiso dado el trabajo terminado,
productividad actual contra esperada, desviación proyectada.
 Costo. Costos reales vs planeados, rentabilidad planeada vs esperada, rentabilidad proyectada
 Calidad. Defectos, resultados de pruebas y revisiones, ritmo en que se han encontrado y corregido
los errores
 Riesgos. Número de riesgos, ritmo en que se han resuelto

El líder del proyecto debe enviar o presentar en una reunión un reporte del estatus del proyecto al gerente
responsable con información como la anteriormente mencionada. En dichas reuniones deben de revisarse los
planes, los cuales deben de actualizarse y en caso necesario realizar las correcciones necesarias para
corregir cualquier desviación.
Puede ser de bastante utilidad utilizar una herramienta de software para llevar el control de los avances y el
estado del proyecto. Esto facilita concentrar la información para que sea analizada con las personas
interesadas, como sería el gerente de proyectos y/o el cliente.

Aseguramiento de la Calidad

Por Norberto Figuerola, PMP® [ Acerca del autor]

“Quality control” y “Quality assurance” son conceptos muy importantes, a pesar de que muchos Project
Managers tienen sólo una vaga idea de qué significa cada uno y cuál es la diferencia entre ellos. Aquí
trataremos de explicar estos conceptos

Primero deberíamos definir que es Calidad:

La calidad es “la totalidad de las funciones y características de un producto o servicio que cumplen y
satisfacen las necesidades o requerimientos implícitos o explícitos del mismo” (ISO 9001:2000)

La calidad es “el grado en el que un conjunto de características inherentes cumple con los requisitos”
(American Society for Quality)

La Administración de la Calidad incluye la creación y seguimiento de políticas y procedimientos para asegurar

que el proyecto cumpla con los objetivos establecidos (sin desviarse de los requerimientos). Incluye las
actividades de Planificación, Aseguramiento y Control de la calidad.

La Gestión de la Calidad aborda tanto la Administración de Calidad del Proyecto (aplicable a todos los
proyectos) como a la Administración de la Calidad del Producto (específicas y particulares de cada producto).
De acuerdo al PMBOK®: “La gestión de Calidad Moderna complementa la Dirección de Proyectos y abarca
distintas disciplinas o industrias”

David Shuster en su libro “Teaming for Quality” nos dice sin embargo que la Administración de la Calidad no
es un subproceso del Project Management, sino que a su criterio son disciplinas gerenciales co-equivalentes.
Quality Management y Project Management comparten:

* Filosofías de gerenciamiento comunes

* Foco en el cliente, procedimientos y política
* Satisfacción de las necesidades y requerimientos del cliente
* Enfoque en la calidad de los procesos
* Principios de teaming (grupos de trabajo)
* Estructuras ordenadas, formales, documentadas, medibles

QM y PM se diferencian en que el enfoque de Project Management es temporario (finaliza con el proyecto)

mientras que el de calidad es mejora continua y permanente, a los efectos de este artículo podemos concluir
como resumen que “La Calidad es el grado en que el proyecto cumple con los requisitos”

El manejo y gestión de la calidad en el proyecto significa que se debe comprender las expectativas de calidad
del cliente y con ellas establecer un plan proactivo para cumplirlas. El Plan de Calidad contiene varios puntos
y actividades pero los más importantes son las tareas referidas a los procesos de Control de Calidad y
Aseguramiento de Calidad.

Control de calidad (“Quality Control”) se refiere a las actividades de calidad asociadas con la creación de los
entregables del proyecto. El control de calidad se utiliza para verificar y medir que el entregable tenga la
calidad aceptable y que está completo y correctamente finalizado. Ejemplos de acciones de control de calidad
incluyen las actividades de “Peer reviews” de procesos o tareas, los procedimientos de testing, mediciones e
inspecciones, entre otras
El Aseguramiento de la Calidad se refiere a los
procesos que se utilizan para generar los entregables.
Esta función puede ser ejecutada por el equipo de
trabajo, la Oficina de Administración de Proyectos o
terceras partes. Ejemplos de actividades de
aseguramiento de calidad incluyen los procesos de
checklists y las auditorías de calidad. Por ejemplo, si el
proyecto está siendo auditado por quality assurance, el
auditor podría no ser capaz de decir si el contenido
específico o resultado del entregable es aceptable o no
(quality control).

Sin embargo, el auditor debería ser capaz de informar

si el entregable podría considerarse aceptable basado
en el estudio de los procesos que se emplearon para
su construcción (quality assurance). Esa es la razón por la cual un auditor de proyectos o QA puede realizar la
revisión del mismo, a pesar de que no conozca en profundidad las características y especificaciones del
entregable. Él no puede medir la calidad del producto final, pero conoce qué tan bien o no fueron los procesos
que se ejecutaron para producir el producto del proyecto.

Un ejemplo sencillo extraído de un artículo publicado al respecto es el siguiente: Supongamos que el Líder de
Proyecto solicita al sponsor que apruebe el documento Requerimientos del Negocio del proyecto. ¿Si usted
fuera el sponsor coómo validaría que el documento es completo y correcto?

Una respuesta podría ser revisar el documento y validarlo con los requerimientos del negocio reales. Si opta
por esta solución estaría realizando una actividad de control de calidad, dado que sus acciones están
enfocadas en validar el entregable por si mismo.

Supongamos que el documento tiene muchas páginas y que usted como sponsor no tiene el conocimiento, el
tiempo o la intención de hacer una revisión de su contenido. En este caso usted podría preguntarle al
administrador del proyecto que le describa el proceso que utilizó para crear el documento. Supongamos que
recibe la siguiente respuesta:

PM: “Me reuní con ocho de los principales usuarios en una sesión. Después de la misma documenté los
requerimientos y solicité al grupo su feedback, modificaciones, etc. Tomé las actualizaciones y con el
documento actualizado me reuní con los representantes de Finanzas, Manufactura, Compras y Marketing y
ellos agregaron los requerimientos necesarios para soportar los estándares de la compañía. Tuvimos
reuniones adicionales con cuatro gerentes de cada área que resultaría críticamente impactada por el sistema.
Cada jefe de área agregó algunos requerimientos adicionales. Con el documento completo solicité la
aprobación (sign-off) de los responsables y usted puede comprobar las firmas en la última página”

El sponsor podría sentirse plenamente confortable con el documento debido a esta explicación. Ésta es la
diferencia con el método anterior, el control de calidad se focaliza en medir y verificar el entregable
propiamente dicho, el aseguramiento de la calidad se focaliza en los procesos que fueron utilizados para crear
el entregable. Ambas son técnicas poderosas para la administración de la calidad en proyectos y deben ser
realizadas para asegurar que nuestro producto o resultado final cumpla con los requerimientos de calidad de
nuestros clientes.

Como conclusión, podemos decir que durante el proceso de Aseguramiento de la Calidad el foco está en la
auditoría de los distintos procesos y las fases del proyecto para garantizar que cumplan con los estándares de
calidad impuestos o las normas y políticas organizacionales. Durante el proceso de Control de Calidad
estaremos más interesados en realizar inspecciones (revisiones técnicas formales, pruebas, etc.) sobre el
producto o servicio durante su desarrollo o ya finalizado de manera de asegurar que está conforme con las
especificaciones de calidad establecidas.

Planificación de la Calidad en un Proyecto

Por Joaquín Ibáñez, PMP® [ Acerca del autor]

 Cuando preguntamos a alguien no introducido en los conceptos de la
administración de proyectos, cuál es el parámetro más importante,
siempre surge la palabra calidad, que curiosamente no está entre la triple
restricción de alcance, coste y tiempo. En la mayoría de los casos
entendemos por calidad que el proyecto vaya más allá de los requisitos
para los que ha sido desarrollado, y nada más lejos de la realidad. Otorgar
más prestaciones o extras de los requeridos por el cliente es lo que se
denomina “Gold Plating”, y es una práctica nada recomendable porque
nos hace incurrir en costes que probablemente no aporten valor para
nuestro cliente, o en su caso, están más allá del alcance y costes
acordados.

Llegados a este punto, hay que remarcar que la calidad está implícita, y
debe ser considerada, en cada uno de los puntos de la triple restricción, determinando cómo satisfacer cada
uno de ellos con el propósito de asegurar los objetivos,

Tradicionalmente se asegura la calidad midiendo los resultados del proyecto mediante el control de calidad, y
analizando dichos datos en el proceso de aseguramiento de la calidad. Podría pensarse que la simple
inspección de todos los productos y niveles de servicio de nuestro proyecto es el mejor método de garantizar
nuestro proyecto, y nada más lejos de la realidad. Hacerlo así no nos impedirá que nos encontremos con
disconformidades por parte del cliente, además de suponer graves sobrecostes. La manera de asegurar que
el proyecto cumple con los requerimientos para los que ha sido desarrollando es asegurando la calidad según
los procedimientos desarrollados en el plan de calidad.

Por tanto, la calidad debe ser planificada; es un proceso que en la versión actual del PMBOK® se conoce
como PLAN DE CALIDAD (QUALITY PLAN ).

Propósitos del Plan de Calidad

El plan de calidad se centra en detallar las normas de calidad para el proyecto y los criterios de calidad que se
utilizan para medir y determinar si los resultados son los esperados, además de crear y documentar un plan
para cumplir con esas normas.

Dicho proceso, que se efectúa durante la fase de planificación del proyecto, está basado en la política de
calidad de la organización y tendrá por objeto desarrollar un plan que determine:

 Los estándares, normas de calidad y regulaciones que afectan a nuestro proyecto

 Los estándares que deberán desarrollarse específicamente para nuestro proyecto
 La manera de asegurar la conformidad con dichos estándares
 Los procesos y planes de mejora continua
 Las métricas que se utilizarán para medir los resultados del proyecto
 Los procesos que se utilizaran para aplicar dichas métricas
 El grado de calidad del producto y cualidades que deben ser poseídas por los entregables del
proyecto

Proceso de Planificación de calidad

Para llegar a determinar todos los aspectos de calidad del proyecto, no solamente deben centrarse los
esfuerzos en el control y la verificación, sino que debe seguirse un proceso orientado a determinar cómo dicha
verificación es llevada a cabo, procesada y transmitida:

1. Determinar qué debe ser sometido a verificación y control

Generalmente serán los entregables. Cualquier entregable importante debe ser sometido a cierto control de
calidad, entendiéndose por entregable importante aquel que forme parte del resultado final del proyecto.
2. Establecer la manera más adecuada de efectuar el control
Si el resultado final es un entregable que debe cumplir un estándar, el control de calidad debería centrarse en
el cumplimiento de dicho estándar, asegurándose esto mediante una auditoría.

3. Desarrollar la programación de las actividades de calidad

La mayoría actividades de calidad se realizan justo antes de completar el entregable, aunque si los plazos de
desarrollo son lo suficientemente largos, deben programarse actividades intermedias.

4. Determinar los interesados y participantes de las actividades de calidad

Obviamente, los responsables del entregable, pero también puede ser necesaria la participación de expertos,
e incluso del cliente final del entregable, para asegurar un común entendimiento de la información
suministrada.

5. Describir las herramientas y técnicas de calidad que deben ser utilizadas

Las herramientas y técnicas utilizadas garantizarán que se contemplan todos los aspectos del proyecto, y no
solo los aspectos importantes, no dispersando los esfuerzos y la atención de los miembros del equipo.

Herramientas y Técnicas

Si bien existe gran cantidad de propuestos de diferentes autores acerca de cómo desarrollar las actividades
de calidad, mencionaremos aquellas especificadas en el PMBOK® por ser las más representativas en el
desarrollo de proyectos. Como bien se especifica en dicho estándar, existen muchas otras que pueden ser
útiles para cierto tipo de proyectos o en determinadas áreas de aplicación.

Análisis Coste-Beneficio
Estudio para determinar el coste total de los gastos previstos de implementación de los requerimientos y
planes de calidad, comparándolos con los costes de la NO CALIDAD derivados de la no implementación de
dichos planes:

 Mayor reproceso
 Menor productividad
 Mayores costes de garantía
 Menor satisfacción del cliente
 Retrasos

Coste de la Calidad (COQ)

El coste de la calidad se refiere a la suma de todos los costes de la vida del producto realizados para asegurar
el cumplimiento de los requerimientos:
 • Formación • Equipos

• Documentación • Tiempo de los procesos

También los costes derivados de incumplir dichos requerimientos

 Costes de reproceso por no cumplir con los requisitos

 Garantías

Los costes de incumplir los requerimientos pueden ser

 Internos: fallos encontrados por el equipo del proyecto

 Externos fallos encontrados por el cliente

Diagramas de Control
Se utilizan para visualizar en una gráfica el comportamiento de las características del producto a lo largo del
tiempo, para determinar si un proceso es estable o no, o si tiene unas características uniformes y predecibles.

Con ello podremos identificar si la magnitud observada se encentra dentro de los márgenes de medida
preestablecidos., o bien identificar el momento en que se produce una disconformidad con dichos márgenes.
En procesos continuos, como por ejemplo un sistema de producción, no se observan todos los productos o
eventos, sino que periódicamente se selecciona una muestra de la producción actual.

En un diagrama de control podremos observar los límites de las especificaciones superior e inferior (valores
máximo y mínimo permisibles), establecidos por lo general en ±3σ (99.73% de las medidas dentro de los
limites).

Hay diversos comportamientos en la medida del sistema que determinan que este se encuentra fuera de
control, haciéndose necesario emprender acciones correctoras:

 Unas medidas de datos exceden un límite de control

 Dos medidas consecutivas más allá de los límites de advertencia (Habitualmente ±2σ).
 Siete medidas consecutivas o más en el mismo lado de la media (por encima o por debajo).
 Cinco medidas consecutivas que entran en la misma dirección (indica una tendencia)
Estudios Comparativos (Benchmarking)
Utilizados para comparar las prácticas desarrolladas en proyectos anteriores con las establecidas para el
proyecto en curso.

Con ello generaremos ideas de mejora, y obtendremos una base con la que comparar la coherencia del
resultado de nuestras mediciones, efectuadas durante el proceso control de calidad.

Diseño de Experimentos
Los modelos de diseño de experimentos (DOE) son modelos estadísticos que siguen una metodología basada
en la experimentación, con el objetivo de determinar qué factores influyen en una variable determinada,
además de cuantificar dicha influencia.

Sus resultados serían:

 Determinar la cantidad y el tipo de pruebas a efectuar

 Obtener las ecuaciones de modelado del sistema a partir de sus factores
 Identificar la influencia de cada uno de los factores en el proceso

Muestreo Estadístico
El muestreo estadístico consiste en seleccionar una parte de la población para su inspección para conseguir
que los resultados de dicha muestra sean extrapolables al total de dicha población.

La frecuencia y el tamaño de la muestra deben especificarse en el Plan de Calidad, anotando el número de

pruebas, los rechazos esperados, etc. Y también el coste de efectuar el muestreo.

Este proceso permite ahorrar recursos, y a la vez obtener resultados parecidos a los que se alcanzarían si se
realizase un estudio de toda la población.

Diagramas de Flujo
Los diagramas de flujo son una manera de representar gráficamente el flujo y la secuencia de procesos a
través de los sistemas. Describen qué operaciones y en qué secuencia se requieren para alcanzar un
resultado o producto, ilustrando la secuencia de las operaciones que se realizarán.
Los diagramas de flujo facilitan la comunicación entre los involucrados en el proyecto, y permiten la
comprensión de problemas largos y complicados.

Metodologías Propietarias de Gestión de la Calidad

Existen diferentes metodologías de gestión de la calidad, desarrolladas por instituciones y entidades privadas,
que actualmente se consideran modelos de referencia en la gestión de la calidad. Los principales son:

 Six Sigma: metodología de mejora de procesos, centrada en la reducción de la variabilidad de los

mismos. La meta de 6 Sigma es llegar a un máximo de 3,4 defectos por millón de unidades.

 Lean Manufacturing: es una filosofía de gestión enfocada a la reducción de los 7 tipos de

"desperdicios" (sobreproducción, tiempo de espera, transporte, exceso de procesado, inventario,
movimiento y defectos) en productos manufacturados.

 CMMI: es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y

operación de sistemas de software.

Herramientas Adicionales de Planificación de Calidad

En el desarrollo de los planes de calidad, no solo se utilizan elementos
propios de la calidad, sino que se recurre también a técnicas más
propias de otros procesos y fases de la gestión de proyectos:

 Tormenta de ideas: herramienta de trabajo grupal que facilita

el surgimiento de nuevas ideas sobre un tema o problema
determinado. La lluvia de ideas es una técnica de grupo para
generar ideas originales en un ambiente relajado.

 Diagramas de afinidad: forma de organizar la información

reunida en sesiones de lluvia de ideas.

 Análisis de campos de fuerzas: Ve el cambio como fuerzas diferentes y contrapuestas que

compiten entre sí. Para propiciar el cambio hay que ver la relación que existe entre las dos.

 Técnicas de grupo nominal: técnica empleada para facilitar la generación de ideas y el análisis de
problemas. Este análisis se lleva a cabo de un modo altamente estructurado, permitiendo que al final
de la reunión se alcance un buen número de conclusiones sobre las cuestiones planteadas.

 Diagramas matriciales: es una representación gráfica de las relaciones existentes entre diferentes
tipos de factores y la intensidad de las mismas, en términos cualitativos.

 Matrices de priorización: es una herramienta que ayuda a comparar y escoger racionalmente entre
varias opciones, con base en unos criterios para fijar prioridades o tomar una decisión.

Contenido del Plan de Calidad

El Plan de calidad del proyecto debe ser redactado con el objetivo de ofrecer un acceso fácil a los requisitos
de calidad.

La lista siguiente enumera los contenidos que deben incluirse en un plan de calidad detallado:

 Responsabilidades de la gestión: describen las responsabilidades de calidad de todos los

interesados.

 Sistema de calidad: documenta los procedimientos de calidad existentes que han sido
estandarizados y utilizados dentro de la organización.
  Documentos de calidad: procedimientos para el mantenimiento de los registros de calidad
(métricas, informes de variación, listas de comprobación etc.) durante la ejecución del proyecto y
para después de la finalización del mismo.

 Control del diseño: procedimientos para la revisión del diseño, cambios de diseño y exenciones de
requisitos.

 Control de la documentación: proceso de control de la documentación del proyecto en cada fase

del mismo.

 Compras: requisitos de calidad para la subcontratación de cualquier parte del proyecto.

 Criterios de aceptación: conjunto de criterios específicos y medibles, que el usuario/cliente utilizará

para verificar si el proyecto está completo y es correcto. Constituirán la base para la firma de
aceptación del proyecto.

 No conformidades: define los procedimientos para gestionar y solventar inconformidades. Los

procedimientos incluyen:

• La definición de responsabilidades
• La definición de las condiciones
• La disponibilidad de la documentación necesaria

 Acciones correctivas: procedimientos para tomar acciones correctivas para los problemas
encontrados durante la ejecución del proyecto.

 Auditorías de calidad: se debe planificar e implementar una auditoría interna durante cada fase del
proyecto.

 Formación: requisitos de capacitación para el equipo del proyecto.

Excelencia del Plan de Calidad

El desarrollo de un plan de calidad es un proceso que debe desarrollarse en equipo, ya que su éxito depende
tanto de la comunicación de la información como de la planificación de actividades. Bajo esta premisa, el jefe
de proyecto preparará los planes y acciones para contrarrestar cualquier debilidad o deficiencia en la
ejecución del proyecto, asegurando así que efectivamente cumplen todos los estándares de calidad.

El plan no sólo debe ser una lista específica y detallada de todas las normas de calidad y requisitos, sino que
también debería incluir todas las medidas adoptadas para garantizar que se cumplan.

¿Cuál es la contribución a la empresa y en qué le sirve a un administrador de proyecto?

Fase de evaluación de un proyecto de software–Mucho más que evaluación

Por Michael Szwarc [ Acerca del autor]

En este artículo se describirán algunos de los beneficios de la fase de evaluación de un proyecto de desarrollo
de software, y cómo asegurar que la empresa y el administrador de proyecto puedan crecer.

Definición de la Fase de Evaluación

Es muy difícil definir "fase de evaluación". Para ilustrar la idea de este artículo, la fase de evaluación se
referirá a la fase en la cual las evaluaciones exhaustivas comienzan a ser realizadas en los productos de
desarrollo (generalmente por evaluadores designados). Para objetivos de discusión, la evaluación exhaustiva
comienza desde las etapas de integración y hasta la prueba de sistema. Muchos refieren a esta etapa como la
“Etapa QA” (Quality Assurance o Aseguramiento de la Calidad), a causa de la complejidad del concepto “QA”
y la descripción enorme, este artículo se adherirá al concepto “fase de evaluación”.
Objetivos de la Fase de Evaluación

Antes de que estudiemos el aporte de la fase de evaluación al proyecto, es importante entender los objetivos
declarados en esta fase. Las respuestas aceptadas de estas interrogantes son las siguientes:

 Permitir que las partes interesadas en el producto reciban una medición de su calidad y cumplimiento
de sus requerimientos.
 Demostrar que el software hace lo que se supone debe hacer (Definición problemática y parcial).
 Encontrar las brechas o entre lo que se supone que debe hacer o no el software y lo que realmente
hace o no (definición completa más ligera).

Esto es efectivamente el propósito principal de la fase de evaluación – una fase importante y crítica para el
éxito del proyecto.

Sin embargo, ¿esto es el objetivo exclusivo?. ¿Es el trabajo de los evaluadores catalogados de este modo?.
En la mayoría de los casos la respuesta es positiva sin mucha vacilación, ya que la tarea de ellos está
enfocada a marcar una “V” la calidad del producto como es percibido por muchos, lo que resulta en la
carencia de la atención administrativa.

La mayor parte de los focos en el proyecto, al igual que el entusiasmo administrativo, está en la etapa de
desarrollo (en su sentido tradicional: el mundo de los desarrolladores de software).

En vista de esto, los administradores tienden a poner menos énfasis en la planeación de la fase de evaluación
en las etapas de planificación del proyecto y se presta mucha mayor atención a esta etapa (y tienen razón, así
es). Pero en realidad este estímulo demuestra que no es trivial. De lo contrario no sería necesario.

Muchos de los project managers recuerdan la fase de evaluación sólo en el último minuto. Pocos se
involucran e integran a ésta en las etapas de planificación y únicamente los “meticulosos” hacen alusión a la
planeación de la evaluación como una parte integral de la planeación del proyecto por sí misma.
Funciones adicionales de la "Fase de Evaluación"

La experiencia en campo muestra que la actitud simplista en la fase de evaluación reduce su aporte al
proyecto. La fase de evaluación oculta mucho valor para el administrador del proyecto y la empresa en
general:

a. Primero y muy importante, y en concordancia con el objetivo declarado, la fase de evaluación otorga una
visión de calidad del producto del proyecto. Ésta es la clásica y obvia contribución de los managers
implicados. Ya después de la rotación de la primera evaluación, los sentimientos viscerales de aquellos
involucrados comienzan a desaparecer y a transformarse basados en evaluaciones más científicas. Hay un
reporte de estado que comienza a hacerse más claro por primera vez, permitiendo al project manager un
suspiro de alivio (incluso un poco) para primera vez o bien comenzar a preocuparse (pero esta vez fuera del
conocimiento…).

b. Al principio de la etapa de redacción del plan de evaluación (antes del comienzo de la evaluación): muchos
problemas aparecen en los documentos de diseño: ambigüedad, manejo de casos extremos, imprecisión y
otros. Esto resulta en una gran precaución, puntualidad y meticulosidad que caracteriza el personal de
pruebas. Su entrenamiento y personalidades son las que los empujan a realizar preguntas (a diferencia de la
gente de desarrollo quienes tienen una tendencia mayor de interpretar de manera subjetiva). Por lo general el
costo de encontrar estos problemas en una etapa posterior es mucho mayor.

Ejemplo: En un proyecto el cual fue planeado para tomar tres meses (dos semanas de diseño, un mes para el
desarrollo, dos semanas para la evaluación y una semana de instalación), la redacción del plan de evaluación
fue demorada una semana antes del inicio de la evaluación. Durante la escritura de éste (por el estudio de
muchos casos extremos) el evaluador se avalancha con un número de preguntas relacionadas a las temas
que no quedaron claros en el diseño. Estas preguntas motivan un cambio básico en el diseño y
consecuentemente en el desarrollo. El resultado fue de dos semanas de retraso total en el proyecto. Además
del evaluador, nadie prestó atención a estos incidentes tempranos.

c. La transferencia del estado de desarrollo a la fase de evaluación se caracteriza normalmente vinculando las
diferentes terminaciones de los productos del proyecto. En muchos casos unos pocos desarrolladores
trabajan en un número de partes diferentes del software. A veces una etapa en sí misma es dedicada a la
evaluación de la integración. A veces la fase de evaluación constituye la primera oportunidad para ver todos
los componentes diferentes trabajando juntos. Este es el momento en el cual las “excavadoras de túneles” de
ambos lados se encuentran. A veces únicamente en esta etapa convergen los últimos detalles finalizados de
las interfaces y la configuración específica.

Ejemplo: En un proyecto para un cliente determinado, una configuración de un sistema específico fue
requerida, por lo cual se definieron algunos parámetros diferentes. Durante el desarrollo el software, éste fue
revisado con una variedad de parámetros sin ninguna conexión con las especificaciones del cliente. Durante
las pruebas, los evaluadores también insistieron en revisar las demandas específicas del cliente y las
evaluaciones revelaron contradicciones funcionales precisamente en estos casos.

d. Continuando con el párrafo anterior al ejemplo, la fase de evaluación comienza desde la instalación (no
necesariamente el primero pero sí el más importante) del software y/o del producto. Esta es la primera vez
que el producto en sí pasa las manos (y no sólo documentos). Hay dos transferencias que son las siguientes:

1) Tecnológica: La transferencia de un ambiente (desarrollo) a otro ambiente (pruebas). Es posible referirse a

esta operación como el primer ensayo para la instalación operacional y para examinar la calidad del proceso
de instalación en sí mismo.

Ejemplo: En un proyecto, la instalación del producto en la transferencia de la fase de desarrollo a la

evaluación duró aproximadamente dos días. El plan de instalación operacional tuvo un plazo de tiempo de
sólo 6 horas. Como consecuencia de la instalación ampliada, la empresa estuvo forzada a asignar otra
semana para reducir el tiempo de instalación. El proyecto demoró otra semana pero una sorpresa
desafortunada fue evitada durante la noche de la instalación operacional.

2) Transferencia de conocimiento: El producto es más que su tecnología. El producto combina procesos,

interfaz de usuario, terminología y más. En un mundo utópico los evaluadores no necesitan el producto para
familiarizarse con éste (ellos ya están implicados en la fase de diseño). En la práctica esto no sucede. La fase
de pruebas tiene que comenzar con la capacitación apropiada del personal de pruebas. Esta formación es el
fundamento inicial para el material de entrenamiento del producto. Por lo tanto, la transferencia de
conocimiento constituye la primera indicación del proceso de entrenamiento y la asimilación requerida.

Ejemplo: Un proyecto que consistió en muchas interfaces de usuario, el programa de adiestramiento estaba
enormemente basado en datos y conclusiones que fueron reportadas por los evaluadores (basados en su
experiencia personal).

e. La fase de pruebas no es una fase consecutiva y homogénea. Por naturaleza es una etapa cíclica
conducida en rotaciones (sin relación con la metodología de la completa administración de proyectos). Los
jugadores importantes participan en estas rotaciones: gerentes de producto, equipo de desarrollo y el project
manager. La tensión organizacional creada entre el evaluador y el evaluado, la necesidad de tomar muchas
pequeñas decisiones (a veces también son grandes) en ocasiones generan la formación de algunas
comunicaciones inter-organizacionales: ¿Cuál es el defecto?, ¿Cuál es el cambio?, ¿Qué es crítico?,
¿Cuándo reparar?, ¿Sí hay que reparar?. Esta comunicación mejora el funcionamiento del equipo en otros
proyectos y así contribuye a la mejora de los procesos en la empresa. Por una buena razón, las herramientas
para administrar los defectos/cambios fueron las primeras en ser asimiladas en el proceso de administración
del proyecto. Para mejorar las habilidades de organización y comunicación.

Ejemplo: Había una carencia de comunicación entre dos empresas que fueron socias en un proyecto de
desarrollo, que incluyó un número de desarrollos y ciclos de prueba. Las etapas de diseño y desarrollo se
vieron afectadas a raíz de las diferencias de entendimiento y metodología del trabajo que casi condujo a una
paralización completa del proyecto en la fase de evaluación conjunta. A la luz de esto, muchos esfuerzos
administrativos fueron invertidos para definir el proceso de trabajo y la comunicación, la cual está basada en
métodos de trabajo acordados y tecnología de soporte. Estos procesos que fueron definidos en la fase de
pruebas ayudaron al resto de los ciclos en el proyecto.

f. El proceso de pruebas incluye un formato estructurado de medición: estadísticas de defectos, porcentaje de

cobertura, medidas funcionales del producto y la mayoría de sus medidas no funcionales. Al "panel de control"
del administrador del proyecto se le añade inmediatamente muchos indicadores que reducen la incertidumbre
y mejoran su capacidad de planificar la continuación del proyecto.

Ejemplo: En un proyecto irregular en la empresa, fueron realizadas las evaluaciones cuidadosamente, para el
tiempo de pruebas (debido a las innovaciones en el proyecto: de nueva interfase y empleo de un nuevo
producto de anaquel). Al principio de la fase de pruebas, el gerente de pruebas comenzó a advertir sobre una
estadística de base diaria a los resultados de las pruebas: defectos y porcentajes de cobertura. El análisis de
los resultados mostró el paso de las pruebas y suministró un instrumento objetivo para planificar la
continuación del proyecto.

Utilización del Potencial Oculto de la Fase de Pruebas

De lo ya mencionado puede verse que el proceso de pruebas constituye un esquema importante para los
gerentes. Para el administrador del proyecto esto es un instrumento central que le permite controlar el
proyecto entero (y no sólo la calidad del producto). Para el resto de los gerentes es un instrumento bueno para
el control de la empresa, y aún más, una oportunidad de aprender, mejorar y asimilar procesos.

La fase de pruebas indica la madurez de la empresa, la calidad de procesos de diseño, procesos de desarrollo
y más. Un buen proceso de diseño no indicará un proceso inferior de prueba, pero sí lo contrario. Desde este
punto de vista los que se confunden entre los conceptos " pruebas de producto " y "aseguramiento de la
calidad" (QA) tienen razón (por bondad y no a favor de). En el amplio sentido del significado, el concepto de
aseguramiento de la calidad se refiere a todos los procesos de la empresa y no sólo a la calidad del producto.
Y el argumento es que la manera de examinar la calidad del producto indica la calidad de los procesos de
empresa.

La conclusión obvia es dedicar mucha más atención a la fase de pruebas y proveer el ambiente necesario
para asegurar su ejecución de una forma correcta y apropiada –para ser precisos con la sincronización
correcta: aclaratoria de los contenidos que están siendo evaluados, congelando el código, interés por el
ambiente de pruebas apropiado y conveniente y la aprobación de todos los socios en el proyecto sobre el plan
de pruebas.

Además, el project manager debería involucrar activamente a los evaluadores en todas las fases, e incluso
administrar el hito del inicio de pruebas. De ser posible, es recomendable comenzar a probar ciclos tan
temprano como sea (aunque haya muchas desventajas en un inicio temprano, es necesario saber cómo
administrarlos). La cooperación entre el jefe del proyecto y el gerente de pruebas es crítica.

Al nivel de empresa, la importancia debe ser aplicada al personal encargado de las pruebas (y en especial sus
directivos) con el fin de maximizar el potencial de la contribución global a la compañía más allá de la calidad
del producto en sí.

Por último, hay casos en los cuales es correcto usar metodologías del mundo de pruebas en otros procesos
de la empresa como puede ser el uso de las mediciones. Un ejemplo extremo incluye la etapa de desarrollo
en la fase de pruebas para forzar una estructura “ágil” en el proyecto si es requerida (sobre todo si la empresa
no es experta en esto).

Ejemplo: En un proyecto de cuatro meses y debido a las condiciones de certeza (presión del tiempo y
características del cliente) fue conocido de antemano que habrían cambios en los requerimientos durante el
desarrollo. La empresa decidió iniciar los ciclos de pruebas en una etapa más temprana. Todos los
mecanismos de revisión de defectos en alta frecuencia y versiones administración de desarrollo
acordadamente sirvieron como puntos de modificación en el diseño. En estas frecuencias encontradas (una
vez cada dos días, en un formato corto) todas las partes interesadas estuvieron presentes: los diseñadores,
desarrolladores, evaluadores y el administrador del proyecto. El proyecto recibió un tipo de administración ágil
natural y familiar sin ninguna necesidad de capacitación específica. Esta decisión aseguró el éxito del
proyecto.

Resumen

La fase de pruebas de un proyecto tiene un objetivo principal, importante y bien conocido pero más allá de
esto, constituye una amplia gama de oportunidades para mejorar los procesos en la empresa y ocultar dentro
del alto valor para el project manager. Las conciencias de este potencial en la etapa inicial y sus usos pueden
servir como un elemento estratégico que asegure el éxito de los proyectos y como una fuerza conductora para
estudios de grandes periodos y desarrollo.

Gestión de la Calidad

Por Haylin Corujo Numa

Uno de los problemas que se afrontan actualmente en la esfera de la informática es el proceso de la calidad
del software. Desde la década del 70, este tema ha sido motivo de preocupación para especialistas,
ingenieros, investigadores y comercializadores de software.

La calidad del software es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y
existencia. La calidad es sinónimo de eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad,
portabilidad, usabilidad, seguridad e integridad.

En términos generales la calidad de software puede definirse como el grado en que un conjunto de
características inherentes al software cumple con unos requisitos explícitos e implícitos.

La implantación de un sistema de calidad en una organización ayuda a mejorar la gestión del desarrollo de
software, y esto traerá como consecuencia una disminución de los problemas y errores, favoreciendo las
relaciones y comunicación entre las personas y grupos de organización, y de éstos con los clientes.
La gestión de la calidad va tomando cada día mayor importancia en el ámbito del desarrollo de software. De
esta forma, los esfuerzos encaminados a integrar la gestión de la calidad dentro de la gestión de los proyectos
deben generar también un aumento de la productividad.

Este artículo se basa en caracterizar los cuatro procesos que se encargan de definir las actividades para
determinar los objetivos y las responsabilidades relativos a la calidad, de modo que percibamos como la
gestión de la calidad dentro de la ingeniería del software va encaminada al aseguramiento de la calidad del
software a lo largo del proceso de desarrollo del mismo.

La obtención de un software con calidad implica la utilización de metodologías o procedimientos, estándares

para el análisis, diseño, programación y prueba del software que permitan uniformar la filosofía de trabajo, en
aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
productividad, tanto para la labor de desarrollo como para el control de la calidad del software.

Gestión de la calidad de software: Conjunto de actividades de la función general de la dirección que

determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como:

1. Planificación de la Calidad del Software.

2. Control de la Calidad del Software.
3. Aseguramiento de la Calidad del Software.
4. Mejora de la Calidad del Software1.

1. La Planificación de la Calidad del Software

Es la parte de la Gestión de la Calidad encargada de realizar el proceso administrativo de desarrollar y

mantener una relación entre los objetivos y recursos de la organización; y las oportunidades cambiantes del
mercado.

El objetivo es modelar y remodelar los negocios y productos de la empresa, de manera que se combinen para
producir un desarrollo y utilidades satisfactorias.

Los aspectos a considerar en la Planificación de la Calidad de Software son: Modelos/Estándares de Calidad

de Software a utilizar, Costos de la Calidad de Software, Recursos humanos y materiales necesarios, entre
otras.
El plan de calidad define los atributos de calidad más importantes del producto a ser desarrollado y define el
proceso de evaluación de la calidad.

En la Planificación de la Calidad de Software se debe determinar:

 Rol de la Planificación.
 Requerimientos de la Calidad de Software.
 Preparación de un Plan de Calidad de Software.
 Implementación de un Plan de Calidad de Software
 Preparar un Manual de Calidad.

2. El Control de la Calidad del Software

Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la
calidad. Son las inspecciones, revisiones y pruebas para asegurar la calidad del producto centradas en 2
objetivos fundamentales:

1. Mantener bajo control un proceso.

2. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

El control de calidad del software se ha convertido, por tanto en una parte esencial de los programas de
control de calidad. La atención de los requisitos específicos de la calidad del software es una actividad que
esta integrada a trabes del programa de procesamientos de información de la calidad.

Está formado por actividades que permiten evaluar la calidad de los productos de software desarrollados. El
aspecto a considerar en el Control de la Calidad de Software es la “Prueba del Software”.

Las pruebas son elementos críticos para determinar la calidad del software. Es el proceso de ejecutar un
programa con intención de encontrar defectos. Es un proceso destructivo que determina el diseño de los
casos de prueba y la asignación de responsabilidades.

Objetivos de las pruebas:

 Encontrar defectos en el software.

 Una prueba tiene éxito si descubre un defecto.
 Una prueba fracasa si hay defectos pero no los descubre.
 Ejecución de un programa con la intención de descubrir un error.
 Técnica experimental para la búsqueda de errores en los programas.

Algunos principios de las pruebas recogen lo siguiente:

 Las pruebas deberían planificarse mucho antes de que comiencen.

 No son posibles las pruebas exhaustivas: El número de permutaciones de camino para incluso
programas pequeños es excepcionalmente grande. Por ese motivo es imposible ejecutar todas las
combinaciones de caminos durante las pruebas.
 Para ser más eficaces, las pruebas deberían ser realizadas por un equipo independiente: El
ingeniero de software que creo el sistema no es el más adecuado para realizar las pruebas del
software, ya que consciente o inconscientemente tiende a probar lo que sabe que funciona.

Existen varios tipos de pruebas que pueden realizarse durante el proceso de desarrollo de software como son:

 Unitarias: Pretenden probar cada función en un archivo de programa simple (una clase en
terminología de objetos).
 Integración: Pretenden comprobar la integración de los componentes, es decir, la comunicación a
través de interfaces, acceso incoherente a estructuras de datos globales.
Las pruebas de integración pueden realizarse de forma ascendente o descendente

 Validación: Pretende comprobar que se satisfacen los requisitos.

 Sistema: Se centran en comprobar la recuperación, seguridad, resistencia, rendimiento.

Asociado a los tipos de pruebas existen también técnicas de pruebas que ayudan a definir conjuntos de casos
de pruebas aplicando ciertos criterios, como son:

 Pruebas de caja blanca: Se centra en comprobar la interacción interna de los componentes del
sistema.
 Pruebas de caja negra: “Se centran en los requisitos funcionales del software. O sea, la prueba de de
caja negra permite al ingeniero del software obtener un conjunto de condiciones de entrada que
ejerciten completamente todos los requisitos”.

La prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las
especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van
recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la confiabilidad del
software e indican la calidad del software como un todo.

Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el
software.

3. El Aseguramiento de Calidad del Software

Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software
satisfará los requisitos dados de calidad. Se trata de una actividad de protección que se aplica a lo largo de
todo el proceso de ingeniería del software.

Se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El aseguramiento de la

calidad del software engloba:

 Un enfoque de gestión de calidad.

 Métodos y herramientas de Ingeniería del Software.
 Revisiones técnicas formales aplicables en el proceso de software.
 Una estrategia de prueba multiescala.
 El control de la documentación del software y de los cambios realizados.
 Procedimientos para ajustarse a los estándares de desarrollo del software.
 Mecanismos de medición y de generación de informes.
Todo el que este involucrado en el proceso de desarrollo del software es responsable de la calidad
desarrolladores, analistas, arquitectos, jefes de proyectos, clientes y aquellas personas que en los proyectos
llamamos grupo de aseguramiento de la calidad.

Las actividades del grupo de aseguramiento de la calidad son:

 Establecimiento del plan de aseguramiento de la calidad para un proyecto.

 Participación en el desarrollo de la descripción del proceso de software.
 Revisión de las actividades de ingeniería del software.
 Auditorías de los procesos de software designados para verificar el ajuste con los definidos como
parte del proceso de software.
 Registrar lo que no se ajuste a los requisitos e informar a los superiores.
 Coordinar el control de cambio.

CMMI v1.2 en el área de proceso de aseguramiento de la calidad propone:

 Elaborar objetivamente los procesos.

 Evaluar objetivamente los artefactos y servicios.
 Comunicar y asegurar la resolución de las no conformidades.
 Establecer registros.

Además de estas actividades, el grupo de aseguramiento de la calidad coordina el control y la gestión de

cambios y; ayuda a recopilar y analizar las métricas del software.

Las métricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Cuando se
habla de software nos referimos a la disciplina de recopilar y analizar datos basándonos en mediciones reales
de software, así como a las escalas de medición.

Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores de métricas se derivan de los
requisitos del cliente o de los usuarios y, por lo tanto, actúan como restricciones dentro del proyecto.
Las medidas de Calidad del Software deben comenzar desde la especificación y terminar con la
implementación, implantación y mantenimiento o post-implantación. Debe aplicarse a lo largo de todo el
proceso de Ingeniería de Software. Básicamente, la medición es una fase normal de cualquier actividad
industrial Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional.

4. La Mejora de la Calidad del Software

Es la parte de la Gestión de la Calidad que contribuye, por medio de las mediciones, a los análisis de los
datos y auditorías, a efectuar mejoras en la calidad del software.

Las auditorías según el estándar ISO 19011:2002 se define como: proceso sistemático, independiente y
documentado para evaluar el estado actual (evidencias de la auditoría) y evaluarlas de manera objetiva con el
fin de determinar la extensión en que se cumplen los criterios de auditoría.

Una Auditoría de Calidad tiene como objetivo:

 Mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar
adversamente esa confianza.
 Suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con
los estándares, las guías, las especificaciones y los procedimientos.

Los resultados de la auditoría son documentados y remitidos al director de la organización auditada, a la

entidad auditora, y cualquier organización externa identificada en el plan de auditoria. El informe incluye la
lista de elementos no conformes u otros aspectos para las posteriores revisiones y acciones. Cuando se
realiza el plan de auditoría, las recomendaciones son informadas e incluidas en los resultados de la auditoría.

Para implementar un programa de mejoras es necesario definir procesos, decidir qué se quiere mejorar,
definir qué medidas serán necesarias recoger, cómo y dónde tomarlas, gestionarlas mediante herramientas,
utilizarlas para la toma de decisiones y reconocer las mejoras.

Cuando el proceso a mejorar es el de desarrollo del software, es importante definir qué objetivos se quieren
alcanzar, para reducir el número de medidas y, en consecuencia, el coste de recopilarlas y el impacto sobre la
actividad de producción de software.

Conclusiones

La calidad ha dejado de ser un tópico y es necesario que forme parte de los productos o servicios que
comercializamos para nuestros clientes. El cliente es el mejor auditor de la calidad, él exige el nivel que está
dispuesto a pagar por ella, pero no más. Por tanto, debemos de cuantificar cuál es el nivel de calidad que nos
exige para poder planificar la calidad de los productos que se generen a lo largo de la producción del producto
o servicio final.

Al analizar las necesidades de nuestros clientes, deberemos tener en cuenta la previsible evolución de sus
necesidades y tendencias en cuanto a características. Deberemos tener en cuenta la evolución tecnológica
del entorno de producción de nuestros productos para suministrarlos con el nivel tecnológico adecuado.

La Calidad de Software es resultado del movimiento global dentro del proceso de mejoramiento continuo de
los modelos y/o estándares de producción en todos los sectores, en particular, cuando éste se concentra en la
producción de sistemas de información y software especializado.
 Gestión de Recursos Humanos

25 secretos para mantener motivado a tu equipo

Por Jorge Aguirre [ acerca del autor ]

De todos los recursos necesarios en un proyecto, el equipo de trabajo es el más difícil de administrar. Si está
motivado, el equipo puede hacer frente a una tarea titánica sin sudar una gota ni quejarse. Pero, cuando
tenemos problemas con la motivación, debemos de ajustar el rumbo oportunamente antes de que se nos
hunda el barco.

La motivación es un todo un arte. Podemos aplicar una regla de pulgar, la motivación es mostrar aprecio y
brindar recompensa al equipo, pero ¡cuidado! cada incentivo funciona diferente para personas distintas.

1. Siempre empezar por uno mismo; para motivar a otros se debe estar motivado y notarse en todas las
situaciones. Como líder que eres, si muestras energía y seguridad el equipo tendrá confianza y te seguirá
convencido.

2. Siempre compartir la información que se tenga acerca del proyecto, el equipo debe hacer suyo al
proyecto y conocer las circunstancias que le rodean y sus limitaciones, esto también puede llevar a que el
equipo tome iniciativas para hacer sugerencias sobre nuevas formas de mejorar el proyecto.

3. Cuando nos enfrentamos a un problema relacionado con el proyecto, el equipo es nuestro mejor recurso.
Además, podemos aprovechar la ocasión y motivar a la gente al compartir los problemas con el equipo.
Propicia la participación para buscar ideas y modos alternativos de salir del problema. Una vez que sienten
que el líder también es parte del equipo es mas fácil llevarlos a resolver los retos del proyecto.

4. La disciplina es importante, pero hay que esforzarnos en mantener un ambiente amigable. Las personas
usualmente trabajan mejor si no sienten la respiración del jefe en su cuello. Las fechas y compromisos deben
ser un reto, de tal forma que el equipo se sienta orgulloso de alcanzarlas, en lugar que sean una obligación
impuesta que ocasione discusiones si no se cumplen.

5. Los proyectos se dividen en fases, un buen administrador de proyecto motiva a su equipo al señalar los
milestones del proyecto, usualmente se puede preparar una celebración especial al alcanzar los milestones
en tiempo. Planee sus fiestas de trabajo con anticipación o prepárelas dentro del horario de trabajo. Así el
equipo completo podrá disfrutarlas en lugar de preocuparse de otros compromisos.

6. Siempre debe mostrar aprecio por los miembros de su equipo, incluso las tareas pequeñas deben
terminar con al menos un gracias, las personas pueden esforzarse más al buscar ese reconocimiento. Al
comunicarse sea humilde, elija las palabras cuidadosamente, utilice más el nosotros que el yo.
7. Durante la evaluación el principio es no intentar culpar a nadie, pues esto puede generar un ambiente de
desconfianza. Para un buen ambiente se debe entender que es un logro de equipo o una falla de equipo.

8. Dar retroalimentación positiva; mencione que es lo que se ha realizado correctamente, las deficiencias y
como el equipo lo puede hacer mejor. Sea parte del equipo cuando haya que responsabilizarse por una falla y
termine siempre la retroalimentación con una nota positiva.

9. Todo mundo come, vaya a comer con un miembro del equipo, platique de temas triviales incluso algunos
relacionados con el trabajo y disfruten el tiempo juntos, será una comida gratis para ellos y un tiempo bien
empleado para usted, porque al final se está trabajando en una relación, se encuentran nuevas ideas y un
colaborador sabrá que es valorado.

10. Escuchar a sus colaboradores; deles espacio de tiempo en tiempo, y esmérate en escucharlos. Esto
debería ser un ritual para obtener sus perspectivas. Se pueden obtener ideas frescas que ayuden a mejorar
las políticas y beneficiar al proyecto.

11. Cuando un miembro del equipo le exponga un problema sea positivo en su análisis, trate de encontrar una
solución definitiva para que este regrese a trabajar en ella. Incluso considera arremangarte las mangas para
ayudar a llevar cabo la solución. Esto es Ganarse el respeto con acciones y no con palabras.

12. Siempre apoye a su equipo, deles confianza y deles oportunidad de ganar su confianza. Es imperativo
que confíen en que los apoyarás en caso de que estén en problemas.

13. No todo el mundo puede realizar todos los trabajos. Como líder le corresponde a usted escoger a la
persona adecuada para el trabajo correcto. Aunque un miembro poco convencido de enfrentar una tarea
nueva podría ganar mucha confianza al completar exitosamente el objetivo. El impacto a la moral es enorme
en caso de falla.

14. Comer juntos es un constructor de relaciones, tenga comidas en equipo cuando alguien le presente algún
tema relacionado con el trabajo. Básicamente matará dos pájaros de un tiro.

15. Permitir la creatividad del equipo, la productividad del equipo aumentará si se les da un día donde
puedan probar nuevas ideas, siempre y cuando tengan algo que ver con el proyecto que nos ocupa.

16. ¿Qué es lo que hace que la gente trabaje mejor?, algunos ponen en juego las recompensas monetarias,
incluso puede ser emocionales o personales. Si logra inculcar un sentido de propiedad o pertenencia en el
equipo, tomarán las metas del proyecto como metas personales, si se consigue no tendrá que preocuparse
por el resultado, pues la gente siempre hará su mejor esfuerzo.

17. Considere la diversión, puede ser algún tiempo libre en un juego de mesa o algo similar, puede hacer
equipos de miembros junior contra veteranos y dejar que disfruten la competencia o quizás fiestas de trabajo
para romper el hielo; esto ayudará a que se tomen mejor las responsabilidades, se trata de aligerar y
compartir.

18. Animar es realmente valioso tanto a nivel equipo como individual para cada miembro. Cuando algo vaya
bien se deben brindar elogios, un correo electrónico que reconozca una buena idea, una palmada en la
espalda por una entrega temprana o elogios con el equipo o con los directivos es una excelente manera de
mostrarles aprecio.

19. Cuando se solicitan ideas y retroalimentación usualmente los miembros más tímidos tienden a quedar
rezagados. Deles a estas personas la oportunidad de adelantarse y hablar, debe escuchar cuidadosamente
y evaluar las ideas por sus méritos. Asegúrese de no desalentar la participación calificando rápidamente
como una mala idea, esto podría significar que no participen más.

20. Durante alguna discusión, si existe un punto que necesite aclararse, busque el tiempo y asegúrese de
pedir las aclaraciones pertinentes. Los malentendidos pueden llevar a grandes errores y estos pueden ser
perjudiciales para los miembros de su equipo. Busque evitar los conflictos y resolver las situaciones antes de
que puedan dañar la moral del equipo o de las personas.
21. Localizar a los motivadores en su equipo, hay miembros de su equipo que muestran gran entusiasmo e
incitan a los demás miembros a hacer lo mismo sin decirlo. Identifíquelos y ponga alta prioridad en su
desarrollo profesional.

22. Sesiones de lluvia de ideas, estas sesiones bien llevadas pueden producir grandes ideas, además de
mostrar a sus colaboradores que son tomados en cuenta. El ser tomado en cuenta viene de la mano con la
adquisición de responsabilidades así que asigne roles de acuerdo a sus aptitudes e intereses.

23. Divida el proyecto en partes, para que pueda dar a sus colaboradores metas alcanzables. Así les
brindará libertad para hacer las cosas a su modo, dejándoles ganar confianza y hacer así su mejor trabajo.

24. Alcanzar metas importantes para la organización debe mostrar beneficios para el equipo. Pueden ser
económicos o paquetes y prestaciones como planes médicos, de vacaciones o algo similar.

25. Por último, pero no el menos importante, considerar la pirámide de Maslow de las necesidades. No todos
tenemos la misma motivación y necesidades. Mientras que un cierto incentivo para el trabajo puede funcionar
para un miembro del equipo, no necesariamente va a motivar a los demás. Por ejemplo, si un miembro tiene
algún problema financiero un aumento es lo que lo motivara mas. Pero, un miembro con ese tema resuelto
pensará en seguridad del empleo, comodidades o beneficios de otro tipo. Por lo tanto, es de suma importancia
conocer bien a su equipo. Elabore una jerarquía de necesidades con esto se puede calcular la mejor
motivación y el incentivo para sus colaboradores.

Liderazgo y Autoridad
Por Miguel Ángel Armas [ Acerca del autor ]

¿Qué es lo que hace falta para ser un buen líder?, indudablemente y entre otras cosas autoridad, que
definitivamente no es la capacidad de vociferar, manotear y ser un déspota. La autoridad no es autoritarismo.
Una de las mejores definiciones de autoridad la encontré leyendo un libro de Ikram Antaki donde menciona:

“La autoridad es la capacidad de obtener de los demás algún comportamiento por simple sugestión (se parece
a la hipnosis), hacerse obedecer sin recurrir a ningún tipo de fuerza.”
Pero el problema muchas veces está en hacer coincidir el título nobiliario con la capacidad real, es decir,
¿cuántas veces han visto a un líder de proyecto oficial con poca o sin ninguna autoridad?

Ikram Antaki hace una interesante descripción de algunos tipos de autoridad

 Autoridad política
 Autoridad artificial
 Autoridad oculta

La autoridad política no tiene nada que ver con el poder o la función gubernamental, la autoridad política
descansa sobre la legitimidad, es decir, la aceptación, no basta con el título nobiliario, debe existir cierta
superioridad que puede ser de los siguientes tipos:

 Figura paternalista: El que trata a todos como si fueran sus hij@s.

 Figura de sabio: El maestro, sensei, gurú.
 Figura carismática: El que tiene “ángel”, una relación excelente con tod@s y les cae bien.
 Autoridad de la razón: El que dirige a todos usando la razón, generalmente son los diligentes que
suelen hacer las cosas por el manual de procedimientos, evaluando y argumentando cada decisión

Esta misma autoridad política puede tener tres desviaciones:

 Autoridad ideológica: Considera algo como indiscutible y lo impone como verdad, aquí caerían por
ejemplo, los que asumen el PMBOK® como grabado en piedra, al que no se le puede mover ni una
coma y hay que aplicar de principio a fin.
 Culto a la personalidad: Es el líder que se asume como todopoderoso, infalible y al que todo mundo
debe obedecer porque es la vaca sagrada.
 Servidumbre voluntaria: Es la autoridad que se da por la pereza colectiva, cuando el líder no es
bueno, pero nadie hace nada por cambiar, y todo mundo considera mejor que alguien más tome las
decisiones.

La autoridad artificial es la que se impone por medio de “pan y circo”, usando la afirmación repetitiva por
contagio, cuando se le dice a las personas lo que quieren escuchar para tenerlos contentos, sin importar si es
lo mejor para todos, exactamente como la de las elecciones a puestos de gobierno.

La autoridad oculta es la del conformismo, cuando las tradiciones se imponen sin importar si son buenas o
malas, cuando algo se hace porque la mayoría lo realiza de esa forma y no se puede cambiar porque es la
costumbre. Es distinto de la servidumbre colectiva porque en esta última todos hacen lo que les indican y en la
autoridad oculta todos hacen lo que es costumbre y rechazan a los que quieren cambiar las cosas, sin
importar si las propuestas son buenas o malas.

Es casi obvio que lo deseable es una autoridad política con una figura de sabio carismático basado en la
razón. La triste realidad es que pocas veces (casi nunca) contamos con un líder así, por lo que debemos
considerarnos con suerte si el líder que somos o tenemos es de los que se basan en la razón, cualquier otra
característica positiva ya es ganancia.

¿Cuál tipo de líder eres?

¿Qué tipo de líder tienes?

Análisis sobre el liderazgo gerencial en la Dirección de Proyectos

¿Gerentes o Líderes?

Por Marcelo Tedesco, PMP® y MIB [ Acerca del autor ]

A través de los años han surgido y continúan surgiendo teorías, métodos y estudios sobre liderazgo y
gerencia, no obstante estas dos parecen no ser necesariamente equivalente, sin embargo pensando en
alcanzar objetivos organizacionales de manera efectiva no se puede pensar en estas dos como rasgos
separados, por el contrario, no se debería concebir a un gerente sin un liderazgo efectivo.

La Gerencia por definición es la Ciencia y el Arte de trabajar con, y a través de, un equipo de personas hacia
el logro de los objetivos de una organización. Es importante no perder de vista las primeras dos
aseveraciones. Es una Ciencia, porque implica el conocimiento de técnicas y métodos que se han
desarrollado durante años y es un Arte, porque el trabajo con seres humanos necesariamente conlleva un
componente importante de administración de sentimientos, conocimiento y sensibilidad del equipo y para con
el equipo con el que se trabaja.

Por otra parte, el Diccionario de Ciencias de la Conducta define al liderazgo como “cualidades de personalidad
y capacidad que favorecen la guía y el control de otros individuos", en todo caso esto implica que un líder no
necesariamente necesita tener una gerencia para guiar a las personas, sin embargo, una gerencia efectiva no
podría funcionar sin las cualidades de un líder.

John Kotter, de Harvard Business School, considera que la gerencia tiene que ver con vencer la complejidad.
El establece que la buena gerencia trae el orden y la consistencia al determinar planes formales, diseñar
estructuras organizacionales y controlar los resultados y avances contra los planes. El liderazgo, por otra
parte, tiene que ver con el cambio. Los líderes establecen la dirección al desarrollar una visión del futuro.
Posteriormente alinean a la gente al comunicar esta visión y la inspiran para que superen los obstáculos.

En las organizaciones modernas y más aquellas que están orientadas al desarrollo de proyectos, el liderazgo
es un rol imprescindible, y éste no es de asignación como lo puede ser en sí el titulo de “Gerente del
Proyecto”, por tal motivo es válido argumentar que no se puede ser líder porque se lo proponen o lo ponen,
sino porque los demás lo reconocen como tal. Por esto mismo, valores como la honradez, la congruencia,
visión de futuro, inspiración y competencia, entre otros, son fundamentales para ser reconocidos como líderes
legítimos. Por supuesto, la honradez y la congruencia son las cualidades más demandadas, ya que se quieren
líderes dignos de confianza y de seguirlos.

Liderazgo Transaccional y Liderazgo Transformador

En las últimas décadas ha existido en los ambientes organizacionales y académicos la inquietud de conocer y
dar a conocer nuevas teorías acerca del liderazgo, como resultado de esto se desprende una nueva tendencia
en el liderazgo, llamado Liderazgo Transformacional, que se contrapone con el Liderazgo Transaccional. Este
último durante muchos años, ha sido la teoría predominante a la hora de ponerla en práctica y lo sigue siendo
hoy en día para muchos gerentes en diversas organizaciones. Esta supone y propone el liderazgo basado en
la recompensa y el castigo, orientado a cumplir con los objetivos y con el desempeño esperado. Esto es,
premiar si se logran los objetivos, castigar o reprender si no.

Si bien este modelo fue muy efectivo durante décadas, desde la Revolución Industrial hasta mediados del
siglo pasado cuando la mayoría de las organizaciones funcionaban en un ambiente de “línea de producción”
donde el objetivo era simplemente cumplir con la cantidad de piezas fabricadas, y las personas eran
consideradas un engranaje más de la maquinaria productiva. Hoy en las nuevas organizaciones este modelo
se convierte en el principal obstáculo al cambio y al éxito de los proyectos, se ha vuelto más una herramienta
del Gerente del Proyecto para controlar a los equipos en busca de logros y reconocimientos personales.

Esta teoría presenta dos conductas de Líderes Transaccionales:

Manejo por Excepciones

 Activo: Se acomoda para monitorear el

desempeño del seguidor y tomar acciones
correctivas cuando la desviación de papel de
desempeño esperado del seguidor no es el
esperado. Concentra la atención en irregularidades,
errores, excepciones y desviaciones de lo que se
espera de los subordinados y llama la atención de
los subordinados por esto. También ponen atención
en fracasos para lograr cupos o metas.
 Pasivo: Interviene sólo si las metas no son
cumplidas. Está contento de dejar que los
subordinados continúen con su trabajo siempre y
cuando las cosas marchen bien.

Laissez-Faire

Este líder no participa en las actividades grupales. El se

abstiene de guiar, es pasivo, se limita a proporcionar
materiales e información sólo cuando los miembros de su organización se lo solicitan. En consecuencia, este
líder evita intervenir y asumir las responsabilidades que se originan por las acciones de sus seguidores. Este
es considerado el liderazgo menos efectivo de todos.

El Liderazgo Transformacional es completamente opuesto al Transaccional y opera en la base de cambiar la

motivación regular basada solamente en la recompensa para llevarla al compromiso con las metas, las
personas y la organización.

Según James Burns, autor del libro “Leadership”, “Los líderes transformacionales elevan los deseos de logros
y autodesarrollo de los seguidores, mientras que a la vez promueven el desarrollo de grupos y organizaciones.
En vez de responder al auto-interés inmediato de los seguidores como resultado del palo o la zanahoria, los
líderes transformacionales despiertan en el individuo un alto conocimiento de temas claves para el grupo y la
organización, mientras aumentan la confianza de los seguidores, gradualmente los mueven desde los
intereses para la existencia hacia intereses para logros, crecimiento y desarrollo”.

Un LÍDER TRANSFORMACIONAL no centra su atención solamente en la maximización del desempeño del

individuo, sino que pone foco en la responsabilidad del integrante del grupo por su propio desarrollo personal,
que como consecuencia trae un aumento en el desempeño as el cumplimiento de los objetivos de la
organización.

Esto tiene mucho que ver con que los integrantes de equipos desean y deben sentir que su trabajo vale la
pena. En el libro ¡A la Carga!, Ken Blanchard relata la historia de una exitosa gerente y su experiencia con una
filosofía de los Aborígenes Norteamericanos llamada “Gung Ho” donde uno de sus principios es que las
personas lograrán trabajar arduamente si su esfuerzo vale la pena, y esto es algo que abarca más terreno que
lo importante.

En esto hay tres lecciones: primero, el trabajo debe ser visto como algo importante; segundo: debe llevar a
una meta comprendida y compartida por todos; y la tercera, que los valores y la visión deben orientar todos
los planes, las decisiones y las situaciones. Esos tres elementos hacen del trabajo algo que vale la pena.

Un LÍDER TRANSFORMACIONAL debe entender este principio y la necesidad de que sus equipos deben
sentir que trabajan por algo más que el dinero, llevarlos hacia un compromiso consigo mismos y con la
organización para alcanzar metas a largo plazo.

Esto mismo aplica y se replica en todos los proyectos y sus equipos. Es común ver Gerentes de Proyectos
que en busca del beneficio propio ejercen un liderazgo transaccional asumiendo que los integrantes del
equipo cooperarán con él a costa de las circunstancias.

Y esto, en la mayoría de los casos no resulta como se espera. Siempre existirá el momento en que los
Gerentes del Proyecto tendrán que tomar decisiones en beneficio del proyecto o de la organización dueña del
proyecto y en entonces tendrán que ir contra algún integrante del equipo de trabajo por falta de disciplina, bajo
rendimiento, negligencia, etc., tendrá que decidir entre el proyecto o el colaborador, una decisión equivocada
puede redundar en el fracaso total del proyecto así como la cabeza rodante del Gerente del Proyecto, en caso
contrario la decisión correcta traerá impopularidad, pero lo que es peor, pérdida total de credibilidad porque no
pudo sostener su liderazgo transaccional y popular, además de poner en riesgo todo el proyecto. Está
demostrado más que el liderazgo efectivo y la popularidad están más peleados.

Finalmente los miembros de equipos altamente productivos no quieren Gerentes o Líderes “Buena Onda”,
buscan en sus líderes otro tipo de cualidades como las anteriormente mencionadas que lo ayuden a ellos
mismos a superarse.

Si bien es cierto que como Líderes inteligentes podemos aplicar diferentes tipos de liderazgo durante un
proyecto o en nuestras gerencias, incluso liderazgo transaccional, lo importante es hacerlo en beneficio del
proyecto o de la organización que patrocina el proyecto, no en el nuestro propio.
Los Gerentes y Directores líderes deberíamos tornar hacia tipos de liderazgos orientados a la superación de
los miembros de equipos alineadas a las metas de las organizaciones que patrocinan nuestros proyectos,
dejar de ser simplemente “gerentes” porque si no corremos el riesgo de enfrascarnos en una relación que
busca más bien la fidelidad y lealtad con nosotros, no con la organización y la visión de esta, si logramos esta
transformación redundará en beneficios no solo de un grupo, un individuo o un gerente, por el contrario, será
en beneficio para todas las personas que formen parte de ésta.

(Este artículo ha sido seleccionado para ser impartido como conferencia en el PMI® Global Congress 2010—
Asia Pacific a celebrarse en febrero de 2010. Consúltalo aquí)

Los equipos multigeneracionales y su impacto en la Gestión de Proyectos

Por Jamie B. Gelbtuch, MBA, PMP® [ Acerca de la autora]

y Conrado Morlan, PMP®, PgMP® [ Acerca del autor]

Mientras que los Directores de Proyectos lidian diariamente

con el presupuesto, los calendarios y los problemas del equipo
de proyecto, por primera vez en muchas décadas un nuevo
elemento relacionado con diversidad se tiene que agregar a la
lista - la gestión de equipos multigeneracionales.

Aunque el equipo multi-generacional siempre ha existido, el

rendimiento del proyecto está condicionado por percepciones
malentendidas respecto a la conducta de los miembros del
equipo. El reto consiste en armonizar los valores y
comportamientos generacionales para crear la sinergia
necesaria en el proyecto.

Los equipos de proyectos ahora incluyen miembros de cuatro

generaciones diferentes. Las generaciones anteriores
incluyen: Madura (aquellos nacidos antes de la Segunda
Guerra Mundial) y "Baby Boomers" (los que crecieron en
prosperidad después de la Segunda Guerra Mundial). Las
generaciones más jóvenes se conocen como la Generación X (nacidos a partir de mediados de los años 1960
a principios de 1980) y la Generación Y (los graduados del nuevo milenio). La clasificación de las
generaciones está basada en las generaciones norteamericanas pero tienen similitudes con generaciones de
otras latitudes.

Las generaciones, como las culturas nacionales, son similares a los icebergs. Cada una tiene características y
comportamientos que son fáciles de observar ("lo que" ellos están haciendo), aunque sólo representan la
punta del iceberg, el 10 por ciento que vemos por encima de la línea de flotación. Las creencias y actitudes
generacionales subyacentes ("por qué" lo están haciendo) son invisibles, similares al 90 por ciento del iceberg
que se oculta bajo el agua.

Para adentrarse en los comportamientos invisibles, los Directores de Proyecto pueden hacer analogías entre
las dimensiones culturales y generacionales. Las diferentes generaciones tienen diferentes tendencias y
percepciones en cuanto a:

Jerarquía y Autoridad

La lealtad y el respeto son un denominador común para miembros de la Generación Madura y la Generación
Y. Los miembros de la Generación Madura son leales a las instituciones y respetan la autoridad, mientras que
la Generación Y es leal a las personas y respeta a los veteranos. Los "Baby Boomers" son los promotores del
trabajo en equipo y la equidad, pero piensan que las reglas pueden ser objetadas. A la Generación X, en
cambio, no le gusta la micro gestión y considera que las reglas son dinámicas y que son establecidas por los
individuos más que por las instituciones.
De tiempo personal y de trabajo

Los Baby Boomers y los miembros de la Generación Madura consideran que el trabajo es una alta prioridad.
Sin embargo, los miembros de la Generación Madura tienen preferencia por los horarios flexibles, mientras
que los Baby Boomers están preocupados con el número de horas dedicadas a los proyectos,
independientemente de la productividad. La Generación X se caracteriza por un deseo de controlar y
establecer su plan de carrera, sus ambiciones personales, así como el horario y lugar de trabajo. La
Generación Y, por otra parte, es impulsada por una fuerte necesidad de equilibrio entre la vida y los beneficios
que permiten una carrera que les satisface.

Tipo de Comunicación Preferida

Los miembros de la Generación Madura crecieron en una era pre-informática, dominan la comunicación
interpersonal y el valor de las comunicaciones “de cara a cara”. Los Baby Boomers también creen que la
comunicación “de cara a cara” es importante, aunque a ellos les gusta dar seguimiento por escrito. La
Generación X y la Generación Y no valoran tanto la comunicación interpersonal. La Generación X busca la
comunicación abierta, independientemente de la jerarquía, mientras que a la Generación Y le gusta
comunicación en cualquier momento y lugar además de que busca comentarios positivos de sus superiores.

Con base en estas tendencias, los directores de proyecto pueden adaptar la manera tradicional en que
seleccionan y gestionan sus equipos de proyectos y se comunican con cada uno de ellos en base a sus
características generacionales. Algunas recomendaciones para dominar la manera de acercarse mejor a los
miembros del equipo son:

 Entender. Cualquier persona está en lo correcto – es sólo percepción. Las creencias y los valores no
se pueden cambiar; por ello, debemos trabajar con los miembros del equipo como individuos,
independientemente de su edad.

 Preguntar. Una simple pregunta como "Si estuvieras en mi lugar, ¿cómo manejarías esta situación?"
Le dará una perspectiva diferente a las motivaciones de la otra generación
  Compromiso. Mantener un diálogo abierto muestra buena fe de trabajar a favor y no en contra de
las diferencias

El éxito definitivo de un equipo multigeneracional depende de qué tan bien el Director de Proyecto es capaz
de liderar e inspirar a un equipo para no solamente reconocer sino conciliar las diferencias. Con un enfoque
proactivo, el equipo del proyecto será capaz de buscar similitudes y tomar ventaja de los diferentes puntos de
vista ¿Como Director de Proyecto o miembro de equipo del proyecto, de qué manera está enfrentando este
desafío?.

Cómo hacer disfuncional a tu equipo

Por Avneet Mathur [ Acerca del autor ]

El diccionario Webster define un equipo como un número de

personas asociadas ya sea en un trabajo o una actividad.
Pero, un equipo es más que una colección de gente. Es un
proceso de dar y recibir. La formación de equipos es el
proceso de crear una empresa colaborativa que pueda
desempeñar o crear cambios. Conocer la diferencia entre un
grupo, un buen equipo y un mal equipo es esencial cuando se
busca tener mejor rendimiento colectivo, especialmente
porque la formación de equipos con grupos puede ser
contraproducente.

Los siguientes dieciséis complejos del trabajo en equipo, se derivan del rígido uso excesivo o subutilización
del MTR-I (Management Team Role-Indicator o Indicador de la Función del Equipo deTrabajo), el cual se
deriva de la teoría de los tipos psicológicos de Carl Jung. El MTR-I es particularmente útil por el nexo que crea
entre los tipos psicológicos y los roles de equipo, así como facilitar la exploración de posibles diferencias entre
las preferencias de personalidad de un individuo y su personalidad en el trabajo. Los equipos se vuelven
disfuncionales cuando hay uso excesivo o insuficiente de un rol.

El uso insuficiente ocurre cuando un equipo no puede usar un rol de equipo, aun cuando sea conveniente
hacerlo. Por el contrario, el uso excesivo ocurre cuando la persona insiste en usar un rol, aun cuando no sea
apropiado hacerlo. Esto nos lleva a las complicaciones mostradas. La siguiente tabla muestra los roles de
equipo basados en la actitud de la función Jungiana identificada en el MTR-I y refleja el uso excesivo o
insuficiente dentro de un equipo.

Uso insuficiente Rol de Equipo Uso excesivo

(actitud de la función jungiana)
Independiente Director Cáscara de huevo
El equipo trabaja (Sentimiento extrovertido) Los miembros del equipo
independientemente, no como no se atreven a estar en
equipo. desacuerdo entre ellos.
Plétora Defensor Cruzada
Tratan de hacerlo todo, (Sentimiento Introvertido) Están demasiado
sin concentrarse en lo envueltos en su propia
que es importante. causa.
Anquilosado Explorador Iniciativas
Están estancados, sólo haciendo (Intuición Extrovertida) Empiezan demasiadas
lo que siempre han hecho. iniciativas pero no las
concretan.
Mirada estrecha Innovador Plutón
No pueden ver más (Intuición introvertida) Están en un planeta
allá de lo que le toca. diferente al de todos los
demás.
Mañana Escultor 100mph
Toman demasiado tiempo (Sensación Extrovertida) Atacan todo sin pararse a
pensando como se hará todo
mañana. pensar.
Impreciso Curador Burocracia
Fallan en reconocer que (Sensación Introvertida) Tratan de coleccionar y
no se han comunicado guardar demasiada
unos con otros. información.
Caos Conductor Riguroso
El caos resulta de la ausencia (Pensamiento extrovertido) Las reglas son demasiado
de la organización adecuada. importantes y el equipo es
inflexible.
Falacia Científico Apolo
No se dan cuenta de las (Pensamiento Introvertido) Pasan todo su tiempo
consecuencias porque no piensan buscándole defectos a los
en todo lógicamente. argumentos de los demás.

Disfuncional se define como “comportamiento interpersonal o interacción anormal o no saludable dentro de un

grupo”. La mayoría de las definiciones dicen que un equipo es disfuncional cuando individuos se esmeran por
seguir los procesos de pensamiento prevalecientes dentro del grupo, sacrificando sentimientos de
personalidad individual o puntos de vista personales.

Los equipos disfuncionales crean un ambiente estresante y no productivo. Se han realizado estudios formales
para reflejar esto, como Keyton (1999) quien analizó que el comportamiento de interacción en equipos
disfuncionales puede traer como consecuencia un desempeño colectivo ineficaz. Para evitar esto y construir
un equipo funcional, hay que empezar por identificar los requerimientos funcionales del equipo.
Preferentemente, los miembros deberían ser escogidos de tal forma que cubran todo el rango de tipos de
roles de equipo y no concentrarse en uno sólo. Esta distribución hace menos probable que el equipo falle.

Además, los pasos mencionados a continuación pueden tomarse para evitar el rígido uso excesivo y uso
insuficiente de roles, así incrementando el potencial para un equipo funcional y productivo. Cada rol de equipo
identificado necesita ser administrado de manera diferente para balancear el conjunto como se refleja en la
tabla.

Identificar la participación de otros en las tareas

Director
Contemplar como obtener su compromiso/participación
Tomar en cuenta la utilidad de cada idea y decidir cual
Defensor/
tomar/rechazar
Emprendedores
Priorizar las ideas, identificar la solución preferida
Probar o hacer prototipos de las soluciones elegidas par
Exploradores ver qué impacto tiene
Probar la idea con más gente y revisar su reacción
Identificar soluciones alternativas al problema
Innovadores Permitir que todas las ideas vean la luz, sin importar que
tan radicales sean
Acordar los Próximos Pasos
Escultores
Tomar acción inmediata
Aclarar el problema o la decisión a tomar
Curadores
Juntar hechos e información relacionada con el problema
Identificar planes de cómo implementar la solución elegida
Conductores
Identificar recursos, responsabilidades y tiempos
Analizar el problema para identificar las causas
Científicos Identificar cualquier situación relacionada donde se haya
presentado este problema/asunto

Puede ser difícil para un team usar un rol de equipo adecuadamente. El equipo puede estar pasando como
péndulo de un extremo a otro, haciendo uso excesivo y luego uso insuficiente de un rol, no permitiendo que se
opere en un término medio. Como individuo puede que funcione, pero cuando un grupo de individuos se
juntan como equipo, estas dinámicas toman control y el uso de los roles de equipo pasan de uso rígido a
evasión.
El equipo puede no estar consciente de este asunto. O, aunque lo estén, puede que no sean capaces de
identificar la causa de esto. O si identifican el asunto, le echan la culpa a alguien más de éste. Si llegan a
aceptar el asunto puede que no tengan la respuesta para solucionarlo.

El trabajo en equipo es la habilidad de trabajar juntos hacia una visión en común - la habilidad para dirigir
logros individuales a objetivos organizacionales. Es el combustible que permite que gente común obtenga
resultados fuera de lo común. La identificación y mitigación del uso excesivo e insuficiente de roles de equipo
como se discutió en el artículo puede ayudarlo a hacer su equipo de disfuncional a funcional.

Gestión de Comunicaciones

Validar Avances con el Usuario

El líder del proyecto debe asegurarse que el usuario se mantenga informado del progreso del proyecto y de
obtener retroalimentación oportuna sobre la funcionalidad completada.

En el caso de los proyectos que se planeen con iteraciones, al final de cada iteración se debe de llevar a cabo
una revisión de avances donde se le muestre la funcionalidad completada hasta la fecha comparándolo contra
el alcance planeado originalmente para dicha iteración. En el caso de no programar iteraciones se considerará
cierta frecuencia para realizar dichas presentaciones.

El usuario debe firmar una carta de revisión de avances, donde podrá indicar sus observaciones y
proporcionar retroalimentación para ser considerada dentro del proyecto. Es muy útil tener retroalimentación
frecuente del usuario respecto a los avances logrados, y no sólo cuando el proyecto ya va a terminarse, pues
el costo de los cambios que podría solicitar podría ser muy alto y poner en riesgo el éxito del proyecto.

Fomentando la Comunicación del Proyecto -

Es planeación, proceso y gente!
Por Suresh Malladi [ acerca del autor ]

La gente y sus expectativas crean un ambiente mas grande en donde los proyectos se llevan a cabo.

La comunicación puede concretar o deshacer proyectos. Los administradores de proyectos tienen la gran
responsabilidad de construir modelos de comunicación sólida que ayude, como instrumento para tener
información clara, concisa y oportuna para atender las metas, expectativas, tareas, revisiones,
retroalimentación y el asesoramiento requerido durante el ciclo del proyecto para promover el éxito y la
transparencia en el proyecto.
Así, la comunicación puede ser una herramienta estratégica no solo para el proyecto y comunicación externa
sino también para la comunicación interna y la mejora.
La administración y comunicación de proyectos se están volviendo mas complejas conforme proyectos
multiregiones entran al panorama. El desafío se multiplica si involucra trabajar con vendedores. Teniendo
proveedores globales puede hacerlo todavía más complejo. Se debería tener un modelo robusto de
comunicación para manejar la comunicación de proyectos internos, proyectos internos geográficamente
esparcidos ó proyectos de vendedores externos.
El objetivo de un modelo de comunicación debe ser:

 Proporcionar comunicación precisa y concisa

 Involucrar a todos los stakeholders necesarios y mantener contacto regularmente para mantener
transparencia durante todas las transacciones.
 Tener canales claros de comunicación con roles y responsabilidades bien definidas.
 Facilitar revisiones y retroalimentación de las entregas de proyectos y el rendimiento del proyecto ya
sea interna o externamente.
 Aclarar dudas, superar desafíos y prevenir riesgos que afecten al proyecto
 Crear una relación de confianza entre las partes.
 Entrenar, motivar y asesorar los equipos del proyecto.

El propósito de este artículo es proporcionar información sobre que debería de contemplar un Administrador
de Proyectos en sus modelos de comunicación, más allá de un mero reporte del progreso del proyecto. Las
siguientes secciones cubren algunos de los puntos que un Administrador de Proyectos debe tener en mente
mientras idea su estrategia de comunicación.

Un buen modelo de comunicación empieza por el principio

Los Administradores deberían darse cuenta de que la comunicación trasciende durante todo el ciclo de vida
del proyecto. Un modelo de comunicación debería ser desarrollado en una etapa temprana del proyecto,
debería ser implementado en su totalidad y el plan debería mantener a los stakeholders informados en
contacto en intervalos bien definidos. El plan de comunicación debe ser construido basado en los
requerimientos del proyecto y su ejecución. Los administradores pueden tomar ventaja del histórico de
información, normas, plantillas, etc. y adaptarlos como los requerimientos del proyecto actual lo requieran.
Todos los roles necesarios y las responsabilidades deben estar claramente definidos al igual que quien tiene
que comunicar que, cuando, como y donde. Se deberán definir canales apropiados de escalamiento. La
periodicidad de la información debe ser determinada, considerando los requerimientos de todos los
stakeholders del proyecto. Los Administradores de proyectos deberían identificar los componentes del modelo
de comunicación, nodos de comunicación, construir y revisar los planes de comunicación, reconocer donde
está fallando el modelo de comunicación, reconocer la necesidad de diferentes estilos de comunicación de los
stakeholders y periódicamente evaluar la efectividad de el plan de comunicación. La flexibilidad debe incluirse
como parte del plan de comunicación para cumplir con los requerimientos cambiantes del proyecto.

Identificar a todos los stakeholders y comunicar claramente las expectativas

Los Administradores de Proyectos deberían identificar todos los stakeholders y sus necesidades de
comunicación. Diversos stakeholders estarán involucrados en diferentes etapas del proyecto y sus
expectativas, requerimientos y necesidades varían. Un Administrador de Proyectos debe hace hincapié en
involucrar a todos los stakeholders para aprovechar la experiencia y especialización.

Mecanismos estructurados deberían usarse para conocer, priorizar y entregar requerimientos del proyecto de
acuerdo a las expectativas de los stakeholders. También se debería dejar claro que será entregado en el
proyecto y por que algo no será entregado.

El administrador de Proyectos debe comunicar de manera clara que se espera de los stakeholders y el tiempo
y ritmo en el que serán requeridos y lo que recibirán a cambio. Cuando se trabaje con proyectos en
Outsourcing, los Administradores de Proyectos del cliente y el proveedor deberán determinar las líneas de
comunicación, roles y responsabilidades; quien comunicará a quien, que será entregado. En proyectos
dispersados geográficamente, se debe tomar en cuenta el ambiente creciente, el cual trae consigo diferencias
lingüísticas y culturales, para asegurar que la información es comunicada, procesada, interpretada y absorbida
como se esperaba. Si tú eres un Administrador de Proyectos del proveedor, deberías saber con quien trabajar
del lado del cliente. Si tú eres Administrador de Proyectos del cliente, tú deberías asignar una clara línea de
comando de quien se comunicará con el proveedor, quien pasará las entradas de información,
retroalimentación, revisiones, resultados, etc. También deberías establecer una clara línea de comunicación
de como el proveedor entregó la información y los entregables serán evaluados y absorbidos de regreso a la
organización del cliente.

El Outsourcing podría crear resistencia interna y un plan de comunicación claro deberá ser redactado e
implementado por la alta dirección en el cual se definirá como los miedos internos de la organización serán
apaciguados, como los empleados serán motivados, como deberían de trabajar con el punto de contacto del
cliente y del punto de contacto del proveedor, etc.

Tenga un robusto enfoque a los procesos

La comunicación del proyecto maneja la entrega y revisión de un conjunto de artefactos del proyecto. Estos
incluyen los entregables del proyecto y los artefactos de comunicación del proyecto como reportes,
predicciones, retroalimentación, etc. Procesos robustos deberán estar implementados para capturar la
información para su futuro uso. Los Administradores de Proyectos deberían determinar la entrega y
documentación necesaria para una comunicación exitosa. Las plantillas y normas pueden ser útiles en éste
ámbito.

Cuando se trabaje con proveedores, las plantillas que pueden ser entendidas mutuamente deberán ser
negociadas, incluyendo el formato, contenido, modo y frecuencia de entrega. Llevar a cabo sesiones de
revisión y el capturar las lecciones aprendidas, deberá ser realizado al final de cada etapa o proyecto. Ningún
proyecto está terminado si no se realizan las revisiones/auditorias finales del proyecto y to todas las lecciones
aprendidas deberían ser capturadas en el repositorio de proyectos de la organización.

Todos los artefactos del proyecto y la documentación también deberían ser recolectados en los activos del
proceso organizacional para futuras referencias. Los registros positivos se volverán en buenas prácticas y los
resultados negativos pueden servir como elementos de acción para mejorar la eficacia y eficiencia de la
organización. Las revisiones finales deberían también revisar que se ha hecho bien y que podría haberse
hecho bien. Cuando se trabaje con proveedores, el equipo del cliente y el del proveedor deberian revisar entre
ellos en intervalos designados el progreso del proyecto y lecciones aprendidas. La comunicación deberá
vigilar los remedios sugeridos durante tales sesiones y como están siendo implementados.

Procedimientos Operativos Estándar los cuales listan las suposiciones que son comúnmente entendidas
deberán estar disponibles para evitar malos entendidos. Ambas partes deberían entender el lenguaje puesto
que esto ayuda a comprender la manera de tomar decisiones. El proveedor y el cliente deberían además
proporcionar una perspectiva general de la cultura interna en vez de solo transmitir lo que se va a realizar. Al
exponer la cultura interna, ayudará a que ambas partes entiendan un contexto mas grande en el que el
proyecto se llevará a cabo y el entendimiento mutuo creara una relación entre las dos partes. Un error común
es que cuando ya se han identificado las prácticas de comunicación, rara vez son incorporadas dentro de los
procedimientos de IT. Estas normas deberían de ser discutidas internamente dentro de la organización para
hacer de los stakeholders parte integral del proyecto, programa o proceso de administración de portafolios.
Todos los stakeholders del proyecto deberían estar adecuadamente educados en estas habilidades
importantes.
La consistencia en la comunicación será mayor si el equipo se subscribe a formatos predefinidos y plantillas
operacionales. Los estándares deberían estar establecidos para formato, lenguaje, nomenclatura, procesos de
administración de proyectos y componentes técnicos. La comunicación se vuelve mas desafiante cuando
involucra equipos virtuales. Normas específicas de comunicación y las herramientas a usar deberían ser
claramente identificadas puesto que las dinámicas de grupo juegan un rol en la comunicación asíncrona entre
equipos virtuales.

El equipo debería tener la oportunidad de hacer borradores de protocolos que dicten cuando se debe usar
cada herramienta. Cada miembro del equipo debería participar activamente en las juntas de equipo,
cualquiera que sea el formato, tomando responsabilidad de ser escuchado y entendido. Métodos ya
aceptados para estar en contacto con miembros del equipo durante el ciclo de vida del proyecto son útiles y
pueden servir de puntos de inicio para discutir ideas, temas e información. Un calendario de comunicaciones,
tan detallado como el plan de administración de comunicaciones, debería ser establecido de forma que sea
flexible y pueda ser ajustado en caso de ser necesario a causa de condiciones dinámicas. Comunicación mas
frecuente podría tener que ser permitida para que los miembros del equipo se sigan sintiendo conectados.

La atención a sentimientos, prioridades y percepciones es igual de importante y se vuelve mas desafiante en

un ambiente virtual cuando se transmite información. Los procesos de comunicación y los procedimientos
pueden requerir modificaciones para asegurar cohesión y compromiso entre los miembros del equipo. Tiempo
de sobra y una agenda específica son necesarias para una participación completa durante las juntas. Métodos
son necesarios para revisar la comprensión. El plan debería también especificar quien hablará y cual será el
tiempo limite para hablar o responder a ideas o hacer sugerencias. La contingencia y medidas de seguimiento
deberán implementarse para manejar variables como tecnología o la unanimidad falla en las juntas virtuales.

Promueva ser abierto y la transparencia

El progreso de un proyecto debería ser reportado en forma oportuna con información precisa. El proporcionar
información honesta, aunque esta sea negativa ayudará a tomar acciones para corregir el curso del proyecto.
Los Administradores de Proyectos deberían usar las herramientas y técnicas apropiadas para estar al tanto de
los signos vitales del proyecto contra los rangos de varianza. Una vez que la varianza es identificada, los
Administradores de Proyectos deberían comunicarlo a todos los stakeholders no solo para informar el estatus
sino para que también vean si pueden ayudar con su especialización a corregir tales varianzas. El monitoreo
de la varianza y las acciones correctivas también deberían ser notificadas a todos los stakeholders.

Este reportaje honesto no solo ayudara a tomar acciones oportunas sino también ayudará a cultivar confianza
y responsabilidad entre los stakeholders. Los Administradores de Proyectos también deberían involucrar a los
miembros del equipo durante fases como finalización de diseño, revisión de proyecto, aceptación de proyecto,
etc. pues esto hará que se sientan importantes y asuman la responsabilidad del proyecto. Involucrar a los
miembros del equipo durante el levantamiento de requerimientos y diseño también ayudará a tener mas ideas
de como cumplir, mediante un diseño de solución óptimo, con los requerimientos propuestos.

La comunicación abierta debe ser fomentada para que todo miembro del equipo se sienta cómodo
contribuyendo en las discusiones y debates. Los debates y discusiones deberían ser manejados
apropiadamente para ser un foro útil para proporcionar información, ideas y formas para compartir información
entre el equipo. Las políticas de comunicación deberían proporcionar un ambiente que asegure que la
información compartida es valiosa para el proyecto.

Tenga mas responsabilidad hacia las personas y mas allá

Los Administradores de Proyectos necesitan darse cuenta de que tienen un rol relacionado con los equipos de
los proyectos. Los Administradores de Proyectos deberían darse cuenta que el entrenamiento y la educación
que necesitan los miembros del equipo y debería encargarse de que se obtenga. Los proyectos pueden tener
efectos negativos en la organización y los Administradores de Proyectos deberían tener planes para minimizar
lo negativo e impulsar lo positivo. Mientras haya Outsourcing, los stakeholders de la organización tendrán
inseguridades y miedos que pueden adversamente impactar el rendimiento. Los Administradores de
Proyectos deberían explicar como el desarrollo por Outsourcing puede ser beneficial al trabajo actual y cual
será el rol que cada personal interno deberá jugar para contribuir en este ejercicio. Esto permitirá que los
empleados internos sepan no solo que están a salvo sino también como trabajar bajo este nuevo escenario
para absorber la sabiduría y aplicarla a su trabajo actual una vez que el proveedor haga la transferencia de
conocimientos y la transición del proyecto. Los Administradores de Proyecto deberían también darse cuenta
de que tienen la gran responsabilidad de motivar a los empleados. Un área que los Administradores de
Proyectos ignoran una vez que las fases o proyectos terminan es sentarse con los empleados para
proporcionarles retroalimentación de su rendimiento durante el proyecto. El tener revisión de compañeros o
revisiones de 360 grados puede ayudar a sugerir mas contribuciones de los empleados. Los Administradores
de Proyectos deberían hacer esto periódicamente, no solo para asesorar a los empleados, sino también para
identificar las áreas de mejora y ayudarlos a trazar planes para mejorar. Retroalimentación honesta y
asesoramiento puede fomentar a los individuos y crea una sana relación con ellos.

Los Administradores de Proyectos tienen mayor responsabilidad hacia la profesión de Administración de

Proyectos. Los Administradores de Proyectos pueden hablar o escribir acerca de sus experiencias de
proyectos y pueden compartir sus logros y fracasos con la comunidad de la administración de proyectos. Esto
los ayuda a compartir que funcionó y que no.

Conclusión

En resumen, la comunicación del proyecto se esta volviendo mas compleja día tras día debido al gran número
de stakeholders involucrados y su bagaje de ideas, vistas, percepciones y puntos de vista. Un modelo sólido
de comunicación apoyado por procesos debería estar implementado para explicar los requerimientos de los
diversos stakeholders. Los Administradores de Proyectos deberían darse cuenta de que el motivo es incluir
toda la información y personas necesarias y que el lema es proporcionar comunicación honesta y oportuna
acerca del proyecto. El tener un enfoque hacia la gente y el proceso es importante para hacer efectiva la
comunicación.

Gestión de Riesgos
Administración de Riesgos

Consiste en identificar, analizar, atacar y eliminar el origen de los riesgos antes de que se conviertan en
amenazas para completar exitosamente un proyecto de software.

Identificar factores que implican un riesgo para el proyecto desde que comienza, algunas de las prácticas para
identificarlos son:

 Lluvia de ideas; utilizando grupos homogéneos en cuanto a rol y jerarquía

 Utilizar la lista de riesgos comunes de la empresa; hay que aprender de las experiencias pasadas de
los proyectos.
 Circula la lista de riesgos del proyecto.

Desde la fase de Concepción hay que identificar los primeros riesgos e incluso atacar los más graves desde
esa fase. A lo largo de todo el proyecto hay que monitorearlos y en las juntas de seguimiento tratar de
identificar nuevos riesgos.

El análisis de Riesgo se refiere a la evaluación de la probabilidad e impacto de cada riesgo, se obtiene con la
exposición al riesgo y se calcula con la siguiente fórmula:

Exposición al riesgo = Impacto x Probabilidad

Impacto. Tiempo de retraso que ocasionaría si el riesgo ocurriera

Probabilidad. Probabilidad de que ocurra el riesgo

Si existe el 25 % de probabilidad de que el proyecto se retrase 4 semanas, entonces la exposición del riesgo
es de 1 (4 sem x .25)

La exposición al riesgo se puede utilizar como la prioridad del riesgo. Hay que ordenar los riesgos de mayor a
menor exposición al riesgo. Se recomienda sólo administrar y analizar los 10 a 20 riesgos más importantes de
acuerdo a sus exposiciones al riesgo. Atacar estos riesgos prioritarios proporciona el mayor retorno sobre la
inversión, pues estamos aplicando la ley del 20-80. El 20% de los riesgos ocasionarían el 80% del impacto,
así que hay que atacar a esos riesgos precisamente.

Se debe de planear que hacer con cada uno de los riesgos prioritarios para ir disminuyendo su exposición al
riesgo. Cada riesgo debe tener:

 Un responsable de resolverlo
 Una fecha planeada de resolución
 Lista de actividades planeadas para disminuir la probabilidad de que ocurra
 Lista de actividades realizadas para resolverlo a la fecha
 La probabilidad actual de que ocurra y la exposición al riesgo

Los riesgos se administran a lo largo de todas las fases, el principal responsable es el administrador del
proyecto, aunque se deben de asignar responsables de atacar cada uno de los riesgos.

Conceptos Básicos de Riesgos en la Administración de Proyectos

Por Luis Alberto Lozano [ Acerca del autor]

La Real Academia de la Lengua Española define el riesgo como la Contingencia o proximidad de un daño.
En sentido estricto, el riesgo implica solamente la posibilidad de sufrir daño o pérdida. En el contexto del
proyecto, la identificación del riesgo también se refiere a las oportunidades (resultados positivos) así como las
amenazas (resultados negativos). La administración de riesgos son los medios a través de los cuales la
incertidumbre se maneja de forma sistemática, para aumentar la probabilidad de lograr los objetivos del
proyecto.

Evaluación de Riesgo (se concentra en identificar los riesgos y en qué concentrarse)

1. Hacer una lista de todos los peligros potenciales que afectarán el proyecto (identificación del riesgo)
2. Determinar la probabilidad de las consecuencias de la ocurrencia y de la pérdida del potencial de
cada elemento identificado (cuantificación del riesgo)
3. Clasificar los elementos (del más al menos peligroso)

Control de Riesgos (hacer algo sobre los riesgos)

1. Establecer técnicas y estrategias para atenuar los riesgos más altos (planeación del riesgo)
2. Ejecutar estrategias para resolver los factores de alto riesgo (respuesta del riesgo)
3. Supervisar de la eficacia de las estrategias y de los niveles de modificación de riesgos a lo largo del
proyecto

La información para determinar riesgo viene de:

1. Descripción del producto. La naturaleza del producto del proyecto tendrá un efecto mayor en los
riesgos identificados. Por ejemplo, los productos que implican tecnología probada, en igualdad de
circunstancias, implicarán menos riesgo que productos, cuáles requieren innovación o invención.

2. Documentos/planes del proyecto: Las revisiones del documento de alcance, del plan del proyecto,
del plan de adquisición del personal, etc. pueden revelar riesgos.

3. Información histórica: Bases de Datos del proyecto, expedientes del proyecto, experiencia del
personal.

4. Entrevistas del Cliente y/o Usuario, así como de los estudios de viabilidad

Los riesgos asociados al producto del proyecto se describen a menudo en términos de su costo e impacto en
sus calendarios.
Identificación del riesgo

La identificación del riesgo debe considerar riesgos internos y externos. Los riesgos internos son los
elementos que el equipo de proyecto puede controlar o influenciar, por ejemplo asignaciones del personal. Los
riesgos externos van más allá del control o de la influencia del equipo de proyecto, tal como cambios de
mercado o acciones del Gobierno.

Podemos también hablar de riesgo inherente que resultan de la naturaleza de los objetivos y del alcance o
riesgo adquirido que resulta del enfoque, metodologías, herramientas, técnicas, habilidades y de la
experiencia que se aplican al proyecto

Herramientas y técnicas para la identificación del riesgo

1. Checklists. Las listas de comprobación se agrupan típicamente por la fuente del riesgo. Algunas
áreas de aplicación han sido ampliamente utilizadas para la clasificación de las fuentes del riesgo.
2. Diagramación. La diagramación puede ayudar al equipo de proyecto a entender mejor las causas y
efectos de los riesgos.
3. Entrevistas.- Las entrevistas orientadas a riesgos con varios de los involucrados (personas que
serán impactadas por el proyecto) pueden ayudar a identificar riesgos no identificados durante
actividades normales de la planeación. Los registros de las entrevistas previas al proyecto deben
estar disponibles (por ejemplo, las aplicadas durante el estudio de viabilidad).

Fuentes de Riesgo

Riesgos asociados al Cliente y/o Usuario

1. Requerimientos (requisitos) confusos / incompletos

2. Cambios frecuentes a los requerimientos (requisitos) del proyecto durante la ejecución del mismo
3. Cliente y/o Usuario que no es eficiente, eficaz o completo en cumplir sus responsabilidades del
proyecto ---
4. Cliente y/o Usuario que no está lo suficientemente disponible o que no conoce lo suficiente para
proporcionar información precisa de los requerimientos (requisitos) y /o proceso de revisión.
5. Cliente y/o Usuario que no tiene expectativas realistas sobre los resultados del proyecto, lo cual
genera restricciones de alto riesgo.
6. Restricciones Contractuales como penalizaciones por no lograr fechas límite o penalizaciones de la
terminación.

Riesgos asociados a los calendarios

1. Tareas o Hitos (Milestone) faltantes

2. Duración inexacta de la métrica
3. Estimaciones no precisas
4. Un calendario basado en cantidades exageradas de tiempo extra para todo el equipo.

Riesgos asociados a los recursos

1. Roles y/o responsabilidades NO claras

2. Recursos NO disponibles
3. Habilidades y/o Conocimientos requeridos NO satisfechos o inadecuados
4. Equipo faltante o Inadecuado
5. Rotación del personal

Riesgos asociados a la Experiencia

1. Nueva Tecnología
2. Nuevo ambiente de desarrollo
3. Nuevo Hardware
Riesgos asociados al Proceso de Administración de Proyectos

 Descomposición de Tareas (WBS) – una descomposición inadecuada falla en identificar todas las
actividades que son parte del proyecto.
 Métricas: estimaciones de tiempo y costo- las estimaciones agresivas o las desarrolladas con
información insuficiente tiempo llevan a un riesgo mayor.
 Fallas del Flujo de Trabajo: en la entrega, en la autorización de la terminación, no cumplimiento de
fechas límite.
 Falla de Aseguramiento de Calidad: proceso con fallas, carencia de la función de aseguramiento de
calidad

Conceptos Básicos de Riesgos en la Administración de Proyectos

Por Luis Lozano [ acerca del autor ]

La Real Academia de la Lengua Española define el riesgo como la Contingencia o proximidad de un daño. En
sentido estricto, el riesgo implica solamente la posibilidad de sufrir daño o pérdida. En el contexto del
proyecto, la identificación del riesgo también se refiere a las oportunidades (resultados positivos) así como las
amenazas (resultados negativos). La administración de riesgos son los medios a través de los cuales la
incertidumbre se maneja de forma sistemática, para aumentar la probabilidad de lograr los objetivos del
proyecto.

Evaluación de Riesgo (se concentra en identificar los riesgos y en qué concentrarse)

 Hacer una lista de todos los peligros potenciales que afectarán el proyecto (identificación del riesgo)
 Determinar la probabilidad de las consecuencias de la ocurrencia y de la pérdida del potencial de
cada elemento identificado (cuantificación del riesgo)
 Clasificar los elementos (del más al menos peligroso)

Control de Riesgos (hacer algo sobre los riesgos)

 Establecer técnicas y estrategias para atenuar los riesgos más altos (planeación del riesgo)
 Ejecutar estrategias para resolver los factores de alto riesgo (respuesta del riesgo)
 Supervisar de la eficacia de las estrategias y de los niveles de modificación de riesgos a lo largo del
proyecto

La información para determinar riesgo viene de:

 Descripción del producto. La naturaleza del producto del proyecto tendrá un efecto mayor en los
riesgos identificados. Por ejemplo, los productos que implican tecnología probada, en igualdad de
circunstancias, implicarán menos riesgo que productos, cuáles requieren innovación o invención.
 Documentos/planes del proyecto: Las revisiones del documento de alcance, del plan del proyecto,
del plan de adquisición del personal, etc. pueden revelar riesgos.
 Información histórica: Bases de Datos del proyecto, expedientes del proyecto, experiencia del
personal.
 Entrevistas del Cliente y/o Usuario, así como de los estudios de viabilidad

Los riesgos asociados al producto del proyecto se describen a menudo en términos de su costo e impacto en
sus calendarios.

Identificación del riesgo

La identificación del riesgo debe considerar riesgos internos y externos. Los riesgos internos son los
elementos que el equipo de proyecto puede controlar o influenciar, por ejemplo asignaciones del personal. Los
riesgos externos van más allá del control o de la influencia del equipo de proyecto, tal como cambios de
mercado o acciones del Gobierno.
Podemos también hablar de riesgo inherente que resultan de la naturaleza de los objetivos y del alcance o
riesgo adquirido que resulta del enfoque, metodologías, herramientas, técnicas, habilidades y de la
experiencia que se aplican al proyecto

Herramientas y técnicas para la identificación del riesgo

1. Checklists. Las listas de comprobación se agrupan típicamente por la fuente del riesgo. Algunas
áreas de aplicación han sido ampliamente utilizadas para la clasificación de las fuentes del riesgo.
2. Diagramación. La diagramación puede ayudar al equipo de proyecto a entender mejor las causas y
efectos de los riesgos.
3. Entrevistas.- Las entrevistas orientadas a riesgos con varios de los involucrados (personas que serán
impactadas por el proyecto) pueden ayudar a identificar riesgos no identificados durante actividades
normales de la planeación. Los registros de las entrevistas previas al proyecto deben estar
disponibles (por ejemplo, las aplicadas durante el estudio de viabilidad).

Fuentes de Riesgo

Riesgos asociados al Cliente y/o Usuario

 Requerimientos (requisitos) confusos / incompletos

 Cambios frecuentes a los requerimientos (requisitos) del proyecto durante la ejecución del mismo
 Cliente y/o Usuario que no es eficiente, eficaz o completo en cumplir sus responsabilidades del
proyecto ---
 Cliente y/o Usuario que no está lo suficientemente disponible o que no conoce lo suficiente para
proporcionar información precisa de los requerimientos (requisitos) y /o proceso de revisión.
 Cliente y/o Usuario que no tiene expectativas realistas sobre los resultados del proyecto, locuaz
genera restricciones de alto riesgo.
 Restricciones Contractuales como penalizaciones por no lograr fechas límite o penalizaciones de la
terminación.

Riesgos asociados a los calendarios

 Tareas o Hitos (Milestone) faltantes

 Duración inexacta de la métrica
 Estimaciones no precisas
 Un calendario basado en cantidades exageradas de tiempo extra para todo el equipo.

Riesgos asociados a los recursos

 Roles y/o responsabilidades NO claras

 Recursos NO disponibles
 Habilidades y/o Conocimientos requeridos NO satisfechos o inadecuados
 Equipo faltante o Inadecuado
 Rotación del personal

Riesgos asociados a la Experiencia

 Nueva Tecnología
 Nuevo ambiente de desarrollo
 Nuevo Hardware

Riesgos asociados al Proceso de Administración de Proyectos

 Descomposición de Tareas (WBS) – una descomposición inadecuada falla en identificar todas las
actividades que son parte del proyecto.
 Métricas: estimaciones de tiempo y costo- las estimaciones agresivas o las desarrolladas con
información insuficiente tiempo llevan a un riesgo mayor.
 Fallas del Flujo de Trabajo: en la entrega, en la autorización de la terminación, no cumplimiento de
fechas límite.
 Falla de Aseguramiento de Calidad: proceso con fallas, carencia de la función de aseguramiento de
calidad
 Importancia de riesgos: El caso del derrame de petróleo en el Golfo de México
Por Jaime González [ Acerca del autor ]
 El mundo entero tiene la vista en las consecuencias del manejo de riesgos por parte de British
Petroleum (BP) para su proyecto de perforación en el yacimiento de Macondo, en aguas profundas
(más bien "ultraprofundas") frente a las costas de Luisiana. Se trata de un caso extremo, donde lo
que pudiera resultar en minucias o problemas cotidianos para un proyecto pequeño o mediano se
han amplificado a niveles catastróficos en cuanto a costo, prestigio y, peor aún, impacto ambiental,
con terribles consecuencias para grandes poblaciones tanto humanas como de otras especies de
seres vivos. Por ello, sobran las razones para seguir cuidadosamente el caso.
 Lo que más me llama la atención es que se trataba de un proyecto extraordinariamente visible y
crítico, con un enorme grado de complejidad y riesgo. En otras palabras, debió ser un proyecto
conducido con gran rigor. (El rigor representa el grado de cuidado y detalle en los estudios y en la
documentación, combinado con el grado de granularidad y frecuencia en el seguimiento). Los
estudios e investigaciones que se vienen realizando mostrarán si los riesgos operativos fueron
sistemáticamente subestimados, tal como sostienen la mayoría de quienes han opinado
públicamente sobre el caso, y si el rigor con el que el proyecto fue conducido correspondía realmente
a su magnitud y a sus probables impactos.
 Tanto la página web de la revista británica The Economist como del diario The Guardian, también
británico, publican una relación muy completa de la sesión de un comité del Congreso
estadounidense, en la que los representantes pasaron por los carbones ardientes al ejecutivo en jefe
(CEO) de BP, Anthony Hayward.
 Los congresistas tuvieron acceso a más de 30,000 páginas de documentos de BP sobre el proyecto
de perforación del pozo y la plataforma Deepwater Horizon (propiedad de la empresa Transocean).
Aún cuando tomemos en cuenta (hablando desde la perspectiva del estudio de manejo de proyectos)
que muchas de las aseveraciones de los representantes están motivadas por sus puntos de vista y
posturas políticas, llama mucho la atención que el diputado Henry Waxman, de California, no
encontró en tal montaña de documentación “un sólo correo electrónico o documento que mostrara
que [BP] prestara la mínima atención a los peligros de este pozo”.


 Un correo electrónico de uno de los técnicos de BP (leído por la congresista Diana De Gette) dice,
respecto de preocupaciones en torno al diseño del pozo, y particularmente relativas a la cantidad de
elementos para centrar la perforación y la cimentación: "¿A quién le importa? De cualquier manera,
ya está hecho, end of story [no más sobre este asunto]. Probablemente todo salga bien."
 En otras palabras, los gerentes del proyecto parecen haber estado operando en modo de rutina.
 Cada día salen a la luz mayores indicios de que el tipo de cabezal (BOP, o Blowout preventer, que es
el complejo que contiene las válvulas de seguridad que deberían haber prevenido el derrame, y que
fue fabricada por la empresa estadounidense Haliburton) fue seleccionado por motivos de ahorro en
 los costos, y no en consideración a las enormes presiones y riesgos que implica la perforación en
aguas de más de de 1,500 metros de profundidad. El CEO de BP afirmó ante el comité de
congresistas que la probabilidad de falla de este tipo de BOP se consideraba que era de uno en cien
mil, a uno en un millón; pero creo que ninguno de los asistentes a la sesión (ni siquiera el mismo
Hayward) creyó que esta estimación correspondiera con la realidad.
 Notoriamente ausente, tanto por parte de los congresistas estadounidense como del CEO de BP, es
un plan de contingencia en caso de que se repitan fugas de petróleo a consecuencia de
perforaciones marinas como la del pozo Ixtoc, en 1979 (otro orgullo de México en cuanto a récords
mundiales), y como la de Macondo del presente año. Puesto en términos de manejo de proyectos, el
riesgo de derrame no ha sido recordado, como lo marcaría el más elemental estándar.
 Seguramente las medidas que pudieran haber prevenido el accidente pudieron haber costado
millones de dólares; pero aún cuando no se sepa todavía el costo real que tendrán las medidas
correctivas y de contingencia, BP ha tenido que apartar un fondo de 20 mil millones de dólares para
hacer frente a reclamaciones gubernamentales y ciudadanas por la catástrofe. Por encima de lo
anterior, están las irreparables pérdidas ambientales y en vidas humanas

Gestión de Adquisiciones

Plan de Adquisiciones
Quién, cómo, cuándo, cuánto… ¿con quién?

Por Antonio Villarreal Saldaña [ Acerca del autor]

Hace mucho tiempo cuando iniciaba en el negocio de la Administración de

Proyectos y en nuestro medio no había tanto conocimiento como lo hay
hoy, recuerdo que después de toda una explicación extensa con filminas y
varias presentaciones a un cliente potencial, de lo que era nuestro negocio,
éste, con frecuencia preguntaba: a ver, si ustedes no diseñan, no hacen
ingenierías, no construyen, no instalan, no proveen ningún material, etc.
Entonces, ¿qué hacen?

Lo primero que se me ocurría para explicarlo, muy práctico, era: somos

como un director de orquesta que tiene una partitura (plan de proyecto) y
dirige a los músicos. Muy probablemente el director empezó tocando un
instrumento o varios, sabe lo suficiente de cada uno de ellos, tiene la
experiencia y se preparó para ser Director de orquesta y su objetivo en dar un concierto, ¿pero con quién lo
vas hacer?, podrías ser el mejor director de orquesta pero el integrar al equipo, buscar a los mejores músicos
y coordinarlos para que entre ellos den un concierto es el gran reto, lo que traducido a nuestras prácticas es
simplemente utilizar la herramienta: Plan de Adquisiciones.

Lo más común cuando iniciamos un proyecto, las típicas preguntas que hay que formular, son: quién, cómo,
cuánto y cuándo; pero otra pregunta relevante que debemos hacernos en las etapas tempranas es ¿con
quién?, y esto en referencia a cómo vamos a integrar el equipo que participará en el proyecto, tanto
internamente, como fuera de nuestra propia organización: proveedores, consultores, ingenierías, diseñadores,
constructores, agencias, etc.

Siguiendo el proceso de la Administración Profesional de Proyectos, para llegar a un buen plan de

Abastecimientos, es básico tomar en cuenta lo siguiente:

 Tener documentada y clara la visión de proyecto, la justificación, supuestos, restricciones = Charter

  Haber definido el alcance, su descripción, detalles, criterios de aceptación= Declaración del Alcance
 Documentar qué incluye y qué no incluye el proyecto: entregables, sub entregables= desglose
estructurado de trabajo = WBS
 Generar un estimado de costo y un estimado de tiempo
 Hacer un diagrama organizacional de la empresas y del proyecto, es importante porque posiblemente
para la administración del proyecto además de visualizar hacia el exterior a quiénes necesitamos
contratar, también debemos de confirmar hacia el interior, cómo vamos a conformar el equipo del
proyecto y si es necesario incluir a algún asesor o especialista interno.

Una vez que tengamos esta información, podremos empezar a realizar la Matriz de Adquisiciones, la cual
debe contener el WBS, para asegurarnos que todo el alcance esté incluido y no se queden entregables sin
considerar, así como el número de contratos o el número de especialidades, en la que vamos dividir la
contratación para el proyecto.

Variables que alimentan la Matriz de Adquisiciones

¿Cuántos contratos vamos a tener?, ¿a cuántos proveedores voy a contratar?, ¿en cuántos paquetes voy a
dividir el proyecto?, esto podría ir desde un llave en mano: diseño, ingeniería, construcción, fabricación,
implementación, puesta en marcha y entrega; pasando por esquemas como diseño-construcción, o diseño-
implementación, o diseño-operación; hasta dividir el proyecto en un sinnúmero de paquetes, comprando los
materiales directos, contratando la mano de obra, etc.

En ocasiones tendemos a pensar que entre más paquetes se tenga en el proyecto puedo obtener un costo
más económico, pensemos que nos ahorramos costos indirectos al hacerlos nosotros mismos, que al hacerlo
de esta manera ahorro sobre costos, etc. pero hay que evaluar las actividades adicionales que tendremos que
hacer como: mayor coordinación, más administración, y sobre todo la división de la responsabilidad;

¿Qué tipo de contrato voy administrar?

Otra variable es planear la estrategia de tipo de contratos, sólo por mencionar algunos, tenemos el contrato a
precio alzado y el contrato a precio unitario. En este tema también existe el paradigma de que el precio alzado
es más caro o más costoso. Sí es más caro, si a la hora de concursar no contamos con la suficiente
información, los detalles del diseño no están completos o no conocemos las expectativas del cliente para el
proyecto; pero con un buen detalle de información previa al concurso, con información definida, se puede
logra una buena negociación competitiva.
¿Cómo lo voy a pagar?

Para tener una estrategia más completa hay que pensar en la forma de
pago: por precio unitario, por porcentaje de avance, por entregables
parciales, por horas hombre, por metros cúbicos, etc. Es una muy buena
práctica pagar por entregables, esto hace que podamos llevar una
administración muy sencilla, práctica, transparente y de mucho valor para el
proyecto.

¿Con quién lo voy hacer?

¿Quiénes serán los jugadores para este proyecto?, ¿a quién voy a invitar?, este tema es muy extenso e
incluso las grandes empresas y por ejemplo las armadoras, tienen toda un área de su organización enfocada
al desarrollo de proveedores. Se recomienda desarrollar una estrategia que nos ayude a definir: el tipo de
proveedores que van a participar, las especialidades de las empresas, su ubicación (locales o foráneas), el
tamaño de la empresa, el organigrama de la empresa (es institucional o es familiar o tiene el soporte de un
corporativo o es una persona sola), el récord como empresa, recomendaciones, entre otras cosas.

Es importante que estos puntos los tengamos planeados, antes del lanzamiento de los concursos y de la
invitación de proveedores a nuestro proyecto. Es muy efectivo y de alto impacto para los resultados del
proyecto y su planeación que los proveedores conozcan estas estrategias para que puedan hacer propuestas
competitivas, tengan claras las estrategias de adquisiciones o contratación que se van a implementar, se
familiaricen con la filosofía de nuestra administración de proyectos y sobre todo que son tomados como parte
del equipo ejecutor.

Antes de iniciar algún trabajo hay que tener en cuenta lo que he considerado una premisa en trayectoria: los
que hacen todo el trabajo en un proyecto son los proveedores, así que es relevante en un proyecto
contestarnos ¿con quién lo voy hacer?

Ética
La Ética en las distintas facetas profesionales

Por Norberto Figuerola, PMP® [ Acerca del autor]

Moral y Ética

Abordar un tema tan importante y amplio como es la ética, no es tarea

sencilla. Su amplitud e implicancias hacen que podría ser analizada
desde muchos ángulos. Como primer paso puede ser apropiado hacer
un acercamiento al concepto o definición de la misma: “Parte de la
filosofía que trata de la moral. Comprende las obligaciones que el
hombre como ser racional y moral, tiene para con Dios, para con el
prójimo y para consigo mismo. La ética, por lo tanto, aparte de su base
primordial, nuestras obligaciones para con el Supremo Hacedor, tiene un
fondo eminentemente de moral social casada en la justicia, y estudia no
los actos como son en sí, sino con relación a lo que idealmente debe
ser”.

“La Ética se propone, no se impone.” El actuar bien y correctamente es

algo que no viene de fábrica. La honestidad es un valor que se aprende
y este discurso debe venir acompañado por la acción. La honestidad es también tener memoria de lo que se
dijo y de lo que se hizo. “Ética (del griego ethika, de ethos, ‘comportamiento’, ‘costumbre’), principios o pautas
de la conducta humana, a menudo y de forma impropia llamada moral (del latín mores, ‘costumbre’) y por
extensión, el estudio de esos principios a veces llamado filosofía moral. La ética, como una rama de la
filosofía, está considerada como una ciencia normativa, porque se ocupa de las normas de la conducta
humana, y para distinguirse de las ciencias formales, como las matemáticas y la lógica, y de las ciencias
empíricas, como la química y la física. Las ciencias empíricas sociales, sin embargo, incluyendo la psicología,
chocan en algunos puntos con los intereses de la ética ya que ambas estudian la conducta social. Por
ejemplo, las ciencias sociales a menudo procuran determinar la relación entre principios éticos particulares y
la conducta social, e investigar las condiciones culturales que contribuyen a la formación de esos principios.

Al hacer un primer análisis de estas definiciones, podemos encontrar algunos elementos básicos que
intervienen; por un lado, el hombre y sus conductas, y por otro, referentes o bases para definir las conductas
esperadas o ideales. Sobre la base de estos elementos se comienza a analizar las conductas humanas con
relación a las esperadas, para determinar si son correctas o no. El ser humano, de una u otra forma, se
cuestiona siempre acerca de su propio comportamiento. Una de las preguntas más palpitantes y frecuentes es
aquella que se dirige al modo de juzgar nuestra conducta. Dicho más brevemente: ¿Cómo saber si mi acción
es buena o mala, acertada o equivocada, facilitadora de mi felicidad o entorpecedora de ella? Podría
afirmarse que precisamente de la ética depende la respuesta que demos a esta pregunta. En contestar a
cuestiones como la que acabamos de formular consiste la ética. Se plantea así la conveniencia de llegar a los
últimos fundamentos de la conducta humana. La necesidad de poder fundamentar racionalmente la moralidad
de los actos humanos, es decir, determinar con seguridad su bondad o malicia.

Todo el mundo emplea a la ligera los calificativos “moral” y “ético” usándolos indistintamente. Si se le pregunta
a la gente cual es la diferencia, la mayoría no tiene idea, sin embargo podemos establecer una distinción. La
Ética se refiere a una teoría o sistema que describe que es el bien y por ende que es el mal. La Moral se
refiere a las reglas que nos dicen lo que debemos hacer y lo que no. Las reglas según las cuales vivimos
constituyen la moral, los sistemas que generan dichas reglas constituyen la ética. La ética trata sobre lo
teórico mientras que la moral sobre lo práctico. El desafío consiste en tener un sistema ético personal al que
poder remitirse en busca de directrices morales, comenzando por pensar que es bueno y que es malo. Ese
problema ha desconcertado a los filósofos de todos los tiempos.

Determinar que es el bien, tal vez sea la pregunta más antigua de la filosofía y sobre la cual no existe una
respuesta precisa, la filosofía hindú tal vez es más práctica al decir que hacer el bien es actuar asegurándose
de no causar daño a los seres sensibles (una forma muy sencilla de medir el bien).

La Ética en la formación de Profesionales

El sistema de valores de cada persona es, en gran parte, adquirido y establecido durante los primeros años de
vida por influencia de su entorno familiar, social y cultural. El mismo puede ser modificado según la interacción
social del individuo con otros sistemas de valores. Los valores pueden ser estables y permanentes en el
tiempo según la forma en que sea adquirió. Algunas de las fuentes clásicas de la Ética de cada individuo
proviene entonces de :

 La familia y los valores éticos que nos han sido pasados

 La Religión
 La cultura académica y formación
 Amigos y Relaciones
 Experiencias de vida personal
 Experiencias de otros
 Razonamiento y Filosofía

Los cimientos para comenzar a construir una organización éticamente sólida, serán formados por el personal
en todos los niveles que esté identificado con la ética, que se preocupe y reflexione sobre lo correcto de sus
comportamientos. En este aspecto quienes están relacionados con la formación de las personas, tienen una
responsabilidad muy grande en procurar dar un perfil claramente ético a su tarea. Aquí la educación tiene un
rol fundamental, y en particular la Universidad, que es la responsable de la generación de profesionales que
serán luego recursos claves en las empresas. Desde ésta óptica es apropiado también analizar qué se puede
hacer desde lo académico para fortalecer la ética en las organizaciones.
En el mundo empresarial, profesional y académico, existe desde hace años tanto en la Argentina como a nivel
mundial, una tendencia, y en algunos casos una declarada decisión de política educativa, a incorporar en la
formación de profesionales de todas las especialidades las temáticas de la ética en general, la ética
profesional en particular y todas las problemáticas englobadas actualmente bajo la denominada
Responsabilidad Social Empresaria (RSE). Hasta no hace mucho tiempo, la ética era vista como una de esas
virtudes intangibles que se esperaba existan en las organizaciones, pero con poco esfuerzo consciente de
parte de sus líderes. Escándalos notorios de público conocimiento, como por ejemplo los fraudes en las
empresas Enron y Worldcom en EEUU a inicios del siglo XXI, dejaron al descubierto la pobre o a veces nula
formación ética de muchos profesionales de todo nivel jerárquico, y promovieron el dictado de una legislación
más adecuada en los Estados Unidos (Ley Sarbanes-Oxley en 2002). De alguna manera esto también indujo
a prestigiosas universidades y altas casas de estudios del mundo a incluir exigencias de contenidos
conceptuales y actitudinales vinculados a la ética en carreras y cursos de formación profesional, grado y
postgrado.

En realidad la cantidad de problemas éticos que vapulean a la sociedad, deben ser encarados por todos los
estamentos, si no es así, los esfuerzos aislados serán poco efectivos. Tenemos que dejar de pensar que éste
es un problema a ser resuelto “por otros”. Con frecuencia se escucha: esto es responsabilidad de los políticos;
el sistema es corrupto; yo no puedo hacer nada ante todo esto; etc. Todos tenemos que hacernos cargo de
esta responsabilidad desde nuestros ámbitos de influencia.

Ética Personal y de Negocios

Cada individuo tiene sus propios códigos éticos en los cuales se basan sus comportamientos. Podemos
pensar que ellos son nuestras propias reglas que gobiernan nuestro comportamiento. Si nos sentimos fuertes
con nuestras reglas éticas nunca las romperemos. Si no son muy intensas algunas veces dejamos que las
condiciones cambien la regla. Si somos indiferentes, frecuentemente dejamos que otros tomen las decisiones.

La mayoría de las organizaciones o compañías tienen hoy sus códigos de ética los cuales establecen la
conducta esperada de sus empleados/miembros y las normas de la misma. El comportamiento ético en el
entorno diario es el resultante de la consideración de ambos comportamientos (el personal y el de negocios).
Generalmente en cualquier cuestión o duda de problemas éticos relacionados con el trabajo, el empleador
mantiene el mayor poder y usualmente el empleador ejecuta su mayor presión en los asuntos financieros. La
diferencia más importante se manifiesta cuando elementos importantes de la ética personal entran en conflicto
con presiones impuestas por el negocio.
A escalas más cotidianas, la actividad profesional nos pone con
frecuencia ante dilemas éticos, situaciones donde se ponen a prueba los
valores que todos poseemos y la fuerza con la que estamos dispuestos
a mantenerlos. En algunos casos, la inclusión de estos temas para su
estudio no solo proviene de las autoridades académicas sino de la
demanda de los propios alumnos, cada vez más interesados en
programas vinculados con la comunidad, con el sector de las ONG
(organizaciones no gubernamentales) y temas medioambientales como
por ejemplo métodos para ahorrar energía y agua, el control de
contaminación, mejora de ambientes de trabajo, etc.

Ética y Liderazgo

El “Liderazgo Ético” es una necesidad que hace mejor y más rica a la empresa. Por el contrario, si se busca el
enriquecimiento acelerado y sobre bases ilícitas, la empresa se condena a sí misma.

Ya en estos tiempos, nadie puede negar la importancia de la inteligencia emocional para la toma de
decisiones en las empresas; que el cliente es cada día más y más exigente y más difícil de engañar; que el
mundo entero se ha reducido por efecto del inmenso desarrollo de las telecomunicaciones y que el temor a
una demanda por efecto de un error que afecte a terceros, es ahora muy latente en todos. Es por eso que la
ética empresarial está teniendo, hoy más que nunca, una presencia determinante en la dinámica de las
empresas modernas.

Es el momento de valorizar o revalorizar las actitudes y valores gerenciales, de tal manera que se comprenda
que la ética empresarial es ahora una necesidad y no una virtud. Ciertamente, estudios actuales revelan que
las empresas internacionales están sometidas a una creciente presión para que las conductas de sus líderes
de negocios se adecuen a comportamientos éticos. Y algunos hechos confirman que las actitudes
relacionadas con malos manejos gerenciales están siendo castigados con multas millonarias.

Más profundamente la ética empresarial, tiene mucha relación con el acatamiento de las leyes,
independientemente de los países en que se aplican. Y aún en aquellas naciones donde existe la impunidad,
la ética debe correr la suerte de emerger, para ubicarse sobre los pilares de la corrupción, el tráfico de
influencias y otras desviaciones mayores o menores que atentan contra la vida y dignidad de las personas.

En la actualidad, hasta el gerente más pragmático necesita actuar con ética, porque el actuar ético, está
demostrando, que le da vida permanente a los negocios, todo porque se adquiere credibilidad y confianza, y
las personas terminan siendo leales a los productos o a las marcas

Está comprobado que la adherencia a códigos éticos incrementa la efectividad del liderazgo hasta en un
500%. Los individuos líderes con fuertes creencias éticas, que demuestran un comportamiento constante y
consistente con sus valores éticos, provoca que sus seguidores puedan confiar y depender plenamente de
sus acciones.
Ética en los Negocios

El conjunto de valores, principios y creencias que posee una organización de forma distintiva se denomina
como cultura organizacional, que es también definida “como el conjunto de procedimientos y conductas
gerenciales que sirven de ejemplo y refuerzan los principios básicos” (Denison, 1991). Estos principios y
procedimientos perduran al tener un significado importante y compartido por cada uno de sus miembros.

La cultura de una organización se inicia a partir de la filosofía de sus fundadores y se mantiene a través de la
influencia y reforzamiento de sus líderes. La cultura determina el criterio de aceptación de cada uno de sus
miembros y es trasmitida de diversas maneras: historias o anécdotas, rituales, símbolos materiales y lenguaje.
Su estudio es de gran importancia para el mejoramiento de la productividad y del clima organizacional. La
cultura organizacional influye en el comportamiento ético y desempeño de la organización, tanto a nivel
individual como en su conjunto. Las diferentes organizaciones aplican normas éticas (códigos de ética) para
orientar sus relaciones y decisiones internas y externas. El comportamiento que expresa la organización se
encuentra influenciado o regido por lo que se ha denominado como ética de negocios o empresarial.

La ética empresarial es el conjunto de principios y normas que guían el comportamiento en el mundo de los
negocios. La ética en las organizaciones puede ser afectada por diversos factores: desarrollo moral de sus
gerentes o líderes; sistemas de valores individuales; contenido y fortaleza de la cultura organizacional;
diseños estructurales de la organización que permiten la ambigüedad; intensidad del problema ético.

Desde hace algún tiempo, más aun en la actualidad, la ética en los negocios ha sido objeto de revisión por
presentar dilemas éticos difíciles en distintas áreas y escenarios. En ese sentido, es obligación de las
empresas determinar si realmente están aplicando actividades éticas y si son socialmente responsables. La
responsabilidad social, es la obligación hacia la sociedad asumida por las empresas más allá de las
finalidades económicas; tiene que ver con la forma como la organización afecta la sociedad en la que existe.
¿Por qué la ética debe estar presente en los negocios? Una respuesta a esta pregunta es que la ética debe
gobernar todas las actividades humanas voluntarias, y como los negocios son una actividad humana y
voluntaria, también debería regir a los mismos. Además, los negocios son una actividad cooperativa que exige
un comportamiento ético. Por ejemplo, un negocio se arruinaría si todos sus gerentes, empleados y clientes
llegaran a pensar que es moralmente permisible robar, mentir, o quebrantar sus acuerdos con la empresa.
Hoy son varios los casos de empresas en todo el mundo que produjeron (o producen) fraude, asociación
ilícita, tergiversación de información económico-financiera, falta de transparencia, corrupción, etc. Algunos
pueden buscar causas en los sistemas de control interno de las empresas o en las auditorias externas, que
podrían ser débiles o que no estén lo suficientemente desarrollados. También se apunta a las normas técnicas
de la contabilidad, que podrían estar mostrando fisuras en su estructura, por las que puede ocultarse
información en forma aparentemente legal. De esta manera se evita mostrar datos que podrían comprometer
a la empresa o desalentar a los inversores, usando técnicas o movimientos que las normas no prohíben.

Aunque existan los mejores sistemas de control, siempre hay personas

que pueden tener el poder o la habilidad de estar por encima de esos
controles, pudiendo vulnerarlos o sortearlos. Si sus ambiciones son
más importantes que la ética o valores, usarán ese poder o habilidad
para violentar los sistemas y alcanzar sus metas. De hecho las
corporaciones multinacionales hoy en día tienen más poder que los
propios gobiernos. Me permito sugerir al lector si tiene la oportunidad
de ver el video “The Corporation” (algunos capítulos pueden
encontrarlos en Google), en donde queda manifestado que los
grandes grupos económicos mundiales produjeron niveles
impredecibles de riqueza, pero a que costo? Algunos ejemplos que
podemos ver en dicho film permiten comprobar la personalidad anti-
social y amoral que tienen algunas corporaciones al dañar
directamente a los trabajadores, la salud, la biosfera, etc. La
personalidad sicopática de algunas empresas en la búsqueda de
ganancias no tiene limites, hoy en día animales, plantas, el ADN,
vacunas, y quien sabe hasta que otro componente del planeta es
factible de ser patentado por las corporaciones.

Resulta patético y alarmante ver los nombres de algunas corporaciones como ejemplos de este
comportamiento (sobre todo cuando alguien trabajó o está trabajando en algunas de esas empresas). El
dilema se presenta en saber hasta dónde uno puede hacer valer sus propios principios morales y éticos
siendo que trabaja en una compañía que a veces no los tiene. Personalmente me he encontrado con algunos
de dichos dilemas y en algunos casos me ha costado el empleo mismo. Las compañías las conforman
individuos y entonces será un gran desafío para las empresas o algún ente que las regule desarrollar e
implementar maneras para que todo el personal, desde los máximos gerentes hasta el empleado de línea, se
sienta motivado para que su comportamiento sea ético.

Que una empresa cuente con un personal que tiene claridad de principios éticos para actuar, y además se
siente valorado por eso, es un primer e importante paso para que llegue a ser una empresa ética, como
institución. Cuando una organización tiene una definida vocación por la ética, su dirección está comprometida
en resaltarla, teniendo el deseo de mostrar los valores que creen que son los fundamentales, se puede utilizar
el Código de Ética para hacer explícito todo esto.

Muchas organizaciones buscan hoy crear su Código de Ética. Esta tendencia que a primera vista puede
asemejarse a una moda, parece estar entrando de forma más profunda en el tejido social y en algunas
empresas. Los ciudadanos en todo el mundo dan muestras de cansancio con relación a la corrupción, al error,
al hacer mal que se corresponde con ser víctima de lo que otros hacen mal. Este trabajo se puede hacer entre
personas, colegas y competidores, que no tienen vergüenza de actuar bien y se disponen a liderar el proceso
de cambio que la sociedad ansía, el problema es no quedarse en una intención puesta en un papel para
demostrar que la compañía tiene sus valores éticos y sociales sino en acciones concretas.

Ética en la administración de proyectos

Por Norberto Figuerola, PMP® [ Acerca del autor ]

Como instructor de Project Management he dictado varios cursos y seminarios, incluyendo los relacionados
con la preparación de los estudiantes en el examen que toma el PMI® para la certificación profesional PMP®.
Como en dicho examen se agrega además de las nueve áreas de conocimiento preguntas sobre ética
profesional y diversidad cultural, siempre tuve la inquietud de escribir algún artículo al respecto, sobre todo
porque también he dictado cursos exclusivos de Ética.

El factor disparador del presente escrito fue recibir la revista mensual PM Network de Octubre 2008, en donde
se presentaron una serie de artículos relacionados con la responsabilidad social y ambiental que tienen las
empresas y de hecho los PM cuando encaran sus proyectos. Permítanme resumirles algunos párrafos de la
editorial normalmente escrita por el presidente y CEO del PMI® Gregory Balestrero: “Que pensaría el lector si
esta fuese la última tirada de la revista dado que la pobre gestión de recursos del planeta lo ha deforestado y
no tenemos más papel? El compromiso social y con el planeta hará que más y más proyectos serán medidos
en términos de ganancias sociales y al medio ambiente y no tanto económicas.

El PMI® invita a repensar a sus miembros en el modo en rehacer las cosas, tal es asi que la propia revista
comenzará a publicarse en un papel más protector del medio ambiente reconocido por el SFI, lo que significa
que proviene de bosques que son manejados en forma sustentable”. Los proyectos que presenta dicha tirada
nos hacen reflexionar en el grado en que muchas empresas están observando el impacto social y ambiental
de sus proyectos, el grado de sustentabilidad de sus procesos productivos y la nueva ola “green”. CSR
(Corporate Social Responsability) o RSE (Responsabilidad Social Empresarial) ya no es sólo un grupo
importante de organizaciones mundiales (ong’s y org’s) en búsqueda de un mundo mejor y más justo sino que
está ya instalada en las grandes compañías y corporaciones y está siendo promocionada además dentro de
las pequeñas y medianas.

La mayoría de las asociaciones profesionales, institutos y entes de certificación profesional como el PMI®,
verifican, controlan y estimulan el comportamiento ético de sus asociados, favoreciendo a aquellos que, entre
otras cualidades, tengan alguna participación en tareas comunitarias. Dichas organizaciones ven aumentado
su prestigio si sus miembros y asociados son reconocidos por sus pares, por sus clientes y por la sociedad en
general como personas con altos estándares éticos.

Fraudes contables, acciones y decisiones empresariales que perjudican a personas, sociedades y al medio
ambiente, generan en quienes resultan afectados y en la opinión pública en general una demanda de
transparencia más que evidente en la actualidad. En el contexto del administración de proyectos, resaltamos
la temática de la ética en la necesidad de determinar la integridad organizacional, la relación entre dicha
integridad organizacional y la del proyecto, la responsabilidad ética del gerente de proyecto, incluyendo el
comportamiento ético en el éxito tanto del proyecto como de la organización.

Estos temas exceden la simple consideración del cumplimiento

o no de leyes y normas (delitos, sobornos, extorsiones, tráfico
de información confidencial, prácticas comerciales
cuestionables, discriminación, contaminación, etc.). Se
incorporan a la jerga profesional conceptos como “desarrollo
sustentable”, “stakeholders”, “accountability”, responsabilidad
social, etc., que cambian el fin clásico que primaba antes en las
empresas, como era el de solamente dar la mayor rentabilidad
y rendir cuenta a sus accionistas, propuesto por Milton
Friedman, sumándole a esto también las consecuencias del
accionar de las empresas sobre el medio ambiente, los
empleados y la sociedad en la que se desarrollan, mediante
una visión socioeconómica de bienestar social.

El Código de Ética y Conducta Profesional del PMI® vigente

desde el 1ro de enero de 2007, incluye disposiciones
obligatorias sobre las cuales todos los miembros voluntarios y
los certificados serán tenidos como responsables, incluyendo
por ejemplo temas de conflictos de intereses. Sólo como
resumen comentaré que consta de 5 capítulos el primero nos habla sobre la visión y aplicabilidad del Código
(Incumbe a todos los miembros del PMI®, no-miembros que posean una certificación del PMI®, no-miembros
que se postulen a un proceso de certificación en el PMI® y no-miembros que desarrollan una actividad
voluntaria en el PMI®). El resto de los capítulos está dividido en secciones que contienen estándares de
conducta alineados con los cuatro valores identificados como más importantes para la comunidad de
Gerentes de Proyecto que forman la base de la toma de decisiones y que guían sus acciones:
Responsabilidad, Respeto, Justicia y Honestidad.

La Ética en las distintas facetas profesionales

Por Norberto Figuerola, PMP® [ Acerca del autor]

Moral y Ética

Abordar un tema tan importante y amplio como es la ética, no es tarea

sencilla. Su amplitud e implicancias hacen que podría ser analizada
desde muchos ángulos. Como primer paso puede ser apropiado hacer
un acercamiento al concepto o definición de la misma: “Parte de la
filosofía que trata de la moral. Comprende las obligaciones que el
hombre como ser racional y moral, tiene para con Dios, para con el
prójimo y para consigo mismo. La ética, por lo tanto, aparte de su base
primordial, nuestras obligaciones para con el Supremo Hacedor, tiene un
fondo eminentemente de moral social casada en la justicia, y estudia no
los actos como son en sí, sino con relación a lo que idealmente debe
ser”.

“La Ética se propone, no se impone.” El actuar bien y correctamente es

algo que no viene de fábrica. La honestidad es un valor que se aprende
y este discurso debe venir acompañado por la acción. La honestidad es
también tener memoria de lo que se dijo y de lo que se hizo. “Ética (del griego ethika, de ethos,
‘comportamiento’, ‘costumbre’), principios o pautas de la conducta humana, a menudo y de forma impropia
llamada moral (del latín mores, ‘costumbre’) y por extensión, el estudio de esos principios a veces llamado
filosofía moral. La ética, como una rama de la filosofía, está considerada como una ciencia normativa, porque
se ocupa de las normas de la conducta humana, y para distinguirse de las ciencias formales, como las
matemáticas y la lógica, y de las ciencias empíricas, como la química y la física. Las ciencias empíricas
sociales, sin embargo, incluyendo la psicología, chocan en algunos puntos con los intereses de la ética ya que
ambas estudian la conducta social. Por ejemplo, las ciencias sociales a menudo procuran determinar la
relación entre principios éticos particulares y la conducta social, e investigar las condiciones culturales que
contribuyen a la formación de esos principios.

Al hacer un primer análisis de estas definiciones, podemos encontrar algunos elementos básicos que
intervienen; por un lado, el hombre y sus conductas, y por otro, referentes o bases para definir las conductas
esperadas o ideales. Sobre la base de estos elementos se comienza a analizar las conductas humanas con
relación a las esperadas, para determinar si son correctas o no. El ser humano, de una u otra forma, se
cuestiona siempre acerca de su propio comportamiento. Una de las preguntas más palpitantes y frecuentes es
aquella que se dirige al modo de juzgar nuestra conducta. Dicho más brevemente: ¿Cómo saber si mi acción
es buena o mala, acertada o equivocada, facilitadora de mi felicidad o entorpecedora de ella? Podría
afirmarse que precisamente de la ética depende la respuesta que demos a esta pregunta. En contestar a
cuestiones como la que acabamos de formular consiste la ética. Se plantea así la conveniencia de llegar a los
últimos fundamentos de la conducta humana. La necesidad de poder fundamentar racionalmente la moralidad
de los actos humanos, es decir, determinar con seguridad su bondad o malicia.

Todo el mundo emplea a la ligera los calificativos “moral” y “ético” usándolos indistintamente. Si se le pregunta
a la gente cual es la diferencia, la mayoría no tiene idea, sin embargo podemos establecer una distinción. La
Ética se refiere a una teoría o sistema que describe que es el bien y por ende que es el mal. La Moral se
refiere a las reglas que nos dicen lo que debemos hacer y lo que no. Las reglas según las cuales vivimos
constituyen la moral, los sistemas que generan dichas reglas constituyen la ética. La ética trata sobre lo
teórico mientras que la moral sobre lo práctico. El desafío consiste en tener un sistema ético personal al que
poder remitirse en busca de directrices morales, comenzando por pensar que es bueno y que es malo. Ese
problema ha desconcertado a los filósofos de todos los tiempos.

Determinar que es el bien, tal vez sea la pregunta más antigua de la filosofía y sobre la cual no existe una
respuesta precisa, la filosofía hindú tal vez es más práctica al decir que hacer el bien es actuar asegurándose
de no causar daño a los seres sensibles (una forma muy sencilla de medir el bien).

La Ética en la formación de Profesionales

El sistema de valores de cada persona es, en gran parte, adquirido y establecido durante los primeros años de
vida por influencia de su entorno familiar, social y cultural. El mismo puede ser modificado según la interacción
social del individuo con otros sistemas de valores. Los valores pueden ser estables y permanentes en el
tiempo según la forma en que sea adquirió. Algunas de las fuentes clásicas de la Ética de cada individuo
proviene entonces de :

 La familia y los valores éticos que nos han sido pasados

 La Religión
 La cultura académica y formación
 Amigos y Relaciones
 Experiencias de vida personal
 Experiencias de otros
 Razonamiento y Filosofía

Los cimientos para comenzar a construir una organización éticamente sólida, serán formados por el personal
en todos los niveles que esté identificado con la ética, que se preocupe y reflexione sobre lo correcto de sus
comportamientos. En este aspecto quienes están relacionados con la formación de las personas, tienen una
responsabilidad muy grande en procurar dar un perfil claramente ético a su tarea. Aquí la educación tiene un
rol fundamental, y en particular la Universidad, que es la responsable de la generación de profesionales que
serán luego recursos claves en las empresas. Desde ésta óptica es apropiado también analizar qué se puede
hacer desde lo académico para fortalecer la ética en las organizaciones.
En el mundo empresarial, profesional y académico, existe desde hace años tanto en la Argentina como a nivel
mundial, una tendencia, y en algunos casos una declarada decisión de política educativa, a incorporar en la
formación de profesionales de todas las especialidades las temáticas de la ética en general, la ética
profesional en particular y todas las problemáticas englobadas actualmente bajo la denominada
Responsabilidad Social Empresaria (RSE). Hasta no hace mucho tiempo, la ética era vista como una de esas
virtudes intangibles que se esperaba existan en las organizaciones, pero con poco esfuerzo consciente de
parte de sus líderes. Escándalos notorios de público conocimiento, como por ejemplo los fraudes en las
empresas Enron y Worldcom en EEUU a inicios del siglo XXI, dejaron al descubierto la pobre o a veces nula
formación ética de muchos profesionales de todo nivel jerárquico, y promovieron el dictado de una legislación
más adecuada en los Estados Unidos (Ley Sarbanes-Oxley en 2002). De alguna manera esto también indujo
a prestigiosas universidades y altas casas de estudios del mundo a incluir exigencias de contenidos
conceptuales y actitudinales vinculados a la ética en carreras y cursos de formación profesional, grado y
postgrado.

En realidad la cantidad de problemas éticos que vapulean a la sociedad, deben ser encarados por todos los
estamentos, si no es así, los esfuerzos aislados serán poco efectivos. Tenemos que dejar de pensar que éste
es un problema a ser resuelto “por otros”. Con frecuencia se escucha: esto es responsabilidad de los políticos;
el sistema es corrupto; yo no puedo hacer nada ante todo esto; etc. Todos tenemos que hacernos cargo de
esta responsabilidad desde nuestros ámbitos de influencia.

Ética Personal y de Negocios

Cada individuo tiene sus propios códigos éticos en los cuales se basan sus comportamientos. Podemos
pensar que ellos son nuestras propias reglas que gobiernan nuestro comportamiento. Si nos sentimos fuertes
con nuestras reglas éticas nunca las romperemos. Si no son muy intensas algunas veces dejamos que las
condiciones cambien la regla. Si somos indiferentes, frecuentemente dejamos que otros tomen las decisiones.

La mayoría de las organizaciones o compañías tienen hoy sus códigos de ética los cuales establecen la
conducta esperada de sus empleados/miembros y las normas de la misma. El comportamiento ético en el
entorno diario es el resultante de la consideración de ambos comportamientos (el personal y el de negocios).
Generalmente en cualquier cuestión o duda de problemas éticos relacionados con el trabajo, el empleador
mantiene el mayor poder y usualmente el empleador ejecuta su mayor presión en los asuntos financieros. La
diferencia más importante se manifiesta cuando elementos importantes de la ética personal entran en conflicto
con presiones impuestas por el negocio.
A escalas más cotidianas, la actividad profesional nos pone con
frecuencia ante dilemas éticos, situaciones donde se ponen a prueba los
valores que todos poseemos y la fuerza con la que estamos dispuestos
a mantenerlos. En algunos casos, la inclusión de estos temas para su
estudio no solo proviene de las autoridades académicas sino de la
demanda de los propios alumnos, cada vez más interesados en
programas vinculados con la comunidad, con el sector de las ONG
(organizaciones no gubernamentales) y temas medioambientales como
por ejemplo métodos para ahorrar energía y agua, el control de
contaminación, mejora de ambientes de trabajo, etc.

Ética y Liderazgo

El “Liderazgo Ético” es una necesidad que hace mejor y más rica a la empresa. Por el contrario, si se busca el
enriquecimiento acelerado y sobre bases ilícitas, la empresa se condena a sí misma.

Ya en estos tiempos, nadie puede negar la importancia de la inteligencia emocional para la toma de
decisiones en las empresas; que el cliente es cada día más y más exigente y más difícil de engañar; que el
mundo entero se ha reducido por efecto del inmenso desarrollo de las telecomunicaciones y que el temor a
una demanda por efecto de un error que afecte a terceros, es ahora muy latente en todos. Es por eso que la
ética empresarial está teniendo, hoy más que nunca, una presencia determinante en la dinámica de las
empresas modernas.

Es el momento de valorizar o revalorizar las actitudes y valores gerenciales, de tal manera que se comprenda
que la ética empresarial es ahora una necesidad y no una virtud. Ciertamente, estudios actuales revelan que
las empresas internacionales están sometidas a una creciente presión para que las conductas de sus líderes
de negocios se adecuen a comportamientos éticos. Y algunos hechos confirman que las actitudes
relacionadas con malos manejos gerenciales están siendo castigados con multas millonarias.

Más profundamente la ética empresarial, tiene mucha relación con el acatamiento de las leyes,
independientemente de los países en que se aplican. Y aún en aquellas naciones donde existe la impunidad,
la ética debe correr la suerte de emerger, para ubicarse sobre los pilares de la corrupción, el tráfico de
influencias y otras desviaciones mayores o menores que atentan contra la vida y dignidad de las personas.

En la actualidad, hasta el gerente más pragmático necesita actuar con ética, porque el actuar ético, está
demostrando, que le da vida permanente a los negocios, todo porque se adquiere credibilidad y confianza, y
las personas terminan siendo leales a los productos o a las marcas

Está comprobado que la adherencia a códigos éticos incrementa la efectividad del liderazgo hasta en un
500%. Los individuos líderes con fuertes creencias éticas, que demuestran un comportamiento constante y
consistente con sus valores éticos, provoca que sus seguidores puedan confiar y depender plenamente de
sus acciones.
Ética en los Negocios

El conjunto de valores, principios y creencias que posee una organización de forma distintiva se denomina
como cultura organizacional, que es también definida “como el conjunto de procedimientos y conductas
gerenciales que sirven de ejemplo y refuerzan los principios básicos” (Denison, 1991). Estos principios y
procedimientos perduran al tener un significado importante y compartido por cada uno de sus miembros.

La cultura de una organización se inicia a partir de la filosofía de sus fundadores y se mantiene a través de la
influencia y reforzamiento de sus líderes. La cultura determina el criterio de aceptación de cada uno de sus
miembros y es trasmitida de diversas maneras: historias o anécdotas, rituales, símbolos materiales y lenguaje.
Su estudio es de gran importancia para el mejoramiento de la productividad y del clima organizacional. La
cultura organizacional influye en el comportamiento ético y desempeño de la organización, tanto a nivel
individual como en su conjunto. Las diferentes organizaciones aplican normas éticas (códigos de ética) para
orientar sus relaciones y decisiones internas y externas. El comportamiento que expresa la organización se
encuentra influenciado o regido por lo que se ha denominado como ética de negocios o empresarial.

La ética empresarial es el conjunto de principios y normas que guían el comportamiento en el mundo de los
negocios. La ética en las organizaciones puede ser afectada por diversos factores: desarrollo moral de sus
gerentes o líderes; sistemas de valores individuales; contenido y fortaleza de la cultura organizacional;
diseños estructurales de la organización que permiten la ambigüedad; intensidad del problema ético.

Desde hace algún tiempo, más aun en la actualidad, la ética en los negocios ha sido objeto de revisión por
presentar dilemas éticos difíciles en distintas áreas y escenarios. En ese sentido, es obligación de las
empresas determinar si realmente están aplicando actividades éticas y si son socialmente responsables. La
responsabilidad social, es la obligación hacia la sociedad asumida por las empresas más allá de las
finalidades económicas; tiene que ver con la forma como la organización afecta la sociedad en la que existe.
¿Por qué la ética debe estar presente en los negocios? Una respuesta a esta pregunta es que la ética debe
gobernar todas las actividades humanas voluntarias, y como los negocios son una actividad humana y
voluntaria, también debería regir a los mismos. Además, los negocios son una actividad cooperativa que exige
un comportamiento ético. Por ejemplo, un negocio se arruinaría si todos sus gerentes, empleados y clientes
llegaran a pensar que es moralmente permisible robar, mentir, o quebrantar sus acuerdos con la empresa.
Hoy son varios los casos de empresas en todo el mundo que produjeron (o producen) fraude, asociación
ilícita, tergiversación de información económico-financiera, falta de transparencia, corrupción, etc. Algunos
pueden buscar causas en los sistemas de control interno de las empresas o en las auditorias externas, que
podrían ser débiles o que no estén lo suficientemente desarrollados. También se apunta a las normas técnicas
de la contabilidad, que podrían estar mostrando fisuras en su estructura, por las que puede ocultarse
información en forma aparentemente legal. De esta manera se evita mostrar datos que podrían comprometer
a la empresa o desalentar a los inversores, usando técnicas o movimientos que las normas no prohíben.

Aunque existan los mejores sistemas de control, siempre hay personas

que pueden tener el poder o la habilidad de estar por encima de esos
controles, pudiendo vulnerarlos o sortearlos. Si sus ambiciones son
más importantes que la ética o valores, usarán ese poder o habilidad
para violentar los sistemas y alcanzar sus metas. De hecho las
corporaciones multinacionales hoy en día tienen más poder que los
propios gobiernos. Me permito sugerir al lector si tiene la oportunidad
de ver el video “The Corporation” (algunos capítulos pueden
encontrarlos en Google), en donde queda manifestado que los
grandes grupos económicos mundiales produjeron niveles
impredecibles de riqueza, pero a que costo? Algunos ejemplos que
podemos ver en dicho film permiten comprobar la personalidad anti-
social y amoral que tienen algunas corporaciones al dañar
directamente a los trabajadores, la salud, la biosfera, etc. La
personalidad sicopática de algunas empresas en la búsqueda de
ganancias no tiene limites, hoy en día animales, plantas, el ADN,
vacunas, y quien sabe hasta que otro componente del planeta es
factible de ser patentado por las corporaciones.

Resulta patético y alarmante ver los nombres de algunas corporaciones como ejemplos de este
comportamiento (sobre todo cuando alguien trabajó o está trabajando en algunas de esas empresas). El
dilema se presenta en saber hasta dónde uno puede hacer valer sus propios principios morales y éticos
siendo que trabaja en una compañía que a veces no los tiene. Personalmente me he encontrado con algunos
de dichos dilemas y en algunos casos me ha costado el empleo mismo. Las compañías las conforman
individuos y entonces será un gran desafío para las empresas o algún ente que las regule desarrollar e
implementar maneras para que todo el personal, desde los máximos gerentes hasta el empleado de línea, se
sienta motivado para que su comportamiento sea ético.

Que una empresa cuente con un personal que tiene claridad de principios éticos para actuar, y además se
siente valorado por eso, es un primer e importante paso para que llegue a ser una empresa ética, como
institución. Cuando una organización tiene una definida vocación por la ética, su dirección está comprometida
en resaltarla, teniendo el deseo de mostrar los valores que creen que son los fundamentales, se puede utilizar
el Código de Ética para hacer explícito todo esto.

Muchas organizaciones buscan hoy crear su Código de Ética. Esta tendencia que a primera vista puede
asemejarse a una moda, parece estar entrando de forma más profunda en el tejido social y en algunas
empresas. Los ciudadanos en todo el mundo dan muestras de cansancio con relación a la corrupción, al error,
al hacer mal que se corresponde con ser víctima de lo que otros hacen mal. Este trabajo se puede hacer entre
personas, colegas y competidores, que no tienen vergüenza de actuar bien y se disponen a liderar el proceso
de cambio que la sociedad ansía, el problema es no quedarse en una intención puesta en un papel para
demostrar que la compañía tiene sus valores éticos y sociales sino en acciones concretas.