Una guía al cuerpo de conocimientos de la Administración de Proyectos (página 2)

1. Hemos cambiado el título para enfatizar que
   este documento no es el PMBOK. El documento de 1987
   definía al PMBOK como "todos los tópicos,
   áreas de materia y
   procesos
   intelectuales que están involucrados en las
   prácticas de principios
   administrativos sanos a los …proyectos".
   Claramente se observa que un solo documento nunca
   contendrá la totalidad del PMBOK.
2. Hemos reescrito completamente la sección del
   Marco
   Teórico. La nueva sección consiste de tres
   capítulos:

• Introducción, que fija el propósito
  del documento y define de manera extensa los términos
  "proyecto" y
  "administración de
  proyectos".
• El Contexto de la Administración de
  Proyectos, que cubre el contexto en el que operan los
  proyectos – el ciclo de
  vida del proyecto, las perspectivas de los partidos
  interesados, influencias externas, y habilidades claves de la
  administración general.
• Los Procesos
  Administrativos de los Proyectos, que describe como los
  elementos varios de la administración de proyectos se
  interelacionan.

1. Hemos desarrollado una definición revisada de
   "proyecto". Queríamos una definición que era
   tanto inclusiva (no debería ser posible identificar
   cualquier empresa
   generalmente considerada como un proyecto que no llene la
   definición) y exclusiva (no debería ser posible
   identificar cualquier empresa que satisfaga la
   definición y que generalmente no se piensa como
   proyecto). Se revisaron muchas de las definiciones de proyecto
   en la literatura
   existente y se encontraron todas insatisfactorias de alguna
   manera. La nueva definición es motivada por las características únicas de un
   proyecto: un proyecto es una tarea temporal desarrollada para
   crear un producto o
   servicio
   único.
2. Hemos desarrollado una nueva vista del ciclo de vida
   del proyecto. El documento de 1987 definía las fases de
   proyecto como subdivisiones del ciclo de vida del proyecto.
   Hemos reordenado estas relaciones y definido el ciclo de vida
   del proyecto como una colección de fases cuyos
   números y nombres están determinados por las
   necesidades de control de
   la
   organización ejecutora.
3. Hemos cambiado los nombres de las principales
   secciones de "función"
   a "área de conocimiento". El termino "función" ha
   sido frecuentemente malentendido como un elemento de la
   organización funcional. El cambio de
   nombre deberá de eliminar este malentendido.
4. Reconocemos formalmente la existencia de una novena
   área de conocimiento. Ha existido un consenso amplio
   durante algún tiempo de que
   la administración de proyectos es un proceso
   integrativo. El Capítulo 4, Administración de la
   Integración de Proyecto, reconoce la
   importancia de este tema.
5. Hemos agregado la palabra "proyecto" al título
   de cada área de conocimiento. Aunque esto pueda parecer
   redundante, ayuda a clarificar el alcance de este documento.
   Por ejemplo, La Administración de Recursos Humanos cubre
   solo esos aspectos de la administración de recursos
   humanos que son únicos o casi únicos al
   contexto de proyectos.
6. Hemos escogido describir las áreas de
   conocimiento en términos de sus componentes de proceso.
   La búsqueda de un método
   consistente de presentación nos ha llevado a
   reestructurar completamente el documento de 1987 en 37
   "procesos administrativos de proyectos". Cada proceso esta
   descrito en términos de sus entradas, salidas, herramientas
   y técnicas. Las entradas y salidas son
   documentos
   (e.g., una declaración de alcance) o ítems
   documentables (e.g., dependencias de actividades). Las
   herramientas y técnicas son los mecanismos aplicados a
   las entradas para crear las salidas. Además de su
   simplicidad fundamental, esta aproximación ofrece otros
   beneficios, a saber:

• Enfatiza las interacciones entre las áreas
  de conocimiento. Las salidas de un proceso se convierten en
  entradas para otro.
• La estructura
  es flexible y robusta. Cambios en conocimientos y
  prácticas pueden ser acomodados agregando un nuevo
  proceso, cambiando las secuencias de procesos, subdividiendo
  un proceso, o al agregar material descriptivo dentro de un
  proceso.
• Los procesos están en el núcleo de
  otros standards. Por ejemplo, los standards de calidad de la
  Organización Internacional de Standards (serie
  ISO 9000)
  se basan en la identificación de los procesos de
  negocios.

1. Agregamos algunas ilustraciones. Cuando se trata de
   estructuras de desglose de trabajo, diagramas de
   red, y curvas
   S, una imagen vale
   más que mil palabras.

    

   Número y Nombre de 1987	Número y Nombre de 1996
   0. Standards PMBOK	B. Evolución de Una Guía al Cuerpo de Conocimientos de la Administración de Proyectos de PMI
   1. Marco Teórico: El Raciocinio	1. Introducción (definiciones básicas)
   	2. El Contexto del Proyecto (ciclos de vida)
   2. Marco Teórico: Una Reseña	1. Porciones varias
   	2. Porciones varias
   	3. Porciones varias
   3. Marco Teórico: Un Modelo Integrativo	3. Procesos Administrativos de Proyectos
   	4. Administración de Integración del Proyecto
   4. Glosario de Términos Generales	IV. Glosario
   A. Administración del Alcance	5. Administración del Alcance del Proyecto
   B. Administración de la Calidad	8. Administración de la Calidad del Proyecto
   C. Administración del Tiempo	6. Administración de Tiempo del Proyecto
   D. Administración de Costos	7. Administración de Costos del Proyecto
   E. Administración de Riesgos	11. Administración de Riesgos del Proyecto
   F. Administración del Recurso Humano	9. Administración del Recurso Humano del Proyecto
   G. Administración de Contratos/Procuración	12. Administración del Procuramiento del Proyecto
   H. Administración de Comunicaciones	10. Administración de las Comunicaciones del Proyecto

2. Hemos reorganizado el documento de manera
   significativa. La siguiente tabla provee una comparación
   entre los encabezados del documento de 1987 con
   este:
3. "clasificar a" ha sido removido de la lista de
   propósitos. Tanto este documento como la versión
   de 1987 proveen una estructura para organizar el
   conocimiento de la administración de proyectos, pero
   ninguna es particularmente útil como una herramienta de
   clasificación. Primero, los tópicos incluidos no
   están completos – no incluyen prácticas
   innovadoras o inusuales. Segundo, muchos elementos tienen
   relevancia en más de un área de conocimiento o
   proceso de tal manera que las categorías no son
   únicas.

El Marco de la
Administración de Proyectos

INTRODUCCIÓN

El cuerpo de conocimiento de proyectos (PMBOK) es un
término inclusivo que describe la suma de los
conocimientos dentro de la profesión de
administración de proyectos. Como en otras profesiones
tales como: medicina,
abogacía, contaduría, el cuerpo del conocimiento
recae sobre profesionales y académicos que aplican ese
conocimiento y lo avanzan. El PMBOK entero incluye conocimiento
probado y prácticas tradicionales que se aplican
ampliamente, además del conocimiento e innovaciones de
prácticas avanzadas que han visto un uso más
limitado.

Este capitulo define y explica varios términos
claves y provee una vista general del resto del documento.
Además incluye las siguientes secciones
principales:

1.1 Propósito de este
documento

1.2 Qué es un proyecto?

1.3 Qué es la administración de
proyectos?

1.4 Relación con otras disciplinas de
administración

1.5 Tareas relacionadas

Propósito de este
Documento

El propósito primario de este documento es
identificar y describir ese subjuego del PMBOK que es
generalmente aceptado. Generalmente aceptado quiere decir que el
conocimiento y las prácticas descritas son aplicables a la
mayoría de los proyectos la mayoría de las veces, y
que hay un consenso amplio sobre su valor y
utilidad.
Generalmente aceptado no quiere decir que las prácticas y
el conocimiento son o deben ser aplicadas uniformemente a todos
los proyectos; el equipo de administración de proyectos
siempre será responsable de determinar que es apropiado
para cualquier proyecto dado.

Este documento también intenta proveer un
léxico común dentro de la profesión para
poder hablar
de la administración de proyectos. La
administración de proyectos es una profesión
relativamente joven, y mientras que hay un entendimiento
común de que es lo que hace, hay poco conocimiento
relativo de los términos que se usan.

Este documento provee una referencia básica para
cualquiera que este interesado en la profesión de
administración de proyectos. Esto incluye, pero no esta
limitado a:

• Administradores de proyectos y otros miembros del
  equipo de administración del proyecto.
• Administradores de administradores de
  proyecto.
• Los dueños del proyecto y otros partidos
  interesados.
• Administradores funcionales y empleados asignados
  al equipo de proyectos.
• Educadores que enseñan administración
  de proyectos y materias relacionadas.
• Consultores y otros especialistas en
  administración de proyectos y campos
  relacionados.
• Entrenadores desarrollando proyectos educativos en
  administración de proyectos.

Como una referencia básica, este documento no es
ni compresivo ni todo inclusivo. El apéndice E discute
extensiones en áreas de aplicación mientras que el
apéndice F lista fuentes de
otra información en administración de
proyectos.

Este documento también es usado por el instituto
de administración de proyectos para proveer una estructura
consistente para sus programas de
desarrollo
profesional que incluyen:

• Certificación de administradores de
  proyectos profesionales (PMP’s).
• Acreditación de institutos educativos que
  enseñan administración de
  proyectos.

¿Qué es un
proyecto?

Las organizaciones
trabajan. El trabajo
generalmente involucra operaciones o
proyectos, aunque las dos se puedan traslapar. Las operaciones y
los proyectos comparten muchas características; por
ejemplo, ellas son:

• Desarrolladas por personas.
• Limitadas por recursos
  escasos.
• Son planeadas, ejecutadas, y
  controladas.

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

Los proyectos son desarrollados en todos los niveles de
la organización. Estos pueden involucrar a una sola
persona o a
muchas miles. Y pueden requerir menos de 100 horas para
completarse o más de 10,000,000. Los proyectos pueden
involucrar a una sola unidad de una organización o cruzar
muchas fronteras organizacionales como en consorcios o sociedades de
hecho. Los proyectos son muchas veces componentes críticos
de la estrategia de
negocios de la organización que los desarrolla. Ejemplos
de proyectos pueden incluir:

• Desarrollar un nuevo producto o
  servicio.
• Efectuar un cambio de estructura, de personal, o
  de estilo en una organización.
• Desarrollar un nuevo vehículo de transporte.
• Desarrollar o adquirir un nuevo sistema de
  información.
• Construir o desarrollar una construcción.
• Administrar una campaña
  electoral.
• Implementar un nuevo procedimiento
  o proceso en un negocio.

Carácter Temporal

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

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

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

La naturaleza
temporal de los proyectos se pueden aplicar a otros aspectos del
desarrollo tales como:

• La oportunidad de la ventana de mercado es
  usualmente temporal — La mayoría de los
  proyectos tienen un marco de tiempo limitado en el que tiene
  que producir su producto o servicio.
• El equipo de proyecto, como un equipo, rara vez
  dura más que el proyecto— la mayoría de
  los proyectos son desarrollado por un equipo creado con el
  sólo propósito de desarrollar el proyecto, y el
  equipo es desmantelado y sus miembros reasignados cuando el
  proyecto se termine.

Producto o Servicio Único

Los proyectos involucran hacer algo que no se ha hecho
antes, por lo tanto, es único. Un producto o un servicio
puede ser único aunque la categoría a la que
pertenezca sea grande. Por ejemplo, muchos miles de edificios de
oficina han
sido desarrollados, pero cada edificio en si es único
— de distinto dueño, de distinto diseño,
diferente locación, y diferentes contratistas, y
así etc. La presencia de elementos repetitivos no cambia
fundamentalmente la característica de ser único.
Por ejemplo:

• Un proyecto para desarrollar una vía
  comercial puede requerir múltiples
  prototipos
• Un proyecto para introducir una nueva droga al
  mercado puede requerir de miles de dosis durante las pruebas
  clínicas.
• Un proyecto de desarrollo de bien raíz puede
  incluir cientos de unidades individuales.

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

La elaboración progresiva de las
características de un producto debe ser cuidadosamente
coordinada en concordancia con una apropiada definición
del alcance del proyecto, particularmente si el proyecto es
desarrollado bajo un contrato. Cuando
definida propiamente, el alcance del proyecto – el trabajo a
realizar – deberá mantenerse constante aún en la
luz del cambio
las características del producto que sea progresivamente
elaborado. La relación entre el alcance del proyecto y el
alcance del producto será discutido con más detalle
en la introducción al capítulo 5.

Para mostrar dos ejemplos ilustrativos de
elaboración progresiva en dos redes de aplicación
distintas, tenemos:

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

Ejemplo 2. El producto de un proyecto de
desarrollo biofarmaceútico puede ser inicialmente definido
como "Pruebas clínicas de XYZ" debido a que el
número de pruebas y el tamaño de cada una de ellas,
es desconocido. A medida que el proyecto avanza, el producto
puede ser descrito más explícitamente "Ensayos de
la fase III, ensayo 4 de la
fase II y ensayo 2 de la fase III". La siguiente ronda de
elaboración progresiva puede enfocarse exclusivamente en
el protocolo de los
ensayos de la fase I – es decir que pacientes reciben que dosis y
que tan frecuentemente. En las etapas finales del proyecto, los
ensayos de la fase III serían explícitamente
definidos con base en información recogida y analizada
durante los ensayos de la fase I y fase II.

¿Qué es la
Administración de Proyectos?

La administración de proyectos es la
aplicación de conocimiento, habilidades, herramientas, y
técnicas a actividades de proyectos de manera que cumplan
o excedan las necesidades y expectativas de partidos interesados
de un proyecto. Cumplir o exceder las necesidades o expectativas
de los partidos interesados invariablemente involucran balancear
demandas que compiten entre sí, tales como:

• Alcance, tiempo, costo y
  calidad.
• Partidos interesados con diferentes necesidades y
  expectativas.
• Requerimientos identificados (necesidades) y
  requerimientos no identificados (expectativas).

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

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

El Marco de la Administración de
Proyectos

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

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

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

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

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

Parte II, las Áreas de Conocimiento de la
Administración de Proyecto, describen conocimiento y
prácticas de la administración de proyectos en
término de sus componentes de proceso. Estos procesos han
sido organizados en nueve áreas de conocimiento, tal como
se describen a continuación e ilustradas en la Figura
1-1.

Capítulo 4, Administración de la
Integración de Proyectos, describe los procesos
requeridos para asegurar que los elementos varios de un proyecto
están

coordinados apropiadamente. Consiste del desarrollo de
un plan de proyecto,
ejecución del plan de proyecto, y el control de cambios en
general.

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

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

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

Capítulo 8, Administración de la
Calidad del Proyecto, describe los procesos requeridos para
asegurar que el proyecto satisfacerá las necesidades para
lo cual fue desarrollado. Consiste en la planeación de la
calidad, aseguranza de la calidad, y control de
calidad.

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

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

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

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

Relación con Otras
Disciplinas de Administración

Mucho del conocimiento requerido para administrar
proyectos es único o casi único a la
administración de proyectos (e.g. análisis de la
ruta crítica y estructura de desglose de trabajo). Sin
embargo, el PMBOK traslapa con otras disciplinas de
administración tal como se ilustra en la Figura
1-2.

La Administración General, comprende planear,
organizar, la consecución de recursos humanos, ejecutar, y
controlar las operaciones de una empresa en
funcionamiento continuo. La administración general
también incluye disciplinas de soporte tales como:
Programación de computadoras,
abogacía, estadística y teorías
de probabilidad,
logística, y administración
de personal. El PMBOK traslapa la administración
general en muchas áreas — comportamiento
organizacional, proyecciones financieras, y técnicas
de planeación sólo para nombrar algunas pocas. La
sección 2.4 provee una discusión más
detallada de la administración general.

Las áreas de aplicación son
categorías de proyectos que tienen elementos comunes
significativos en tales proyectos pero que no son requeridos o
presentes en todos los proyectos. Las áreas de
aplicación usualmente están definidas en
términos de:

• Elementos técnicos, tales como, desarrollo
  de software,
  drogas
  farmacéuticas, o ingeniería de
  construcción.
• Elementos de la administración, tales como,
  contratos con el gobierno o
  desarrollo de nuevos productos.
• Grupos de industria,
  tales como los de automóviles, químicos o de
  servicios financieros.

El apéndice E incluye una discusión
más detallada de las áreas de aplicación de
los proyectos.

Tareas Relacionadas

Ciertos tipos de eventos
están ligados de manera muy cercana a los proyectos.
Estos desarrollos relacionados se describen a
continuación

Programas. Un programa es un
grupo de
proyectos administrado de una manera coordinada de tal manera que
se obtienen beneficios que no se pueden obtener al administrar
los proyectos individualmente [2]. Muchos programas incluyen
también elementos de operaciones sucesivas. Por
ejemplo:

• El "programa de avión XYZ" incluye tanto el
  proyecto o proyectos de diseño y desarrollo del
  avión como la manufactura y soporte del avión en el
  campo de pruebas.
• Muchas firmas electrónicas tienen
  "administradores de programa" que son responsables tanto por
  la entrega de productos individuales (proyectos) y de la
  coordinación de múltiples
  entregas sobre un período de tiempo (una
  operación en desarrollo).
• Los programas también involucran una serie
  de desarrollo cíclicos o repetitivos, por
  ejemplo:
• Las compañías de servicios
  públicos muchas veces hablan de "un programa de
  construcción" que es una operación sucesiva y
  regular que involucra muchos proyectos.
• Muchas organizaciones sin ánimo de lucro
  tienen un "programa de captación de fondos" que es un
  esfuerzo continúo para obtener apoyo financiero que
  muchas veces involucra una serie de proyectos discretos tales
  como funciones de
  beneficencia o remates.
• Publicar un periódico o una revista es
  también un programa — el
  periódico en si es un esfuerzo continúo,
  pero cada edición es en si un proyecto.

En algunas áreas de aplicación, la
administración de programas y la administración de
proyectos se tratan como sinónimos; en otras, la
administración de proyectos es un subproyecto del programa
de administración. Ocasionalmente, la
administración de programas es considerada como un
subproyecto de la administración de proyectos. Esta
diversidad de definiciones hace que sea imperativa que cualquier
discusión de la administración de programas versus
administración de proyectos sea precedida por un acuerdo
claro y consistente de la definición de cada
término.

Subproyectos. Los proyectos frecuentemente
están divididos en componentes más manejables o
subproyectos los subproyectos son muchas veces contratados con
una entidad externa o con otra unidad funcional de la
organización ejecutora. Ejemplos de subproyectos pueden
incluir:

• Una fase de proyecto (las fases del proyecto se
  describen en la Sección 2.1).
• La instalación de la plomería o
  electricidad
  en un proyecto de construcción.
• Pruebas automatizadas de programas de computadora en un proyecto de desarrollo de
  software.
• Manufactura de alto volumen para
  dar soporte a las pruebas clínicas de una nueva droga
  en un proyecto de desarrollo e investigación
  farmaceútica.

Sin embargo, desde la perspectiva de una
organización ejecutora un subproyecto es muchas veces
pensado más como un servicio que un producto, y este
servicio es único. Por lo tanto los subproyectos
serán referidos típicamente como proyectos y
serán administrados como tal.

NOTAS:

El
Contexto de la
Administración de Proyectos

Los proyectos y la
administración de proyectos operan en un
ambiente
más amplio que el del proyecto mismo.
El equipo de administración de proyectos debe entender
este contexto más amplio – administrar día a
día la actividades del proyecto es necesario para el
éxito
de este, pero no suficiente. Este capítulo describe
aspectos claves del contexto de la administración de
proyectos, que no están descritos en otras partes de este
documento. Los tópicos incluidos aquí
son:

2.1 Fases del Proyecto y el Ciclo de
Vida del Proyecto

2.2 Los Partidos Interesados del
Proyecto

2.3 Influencias Organizacionales.

2.4 Habilidades Claves de Administración
General

2.5 Influencia
Socioeconómicas

Fases del Proyecto y Ciclo de Vida del
Proyecto

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

Características de las Fases del
Proyecto

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

La conclusión de una fase de proyecto es
generalmente marcada por la revisión de tanto las entregas
como del desempeño del proyecto para poder (a)
determinar si el proyecto debe continuar a su próxima fase
y (b) detectar y corregir errores de manera eficiente. Estas
revisiones de final de fase generalmente se llaman salidas de
fase, puertas de fase o puntos muertos.

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

Características del Ciclo de Vida del
Proyecto

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

factibilidad es tratado como la primer fase de vida del
proyecto o como un proyecto independiente.

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

La secuencia de fase definida por la mayoría de
los ciclos de vida del proyecto generalmente involucran
algún tipo de transferencia en tecnología o
intercambios tales como los requerimientos para diseñar,
construcción para operaciones o diseño para
manufactura.
Entregas de la fase precedente son usualmente aprobadas antes que
comience el trabajo en
la fase siguiente. Sin embargo, una fase subsiguiente es a veces
comenzada antes de la aprobación de las entregas de la
fase anterior cuando los riesgos
involucrados se tornan aceptables. Esta táctica de
traslapo de fases muchas veces es llamada "Fast
Tracking".

Los ciclos de vida del proyecto generalmente
definen:

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

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

La mayoría de las descripciones de ciclo de vida
del proyecto comparten un número de características comunes:

• Los niveles de empleados y costos son
  bajos al comienzo, más altos hacia el final, y caen
  rápidamente a medida que se llega a la
  finalización. Este patrón se ilustra en la
  Figura 2-1.

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

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

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

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

Ciclos de Vida de Proyecto
Representativas

Los siguientes ciclos de vida del proyecto se han
escogido para ilustrar la diversidad de aproximaciones en uso.
Los ejemplos mostrados son típicos; no son ni recomendados
ni preferidos. En cada caso, los nombres de fases y las entregas
más grandes son las descritas por los autores.

/

Adquisiciones de Defensa La directiva 5000.2 del
Departamento de Defensa de los Estados Unidos,
tal como lo indica la revisión de febrero de 1993,
describe una serie de hitos y fases de adquisición tal
como se ilustran en la Figura 2-2 .

• Determinación de la Necesidad de la Misión
  — termina con la Aprobación de los Estudios
  Conceptuales.
• Exploración de Conceptos y Definiciones
  — termina con la Aprobación de la
  Demostración de Conceptos.
• Demostración y Validación —
  termina con la Aprobación de Desarrollo.
• Desarrollo de la Ingeniería y Manufactura
  — se traslapa con Operaciones y Soporte
  sucesivas.

Construcción. Morris [1] describe el
ciclo de vida de un proyecto de construcción como se
ilustra en la Figura 2-3.

• Factibilidad — formulación del
  proyecto, estudios de factibilidad, y diseños de
  estrategia
  y aprobación. Una decisión de seguir – no
  seguir es hecha a la terminación de esta
  fase.
• Planeación y Diseño —
  diseño de base, costos y cronogramas, términos
  del contrato y
  condiciones, y planeación detallada. Los contratos
  principales son adjudicados al final de esta
  fase.
• Producción — manufactura, entrega,
  obra civil, instalación, y pruebas.
  La factibilidad es terminada sustancialmente al completar
  esta fase.
• Entrega y Comienzo de Operaciones — ensayos
  finales y mantenimiento. La operación debe estar
  en pleno funcionamiento al terminar esta fase.

Farmaceúticas. Murphy [2] describe el
ciclo de vida del proyecto para el desarrollo de un nuevo
producto farmacéutico en los Estados Unidos como se
ilustra en la Figura 2-4.

• Descubrimiento y Selección — incluye investigación básica y aplicada
  para identificar candidatos para los ensayos
  preclínicos.

• Desarrollo Preclínico — incluye
  ensayos de laboratorio y en animales para
  determinar su seguridad
  y eficacia
  así también para la preparación y
  formulación de una aplicación de
  Investigación de una Nueva Droga
  (IND).
• Trabajo para los Registros— incluye ensayos de Fase
  Clínica I, II, y III así como también la
  preparación y formulación para una
  Aplicación de una Nueva Droga (NDA).
• Actividades después de la
  Remisión—incluye trabajo adicional tal como se
  requiera para darle soporte a la revisión de la NDA
  que haga la Administración de Comidas y Drogas
  (FDA).

Desarrollo de Software. Muench, et.al. [3]
Describe un modelo espiral
para desarrollo de software con cuatro ciclos y cuatro cuadrantes
como se ilustra en la Figura 2-5:

• Ciclo de prueba de concepto
  — captura los requerimientos del negocio, define metas
  para la prueba del concepto produce diseños
  conceptuales de sistema,
  diseño y construcción de la prueba del
  concepto, produce planos para el ensayo
  de la aceptación, conduce a análisis de riesgo y hace
  recomendaciones.
• Ciclo de la primera construcción —
  deriva requerimientos del sistema, define metas para la
  primera construcción, produce diseños de los
  sistemas
  lógicos, diseño y construcción del
  primer modelo, produce planos para los ensayos del sistema,
  evalúa la primera construcción y hace
  recomendaciones.
• Ciclo de la segunda construcción —
  deriva requerimientos del sistema, define metas para la
  segunda construcción, produce diseños
  físicos, construye el segundo modelo, produce planos
  para los ensayos del sistema, evalúa la segunda
  construcción y hace recomendaciones.
• Ciclo final — completa los requerimientos de
  la unidad, diseño final, construye el modelo final,
  hace ensayos de unidad, subsistema, sistema, y
  aceptación.

Partidos Interesados en el
Proyecto

Los partidos interesados son individuos y organizaciones
que están activamente interesados en el proyecto, o cuyos
intereses pueden ser afectados positiva o negativamente como
resultado de la ejecución del proyecto o de la
terminación exitosa del proyecto. El equipo de
administración del proyecto debe identificar a los
partidos interesados en el proyecto, determinar cuales son sus
necesidades y

expectativas, y administrar e influenciar esas
expectativas para asegurar un proyecto exitoso. La
identificación de los partidos interesados en el proyecto
es a veces difícil.

Por ejemplo, ¿Es un obrero de una línea de
ensamblaje cuyo futuro empleo depende
del resultado de un nuevo proyecto de diseño, un partido
interesado en el proyecto?

Los partidos claves en cada proyecto
incluyen:

• Administradores de proyectos — el individuo
  responsable por administrar el proyecto.
• Cliente — el individuo u organización
  que usará el producto del proyecto. Puede haber
  múltiples capas de clientes.
  Por ejemplo, los clientes para un nuevo producto
  farmacéutico pueden incluir a los doctores que los
  prescriben, los pacientes que lo toman y a las
  compañías aseguradoras que pagan por
  el.
• La organización ejecutora — la
  organización cuyos empleados que están
  más directamente en el trabajo del
  proyecto.
• El patrocinador — el individuo o grupo
  dentro de la organización ejecutora que provee los
  recursos
  financieros en efectivo o en especie, para el
  proyecto.

Adicionalmente a estos hay muchos nombres y
categorías distintas para los partidos interesados en el
proyecto – interno y externo, dueños y fundadores,
proveedores y
contratistas, miembros del equipo y sus familias, agencias
gubernamentales y compañías de medios de
comunicación, ciudadanos individuales, organizaciones
de lobby permanentes o temporales, y la sociedad en
general. El nombramiento o agrupamiento de los partidos
interesados en el proyecto es una ayuda principalmente para
identificar que individuos u organizaciones se ven a ellos mismos
como partidos interesados. Los roles de los partidos interesados
y sus responsabilidades se pueden traslapar, así como
cuando una firma de ingeniería provee financiación
para una planta que esta diseñando.

Administrar las expectativas de los partidos
interesados puede ser difícil porque los partidos
interesados muchas veces tienen objetivos
muy distintos, que pueden entrar en conflicto.
Por ejemplo:

• El administrador
  de un departamento que ha pedido un nuevo sistema de manejo
  de información, puede desear un bajo
  costo, el arquitecto del diseño puede enfatizar el
  aspecto técnico, y el contratista de programación puede estar interesado en
  maximizar sus ganancias.
• El vicepresidente de investigación de una
  firma electrónica puede definir el
  éxito de un nuevo producto como estado del
  arte de la
  tecnología, el vicepresidente de manufactura puede
  definirlo como prácticas a nivel global y el
  vicepresidente de mercadeo
  puede estar preocupado principalmente con el número de
  nuevas innovaciones que traiga el producto.
• El dueño de un proyecto de desarrollo de
  bien raíz puede estar enfocado en una ejecución
  a tiempo, el
  cuerpo gobernante local puede desear maximizar sus impuestos
  prediales, y un grupo ambiental puede desear minimizar el
  impacto
  ambiental, y los residentes locales pueden desear la
  relocalización del proyecto.

En general, las diferencias entre los distintos partidos
interesados se deben resolver en favor del cliente. Esto no
quiere decir, sin embargo, que las necesidades y expectativas de
otros partidos interesados sean o deban ser descartadas.
Encontrar las respuestas apropiadas para estas diferencias debe
ser uno de los mayores retos para el administrador de
proyectos.

Influencias Organizacionales

Los proyectos son parte típicamente de una
organización más grande que el proyecto mismo –
corporaciones, agencias gubernamentales, instituciones
de salud, cuerpos
internacionales, asociaciones profesionales, y otros. Aún
cuando el proyecto es la organización (consorcios,
sociedades de
hecho), el proyecto aún estará influenciado por la
organización u organizaciones que lo conforman. La
siguiente sección describe aspectos claves de estas
estructuras
organizacionales más grandes que con seguridad
influenciaran el proyecto.

Sistemas Organizacionales

Las organizaciones basadas en proyectos son aquellas
cuyas operaciones consistirán principalmente del proyecto.
Estas organizaciones caen en dos categorías:

• Organizaciones que derivan sus entradas
  principalmente de ejecutar proyectos para otros – firmas de
  arquitectos, firmas de ingeniería, consultores,
  contratistas de construcción, contratistas para el
  gobierno,
  etc.
• Organizaciones que han adoptado la
  administración por proyectos (vea Sección
  1.3).

Estas organizaciones tienden a tener sistemas
administrativos para facilitar la administración de
proyectos. Por ejemplo, sus sistemas financieros mucha veces
están diseñados específicamente para
contabilizar, controlar, y reportar sobre múltiples
proyectos simultáneos.

Organizaciones no basadas en proyectos –
compañías de manufactura, firmas de servicios
financieros, etc. -rara vez tienen sistemas administrativos
diseñados para soportar las necesidades de los proyectos
eficiente y efectivamente. La ausencia de

sistemas orientados a proyectos, usualmente hace que la
administración del proyecto sea más difícil.
En algunos casos, organizaciones no basadas en proyectos
tendrán departamentos u otras subunidades que operaran
como organizaciones basadas en proyectos con sistemas para tales
necesidades.

El equipo administrativo del proyecto debe estar
agudamente consciente de como el sistema de la
organización afectará al proyecto. Por ejemplo, si
la organización premia a sus administradores funcionales
por cargar tiempo de los empleados al proyecto, el equipo de
administración del proyecto tendrá que implementar
controles para asegurar que el personal asignado
este siendo usado de manera efectiva en el proyecto.

Culturas Organizaciones y Estilo

La mayoría de las organizaciones han desarrollado
culturas que son describibles y únicas. Estas culturas se
reflejan en sus valores
compartidos, normas,
creencias, y expectativas; en sus procedimientos y
políticas; en su vista particular de las
relaciones de autoridad; y
en otros factores numerosos. Las culturas organizacionales tienen
muchas veces influencia directa en el proyecto. Por
ejemplo:

• Un equipo que proponga una aproximación
  inusual o de alto riesgo es más seguro de
  encontrar aprobación en una organización
  agresiva o creativa.
• Un administrador de proyectos con un estilo
  altamente participativo seguramente encontrará
  problemas
  en una organización jerárquica rígida,
  mientras que un administrador de proyectos con estilo
  administrativo autoritario se verá enfrentado si
  trabaja en una organización participativa.

Estructura Organizacional

La estructura de la organización ejecutora a
veces limita la disponibilidad de los términos bajo los
cuales los recursos se hacen disponibles para el proyecto. Las
estructuras organizacionales pueden ser caracterizadas como
conformando un espectro que va desde funcional a proyectizado,
con una variedad de matrices
estructurales en el medio. La Figura 2-6 detalla
características claves relacionadas con el proyecto, de
los principales tipos de estructura
organizacional. La organización de proyectos es
discutida en la Sección 9.1, Planeación
Organizacional.

La organización funcional clásica se
muestra en la
Figura 2-7, es una jerarquía donde cada empleado
tiene un jefe inmediato claro. Los empleados están
organizados por especialidad, tales como producción, mercadeo, ingeniería, y
contabilidad
en el nivel superior, con la ingeniería subdividida en
mecánica y eléctrica. Las
organizaciones funcionales tendrán todavía
proyectos pero el alcance percibido del proyecto estará
limitado a los límites de
la función: El departamento de
ingeniería en una organización funcional
hará su trabajo independientemente de los departamentos de
manufactura y mercadeo. Por ejemplo, si el desarrollo de un nuevo
producto es desarrollado en una organización puramente
funcional, su fase de diseño muchas veces se
llamará "proyecto de diseño" e incluirá
solamente al personal del departamento de ingeniería. Si
surge una pregunta de manufactura, esta se llevará a la
cabeza del departamento que consultará con el jefe del
departamento de manufactura. La cabeza de el departamento de
ingeniería pasará entonces su respuesta,
descendiendo por la jerarquía hasta el administrador de
ingeniería del proyecto.

En el lado opuesto del espectro está la
organización proyectizada que se muestra en la Figura
2-8. En una organización proyectizada, los miembros
del equipo son muchas veces colocados. La mayor parte de los
recursos de la organización están involucrados en
el proyecto, y los administradores del proyecto tienen una gran
cantidad de independencia
y autoridad. Las organizaciones proyectizadas muchas veces tienen
unidades organizacionales llamadas departamentos, pero estos
grupos o
reportan directamente al administrador de proyectos o proveen
servicios de soporte a proyectos varios.

Las organizaciones matriciales tal como se muestran en
las Figuras 2-9 a 2-11 son una mezcla de
características funcionales y proyectizadas. Las matrices
débiles mantendrán muchas de las
características de una organización funcional y el
rol de administrador de proyectos es más el de un
coordinador que el de un administrador. De manera similar, las
matrices fuertes tendrán muchas de las
características de la organización proyectizada –
administradores de proyectos de tiempo completo con autoridad
considerable y personal administrativo de proyecto de tiempo
completo.

La mayoría de las organizaciones modernas
involucran todas estas estructuras en varios niveles tales como
se muestran en la Figura 2-12. Por ejemplo, aún una
organización fundamentalmente funcional puede crear un
equipo especial de proyectos para encargarse de un proyecto
crítico. Tal equipo tendrá muchas de las
características de un proyecto en una organización
proyectizada: Puede incluir personal de tiempo completo de
diferentes departamentos funcionales, y puede desarrollar su
propio juego de
procedimientos operativos, y puede operar fuera de la estructura
estandarizada, formalizada de reportes.

Habilidades Claves de la
Administración General

La Administración en General es un tema amplio
que trata con todos los aspectos de la administración de
una organización en producción. Entre otros temas
incluye:

• Contabilidad y finanzas,
  ventas y
  mercadeo, investigación y desarrollo, manufactura y
  distribución.
• Planeación estratégica,
  planeación táctica, y planeación
  operacional.
• Estructuras organizacionales, comportamiento
  organizacional, administración de personal, prestaciones, beneficios, y caminos de
  ascensos.
• Administración de relaciones de trabajo a
  través de la
  motivación, la delegación, supervisión, construcción de
  equipos de
  trabajo, manejo de conflictos, y otras técnicas.
• Manejo de uno mismo por medio de técnicas de
  administración del tiempo, manejo de estrés, y otras
  técnicas.

Las habilidades de administración general proveen
gran parte de los fundamentos para construir habilidades
administrativas de proyecto. Son muchas veces esenciales para el
administrador de proyectos. En cualquier proyecto dado,
habilidades de un gran número de áreas de
administración general pueden ser requeridas. Esta
sección describe habilidades claves de
administración general que muy probablemente
afectarán la mayoría de proyectos y que no son
contempladas en ningún otro lugar. Estas habilidades
están bien documentadas en la literatura de
administración general y su aplicación es
fundamentalmente la misma en un proyecto.

Hay también muchas habilidades de
administración general que son relevantes solo en algunos
proyectos o áreas de aplicación. Por ejemplo la
seguridad de los miembros del equipo es crítica en virtud
todos los proyectos de construcción y de poca monta en la
mayoría de los proyectos de desarrollo de
software.

Liderazgo

Kotter [4] distingue entre liderazgo y
administración mientras que enfatiza la necesidad de
ambas: Una sin la otra probablemente producirá resultados
pobres. El dice que administrar esta principalmente preocupada
con "producir consistentemente

los resultados claves esperados por los partidos
interesados," mientras que el liderazgo involucra:

• Establecer dirección — desarrollar tanto una
  visión del futuro como estrategias para producir los cambios
  necesarios para alcanzar esa visión.
• Alinear las personas — comunicar la
  visión por medio de palabras y actos a todos aquellos
  cuya cooperación podrá ser necesitada para
  alcanzar esa visión.
• Motivar e inspirar — es ayudar a las personas
  a energizarse para sobreponer barreras políticas,
  burocráticas y de recursos para lograr un
  cambio.

En un proyecto, y en particular un proyecto grande, se
espera generalmente que el administrador del proyecto sea
también el líder
del proyecto. El liderazgo no esta, sin embargo, limitado al
administrador del proyecto: Este podrá ser demostrado por
muchos individuos diferente, en diferentes puntos del proyecto.
El liderazgo debe ser demostrado a todos los niveles del proyecto
(liderazgo del proyecto, liderazgo técnico, liderazgo de
equipo).

Comunicación

La comunicación involucra el intercambio de
información. El que envía es responsable por hacer
la información clara, no ambigua, y completa para el que
reciba pueda hacerlo de manera correcta. El que recibe es
responsable por asegurarse de que la información se recibe
de forma completa y se entiende en su totalidad. La
comunicación tiene muchas dimensiones:

• Escrita y oral, escuchar y conversar.
• Interna (dentro del proyecto) y externa (al
  cliente, a los medios, al
  público, etc.).
• Formal (reportes, actas, etc.) e informal (memos,
  conversaciones ad hoc, etc.).
• Vertical (hacia arriba y abajo en la
  organización) y horizontal (con los compañeros
  de trabajo).

Las habilidades de administración general de las
comunicaciones
está relacionada a, pero no lo mismo que, la
Administración de Comunicaciones en un Proyecto (descrito
en el Capítulo 10). La comunicación es una materia amplia
e involucra un cuerpo sustancial de conocimiento
que no es único al contexto del proyecto, por
ejemplo:

• Modelos de envío y recibo — ciclos de
  retroalimentación, barreras de
  comunicación, etc.
• Escoger el medio — cuando comunicarse por
  escrito, cuando comunicarse oralmente, cuando escribir un
  memo de información, cuando escribir un reporte
  formal, etc.
• Estilo de escritura
  — voz activa vs. pasiva, estructura de frase, escoger
  las palabras, etc.
• Técnicas de presentación —
  cuerpo de lenguaje,
  diseño de ayudas visuales, etc.
• Técnicas de administración de
  reuniones — preparar una agenda, administración
  de conflictos, etc.

La Administración de Comunicaciones del Proyecto
es la aplicación de estos conceptos amplios a las
necesidades especificas de un proyecto; por ejemplo, decidir
cuando, como, en que forma, y a quien se el reporta los avances
de ejecución del proyecto.

Negociación

La negociación involucra conferir con otros de
manera que se llegue a términos o se llegue a un
entendimiento. Los acuerdos pueden ser negociados directamente o
asistidos; la mediación y el arbitramento son dos tipos de
negociación asistida.

La negociación ocurre alrededor de muchos
tópicos, muchas veces, y a muchos niveles del proyecto.
Durante el curso típico de un proyecto, el personal del
proyecto tendrá que probablemente negociar alguna o todas
de las siguientes:

• Alcance, costo, y objetivos de la
  programación.
• Cambios al alcance, costo, y
  programación.
• Términos y condiciones del
  contrato.
• Asignaciones.
• Recursos.

Resolución de Problemas

La resolución de problemas involucra la
combinación de la definición de problemas y la
toma de
decisiones. Se preocupa con problemas que ya han ocurrido (en
oposición a la administración de riesgos que nombra
problemas potenciales).

La definición del problema requiere distinguir
entre causas y síntomas. Los problemas pueden ser internos
(un empleado clave es reasignado a otro proyecto) o externos (un
permiso requerido para comenzar el trabajo, se retrasa). Los
problemas pueden ser técnicos (diferencias de
opinión sobre la mejor manera de diseñar un
producto), administrativos (un grupo funcional no esta
produciendo de acuerdo al plan), o
interpersonales (choques de personalidad o
estilos).

La toma de decisiones incluye analizar el problema para
identificar soluciones
viables, y luego tomar una decisión de esas posibles
soluciones. Las decisiones pueden ser hechas u obtenidas (del
cliente, del equipo, o de un administrador funcional). Una vez
hecha, la decisión debe ser implementada. Las decisiones
también tiene un elemento de tiempo en ellas – la
decisión "correcta" puede no ser la "mejor"
decisión si se hace o muy temprano o muy tarde.

Influenciando la Organización

Influenciando la Organización involucra la
habilidad "para hacer las cosas". Requiere un entendimiento de
tanto las estructuras formales como informales de todas las
organizaciones involucradas – la organización ejecutora,
contratistas, y tantas otras como sea apropiado. Influenciar la
organización también requiere un entendimiento de
la mecánica del poder y la política.

Tanto el poder como la política son usados
aquí en su sentido positivo. Pfeffer [5] define el poder
como "la habilidad potencial para influenciar el comportamiento, cambiar el curso a los eventos,
sobreponerse a la resistencia, y
hacer que las personas hagan cosas que de otra manera no
harían". De manera similar, Eccles [6] dice que "la
política trata de conseguir acción colectiva de un
grupo de personas que pueden tener intereses muy diferentes.
Trata de estar dispuesto a utilizar el conflicto y el desorden de
manera creativa. El sentido negativo, es claro, se deriva del
hecho que trata de reconciliar estos intereses resultando en una
lucha por el poder y juegos
organizacionales que a veces pueden tener una vida propia poco
productiva".

Influencias
Socioeconómicas

De manera similar a la administración general,
las influencias socioeconómicas incluyen un amplio rango
de tópicos y temas. El equipo administrativo de proyectos
debe entender que las condiciones actuales y tendencias en esta
área pueden tener un efecto muy grande en su proyecto: Un
pequeño cambio acá se puede traducir, usualmente
con una holgura de tiempo, en efectos cataclísmicos en
todo el proyecto. De todas las influencias socioeconómicas
potenciales, las principales categorías que afectan los
proyectos se describen brevemente a
continuación.

Standards y Regulaciones

La Organización Internacional para la
Estandarización (ISO) hace
diferenciación entre standards y regulaciones como se
muestra a continuación [7]:

• Un standard es un "documento aprobado por un cuerpo
  reconocido, que provee, para el uso común y repetido,
  reglas, marcos de referencia, o características para
  productos, procesos o
  servicios con los cuales el cumplimiento no es mandatorio".
  Hay numerosos standards en uso que cubren virtualmente todo
  desde la estabilidad térmica de líquidos
  hidraúlicos hasta el tamaño de diskettes para
  computadora.
• Una regulación es un "documento que describe
  procesos o características de servicios para
  productos, incluyendo las provisiones administrativas
  aplicables, con las cuales es obligación cumplir". Las
  normas de construcción son un ejemplo de
  regulaciones.

Se debe tener cuidado al discutir standards y
regulaciones ya que hay una vasta área gris entre las dos,
por ejemplo:

• Los standards muchas veces comienzan con marcos de
  referencia que describen una aproximación preferida, y
  luego, con su amplia adopción, se convierten en regulaciones
  de facto (e.g., el uso del Método de la Ruta Crítica para
  la programación de grandes obras de
  construcción).
• El cumplimiento puede ser mandatorio a diferentes
  niveles (e.g., por una agencia de gobierno, por la
  administración de la organización ejecutora, o
  por el equipo de administración de
  proyectos).

Para muchos proyectos, los standards y regulaciones (por
cualquier definición) son bien conocidas y los planes de
proyectos pueden reflejar sus efectos. En otros casos, la
influencia no es conocida o poco conocida y se debe considerar
bajo la Administración de Riesgo del Proyecto.

Internacionalización

A medida de que más y más organizaciones
se involucran en trabajo que abarca varias fronteras nacionales,
más y más proyectos cruzan fronteras
también. Adicionalmente a las preocupaciones tradicionales
por alcance, costo, tiempo, y calidad, el
equipo de administración del proyecto debe también
considerar los efectos de cambios de horario, fiestas religiosas
y nacionales, requerimientos de viaje para reuniones cara a cara,
la logísticas de teleconferencias, y las muchas veces
diferencias políticas volátiles.

Influencias Culturales

La cultura es "la
totalidad de los patrones de comportamiento transmitidos de la
sociedad, arte, creencias, instituciones y todos los otros
productos del esfuerzo del trabajo y pensamiento
humano" [8]. Cada proyecto tiene que operar dentro de un contexto
de una o más normas culturales. Esta área de
influencia incluye aspectos políticos, económicos,
demográficos, educativo, étnicos, religiosos, y
otra áreas de práctica, creencias, y actitudes que
pueden afectar la manera en que las personas y las organizaciones
interactúan.

NOTAS

Procesos de
Administración de Proyectos

La administración de proyectos es una tarea
integrada – una acción, o falta de toma de acción,
en un área usualmente afectará otras áreas.
Las interacciones pueden ser directas y bien entendidas o pueden
ser sutiles e inciertas. Por ejemplo, un cambio de alcance casi
siempre afectará el costo del proyecto, pero puede afectar
o no afectar la moral del
equipo o la calidad del producto.

Estas interacciones muchas veces requieren canjes
entre los objetivos del proyecto – la calidad de
ejecución en un área puede ser mejorada
únicamente al sacrificar la calidad de ejecución
en otra. La administración de proyectos exitosa requiere
administrar activamente estas interacciones.

Para ayudar a entender la naturaleza de
estas interacciones de la administración de proyectos, y
para enfatizar la importancia de la interacción, este
documento describe la administración de proyectos en
término de sus componentes procesales y sus interacciones.
Este capítulo provee una introducción al concepto de la
administración de proyectos, como un número de
procesos encadenados y por lo tanto provee los fundamentos
esenciales para el entendimiento de los procesos descritos de los
Capítulos 4 y 12. Incluye las siguientes
secciones:

3.1 Procesos de Proyecto

3.2 Grupos de Procesos

3.3 Interacciones de Procesos

3.4 La Personalización de las
Interacciones de Procesos

Procesos de Proyecto

Los proyectos están compuestos de procesos. Un
proceso es
"una serie de acciones que tiene como consecuencia un resultado"
[1]. Los procesos de proyecto son ejecutados por personas y
generalmente caen en una de dos categorías:

• Los procesos de administración de proyectos
  se preocupan principalmente con describir y organizar el
  trabajo del proyecto. Los procesos de administración
  de proyectos que son aplicables a la mayoría de los
  proyectos, la mayoría del tiempo, se describen
  brevemente en este capítulo y en detalle en los
  Capítulos 4 al 12.
• Los procesos orientados al producto se preocupan
  principalmente con especificar y crear el producto del
  proyecto. Los procesos orientados al producto son
  típicamente definidos por el ciclo de vida del
  proyecto (discutido en la Sección 2.1) y varían
  de acuerdo con el área de aplicación (tal como
  se discute en el Apéndice F).

Los procesos de administración de proyectos y los
procesos orientados al producto se traslapan e interactúan
a través del proyecto. Por ejemplo, el alcance del
proyecto no se puede definir en la ausencia de algún
conocimiento básico de como crear el producto.

Procesos de Grupo

Los procesos de administración de proyecto se
pueden organizar en cinco grupos de uno o más procesos
cada uno:

• Procesos inicializadores — reconoce que un
  proyecto o fase deben comenzar y se comprometen a
  eso.
• Procesos de planeación — desarrollar y
  mantener un esquema trabajable para completar la necesidad
  del negocio para el cual el proyecto fue
  desarrollado.
• Procesos de ejecución — coordinar a
  las personas y otros recursos para desarrollar el
  plan.
• Procesos controladores — aseguran que los
  objetivos del proyecto sean cumplidos a través del
  monitoreo y medición de avance y tomar
  acción correctiva cuando sea necesario.
• Procesos de cierre — formalizan la
  aceptación del proyecto o fase y los llevan a una
  terminación ordenada.

Los grupos de proceso están encadenados por los
resultados que producen – el resultado o producto de uno se
convierte en la entrada "input" para otro. Entre los grupos de
procesos centrales, los encadenamientos son iterativos – la
planeación produce una ejecución con un plan de
proyecto documentado en un principio y después provee
actualizaciones documentadas al plan a medida que el proyecto
progresa. Estas conexiones se ilustran en la Figura 3-1.
Adicionalmente los grupos de procesos de administración de
proyectos no son discretos, o eventos únicos; son
actividades que traslapan que ocurren a varios niveles de
intensidad a través de cada fase del proyecto. La
Figura 3-2 ilustra como los grupos de procesos se
traslapan y varían dentro de una fase.

Finalmente, las interacciones de los grupos de procesos
pueden también atravesar fases de tal manera que la
finalización de una fase provea entradas o input para la
iniciación de otra. Por ejemplo, la terminación de
una fase de diseño requiere la aceptación del
cliente del documento de diseño. Simultáneamente el
documento de diseño describe el producto para la fase
subsiguiente de implementación. Esta interacción se
describe en la Figura 3-3.

Repetir el proceso de iniciación al comienzo de
cada fase ayuda a mantener el proyecto enfocado en el negocio
para el cual fue desarrollado. Debe ayudar también a
asegurar que si el negocio ya no existe o no se necesita el
proyecto se suspenderá, también en el caso si el
proyecto tiene pocas probabilidades de satisfacer las necesidades
del negocio. Las necesidades del negocio serán discutidas
en más detalle en la introducción a la
Sección 5.1, de Iniciación.

A pesar de que la Figura 3-3 se dibuja con fases
discretas y procesos discretos, en un proyecto real habrán
muchos traslapos. El proceso de

planeación, por ejemplo, no solo debe proveer
detalles que se necesitan para terminar exitosamente la fase en
ejecución del proyecto sino que también debe
proveer alguna descripción preliminar de trabajo que se
hará en fases subsiguientes. Este detallamiento progresivo
del plan de proyecto es muchas veces llamado planeación
por olas.

Interacción de
Procesos

Dentro de cada grupo de proceso, los procesos
individuales están encadenados por sus salidas y entradas.
Al enfocarse en estos encadenamientos, podemos describir cada
proceso en término de:

• Input o entradas — documentos o
  ítems documentables sobre los que se
  actuará.
• Herramientas y técnicas — los
  mecanismos aplicados a las entradas para crear las
  salidas.
• Salidas — documentos o ítems
  documentables que son el resultado de un proceso.

Los procesos de administración de proyectos
comunes a la mayoría de los proyectos en la mayoría
de las áreas de aplicación, se listan aquí y
se describen en detalle en los Capítulos 4 al 12. Los
números en paréntesis después de los nombres
de los procesos identifican al capítulo y sección
donde se describen. Los procesos de interacción descritos
aquí son también típicos para la
mayoría de los proyectos en la mayoría de las
áreas de aplicación. La Sección 3.4 discute
como personalizar tanto los procesos descriptivos como sus
interacciones.

Procesos de Inicialización

La Figura 3—4 ilustra el único
proceso en este grupo de procesos.

• La inicialización (5.1) — es
  comprometer a la organización a ejecutar la siguiente
  fase del proyecto.

Proceso de Planificación

La planeación es de gran importancia para el
proyecto porque el proyecto involucra hacer cosas que no se han
hecho antes. Como resultado, hay relativamente más
procesos en esta sección. Sin embargo, el número de
procesos no quiere decir que la administración de
proyectos consiste primordialmente de la planeación – la
cantidad de planeación ejecutada debe conmesurarse con el
alcance del proyecto y la utilidad de la
información desarrollada.

Las relaciones entre los procesos de planeación
del proyecto se muestra en la Figura 3-5 (esta
gráfica es una explosión del elipse llamado
"procesos de planeación" en la Figura 3-1). Los
procesos están sujetos a una frecuente iteración
antes de completarse el plan. Por ejemplo, si la fecha inicial de
terminación es inaceptable, los recursos del proyecto,
costos, o inclusive el alcance tendrá que ser redefinido.
Adicionalmente, la planeación no es una ciencia exacta
– dos equipos diferentes pueden generar dos planes muy diferentes
para un mismo proyecto.