Administración de Proyectos de Informática - Francisco J. Toro López PDF

ECOE EDICIONES Francisco J.
Toro López
Francisco J. Toro López
Ingeniero Químico de la Universidad
Nacional de Colombia, participante del
programa de Magíster en Ingeniería de
Sistemas de la Universidad Nacional de
Colombia, y un título de Master in Business
Administration de North Dakota State
University. Obtuvo una beca de la
Organización de Estados Americanos en
Project
Management Professional) del PMI (Project
Management Institute) en el 2009. Es
miembro activo de la Asociación
Colombiana de Ingenieros de Sistemas
desde 1992.
Su experiencia profesional actual la

desarrolla como Consultor de la Cámara de
Comercio de Bogotá y director de
Programación de la Constructora
Esmeralda. Fue consultor e instructor en
asocio con Unisys de Colombia y High
Computer en diversas empresas
multinacionales y nacionales radicadas en
Colombia, Puerto Rico y República
Dominicana. También trabajó como
consultor en documentos multimedia de
educación bilingüe para los estudiantes de
origen latino para el HISD, uno de los
distritos escolares más grandes de
Houston, Texas. Fue fundador de MESYS
Ltda., empresa dedicada a la consultoría y
capacitación en sistemas de computación.
Actualmente es profesor de las

universidades EAN, Autónoma de
Colombia y La Gran Colombia en los
programas de postgrado. Ha sido
conferencista, asesor y catedrático de las
universidades, Interamericana de Puerto
Rico, del Rosario, Católica y del Instituto
Tecnológico de Santo Domingo.
Administración
de proyectos
de informática
Francisco J. Toro López

Catalogación en la publicación – Biblioteca Nacional de Colombia
Toro López, Francisco J.

Administración de proyectos de informática / Francisco
J. Toro López. – 1ª. ed. – [Bogotá] : Ecoe Ediciones, 2012
236 p. – (Ciencias administrativas)
Incluye índice temático. -- Bibliografía al final del texto

ISBN 978-958-648-816-7
1. Administración de proyectos informáticos

I. Título II. Serie
CDD: 658.404 ed. 23 CO-BoBN– a830395
Colección: Ciencias Administrativas

Área: Administración
Primera edición: Bogotá, 2013
ISBN: 978-958-648-816-7
e-ISBN: 978-958-648-817-4
© Francisco J. Toro López

E-mail: fcotorol@gmail.com
© Ecoe Ediciones
E-mail: correo@ecoeediciones.com
www.ecoeediciones.com
Coordinación editorial: Alexander Acosta Q.

Diseño y diagramación: Emilse Londoño Díaz
Diseño de carátula: Edwin Penagos P.
Impresión: Gráficas de la Sabana Ltda.
Carrera 69 H, No 77-36 - Tel.: 630 0255
Carrera 25 No. 8-81, Tel.: 3711916
Impreso y hecho en Colombia.

Preliminares
Tabla de contenido
Observaciones generales ................................................................ IX

Dedicatoria especial ....................................................................... XI
Capítulo 1 ...................................................................................... 1
Introductorio ................................................................................. 1
1.1 Introducción ............................................................................ 1
1.2 Industria de la Informática en los últimos años......................... 4
Algunas consideraciones sobre el medio latinoamericano ....... 6
1.3 Principios y métodos del PMI................................................... 8
Ciclo de vida del proyecto ....................................................... 14
1.4 Metodologías empleadas en desarrollo
de proyectos Informáticos ........................................................ 15
¿Qué es ITIL? ........................................................................... 15
La metodología CASE............................................................... 18
Principios y prácticas XP .......................................................... 23
Los roles en las metodologías XP ............................................. 24
Las historias de usuario ............................................................ 25
OTRAS METODOLOGÍAS ÁGILES .......................................... 26
Rational Unified Process (RUP)................................................ 27
Metodología SOA .................................................................... 31
Development (Lean Project Management) ............................... 32
FRANCISCO J. TORO LÓPEZ V

Administración de proyectos informáticos
La cadena de valores de los procesos del negocio ................... 33

Principios fundamentales de la metodología
Lean development ................................................................... 34
Push (empujar) vs. Pull (jalar)
En la planeación estratégica de proyectos ................................ 35
La computación en la nube...................................................... 40
Almacenamiento en las nubes ................................................. 41
Conclusiones y recomendaciones generales ............................ 42
1.5 Análisis DOFA ......................................................................... 43
1.6 tarifa global y su empleo en proyectos ..................................... 45
Antecedentes de este enfoque: ................................................. 46
Registro cronológico de tarifas ................................................ 51
1.7 Métodos de costeo y la factibilidad financiera .......................... 54
Factibilidad financiera de un proyecto ..................................... 58
Valor presente neto .................................................................. 59
Período de restitución (payback) .............................................. 59
Relación beneficio / costo ........................................................ 60
Casos de evaluación financiera ................................................ 60
1.8 Software de manejo de proyectos ............................................ 61
Introducción a microsoft project .............................................. 61
Elementos visuales de ms-project ............................................. 62
La técnica de la planeación paulatina
o Rolling Wave......................................................................... 69
Otros productos de software de manejo de proyectos .............. 70
Capítulo 2
Iniciación ....................................................................................... 73
2.1 Formalización y definición de proyectos.................................. 73
La oficina de administración de proyectos ............................... 73
Objetivos del proyecto............................................................. 75
2.2 Definición de la estructura operativa ....................................... 78
Proyectos, programas y portafolios........................................... 78
2.3 Administración de las comunicaciones y
Expectativas de los interesados ................................................ 79
Balanceando intereses entre los interesados ............................. 82
2.4 Gestionando la integración del proyecto.................................. 83
Necesidades del negocio ......................................................... 83
Alcance del producto............................................................... 83
VI
Preliminares
Capítulo 3
Planeación ..................................................................................... 87
3.1 la planificación de proyectos ................................................... 87
La planeación paulatina o Rolling ........................................... 92
La planeación del recurso humano .......................................... 94
Modelo de desarrollo de un equipo humano ........................... 98
Recompensas por desempeño .................................................. 99
La comunicación del equipo de trabajo ................................... 100
La estructura de desglose del trabajo........................................ 103
Método de la ruta crítica .......................................................... 109
Estimar los recursos y duraciones de las actividades ................ 113
El diccionario de la edt ............................................................ 115
Técnicas para comprimir la duración de un proyecto .............. 116
Probabilidad de terminar un proyecto a tiempo ....................... 119
3.2 Administración del costo y de la calidad
En un proyecto......................................................................... 121
La administración de la calidad ............................................... 124
¿Que es calidad? ...................................................................... 125
¿Que es y no es calidad? .......................................................... 126
La moderna gestión de la calidad............................................. 126
Conformidad............................................................................ 127
No conformidad ...................................................................... 128
Línea base de la calidad........................................................... 129
3.3 Gestión de riesgos en un proyecto ........................................... 130
Identificar los riesgos ............................................................... 133
3.4 Manejo de compras y adquisiciones ........................................ 137
Factores ambientales de la empresa
(Enterprise Environment Factor´s, sigla EEFs)............................. 143
Activos de procesos organizacionales
(Organizational Process A´s sigla OPA´s) .................................. 143
Tipos de contrato de compras usados en proyectos.................. 149
1. Contrato de precio fijo firme (FFP) ....................................... 151
2. Costo más contratos de tarifa fija (CPFF) .............................. 153
3. Costo más contratos de tarifa de incentivo (CPIF) ................. 153
Tipos de acuerdos contractuales híbridos................................. 154
Riesgo y tipos de contrato ........................................................ 157
3.5 Gestión de concursos y cotizaciones ....................................... 158
Outsourcing (Tercerización) ..................................................... 158
FRANCISCO J. TORO LÓPEZ VII

Capítulo 4
Ejecución y control ........................................................................ 165
4.1 ejecutar y controlar el plan del proyecto .................................. 167
Procedimientos de reporte y ajustes de la programación .......... 167
Preliminares del reporte de avances ......................................... 168
Reporte de los avances ............................................................ 173
Mostrar el avance .................................................................... 175
Medición del desempeño......................................................... 184
Cambios inesperados en el alcance ......................................... 185
Más recomendaciones sobre el uso de software de proyectos .. 186
4.2 Integración de equipos, comunicación
y distribución de la información .............................................. 186
Distribuir la información .......................................................... 190
Gestionar las expectativas de los interesados ........................... 190
4.3 Aseguramiento de la calidad .................................................... 192
4.4 Administración de contratos .................................................... 193
4.5 Control del programa del proyecto .......................................... 195
4.6 Control presupuestal y el análisis del valor ganado .................. 195
TALLER 2. Uso de Indicadores de seguimiento
y el análisis de valor ganado ................................................... 200
Capítulo 5
Cierre .......................................................................................... 207
El cierre contractual........................................................................ 207
El cierre administrativo ................................................................... 209
Apéndices
Apéndice A Introducción a la herramienta MS-Project ................... 211
Apéndice B Proyectos informáticos de calidad ............................... 214
Apéndice C La metodología Scrum................................................. 217
Visión general del modelo ............................................................. 218
Metodología Scrum ....................................................................... 219
Roles .......................................................................................... 219
Índice temático .............................................................................. 221
Bibliografía .................................................................................... 223
VIII
Preliminares
Observaciones generales
La intención de esta obra es orientar el manejo de proyectos en el
área de la informática, desde su fase de iniciación, pasando por las de
planeación, ejecución y control, hasta su cierre una vez se han logrado
los objetivos, respetando y manteniendo los principios impulsados por el
Project Management Institute (PMI)™ y observando las guías generales
y enfoques metodológicos que estableció este Instituto para el manejo
gerencial de Proyectos, los cuales permanecen como una guía en el uso de
mecanismos y métodos aplicables a la gestión de todo tipo de proyectos.
Los ejercicios y ejemplos mencionados vienen en formato de presentación

que hace fácil su desarrollo y seguimiento. En su mayoría vienen elaborados
con la herramienta de Microsoft Project ™, versión 2010 y el lector puede
estudiarlos y guardarlos en su computadora y posteriormente adaptarlos si
lo desea para un mejor entendimiento y extensión de su conocimiento.
No es la intención del autor explicar todas o la mayoría de las técnicas

de manejo de esta herramienta, sino tan solo emplear sus facilidades en
diversos aspectos de la fase de seguimiento y control de un proyecto
informático. Tampoco se pretende entrar en detalles de las varias técnicas
actualmente empleadas por las empresas para trazar un plan estratégico
como sostén de sus proyectos de cualquier tipo.
En este orden de ideas, se va a hacer algunas referencias breves a

metodologías como ITIL puesto que se ha logrado constituir en un
FRANCISCO J. TORO LÓPEZ IX

conjunto bien documentado de mejores prácticas orientadas a la

administración de los servicios de Tecnologías de Información (TI) a través
de un enfoque basado en el análisis de todos los procesos empresariales,
pero ello sin embargo no significa que por no hacer mención alguna a
otras metodologías como CMMi y COBIT, la importancia de estas últimas
pudiera ser soslayada.
Las instrucciones relativas a los ejemplos y casos que usen herramientas

de computación, se presentan preferencialmente en Castellano pero es
inevitable la presencia de términos en Inglés dada su amplia aceptación en
este medio profesional. Se señalan en negrilla los nombres de los menús
o teclas de acceso rápido y en letra normal las opciones que el usuario
podrá o deberá indicar en cada instrucción.
En caso que el usuario deba escoger una opción dentro de una lista de valores,
esta aparecerá demarcada entre corchetes rectangulares [.,.] y si tiene que
escribir un texto en particular, ello se señalará con la notación <...>.
Las teclas de acceso rápido son opciones de un programa que se ejecutan

con una combinación de dos teclas. Generalmente, se oprime primero la
tecla Ctrl y manteniendo esta oprimida se oprime la tecla correspondiente a
la letra que aparece subrayada en la opción respectiva (por ejemplo, Ctrl+O).
Los nombres y opciones de un menú que aparezcan con una letra subrayada
se debe a que se pueden ejecutar con cierta combinación de teclas de
acceso rápido. Es frecuente el uso de este tipo de notación: Tarea → Vista
→ Diagrama de Gantt para indicar la secuencia de pasos usando opciones
del menú principal de una herramienta de cómputo.
El término “clic” se utilizará en este libro para aludir a la acción de

presionar uno de los botones (generalmente el izquierdo) del dispositivo
apuntador llamado comúnmente, Mouse en el medio hispano parlante.
Algunos países prefieren usar el término ratón en vez de Mouse. Términos
en inglés como Hardware y Software que son de amplia aceptación en
el mundo de la Informática, se emplearán en esta obra, para referir los
componentes físicos y lógicos de computadores, respectivamente.
X
Preliminares
Dedicatoria especial
A la Memoria de mi inolvidable hermano

Iván Toro López por su permanente disposición
en colaborarme y su incondicional apoyo durante
el transcurso de toda mi vida.
Una mención por su generosa y siempre franca aptitud

ante la vida a mi hija, Viviana Alejandra,
mi esposa Myriam Abondano, y a mis familiares Myriam Guzmán,
Alberto López y Olga López, por su incondicional y absoluta
confianza y sus permanentes muestras de aprecio y consideración.
FRANCISCO J. TORO LÓPEZ XI

Capítulo 1 • Introductorio
Capítulo 1
Introductorio
1.1 Introducción
El siglo XXI ha traído retos muy interesantes para todas las disciplinas del
conocimiento. Y en casi todas estas disciplinas, la gerencia de proyectos
ha demostrado ser un gran contribuyente que en forma destacada ha
conseguido que estos proyectos sean exitosos. Entre los proyectos más
importantes desarrollados durante esta primera década del siglo están:
• La campaña presidencial de Barack Obama: el alcance fue definido
en forma clara y se logró cumplir el objetivo contundentemente.
• La reconstrucción del centro de Manhattan después de los ataques del
11 de septiembre: se integró un equipo multidisciplinario que aún sigue
trabajando en la reconstrucción del centro financiero de la nación.
• El rescate de los mineros en Chile: donde en un tiempo récord se logró
la excavación de un túnel de 700 metros de profundidad que permitió
traer con vida a 36 chilenos después de 70 días de permanecer
enterrados en un socavón. El trabajo en equipo liderado por el
mismo presidente de la república y con la participación de la NASA,
universidades del mundo entero, ingenieros y gerentes de proyecto,
lograron llevar a feliz término el mencionado rescate.
Esto se logró porque los miembros de los equipos que participaron en los
proyectos mencionados anteriormente siguieron las llamadas buenas
FRANCISCO J. TORO LÓPEZ 1

prácticas. Las buenas prácticas, como lo describe el Project Management

Institute (PMI), son un conjunto de habilidades, herramientas y técnicas que
pueden aumentar la posibilidad de éxito en una amplia variedad de proyectos.
Al día de hoy existen varias asociaciones sin ánimo de lucro que promulgan
las citadas buenas prácticas, entre ellas se citan las siguientes no exactamente
en el orden de las fechas en que fueron fundadas u organizadas:
1. Project Management Institute (PMI) www.pmi.org
El PMI fue fundado en 1969 en Estados Unidos y desarrollado por
cientos de miles de practicantes que han transmitido su experiencia.
Regularmente publican estándares relacionados con la Gerencia de
Proyectos. El principal es el Project Management Body of knowledge
(PMBOK) donde se comunica al interesado qué debe hacer para
desarrollar un proyecto exitoso. La primera edición fue publicada
en 1983. La actual, cuarta edición, fue publicada en diciembre de
2008. Existen traducciones a una docena de lenguajes que incluyen el
alemán, coreano, chino, español, portugués entre muchos.
2. International Project Management Association (IPMA) www.ipma.org
Esta asociación fue fundada en 1965 y se ha desarrollado en una
red internacional de asociaciones de Gerencia de Proyectos el IPMA
tiene 4 niveles de certificación que se basan en las competencias del
Gerente de proyecto. Esas competencias son: a-Comportamiento,
b-técnicas y c- Contextual.
3. Project in Controlled Environments: (PRINCE2) www.prince2.com
Fue desarrollada por el gobierno británico y lo deben aplicar todos
los proveedores que pretenden vender productos y servicios al citado
reino. Los proyectos siempre deben cumplir con la entrega oportuna
de los productos y/o servicios respetando los límites de tiempo y
dinero. Cabe resaltar que siempre se aplican a tecnología informática
como a cualquier otro entregable que se desee suministrar.
En este trabajo se va a hacer constante referencia a los principios y métodos

propiciados por el Project Management Institute (PMI) como elementos
básicos en la planeación y el seguimiento de proyectos. Es importante
destacar que esta no es una metodología; es un conjunto de prácticas
políticas, procedimientos, guías y técnicas que se utilizan para dirigir
proyectos. El PMI destaca las buenas prácticas, pero hace salvedad en que
no utiliza las llamadas mejores prácticas.
2
Estas últimas se usan en empresas que desarrollan constantemente

procedimientos aplicables a proyectos y que son exclusivos para ellos;
por eso las pueden llamar, como en efecto lo hacen las Mejores prácticas.
Es absolutamente necesario decir en este momento que el proceso de llevar a

cabo proyectos de tecnologías informáticas debe estar acorde con el desarrollo
estratégico de las compañías. La Planeación Estratégica de Tecnología
Informática debe ser una metodología propia, desarrollada y aplicada durante
algunos años en el ambiente de negocios y que facilite alinear las estrategias
de la tecnología informática con las estrategias del negocio.
En los últimos años se ha invertido mucho dinero en la adecuación o

adquisición de tecnología, sin saber realmente si esta inversión ha tenido
los resultados estratégicos esperados.
Uno de los objetivos primordiales que se impone es entonces elaborar y

desarrollar el proceso de Planeación Estratégica de Tecnología Informática
en su etapa estratégica para cualquier empresa. Durante este proceso se
establecen los factores críticos de soporte a las estrategias de la empresa
y sus métricas, de tal manera que la inversión en tecnología pueda ser
fácilmente justificable.
Para el desarrollo de un Plan Estratégico de Tecnología Informática se

sugiere seguir el siguiente análisis:
1. Realizar un Modelo de Empresa y establecer las relaciones entre la
estrategia empresarial, la organización, los procesos y las entidades a
cargo del manejo de datos.
2. Conocer, mediante entrevistas a ejecutivos, las necesidades de
información.
3. Determinar las prioridades de las necesidades actuales y potenciales
de solución informática.
4. Definir la Arquitectura Básica de Aplicaciones y la Arquitectura Básica
de la Red.
5. Analizar el soporte que los sistemas actuales brindan al modelo de
empresa y la factibilidad de que, a partir de los sistemas actuales, se
cubran las necesidades de soluciones informáticas.
6. Elaborar las recomendaciones para la administración de la Tecnología
Informática y las pautas para la elaboración del presupuesto del área.

7. Entregar, al término de la prestación del servicio, el informe del Plan

Estratégico de Tecnología Informática, en el cual se expondrá el
resultado del análisis realizado por un equipo de trabajo así como las
recomendaciones sobre las estrategias a corto plazo para adecuar el Plan
de Tecnología Informática al Plan Estratégico General de la empresa.
El desarrollo de un Plan Estratégico de Tecnología Informática refuerza y

debe estar en línea con el plan estratégico de la empresa. Adicionalmente,
se crea un marco de trabajo que permite el enfoque integrado del desarrollo
de aplicaciones y de las bases de datos.
Al así hacerlo, se obtienen los siguientes beneficios del proceso:

• Alinea la tecnología informática con la estrategia general de la empresa
• Cubre todas las necesidades de información que puedan ser objeto de
tratamiento informático.
• Facilita la utilización compartida de información dentro y fuera de la
empresa.
• Define y da soporte a un marco o arquitectura para el desarrollo
integrado de aplicaciones y bases de datos.
1.2 Industria de la informática en los últimos años

La elaboración y distribución de productos para la administración y manejo
de la información han cobrado protuberante relevancia en los últimos
años. Este sector de la economía se caracteriza por desarrollar proyectos
que persiguen tanto la producción de mercancías y de equipos para el
manejo de la información, como la elaboración y entrega de servicios
informáticos que implican generalmente el diseño, desarrollo y prueba de
programas de aplicaciones.
Dos naciones se han destacado últimamente en forma notoria en el

concierto universal en el desarrollo de este tipo de proyectos y son la India
y la China1.
1. Algunos teóricos se han inventado ya el término CHINDIA para denominar esta pareja de países
con tan alto grado de desarrollo y de competitividad internacional.
4
En lo que se refiere a los servicios (véase la Tabla 1), entre 1993 y 2008
la parte de China se ha duplicado con creces, pero la proporción de la
India se ha multiplicado por más de cuatro. Es bien conocido que la India
se ha convertido en un importante exportador de servicios de tecnologías
de la información (STI), especialmente de los subcontratados por grandes
compañías multinacionales extranjeras a empresas indias, como Tata
Consultancy Services (TCS), o a filiales de grandes compañías del sector,
como Dell, HP, IBM y Microsoft.
Tabla 1.1. Peso en el comercio internacional de servicios informáticos, período 1993-2008 (%)
Exportaciones Importaciones
País /Grupo
1993 2008 1993 2008
China 1,6 3,7 2,1 4,4
India 0,6 2,8 0,8 2,6
China + India 2,2 6,5 2,9 7,0
EEUU 16,7 16,2 10,8 13,6
Fuente: OMC, 2010.
Los STI suponen más de la mitad de las exportaciones indias de servicios. En

la India, los STI consisten, por un lado, en software y servicios relacionados
(en inglés ITSS, siglas correspondientes a Information Technology Software
and Services).
En ese sector, la India se ha destacado por la alta relación calidad-costo de

actividades como, entre otras, desarrollo y mantenimiento de aplicaciones
informáticas, integración de sistemas, mejora de paquetes informáticos y
alojamiento de páginas web.
Por otro lado, en los STI hay otro subsector (llamado ITESBPO), constituido
por los servicios integrales a empresas, esto es, por servicios dependientes
de las tecnologías informáticas (ITES, o information technology-enabled
services) y los servicios de subcontratación de procesos empresariales
(BPO, o business process outsourcing), como son los servicios de atención
al cliente por teléfono (call centers) o correo electrónico, administración
de personal, contabilidad y mantenimiento de páginas web.

Están haciendo, además, procesos subcontratados basados en

conocimiento especializado (KPO, o Knowledge Process Outsourcing),
como análisis financieros y jurídicos, diagnósticos médicos a distancia,
estudios de ingeniería y operaciones actuariales. Los principales mercados
para las exportaciones indias de STI son EEUU y el Reino Unido, seguidos
de Europa continental y Asia-Pacífico.
El atractivo de la India para la subcontratación internacional de STI

reside en varios aspectos como son el elevado número de profesionales
del sector, su bajo costo relativo (un tercio del vigente en EEUU o en
Europa Occidental) y su dominio del idioma inglés2. Numerosas empresas
multinacionales del sector bancario y de otros servicios dan empleo a
decenas de miles de personas en la India.
Algunas consideraciones sobre el medio latinoamericano

La historia de proyectos en la mayoría de los países latinoamericanos,
indica que desafortunadamente muchos de ellos, ya sea la simple adición
de una alcoba a una casa, la implantación de un sistema de información
o la construcción de una obra grande de ingeniería, terminan entre un
descalabro mayor y una catástrofe completa.
Éxito total parece ser una expresión rara en gerencia de proyectos. En unos
casos (1) el presupuesto se excede varias veces; en otros (2) el proyecto
no se completa a tiempo; en muchos más (3) la cosa no funciona como
se esperaba. Descalabro es el término aplicable a cualquiera de los tres
problemas; catástrofe, a los tres juntos.
¿Cuál es la causa principal de tanto fracaso? En casi todas las situaciones,

los que ponen el billete (los dueños) y los encargados de ejecutarlo
(el equipo) no definen bien qué es lo que quieren e inician la marcha
sin saber hacia dónde van. En términos gerenciales, los objetivos del
proyecto quedan mal definidos, lo que conduce a preguntar: ¿Qué es un
buen objetivo?
2. La India es el país con mayor población de habla inglesa en todo el mundo!
6
Algunos teóricos de los Estados Unidos de Norteamérica (EUA) dicen que

un buen objetivo tiene que ser SMART, expresión que se forma a partir
de las palabras inglesas: (1) Specific, (2) Measurable, (3) Achievable, (4)
Relevant, (5) Time-bound. ¿Cómo se puede asimilar este concepto en el
medio latinoamericano? La respuesta se pasa a elaborar.
Para cuadrar la traducción y generar una palabra llamativa en Castellano

(SMART es inteligente en inglés) se tiene que cambiar el orden a los
adjetivos anglosajones. Se va a comenzar por el quinto término. “Time-
bound” significa que todo proyecto debe tener una fecha de entrega final
así como fechas intermedias para la entrega de resultados parciales, esto
es, tiene que haber un calendario, tiene que estar FECHADO. Así el nuevo
puente a la entrada de un pueblo quede muy bien diseñado, no es lo
mismo terminarlo en los doce meses del plan original que con dos años de
retraso, como frecuentemente ocurre en muchos países.
“Relevant” quiere decir pertinente, aplicable, útil para quienes están

pagando por algo, lo cual es IMPORTANTE. Cambiarle la nomenclatura
de las calles a una ciudad es una idea interesante que puede resolver
diversos problemas puntuales pero para un país tercermundista siempre
hay prioridades más “importantes” como la salud, la educación o la
seguridad ciudadana.
“Achievable” es REALIZABLE, esto es, que un proyecto, en vez de ser un

conjunto de intenciones irreales y de buenos deseos, es algo que puede
completarse con los recursos técnicos, logísticos y humanos disponibles,
así como a tiempo y dentro del presupuesto asignado.
“Measurable” es MEDIBLE, o sea que a cualquier proyecto, cuando ya está

en desarrollo, hay que calcularle adecuadamente su progreso y compararlo
contra el calendario y el presupuesto originales, con el propósito de saber
cómo vamos y de corregir oportunamente cualquier desviación.
Por último y por fortuna, “SPECIFIC” es una palabra que, por ser casi igual
en ambos idiomas, requiere poca explicación. ESPECÍFICO quiere decir
que el objetivo descrito no dé margen a ambigüedades, que sea concreto
y que todos los involucrados entiendan de la misma forma su dimensión
y su significado.

En resumen, un buen objetivo deber ser FIRME, esto es, FECHADO,

IMPORTANTE, REALIZABLE, MEDIBLE y ESPECÍFICO. Si le falta una de esas
cualidades, a cualquiera de los objetivos centrales de un proyecto, pues la
probabilidad de enfrentar dificultades aumenta en forma significativa.
Por supuesto que la sigla SMART no es la causa que lleva a los

norteamericanos a ser más exitosos que los hispanoamericanos en la
ejecución de proyectos (de hecho, lo son). Existen, por supuesto, muchos
otros factores, más allá del alcance de esta explicación. Pero una sigla
como FIRME (tomada de las iniciales Fechados, Importantes, Realizables,
Medibles, Específicos), como propuesta conversión de la palabra SMART
al castellano, es una buena ayuda en la planeación inicial de cualquier
proyecto, sin importar cuál sea su tamaño.
¿Cómo nos puede servir esta explicación nemotécnica? - De varias formas:

de la manera positiva, unos objetivos FIRMEs colocan en el mismo contexto
a todos los participantes —generales, capitanes y soldados— en un nuevo
proyecto. De modo negativo, si en un proyecto que a alguien le asignan,
los objetivos eran verdaderamente FIRME —Fechados, Importantes,
Realizables, Medibles, Específicos— y el resultado final fue desastroso,
pues no mire para otro lado. La mala ejecución fue culpa de la actuación
del gerente y exclusivamente suya.
1.3 Principios y métodos del PMI

En la actualidad se considera fundamental en proyectos de desarrollo
de Software (SW), seguir las recomendaciones del Project Management
Institute. Esta metodología de administración de proyectos maneja técnicas
como valoración del trabajo y desglose del trabajo a realizar en tareas que
facilitan administrar un proyecto en forma efectiva para dar cumplimiento
a compromisos, más teniendo en cuenta que muchos proyectos fallan al
no cubrir expectativas en cuanto a funcionalidad, tiempo, presupuesto y
calidad. Igualmente es fundamental en la obtención de certificaciones o
valoraciones tales como ISO y CMMI.
Existe una Guía Metodológica publicada por el Project Management

Institute (PMI) para dirigir proyectos, y aparece descrita por completo en el
documento intitulado Project Management Body of knowledge (PMBOK),
cuarta edición publicada el 28 de diciembre de 2008.
8
La citada Guía Metodológica se basa en la relación armónica de cuarenta y

dos (42) procesos. Un proceso –como se ilustra en el texto– es un conjunto
relacionado de: entradas, herramientas y técnicas, y salidas. Estos se
clasifican bajo dos criterios: a) en cinco grandes grupos de procesos: inicio,
planeación, ejecución, seguimiento y control, y cierre; b) en nueve áreas
de conocimiento: integración, alcance, tiempo, costos, calidad, recursos
humanos, comunicaciones, riesgos y las compras o adquisiciones.
La ejecución de los procesos es presentada en el orden lógico en que

suceden los hechos en vida real. Es importante anotar que los procesos se
pueden realizar una o varias veces y que durante se ejecución se pueden
solapar. Los análisis de tiempo, costos y variación del cronograma y
presupuesto son vitales cuando se realiza un proyecto en vida real.
Cada proceso es ilustrado en este libro con un cuadro donde se consignan

las entradas, las herramientas y/o técnicas y finalmente las salidas. Le sigue
una descripción de las actividades que debe desarrollar y finalmente se
presenta un gráfico con el Flujo de Datos que le acompaña. En el caso de
hacer referencias en esta obra a este documento, solo se mencionara la
página de donde se tomaron los datos.
El manejo de todo tipo de proyectos de acuerdo a los planteamientos del

PMI se define en términos del desarrollo de cinco fases que cubren las
fases de su concepción general hasta el término de su desarrollo, en las
que los flujos de información se traslapan de tal forma que la información
de un proceso alimenta a los siguientes y retroalimenta a los procesos
anteriores. Las flechas indican los flujos de información.
Los 42 procesos se agrupan a su vez en cinco grandes grupos: Inicio, Planeación,

ejecución, Monitoreo y Control y Cierre como se explica a continuación:
Grupo de Procesos de Iniciación: Estos se ejecutan para definir un nuevo

proyecto o una nueva fase de un proyecto que esté en ejecución. El
Proyecto es autorizado y por lo mismo tiene vía libre para comenzar.
Grupo de Proceso de Planeación: Estos procesos establecen l alcance del

proyecto, redefinen los objetivos, y definen las acciones requeridas para
lograr que los objetivos del proyecto sean alcanzados.

Grupo de Procesos de Ejecución: Estos procesos son realizados para

terminar el trabajo que fue definido en el plan en forma tal que satisfaga
las especificaciones del proyecto
Grupo de Procesos de Monitoreo y Control: Estos procesos requieren

seguimiento a través de bitácoras, revisiones, y supervisar el avance y
rendimiento del proyecto. Identifica cualquier área en la que se requiera
algún tipo de cambio y se ajuste la planeación correspondiente.
Grupo de Procesos de Cierre: Estos se ejecutan para finalizar las actividades

mencionadas en los procesos anteriores y formalmente hacen parte del
cierre del proyecto o de una fase en particular.
El siguiente diagrama muestra los cinco grupos de procesos y sus mutuas

interrelaciones:
Procesos de Procesos de
iniciación planeación
Procesos de Procesos de
control ejecución
Procesos de
cierre
Enlaces entre procesos
Figura 1.1. Grupos de procesos de manejo del ciclo de vida de un proyecto
Las areas generales de conocimientos que se requieren para la realización

de los procesos generales a ser realizados durante la dirección y manejo
de un proyecto en general, son planteadas por el Project Management
Institute (PMI) en nueve (9) grandes asociaciones, a saber:
• Integración: Consta de la definición del proyecto, el desarrollo del
plan, estudio de los procesos y políticas organizacionales, uso de
técnicas de administración por objetivos y del trabajo a realizar de
acuerdo a los resultados esperados.
10
• Alcance: que comprende determinar el ciclo de vida del producto

resultante de un proyecto, aplicar criterios de selección de proyectos
de acuerdo a las recomendaciones de un plan estratégico y el ejercicio
de descomposición del trabajo que implica el desarrollo del proyecto
en unidades más manejables y estructuradas de acuerdo a la secuencia
lógica que se determine.
• Tiempo: establecer el plan de desarrollo del proyecto en el tiempo,
mediante la secuencia de las tareas y dando a lugar al cronograma del
mismo
• Costo: aquí se define el costo del proyecto y el flujo de los dineros
necesarios para poder ejecutar el proyecto
• Calidad: la planeación y el control, mediante el estudio del impacto
y el empleo de los estándares de Calidad aplicables al entregable o
producto final.
• Recursos Humanos: en este grupo están comprendidos todos los
estudios de los requisitos, formas de contratación y evaluación del
desempeño de los recursos humanos a ser empleados para el desarrollo
de un proyecto.
• Comunicaciones: comprende el análisis de los medios de comunicación
y de las exigencias de comunicación de todos los participantes en un
proyecto.
• Riesgos: es el análisis del impacto y de las probabilidades de los riesgos
que la ejecución de todos los proyectos conlleva.
• Manejo de Adquisiciones y de las Compras: es el estudio de la
cantidad y calidad de las compras y adquisiciones necesarias para
que el proyecto pueda ser realizado.
Existe otra serie de conocimientos que todo gerente de proyecto debe tener
muy en cuenta y entre ellas la que más se destaca es la de la Ética Profesional
que comprende todos los conceptos relacionados con el respeto a normas
y regulaciones ya sea a nivel institucional o a nivel personal que deben ser
consideradas durante todo el desarrollo de un proyecto.
En la práctica se han identificado una serie de factores cercanamente muy

interrelacionados que son fundamentales para el éxito de un proyecto,
puesto que determinan la CALIDAD del producto resultante o entregable
final del mismo, tal y como se muestra enseguida:

LA TRIPLE RESTRICCIÓN MEJORADA
Recursos
Riesgos
Alcance
Tiempo CALIDAD Costo
Figura 1.2. Restricciones y sus interrelaciones
Es también muy importante tener siempre presente las relaciones dinámicas

entre la estructura de desagregación del trabajo (EDT) o Work breakdown
structure (WBS en inglés), que va a ser utilizada en un proyecto y las
diferentes unidades organizacionales de la empresa que desarrolla el
proyecto, como lo sugiere la siguiente gráfica, hecha para un proyecto
de diseño y elaboración de equipos como turbinas, ventiladores y un
compresor nuevo: (ver figura 1.3 página siguiente).
Lo que es básico para el inicio de un proyecto, según el PMI, es analizar y

dejar bien claros los siguientes aspectos:
• Definir el resultado final en términos de un ENTREGABLE y que este
sea medible y cuantificable.
• Identificar los grupos de interesados (clientes, patrocinadores, equipos
de trabajo, gerente, coordinadores, ...).y sus expectativas con respecto
al proyecto
• Establecer un plan de desarrollo preliminar.
• Determinar la Cantidad, Calidad y disponibilidad de los recursos.
• Analizar eventos o contingencias que puedan afectar positiva o
negativamente, el logro de los objetivos del proyecto.
• Determinar los mecanismos de comunicación entre los integrantes del
proyecto.
12
EL WBS Y LA ORGANIZACIÓN
Project
S
Engine Training
S
Fan Compressor Turbine
S
Fan Full Scale Minor Dual Spool
S
Assembly Fan Rig Fan Rig Compressor Rig
S
S
S
Test
S
Mechanical Cost
Design Account
Design
Company
Analytical Cost
Engineering
Design Account
S
Drafting and Cost
Checking Account Work Packages
Mfg
S
FRANCISCO J. TORO LÓPEZ

Figura 1.3. WBS y su relación con el Plan de cuentas.
13
Ciclo de vida del proyecto

El ciclo de vida de un proyecto es el lapso transcurrido entre la fecha de
inicio y la fecha de terminación del citado proyecto, comprende estos dos
conceptos fundamentales:
• Ciclo de vida de Proyecto: Conjunto de proyectos o fases, generalmente

secuenciales cuyo número es determinado por los requerimientos de
control de la organización o de las organizaciones involucradas en un
proyecto
• Fases del Proyecto: Similar a la anterior pero dirigida a una de las
fases del proyecto. Cuando los proyectos son muy extensos se suelen
dividir en etapas o fases.
El producto y el proyecto tienen generalmente ciclos de vida diferentes.

Ilustremos lo anterior con un simple ejemplo: el proyecto es construir una
casa familiar con tres habitaciones, sala, comedor, cocina, dos garajes,
cuatro baños y un jardín. Se construye en un lapso de ocho meses y a un
costo de quinientos millones. Este es el proyecto y su ciclo de vida son los
mencionados ocho meses. El Producto final, la casa, durará unos cuarenta
años en condiciones de ser habitable y este tiempo, es el tiempo de
operación del producto. Si este ejemplo se tradujera en términos gráficos,
el resultado sería similar al de la siguiente figura:
F
i
n
Ciclo de p
Plan de Operación del producto r
vida del
negocios o
producto d
u
Idea c
t
o
INICIAL INTERMEDIAS FINAL
Ciclo vida proyecto
En algunos medios es conveniente contar con una oficina de manejo de

proyectos (siglas en inglés PMO correspondiendo a Project Management
Office) a cargo precisamente de reglamentar y estandarizar los procesos
de planeación y evaluación de proyectos en las empresas. Esta oficina
14
es la que se encarga también de reunir todas las experiencias derivadas

del desarrollo de proyectos y hacerla disponible para la planeación de
los futuros.
1.4 Metodologías empleadas en desarrollo

de proyectos informáticos
Aunque el propósito de este libro no es propiamente entrar en detalle sobre
las diversas metodologías prevalecientes en el mercado para desarrollar
productos informáticos, el autor va a mencionar las principales características
de las más comúnmente empleadas en la actualidad y que cuentan muy
probablemente con la mayor cantidad de usuarios y aficionados.
El limitado número de estas metodologías mencionadas en esta obra,

no significa de modo alguno que son las únicas puesto que es de todos
conocido que existen muchas maneras de llevar a cabo proyectos
orientados al área de la Informática. Algunas de estas metodologías son
inclusive desconocidas en el medio profesional pues han sido desarrolladas
en forma privada por algunas empresas.
Por ser de significativa importancia y por ser una de las metodologías que
quizás con mayor holgura cubre no solo el ámbito de lo que es propiamente
el desarrollo de aplicaciones, sino el ámbito de la planeación estratégica
se comienza este numeral con una mención a ITIL.
¿Qué es ITIL?
Esta metodología fue desarrollada a finales de 1980, y corresponde a la
expresión Biblioteca de Infraestructura de Tecnologías de la Información
(ITIL) y se ha convertido en un estándar mundial de facto en la Gestión
de Servicios Informáticos. Iniciada como una guía para el gobierno de
Inglaterra, la estructura base ha demostrado ser útil para las organizaciones
en todos los sectores a través de su adopción por innumerables compañías
como base de consulta, educación y soporte de herramientas de software.
Hoy, ITIL es conocido y utilizado mundialmente y pertenece a la

Organización de Comercio del Gobierno Británico (Office of Government
Commerce), pero es de libre uso.

ITIL fue desarrollada al reconocer que las organizaciones dependen cada

vez más de la Informática para alcanzar sus objetivos corporativos. Esta
dependencia en continuo aumento ha dado como resultado una necesidad
creciente de servicios informáticos de calidad, que se correspondan con
los objetivos del negocio y que satisfagan los requisitos y las expectativas
de los clientes. A través de los años, el énfasis pasó de estar sobre el
desarrollo de las aplicaciones TI a la gestión de servicios de TI.
La aplicación TI (a veces nombrada como un sistema de información)

solo contribuye a realizar los objetivos corporativos si el sistema está a
disposición de los usuarios y, en caso de fallos o modificaciones necesarias,
es soportado por los procesos de mantenimiento y operaciones.
A lo largo de todo el ciclo de los productos TI, la fase de operaciones

alcanza cerca del 70-80% del total del tiempo y del coste, y el resto se
invierte en el desarrollo del producto (u obtención). De esta manera, los
procesos eficaces y eficientes de la Gestión de Servicios TI se convierten
en esenciales para el éxito de los departamentos de TI.
Esto se aplica a cualquier tipo de organización, grande o pequeña, pública

o privada, con servicios TI centralizados o descentralizados, con servicios TI
internos o suministrados por terceros. En todos los casos, el servicio debe ser
fiable, consistente, de alta calidad, y de aceptable costo. La siguiente figura
explica a grandes rasgos los diversos componentes que cubre el método ITIL:
LA
entación Gest TE
plem ión C
a im de
al
N
i
ios
OL
vic
r
n fr
pa
er
OG
ae
n
ació
stru
s
de
ÍA
ctura
c
Planif
Soporte
Gestió
s TI
al servicio
Provisión
del servicio
EG negocio
Gestión
Ges
IO
de la
seguridad
ti
OC
d el
ón
va
ea
d
cti plic
spe acio
N
Per nes
EL
Figura 1.4. Componentes de ITIL
16
De acuerdo a este diagrama, es de resaltar que ITIL cubre aspectos

generales que van desde el conocimiento del negocio hasta la planeación
e implementación de los recursos tecnológicos, a través de una gestión
que focaliza la infraestructura de tecnologías de información (TI) y el
desarrollo de aplicaciones, ocupando siempre un lugar preferencial
la seguridad de la información. ITIL fue producido originalmente a
finales de 1980 y constaba de 10 libros centrales cubriendo las dos
principales áreas denominadas Soporte al Servicio y la prestación de
los Servicios.
Estos libros fueron más tarde soportados por 30 libros complementarios

que cubrían una numerosa variedad de temas, desde el cableado hasta la
gestión de la continuidad del negocio. A partir del año 2000, se acometió
una revisión periódica de esta gran biblioteca de conocimientos y procesos
metodológicos.
En su última revisión, ITIL ha sido restructurado para hacer más sencillo el

acceder a la información necesaria para administrar todos sus servicios. Los
libros centrales se han agrupado en dos, cubriendo las áreas de Soporte del
Servicio y de Prestación del Servicio, en aras de eliminar la duplicidad y
mejorar la navegación. El material ha sido también actualizado y revisado
para un enfoque más conciso y claro.
Hay un conjunto de entidades que respaldan a ITIL entre ellas:

1. OGC - Office of Government Commerce - Reino Unido www.ogc.
gov.uk
2. EXIN – Examination Institute for Information Science www.exin-
exams.com/
3. ISEB – Information Systems Examination Board – British Computer
Society www.iseb-exams.com
4. Pink Verify – Entiodad Certificadora de Herramientas de Gestión de
ITIL www.pinkelephant.com/pinkverify/
5. ITSMF – Information Technology Service Management Forum www.
itsmfusa.org/
ITL reconoce la existencia de un plan estratégico fundamental basado

en cinco pasos para poder prestar en forma eficiente servicios de TI en
cualquier empresa y que se extrae de la siguiente gráfica:

I. Estrategia del Servicio (SS -Service Strategy)
II. Diseño del Servicio (SD – III. Transición del Servicio – IV. Operación del Servicio
Service Design) (ST - Service Transition)) (SO – Service Operation)
V. Mejora Continua de Servicios (CSI – Continual Service Improvement)
Como se puede concluir hasta aquí, ITIL es más que una simple serie
de recomendaciones sobre cómo instalar un desarrollo de aplicaciones
computarizadas, dado que amplia su enfoque en todos los niveles de una
empresa en los que la información es un elemento necesario y quizás
hasta vital. Los siguientes numerales van a explicar en forma general los
métodos de desarrollo de aplicaciones computarizadas, más comúnmente
empleados en la actualidad.
La metodología CASE
La metodología CASE (Computer Aided Software Engineering) surgió a
principios de los años 90’s y lo que plantea es una secuencia de etapas
detalladas que brindan para cada etapa del desarrollo una descripción, una
definición de los objetivos y de las metas, los productos esperados de cada
etapa y una lista de las tareas que son convenientes realizar en cada etapa.
Cuenta además con una serie de facilidades (muchas de ellas

computarizadas) que colaboran sustancialmente en la puesta en práctica
de su manejo y que agilizan diversos procesos en forma efectiva; las etapas
del ciclo de vida del desarrollo de sistemas que usan esta metodología
aparecen en la siguiente gráfica:
Etapas de la metodología CASE
Estrategía
Análisis
Diseño
Construcción Documentación
Transición
Producción
Figura 1.5. Etapas de la metodología CASE
18
Por la importancia ganada en los últimos años, a continuación se van a

describir los principios generales de un grupo de metodologías aplicables
al desarrollo de proyectos de Informática, que se han dado en llamar
Ágiles, a saber:
• En proyectos informáticos la productividad de los recursos humanos

empleados es un factor CRUCIAL en aras de cumplir con las expectativas
de los interesados; el factor humano es altamente ponderado y
evaluado en este tipo de proyectos
• Las metodologías ágiles dan mayor valor al individuo, a la colaboración
con el cliente y al desarrollo incremental del software con iteraciones
más cortas, es decir con ciclos de producción y evaluación más cortos
y realistas
• Este enfoque está mostrando su efectividad en proyectos con requisitos
muy cambiantes y cuando se exige reducir drásticamente los tiempos
de desarrollo pero manteniendo una alta calidad.
• Las metodologías ágiles están revolucionando la manera de producir
software y a la vez generando un amplio debate entre sus seguidores
y quienes por escepticismo o convencimiento no las ven como
alternativa del todo valida para las metodologías tradicionales.
¿Porqué la utilidad de las metodologías ÁGILES?

Por las siguientes razones:
• Las metodologías ágiles han demostrado en sus pocos años de existencia
mayor eficacia en el control del avance y manejo de las expectativas,
sin embargo debe aceptarse que aunque no son la solución a todos
los problemas, si constituyen una conveniente alternativa para el
desarrollo de proyectos informáticos.
• Hasta hace poco la mayoría de las metodologías de desarrollo llevaban
asociada un marcado énfasis en el control de los proceso mediante una
rigurosa definición de los roles, actividades y artefactos, incluyendo
el modelado de datos y de los procesos y una documentación
detallada.
• Este esquema “tradicional” para abordar el desarrollo de software había
demostrado ser algo efectivo y muy conveniente en proyectos de gran
tamaño (respecto al manejo del tiempo y de los recursos), donde por lo
general se exige un alto grado de “formalidades” en el proceso.

• Sin embargo, este enfoque no resulta ser el más adecuado para

muchos de los proyectos actuales en el cual el entorno del sistema
es muy cambiante, y en donde se exige reducir drásticamente los
tiempos de desarrollo pero manteniendo siempre una alta calidad en
los entregables de los mismos.
• Ante las dificultades para utilizar metodologías tradicionales con
restricciones de tiempo y flexibilidad, muchos equipos de desarrollo
se resignan a prescindir del ¨buen hacer¨ de la ingeniería del software,
asumiendo el riesgo que ello conlleva.
Breve historia de las metodologías ágiles

• En febrero de 2001, tras una reunión celebrada en Utah-Estados
Unidos, nace el término <ágil> aplicado al desarrollo de software.
En esta reunión participaron un grupo de 17 expertos de la industria
del software, incluyendo algunos de los creadores o impulsores de
metodologías de software.
• Su objetivo fue esbozar los valores y principios que deberían permitir
a los equipos desarrollar software rápidamente y respondiendo a los
cambios que puedan surgir a lo largo del proyecto.
• Se pretendía ofrecer una alternativa a los procesos de desarrollo
de software tradicionales, caracterizados por ser rígidos y dirigidos
por la documentación que se genera en cada una de las actividades
desarrolladas.
• Tras esta reunión se creó The Agile Alliance3, una organización, sin
ánimo de lucro, dedicada a promover los conceptos relacionados con el
desarrollo ágil de proyectos de software y ayudar a las organizaciones
para que adopten dichos conceptos.
• El punto de partida es el Manifiesto Ágil, que es un documento que
resume la filosofía ágil.
Según el Manifiesto Ágil se valora más:

• Al individuo y a las interacciones del equipo de desarrollo que al
proceso y las herramientas empleadas en el desarrollo.
• La gente es el principal factor de éxito de un proyecto de desarrollo de
software y es más importante construir un buen equipo que construir
el entorno en el que se desarrolle el proyecto respectivo, dando lugar
a las siguientes prácticas:
20
– Es mejor crear el equipo y que este configure su propio entorno de de-

sarrollo con base en sus necesidades de interacción y comunicación.
– Desarrollar software que funcione más que conseguir una buena
documentación. La regla a seguir es no producir documentos a
menos que sean necesarios de forma inmediata para tomar una
decisión importante. Los documentos deben ser cortos y centrarse
en lo fundamental.
– La colaboración con el cliente más que la negociación de un
contrato.
• Se propone que exista una interacción constante entre el cliente y el
equipo de desarrollo. Esta colaboración será la que marque la marcha
del proyecto y asegure su éxito.
• Responder a los cambios más que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (en los requisitos, en uso de tecnologías, en el equipo, etc.)
determina el éxito o fracaso del mismo.
Y tener siempre una aptitud abierta hacia este principio...
*La planificación no debe ser estricta sino flexible y abierta a los cambios*
Las 12 prácticas empleadas en la planeación de las tareas conllevan los

siguientes principios generales:
I. La prioridad es satisfacer al cliente mediante tempranas y continúas
entregas de productos o subproductos ligados al desarrollo de software
que le aporten valor.
II. Bienvenidos los cambios. Se capturan los cambios para que el cliente
tenga una ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo posible
entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo
largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el
entorno y el apoyo que necesitan y confiar en ellos hasta conseguir
finalizar el trabajo.
VI. El diálogo cara a cara es el método más eficiente y efectivo para
comunicar información en el equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso del proyecto.

VIII.Los procesos ágiles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberían ser capaces de
mantener un ambiente de paz constante y estable.
IX. La atención continua a la calidad técnica y al buen diseño mejora la
agilidad.
X. La simplicidad es esencial.
XI. Mejores arquitecturas, requisitos y diseños surgen de equipos
organizados por sí mismos.
XII. A intervalos regulares, el equipo reflexiona respecto a cómo llegar a
ser más efectivo, y según esto ajusta su comportamiento.
¿Qué hábitos pueden ser promovidos por un gerente que adopte una
aptitud flexible en el manejo de proyectos de tecnologías de información
y la comunicación (TIC)? Las respuestas son las siguientes:
1. Cuestionar todo: Para ser eficaz y ágil como un Gerente de proyecto,
aprender a hacer preguntas sencillas pero potentes que cuestionen el
status quo.
2. Relacionarse con la innovación: Ampliar la visión, experiencias y
redes para descubrir nuevos enfoques para un trabajo. Aprovechar
esta exposición para ser más creativos e innovadores.
3. Un error puede ser el camino al éxito: Usar la experimentación para
descubrir lo que sí funciona y mejorar la capacidad para adaptarse, es decir
permitirse fallar en pequeños pasos para lograr luego grandes éxitos.
4. Ideas y pensamientos de comunicación: Dar rienda suelta a la
creatividad. El gerente ágil facilita los procesos para mejorar las
oportunidades y lo que es más importante, para sentar precedentes
con nuevos pensamientos e ideas.
5. Ofrecer valor frecuentemente: Convertir en hábito todo lo que
se considere indispensable y que proporcione un valor tangible al
producto final. Además cabe esperar que su capacidad de liderazgo le
facilite brindar soluciones y poder anticiparse a los problemas.
6. Cambio incremental: Hacer pequeños cambios incrementales
constantemente en el tiempo para lograr saltos cuantificables en
productividad y agilidad.
7. Conectar siempre con un propósito: Conectarse con un propósito
para mejorar la creatividad y la agilidad y así liberar esas reservas
ocultas del personal involucrado en un proyecto TIC.
22
El Gerente de proyecto flexible es una posición única para convertirse en

indispensable para una organización. Mediante el empleo de estos siete
hábitos, puede hacer una diferencia y cada uno de estos hábitos puede
utilizarse no solo para hacer proyectos más ágilmente, sino también hacer
individuos más ágiles mentalmente.
Principios y prácticas XP
Esta derivación o subclase de metodología surge a partir del manifiesto
Ágil y los principios y prácticas que se manejan con esta denominación,
conocidas también en algunos medios como eXtreme Programming (XP)
o Fast Programming, aparecen mostradas en forma gráfica, así:
TABLA 1.2. Principios básicos y Prácticas habituales del método eXtreme Programming (XP)
4 PRINCIPIOS 12 PRÁCTICAS
Comunicación 1. Planeación 7. Integración permanente
2. Pruebas (testing) 8. El usuario al lado del
equipo programador
Simplicidad 3. Programación por pares 9. Entregas frecuentes y
4. Refactoring pequeñas
10. 40 horas de trabajo
a la semana
Retroalimentación (Feedback) 5. Diseños sencillos 11. Estandarización del
6. Propiedad colectiva del Código
Coraje Código 12. Metáfora.
Con base en la experiencia ganada en los últimos años en este tipo de

proyectos, se ha comprobado que existen diferencias prácticas entre las
metodologías ágiles y no ágiles, que se resumen en esta tabla:
TABLA 1.3. Comparando métodos Ágiles vs. Métodos Tradicionales
METODOLOGÍAS ÁGILES METODOLOGÍAS TRADICIONALES

Basadas en heurísticas provenientes de prácti- Basadas en normas provenientes de estándares
cas de producción de código seguidos por el entorno de desarrollo
Especialmente preparados para cambios du-

Cierta resistencia a los cambios
rante el proyecto
Impuestas internamente (por el equipo) Impuestas externamente
Proceso mucho más controlado, con numero-

Proceso menos controlado, con pocos principios
sas políticas/normas

No existe contrato tradicional o al menos es

Existe un contrato prefijado
bastante flexible
El cliente interactúa con el equipo de desarro-

El cliente es parte del equipo de desarrollo
llo mediante reuniones
Grupos pequeños (menos de10 integrantes)

Grupos grandes y posiblemente distribuidos
trabajando en el mismo sitio
Pocos artefactos Más artefactos
Pocos roles Más roles
La arquitectura del software es esencial y se

Menos énfasis en la arquitectura del software
expresa mediante modelos.
Los roles en las metodologías XP

En este tipo de proyectos informáticos que usan metodologías XP’s, existen
varios actores cuyos roles se explican enseguida:
• Programador. Escribe las pruebas unitarias y produce el código del
sistema.
• Cliente. Escribe las historias de usuario y las pruebas funcionales
para validar su Implementación. Además, asigna la prioridad a las
historias de usuario y decide cuáles se implementan en cada iteración
centrándose en aportar mayor valor al negocio.
• Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente, difunde los resultados en
el equipo y es responsable de las herramientas de soporte para pruebas.
• Encargado del seguimiento (Tracker). Proporciona realimentación al
equipo. Verifica el grado de acierto entre las estimaciones realizadas
y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza
el seguimiento del progreso de cada iteración.
• Entrenador (Coach). Es responsable del proceso global. Debe proveer
guías al equipo de forma que se apliquen las prácticas XP y se siga el
proceso correctamente.
• Consultor. Es un miembro externo del equipo con un conocimiento
específico en algún tema necesario para el proyecto, en el que puedan
surgir problemas.
• Gestor (Big boss). Es el elemento humano que vincula los clientes
y los usuarios con los programadores, colaborando a fin de que el
equipo trabaje efectivamente y creando las condiciones adecuadas.
Su labor esencial es de coordinación.
24
En el siguiente diagrama se pueden analizar las muy comunes formas de

interactuar estos diversos actores durante el desarrollo de un proyecto
informático:
1. El cliente define valor de
negocio a implementar
2. El programador estima el esfuerzo

necesario para su implementación
3. El cliente selecciona qué construir

de acuerdo con su prioridad y
las restricciones de tiempo
4. El programador constituye
valor de negocio
5. Vuelve al paso 1.
Proceso XP
Figura 1.6. Interacciones de funciones
El ciclo de vida ideal de un proyecto que use alguna metodología de tipo

ágil consiste fundamentalmente de seis fases:
1. Exploración,
2. Planificación de la Entrega (Release),
3. Iteraciones,
4. Producción,
5. Mantenimiento y
6. Cierre del Proyecto.
En forma resumida se puede explicar los múltiples pasos que implica el

manejo de esta metodología mediante la siguiente gráfica que aunque
parece ser algo complicada de comprende refleja perfectamente a la forma
dinámica como se mueven los procesos entre los diferentes actores: (ver
figura página siguiente).
Las historias de usuario

1. Es una técnica complementaria de las metodologías agiles que es
utilizada para especificar formalmente los requisitos funcionales y
operativos de un producto de software a ser desarrollado.

Cliente in situ Juego de la

planificación
40 horas
Metáfora semanales
Diseño
Refactorización sencillo
Programación PRUEBAS!!! Versiones

en parejas pequeñas
Estándares de
codificación
Propiedad
colectiva Integración
continua
Figura 1.7. Las 12 prácticas XP y cómo se refuerzan entre sí
2. Se maneja con una serie de tarjetas de papel en las cuales el cliente

describe brevemente las características que el sistema debe poseer,
sean requisitos funcionales o no funcionales.
3. El tratamiento de las historias de usuario debe ser muy dinámico
y flexible, queriendo decir con esto que los contenidos deben
permanentemente ser actualizados y ser empleados dependiendo del
avance del trabajo.
4. Cada historia de usuario debe ser lo suficientemente comprensible y
delimitada para que los programadores puedan hacerla e implementarla
en unas pocas semanas.
Otras metodologías ágiles

SCRUM. Especial para proyectos que están expuestos a sufrir rápidos
cambios de los requisitos funcionales. Sus principales características son:
El desarrollo de software se realiza mediante iteraciones, denominadas
sprints, con una duración aproximada de unos 30 días. Otra característica
es sostener reuniones tipo usuario-programador a lo largo de todo el
proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo
de desarrollo para una necesaria coordinación e integración.
26
Para tener éxito con los métodos Agile y Scrum y según la complejidad de
los proyectos, se requiere de un proceso de gestión coherente que incluya
información para comprender los diversos roles involucrados en estos
proyectos y los pasos para completar las tareas esenciales.
CRYSTAL METHODOLOGIES. Conjunto de metodologías para el desarrollo

de software caracterizadas por estar centradas en las personas que
componen el equipo y la reducción al máximo del número de artefactos
producidos.
COCKBURN. El desarrollo de software lo considera un juego cooperativo de

invención y comunicación, limitado lógicamente por los recursos humanos
y tecnológicos que sean utilizados. El equipo de desarrollo es un factor
clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y
destrezas, así como tener políticas de trabajo en equipo bien definidas.
DYNAMIC SYSTEMS DEVELOPMENT METHOD7 (DSDM). Sus principales

características son: es un proceso iterativo e incremental y el equipo de
desarrollo y el usuario trabajan juntos.
ADAPTIVE SOFTWARE DEVELOPMENT (ASD). Sus principales

características son: iterativo, orientado a los componentes software más
que a las tareas y tolerante a los cambios. El ciclo de vida que propone
tiene 3 fases esenciales: especulación, colaboración y aprendizaje.
FEATURE -DRIVEN DEVELOPMENT (FDD). Define un proceso iterativo

de 5 pasos.
LEAN DEVELOPMENT (LD). Se va a dar una explicación detallada de esta

metodología en los capítulos subsiguientes, por la significativa importancia
que ha cobrado en los últimos años. Es también conocida en algunos
medios como Lean Project Management y se hará un especial esfuerzo en
describirla en el resto de los capítulos de este libro.
Rational Unified Process (RUP)

Este método de desarrollo se suele llamar Rational, y es el mismo RUP
(con algunas variaciones) conocido desde mediados de los años 90’s. Es

más reconocido como un producto de software hecho por sus creadores

y utilizado ya hace algunos años por la IBM. El software metodológico
Rational (RUP), ha sido utilizado desde hace rato y algunos expertos lo
consideran de mucha complejidad y difícil de interpretar, muchas veces
por involucrar quizás demasiados conceptos abstractos y el empleo de un
seudocódigo nemotécnico.
RUP esta muy bien orientado para proyectos que requieren infraestructuras
grandes, ambientes Myfriend muy grandes como el que proveen servidores
de empresas multinacionales y exige un profundo conocimiento de
sistemas de información, tecnologías IBM, avanzados conocimientos de
integración (interpretados generalmente como amplios conocimientos en
modelamiento UML3 y el uso del lenguaje Java 2 Enterprise Edition).
NOTA: JAVA es un lenguaje de múltiples usos y ampliamente empleado por

desarrolladores expertos que deben programar con exigentes características
de seguridad (como suelen ser los bancos y muchas entidades financieras
a nivel internacional).
La metodología RUP, llamada así por sus siglas en inglés Rational Unified
Process, divide en 7 etapas o fases el desarrollo de un proyecto de desarrollo
de aplicaciones de software:
• Modelo del Negocio (Business Modeling): El ojetivo en esta etapa es
hacer claro las reglas del negocio relativas al manejo de la información.
• Requisitos funcionales (Requirements): En esta etapa el objetivo es
determinar los requisitos de funcionamiento y de operación.
• Analisis y Diseño (Analysis/Design): En esta etapa el objetivo es diseñar
los programas, módulos, rutinas y demás componentes del sistema,
buscando una arquitectura óptima del mismo.
• Implementación (Implementation): Se instalan los bancos de datos y se
montan igualmente las facilidades de comunicación de los programas
e interfaces previstas.
• Pruebas (Test): en esta fase se realizan todas las pruebas tanto a nivel
de los módulos independientes como las resultantes de la integración
de estos.
3. Siglas del término en inglés, Unified Modeling Language. Es una herramienta para modelar objetos
de un sistema de información.
28
• Configuración y Administración de Cambios (Configuration & Change

Manage): el propósito aquí es llevar a cabo los cambios tanto en la
configuración de equipos, servidores y programas así como en las
diferentes interfases.
• Instalación (Deployment): El objetivo es poner en funcionamiento el
producto del proyecto.
Cada una de estas etapas es desarrollada mediante un ciclo de iteraciones,

lo cual consiste en reproducir el ciclo de vida en cascada a una menor y
cada vez más menor escala. Los objetivos de una iteración se establecen
en función de la evaluación que se haga de las cantidades y calidades de
las iteraciones precedentes o precursoras.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración,
es llevado a cabo bajo la guía combinada de dos disciplinas muy
interrelacionadas, a saber:
1. Disciplina de desarrollo
– Ingeniería de Negocios: Que consiste en entender las necesidades
del negocio.
– Análisis de Requerimientos: Trasladando las necesidades del nego-
cio a un sistema automatizado de manejo de información.
– Análisis y Diseño: Trasladando los requerimientos dentro de la ar-
quitectura de software.
– Implementación: Creando software que se ajuste a la arquitectura
y que tenga el comportamiento deseado.
– Pruebas: Asegurándose que el comportamiento requerido es el
correcto y que todo los solicitado esta presente.
2. Disciplina de soporte
– Configuración y administración del cambio: Guardando todas las
versiones del proyecto.
– Administrando el proyecto: Administrando horarios y recursos.
– Ambiente: Administrando el ambiente de desarrollo.
– Distribución: Hacer todo lo necesario para la salida del proyecto.
Es recomendable que a cada una de estas iteraciones se les clasifique y

ordene según su prioridad, y que cada una pueda ser convertida luego,

en un entregable al cliente. Esto trae como beneficio una conveniente y

necesaria retroalimentación que se tendría en cada paso que signifique un
entregable o en cada iteración.
Los elementos del RUP son entonces:

• Actividades, Son los procesos que se llegan a determinar en cada
iteración.
• Trabajadores, Vienen hacer las personas o entes involucrados en cada
proceso.
• Artefactos, Un artefacto puede ser un documento, un modelo, o un
elemento de un modelo.
Una particularidad de esta metodología es que, en cada ciclo de iteración,

se hace exigente el uso de artefactos, siendo por este motivo, una de las
metodologías más importantes para alcanzar un grado de certificación en
el desarrollo del software.
La Metodología RUP es muy conveniente y adaptable para proyectos de

largo plazo. Existen varios link referenciados y originales in inglés, y en la
red Internet hay muchos más para escoger, a saber:
• http://www.ibm.com/developerworks/rational/library/05/0816_Louis/
• http://www.buzzle.com/articles/rational-unified-process-rup-
methodology.html
• http://www.mariosalexandrou.com/methodologies/rational-unified-
process.asp
• http://www.cybertesis.edu.pe/sdx/sisbib/fiche.xsp?base=documents&i
d=sisbib.2005.tupia_am-principal
• http://www.scribd.com/doc/41153/RUP-Best-Practices
• http://portal.acm.org/citation.cfm?id=581455&dl=GUIDE&coll=GUI
DE&CFID=84545597&CFTOKEN=50480514
• http://www.my-project-management-expert.com/the-advantages-and-
disadvantages-of-rup-software-development.html
• http://www.blogged.com/topics/rup-methodology/
• http://hubpages.com/hub/Transition_Phase
Un comparativo con la última de las metodologías de desarrollo mencionadas

o sea SOA que se explica un poco más adelante, se halla en este enlace:
• http://it.toolbox.com/blogs/the-soa-blog/rup-versus-agile-for-soa-
methodology-10850
30
Otro anexo adjunto Rational Vs. XP:

En la enciclopedia Wikipedia explica esto en términos algo resumidos:
• http://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational
y existen otras referencias como:

• http://www.slideshare.net/msch/utilizando-metodologia-rup-parte1
Metodología SOA
Esta metodología está orientada hacia la integración de servicios
suministrados por sistemas con diferentes arquitecturas, tecnologías y/o
sistemas de información, que fueron o están realizados en diferentes
sistemas ya sean grandes o pequeños, así como por el uso de varios
lenguajes como JAVA, PHP, C#,. Net, ASP, incluidos los viejos lenguajes
como Pascal, RPG, PERL, Cobol, C, o C++.
SOA lo integra todo pero exige saber mucho de arquitecturas de sistema

complejos para convertir todo en un conjunto de servicios integrados.
Dado que reúnen una serie de características comunes, es posible

igualmente combinar la metodología RuP con la XP como se puede
apreciar en la siguiente gráfica:
Figura 1.8. Combinando metodologías RUP y la XP

Como se ve existe una gran variedad de metodologías para proyectos

informáticos que por su extensión no se van a explicar en detalle en esta
obra; tan solo una de ellas va a ser descrita con ciertos detalles y es la
metodología Lean Development debido a consideraciones un tanto ligadas a
las experiencias particulares del autor y concernientes al tema de este libro.
Las siguientes son las principales recomendaciones que los gerentes de proyectos
informáticos que usen metodologías agiles deberían tener en cuenta:
Conclusiones
• El gerente de proyectos de software debe:

– Conocer en detalle, (o mejor aún)
– Participar en la adaptación (o mejor aún)
– Participar en la creación
del proceso de software que va a orientar el desarrollo
• Velar por el cumplimiento del proceso
• Estar pendiente de cualquier desvío del cronograma
(y presupuesto) detallado
Figura 1.9. Algunas conclusiones y recomendaciones del método XP
Existen a su vez otra serie de recomendaciones derivadas de las experiencias

de grandes empresas que desarrollan proyectos informáticos con base en
este método, a saber:
Conclusiones
• Los procesos de desarrollo de software modernos

deben estar basados en RUP
• RUP es un marco general, no un estándar
– Cada compañía debe ajustarlo a sus necesidades
– Evitar exageraciones!!!
• Enfoque dominado por casos de uso
• “Extreme Programming ha tenido enorme acogida
• Hay muchas herramientas libres de alta calidad, que
ayuda enormemente en el proceso de desarrollo
Figura 1.10. Más conclusiones derivadas del método RUP
Lean Development (Lean Project Management)

Introducción: Esta técnica de desarrollo de proyectos ha cobrado especial
auge en los últimos años y hace parte de las metodologías mencionadas
como agiles. Se pretende en esta obra explicarla aquí en complacencia
32
total a los términos originales de su manejo, para después entrar a detallarla

en forma tal que hasta facilite al lector su comprensión desde el punto de
vista de los principios que invocan las metodologías agiles.
Los principios básicos de esta metodología, parten desde las instancias de

la planeación estratégica de una empresa y por lo mismo toman muy en
cuenta la serie de propuestas y planes que giran alrededor de un concepto
teórico llamado cadena de valores que se va a explicar enseguida:
La cadena de valores de los procesos del negocio

La cadena de valores es uno de los mecanismos de evaluación más usados
en diversas instancias de la planeación estratégica de una empresa y en la
evaluación de funciones de un producto resultante. A la expresión cadena
de valores se le suele añadir la palabra agregados para dar a entender
que es la secuencia de procesos o funciones de un negocio en el cual una
utilidad cuantificable y relevante, es agregada en forma continua a los
productos o servicios de una empresa. Estas funciones son:
1. Investigación y Desarrollo (I&D) o sea la generación y experimentación
con ideas relativas a nuevos productos, servicios o procesos.
2. Diseño de productos, servicios o procesos: la planeación detallada y
el diseño de productos, servicios o procesos
3. Producción: la coordinación y el ensamblaje de recursos e insumos
necesarios para producir un producto o un servicio
4. Mercadeo: la forma en la cual individuos o grupos perciben y valoran
los atributos de productos o servicios y luego deciden comprar estos
productos o servicios
5. Distribución: el mecanismo por el cual los productos o servicios son
entregados a los clientes
6. Servicio al Cliente: las actividades de soporte y satisfacción al Cliente,
posteriores a la adquisición y disfrute del producto o servicio.
Investigación y Diseño de Servicios

Producción Mercadeo Distribución
desarrollo productos/serv. al cliente
Pasos de la cadena de valores agregados
Figura 1.11. Cadena de Valores Agregados

Fundamentalmente, esta cadena no solo visualiza los procesos en forma

de una secuencia, sino que también interpreta cada paso como una serie
de eslabones que agregan o refuerzan valor permanentemente ya sea
en términos de costo, calidad y velocidad de entrega de un producto o
servicio, desde el momento del diseño de los insumos básicos hasta que
todo el trabajo ha sido completado a satisfacción del cliente.
Los administradores de cada eslabón de esta cadena tienen la responsabilidad

primaria de adoptar decisiones relativas al plan estratégico global de cada
paso, el cómo los recursos van o tienen que ser adquiridos y cómo las
recompensas van a distribuirse por alcanzar los resultados parciales o
totales de la cadena de valor.
La Gerencia de un proyecto informático debe reconocer cuál o cuales

eslabones de esta cadena pueden ser afectados por su implementación y
cuales son las funciones que van a recibir un mayor impacto así como tener
alguna medida de este impacto en la estructura global de la organización
como un todo.
Principios fundamentales de la metodología Lean Development

Los principios fundamentales de la metodología Lean Development son
resumidos e introducidos mediante esta tabla:
Principios de Lean Development

1. Definir o identificar el (los)Valor(es) agregado(s) que aporta el desarrollo de un proyecto
2. Identificar el flujo de valor, es decir la serie de pasos dentro de la cadena de valores a ser
estudiados
3. Diseñar el flujo de procesos empresariales que van a ser el objeto del proyecto (resultante en
una EDT)
4. Tratar de planear los proyectos con base al método “pull’ (Jalar)4
5. Bregar siempre por alcanzar la perfección
4. Lo cual se explica justo enseguida.
34
Push (Empujar) vs. Pull (Jalar)

en la planeación estratégica de proyectos
En la fase de planeación estratégica de proyectos, es conveniente tener
siempre presente la distinción entre proyectos que son jalonados (pull en
inglés) por los directivos de una empresa, de aquellos que son impulsados
(push en inglés) por la iniciativa de los clientes. Al respecto se ha visto que
los dos puntos de vista se caracterizan por los siguientes aspectos:
1. Push es el método tradicional y en este caso, la demanda de proyectos
la impulsan con mayor fuerza y mayoritariamente los clientes
2. Push forza a maximizar la cantidad de proyectos que puedan
desarrollarse.
3. Push aumenta la probabilidad de congestionar la ejecución de los
proyectos
4. Pull se basa en el reconocimiento pleno de la capacidad para gestionar
los proyectos que tenga o perciba tener una empresa
5. Pull se basa en la capacidad de oferta de proyectos por parte de una
empresa
6. Pull facilita una planeación de proyectos más realista que la Push.
Desde el mismo momento de comenzar a determinar la estructura de

descomposición del Trabajo (EDT) de un proyecto informático, los
siguientes elementos son prioritariamente tenidos en cuenta:
1. Organización responsable y dueña del proyecto (sponsor)
2. Descripción del trabajo
3. Códigos de cuentas asociadas al proyecto
4. Cronograma de actividades
5. Lista de Hitos
6. Recursos requeridos
7. Estimativos del costo
8. Requisitos de Calidad
9. Criterios de aceptabilidad
10. Información de Contratos asociados al proyecto.
La filosofía del pensamiento Lean aplicados al desarrollo de proyectos

respeta y observa los siguientes principios generales a manera de un
decálogo:

TABLA 1.4. Principios del pensamiento Lean
1. No agregarás desperdicios al proyecto
2. Honrarás los entregables al cliente
3. No perderás tiempo en reuniones
4. No revisarás diseños en vano
5. Levantarás las etapas tradicionales
6. Codiciarás los métodos visuales
7. No matarás los métodos estándares
8. No provocarás largas esperas
9. No olvidarás la cadena crítica
10. Santificarás proyectos prioritarios
El método de la Cadena Crítica usado en la fase de planeación de proyectos

Lean determina los siguientes pasos generales que en algunos casos
pueden ser repetibles; estos pasos se van a explicar usando un sencillo
ejemplo de un proyecto, cuya EDT básica contiene la secuencia de tareas
y sus duraciones aun sin confirmar la asignación de recursos tal y como se
muestra en esta secuencia de las tareas, enseguida:
1. Diagrama de la 5. Quitar protección

red de la ruta crítica de tareas
2. Determinación 6. Resolver conflictos

de las holguras de recursos
3. Programar lo 7. Identificar
más tarde posible la cadena crítica
4. Asegurar recursos 8. Incorporar los

e identificar críticos buffers (reservas)
Figura 1.12. Paso 1 método Lean
El siguiente diagrama describe el primero de estos pasos, en el que se

han asignado duraciones a las tareas, teniendo en cuenta solamente una
36
disponibilidad preliminar de los recursos y dando lugar a una sola ruta

crítica:
1.
A - 14 días D - 3 días
B - 16 días E - 5 días G - 3 días
C - 9 días F - 14 días
1. Ruta crítica C-F-G

2. 2. Duración total 26 días
3. A-D-G tiene holgura de 6 días
4. C-F-G tiene 2 días de holgura
Enseguida se hace una programación de las tareas tratando de llevar las

tareas para que se inicien lo más tarde posible; en estos casos la ruta crítica
no se afecta puesto que no tienen holguras sus tareas pero se ha llevado
a un escenario que permite identificar potenciales conflictos provenientes
de los recursos que han sido asignados y están disponibles.
3. Programar lo más tarde posible
1. Paso requerido para identificar conflictos de los recursos

2. Duración total 26 días

4. Asegurar recursos e identificar los críticos

Recurso A
A - 14 días D - 3 días Recurso B
Recurso C
1. Existe algún conflicto de recursos? 1. Si y es el C

2. Recursos en conflicto están en la ruta crítica? 2. No.
Una vez se realiza el paso 4; observe los 4 aspectos que surgen de este paso:
5. Quitar la protección de las tareas
1. Tareas con riesgos se planifican con una reserva o colchón de seguridad (buffer)
2. Síndrome del estudiante es posible y hay que evitarlo
3. Hay que acelerar el flujo de tareas del proyecto
4. Se determinan las duraciones mínimas (duración optimista)
1. El proyecto no está del todo protegido!!!

2. Por lo tanto se deben incorporar colchones de seguridad (buffers)
3. Es posible agregar como buffer una tarea al final, que no supere el 50% de la suma de
las protecciones de la ruta crítica
El Síndrome del Estudiante es un efecto quizás visible en algunos

ambientes escolares, que consiste en que el estudiante espera hasta última
hora para prepararse para un examen ya programado a un cierto plazo,
38
menospreciando el margen de tiempo con el que cuenta a partir del día en

el que le fue asignado un deber.
6. Resolver conflictos de recursos
1. Recurso crítico (restricción) C se asigna a tarea D y no a la tarea E mediante algún

mecanismo de prioridades
2. Esta es una solición Lean!!!
Enseguida se procede al paso 7 en el que se identifica la cadena crítica, es

decir aquella en la que se detectan recursos críticos:
7. Identificar la Cadena crítica
1. La Cadena crítica es ahora B-D-E-G y su duración es de 19 días

2. El problema ahora es que el proyecto no está aún protegido.
Luego viene el paso 8 en la que se incorporan los buffers o sean reservas

de tiempo, como se explica en la siguiente gráfica:

8. Incorporar los buffers (reservas)

1. Los buffers deben proteger todo el proyecto!!!
2. Existen 3 tipos de protecciones:
1. Project Buffer
2. Protectores de la cadena crítica o feeding buffers
3. Protectores de los recursos críticos o capacity buffers
Si se agrega como project buffer una tarea al final, que no superes el 50% de la suma de las
protecciones de la ruta crítica, su duración máxima sería de 7.5 días (50% de 15 días)
Al aplicar el concepto visto de la CADENA CRÍTICA para un portafolio de

múltiples proyectos, hay que mantener en paralelo una gran atención en
estos aspectos:
1. Hay que establecer una prioridad a todos los proyectos y esto es
recomendable que sea una parte esencial del ejercicio de planeación
estratégica de una empresa.
2. Planifique cada proyecto por el método de la CADENA CRÍTICA
3. Clasifique los proyectos en el tiempo, teniendo en cuenta la capacidad
de los recursos
4. Mida el estado de los buffers de los proyectos (medidor)
5. Controle los proyectos atendiendo el estado de los buffers mediante
los medidores seleccionados
6. En este tipo de proyectos es muy importante la conformación de
equipos altamente integrados.
Note que en lo explicado hasta aquí de la metodología Lean, las reservas

que se usan para poder ajustar el cronograma en las circunstancias que así
lo aconsejen, se expresan únicamente en términos de tiempo.
El autor va a explicar al final del numeral 1.6 los procesos para incorporar
un concepto que el autor denominará Tarifa como mecanismo de
seguimiento de proyectos y que sirve como criterio para hacer ajustes o
cambios en la fase de seguimiento del proyecto, en vez de usar las reservas
solo medibles en función del tiempo.
La computación en la nube
La computación en nubes no es en sí propiamente una metodología
de desarrollo de proyectos de manejo de información; más bien es una
40
alternativa de almacenamiento y manejo de datos que por sus grandes

beneficios se ha convertido en la tendencia y su popularidad sigue ganando
adeptos día tras día, no solo por ser un término nuevo en el mercadeo de
soluciones de software, sino por sus bajos costos y alta flexibilidad.
La Computación en Nube (Cloud Computing) promete acelerar la

implementación de aplicaciones, aumentar la innovación y minimizar
los costos al mismo tiempo que incrementa la agilidad de un negocio.
También puede transformar la manera en que se diseñan, construyen y se
ofrecen aplicaciones. Existen por parte de algunas empresas paquetes de
software del Cloud Computing que trabajan en un entorno de hospedaje
en nube virtualizado.
Igualmente existen en el mercado aplicaciones orientadas al sector

público, al privado e híbrido, con una variedad de maneras de aprovechar
las aplicaciones de nube y que ayudan a responder a las cuestiones
fundamentales que se hacen las empresas para detectar el mejor método y
el mejor momento para su instalación.
Hoy la computación en nubes incluye muchos tipos de soluciones

empresariales y entre ellas se encuentran los sistemas para los respaldos
(¨backups¨) de la información empresarial. Pero ¿cuáles son exactamente los
beneficios de dichas soluciones? Se pueden citar las siguientes ventajas:
• Accesibilidad permanente
• Confiabilidad
• Escalabilidad ilimitada
• Reducción de costos
• Sencillos entornos de prueba y desarrollo.
Almacenamiento en las nubes

El término “Almacenamiento en las nubes” ha pasado a ser uno de los
términos más usualmente usados en la literatura moderna de desarrollo
de Software y se emplea para explicar todo el proceso a realizar desde
el tipo de almacenamientos, pasando por la catalogación y utilización de
los backups, hasta las mejores prácticas para su administración usando la
herramienta de desarrollo de proyectos de Microsoft Project. Este autor
recomienda el siguiente documento que ayuda a comprender estos temas:

Dynamic Scheduling® with Microsoft® Project 2010

The Book By and For Professionals
Los autores son Rodolfo Ambriz, PMP, MCTS, MCITP and John White.
Conclusiones y recomendaciones generales

• No existe una metodología universal para hacer frente con éxito a
cualquier proyecto de software. Toda metodología debe ser adaptada
al contexto del proyecto (recursos técnicos y humanos, tiempo de
desarrollo, tipo de sistema, etc.).
• Históricamente, las metodologías tradicionales han intentado abordar
la mayor cantidad de situaciones del proyecto, exigiendo un esfuerzo
considerable para ser adaptadas, sobre todo en proyectos pequeños
y con requisitos cambiantes. Las metodologías ágiles ofrecen una
solución casi a la medida para buen número de proyectos con estas
características.
• Cualidad destacable de la metodología ágil es su sencillez, tanto en
su aprendizaje como en su aplicación, reduciéndose así los costos de
implantación en un equipo de desarrollo. Esto ha llevado hacia un
interés creciente en estas metodologías.
• El autor cree firmemente que los criterios más solicitados en el éxito de
un proyecto informático deberían expresarse en términos del costo y el
esfuerzo a ser realizado y la funcionalidad exigida y no condicionarlo
estrictamente al cumplimiento de fechas.
Hay que tener presente una serie de inconvenientes y restricciones para

una debida aplicación de estas metodologías, tales como: están dirigidas
a equipos pequeños o medianos, el entorno físico debe ser un ambiente
que permita la comunicación y colaboración entre todos los miembros del
equipo durante todo el tiempo de desarrollo.
Cualquier resistencia del cliente o del equipo de desarrollo hacia las

prácticas y principios aquí mencionados puede llevar el proceso al
fracaso (el clima de trabajo, la colaboración y la relación contractual
son claves) y el uso de tecnologías que no tengan un ciclo rápido de
realimentación o que no soporten fácilmente el cambio inevitable en
estos ambientes.
42
En un numeral anterior se explicó una de las técnicas de desarrollo más

empleadas para proyectos de Informática llamada Lean Development,
utilizada por los gerentes de proyectos informáticos en los aspectos de
diseño, pruebas, implementación y entrega del producto final.
Independiente de la mecánica de desarrollo de un proyecto, tome medidas

a tiempo a fin de evitar tener que afrontar estas lamentables situaciones
durante el desarrollo de un proyecto informático...
Figura 1.20. En caso de situaciones harto difíciles
1.5 Análisis DOFA

La técnica DOFA es una herramienta basada a su vez en otra técnica
denominada Tormenta de Ideas en la que se trata de identificar las
debilidades (D), las oportunidades (O), las fortalezas (F) y las amenazas
(A) relacionadas con el logro de un determinado objetivo. Los resultados
de esta técnica son revisadas en forma coordinada por los integrantes del
equipo de trabajo y luego se convierten en acciones a seguir.
No es una técnica que por si misma constituya el único medio de

análisis para llegar a una decisión, sino que debe ser complementada
con otras.

La forma de dirigir las acciones de una sesión usando el análisis DOFA es

bastante similar al de las sesiones de Tormenta de Ideas en el sentido que
los participantes identifican los factores que afectan o benefician el logro del
objetivo bajo estudio y los escriben en una cuadricula semejante a esta:
Beneficio Daño
Internos Fortaleza Debilidad
Externos Oportunidad Amenaza
Análisis DOFA
Figura 1.21. Factores básicos de la técnica DOFA
Los objetivos de una práctica DOFA pueden ser muy diversos y en el caso
de proyectos pueden ser tan distintos como seleccionar los proyectos a
ser ejecutados dentro de un portafolio de proyectos planteados, o analizar
el beneficio de un proyecto en los diferentes procesos generales de una
empresa o sea en su cadena de valores (concepto que se explica más
adelante) o estudiar el impacto de los riesgos que todo proyecto conlleva.
En el caso de este ultimo, las sesiones DOFA se caracterizan porque

los participantes continuamente revisan entre sí los impactos y las
probabilidades y después de un análisis cuidadoso, se someten a mayores
discusiones y luego de ser claramente identificados los diferentes riesgos,
se analizan y estudian tratando de hallar respuestas a cómo las fortalezas y
las oportunidades se pueden explotar y cómo las debilidades y amenazas
se evitan o se mitigan.
Al momento de aplicar medidas que mitiguen o contrarresten los efectos

negativos de un riesgo, es posible detectar otros conceptos a tener en cuenta:
1. Riesgo residual: cantidad de riesgo remanente después de aplicada
una respuesta al riesgo.
2. Riesgo secundario: peligro resultante de la implantación de una
respuesta al riesgo.
3. Re aplicar: contingencia que se pone en acción cuando una respuesta
al riesgo o un plan de acción ya no funciona.
Todos estos análisis vistos anteriormente se pueden perfectamente aplicar

mediante una lista de chequeo parecida a la siguiente que facilita evaluar
44
cuantitativamente los riesgos conocidos y no conocidos como se muestra

a manera de un ejemplo:
TABLA 1.5. Manejo de riesgos conocidos y desconocidos
CREADO PARA
NOMBRE DESCRIPCIÓN EJEMPLO
RIESGOS
Riesgos que se sabe Algo que no se vislumbra
Reservas por Conocidos
pueden ocurrir en un que afecte un proyecto tal
contingencias desconocidos
proyecto como un desastre natural.
Riesgos que no
Algo que cuesta más de lo
pueden ser
Reservas Conocidos planeado o cuya duración
pronosticados y que
administrativas desconocidos es mayor de la planeada o
potencialmente
afecta los alcances.
afectan un proyecto
1.6 Tarifa global y su empleo en proyectos

La idea en este numeral es introducir y explicar un concepto que envuelve
las variables costo y esfuerzo de las tareas en una sencilla formula, que
el autor denomina Tarifa la cual como se va a comprobar, puede ser
utilizada tanto en la planeación como en el seguimiento de cualquier
clase de proyectos; la formula dispone de estos dos conceptos: Costo Total
y Trabajo Total, fácilmente aplicables tanto a una tarea en particular como
a todo un proyecto.
Sin importar la metodología que se emplee, es muy universalmente

aceptado que en la fase de control y seguimiento de un proyecto, para
medir el avance de las tareas individuales o de grupo, se compara, Lo
Planeado vs. Lo Ejecutado en términos del trabajo, costo, calidad y el
cumplimiento de un cronograma.
La idea de crear y usar una tarifa como mecanismo de seguimiento de

un proyecto es poder expresar el avance del mismo por medio de una
sola variable que involucre tanto el costo como el trabajo, ambos en
términos de lo que se planeo vs. lo que realmente se ha ejecutado. Esta
sola variable puede perfectamente ser llevada a un tablero de control
de los proyectos de una empresa como es precisamente la intención del
autor de este libro.

Antecedentes de este enfoque

Existen un antecedente operativo que motiva el concepto de una tarifa,
y es un viejo sistema para valorar y costear proyectos de obras civiles
denominado ¨Precios Unitarios¨ el cual se fundamenta en:
1. Casi todas las tareas entregan un producto que es fácilmente medible
por una determinada unidad de obra (m, m2, m3, Ton, U,...).
2. Se calcula un precio unitario por unidad de obra que toma en cuenta
la productividad y el rendimiento derivado de los recursos empleados,
el salario o compensación de la mano de obra, y el uso de materiales
y de equipos. Asume generalmente un día como el marco de tiempo
laborado.
3. Calcula la duración de una tarea en función de la cantidad total de
obra a ejecutar y la cantidad de recursos disponibles.
4. Y el costo de la tarea es igual a cantidad de unidades de obra * precio
unitario.
Por otra parte, la técnica del Valor Acumulado o Ganado focaliza el

progreso del proyecto en un determinado momento, evalúa su estado y
luego hace un estimativo de sus posibles resultados con miras a realizar
ajustes en la medida que el proyecto avance. Se compara el progreso con
respecto al plan base a intervalos regulares por lo que facilita proponer
soluciones a problemas con el manejo del cronograma y/o la ejecución
del presupuesto.
Esta técnica se va a explicar más detalladamente en el siguiente capítulo, pero

por ahora se van a explicar 3 conceptos claves: Valor Planeado, Valor real y
Valor ganado que son necesarios para entender su formulación y su empleo.
EVA es el término en inglés correspondiente a las siglas de Earned Value

Analsys y es una técnica de medida del desempeño de un proyecto que
integra las variables fundamentales de un proyecto: Trabajo, Tiempo y Costo.
A partir de un plan, y el reporte periódico del trabajo y costos reales a

una fecha de corte, se puede determinar que tan bien el proyecto esta
cumpliendo los objetivos a una fecha específica de control o evaluación.
Se puede emplear para un nivel o grupo de tareas o a nivel de todo el
proyecto. La siguiente tabla resume las principales características de estos
indicadores:
46
TABLA 1.6. Principales factores de seguimiento de un proyecto
INDICADOR DEFINICIÓN
También llamado el Presupuesto, es el costo
acumulado del trabajo que ha sido planeado
Valor Planeado (PV = Planned Value)
para una tarea durante un período de tiempo
determinado
Costo real del trabajo realmente ejecutado a

Costo Real (AC = Actual Cost) una determinada fecha en una tarea; incluye
todos los costos asociados a la tarea
Valor planeado del trabajo realmente termina-

Valor Acumulado (EV = Earned value)
do en una tarea a una fecha de control
Índice de Desempeño del Costo (CPI = Cost CPI = EV/AC - Cuánto se ha obtenido realmen-
Performace Index) te por cada $ gastado en una tarea.
Índice de Desempeño del Programa (SPI = SPI = EV/PV - Cuánto se ha logrado en térmi-
Schedule Performance Index) nos del cronograma.
La interpretación de los valores de los indicadores CPI e SPI son las

siguientes:
IRC mayor de 1 → El presupuesto está por abajo de lo planeado
IRC menor de 1 → El presupuesto está por encima de lo planeado
IRP mayor de 1 → El trabajo va adelantado
IRP menor de 1 → El trabajo esta atrasado.
Observe como el CPI influye en todas estas formulaciones y como juega

un papel determinante en la fase del seguimiento y control de un proyecto.
Por otra parte, como el Trabajo es la medida del esfuerzo aportado por los
recursos necesarios para el desarrollo de una tarea, esto conlleva a que
los recursos estén sujetos a alguna medida de productividad generalmente
expresada en función del tiempo. Es también muy frecuente en las empresas
medir la cantidad de trabajo en función de la eficiencia de los recursos
que se usen.
Para proyectos de tipo informático y en general para los proyectos en los

que la productividad del recurso humano es un factor fundamental, es
usual medir el trabajo en términos de horas-hombre, aunque es también
muy frecuente hallar que algunas empresas lo midan dependiendo del
tipo de tarea a ejecutar, por ejemplo 2 módulos de código por día para un
equipo de 2 programadores de Java con 3 años de experiencia. Estos últimos

ejemplos implican el uso de algún mecanismo que mide la productividad

de los recursos empleados.
El costo proviene por el pago de recursos de trabajo y opcionalmente por

el empleo de materiales o el pago de algún dinero para poder ejecutar una
tarea; es de anotar que mientras los dos últimos costos son opcionales,
el primero es obligatorio. Los recursos humanos y/o de equipos tienen
generalmente tasas de costo en función del tiempo.
Conceptualmente todos los costos se pueden sumar en un solo valor dando

lugar a un costo total por tarea, lo que podría llevar a una tarifa global
expresada en estos términos:
Tarifa = Costo total / Trabajo total
Que resulta sencillamente de dividir el costo total por el volumen del

trabajo. Teniendo en cuenta la definición de los valores planeados,
reales y ganados mencionados en el análisis EVA, se puede deducir que
a una determinada fecha de control se podrían calcular las dos siguientes
tarifas:
1. En términos del plan:
Tarifa planeada = Costo planeado / Trabajo planeado
2. Y en términos de la ejecución:
Tarifa real = Costo real / Trabajo real
Si observamos las clásicas definiciones de los conceptos PV, AC y EV, se

ve clara la posibilidad de que estos se puedan reformular usando el nuevo
concepto de tarifa, dando lugar a estas fórmulas:
Valor Planeado (PV Planned Value) = Trabajo Planeado x Tarifa Planeada
Valor Real (AC Actual Cost) = Trabajo Real x Tarifa Real
El siguiente paso es reformular la expresión matemática de los indicadores

CPI y SPI, con base a las anteriores formulas en las que los 3 conceptos
PV, AC y EV se han puesto en términos de las tarifas, y luego cancelando
los términos comunes hallados tanto en el numerador como en el
denominador, quedando así las 2 formulas:
CPI = EV/ AC = Trabajo Real x Tarifa Planeada / Trabajo Real x Tarifa Real =
CPI = Tarifa planeada / Tarifa real
48
SPI = EV / PV = Trabajo Real x Tarifa Planeada / Trabajo Planeado x Tarifa Planeada =

SPI = Trabajo real / Trabajo planeado
Observe que en el CPI es determinante que la tarifa real sea menor que la
planeada para que este sea mayor de 1, y que para que el SPI sea mayor
de 1 es necesario que el trabajo planeado sea menor del trabajo real como
lo confirman estas formulas:
CPI = Tarifa planeada* / Tarifa real
SPI = Trabajo real / Trabajo planeado*
NOTA: en estas formulas el factor indicado con un asterisco (*) se señala

porque es el que determina si el indicador de seguimiento pueda ser mayor
o menor de uno (1).
Lo anterior conduce a concluir que mientras menos se pague realmente

en una tarea con respecto al valor planeado y más trabajo se obtenga
con respecto al planeado, el proyecto va marchando perfectamente.
Como creo que este enfoque puede ser muy perjudicial en el desarrollo de
proyectos informáticos, el autor va a hacer una recomendación al respecto
más adelante, tendiente a incentivar el buen desempeño de los recursos
humanos, factor que es crucial en este tipo de proyectos.
De lo anterior se puede concluir igualmente que...

1. El CPI esta relacionando la tarifa real con respecto a la planeada.
2. El SPI relaciona el avance real del trabajo con respecto al trabajo
planeado.
Resumiendo los conceptos que habría que formular con base en este
concepto de tarifa serian:
Tarifa planeada = Costo planeado / Trabajo planeado
Valor ganado = Trabajo real * Tarifa planeada
CPI = Tarifa planeada / Tarifa real
SPI = Trabajo real / Trabajo planeado

Enseguida se va a mostrar un par de ejemplos hechos con la herramienta

Excel que demuestran el uso del concepto Tarifa:
Ejemplo 1: Una tarea de duración planeada de 4 semanas, presupuesto

total de $40.000 y trabajo programado de 400 mts., se le efectúa un control
en su 3ª. semana y se halla que el trabajo realmente ejecutado es 100 mts.,
el costo real AC= $20.000 y como el PV = $30.000 (3 semanas a $10.000
/ semana), entonces siguiendo el método clásico:
EV = 100 x (40.000/400) = $10.000 → CPI = 10.000/20.000 = 0.50 o 50%
SPI = 10.000/30.000 = 0.33 o 33.3%
A continuación se muestran los resultados siguiendo el método aquí

explicado:
VARIABLE VALOR
Costo real al corte 20,000.00
Trabajo Total planeado 400.00
Tarifa planeada 100.00
Tarifa real 200.00
Trabajo Real al corte 100.00
Trabajo Plan. al corte 300.00
Ejemplo 2: Proyecto A tiene que terminar hoy y se le presupuesto $1,000.

Esta hoy en un 85% de avance y se gasto realmente $900.
Con el método tradicional:

Valor Acumulado (EV) = 850,
Índice de desempeño de costos (CPI): EV / AC = 850/900 = $0,94.
Aquí, se puede calcular:

Varianza de Costo: CV = EV – AC = 850 – 900 = -50
Índice de desempeño del Cronograma SPI: EV / PV = 850 / 1000 = 0.85.
NOTA: Se observa que en este tipo de casos expuestos con este ejemplo,
no es necesario saber el volumen de trabajo a ejecutar puesto que con los
50
restantes datos es posible conocer el valor de los indicadores; para facilitar

la comprensión del ejemplo se ha supuesto que el trabajo a realizar es de
1,000 U. pero de hecho se puede usar cualquier valor.
Resultados con el nuevo enfoque propuesto:
VARIABLE VALOR
Costo real al corte (AC) 900
Trabajo planeado al corte 1,000
Tarifa planeada 1.00
Tarifa real 1.06
Trabajo real al corte 850
VARIABLE VALOR
PV 1,000
EV 850
CPI 0.94
SPI 0.85
Registro cronológico de tarifas

Para una empresa que esté ejecutando un proyecto e inclusive para
aquellas que ya han desarrollado un cierto número de proyectos y cuentan
con datos históricos confiables, es recomendable el ejercicio de estimar
en cada punto de control qué tipo de tarifa tenía o estaba el proyecto, y la
clasifica de acuerdo a una de las siguientes cuatro clases, a saber:
Trabajo
Óptimo!! Costo real < Planeado y Aceptable! Costo real > Planeado y
Trabajo real > trabajo planeado Trabajo real > trabajo planeado
Planeado Costo $
Pobre! Costo real < Planeado y Pésimo! Costo real > Planeado y
Trabajo real < trabajo planeado Trabajo real < trabajo planeado
Cuatro escenarios posibles en el seguimiento de un proyecto
Figura 1.22. Casos posibles de los valores de la tarifa

Note que para cada fecha de control, se puede saber el tipo de tarifa de
acuerdo a las condiciones claramente establecidas para cada cuadrante
y deducir el tipo de tarifa y clasificarla de inmediato como Optima,
Aceptable, Pobre o Pésima. Si la tarifa corresponde a uno de los 2
cuadrantes superiores se puede concluir que el proyecto va marchando
bien, aunque en el caso de encontrarse en el cuadro llamado Aceptable
habría que revisar si el alcance del proyecto fue redefinido o no.
Si el escenario en que se ubica un proyecto en una fecha de control

corresponde a uno de los que están en la parte inferior (escenarios marcados
como Pobre y Pésimo) la situación es preocupante y dependiendo del
momento en que esto ocurra habría que determinar primero cuál es el
tiempo con que se cuenta para terminar el proyecto y cuánto es el trabajo
o esfuerzo pendiente de realizar.
Hay que aceptar de todas formas que esta clasificación de los resultados
de un proyecto se hizo sobre la base de un juzgamiento que no tuvo en
cuenta la calidad del producto y por otra parte, hay que reconocer que
pueden haber estilos y criterios de pensamiento muy diversos sobre la
forma de clasificar un proyecto en su fase de ejecución.
Se pretende explicar en este momento cómo se podría usar la tarifa como

elemento de control y evaluación de un proyecto. Para ello el autor se vale
de la siguiente gráfica:
SEGUIMIENTO DE UN PROYECTO USANDO LA TARIFA
Categoría de Tarifa
Aceptable!
Óptimo!
Pésimo!
Pobre!
T1 T2 T3 T4 Tiempo
Figura 1.23. Seguimiento de proyectos usando Tarifa
52
Los momentos de control del proyecto se colocan en la parte inferior y

corresponden a los tiempos cuando al proyecto se le hicieron rutinas de
control; estos puntos de control también se pueden indicar usando las
fechas en las que se realizaron. Con base en la fórmula de cálculo de la
tarifa, estas se han calculado para cada punto de control y luego clasificado
en una de las 4 categorías indicadas, señalando de esta forma el respectivo
grado de avance del proyecto.
El usar esta tarifa y no simplemente el margen de holgura en el tiempo

como mecanismo de control de un proyecto, tiene indudables ventajas.
Resumiendo lo visto hasta el momento, las siguientes conclusiones y

recomendaciones son posibles de extraer del examen anterior, en el que
se recalca las categorías de tarifa y su uso como mecanismo de control en
el seguimiento de un proyecto:
1. La tarifa ayuda a entender en forma quizás más simplificada el
mecanismo de seguimiento de un proyecto y aporta una visión
conjunta de su entorno, validando tanto el proceso de control del
presupuesto como el del cumplimiento del trabajo.
2. Cuando se estudia la probabilidad de terminar una tarea o todo un
proyecto en un marco de tiempo determinado, se asume que la duración
de las tareas5 fluctúa en un rango de tres estimativos: el pesimista (la
mayor duración posible), el optimista (la menor duración) y la duración
más probable o esperada. Con relación a la tarifa, es viable proponer
rangos de valores de la tarifa que fluctúen desde un mínimo hasta un
máximo, asumiendo que el valor mínimo corresponde a la duración
optimista, el máximo a la duración pesimista y el más probable a la
duración esperada.
3. Es conveniente analizar periódicamente el comportamiento de estas
tarifas ya clasificadas en una de las 4 categorías vistas. Si durante la
ejecución de un proyecto, sus valores no muestran un comportamiento
satisfactorio, deben considerarse procedimientos que hagan más
eficiente y racional el uso de los recursos que aportan trabajo en las
tareas en desarrollo o por comenzar
5. La distribución de probabilidades Beta es la más común pero se reconoce que existen tareas con
comportamiento de sus duraciones siguiendo distribuciones como la Triangular uniforme o la de
Poisson.

4. Revisar con frecuencia las tarifas y los indicadores es fundamental, pues

aleja la tendencia a suponer constantes la productividad y eficiencia
de los recursos a lo largo del desarrollo de un proyecto, una vez se
ha establecido la respectiva línea de base. Existen métodos como el
mejoramiento continuo y las curvas de aprendizaje que propugnan
por un mejoramiento de la eficiencia y la racionalidad en el uso de
estos, lo cual debe ser tenido muy en cuenta cuando se evalúa el
desarrollo de un proyecto6.
5. Es recomendable conservar y clasificar las tarifas globales de
proyectos por tipo de proyectos y así disponer de registros históricos
usables en la planeación de proyectos. Esto podría ser una labor de la
oficina de administración de proyectos (Project Management Office)
muy útil en organizaciones que preparan y desarrollan múltiples
proyectos.
6. Igualmente se recomienda que en la fase de seguimiento, todos estos
métodos de control a un proyecto se estudien detenidamente y sean
comprendidos en forma dinámica a lo largo del ciclo de vida del
proyecto.
En el numeral 1.8 Software de manejo de Proyectos y específicamente en

el ítem donde se explica cómo usar la herramienta de proyectos Project
de Microsoft™, se explican los procedimientos para crear la formula de la
variable Tarifa, tal como fue conceptualizada y explicada en este libro.
1.7 Métodos de costeo y la factibilidad financiera

Esta sección se empezara explicando una metodología de costeo llamada
ABC (siglas en Inglés Activity-Based Costing) que el autor considera más
apropiada para el costeo de proyectos de informática, pero antes de entrar
a explicar estas materias se considera importante aclarar algunos términos.
Se va a comenzar con el término de costos directos que en un proyecto de
desarrollo de software, son los costos que están directamente relacionados
al aplicativo resultante y que pueden ser reconocidos en este mediante un
fácil mecanismo de seguimiento, efectivo en términos de costo.
6. Recuerde que en proyectos informáticos la productividad del recurso humano es un factor

CRUCIAL
54
Esto incluye el costo de salarios y prestaciones de los actores directos como

son los analistas, programadores, líderes del proyecto y usuarios así como
el tiempo de uso de Software aplicativo, estaciones, servidores, impresoras
y conexiones a redes. Generalmente estos son fáciles de evaluar sobre la
base de una asignación de cuentas por cada componente.
Por otra parte, los indirectos son los costos que están relacionados con el
producto final pero que no pueden ser identificados en este mediante una
simple formula económica. Para poder asignarlos a este, apelamos a un
mecanismo de asignación en particular, que en el caso de un proyecto de
SW se relacionan con los de adquisición de licencias de operación del
SW operacional y de redes y conexiones, el mantenimiento y operación
de redes y de equipos de cómputo y el entrenamiento del personal
indirectamente involucrado en estos proyectos.
En el caso de proyectos se usa el sistema de Costos basado en Lotes

considerando el lote el producto final o sea el aplicativo resultante. Este
producto generalmente se ajusta de acuerdo a los requerimientos del
cliente y por lo mismo su costo puede variar en forma muy significativa de
un proyecto a otro.
El método de costeo ABC consiste fundamentalmente en asignar costos a los

insumos necesarios para ejecutar las múltiples actividades de un proceso
productivo, identificadas como las relevantes para obtener un determinado
producto o servicio, calculando el costo de estos mediante mecanismos de
absorción del costo de las actividades. Las actividades pueden y deben ser
tanto las directamente requeridas en un proceso productivo como aquellas
indirectamente apoyando todo el proceso productivo. Lo fundamental es
que todas estas actividades estén de la cadena de valores agreagados.
Cada actividad genera un subproducto o entregable que representa un trabajo

que a su vez consume recursos de una empresa y es generalmente una
parte integrante de un proceso compuesto de varias tareas; las actividades o
tareas se expresan mediante verbos o expresiones que signifiquen acción.
Al describir una actividad, es necesario entender el concepto relación

causa-efecto; este explica la relación que existe entre un generador de
costo (la causa) y una actividad (el efecto) o sea que tipo de relación existe

entre el efecto de ejecutar una tarea y el factor causa que mejor mide su
costo, por ejemplo: la labor de brindar seguridad (el efecto) a una red de
computadoras varia en proporción al tamaño de la misma (la causa).
El generador de costo permite medir que tanto del costo de una tarea
puede ser absorbido por el producto o subproducto resultante de cada
tarea y se expresan mediante un factor base de la asignación.
En un proyecto de desarrollo de software son actividades típicamente

directas y relevantes: planear, diseñar, codificar, programar, probar, integrar
y documentar. La forma de asignar costos a las actividades se explica
gráficamente así:
Costo de recursos
Asignación de la base
Actividades
Bases unitarias y no unitarias
Objeto de costo
Actividades→Costo de tareas→Objetos de Costo: Productos, servicios, Clientes...

Figura 1.24. Asignando costos a las actividades y a Objetos de Costo
El siguiente diagrama resume en términos generales el proceso de aplicar

la metodología ABC:
Costos indirectos por cada tarea: Tarea 1 Tarea 2 Tarea 3
Tiempo Producto Operación

Factor base para asignar costos: $/ $/ $/
Costos indirectos
Objeto de costo:
Costos directos
Mano de obra Materiales

Otros costos
Costos directos: directa por cada e insumos
directos
objeto de costo directos
Figura 1.25. Costos directos e indirectos a Objetos de Costo
56
En todas las tareas que se han programado es fundamental contar con la

provisión y entrega de elementos y formulas que apoyen o mejoren el
rendimiento de los recursos a cargo de las tareas principales de análisis
y programación, y sin su concurso estos recursos no podrían realizar su
cuota de esfuerzo.
Son atributos importantes de las tareas el factor base del costo usado para
distribuir costos entre las tareas que se requieren para un determinado
producto, así como el nivel del costo, la tarifa base de asignación, el
valor del esfuerzo de calidad, el costo estándar y el valor Benchmarking.
Estos últimos son fundamentales cuando se desea mejorar y/o optimizar
procesos productivos, comparándolos con la competencia o con
estándares de la industria.
Los factores base del costo se expresan generalmente en unidades de salidas

de cada proceso (por ejemplo, $3.65 / minuto al aire, 54 hrs. máquina, etc.)
ó en la forma de variables que son a su vez, función de otra unidad de salida.
Sin embargo, no todos los costos son activados por una unidad de salida y ello
conduce a clasificar los costos en niveles, que reflejen una clasificación de los
costos en grupos sobre la base de las diferentes clases de generadores de costo
ó diferentes grados de dificultad en determinar la relación causa-efecto.
Al analizar las formas de asociar cualquier costo a un determinado

producto, se pueden detectar cuatro niveles posibles de asociación:
• Costos a nivel de cada unidad producida.
• Costos a nivel de un lote o grupo limitado de productos o servicios.
• Costos de apoyo específico a una línea o grupo de productos y/o
servicios,
• Costos de apoyo general a nivel de toda la empresa o de una planta de
producción.
La mayoría de las empresas de desarrollo de software tienen diversas

actividades de producción que es conveniente clasificar en estas cuatro
categorías. Una vez se han determinado los alcances del producto final de
un proyecto de desarrollo, la metodología ABC sigue estos pasos:
1. Se estudian los procesos productivos, preferiblemente en el orden

en que se ejecutan y se identifican las actividades necesarias para

desarrollar cada proceso. Al tener identificadas las tareas, se estudian

los costos y los volúmenes de recursos que consumen cada una de
ellas, usando la información registrada o la que se considere más
apropiada.
2. Se analizan los posibles factores generadores de costo de cada
actividad, con base en una relación causa-efecto y se asigna una base
mediante una fórmula de costos, cuyo valor es la base de asignación
unitaria y no necesariamente es financiero. En este momento se obtiene
el costo y una base de asignación de cada actividad que se aplicará al
producto final.
3. Se analizan los mecanismos de absorción del costo de cada actividad
para el especificado producto y se determina la fórmula de absorción
más apropiada. En este momento se tienen los costos unitarios del
producto y volúmenes de recursos requeridos al ejecutar sus tareas.
4. Se calculan los costos del producto final, sumando los costos directos
y los indirectos. Se emplea el costo así calculado como la base unitaria
para asignar costos a otros proyectos de desarrollo que cubran las
varias fases de la cadena de valores agregados de producción.
Factibilidad financiera de un proyecto

En esta parte se asume que se esta en capacidad de estimar los costos
de un proyecto, por lo tanto solo hace falta es conocer los potenciales
beneficios económicos del mismo. Un estudio de factibilidad económica
de cualquier proyecto requiere que se hayan estimado tanto los egresos o
costos como los posibles ingresos del mismo.
Estos estimativos se logran generalmente después de un estudio de

mercados o de un estudio de los beneficios económicos esperados cuando
el producto final se entrega y que en algunos casos pueden ser simplemente
el ahorro de una serie de gastos.
Los factores que miden el resultado financiero de un proyecto determinan

la potencialidad de generar un producto con atributos medibles y reales,
los que se comparan con un determinado patrón. Los siguientes son los
mecanismos financieros más utilizados en estos casos.
58
Valor Presente Neto

Es el factor más usualmente empleado para medir la factibilidad financiera
de un proyecto (siglas VPN) el cual se explica con este ejemplo: Se tiene
que invertir hoy $1.000 y se tiene una tasa de oportunidad del 30%;
se espera obtener $1.500 al final de un año, entonces el VPN de esta
inversión, se obtiene así:
VPN = 1,500/(1 + 0.3) – 1,000 = 1,153.85 – 1,000 = $153.85
Y como es positivo entonces es una inversión atractiva. Si se aumenta la

tasa de oportunidad, entonces se obtiene un VPN más pequeño lo que se
explica porque al aumentar esta tasa, el evaluador del proyecto tiene una
esperanza de retribución más alta para justificar un proyecto o no. En el
cálculo del VPN se deben obtener los valores del flujo neto esperado (de
ingresos – egresos) a lo largo de la vida del Producto y esto debe tenerse
muy presente pues generalmente durante la vida útil del proyecto se tienen
más egresos (costos) que ingresos.
Se pueden presentar en la práctica, las siguientes situaciones:

• Si el VPN es positivo. Se está agregando valor y el proyecto debería
aceptarse.
• Si el VPN es negativo. Aquí se está destruyendo valor y el proyecto
debería rechazarse.
• Cuando se tienen varios proyectos con VPN positivo, entonces debería
escogerse aquel con el mayor VPN ya que este es el que agrega más
valor.
• La mejor forma para que los proyectos produzcan valor a una empresa,
es escoger aquellos con VPN positivos.
Período de restitución (Payback)

Mide la bondad de un proyecto de inversión en términos del tiempo que
se demora en recuperar la inversión. Equivale al número de períodos
requeridos para que los flujos de caja neto recuperen la inversión a una
tasa del 0% de interés.
Financieramente es muy importante, especialmente para empresas o

proyectos pequeños que no pueden esperar muchos años para recuperar el

capital invertido por el riesgo que perciben antes de recibir los beneficios
del proyecto.
Pero es también considerado un índice pobre porque asigna el mismo

valor presente a sumas en momentos diferentes, ignorando el Valor del
Dinero En El Tiempo que es una de las bases fundamentales del Análisis
Financiero.
Relación Beneficio/Costo
Tiene bastante uso en proyectos de naturaleza social, en proyectos
gubernamentales y de construcción de obras civiles. Se usa también en
proyectos relacionados con inversiones financiadas por organismos
internacionales, en los que se exige hacer explícitos los beneficios y los
costos y requiere del cálculo previo de los flujos netos al igual que el VPN.
Es un criterio a dimensional porque proviene de hacer una relación entre

dos indicadores que se expresan en las mismas unidades. Su concepción
básica es la PRODUCTIVIDAD es decir toda la serie de utilidades o
ganancias derivadas de un uso productivo de los recursos. Se define como
la relación entre el valor (presente, anual o futuro) de los beneficios y el
valor de los costos del mismo proyecto y se expresa mediante las siglas
RBC, matemáticamente así:
RBC = ∑j = 0(VP Ingresos) / ∑j = 0(VP Egresos)
Un proyecto es factible si y solo si la RBC es mayor de 1. Facilita decidir

sobre la bondad del proyecto, pero NO sobre lo óptimo de varias
alternativas. El RBC mide el número de veces que los ingresos superan
a los egresos en términos del Valor Presente y si el número calculado es
menor de 1, no es rentable el proyecto. No es un criterio absolutamente
correcto de decisión económica.
Casos de evaluación financiera

Se pueden presentar en la práctica dos casos cuando se evalúan los flujos
de caja de un proyecto informático, a saber:
1. El nuevo desarrollo es nuevo y no va ni a complementar ni agregar
funcionalidad a otro ya existente.
60
2. El desarrollo nuevo va a producir un producto que va a reemplazar

una aplicación ya existente.
En el primer caso el flujo de caja debe reflejar los costos del nuevo producto
y sus ingresos esperados. En el segundo caso, la evaluación esta dada en
términos de comparar los flujos de dos alternativas: dejar el actual sistema
o reemplazarlo. Esto se conoce en análisis financiero como el análisis de
dos alternativas mutuamente excluyentes (A - B).
1.8 Software de manejo de proyectos

En este numeral se va a explicar en primer término el manejo general de
la herramienta Microsoft Project y luego se expondrán los pasos de esta
herramienta en cuatro aspectos útiles durante la planeación y seguimiento
de un proyecto, a saber:
1. Establecer la fórmula de la variable tarifa y su utilidad en el seguimiento
de proyectos.
2. Descargar los datos de seguimiento desde Project a Excel necesarios
para calcular y clasificar la tarifa y así poder graficar los datos de
seguimiento descritos en el numeral 1.6.
3. Uso del método de la planeación flexible.
4. Empleo de plantillas enderezadas a crear proyectos informáticos.
El primer proceso de los cuatro listados antes se explicará al final de este

numeral, el punto 2 se explica en el capítulo 4, numeral 4.1 que maneja el
tema seguimiento de un proyecto y los restantes 3 y 4 en el capítulo 3 que
trata sobre la planeación de un proyecto.
Introducción a Microsoft Project

Este producto orientado al manejo de proyectos, se puede ejecutar en una
computadora con Windows 2000 o superior, operando en modo estándar,
además de requerir un mínimo de 24 Mbytes. (40 Mb. si maneja versiones
de Windows posteriores a Windows NT o XT) de memoria principal RAM.
El espacio en disco depende de la cantidad y tamaño de los proyectos
aunque es recomendable un mínimo de 30 Mbytes. Una unidad de CD-
ROM y una resolución VGA o superior es conveniente en la pantalla y un
mouse es casi que obligatorio.

A continuación se presenta la manera de comenzar una sesión con Project.

Una vez se domine este procedimiento, es importante también conocer la
manera en que se puede terminar una sesión de trabajo, la misma que a
continuación se describe.
Ejercicio 1.1:
1. Entrar a Windows.
2. Ejecutar el programa Project (Inicio → Programas). Al aparecer la
ventana de programas, hacer un doble clic en el icono de Project.
3. Salir de Microsoft Project, empleando el teclado, o sea usando la
combinación de teclas Alt+F4
4. Entrar nuevamente a Project pero esta vez a través del programa
Explorador de Windows: Inicio → Explorador de Windows y luego
ubique el directorio en donde reside o fue instalado MS-Project
(normalmente está bajo el directorio Microsoft Office y subdirectorio
WinProj) y luego dé clic al ejecutable WinProj.EXE
5. Salir de Project, empleando el Mouse, haga un clic sobre el menú
Archivo para ejecutar la opción Salir.
6. Volver a entrar al programa Project por el mecanismo que usted prefiera.
La siguiente gráfica muestra los principales elementos visuales de la

ventana de Project 2010:
Figura 1.26. Ventana del menú principal de MS-Project.
Elementos visuales de MS-Project

La siguiente es una lista resumida de los elementos más característicos de
Project:
1. La barra del menú principal en la que resaltan los objetos básicos de
todo proyecto: tareas, recursos y proyecto
2. La barra de herramientas en la parte superior izquierda (Tools bar, en
inglés).
62
3. Las ayudas para tareas, recursos, y proyecto que se activan con la

tecla F1.
4. Las diferentes opciones de Vistas que cambian dependiendo del objeto
que se indique en el paso 1 (View).
5. La opciones de Formato que también dependen del objeto que se
marque (Format)
6. Las vistas de información (por defecto muestra el diagrama de GANTT)
a la izquierda.
Project es una herramienta para la planeación y el control de proyectos

dotado de los elementos que facilitan crear y programar las tareas,
administrar recursos, revisar costos y generar reportes para análisis y
presentación, con todas las ventajas que caracterizan un agradable
ambiente gráfico.
Además de las características de las versiones anteriores que permiten un

buen control de proyectos, las mejoras a partir de la versión 2003, facilitan aún
más la administración, creación y transmisión de información de proyectos.
La forma en que se despliega la información facilita la organización de tareas
en un proyecto, la actualización de datos y la supervisión de su desarrollo
general, pues permite desplegar la información de distintas maneras para
revisar varios aspectos del proyecto al mismo tiempo.
Si el usuario es nuevo en el uso de esta herramienta Project se le recomienda

dejar en la pantalla la barra de herramientas ya sea la que se monta por
defecto o la que construya el usuario para tareas, recursos y proyectos,
pues muestra útil información en forma sencilla.
Se pueden comparar los calendarios del plan original con los reales
para determinar qué cambios se requieren en el proyecto, considerando
aspectos como la fecha de término esperada, el costo total o los recursos
asignados. Project facilita mediante el despliegue gráfico de las diversas
duraciones e interrelaciones entre tareas, la estructuración de un proyecto,
permitiendo además que las modificaciones al plan original sean fáciles
de llevar a cabo y se puedan mostrar rápidamente.
Project maneja los proyectos con base en cinco contenidos o tablas

generales de información:
1. Información general del proyecto,

2. Calendarios.
3. Tareas.
4. Recursos, y
5. Asignaciones que surgen cuando un recurso se asigna a una tarea.
La primera comprende los datos y parámetros generales de un proyecto;

la de tareas tiene la información propia de cada tarea y es quizás, la más
importante de todas; la de recursos puede o no existir, dependiendo de los
objetivos del proyecto y la de calendarios existe siempre, aún en forma
implícita, cuando se asigna a las tareas y/o a los recursos. Este gráfico
describe las relacionales entre las tablas:
Info gral. del proyecto:

- Información general
- Parámetros
Calendarios
Tareas Recursos
Asignaciones
Figura 1.27. Tablas de información de Project.
Microsoft Project en su versión 2010, es ejecutable en una computadora

con Windows 2000 o superior, operando en modo estándar, además
de requerir un mínimo de 24 Mbytes. (40 Mb. si maneja versiones de
Windows posteriores a Windows NT o XT) de memoria principal RAM.
El espacio en disco depende de la cantidad y tamaño de los proyectos
aunque es recomendable un mínimo de 30 Mbytes. Una unidad de CD-
ROM y una resolución VGA o superior es conveniente en la pantalla y un
mouse es casi obligatorio.
A continuación se presenta una sesión con Project y se invita al lector que

posea esta herramienta a que también lo haga desde su escritorio porque
tendrá la oportunidad de crear con esta herramienta la nueva variable
ya explicada en el numeral 1.6, el uso de los elementos básicos de la
planeación flexible más el uso de plantillas reformateadas que dispone
64
Project para crear la EDT aplicables a varios modelos de desarrollo de

proyectos informáticos.
La siguiente gráfica expone los pasos para llegar a las plantillas disponibles
de Project 2010:
Figura 1.28. Ventana del menú principal de MS-Project
Es de común práctica manejar proyectos no solo con esta herramienta sino

auxiliarse con la otra herramienta de Microsoft llamada Excel pues las dos
se complementan en forma muy eficiente y además con Excel es posible
elaborar gráficos y usar formulas matemáticas que Project por si solo no tiene.
Usando estas dos herramientas, se van a explicar enseguida los pasos para
definir la formula de la Tarifa y el cambio que se produce en las fórmulas
de los indicadores CPI y SPI.
Hay que tener presente que EVA requiere de dos condiciones previas:
• Haber guardado previamente un plan base, y
• Haber reportado una fecha de corte (fecha de estado en Project).
Las siguientes variables existen en Project a nivel de una tarea o del grupo
de tareas:
• Costo total, planeado y real
• Trabajo total, planeado y real.

Debe recordarse que la ecuación básica del concepto de Tarifa es

• Tarifa = Costo total / Trabajo total
Project tiene una facilidad para crear nuevos campos o variables, entonces
la labor consiste en definir una fórmula que tome el costo (planeado o real)
y lo divida por el trabajo, planeado o real; este cálculo se requiere aplicar
tanto a las tareas de detalle como a las de resumen y requiere de dos
condiciones básicas:
• Tener guardado un plan base, y
• Haber reportado una fecha de corte (fecha de estado en Project).
Dado que las siguientes variables ya existen en Project a nivel de una tarea
o del grupo de tareas:
• Costo total, planeado y real
• Trabajo total, planeado y real.
Entonces el procedimiento recomendado a seguir es:

1. Seleccionar la opción del menú principal Proyecto y
2. Dar clic en Campos personalizados:
Figura 1.29. Creando campos personalizados
66
3. Verifique que se va a crear un nuevo campo aplicable a las tareas

4. Luego seleccione el tipo de campo haciendo clic en la lista de opciones
con el nombre Tipo, y escoja Número.
5. Luego indique que va a cambiarle el nombre haciendo clic en el botón
Cambiar nombre…
6. Modifique el nombre en la ventana como se muestra en la figura
siguiente:
Figura 1.30. Cambiando el nombre a un campo personalizado
Cuando regrese a la ventana de Campos personalizados…

7. Haga clic en la opción Fórmula, para indicar que se va a crear una
fórmula para calcular los valores de este campo.
8. Observe que es posible también reportar una lista de valores o señalar
que se delega en el usuario reportar un valor al momento de usarlo.
9. Enseguida se muestra la siguiente ventana en la que en conjunto con
las variables o campos de Project y los operadores matemáticos y
lógicos que provee esta ventana, se puede armar esta fórmula:
Figura 1.31. Estableciendo la fórmula

En este momento se despliega de nuevo la ventana de Personalizar

campos…
10. Dar clic en el botón de Cálculo de filas de tareas de resumen
11. Enseguida clic en el icono Usar formula con lo que se especifica
que el objetivo es que use esta misma fórmula para las tareas de
resumen.
Este mismo proceso se puede seguir para las otras variables usadas en esta
presentación:
Tarifa planeada = Costo previsto / Trabajo previsto
EV (nueva fórmula) = Trabajo real * Tarifa planeada
CPI o IRC (nueva fórmula) = Tarifa planeada / Tarifa real
SPI o IRP (nueva fórmula) = Trabajo real / Trabajo previsto.
Resumiendo, la herramienta Project solo requiere de las siguientes 4

variables para poder establecer una formula para el concepto llamado
tarifa y para los indicadores de seguimiento:
• Costo real
• Trabajo real
• Costo previsto
• Trabajo previsto.
Los otros usos que se explicarán en esta obra de Project, serán en el

capítulo 3 donde se explican los procedimientos para generar archivos
de Project con base en plantillas pre formateadas que agilizan la creación
de proyectos informáticos y en el capítulo 4 que detalla como clasificar
las tarifas en una de las 4 categorías mencionadas en el numeral 1.6 para
así poder elaborar la gráfica numerada como 1.22; luego en el mismo
capítulo 4 se explicará el proceso de descargar los datos necesarios en
Excel7 para luego calcular las tarifas a intervalos regulares marcados por
las fechas de control.
7. Herramienta de Microsoft utilizada ampliamente para generar gráficas y aplicar formulas que
Project no tiene.
68
La técnica de la planeación paulatina o Rolling Wave

Existen proyectos en los que el mecanismo de evaluación de algunas tareas
es complicado de hacer o no es aconsejable hacerlo con mucha precisión
o cuando del éxito o fracaso de unas tareas depende la realización de
tareas sucesivas; es estos casos se recomienda usar la planeación paulatina
o por etapas (en Inglés, Rolling Wave). Ha ganado un lugar preferencial en
los últimos años para el desarrollo de proyectos informáticos con base en
metodologías ágiles.
Es posible que el mecanismo de reporte del avance de tareas de corta

duración o de bajo costo, genere muchas dudas si se hace con base con
un simple %, por lo que es aconsejable usar técnicas de reporte conocidas
como del 50/50 o del 0/100 queriendo decir que para estas tareas solo se
reportará como terminadas cuando todo el trabajo ha sido realizado (0/100)
o cuando va en un 50% a su inicio y el próximo reporte solo cuando se
termine (50/50). El PMI reconoce este tipo de acciones, mediante el uso
de iconos y opciones que aparecen cuando se activa el panel de Formato
de la herramienta Project:
Figura 1.32. Reporte de Avances del 25%, 50% 75% y 100%
Project facilita el uso de la planeación flexible haciendo que el usuario

detalle las etapas que van a ser ejecutadas a corto plazo y deje en forma
imprecisa las subsiguientes etapas; luego se usa la opción de generar un
plan base para solamente las tareas que han sido previamente seleccionadas
por el usuario.
Una vez se define el plan base de un proyecto que va a ser ejecutado

con técnicas ágiles (el término Fast Programming es también usado
apropiadamente en estos casos), se puede ejecutar la orden Guardar
línea de base mediante la opción Seguimiento del menú Herramientas,
seleccionando la opción Tareas seleccionadas en la ventana Guardar
línea de base como se muestra en la siguiente figura:

Figura 1.33. Guardando la Línea Base
Project copia toda la información del proyecto, guardándola en variables

que tienen todas el adjetivo de previsto (Duración → Duración prevista,
etc.). Se puede guardar un plan base para ciertas tareas lo que suele ocurrir
cuando el proyecto se planifica en forma paulatina o flexible (no olvidar
que las tareas han debido ser previamente seleccionadas).
Otros productos de software de manejo de proyectos

En este numeral se van a hacer unas recomendaciones sobre el empleo
de Software diseñado para el manejo de proyectos para calcular los
cronogramas, presupuestos y cantidad de esfuerzo o trabajo, tal como los
productos Microsoft Project, OpenAir y Primavera; para los que no quieran
invertir altas sumas en su adquisición, existe software libre muy bueno
como el GanttProject y Planner, pero se recomienda especialmente a
OpenWorkbench y OpenProj. Estas herramientas pueden ser descargadas
de: http://openproj.org/. Algunas personas alegan que este último no
funciona muy bien bajo el sistema Windows Vista™ por el momento. Es
muy similar al MS-Project y puede importar/exportar archivos con formato
de este aplicativo.
70
También puede ensayar con este sitio: http://www.openworkbench.org/

el cual está muy orientado a la planificación por recursos. Es un producto
derivado de NikuWorkBench de Computer Associates™, el cual lo integra
en Clarity. Aunque esta iniciativa pretende usar un software aplicativo en
propósitos para los que no fue concebido precisamente, el autor ha tenido
la oportunidad de usarlo en estos menesteres y los resultados han sido
hasta el momento satisfactorios.

72
Capítulo 2 • Iniciación
Capítulo 2
Iniciación
2.1 Formalización y definición de proyectos

En este capítulo se van a explicar las entidades, responsabilidades y
procesos que son claves en mayor o menor medida en la formalización
e iniciación de los proyectos en una empresa. Se comienza con una
unidad de manejo de proyectos que puede inclusive no existir en muchas
empresas, pero no por ello pierde su importancia.
La oficina de administración de proyectos

La oficina de administración de proyectos (PMO por Project Management
Office) es una unidad organizativa que formaliza y centraliza las técnicas
de administrar proyectos de una empresa. Su papel es muy importante
en las fases de Iniciación y planeación y generalmente una PMO asume
generalmente uno o todos de los tres roles siguientes:
1. Proporciona políticas, metodologías y plantillas para la gestión de
proyectos dentro de una organización.
2. Presta apoyo y orientación a los otros miembros de la Organización
sobre cómo gestionar proyectos, entrena a otros en la administración
de proyectos o en el software de gestión de proyectos y presta asistencia
con herramientas de administración de proyectos específicas.

3. Proporciona mecanismos para hacer a los Jefes de distintos proyectos,

responsables de los resultados de sus proyectos (todos los proyectos, o
de un determinado tamaño, tipo o influencia, son gestionados por esta
Oficina).
Hay que tener cuidado para comprender la autoridad de la PMO y cómo

es diferente de los demás jugadores en un proyecto. La PMO es una
estructura organizativa, no una persona. El papel de jefe de proyecto es
muy claro en proyectos informáticos y los papeles del patrocinador y de
otras personas involucradas en un proyecto se van a describir en este libro
en términos algo sencillos pues el enfoque básico de este libro es en el uso
de metodologías de manejo de este tipo de proyectos. La PMO puede:
• Administrar las interdependencias entre los proyectos
• Ayudar a proporcionar los recursos
• Terminar proyectos.
• Ayudar a recolectar toda la experiencia adquirida y la hace disponible
para otros proyectos
• Ofrecen plantillas (por ejemplo, para conformar las estructuras de
desglose de trabajo o EDT)
• Proporciona guías de orientación
• Proporciona Software de gestión de proyecto para la empresa.
• Involucrarse más fuertemente en la fase de iniciación tardía de un
proyecto.
Hay actualmente una fuerte tendencia a abrir Oficinas de Administración de

Proyectos, sobre todo en empresas que llevan ya muchos años manejando
proyectos. Pero se dan cuenta del riesgo; si lo hacen mal, puede generar un
sentimiento negativo hacia la gestión profesional de proyectos que puede
hacer retroceder a una empresa años atrás. Para ponerla a funcionar, debe
recordarse estos conceptos claves:
• Debe definirse claramente el papel de la PMO
• Elija uno de los tres roles, como se ha definido previamente y
mantenerlo sin intentar hacer todo lo posible
• Todos aquellos que se encuentran en la PMO deben ser PMP
certificados.
• Es necesario un compromiso de la gestión ejecutora
• El PMO no mejorará el rendimiento de su proyecto sin el uso de
procesos de gestión de proyectos adecuados y técnicos, por lo que se
debe fomentar una gestión profesional de proyectos.
74
Objetivos del proyecto

Puede haber una gran cantidad de diferentes tipos de objetivos perseguidos
en un proyecto informático pero lo que debe ser claro son los objetivos del
producto final que se debe entregar, que involucre al menos los objetivos
de costos y de calidad de las partes interesadas. Los objetivos del proyecto
son críticos en si mismos, como se ilustra a lo largo de este libro.
Una vez redactados, el gerente debe leerlos cuidadosamente para entender

mejor el enfoque básico del proyecto y tener presente que de acuerdo al
PMI, los objetivos del proyecto deben estar contenidos en el proyecto de
declaración de Alcance preliminar del proyecto y en la Declaración de
alcance.
La premisa básica es que los proyectos se consideran terminados cuando

se han cumplido sus objetivos. Un motivo para rescindir un proyecto antes
de su conclusión es que los objetivos del mismo no se pueden cumplir.
Es claro que un entendimiento más completo de los objetivos se alcanza
a medida que el proyecto se desarrolla y es una función básica del jefe de
proyecto esforzarse en lograr los objetivos del proyecto, y para ello:
• Los objetivos deben ser claros y alcanzables
• La razón de las actividades de calidad es asegurar que el proyecto
cumpla sus objetivos
• La razón de ser de los procesos de riesgo es mejorar las oportunidades
y reducir las amenazas a los objetivos del proyecto.
• Factores que podrían afectar negativamente a los objetivos del
proyecto, tales como el riesgo y la influencia de las partes interesadas
deben ser visto y ejecutar un seguimiento.
• Los proyectos a menudo requieren compensaciones y compromisos
entre los requisitos y los objetivos del proyecto.
• Los Objetivos del proyecto son determinados en la fase de procesos
de iniciación y refinados en la fase de procesos de planificación
• Uno de los objetivos del proceso de desarrollo del proyecto es
determinar cómo se desarrollará el trabajo para cumplir los objetivos
del proyecto.
Gestión por objetivos (MBO) es una filosofía de gestión que dice cómo una
Organización debe ser gestionada por objetivos. Consta de tres pasos:

1. Establecer objetivos inequívocos y realistas

2. Evaluar periódicamente si se cumplen los objetivos.
3. Implementar acciones correctivas.
Debe comprender lo que esto significa para el jefe de proyecto. Si el proyecto

no está en línea con o no es compatible con los objetivos empresariales,
es probable que pierda los recursos asignados y que el proyecto requiera
de mayor asistencia y atención. También debe comprender que MBO solo
funciona si la Administración General lo admite.
La restricción llamada popularmente “Triple restricción” a menudo se

expresa en términos de lo que un gerente de proyectos debe manejar o
saber manejar en forma simultanea para poder dirigir y garantizar entregar
el producto resultante del proyecto. En la actualidad se considera que las
restricciones generales de un proyecto son tiempo, costo, riesgo, alcance
o cualquier otro factor que limite las opciones.
Estos factores pueden incluir la fecha de un hito o en la que debe ser

completado el proyecto, o el máximo permitido al riesgo que un proyecto
pueda tener. La “triple restricción” como mecanismo básico suele
emplearse como ayuda para evaluar las demandas competitivas.
Triple restricción como tal es un término antiguo que incluía originalmente

el costo, el tiempo y el alcance. Una más actualizada y ampliada definición
incluye calidad, riesgo y satisfacción del cliente (o las partes interesadas
satisfacción). Actualmente es más recomendable usar el término “triple
restricción” para referirse a una definición ampliada.
Una gestión directa y/ o indirecta establece la prioridad de cada componente

y de las variables mutuamente interrelacionadas. Esta asignación de
prioridades se utiliza en todo el proyecto por el director del proyecto para
planificar el proyecto, evaluar el impacto de los cambios y demostrar el
éxito de una finalización correcta.
Es importante darse cuenta de que un cambio en uno de los componentes

de las restricciones planteadas, debe ser evaluado por su potencial efecto
en los demás componentes. En otras palabras, es poco probable que se
pueda acortar el cronograma de las tareas sin causar un impacto negativo
sobre el costo, riesgo, etc.
76
Queda entendido que las partes interesadas, los gerentes y otros intentarán
siempre conseguir algún cambió que de valor agregado al proyecto. Es
aceptable asumir que es responsabilidad del jefe de proyecto analizar estos
cambios y solicitar e identificar los impactos en todos los componentes de
las “restricciones” a través de un control de cambios integrado.
Se va a destinar en este momento un buen tiempo para explicar y ampliar

el análisis sobre el papel de un control de cambio integrado en proyectos
de teleinformática, pues se ha vuelto muy común en este tipo de proyectos
contar con un mecanismo dinámico y ágil que procese las solicitudes de
cambios tanto en la fase de planeación como en la ejecución y control.
Este aspecto es de especial cuidado, máxime cuando se manejan

metodologías tales como la llamada Ágil en el que el tiempo de desarrollo
y prueba de los programas deja un margen de tiempo muy estrecho para
estudiar e introducir cambios.
Para ello es conveniente ante todo observar la siguiente figura en la que

se muestran las implicaciones de tener una visión ampliada del nuevo
concepto de restricciones y sus mutuas interrelaciones:
Alcances Costo
Riesgo Tiempo
Satisfacción Calidad
Definición ampliada de las DELIMITACIONES.

Figura 2.1. Nueva definición de las restricciones
El control de cambios como tal es un proceso de documentación, revisión,

aceptación o rechazo de un cambio y posterior documentación de cualquier
modificación en la línea base o el plan de un proyecto. Generalmente y el
PMI lo propugna igualmente, debería existir un comité a cargo del control

de cambios que en lo posible lo dirija el (la) gerente del mismo y en el cual

tenga representación al menos el patrocinador del proyecto.
Todos estos aspectos hacen parte del modelo de desarrollo de proyecto

que instaure o maneje una empresa. El modelo de madurez organizacional
del PMI para la gestión de proyectos se llama OPM3 y este modelo está
diseñado para ayudar a las organizaciones a determinar su nivel de
madurez en la gestión de proyectos.
2.2 Definición de la estructura operativa

Al definir la estructura operativa y funcional de un proyecto es conveniente
ante todo mirar el ambiente que rodea el desarrollo de un proyecto y para
ello sirve mucho estudiar el Entorno Empresarial el cual generalmente
se manifiesta en términos de la existencia de un plan estratégico que
en forma periódica (anual, generalmente) revisa, clasifica y prioriza los
diferentes...
Proyectos, programas y portafolios

En las empresas en las que frecuentemente se desarrollan o se planea
desarrollar proyectos (¡deberían ser todas!) es importante introducir los
términos de Portafolio, Programa y Proyecto. Los mismos facilitan a una
organización, la pronta o tardía asignación de recursos, definir sus roles
y responsabilidades y por último, establecer los presupuestos apropiados
para cada proyecto.
• PROYECTO: esfuerzo temporal requerido para crear un producto,
servicio o resultado único.
• PROGRAMA: grupo relacionado de Proyectos coordinado para
obtener beneficios y controles que permitan su manejo individual.
• PORTAFOLIO: un conjunto de Programas o Proyectos que se reúnen
juntos para facilitar su manejo efectivo a fin de cumplir con una
estrategia especifica del negocio.
El siguiente gráfico ayuda a comprender el significado de estos términos

que son parte constituyente de los ejercicios de planeación estratégica de
las empresas, sin importar el horizonte de tiempo en que se tracen:
78
PLANEACIÓN ESTRATÉGICA
Portafolio de proyectos
Programa 1 Proyecto A Programa 2
Proyecto 1A Proyecto 1B Proyecto 2A Proyecto 2B
INTERACCIÓN ENTRE PORTAFOLIOS, PROGRAMAS Y PROYECTOS

Figura 2.2. Portafolio y programas de proyectos
Esta práctica de planeación estratégica facilita el estudio de muchos casos

de proyectos en las que no es fácil la consecución de recursos por razones
distintas y permite estudiar la priorización de proyectos vinculados con
alguna emergencia o a los cuales no se les han asignado un presupuesto
alguno o que no obtuvieron una alta prioridad en un caso determinado.
Lamentablemente no todas las organizaciones tienen oficinas de manejo
de proyectos en muchos países.
2.3 Administración de las comunicaciones y expectativas de

los interesados
Ante todo es aconsejable identificar a los diferentes grupos de interesados
en un proyecto, por lo que se comienza este numeral analizando quiénes
son estos interesados o también conocidos como “stakeholders” si se usa la
expresión inglesa para denominar a los grupos de Interés de un proyecto.
Análisis de los interesados
Amén del Gerente y de los patrocinadores del proyecto existen una serie
de personas que deben ser considerados en un proyecto. La siguiente lista
describe el papel y la forma más aceptable de nombrar a estas personas:
• Junta de Revisión del Portafolio: revisa cada proyecto en términos de
su valor, riesgos, ROI y otros atributos y determina cuáles proyectos
pueden continuar y cuáles no

• Gerente portafolio de proyectos: da viabilidad a proyectos y programas

• Administrador de operaciones: maneja actividades corrientes e
incorpora en determinados proyectos, facilidades y operaciones que
lo apoyen
• Proveedores/Socios de negocios: todas aquellas que faciliten su apoyo
• Equipo de trabajo: programación, evaluación y control en su manejo
• Coordinador: actúa como enlace de comunicación con la
Administración General; puede tener limitada participación en algunas
decisiones
• Facilitador (expeditor): verifica que algunas tareas se realicen
supervisando el estado de algunas asignaciones y comunicándolas a
la Administración General. No tienen ningún papel en la toma de
decisiones del proyecto
• Gerente funcional: manejo de personal y de recursos que participan
en proyectos. Puede a veces entrar en conflicto con el Gerente del
proyecto
• Patrocinador (Sponsor): asegura fondos, crea el «Project Charter» y
aprueba la terminación del proyecto
• Organización ejecutora: compañía o División que realiza el trabajo
• Influyente (Influencer): persona o grupo de personas indirectamente
relacionadas con un proyecto y que tienen alguna influencia positiva
o negativa en el mismo.
Observe la diferencia en funciones entre el Coordinador y el Facilitador

pues el PMI considera que el primero tiene alguna participación ya sea
limitada o absoluta, en procesos de toma de decisiones y el segundo, no.
En este sentido, el gerente debe interpretar en forma inequívoca quien es
un coordinador y quien es un facilitador.
Restricciones y supuestos: el patrocinador, el equipo de trabajo y otros

interesados pueden identificar supuestos y restricciones durante el proceso
de Iniciación y a lo largo de todo el proyecto. Si las restricciones cambian
o los supuestos estaban equivocados, el plan de gestión del proyecto
necesita ser cambiado.
Al establecer el plan de comunicaciones del personal a cargo de un proyecto,

hay que tener en cuenta que la necesidad y utilidad de este plan es:
• Detallar métodos a ser usados para recolectar y almacenar los diferentes
80
tipos de información
• Detallar hacia quién la información debe fluir
• Describir métodos a ser usados para distribuir la información
• Describir la información a ser distribuida
• Mostrar cuándo se producirá cada tipo de información
• Discutir las formas de acceder a información entre comunicaciones
programadas.
Es el gerente del proyecto el encargado de establecer los mecanismos de

comunicación y reporte a los diferentes grupos de interesados. Con relación
a las expectativas de estos interesados es conveniente decir primero que es
muy frecuente que haya diferentes puntos de vista de los interesados a los
que potencialmente habría que agregar:
• Personas u organizaciones cuyos intereses pueden impactar en forma
positiva o negativa a un proyecto.
• Grupos de interés que pueden o deben ser periódicamente informados
del proyecto o sus servicios ser solicitados para satisfacer sus
necesidades o expectativas.
Adicionalmente, los siguientes pueden ser considerados en mayor o menor

medida como “stakeholders” de un proyecto, lo que depende de otros
aspectos organizativos de este:
• Gerente del proyecto
• Cliente (individuo u organización que usará el producto del
proyecto).
• Organización ejecutora
• Patrocinador del proyecto (sponsor).
• Otros posibles:
– Propietarios de los diversos activos a ser usados en un proyecto.
– Financiadores.
– Proveedores.
– Contratistas.
– Miembros del equipo del proyecto.
– Agencias gubernamentales.
– Distribuidores.
– Sociedad en general.
De acuerdo a los principios y recomendaciones del PMI, el Gerente de un

proyecto debe ser una persona que está en capacidad de cumplir con las
siguientes funciones básicas:
• Identificar y asegurar las expectativas y necesidades de los ¨stakeholders¨
y del patrocinador
• Comunicar en forma efectiva los mecanismos de Iniciación de las
actividades
• Explicar a miembros del equipo de trabajo las tareas a ser realizadas
de acuerdo al plan
• Establecer los procesos de control del alcance del proyecto
• Conocer, evaluar y reconocer las características del trabajo a ser
realizado
• Comunicar el estado del proyecto a medida que se desarrolla a los
grupos de interés pertinentes.
Balanceando intereses entre los interesados

Los interesados muy frecuentemente pueden tener diversos enfoques e
inquietudes que pueden llevar fácilmente a conflictos entre los miembros
de los grupos de interés. El Gerente del proyecto puede en estos casos
acudir para despejar estos conflictos, a la siguiente tabla propuesta de
prioridades y que se utiliza exactamente en el orden descrito, es decir que
la regla 1 tiene prioridad sobre la 2 y la 3 y la 2 está por encima de la 3:
1. Porqué el proyecto va a ser realizado? Cuáles son las condiciones
del mercado o las necesidades del negocio? Cómo es la prioridad en
comparación con la de otros proyectos?
2. Cuáles ítems de los que deben ser ejecutados, y están descritos en el
“Project Charter”?
3. Qué dice el plan de administración del proyecto?
Como ejemplo, suponga que dos miembros de este grupo tienen conflictos
de interés. Uno de ellos, insiste en usar una vieja aplicación sistematizada
de reportes debido a que él está familiarizado con esta, mientras que el
otro no desea seguir empleándola; hasta aquí se podría argumentar que la
regla 3 provee cierta flexibilidad para poder discutir este caso.
Pero si las condiciones del mercado que impulsa el proyecto del caso, tal y
como fue mencionado en su “Project Charter” dice que es imperativo usar
un nuevo Software para lograr puntos en un mercado muy competido,
82
entonces esta necesidad tiene prioridad sobre el deseo de usar un viejo

software.
2.4 Gestionando la integración del proyecto

En todos los proyectos, sin importar la clase de productos a ser desarrollados,
es muy conveniente que la integración se exprese en términos de las
necesidades del negocio, la declaración del Alcance del producto y el
análisis de las suposiciones y restricciones aplicables a un proyecto.
Necesidades del negocio

Son todas las expectativas y necesidades que determinan y condicionan
la decisión de ejecutar un proyecto, expresadas en cifras y términos que
pueden y deber ser evaluados y cuantificados para posteriormente ser
confirmados por los responsables de su desarrollo.
Alcance del producto

Ante todo es conveniente tener en cuenta que el alcance del producto
resultante del desarrollo de un proyecto comprende todos los requisitos
y funcionalidades que van desde su diseño hasta la entrega final que se
hace a la terminación formal del respectivo proyecto. Existen muchísimos
mecanismos de medir el Alcance del producto de acuerdo a la definición
y naturaleza del mismo.
Las características comunes de los productos resultantes de un proyecto

informático se mide usualmente en términos de su funcionalidad,
modularidad y capacidad de integración con otras aplicaciones o sistemas
de información.
Fundamentalmente este ciclo comienza con un plan de negocios, luego

del cual viene la planeación y el desarrollo del proyecto, seguido por el
proceso de transición en el que formalmente se hace entrega del producto
a la parte responsable de su operación y que finalmente termina con el
fin de la explotación operativa, financiera y comercial del producto o
entregable final.
Análisis de las suposiciones y restricciones aplicables

Casi todos los proyectos (por no decir que todos) generan a lo largo de
su desarrollo, un gran esfuerzo en balancear las diferentes variables que
en algunos casos se enfrentan entre sí y ocasionan problemas. Como se
mencionó en el capítulo anterior, los gerentes de proyectos tradicionalmente
se han focalizado en tres de las más importantes y comunes restricciones
es decir, el Costo, Tiempo y el Alcance. En la realidad, hay más de tres
restricciones y cada una de ellas tiene un efecto importante en el proyecto
y es el Gerente del mismo el primer responsable en su manejo para poder
terminarlo en forma exitosa.
Si el gerente presta demasiada atención a una de estas restricciones,

ello puede a su vez ocasionar daños en otros aspectos por lo que
continuamente el Gerente debe estar en un plan de balancearlas. Estas
limitaciones incluyen los siguientes efectos, aunque es de advertir que
pueden presentarse más una vez se analizan sus interrelaciones:
1. Alcance: ¿cuánto trabajo deber ser realizado? – Aumentar el Alcance

aumenta la cantidad de trabajo a realizar y viceversa.
2. Calidad: qué estándares de calidad debe el proyecto cumplir? Mayores
estándares de calidad implica mayores esfuerzos y trabajo y ello
provoca a su vez impacto en otras restricciones
3. Cronograma: es el tiempo necesario para terminarlo; modificar el
cronograma altera las fechas de inicio y/o terminación de las tareas
y puede ocasionar cambios en la fecha final de terminación del
proyecto.
4. Presupuesto: es el costo requerido para poder realizar los objetivos
del proyecto; cambiar el costo del proyecto generalmente causa
alteraciones en el Alcance, el Tiempo y la Calidad.
5. Recursos: los que están disponibles para poder ejecutar el trabajo del
proyecto.
6. Riesgos: cada decisión hecha en la planeación y en la ejecución de
un proyecto conlleva algún riesgo. Decisiones riesgosas pueden tener
consecuencias que afectan a otras restricciones.
La clave para poder entender las restricciones de un proyecto es aceptar
que todas ellas están estrechamente interrelacionadas; por ejemplo, si se
reduce el presupuesto de un proyecto es muy probable que se desmejore
la calidad y quizás es muy posible que se incremente el riesgo. Si se cuenta
84
con menos fondos financieros, menos trabajo podrá ser hecho o es también
posible que tome más tiempo poder producir los mismos resultados. De
cualquier forma, un cambio en los costos produce un impacto colateral en
otras variables.
Aun cuando este concepto es fácilmente asimilable, el Gerente de

proyectos debe esforzarse en que estas restricciones estén apropiadamente
balanceadas. Además de estar permanentemente preocupado por balancear
estas restricciones, el Gerente debe también mantener informados a los
Interesados sobre la necesidad de balancearlas.
En la práctica se percibe que los Interesados (stakeholders) tienden más

a favorecer una restricción sobre otra(s) y aquí lo importante es que los
Interesados entiendan la necesidad de balancearlas a todas en forma tal que
refleje los requisitos y objetivos finalmente acordados para un proyecto.
Las mencionadas consideraciones deben ser documentadas y

suficientemente ilustradas por el Gerente para el conocimiento de los
Interesados del proyecto, enfatizando sus efectos en los objetivos del
mismo.
Todos los anteriores conceptos son elementos formalmente integrados

unos con otros y son la base de un Acta de constitución del proyecto que
oficialmente es la declaración de comienzo del mismo, que es llamada
por el PMI en inglés el ¨Charter¨del proyecto. Esta acta como mínimo
debe identificar a los interesados y sus expectativas sobre el proyecto,
el Alcance del proyecto en términos de los supuestos, las restricciones y
requisitos básicos del producto entregable, y un examen preliminar de los
riesgos identificados hasta este momento del proyecto.

86
Capítulo 3 • Planeación
Capítulo 3
Planeación
3.1 La planificación de proyectos

En capítulos anteriores se introdujeron y estudiaron los conceptos claves
de procesos, grupos de procesos y áreas de conocimientos como temas
fundamentales del PMI. Vale la pena recordar que el PMI define un total
de 42 procesos que describen todas las tareas a desarrollar durante el ciclo
de vida de un proyecto y que estos procesos se organizan a su vez en
nueve áreas de conocimiento que por otra parte, se presentan en cinco
grandes grupos de procesos.
Uno de los más importantes grupos de procesos es el de la planeación

debido a que un poco más de la mitad de estos procesos están en este
grupo; de hecho 22 de los 42 procesos están de pleno en este grupo. Si
el lector intentase identificar las áreas de conocimiento relacionadas con
la planeación, se encontrara ante el hecho de que los procesos de este
grupo de planeación cubren todas las 9 áreas de conocimientos y de ahí
la importancia del grupo de planeación.
Los tres elementos de entrada fundamentales para poder entrar al grupo de

procesos de planeación son:

1. Acta de constitución (“charter”)

2. El registro de los interesados (“stakeholders”)
3. La estrategia de gestión y manejo de los interesados.
El grupo de procesos de iniciación visto anteriormente se caracteriza

porque responde generalmente a las preguntas del tipo “qué?” y “por
qué?” Mientras que en el de planeación, se van a responder preguntas
del tipo “cómo?”. La razón para ello es porque en este, los procesos a ser
desarrollados resultan en respuestas que explican cómo el proyecto va a
ser conducido a fin de que se cumplan sus objetivos a cabalidad.
La siguiente figura muestra cómo los procesos del grupo de planeación se

relacionan entre sí y alerta al lector sobre la forma como debe prepararse
para planear diversos aspectos como el cronograma de las tareas, el manejo
del dinero disponible, los requisitos de calidad del entregable final, las
respuestas a los diversos riesgos (¿qué proyecto no tiene riesgos?) y los
diversos contratos con los proveedores asociados al proyecto.
Debe recordarse que el lector tiene que asociar e identificar bien las
entradas, herramientas y salidas de cada uno de estos procesos y que un
buen ejercicio que ayuda a memorizar bien estos procesos es tratar de
dibujar los flujos de estos procesos y la forma como estos se relacionan
entre sí. Se invita al lector a hacerlo.
El motivo mayor que empuja el proceso de planeación es proveer un

marco de análisis en el que la información a ser producida sea el plan de
administración del proyecto. De hecho, el plan en sí es una recopilación
de otros planes dado que el esfuerzo mayor en esta fase es el desarrollo
de documentos que de una forma u otra están relacionados con el plan
general de manejo y administración del proyecto.
En la medida que se conozca y se recolecte más información, el plan

general llega a ser más completo y detallado y es de esperar que la
confianza de los interesados (stakeholders) aumente en forma significativa.
La planeación es a su vez un grupo de procesos interactivos y dinámicos

pues a medida que sus procesos progresan, el plan se va modificando como
consecuencia de una mayor y mejorada cantidad de aportes y de muchas
88
Adm. del alcance Adm. de Costos

6.1 Definir 6.3 Estimar
5.1 Recolectar actividades recursos de activ. 7.1 Estimar
requisitos costos
6.2 Secuencia 6.4 Estimar durac.

5.2 Definir el de actividades de actividades 7.2 Determinar
alcance presupuesto
6.5. Desarrollar
5.3 Crear la cronograma
EDT (WBS)
Plan administrac. Tiempo
8.1 Adm. calidad
Plan de
4.2 Desarrollo plan calidad
12.1 Adm. adquis. adm. del proyecto
Plan de
adquisiciones Manejo
de la investigación 9.1
proyecto Plan desarrollo
del rec. humano
11.3 Análisis
11.1 Plan admin.
cualitativo
de riesgos 10.2
de riesgos
Administración de
la comunicación
11.3 Análisis
11.2 Identificación
cuantitativo
de riesgos
de riesgos
11.5 Plan de
respuestas al riesgo
Administración de riesgos del proyecto
Figura 3.1. Interacciones de los procesos de planeación. Esta gráfica fue inspirada por la que aparece
en el PMBOK.
veces inesperadas circunstancias. Logros no esperados, demoras, factores

y razones externo(a)s e interno(a)s, pueden dar lugar a cambios en el plan
de tal forma que no se puede asumir que el proceso de la planeación se
realiza de una sola vez y se puede concluir que la planeación es interactiva
a lo largo de todo el ciclo de vida del proyecto.
Hay que mantener siempre la visión de que uno de los logros más prácticos
y necesarios al terminar un plan es la obtención del así llamado plan línea

de base que expresa en términos como mínimo del alcance, tiempo, costo
y calidad, cuales son los estimativos medibles y a ser alcanzados de un
proyecto. La línea base es la encargada finalmente de recopilar y registrar
los objetivos, planes y labores en términos de la duración, trabajo, calidad
y costo, a ser realizadas a fin de cumplir con los requisitos funcionales y
operativos del proyecto.
La siguiente lista detalla los aspectos más importantes del proceso de

planeación que son fundamentales en cualquier tipo de proyectos y por
simple extensión, en un proyecto informático tal y como los recomienda
el PMI:
• Plan de administración del proyecto – es el proceso que direcciona
el plan de administración del proyecto y es el de mayor significancia
porque hace claro las directrices para desarrollar planes subsidiarios y
recopila la información del plan final del proyecto
• Alcance – se focalizan tres procesos de planeación, comenzando con
el que refina el alcance preliminar ya hecho; luego otros procesos
descomponen los objetivos globales en paquetes más pequeños y más
manejables de objetivos parciales
• Actividad – son cinco procesos que se dirigen a la planeación de las
actividades o tareas. Luego del anterior proceso, en este momento
las actividades son detalladas y son integradas con los recursos del
proyecto y finalmente son secuenciadas
• Costo – aquí hay dos procesos de planeación, cuyo esfuerzo se
centraliza en hacer estimativos de costos y luego organizarlos en el
presupuesto final del proyecto.
Hay una regla práctica denominada Regla del 100% que consiste
sencillamente en recordarle a los encargados de un proyecto que el 100%
del trabajo del mismo debe hacer presencia en el momento de hacer la
EDT(o WBS en inglés); ello obliga a que las tareas resultantes por ejemplo:
hacer pruebas de resultados parciales, recopilar estadísticas, reuniones de
comités, o aquellas que se plantean para contrarrestar la eventualidad de
un riesgo deben ser tenidas en cuenta al momento de elaborar la EDT.
Esto también incluye las actividades de solicitudes de cotizaciones o de

analizar propuestas de proveedores tanto de hardware como de software; el
no programar estas tareas con antelación puede dar lugar a modificaciones
90
en el desarrollo del proyecto y ocasionar algunas distorsiones en los costos

y en tiempos del proyecto.
La siguiente gráfica es una muestra típica de las fases generales y ya un

poco más detalladas de la secuencia de tareas a ejecutar para un proyecto
de desarrollo informático que puede servir como matriz de proyectos
similares:
Desarrollo
de un producto
de Software
Requisitos
Administración Diseño Integración
funcionales del Construcción
del proyecto detallado y pruebas
producto
Manejo Manejo Codificación Ajustes y cambios

Planeación de Software de Software de Software al Software
Acuerdos Documentación Documentación Documentación Documentación

y reuniones del usuario del usuario del usuario del usuario
Administración Material del plan Material del plan Material del plan Material del plan
del proyecto entrenamiento entrenamiento entrenamiento entrenamiento
Figura 3.2. Flujo de tareas para el desarrollo de un producto software
En la fase de elaboración del cronograma de un proyecto, una de las fases

que debe ser muy bien documentada es la de requerimientos funcionales
puesto que se ha comprobado que aproximadamente el 80% de los
proyectos de sistemas de información fallan por una inadecuada gestión
de estos requerimientos.
El siguiente diagrama explica en una forma similar al anterior el esquema

de tareas y sus secuencias lógicas de un proyecto de desarrollo de software
descrito en términos generales:

Análisis de Planeación
necesidades de
y diseño
información Personalización
del aplicativo Entrega a
Codificación
y pruebas producción
Análisis de Planeación
necesidades de
y diseño
información Personalización
del aplicativo Entrega a
Codificación
y pruebas producción
Figura 3.3. Secuencia preliminar de las tareas de un proyecto TIC
Note la secuencia lógica de las tareas y como algunas se ejecutan en

forma simultánea formando una serie de ciclos; en proyectos de software
es posible encontrar tareas que se repiten con alguna frecuencia debido
a diversos factores como criterios de aceptación de labores terminadas
y de módulos probados, dificultades en su integración y complejidad
y la experiencia en el manejo y aprovechamiento del lenguaje o de las
herramientas de programación.
La planeación paulatina o Rolling wave

Como ya se menciono, los proyectos informáticos que se desarrollan con
metodologías agiles se caracterizan porque su plan de desarrollo no se ve
conveniente hacerlo con precisión a largo plazo y se prefiere o se ve más
conducente desarrollar planes a muy corto plazo y en forma sucesiva;
es estos casos se usa la planeación paulatina o por etapas (en Inglés,
Rolling Wave). Esto ha llegado a ser muy frecuente en proyectos del tipo
informáticos.
92
Una herramienta de Software como Microsoft Project facilita esta forma

de planeación haciendo que el usuario detalle las etapas iniciales y deje
en forma imprecisa las subsiguientes etapas; luego se usa la opción de
generar un plan base para unas tareas previamente seleccionadas como se
explicará más adelante.
Es posible que el mecanismo de control de algunas tareas de corta duración

o de bajo costo ocasione muchos problemas si se hace en forma rutinaria,
por lo que se aconseja el uso de técnicas de reporte conocidas como del
50/50 o del 0/100 queriendo decir con ello que para estas tareas solo
se reportará como terminadas cuando todo el trabajo ha sido realizado
(0/100) o que va en un 50% cuando se inicia y el próximo reporte solo
cuando se termine (50/50). El PMI reconoce y facilita este tipo de acciones
en diversos casos.
Durante el proceso de secuenciar las actividades, el objetivo primordial es

poner las actividades en el orden en que van a ser ejecutadas. Lo que debe
ser hecho ya se hizo, ahora el interés es arreglar las actividades en el orden
más eficiente y efectivo. La siguiente figura explica las entradas, técnicas y
procedimientos usados y las salidas esperadas de este proceso:
Entradas Salidas
Lista de actividades
Secuenciar Estimar los
Diagramas de red
Lista de hitos las recursos
del cronograma
actividades de las tareas
Propuesta de alcance
Herramientas y técnicas
• Método de diagramación de precedencias
• Determinación de precedencias
• Aplicar demoras y anticipos
Plantillas de red del cronograma
FLUJOGRAMA DEL PROCESO DE SECUENCIAR ACTIVIDADES

Figura 3.4. Entradas, Salidas y Herramientas del proceso de secuenciar las tareas
Existen varios formatos para explicar la secuencia de las actividades, a

saber:
1. Lista de actividades: comprende todas las tareas que se requieren para
un proyecto; generalmente lista las tareas (no necesariamente en el
orden de su ejecución) con un número y una corta descripción del
trabajo que implica el desarrollo de cada tarea.

2. Diagramas de barras: representa cada tarea por medio de barras, con

fechas programadas de inicio y terminación, y la duración prevista de
ellas.
3. Diagramas de redes: representación gráfica de la lógica de desarrollo
de las tareas y su ubicación en el tiempo. Generalmente contiene
información de sus fechas y de sus relaciones con otras tareas lo que
da lugar a la clara visualización de la(s) ruta(s) crítica(s). Este tipo de
diagramas puede ser presentado haciendo que la información de cada
tarea vaya en la flecha que conecta las tareas o vaya en un nodo
(generalmente rectangular).
La planeación del recurso humano

Esta parte es quizás una de las más importantes por la alta trascendencia
e importancia que tienen los recursos humanos, sobre todo en proyectos
del área de tecnologías de información. La siguiente gráfica recalca los
procesos a seguir en este momento:
LA ADMINISTRACIÓN DEL EQUIPO DE TRABAJO
1. Planear el
Recurso humano
2. Vincular el
Recurso humano
3. Desarrollar el
Recurso humano
4. Administrar el
Recurso humano
Figura 3.5. Fases del proceso de contratar el Recurso Humano
El gerente del proyecto ejerce las siguientes roles y responsabilidades en

estos casos:
• planear, programar y estimar el recurso humano a ser vinculado
• evaluar desempeño, costos y tendencias.
• reportar progreso en las tareas encomendadas al recurso humano.
• mantener relaciones con clientes/consultores.
94
• administrar la logística.
• controlar costos.
• escribir y administrar procedimientos.
• administrar las interfaces establecidas en el cronograma
• integrar subsistemas del proyecto.
En resumen el gerente del proyecto debe tener claro las siguientes

funciones generales que son las más importantes al contratar el recurso
humano necesario:
• Planear
• organizar
• liderar
• controlar.
La planeación del recurso humano en un proyecto se ve clara después del

examen de la siguiente figura:
Plan del
proyecto
Estimar Desarrollar Plan de

recursos Recursos humanos
Estimar
costos
Figura 3.6. Fases del desarrollo del Recurso Humano
En la siguiente tabla, se muestran los elementos claves en términos

de entradas, técnicas y salidas al desarrollar el plan de consecución y
contratación del recurso humano:
TABLA 3.1. Entradas, Herramientas y Salidas del proceso de contratación del Recurso
Entradas Herramientas y técnicas Salidas

1. Factores alrededor de la 1. Flujogramas de funciones y
1. Roles y responsabilidades.
empresa descripción de cargos.
2. Activos organizacionales 2. Diagramas de organización

2. Redes de funciones.
en procesos de proyectos.
3. Plan de Administración del

proyecto: 3. Plan de Administración del
3. Teoría organizacional.
- Requisitos de recursos/ RRHH.
Tarea.

• Requisitos de recursos / tareas: define qué tipos de competencias se

requieren por cada tipo de individuo o de grupos y en ¿qué momento?
– son un subconjunto de los requisitos generales de recursos
identificados al momento de asociar recursos a una tarea.
• Plan de administración del RRHH: describe cómo y cuándo los
requisitos de los recursos serán cumplidos. El plan de administración
del rrhh puede ser informal y escasamente programado o ser formal
y muy bien detallado, con base en las necesidades del proyecto.
Información del plan de administración del RRHH varía por área de
aplicación y depende también del tamaño del proyecto.
• Roles y responsabilidades: los siguientes son los aspectos a ser
estudiados aquí:
– Rol: descripción de la parte de un proyecto por la que una persona
será responsable (ejemplo, Programador de Java 3.0, etc.). Claridad
en la autoridad, responsabilidad y sus límites son esenciales para el
éxito del proyecto.
– Autoridad: el derecho de aplicar recursos al proyecto, tomar deci-
siones y firmar aprobaciones. Los miembros del equipo operan en
mejor forma cuando sus niveles de autoridad están a la par con sus
responsabilidades individuales.
– Responsabilidad: el trabajo que un miembro del equipo se espera
que realice, a fin de completar las actividades del proyecto.
– Competencia: las habilidades y capacidades que se requieren para
terminar las actividades del proyecto. Si los integrantes del equipo
no las poseen, su desempeño puede poner en peligro al proyecto.
Cuando esto ocurre, se necesitan respuestas proactivas tales como
entrenar, solicitar, contratar, cambiar cronogramas o los alcances,
serán requeridas.
Las siguientes son las consideraciones más importantes que el PMI

recomienda al momento de vincular el equipo de trabajo del proyecto:
• Es el proceso de contratar los recursos humanos necesarios para
terminar el proyecto.
• El equipo de administración del proyecto puede tener o no control
sobre los miembros del equipo contratado para un proyecto.
• En muchos ambientes de trabajo de proyectos, el mejor recurso puede
estar no disponible, por lo que el equipo de manejo del proyecto
debe ser muy cuidadoso a fin de asegurar que estos estén disponibles
cuando se necesiten en un proyecto.
96
Las entradas, herramientas y salidas del proceso de vincular al equipo de

trabajo de un proyecto:
TABLA 3.2. Entradas, Técnicas y Salidas del proceso de vincular el recurso Humano

1. Factores alrededor de la 1. Asignación del ¨Staff¨del
1. Pre-asignaciones.
empresa proyecto.
2. Activos organizacionales
2. Negociación. 2. Disponibilidad de recursos.
en procesos
3. Plan de Administración del

3. Roles y responsabilidades. 3. Contratación.
¨Staff¨ del proyecto.
4. Diagrama de organización
4. Equipos virtuales.
del proyecto.
5. Plan de Administración
¨Staff¨ del proyecto.
Finalmente el proceso de desarrollar el equipo del proyecto considera

estos aspectos claves:
• El proceso de desarrollar los recursos humanos pretende mejorar las
competencias e interacciones entre los miembros de un equipo del
proyecto, con el propósito de mejorar su desempeño.
• Los objetivos son:
– Mejorar las habilidades de los integrantes del equipo con la idea de
incrementar sus habilidades en completar las tareas del proyecto.
– Mejorar los sentimientos de fidelidad, confianza y cohesividad en-
tre sus miembros a fin de elevar su productividad mediante un me-
jor trabajo en equipo.
– En este tipo de proyectos del área de la Teleinformática se debe
promover e incentivar al personal de forma tal que se reduzca la
necesidad de que tenga que ser remplazado, por los graves incon-
venientes que ello ocasiona.
Adicionalmente en proyectos del tipo informático es altamente apreciada

la adecuada integración del equipo humano y existe un término llamado
sinergia cuya esencia se puede encontrar en la frase ¨El todo es mayor
que la suma de sus partes¨ y que inclusive se muestra en dos dimensiones
confrontadas pues existe una sinergia positiva y otra negativa.

La positiva tiene las siguientes características:

• El equipo comparte un sentido de propósito común y cada integrante
esta bien dispuesto a trabajar por el logro de los objetivos comunes
• El equipo tiene los talentos y las experiencias individuales y los emplea
de acuerdo a las necesidades del proyecto
• Las funciones se equilibran y se comparten en aras de cumplir con las
tareas
• El equipo aplica energía para solucionar problemas más que agotarse
por conflictos interpersonales
• Se fomentan las diferencias de opinión y se expresan con libertad
• Los errores se manejan como oportunidades de aprendizaje y no como
razones para implantar un castigo
• Los integrantes establecen estándares personales y se alientan a
cumplir con los objetivos del proyecto
• El equipo se integra en forma eficiente y se considera asimismo una
fuente importante de crecimiento personal y profesional.
Modelo de desarrollo de un equipo humano

Muchos expertos consideran que los equipos de trabajo de una manera
predecible y en cuyo curso se pueden identificar cinco (5) etapas, a saber:
1. Formación: los integrantes se familiarizan y entienden el alcance del
proyecto. Comienzan por establecer las reglas básicas del equipo y se
esfuerzan en averiguar que conductas son aceptables con relación al
proyecto y las relaciones interpersonales.
2. Tormenta: esta marcada por un alto nivel de conflictos internos.
Los miembros se reconocen como un equipo pero se resisten a las
limitaciones del proyecto y las que impone el grupo a su individualidad.
Hay discusiones sobre quien controlara al equipo y quien toma las
decisiones. Conforme se resuelven los problemas, el grupo acepta una
autoridad y se pasa a la siguiente etapa
3. Normatividad: se desarrollan las relaciones cercanas y el equipo
muestra cohesividad y se demuestran sentimientos de camaradería y
de responsabilidad compartida. El grupo se consolida y se establece un
conjunto de expectativas comunes sobre cómo el grupo va a estar unido
4. Desempeño: la estructura es funcional y se acepta por completo; la
energía de todo el grupo pasa de conocerse entre ellos a cómo el
grupo trabajará unido
98
5. Cierre: el equipo se prepara para su terminación en la que el alto

rendimiento ya no es una prioridad, puesto que la atención se
concentra en cómo terminar el proyecto. Algunos estarán optimistas,
otros disfrutan los logros alcanzados y otros podrán sentirse deprimidos
por la partida de algunos integrantes.
Este modelo tiene varias implicaciones para los gerentes de proyectos,

pues aunque sirve para conformar los equipos de trabajo y ayuda a explicar
las tensiones propias de trabajar en equipo, enfatiza en gran medida la
importancia de la etapa normativa (3) lo cual contribuye significativamente
al nivel de productividad a partir de la siguiente etapa (la 4).
Recompensas por desempeño

Generalmente los proyectos del tipo informático son una excelente
oportunidad para que los participantes muestren un alto desempeño y
para que aprendan nuevas habilidades. Aun cuando en un proyecto los
resultados no sean exactamente lo que se buscaban, las recompensas
internas o externas juegan un papel muy importante en la motivación del
desempeño por parte del equipo de trabajo.
Como el trabajo de los proyectos informáticos es un esfuerzo de

colaboración mutua y de compartir diversas habilidades, tiene sentido
que las recompensas alienten primordialmente el trabajo conjunto, pero
reconociendo a cada integrante sus logros al mismo tiempo que se trata de
que los bonos o los incentivos que se vayan a entregar se asocien con las
prioridades del proyecto y con el tamaño del esfuerzo alcanzado.
Muchas empresas otorgan las recompensas en efectivo y muchas otras lo

hacen en la forma de vacaciones o temporadas con todos los pagos hechos,
pero sin importar el cómo se concedan en todos los proyectos deberían
haber reglas claras relativas al otorgamiento de incentivos económicos
derivados de un alto rendimiento y productividad demostrado en función
de los estándares señalados para estos proyectos.

La comunicación del equipo de trabajo

Es este un factor muy importante y el motivo mayor que empuja el proceso
de planeación de las comunicaciones es proveer los medios y los niveles de
reporte de información entre los integrantes del equipo de trabajo del proyecto
y de todos los interesados, entre sí y con todos los agentes externos.
El plan de comunicaciones del personal involucrado en un proyecto sirve

para los siguientes propósitos:
• Detallar métodos a ser usados para recolectar y almacenar los tipos de
información
• Detallar hacia quién la información debe fluir
• Describir métodos a ser usados para distribuir la información
• Describir la información a ser distribuida
• Mostrar cuándo se producirá cada tipo de información
• Discutir y acordar las formas de acceder a información de las
comunicaciones programadas.
El plan de comunicaciones define las necesidades de comunicación de

los interesados, el formato, la frecuencia y a quien se envía o quien recibe
la información. Los medios de comunicación pueden incluir reportes,
reuniones, procesos de cambios, llamadas, mensajes y la información
de contactos entre los miembros del equipo de trabajo. Permite a los
integrantes del equipo de trabajo conocer las reglas de comunicación
y las expectativas del proyecto, para analizar en profundidad estos
aspectos:
• Necesidades de comunicación de los Interesados (“stakeholders”)
• La infraestructura de comunicación para distribuir información del
proyecto
• Reportes del desarrollo del proyecto a los Interesados del caso
• Manejar los aspectos de comunicación que surjan durante el desarrollo
del proyecto.
Las siguientes son las entradas, herramientas y salidas de este proceso

en el que se resaltan primero las entradas como tareas que han debido
ser realizadas antes de establecer los requisitos, métodos y modelos de
comunicación:
100
TABLA 3.3. Planificación de las comunicaciones
10.2 PLANIFICAR LAS COMUNICACIONES

Análisis de Requisitos de Plan de Gestión de las Comu-
Registro de los interesados
Comunicaciones nicaciones
Estrategia de Gestión de los Tecnología de las Comunica- Actualizaciones a los Docu-

Interesados ciones mentos del Proyecto
Factores Ambientales Modelos de Comunicación
Activos de los procesos de la

Métodos de Comunicación
organización
Como un proyecto informático requiere del concurso permanente de los

equipos de trabajo, se necesita conectar en forma confiable y efectiva
a los integrantes del equipo de trabajo para facilitarles el intercambio
permanente de información. La comunicación puede ser un componente
complejo en algunos proyectos pues generalmente envuelve a una gran
cantidad de personas con diferentes enfoques de sus necesidades y con
usos variados de la información y localizados en diferentes ubicaciones.
Existe una fórmula para calcular el número de canales de comunicación

requeridos en un proyecto y es expresada así:
N * (N-1) / 2
En la que N es el número de personas participantes en un proyecto que

requieren, proveen o facilitan la información. En la siguiente figura, el
lector es invitado a tratar de estimar el número de canales de comunicación
para los tres casos presentados de 2, 3 y 4 personas:
2 personas 3 personas 4 personas

CANALES DE COMUNICACIÓN
Figura 3.7. Canales de Comunicación

Si sus respuestas son 1, 3 y 6 canales, los cálculos están correctos. Pueden

haber situaciones en la que nuevos miembros del equipo de un proyecto
sean contratados o que uno o dos miembros sean desvinculados; este tipo
de eventos son comunes en muchos proyectos y es un tema recurrente en
la dirección de proyectos.
Existen situaciones en las que se parte de un equipo inicialmente

conformado para un proyecto al cual luego se agregan o se desvinculan
miembros; se requiere que el o la gerente recalcule el número de canales
de comunicación adicionales o eliminados. Este tipo de situaciones es
fácil de resolver con base en un examen cuidadoso de esta tabla:
TABLA 3.4. Aumentado o quitando canales de comunicación
Escenario: Canales necesarios

El gerente ya está contabilizado (Fórmula: N * (N-1) / 2)
El equipo tiene 4 personas... 4*(4-1)/2 = 6
6*(6-1)/2 = 15 y canales adicionales

Se agregan 2 personas...
= 15 – 6 = 9
Se desvincula 1 persona... 3*(3-1)/2 = 3 y fueron eliminados3 canales
Escenario:
el gerente no está contabilizado
El gerente del proyecto tiene un equipo de 4
5*(5-1)/2 = 10 canales para 5 personas
personas...
8*(8-1)/2 = 28 canales y adicionales

Tres personas se vinculan...
= 28-10 =18
Dos personas se desvinculan... 3*(3-1)/2 = 3, eliminados = 10 -3 = 7
Los métodos de comunicación utilizados para el intercambio de

información entre los interesados en un proyecto, pueden ser divididos en
tres métodos básicos:
1. Interactivo – Facilita un intercambio de información entre múltiples
participantes, promoviendo un común entendimiento entre ellos
2. Lanzar – Distribuye información sin asegurarse que esta sea bien
recibida o comprendida
3. Halar – Provee información desde un centro accesible a múltiples
receptores, como en Internet.
102
En cualquiera de las técnicas o métodos de comunicación que se empleen,

es posible encontrar agentes perturbadores que bloqueen o interrumpan
el mensaje que el receptor está tratando de interpretar del remitente. En el
caso de reuniones de los Interesados con la Gerencia o con miembros de un
equipo de trabajo, es recomendable tener en cuenta las siguientes reglas:
• Toda reunión debe tener un registro en la agenda para darle a las

gentes involucradas una oportunidad para prepararse; la agenda debe
proveer un previamente acordado tiempo a cada tópico que vaya a ser
tratado
• Toda la información a ser tratada en la reunión debe ser distribuida
antes de la reunión
• Los participantes deben revisar la agenda y prepararse para la reunión
• Antes o en la reunión, un líder debe ser nombrado para que conduzca
la reunión; no necesariamente el Gerente del proyecto debe ser el
líder de la reunión
• Cualquier tema que surja o se agregue a una discusión y que no esté en
la agenda, debe ser discutido al final o dejarse para una futura reunión
• Para facilitar el análisis de los temas a tratar, si el proyecto es la primera
prioridad y una reunión ha sido programada, aspectos operativos o
funcionales no deben demorar la reunión.
La estructura de desglose del trabajo

Bajo el enfoque de estudiar todas las posibles estructuras de descomposición
del trabajo pueden existir varias versiones de esta, pero para efectos del
PMP existen solo las siguientes:
• Estructura de descomposición organizacional
• Estructura de descomposición de los riesgos
• Estructura de descomposición de los recursos
• Propuestas de suministros de materiales.
La estructura de descomposición organizacional tiene que ver con la
forma como la estructura de descomposición del trabajo de un proyecto
(WBS en inglés) se integra con la organización responsable del mismo,
según se puede ver en la siguiente figura que describe como un proyecto
de diseño y elaboración de ventiladores, compresores y turbinas se integra
con el plan de cuentas de una empresa de manufactura electromecánica,
siguiendo el patrón de su estructura organizacional:

104
EL WBS Y LA ORGANIZACIÓN
Project
S
Engine Training
S
Fan Compressor Turbine
S
Fan Full Scale Minor Dual Spool
S
Assembly Fan Rig Fan Rig Compressor Rig
S
S
S
Test
S
Mechanical Cost
Design Account
Design
Company
Analytical Cost
Engineering
Design Account
S
Drafting and Cost
Checking Account Work Packages
Mfg
S
S
Figura 3.8. La EDT (WBS) y el Plan de Cuentas de una empresa
Para establecer la secuencia entre las actividades existen varias técnicas y

herramientas que se usan generalmente en forma combinada o en forma
independiente, dependiendo de la complejidad de tareas a ser ejecutadas
o del conocimiento y dominio que se tenga en la forma como se enlazan
entre ellas. El siguiente cuadro detalla las técnicas usadas en estos casos:
TABLA 3.5. Técnicas de diagramación
Métodos de diagramación de precedencias (PDM en

Métodos de diagramación de preceden-
inglés) son habitualmente usados por programas de
cias (PDM en inglés por Precedence
Software. Muestra las actividades en cajas interconec-
Diagramming method)
tadas con otras mediante flechas.
Es una herramienta clave ya que establece el tipo

Determinación de precedencias de relación entre tareas que puede ser Obligatorio o
Discrecional y las relaciones externas de las tareas
Aplicar adelantos y demoras en las relaciones de las

Aplicar adelantos y demoras tareas se emplea para mostrar las duraciones reales de
las múltiples rutas de tareas en un proyecto
Las plantillas se usan cuando estas están disponibles

Plantillas de redes del cronograma
para un determinado proyecto.
Cuando se crea la secuencia de tareas se analiza primero que tipo de

dependencias tienen las tareas entre sí. Las dependencias en términos
generales pueden ser flexibles, es decir su presencia no tiene un impacto
sustancial para el equipo a cargo del proyecto o inflexibles en el sentido
de que su presencia no puede ser ignorada. Existen en la práctica 3
modalidades que motivan las dependencias entre tareas:
TABLA 3.6. Ejemplos de tipos de Secuencia
TIPO DEFINICIÓN EJEMPLO

Una restricción que obliga a que una Hay que descargar un modulo de va-
Obligatorio tarea deba ser terminada antes de que lidación antes de que se prueben las
la subsiguiente pueda empezar rutinas de aceptación de datos
Restricción que debería cumplirse Se ve conveniente terminar todas las

pero que no es absolutamente necesa- pruebas de un sistema antes de co-
Discrecional
ria antes de que las tareas subsiguien- menzar a contactar al usuario para
tes puedan empezar solicitar su aceptabilidad
Una restricción impuesta por algo o La autoridad debe obtener una licen-
Externo alguien externo al equipo del proyec- cia multiusuario antes de entregar el
to o de su organización responsable. modulo de un sistema.

De acuerdo al cuadro anterior, las dependencias entre tareas se originan

por tres razones básicas:
1. Dependencia operativa o técnica, es decir que para ejecutar una tarea,
alguna(s) otra(s) tiene que ser ejecutada(s), total o parcialmente. Esta
es una relación de tipo obligatorio
2. Cumplimiento de regulaciones o leyes. aunque es una relación del
tipo obligatorio, su incumplimiento está en algunos casos sujeto a una
sanción que podría ser reconsiderada
3. Conveniencia funcional. Es de tipo discrecional.
Cuando la secuencia de las tareas es finalmente acordada por el equipo

de trabajo y aprobada por la Gerencia, pasa a ser llamada el cronograma
preliminar del proyecto que resume la duración del proyecto y sus fechas
previstas de inicio y de terminación, amén de otra información que se ira
agregando en la medida que se asignen recursos a las tareas.
Existe un método muy aceptado llamado CPM (Critical Path Method)

que deja claro la trayectoria(s) de ejecución del proyecto y que se puede
analizar hacia adelante (inicio → fin) o hacia atrás (fin → inicio); en
este tipo de análisis es posible descubrir tareas cuyas fechas de inicio y
terminación no puede ser modificadas puesto que ocasionaría una demora
total del proyecto y también es posible detectar otras que tienen holguras
(slack) en el tiempo indicando con ello que sus fechas pueden cambiarse
dentro de ciertos límites sin alterar la duración total.
Una holgura es por lo tanto una cantidad de tiempo que una actividad
puede ser adelantada o demorada sin afectar la fecha de terminación de
todo el proyecto. Si una tarea no tiene holgura entonces es crítica y se dice
que es crítica porque su postergación o adelanto afecta la duración del
proyecto en términos del tiempo.
Una holgura puede ser positiva o negativa puesto que la fecha real de
inicio o de terminación de un proyecto puede ser anterior o posterior a la
fecha programada de inicio o de terminación. Por ejemplo, si un proyecto
está programado para terminar un Mayo 30, 2012 y termina realmente en
Abril 24, 2012, entonces se tiene una holgura positiva de 36 días.
El proceso de secuenciar consiste fundamentalmente en estimar y asignar

duraciones a las tareas y su desarrollo se explica en la siguiente gráfica:
106
Entradas Salidas
Lista de actividades
Estimar
Requisitos de recursos Estimados de las Cronograma
duración de las
Calendarios de recursos duraciones de tareas de las tareas
actividades
Propuesta de alcance
Herramientas y técnicas
• Juicio a expertos
• Estimativo por analogías
• Estimativo paramétrico
• Estimativo por 3 puntos
• Análisis de reservas
FLUJOGRAMA DEL PROCESO DE ESTIMAR DURACIONES A TAREAS

Figura 3.9. Entradas, Herramientas y Salidas del proceso de estimar duraciones
• El estimativo por analogías es recomendado cuando se cuenta con la

opinion de expertos o con información historica extraida y validada
de anteriores proyectos similares, al que se esta estudiando.
• Un estimativo paramétrico o parametrizado se sirve de un modelo
cuantitativo hecho con base en estadisticas de la cantidad de trabajo y
las tasas de productividad y de costos de los recursos a ser empleados.
• El análisis de reservas suele ser empleado cuando el equipo del proyecto
desea planear un proyecto con base en establecer reservas por riesgos
o contingencias plenamente identificados. Esta técnica usualmente
agrega tiempo extra a las duraciones de las tareas estimadas estas a
partir de una EDT preliminar o con base en un estimativo básico.
En la práctica el ejercicio de asignarle una duración a una tarea se realiza

teniendo en cuenta primordialmente la disponibilidad (determinada en
buena parte por los calendarios de los recursos) y por la calidad y cantidad
(requisitos) de los recursos que van a ser responsables de su ejecución. Esta
labor es de plena responsabilidad del gerente y del equipo del proyecto.
El cronograma del proyecto generalmente se representa mediante gráficos.

El cronograma muestra la red de tareas de un proyecto y cómo las diferentes
tareas se interconectan entre sí como resultado de sus secuencias. Existen
en la práctica dos tipos de representación gráfica de las tareas:
1. Diagrama de Barras – las tareas se presentan en barras y las flechas
se encargan de señalar las relaciones de precedencia y de secuencia
entre ellas; es también conocido como diagramas de Gantt

2. Diagramas de redes – la información de la tarea va en flechas y la red

de tareas se presenta empleando dos métodos de diagramación; PERT
y PDM.
Las siguientes figuras ilustran sobre estos dos sistemas de graficar estas
redes:
HAY DOS MÉTODOS DE DIAGRAMACIÓN DE REDES: PERT Y PDM
WBS WBS WBS

1.1.1 1.1.2 1.3.2
(AEF) Diagrama de actividad sobre flecha
WBS
Inicio Inicio
1.2.1
WBS WBS
1.2.1 1.2.1
WBS WBS WBS

1.1.1 1.2.1 1.2.2
(AEN) Diagrama de actividad en Nodo Inicio Fin
WBS WBS WBS

1.1.2 1.3.1 1.3.2
Figura 3.10. Métodos de diagramación de redes de tareas
Observe que en el primer método mostrado de diagramación de la red de

tareas, es necesario dibujar varias flechas convergiendo a más de un nodo
cuando es requerido establecer una relación múltiple entre varias tareas
predecesoras y una sola sucesora. Esto último no es necesario cuando la
red se dibuja con la técnica de Actividad en Nodo pues las flechas en
estos casos se encargan de establecer las relaciones múltiples. La siguiente
figura explica la relación de una WBS con un diagrama de red ya sea
que se construya con la técnica AEF (Actividad en Flecha) o con la AEN
(Actividad en Nodo), a saber:
108
RELACIÓN DE LA EDT CON EL DIAGRAMA DE RED
WBS
1.0
WBS WBS WBS

1.1 1.2 1.3
WBS WBS WBS WBS WBS WBS

1.1.1 1.1.2 1.2.1 1.2.2 1.3.1 1.3.2
WBS WBS WBS

1.1.1 1.2.1 1.2.2
Inicio Fin
WBS WBS WBS

1.1.2 1.3.1 1.3.2
Figura 3.11. Relación de una EDT con el diagrama de red
La técnica conocida en Inglés como PERT (Program Evaluation Review

Technique) no solamente plantea una representación simbólica de la
red, sino que resalta la importancia de unas tareas que por su relación de
precedencia con otras, dan lugar a una ruta cuya duración sumada de las
mismas determina la duración total del proyecto; es llamada la ruta crítica
porque sus tareas no tienen holguras de tiempo, es decir que la diferencia
entre sus fechas más temprana y la más tarde de inicio es cero; al no tener
holgura esta ruta hace que el riesgo de no cumplir con el cronograma del
proyecto apunte en forma significativa hacia esta ruta. Más adelante se
explica en detalle este importante concepto.
Método de la ruta crítica

El metodo conocido como CPM por sus siglas en inglés Critical Path
Method, determina mediante un analisis cronológico hacia adelante las
fechas más tempranas de inicio y de terminación y luego mediante un

análisis hacia atrás, las más tardes de inicio y de terminación de las tareas.
Estos 2 analisis dan lugar al calculo de las holguras de tiempo de las tareas
y al establecimiento de la asi llamada ruta crítica en la que todas sus
tareas tienen holgura cero (0).
Al calcular la holgura se aplica el concepto de fecha más temprana o

más tarde en términos de que no afecta la duración total del proyecto. El
metodo CPM enfatiza la idea de considerar a los recursos como flexibles y
sujetos a ser nivelados a lo largo de la duración del proyecto cuando estos
están limitados o sobreasignados.
Se va a graficar la ruta crítica del siguiente proyecto con base en las

duraciones y las precedencias de sus tareas y aclarando: 1. Una tarea
puede tener varias predecesoras, 2. La longitud de la barra va de acuerdo
a la duración de la tarea, 3. La primera tarea (1) no tiene predecesora
puesto que es la primera en ser comenzada y 4. con la última (código 7)
se termina el proyecto:
Duración en Predecesora
Actividad
semanas es la tarea #
1. Inicio del proyecto 3 -
2. Análisis 4 1
3. Diseño 3 2
4. Construcción y documentación 2 3
5. Transición 2 1
6. Producción 3 5
7. Cierre del proyecto 2 4, 6
Al graficar este proyecto usando la técnica gráfica AEN se produce esta

red de tareas en la que la ruta crítica se han marcado en color gris claro y
las que tienen holguras es decir no son críticas, en gris oscuro: (ver figura
página siguiente).
Observe que las tareas sobre la ruta crítica no tienen holgura y que si se
modifica alguna de sus duraciones o comienzan o terminan en fechas
distintas a las programadas, provoca un cambio en la duración total del
110
Figura 3.12. Diagrama de Gantt.
proyecto. Algunas de estas tareas se pueden descomponer para hacer más

clara la asignación de las tareas a un recurso específico.
La holgura como concepto puede ser aplicado a una tarea o a todo el

proyecto y puede ser positiva o negativa; si un proyecto se programa para
que termine el 30 de mayo y termina realmente dos semanas antes, entonces
tuvo una holgura positiva de 2 semanas. La holgura tiene entonces varias
definiciones como se ve en la siguiente tabla:
Implica determinar lo más tarde que una tarea puede comenzar sin demorar
Holgura libre
la(s) tarea(s) que la sigue(n) en secuencia
Es lo más tarde que una tarea puede comenzar sin que afecte la fecha de ter-
Holgura total
minación del proyecto
Cantidad de tiempo en que algo puede demorarse sin que altere la fecha de
Holgura del
terminación del proyecto. La mayoria de los productos de Software de proyec-
proyecto
tos hacen automáticamente estos calculos.
El siguiente diagrama ayuda a entender el desarrollo de un proyecto

informático tal y como lo podría mostrar una herramienta común de
software para el manejo de proyectos: (ver página siguiente).
Al empezar a estudiar la planeación de las tareas, puede ser también

aconsejable apelar a una facilidad llamada plantillas (templates en inglés)
que traen usualmente muchas herramientas de Software como Project y
que sirven para crear nuevos proyectos con base en modelos de desarrollo
ya probados. Las plantillas deben ser tomadas como ayudas y no como el
único medio para crear la EDT de un proyecto.

Figura 3.13. Diagrama de Gantt producido por un producto de Software
Las plantillas pueden ser muy útiles en la planeación de proyectos

informáticos. La siguiente figura ilustra el uso de una plantilla de Project
como herramienta de computación, denominada Plan de desarrollo de
software, la que se invoca mediante la siguiente serie de pasos:
1. Clic en la opción Archivo
2. luego de clic en la opción Nuevo y
3. clic en la ventana, Planes y
4. luego de un clic en la casilla Negocios
Para que finalmente aparezca este diagrama que se muestra enseguida:
Figura 3.14. Usando plantillas para crear un nuevo proyecto
112
Usando esta plantilla el proyecto nuevo puede ser utilizado como una base
para crear nuevos proyectos informáticos seria semejante al siguiente:
Figura 3.15. Archivo de proyecto creado a partir de una plantilla
En este punto, el usuario puede empezar a modificar las fases, las tareas
y los recursos para acomodarlos a un nuevo proyecto. El archivo que
se crea en este momento esta en formato MS Project o sea que tiene
la extensión .mpp. Existen otra serie de plantillas de MS Project que
pueden ser útiles en diversos proyectos de tecnologías de información
como el de la Implementación de un sistema contable y financiero,
el del Ciclo DMAIC de Six Sigma muy útil en proyectos informáticos
para el mejoramiento de la calidad o el Opciones tecnológicas y
compatibilidad SOX.
Estimar los recursos y duraciones de las actividades

En esta parte se entra a detallar las técnicas para manejar la ruta crítica y
las holguras de un proyecto. Este análisis sirve para establecer mecanismos
para acortar la duración de un proyecto e implica afectar los costos y
la forma de secuenciar las tareas y en forma indirecta tiene que ver con
los recursos disponibles y a ser asignados a las tareas. Los procesos,
entradas y salidas de los dos procesos que en la práctica se ejecutan casi
simultáneamente son los siguientes:

TABLA 3.7. Estimando las duraciones
6.3 ESTIMAR LOS RECURSOS DE LAS ACTIVIDADES

Requisitos de los Recursos de
Lista de Actividades Juicio de Expertos
la Actividad
Estructura de Desglose de
Atributos de la Actividad Análisis de Alternativas
Recursos
Datos Publicados para Actualizaciones a los

Calendario de los Recursos
Estimaciones Documentos del Proyecto
Factores Ambientales

organización
TABLA 3.8. Estimando las duraciones
6.4 ESTIMAR LA DURACIÓN DE LAS ACTIVIDADES

Estimados de la Duración de
Lista de Actividades Juicio de Expertos
la Actividad
Actualizaciones a los
Atributos de la Actividad Estimación Análoga
Documentos del Proyecto
Requisitos de los Recursos de

Estimación Paramétrica
la Actividad
Calendario de los Recursos Estimación por Tres valores
Enunciado del Alcance Análisis de Reserva
Factores Ambientales

organización
Al asignar duraciones a las tareas, es vital primero estudiar los recursos

disponibles pues de su calidad y disponibilidad dependerán estas
duraciones. Al momento de asignar recursos a una tarea se tiene presente
la siguiente ecuación que vincula la duración de una tarea con el esfuerzo
necesario para su realización y la cantidad disponible de recursos:
Esfuerzo o trabajo requerido
Duración =
Recursos asignados a la tarea
114
La cantidad asignada de recursos a una tarea determina el esfuerzo

o trabajo que tomará para desarrollar la misma; esto se denomina
programación condicionada por el esfuerzo. Observe que mientras más
recursos se asignen a una tarea, menor será su duración y que en función
de las asignaciones de los recursos, se calculan entonces los costos de los
recursos y de las tareas (usando la información sobre sus tarifas y costos) y
la cantidad de trabajo planeado y completado.
El diccionario de la EDT
Es conveniente una vez se ha hecho la descomposición total del trabajo
de un proyecto, completarlo con un diccionario de los términos usados
en el mismo y que sirve para explicar en detalle los aspectos claves de
los paquetes o unidades elementales de trabajo. Este diccionario puede
tener diferentes formas de presentación y un ejemplo del mismo se puede
apreciar a continuación:
DICCIONARIO DE LA EDT
Año fiscal 2010 Esta tarea es Repetitiva
2011 No repetitiva
DICCIONARIO DE LA ESTRUCTURA DE DESCOMPOSICIÓN DEL TRABAJO

Elemento WBS No. No. Orden pedido
Persona responsable
Descripción elemento WBS
Cronograma del trabajo WBS - Horas & Costo

Persona responsable Trabajo Cat. Desde Hasta Horas labor ODC Costo material Total
Costo elemento WBS
Figura 3.16. El Diccionario de la EDT

Aunque puede haber diferentes versiones del contenido del diccionario

de la EDT, los elementos más comunes de este son los siguientes, no
estrictamente citados en el orden mostrado aquí:
1. Organización responsable
2. Descripción del trabajo
3. Códigos de cuentas asociadas al proyecto
4. Cronograma de actividades
5. Lista de Hitos
6. Recursos requeridos
7. Estimativos del costo
8. Requisitos de Calidad
9. Criterios de aceptabilidad
10. Información de Contratos asociados al proyecto.
Los hitos o eventos que de acuerdo al equipo de trabajo tiene sentido

resaltar en un proyecto se deben identificar en este momento, pues sucede
con mucha frecuencia que pueden ser utilizados como puntos de control
de un proyecto o porque constituyen momentos en los que se evalúa el
alcance y los logros de objetivos parciales, que a su vez pueden determinar
la interrupción o la pronta ejecución de algunas tareas o la continuidad de
todo el proyecto.
En proyectos de informática sobre todo en aquellos que empleen

metodologías ágiles es común tener hitos al final de períodos de tiempo
muy cortos por lo que llevar a cabo este tipo de revisiones puede volverse
un ejercicio muy dispendioso. Hecho motiva a crear protocolos de manejo
de estas auditorías o controles, muy efectivos en el manejo del tiempo
disponible. En el capítulo 4o. se van a hacer algunas sugerencias sobre el
tipo de reportes aconsejables en estos casos.
Técnicas para comprimir la duración de un proyecto

La necesidad de acortar la duración de un proyecto es muy frecuente
en estos y proviene de diversas razones que el Gerente del respectivo
proyecto debe analizar cuidadosamente. Esta técnica se aplica tanto en
la fase de planeación como en la de ejecución y para ello existen dos
técnicas ampliamente usadas para comprimir o acortar la duración de un
proyecto; una es llamada CRASHING y la otra FAST TRACKING en Inglés.
116
La primera consiste sencillamente en acortar la duración total, asignando

más recursos a una o a algunas tareas de la ruta crítica y la otra se orienta al
análisis de la red de tareas y luego estudiar la posibilidad de ejecutar tareas
en forma simultánea con la mira de acortar la duración de todo el proyecto.
A continuación se va a explicar la técnica conocida en inglés como

Crashing que consiste en asignar mayor cantidad de recursos para acortar
la posible duración de un proyecto. En esta técnica es primordial conocer
la ruta crítica del proyecto a ser recortado y el elemento costo se asume
que no es primordial.
¿QUÉ SE PUEDE HACER CUANDO LA NECESIDAD ES
ACORTAR LA DURACIÓN TOTAL DE UN PROYECTO?
• Acortar la duración total de un proyecto generalmente implica aumentar costos.
• Si no desea aumentar costos, escoja tareas críticas consecutivas en las que es posible aplicar el
traslapo y no tienen recursos compartidos.
• Si el costo no es problema, seleccione aquella tareas críticas que tiene el menor costo por unidad
de tiempo para asignarle más recursos.
• Entre más temprano este ubicada la tareas críticas que acorta la duración total del proyecto, más
oportunidades se tienen de aplicar este proceso varias veces.
• Es posible generar varias rutas críticas aplicando este procedimiento llamado “Crashing”.
Examine el siguiente diagrama y trate de responder la pregunta que aparece al final de la figura.
Figura 3.17. Técnica Crashing para ajustar el cronograma de un proyecto.
La segunda técnica llamada FAST TRACKING consiste en analizar las rutas

de un proyecto e identificar la(s) ruta(s) crítica(s) para con ellas determinar
cuáles pueden ser susceptibles de ser ejecutadas en forma paralela, es
decir simultáneamente con el objetivo puesto en reducir la duración
total del proyecto. Al usar esta técnica es muy posible que se generen
riesgos puesto que el desarrollo de tareas en forma paralela puede generar
adicionales riesgos por la posibilidad de tener que repetir procesos.
El siguiente cuadro resume las ventajas e implicaciones que se generan en

el uso y aplicación de estas dos técnicas:

TABLA 3.9. Ventajas y desventajas de las dos técnicas de ajuste al cronograma
Técnica de Características Implicaciones Implicaciones Otras

compresión claves en el costo en la Calidad Implicaciones
Se aumenta el
Poner más Usualmente se equipo de
Exposición
CRASHING recursos en la incrementan los trabajo y por lo
mínima al riesgo
ruta crítica costos mismo su
manejo
Hacer
Flexible, pero Riesgos Puede
actividades en
potencialmente adicionales como requerir medios
paralelo que
FAST TRACKING puede aumentar consecuencia de de comunicación
normalmente
por posibles posibles adicionales para
aparecen en
reprocesos. reprocesos coordinar tareas.
secuencia
Es de anotar que estas dos técnicas pueden ser usadas en forma

independiente una de otra o en forma simultánea, dependiendo de las
circunstancias y factores que rodeen este tipo de soluciones. El siguiente
cuadro explica los variados procesos concurrentes en la fase de desarrollar
y ajustar el cronograma de un proyecto:
TABLA 3.10. El desarrollo del Cronograma: Entradas, herramientas y Salidas
6.5 DESARROLLAR EL CRONOGRAMA

Análisis de la Red del
Lista de Actividades Cronograma del Proyecto
Cronograma
Atributos de la Actividad Método de la Ruta Crítica Línea Base del Cronograma
Diagramas de Red del

Método de la Cadena Crítica Datos del Cronograma
Cronograma
Requisitos de los Recursos de Actualizaciones a los

Nivelación de Recursos
la Actividad Documentos del Proyecto
Calendario de los Recursos Análisis ¿Qué pasa si…?
Estimados de la Duración de Aplicación de Adelantos y

la Actividad Retrasos
Enunciado del Alcance Compresión del Cronograma
Factores Ambientales Herramientas de Planificación

organización
118
Probabilidad de terminar un proyecto a tiempo

Una vez se tiene una EDT es conveniente realizar un ejercicio que pretende
buscar obtener un estimativo de la probabilidad de terminar un proyecto
en una fecha determinada. Antes de entrar a profundizar en estas materias,
se van a precisar algunos términos, a saber:
Probabilidad. La factibilidad de que algo ocurra. Se evalúa de acuerdo

a una función matemática llamada distribución de probabilidades y se
expresa en fracciones, por ejemplo, 0.05, 0.45 o como porcentajes (33%,
50.98% etc.).
Los análisis tendientes a hacer pronósticos sobre la duración de una tarea

se pueden realizar asumiendo que la duración de las tareas están en un
rango de tres valores todos con una probabilidad determinada por una
función matemática:
1. El pesimista (la mayor duración posible),
2. El optimista (la menor duración) y
3. La duración más probable o esperada.
Es aceptable asumir que en la mayoría de los casos8, la duración de una

tarea sigue una distribución de probabilidades llamada BETA, en el cual el
valor más probable es M, el límite inferior es O (optimista), y el superior es
P (pesimista). La desviación estándar (σ) es una medida de la dispersión de
los datos alrededor de un valor y está dada en este caso por la formula:
σ = (P - O) / 6
Con base en la explicación anterior se puede calcular la varianza (δ2), la

desviación estándar (notación matemática, δ) y la variabilidad del proyecto.
La varianza del proyecto es simplemente la suma de las varianzas de las
tareas críticas (se puede usar aquí el Filtro: Tareas críticas de la herramienta
Project) y la desviación estándar es la raíz cuadrada de la varianza.
Es posible en estos casos usar la herramienta Project, y en tal acaso haga

clic en la barra de herramientas Análisis PERT (Archivo → Complementos
8. Existen tareas que se comportan mejor si se les asigna distribuciones de probabilidad como la de
Poisson o la Triangular Uniforme.

y luego dirigirse a la barra de herramienta) y escriba los valores de las

duraciones optimistas, pesimistas y esperadas de las tareas críticas y luego
cópielas en una hoja Excel similar a la que se muestra aquí:
Tareas Duración Duración Duración Desviación Duración

Varianza
críticas Optimista Esperada Pesimista Estándar probable
Análisis 2,000 3,000 4,000 0,3333 3,0000 0,111
Diseño 2,500 4,000 5,000 0,4167 3,9167 0,174
Construcción y
1,500 3,000 4,500 0,5000 3,0000 0,250
documentación
Transición 1,000 2,000 3,000 0,3333 2,0000 0,111
Producción 1,500 2,000 3,000 0,2500 2,0833 0,063
Valores para el
1,833 14,000 0,842
proyecto
Variabilidad
1,833 ´+/-0,842
proyecto
Los resultados del análisis hasta este momento pueden ser empleados para
concluir que la variabilidad del proyecto es de 14 semanas más o menos
(+/-) 1,833 semanas. El valor 14 semanas de la duración esperada del
proyecto (m) es la suma de las duraciones esperadas de las tareas críticas
(la ruta crítica determina la duración total del proyecto).
Dado que el tiempo de terminación de un proyecto no sigue una distribución

de probabilidades Beta sino una Normal aproximadamente, podríamos
también responder a este tipo de preguntas. Cuál es la probabilidad de
terminar el proyecto en 15 semanas?
La distribución de probabilidades llamada Normal que es aplicable en

estos casos, tiene los siguientes atributos:
• Duración esperada m = 14
• Desviación estándar = 1,833
• Probabilidad de terminar en N semanas Z = (N - m) / δ
Luego la respuesta a esta pregunta es simplemente: (15 - 14) / 1,833 =

0,5455 o sean que son 54,55% las probabilidades de terminar el proyecto
en 15 semanas.
120
NOTA: Este análisis solo se recomienda en proyectos que por su

complejidad y lo fundamental que es culminarlos en una determinada
fecha, hacen supremamente importante tener un estimativo de los riesgos
en alcanzar o no los objetivos a cumplir en un tiempo determinado.
3.2 Administración del costo y de la

calidad en un proyecto
El PMI reconoce en la práctica 4 técnicas básicas para estimar el presupuesto
de un proyecto:
• Estimación Análoga que consiste en estimar una cifra global aproximada
con base en registros históricos de proyectos similares.
• Estimación paramétrica que calcula los costos multiplicando la
cantidad de trabajo por una tarifa determinada, conocida y aceptada
por los directores
• Estimación por tres valores que calcula tres estimativos por cada
actividad del proyecto; estos tres valores se conocen como:
– Valor probable el valor del costo más probable
– Optimista el valor del costo cuando todo sucede como estaba pla-
neado o mejor
– Pesimista el costo cuando acontece en el peor de los casos po-
sibles
• Estimativo Bottom- up o estimativo ingenieril que consiste en
calcular el costo de cada tarea individualmente y luego estos se van
resumiendo en la medida que se asciende a los niveles superiores
hasta concluir en el costo total. En este caso, los paquetes de trabajo
se consideran que están en el fondo de la estructura descompuesta
del trabajo (WBS).
Es muy frecuente en el último caso aplicar procedimientos de ajuste

de los costos en función de las duraciones de las tareas. La curva de
intercambio de tiempo y costo representa un conjunto de programas
factibles para el proyecto: observe que existe un programa de tiempo
mínimo así como un programa de costo mínimo. Solo estos programas
y los que están sobre esta curva y entre los dos puntos extremos, son
programas teóricamente factibles para un proyecto como se observa en
la siguiente figura:

Costo
máximo
Costo
Programa de costo mínimo
mínimo
Tiempo mínimo Tiempo máximo Tiempo terminación del proyecto
Figura 3.18. Balance entre Tiempo vs. Costo
En conjunto, administrar los costos de un proyecto es un proceso que se

desenvuelve en 3 pasos:
1. Estimarlos.
2. Presupuestarlos y
3. Controlarlos.
Y es en este momento que se necesita entender bien los conceptos y

procedimientos de:
• Cómo estimar costos.
• Cómo elaborar el presupuesto de capitales, y
• Cómo entender bien y aplicar controles mediante el análisis del valor
acumulado (o logrado) conocido por las siglas AVA o en inglés EVA
(Earned Value Analysis).
Y a esto cabe agregar el cómo resolver fórmulas matemáticas básicas y

cómo interpretar y manejar todos los conceptos derivados del análisis
de varianzas. El PMI recomienda el empleo de algunos complementos
para calcular los costos de un proyecto ya sea a nivel de una sola tarea
o de un grupo de tareas o de todas estas, y el empleo de herramientas
computarizadas como hojas electrónicas, software de proyectos u otro
software para ayudar a estimar los costos del proyecto.
Una vez se conocen los costos de las tareas se procede a su consolidación

para llegar por ultimo al presupuesto general de los montos de capital
necesarios para la ejecución de las tareas del proyecto. El siguiente
122
paso a seguir es incluir en el presupuesto las así llamadas reservas por

contingencias que se han debido identificar y evaluar previamente.
La siguiente figura resume el siguiente procedimiento que incluye como

primer paso, la asignación de reservas por contingencias de acuerdo a
la clase de respuesta que se decida darle (existen 4 alternativas: evitarlo,
mitigarlo, transferirlo a un tercero, o simplemente eliminarlo) a los riesgos
que han sido plenamente identificados en un proyecto, luego de un análisis
cualitativo y cuantitativo que tiene en cuenta tanto el impacto como la
probabilidad de ocurrencia de cada riesgo.
Observe que después de este paso, las reservas administrativas son

agregadas en segundo término; estas reservas toman en cuenta aquellos
riesgos que pueden suceder pero que no han podido ser identificadas y
mucho menos cuantificar con alguna exactitud:
8. Presupuesto total $740
7. Reserva administrativa $40
6. Costo línea base $700
5. Reservas contingentes $50

(por análisis de riesgos)
$650
4. Costo proyectado
Cuentas de control 1 Cuentas de

3. Cuentas de control $420 control 2 $230
2. Paquetes de trabajo (PT) PT1 $100 PT2 $200 PT3 $120
1. Actividades T1 $40 T2 $50 T3 $80 T4 $30
Figura 3.19. El Presupuesto total del proyecto
Observe también en la anterior gráfica el uso de cuentas de control cuyo

propósito principal es registrar la historia de los costos de una o de un grupo
de tareas para diversos propósitos contables de control. Estas cuentas de

control hacen parte del Plan de Cuentas de la empresa responsable del

proyecto y deben ser plenamente conocidas al momento de calcular los
costos y proceder a elaborar el presupuesto general.
La administración de la calidad
• Incluye todas las actividades de las empresas que desarrollan
proyectos orientadas a fijar políticas de Calidad, establecer objetivos
y responsabilidades de tal forma que estos satisfagan las necesidades
por las que se ejecutan.
• Implanta el sistema de administración de Calidad a través de políticas,
procedimientos y procesos de planeación, aseguramiento y control
de la Calidad, mediante procesos continuos de mejoramiento de las
actividades.
El manejo de la Calidad en estos proyectos es quizás el más fuerte

asegurador del éxito del mismo y se puede contemplar en forma ampliada
mediante el estudio de la siguiente gráfica:
Figura 3.20. La gestión de Calidad
124
Este estudio de la Calidad se reforzara con las explicaciones de varios

términos claves.
¿Que es calidad?
• Calidad es el grado con que un proyecto cumple determinados
requisitos.
• Un elemento importante de la administración de la Calidad dentro
del contexto de un proyecto es transformar las necesidades, deseos y
expectativas de todos los grupos de interés en REQUISITOS a través
de un análisis de ellos que se realiza durante la fase del Alcance del
proyecto.
• La Administración de la Calidad de proyectos debe focalizar tanto la
administración de proyectos, como sus productos finales.
• Cada producto final determina el sistema de Calidad que se empleará.
• Mientras que la administración de la Calidad se aplica a todos los
proyectos, sin importar la naturaleza de su resultado o producto final,
las medidas de calidad y/o técnicas empleadas son especificas del
resultado o producto final que del proyecto se espera.
• Es importante resaltar que de las nueva áreas del conocimiento que
deben ser consideradas en un proyecto según el PMI, la única que por
si sola puede generar todo un proyecto es la de Calidad.
Tres son las actividades básicas concernientes a la Calidad:

1. Planearla.
2. Desarrollar el Aseguramiento de la Calidad.
3. Desarrollar el Control de la Calidad.
Cada una de ellas se explican en forma resumida, de esta forma:

1. Planear: Identificar los estándares de Calidad que son relevantes al
proyecto y cómo satisfacerlos.
2. Asegurar: Aplicar actividades de calidad sistemáticas y planeadas que
aseguren que el proyecto realizará todos los procesos requeridos de
acuerdo a los requisitos.
3. Controlar: Monitorear los resultados específicos del proyecto,
para asegurar que cumplen con estándares de Calidad relevantes,
identificando mecanismos que minimicen o eliminen causas de
realización no satisfactorias.

¿Qué es y no es calidad?
• Es Conformidad a requisitos (el proyecto debe producir lo que dice
que producirá) y a exigencias de uso (el producto o servicio debe
satisfacer necesidades reales).
• Calidad no es dar más – agregar valores o servicios extras no
necesariamente contribuye a adicionar valor o calidad a los entregables
(esta práctica se suele llamar en inglés ¨Gold Plating¨).
• La Calidad debe ser planeada, y no impuesta como un proceso de
inspección.
• El 85% del ¨Costo de la Calidad¨ es responsabilidad de la Administración.
La moderna gestión de la calidad

Este término involucra los siguientes conceptos:
• Exige la satisfacción completa del Cliente.
• Es preferible la Prevención en vez de la inspección.
• Reconocimiento de la responsabilidad de los Administradores en la
Calidad.
• Procesos en fase
• El ciclo repetitivo de Planear-Hacer-Inspeccionar.
Expertos en Calidad que ameritan una mención especial: Deming, Juran,

Crosby, Ishikawa, Taguchi y Feigenbaum.
Existen otros enfoques y metodologías, a saber:

• La Administración de la Calidad Total (TQM).
• Six Sigma.
• Análisis de Efectos y modo de Falla.
• Revisión de diseños.
• La Voz del Cliente.
• Costo de la Calidad (COQ).
• Mejoramiento Continuo (CI).
Para el caso específico de proyectos informáticos (se suele usar la sigla

TIC para denominarlos) es importante tener presente estos conceptos en el
manejo de la calidad:
1. Los requerimientos críticos.
2. Crear una estimación aproximada.
126
3. Aplicación de conceptos de reutilización para mejorar las estimaciones.

4. Determinar el nivel de esfuerzo requerido para ofertar en un proyecto.
5. Uso de las Técnicas Wideband Delphi que fundamentalmente
persiguen es escuchar la opinión de expertos.
En términos generales, es decir, aplicables a todo tipo de proyectos se

pueden considerar estos otros conceptos:
Análisis Costo/Beneficio: El objetivo primario en el cumplimiento de

requisitos de Calidad es disminuir reprocesos y trabajos, lo que redunda
en una mayor productividad, menores costos y mayor satisfacción de los
patrocinadores y clientes del proyecto.
El costo fundamental de cumplir requisitos de Calidad es el gasto asociado

con las actividades de administrar la Calidad del proyecto.
Benchmarking: Equivale a comparar las prácticas reales o planeadas de un

proyecto con las de otros proyectos a fin de generar ideas de mejoramiento
y proveer un estándar con el cual se mida su desarrollo. Este enfoque lo
hace aplicable en proyectos informáticos.
Diseño de Experimentos: El diseño de experimentos (DOE) es un método

estadístico que ayuda a identificar cuáles son los factores que pueden
influenciar variables específicas de un producto o proceso que está en
desarrollo en un proyecto.
Costos de Calidad (COQ): Costos totales incurridos para evitar la no

comformidad a requisitos, por evaluar el producto o servicio a fin de
que cumpla requisitos y por fallas en el cumplimiento de estos requisitos
(reproceso).
Los conceptos Costos de Conformidad y no Conformidad se distinguen

entre sí por estos conceptos:
Conformidad:
• Planeación
• Entrenamiento y adoctrinamiento

• Control de procesos
• Validación del diseño del producto
• Validación de procesos
• Auditorías cortas
• Mantenimiento y Calibración
• Inspecciones.
• Pruebas de campo.
No conformidad:
• Desperdicios
• Reproceso y efectuar reparaciones
• Material adicional o inventarios extras
• Reparaciones por garantía y servicios
• Manejo de quejas
• Juicios por responsabilidad
• Retiro de productos
• Despachos
• Servicios de campo.
Observe la siguiente figura que resalta estos conceptos:

Plan administración de la calidad: Define los
estándares de Calidad que se van a utilizar.
Métrica de la calidad: Define cómo es que algo
seva a hacer y cómo los procesos de control lo
medirán.
Lista de chequeo: Se emplea para asegurar que
ciertos pasos van a ser llevados a cabo o que
ciertas tareas van a desarrollarse dentro de un
proceso general o un proyecto.
Figura 3.21. El Plan de Manejo de la Calidad
Plan mejoramiento de procesos: Detalla los pasos a ejecutar para poder

analizar procesos que facilitarán identificar desperdicios y actividades que
no agregan valor.
• Límites entre procesos.
• Configuración de procesos.
128
• Métrica de los procesos.

• Objetivos para un desempeño mejorado y optimizado.
Para los proyectos informáticos en los que se asume que la metodología de

desarrollo se basa en seguir la siguiente serie de pasos iterativos: Modelar
→ Ensamblar → Puesta en marcha → Manejar, los procesos generales en
los que se estudian y siguen procesos de Calidad, son en términos globales
los que aparecen en la siguiente gráfica:
FLUJO DE REQUERIMIENTOS
Generación Pruebas
Requerimiento Producción certificación
PROCESOS
Diseño
Análisis Modelar Ensamblar
preliminar
Gobernar
Estimación Diseño Manejar Puesta en marcha
preliminar definitivo
Pruebas
Estimación integrales
definitiva SOA
Grupo On-Site
Estimación Estimación Diseño Pruebas Entrega

Arquitectura Desarrollo
preliminar definitiva técnico unitarias versión
Figura 3.22. Flujo de Requerimientos
Es fundamental tener muy presente que en la gestión de la Calidad mientras

más temprano se establezcan mecanismos de planeación y evaluación de
esta, se reduce el riesgo de tener que pagar luego altos costos durante
la elaboración y entrega del producto final. Un diseño preliminar mal
elaborado genera con mucha frecuencia, altos costos y tener que afrontar
reprocesos posteriores.
Línea base de la calidad

Para un proyecto de tecnologías de la información, la línea base registra
los objetivos de Calidad del entregable en términos de su integralidad,

el cumplimiento de requisitos funcionales, el costo y la oportunidad en

su entrega.
3.3 Gestión de riesgos en un proyecto

El manejo del riesgo en proyectos hace recomendable tener ante
todo presente para cualquier gerente de proyectos las siguientes
recomendaciones:
• Todo proyecto conlleva cierta dosis de riesgos por lo tanto es necesario
reconocerlos y estimarlos mediante un proceso que parte de la fase
de planeación, en la identificación, el análisis y en todas las demás
acciones que deben ser conducidas por último en la fase de monitoreo
y control.
• El objetivo fundamental del proceso de estimar y manejar los riesgos
de un proyecto, es incrementar la probabilidad y el impacto de eventos
positivos y reducir la probabilidad y el impacto de eventos negativos.
• Los riesgos pueden provenir de factores internos al proyecto así como
de factores externos al mismo,
Hay diversos factores de riesgo en cada objetivo del proyecto, en sus

entregables y en cada tarea que van desde el inicio hasta la terminación del
proyecto. Aunque al principio se piensa que todos los riesgos son amenazas
con consecuencias negativas o desastrosas para un proyecto, existen
también riesgos positivos llamados oportunidades, que pueden aumentar las
probabilidades de éxito o que pueden ser aprovechadas para ahorrar esfuerzos
o dinero. Con relación a las amenazas y oportunidades en proyectos, es
recomendable entonces tener en cuenta los siguientes conceptos:
• un riesgo puede o no acontecer y su impacto puede ser positivo o
negativo.
• La incertidumbre es la ausencia de conocimientos acerca de un
evento y por lo mismo reduce la confianza en decisiones derivadas de
los datos disponibles.
• los diversos actores de riesgo tienen una probabilidad y un rango
de posibles valores y la función primaria del gerente del proyecto es
evaluarlos cualitativamente y cuantitativamente.
El objetivo de una administración de los riesgos en un proyecto es no evitar

los riesgos completamente sino incrementar la probabilidad y el impacto
130
de los eventos positivos y decrementar la probabilidad y el impacto de los

eventos adversos al proyecto.
El gerente tiene un papel fundamental en estos análisis, y aun cuando se

cuente con personal especializado en estas materias; se requiere un enfoque
proactivo de todos porque ante todo los riesgos no son la causa única del
fracaso de los proyectos. Pueden existir falsas suposiciones acerca de un
riesgo o restricciones que probaron ser falsas o eventos activadores que no
fueron suficientemente analizados y luego probaron ser inocuos.
El proceso comienza con este paso inicial:

• Asegúrese que haya un entendimiento común y un acuerdo del equipo
y de otros interesados en el enfoque y los parámetros que van a ser
aplicados para el manejo de los riesgos del proyecto.
• Determine el Alcance y los objetivos del proceso de gestión de
riesgos
• Defina las actividades de gestión de riesgos, los recursos y preste
atención a que las tareas sean apropiadas al proyecto, ya que
diferentes proyectos pueden requerir diferentes niveles de aplicación
de la gestión de riesgos.
El producto de este paso inicial debe ser documentado, revisado por los
interesados y aprobado formalmente en un nivel superior. El gerente y su
equipo del proyecto deben entonces gestionar los riesgos de un proyecto
siguiendo los siguientes pasos planteados por el PMI, a saber:
• Planear la administración de los riesgos
• Identificar los riesgos
• Analizar cualitativamente los riesgos
• Analizar cuantitativamente los riesgos
• Planear las respuestas a los riesgos
• Monitorear y controlarlos.
En la siguiente gráfica se pretende explicar las entradas, herramienta y

salidas del proceso de gestionar los riesgos teniendo en cuenta que algunos
de los planes elaborados en pasos previos (por ejemplo en la planeación
de las tareas) sirven como entradas en este momento:

Planeación de la Plan de admon. del riesgo

admon. del riesgo
Identificación Registro del riesgo

del riesgo
Análisis cualitativo Registro actualizado de riesgos

del riesgo Registro actualizado
de riesgos
Lista de riesgos
para posterior Análisis cuantitativo
análisis del riesgo
Registro actualizado
Monitoreo y de riesgos Planeación de
control de riesgos respuestas a riesgos
Registro
actualizado
de riesgos
Dirigir y administrar
la ejecución
del proyecto
Figura 3.23. Flujograma de procesos de manejo de los riesgos
En estos temas es conveniente tener muy claros los siguientes conceptos

de los cuales se va dar una detallada y explicita definición que al lector se
le invita a leer y tratar de interiorizar:
RIESGOS: Evento incierto que impacta uno o varios objetivos de un

proyecto. Son inciertos puesto que no podemos estar 100% de su ocurrencia
y aquellos que van en detrimento de uno de los objetivos son llamados
amenazas o riesgo negativo y los que son beneficiosos al proyecto son
llamados oportunidades o riesgos positivos
RESPUESTA AL RIESGO: Las acciones que serán tomadas antes de que el

riesgo tenga lugar para reducir la probabilidad o el impacto de una amenaza
o para aumentar la probabilidad o el impacto de una oportunidad.
CAUSA RAÍZ: El factor que es la fuente o razón del riesgo. Es necesario

conocer la fuente de un riesgo a fin de estar en capacidad de desarrollar
una respuesta; un ejemplo, es el riesgo que puede tener la entrega tardía
de un componente clave de un proveedor y la fuente o causa raíz puede
ser un error en la orden de compras o una súbita tormenta.
132
ACTIVADOR: El signo, síntoma o elemento clave que alerta que un riesgo

es inminente o que es más probable que ocurra. Aunque nunca han sido
fáciles de identificar, si logramos al menos entender el elemento que lo
puede activar, podemos tomar pasos adicionales en su prevención.
PROBABILIDAD: Una evaluación matemática de cuán probable es que

un riesgo ocurra. Tenga presente que el objetivo primario es incrementar
la probabilidad y el impacto de los eventos positivos y decrementar la
probabilidad y el impacto de los eventos adversos al proyecto.
IMPACTO: El efecto que el riesgo tendrá en uno de los objetivos, usualmente

expresado en términos monetarios, de tiempo, de calidad del entregable o
en medidas del alcance del proyecto.
PLAN DE CONTINGENCIA: Acciones que serán tomadas en respuesta al

evento de un riesgo que es inminente o es probable que ocurra. Estos planes
reducen el impacto de un evento negativo o incrementan el impacto de una
oportunidad y son empleados conjuntamente con la respuesta al riesgo.
PLAN SUBSTITUTO: Que acciones tendrán lugar si el plan de contingencia

muestra ser inefectivo.
En la siguiente figura se pueden ver los contenidos básicos de un reporte

de los aspectos ligados a los riesgos que hay que evaluar y controlar en
un proyecto orientado a la producción de un producto informático (ver
página siguiente).
Se observa que en la descripción de los riesgos, se presta atención el asignar

a cada riesgo un DUEÑO(A) para que él o ella sea el encargado(a) de su
manejo y control. Este responsable será el encargado de su detección,
control y de avisar cuando puede presentarse, los activadores del mismo y
de recomendar y adoptar medidas que lo minimicen o eliminen.
Identificar los riesgos

En proyectos informáticos es esencial que la información sea considerada
un activo y como otros activos importantes de un negocio, es esencial para
las actividades de cualquier organización y en consecuencia, necesita una
protección adecuada. Esto es especialmente importante en un entorno de
negocios cada vez más interconectado.

FAVOR SUMINISTRAR CUADRO ESTA TOTALMENTE ILEGIBLE

REPORTE DE RIESGOS
Figura 3.24. El reporte de los Riesgos
134
La seguridad de la información es la protección de la información contra

una gran variedad de amenazas con el fin de asegurar la continuidad del
negocio, minimizar el riesgo para el negocio y maximizar el retorno de
inversiones y oportunidades de negocio. La seguridad de la información
se logra implementando un conjunto apropiado de controles, incluyendo
políticas, procesos, procedimientos, estructuras organizacionales y
funciones de software y hardware.
Existen algunas normas técnicas de calidad que adoptan un modelo de procesos

descrito por los términos: “Planificar-Hacer-Verificar-Actuar” (PHVA), que se
aplica para estructurar todos los procesos de un sistema de información.
La identificación de los riesgos frecuentemente se comienza al emplearse

una técnica conocida como Causa–Riesgo–Efecto que se explica de la
siguiente manera:
• Causa: Eventos o circunstancias que actualmente existen o es seguro
que puedan existir en el futuro y que podrían dar lugar a un riesgo
• Riesgo: es un evento o condición incierto, que en caso de ocurrir,
tiene un efecto positivo o negativo sobre los objetivos del proyecto
• Efecto: Los efectos son eventos futuros condicionales o condiciones
que afectarían directamente uno o varios objetivos del proyecto si se
produce el riesgo asociado.
Es muy práctico en el momento de identificar los riesgos de un proyecto,

usar uno o varios diagramas, entre los cuales cabe destacar los siguientes
acompañados cada uno de un sencillo ejemplo:
Diagrama Causa-Efecto: sirve para mostrar los factores activadores o

causas (triggers) que pueden ocasionar un riesgo o peligro
CAUSAS Categoría A Categoría B Categoría C
Factor 1 Factor 3 Factor 5

Problema
Factor 8 Factor 12
Factor 9
CAUSAS Categoría A Categoría B Categoría C
DIAGRAMA CAUSA/EFECTO O ESPINA DE PESCADO

Flujogramas: muestra las s interrelaciones de los riesgos asociados a ciertos

procesos o tareas,,,
USO DE FLUJOGRAMAS EN PROCESOS CON RIESGO
Tarea A Tarea B Riesgo X? Tarea C
Tarea D
Diagrama de Influencia: sirve para demostrar los factores causantes de un

riesgo al adoptar ciertas decisiones a manera de un árbol de decisión
DIAGRAMA DE INFLUENCIA
Factor B Decisión 2
Resultado
Factor 3
Factor A
Decisión 1
Los estudios elaborados con este tipo de diagramas facilitan después el

descubrir las tendencias y los factores de riesgo que son comunes a muchos
procesos de un proyecto lo que posteriormente puede ser muy útil para
plantear respuestas a cada uno de los riesgos y poder predecir y estimar las
probabilidades de ocurrencia con una mayor precisión.
Note que en los diagramas de influencia no hay un orden en el tiempo

o en otros sentidos de los factores que ahí intervienen (decisiones y
factores que determinan la existencia o no de un riesgo) en un proceso
que está expuesto a ciertos riesgos, dado que lo importante es descubrir
las interrelaciones entre estos.
En proyectos tipo TIC es recurrente la aparición de los siguientes tipos de

riesgos para los cuales un estudio y evaluación cuidadosa, es pertinente
y necesario:
136
1. Alta dependencia de datos de fuentes externas, por ejemplo de bases

de datos sobre las cuales una empresa no ejerce algún control o
participación
2. Un pobre diseño de los modelos de datos
3. Redes internas y externas con alto probabilidad de ser vulneradas o
afectadas; esto incluye redes congestionadas o con altos volúmenes
de transacciones
4. Diseño de la arquitectura del sistema que deja servidores de datos
congestionados o redundantes
5. Protocolos de validación de datos no suficientemente estudiados
6. Suposiciones del sistema que no fueron del todo aceptadas
7. Alta convergencia de modelos de datos con protocolos diferentes
o un alto número de empresas proveyendo tecnologías no del todo
estandarizadas y poco convergentes.
8. Equipo humano con poca experiencia en ciertas herramientas
tecnológicas
9. Los interesados tienen muy diferentes enfoques y expectativas sobre el
entregable.
Una vez se han identificado, evaluado y planteado las diferentes respuestas

a los riesgos, las actividades pertinentes deben ser incorporadas al
cronograma del proyecto.
3.4 Manejo de compras y adquisiciones

En este numeral se explican los procedimientos de compras y adquisiciones
de aquellos elementos de Software y de Hardware necesarios en un
proyecto informático, más los servicios y otros recursos físicos que puedan
ser necesarios para un proyecto de esta naturaleza. Previamente se han
realizado los siguientes procesos:
• Los cronogramas de las actividades
• Establecidos las relaciones lógicas entre las actividades
• Asignados los recursos y estimado las duraciones
• Establecidos los responsables
El problema de contratación es un asunto primordial para el gerente pues

ha de decidir qué bienes y servicios puede proporcionar por si mismo
o adquirir en casa y cuáles puede adquirir por fuera. Un mal contrato

de adquisición puede hacer fracasar totalmente un proyecto y para evitar

mal contratar es conveniente determinar el procedimiento de adquisición,
el cómo conseguirlos, lo que hay que adquirir, la cantidad a adquirir, y
cuando ha de ser adquirido.
Son seis los pasos principales que comprenden la administración de los

contratos:
1. Planeación de compras y adquisiciones que determina qué comprar,
cuándo y cómo
2. Planeación de la contratación que incluye la descripción de los
requisitos de productos o servicios deseados de contratación externa
y la identificación de los proveedores o vendedores potenciales
3. Solicitar las respuestas a los vendedores que comprende obtener
respuestas e información sobre las cotizaciones, ofertas y propuestas
de los proveedores.
4. Selección de los vendedores que incluye elegir entre vendedores
potenciales mediante un estudio y evaluación de estos y la negociación
de un contrato
5. Administración de los contratos que da lugar a las relaciones
contractuales entre proveedores y la gerencia del proyecto
6. Cierre de contratos que incluye la terminación y acuerdo de cierre de
contratos.
EL siguiente diagrama explica la serie de pasos y las entradas y salidas de

este grupo de procesos: (ver página siguiente)
También debe incluir analizar la posibilidad de otorgar subcontratos

potenciales, sobre todo si el gerente quiere ejercer algún grado de influencia
o control sobre las decisiones de subcontratación.
Un proyecto puede necesitar bienes y/o servicios de fuera de la organización

y en algunos casos, al interior de la organización. El plan de gestión de
las adquisiciones es el documento central que expone el enfoque que el
director del proyecto tendrá para adquirir bienes o servicios necesarios en
un proyecto. Es una de las primeras tareas que debe llevarse a cabo porque
los sistemas de organización y gestión del proyecto no podrán fijarse hasta
que no se hace esto. Para ello se analiza:
• Integrar la planificación de las adquisiciones con la programación
general del proyecto.
138
Figura 3.25. Gestión de las compras
• Capacidad del personal existente

• Costo de realizar en casa vs. adquirir mediante un proveedor externo
• Impacto del cronograma
• Demanda futura de habilidades tras finalización del proyecto
• Objetivos y metas de la organización que postuló al gerente
• Protección de la competencia
• Circunstancias especiales
• Efectos potenciales en toda la organización
• Proceso requiere conocimientos que pueden no existir en el equipo
del proyecto
• Proceso puede requerir recursos de afuera del equipo
• Plan de adquisiciones implica frecuentemente tomar decisiones
conjuntamente con otras partes interesadas en la organización, por
múltiples razones.
• El proceso de adquisiciones a menudo requiere asistencia de afuera
del proyecto, y en este caso es muy saludable que las organizaciones
involucradas estén informadas de tal exigencia lo más temprano
posible, especialmente si un ente central de compras se ve necesario.

El plan de adquisiciones es el proceso de identificar lo que el proyecto

necesita y lo que puede mejor adquirirse ya sean productos o servicios de
afuera de la organización. Se trata de decidir cómo se justifica lo que hay
que adquirir, cómo adquirirlos, qué adquirir, cuánto adquirir y cuándo
adquirir. Este plan comprende:
• Descripción de las necesidades, justificación, requisitos y límites
actuales para el proyecto
• Elementos de la declaración de alcance del proyecto:
– Descripción del alcance de proyecto
– Criterios de aceptación del proyecto
– Resultados del proyecto
– Exclusiones del proyecto
– Las delimitaciones.
• EDT
• Diccionario EDT
El componente de descripción de producto y la declaración de alcance

pueden plantear algunos problemas técnicos relacionados con los
productos, servicios y resultados. Plantea estudiar consideraciones de los
riesgos relacionados con la decisión de hacer o comprar e igualmente obliga
a revisar los tipos de contrato, las previsiones con respecto a la mitigación
de riesgos, y en algunos casos cómo transferir los riesgos al proveedor.
La propuesta de Alcance describe los límites del proyecto actual en

lo relativo al esfuerzo de adquisiciones y proporciona información
importante acerca de las necesidades del proyecto y las estrategias que
deben considerarse durante la planeación.
La propuesta de Alcance describe los límites del proyecto actual en

lo relativo al esfuerzo de adquisiciones y proporciona información
importante acerca de las necesidades del proyecto y las estrategias que
deben considerarse durante la planificación.
La declaración de trabajo (SOW por Statement Of Work) como una salida

más del proceso de planeación, sirve en estos casos para describir el tema
de las adquisiciones con el suficiente detalle que permita a los proveedores
potenciales el determinar si son capaces de proporcionar los elementos o
servicios requeridos en un proyecto.
140
La propuesta de Alcance es una base documentada para las decisiones

del gerente en compras futuras y confirma o desarrolla un entendimiento
común del alcance del proyecto entre todos los interesados. En la medida
que el proyecto avance de la fase de viabilidad a la de planeación, puede
cambiar el ámbito de su aplicación. Es necesario que el gerente examine
el contenido de la declaración de alcance en estos puntos:
• Justificación del proyecto: la necesidad del negocio del proyecto
proporciona la base para evaluar futuras compensaciones
• Producto del proyecto: una breve descripción de la descripción del
producto
• Entrega del proyecto: una lista de los elementos principales de cuya
entrega final plena y satisfactoria, determina la finalización del
proyecto
• Objetivos del proyecto: los criterios cuantificables que deben cumplirse
para que el proyecto sea considerado exitoso.
El PMI recomienda que se prepare un plan de gestión del alcance como

un subsidiario del plan de gestión de proyecto. El plan de gestión de
alcance describe cómo se administrará el alcance del proyecto y cómo
los cambios en el alcance se integrarán al proyecto. Debe incluir una
evaluación de la estabilidad esperada del alcance del proyecto, la
probabilidad de cambios, ¿con qué frecuencia y por cuánto tiempo?
También debe incluir una descripción clara de cómo se registrarán los
cambios en el alcance.
Se analizan en este momento los siguientes aspectos:

• Documentación de los requisitos:
– Información relativa a los requisitos que se consideran durante la
planeación de las adquisiciones
– Requisitos con implicaciones legales y contractuales
• Acuerdos de colaboración
• Acuerdos contractuales que definen los roles del gerente y de los
proveedores:
– Señalar que en la planeación de un proyecto, el gerente debe
estructurar el trabajo en pequeños elementos que sean manejables
y a los cuales se les asignará una autoridad específica y respons-
abilidad; o con interfaz mínima analizar la dependencia de otros
elementos permanentes e integrables para que puede verse el pa-

quete total y medible en términos de progreso. El gran paso en el

proceso de planificación después de la definición de requisitos, es
el desarrollo de la WBS del proyecto.
– La EDT (WBS) es el único elemento más importante de la plane-
ación del proyecto puesto que proporciona un marco común para
el proyecto. Está estructurado según la forma como el trabajo se
hará y refleja la forma en que el proyecto, sus costos y datos se
resumen y finalmente cómo se informarán.
– Desde una perspectiva del plan de adquisiciones, la WBS propor-
ciona el marco para identificar paquetes de trabajo coherente para
ser contratado.
• Registro de riesgos que incluye información relacionada con:
• Identificando los riesgos
• Propietarios de cada riesgo
• Respuestas a los riesgos
• El riesgo de las decisiones conexas con el contrato que incluye
acuerdos sobre seguros, fianzas y servicios conexos.
En seguida se entra a explicar el propósito del registro de riesgo y el

papel que desempeña el registro de riesgo en el proceso de planificación
de las adquisiciones. El registro de riesgos identifica los riesgos, las
personas que enfrentan los riesgos y las posibles respuestas al riesgo.
Mediante el registro de riesgos, los miembros del equipo de proyecto
toman decisiones sobre seguros y fianzas con base en las necesidades de
manejo del riesgo.
• Necesidades de recursos de actividad (personas, equipos, ubicación)
• Programación del proyecto
• Estimaciones de costos de actividad
• Línea base de la ejecución del presupuesto.
Durante el proceso de adquisición del plan, los miembros del equipo de

proyecto necesitan evaluar las necesidades de recursos, la planificación
de las adquisiciones, las estimaciones de gastos y costos planeados y su
rendimiento. Con esta información más la de los factores ambientales y
los activos organizacionales, los miembros del equipo de proyecto pueden
crear un plan de gestión integral de las adquisiciones y administrar más
eficazmente el proceso de adquisición.
142
Factores ambientales de la empresa (Enterprise Environment

Factor´s, EEFs)
• Las condiciones del mercado
• La disponibilidad de productos, servicios y resultados
• De quién y bajo qué términos y condiciones
• Términos y condiciones típicas
• Requerimientos locales exclusivos
Activos de procesos organizacionales (Organizational Process A´s,

OPA´s)
• Es conveniente revisar las políticas existentes relacionadas con la
contratación, formales e informales, los procedimientos, las directrices
y los sistemas de gestión para desarrollar el plan de adquisiciones y
decidir los tipos de contrato a emplear.
• Decisiones sobre la forma de contratación
Los factores ambientales de la empresa y los activos de los procesos

organizacionales son dos entradas para el proceso de planificación de las
adquisiciones. Estas son las condiciones externas o internas que influyen
en el éxito de los procesos de adquisición.
OPAs son los activos que influyen en los resultados de un proyecto de

adquisición. Políticas organizativas con frecuencia restringen algunas
provisiones hacia los proyectos. Algunos ejemplos de ello son las políticas
que limitan el uso de órdenes de compras por elementos muy simples,
las compras por encima de un cierto valor y las que obligan a utilizar un
formulario de contrato extenso con requisitos para tipos específicos de
proveedores.
La información de fuentes de proveedores pueden conseguirse de:

• Internet
• Archivos de las adquisiciones
• Listas de proveedor cualificado
• Personal de la empresa
• Otras empresas
• Otros proveedores

• Personal de ventas de proveedor

• Catálogos de proveedor
• Registros y directorios
• Revistas de comercio
• Exposiciones comerciales
• Páginas amarillas
Agencias gubernamentales con frecuencia ponen anuncios en catálogos

oficiales o en las Páginas Amarillas y muchos gobiernos estatales tienen
un documento específico para la adquisición de bienes o servicios para
proyectos estatales.
Las restricciones son factores que limitan las opciones del gerente. En
algunos casos, existen restricciones con factores equivalentes a una
hipótesis que para fines de la planeación de proyectos, sus valores pueden
ser considerados como verdaderos, reales o indeterminados.
Ejemplo: los fondos disponibles y las fechas de financiación de algunas

compras pueden afectar la capacidad para adquirir productos o servicios. Los
protocolos que regulan secretos industriales pueden exigir que ciertos trabajos
se hagan en casa o con ciertas precauciones especiales de seguridad.
Diferentes regulaciones afectan el proceso de contratación, especialmente

cuando se trata de empresas foráneas. Por ejemplo, antes de que terminara
el apartheid, muchas empresas internacionales decidieron no hacer
negocios con empresas sudafricanas. Asimismo, muchos países árabes no
hacen negocios con Israel.
Acuerdos entre sindicatos a veces restringen la capacidad de las empresas

para subcontratar trabajos. El Gobierno de Estados Unidos tiene restricciones
sobre el comercio con diversos países y sobre los aranceles que aumentan
los costos de las importaciones y exportaciones entre algunos países.
También, las empresas tienen políticas relativas a los términos y contenidos,

repetitivos y condiciones en contratos que guían al administrador de un
proyecto, entre ellas.
• Fondos disponibles
• Confidencialidad y seguridad
144
• Cultura
• Acuerdos de negociación colectiva
• Incentivos y restricciones del Gobierno
• Términos y condiciones.
1. Plan de adquisiciones es el proceso de identificación que proyecto
necesita puede mejor cumplirse por la adquisición de productos o
servicios desde fuera de la organización. Se trata de decidir si de-
sea adquirir, cómo adquirir, qué adquirir, cuánto adquirir y cuándo
adquirir.
2. Incluye consideraciones de los riesgos relacionados con cada
decisión de hacer o comprar. Finalmente incluye la revisión del
tipo de contrato, previsto para ser utilizado con respecto a la miti-
gación de riesgos, a veces la transferencia de los riesgos para el
proveedor.
3. Revisar las entradas, herramientas, técnicas y salidas.
• Debe equilibrarse el costo mínimo y el papel de la organización en
consideraciones específicas de un proyecto
• Estimación del costo de producir internamente
• Estimativos de los costos asociados con proveedores potenciales
Hacer o comprar es una combinación de análisis económico y financiero

y es una estrategia del negocio. El concepto es simple: para cada bien
o servicio que tiene el potencial para ser adquirido o hecho al interior,
existe un equilibrio entre su precio y el costo para la compañía y para un
proyecto con consideraciones específicas.
Se realiza una estimación del costo de producción del producto o servicio

internamente, y esto se compara con la estimación de gastos recibida de
potenciales proveedores del producto o servicio. Tener presente que si el
costo fuera el único criterio, la elección sería sencilla.
• Ventajas de Hacer:
– Menos costoso?
– Fácil integración
– Capacidad existente de uso
– Control directo
– Secreto
– Evitar problemas con un proveedor
– Evitar problemas morales.

• Desventajas de Hacer:
– Más costosa?
– Puede llevar más tiempo para completar el proyecto
– Requiere recursos adicionales para construir la solución
– Mayores costos de adquisición de producto
Ejemplos sencillos de adquisiciones incluyen hacer vs. comprar,

arrendamiento vs. compra, o leasing vs. alquiler. Hay que tener en cuenta
que es mejor comprar si se reduce significativamente los costos del
personal interno, o si hay beneficio al obtener disponibles los productos
en un menor plazo o si se mejoran las capacidades internas o si brinda
avances tecnológicos para la empresa dueña del proyecto.
Hay que tener en cuenta que es mejor hacer al interior si se quiere evitar
depender de proveedores externos, asegurar que no se presente algún
problema moral o de interrupción para el personal interno o del sindicato,
aprovechar un exceso de capacidad interna inactiva, lograr un control
directo o mantener un secreto de diseño y producción.
En esta toma de decisiones, hay que tomar en cuenta los criterios

fundamentales de la contratación expresados en:
• La capacidad del proveedor para proporcionar los productos necesarios
y servicios necesarios.
• La viabilidad financiera potencial del proveedor para garantizar la
entrega de los productos.
• La calidad de los productos comprados.
• Los términos y condiciones bajo las cuales se adquieren los
productos.
• Las preferencias del Departamento solicitante.
Para determinar si se va a hacer o comprar, hay que comparar los costos

internos y los del externalizarlos. Para ello, hay que establecer una
base del costo de mano de obra y del material necesario para sostener
la función internamente e incluir los costos adicionales necesarios para
futuras mejoras, actualizaciones, expansiones, etc.
Al estudiar una posible subcontratación, habría que determinar los ahorros

del personal en términos del trabajo que se contrata, qué ahorro se hace
146
del trabajo y el porcentaje de tiempo dedicado a la función. Hay que tener

también cuidado con una posible transferencia de costos - si un costo
no es totalmente eliminado, solo va a aparecer finalmente en otra parte.
Recuerde que solo obtener un ahorro de los costos no debe ser siempre un
objetivo en forma sistemática:
• Elabore una lista de los bienes y servicios necesarios
• Realice un análisis de costos si la organización del gerente hace el
trabajo
• Obtenga ofertas de proveedores
• Complete la lista de comprobación
• Tome la decisión de “hacer o comprar”
Los análisis de Hacer o comprar no son ejercicios triviales. Pueden ser

muy complejos y hay que hacerlos con suma precisión.
Métodos de valoración de inventarios de existencias son importantes a

considerar, en particular el tratamiento de la sobrecarga y las transferencias
de bienes o servicios entre divisiones. Es importante comparar manzanas
con manzanas al obtener ofertas de diversos proveedores. En algunos
casos, métodos de valoración del ciclo de vida de algunos productos a ser
adquiridos pueden ser muy necesarios, sobre todo en el caso de productos
con ciclo de vida tecnológicos muy cortos.
Los factores cualitativos también deben considerarse para decidir qué

productos y servicios se suministrarán internamente y cuáles por los
proveedores. Estos factores son evaluados cuidadosamente y evite en lo
posible hacer cambios en estas decisiones una vez el proyecto está en
progreso ya que pueden provocar retrasos significativos y aumento de los
costos, así como poner en peligro el logro de los requisitos de calidad.
La finalización de la lista de comprobación es parcialmente subjetiva y en

parte objetiva. A menudo las decisiones de compra se realizan con un solo
criterio. La lista de comprobación ayuda al gerente del proyecto a tomar
decisiones más equilibradas y es una buena idea anotar todos los criterios
que se van a tener en cuenta al decidir, similar a la siguiente:
• La decisión siempre debe estar basada en conocimientos en un área
de aplicación, área de conocimiento, disciplina o industria.
• Puede ser proporcionada por un grupo o una sola persona

• Juicio de expertos técnicos

• Juicio de expertos en compras
• Juicio de expertos en temas jurídicos
• Estos expertos podrían ser:
– Personal del mismo proyecto
– Otras unidades de la organización ejecutante
– Consultores externos o internos
– Organizaciones de profesionales y técnicas
– Grupos o asociaciones industriales.
La opinión de un experto es a menudo una buena base para encontrar

y desarrollar normas y especificaciones. La experiencia acumulada por
fuera en la adquisición de un tipo concreto de producto o servicio puede
ser muy útil. El gerente puede tener en cuenta además:
• No pasar por alto cualquier individuo o grupo que tenga conocimiento.
• Utilice ejemplos de su experiencia propia e incluya personas de la
organización que han trabajado en proyectos similares y de personas
que han gestionado proyectos en la misma área técnica.
• Acudir a diversa literatura como publicaciones del PMI, las asociaciones
privadas de administración de contratos y los organismos estatales y
privados para compras de bienes y servicios; todos generalmente tienen
un sitio web con información disponible sobre muchos aspectos de la
contratación.
El gerente podría eventualmente preguntarse si su organización utiliza

personas ajenas a esta función. Durante la contratación del plan de
compras, es importante considerar el mejor tipo de contrato para el
proyecto ya que el tipo de contrato tiene un impacto grande en la calidad,
costo y programación del proyecto.
Otra importante tarea de planificación que debe llevarse a cabo temprano

en el proyecto es la selección de los tipos de contratación a utilizarse,
especialmente para los principales contratos. Enfoques de contratación son
seleccionados al mismo tiempo que se determinan el número y el alcance
de los contratos individuales. Los tipos de contratos seleccionados tienen
un impacto significativo sobre la organización y el control necesarios
para el proyecto y en riesgo. La programación del proyecto es también
directamente afectada por el tipo de contrato seleccionado.
148
Puede utilizarse una cierta variedad de enfoques en la adquisición de

bienes y servicios para un proyecto. Muchos administradores de proyecto
no reconocen la importancia de evaluar correctamente el tipo de contrato
que es mejor para una situación particular. Si se selecciona un enfoque
equivocado, pueden producirse problemas graves que afecten la calidad,
costo y programación del trabajo realizado.
Tipos de contrato de compras usados en proyectos

Las principales inquietudes del gerente en este momento giran alrededor de:
• ¿Cuántos contratos tendrá el proyecto?
• ¿Cuál es el alcance de cada contrato?
• El número y el alcance de los contratos y su:
• Impacto en la organización del proyecto
• Impacto en los sistemas de gestión
• Necesidad de crear interfaces de administración
• Debe ser coordinada.
Después de que se determina cuales son las adquisiciones del proyecto

principal a ser realizadas internamente y cuáles no, la administración
determina el número y el alcance de los contratos individuales. Las
decisiones sobre el número y el alcance de los contratos individuales
pueden tener un impacto significativo sobre la organización del proyecto
y los sistemas de gestión.
Cada contrato adicional importante sobre un proyecto crea interfaces de

administración adicionales que deben coordinarse adecuadamente. El
alcance de cada contrato individual debe definirse de manera que sea
compatible con el alcance del trabajo realizado por otros grupos y por
otros proveedores del proyecto.
En algunas organizaciones se establece una posición de “Gestor de

subcontratación” que informa al jefe de proyecto y le colabora en esta
área compleja, guiado por estas consideraciones generales:
• Los proveedores locales son generalmente más fáciles de controlar
• Analice si los proveedores tienen suficientes recursos internos
• Considere si los proveedores tienen suficientes capacidades técnicas
• La misma organización que prepara especificaciones de compras, es
la responsable de la adquisición de materiales.

Una decisión de tener más de un contratista de ingeniería responsable del

diseño de un proyecto, por ejemplo, crea automáticamente un número
de diseño de zonas de interfaz que pueden ser algo complejas en su
naturaleza. Contratistas de ingeniería local pueden ser preferibles para un
proyecto debido a su experiencia en trabajos similares y la proximidad del
personal a la ubicación del proyecto.
Es posible contratar con una firma local para realizar las partes de un
diseño porque tiene la experiencia en el ámbito nacional, y con grandes
empresas de ingeniería para realizar el diseño de partes más complejas
de un proyecto. Evalué si un contratista único tiene suficientes recursos
internos para realizar todas las funciones de diseño de un proyecto.
Evaluar si los grupos internos tienen la capacidad para realizar ciertas tareas
de diseño específico. Con frecuencia es mejor contratar tareas específicas
de diseño de un proyecto con personal de ingeniería interno porque tienen
una mejor comprensión técnica que la del personal contratista externo en
diseños similares.
Hay ciertas ventajas en tener la organización responsable de preparar

las especificaciones, también ser responsables de la adquisición de la
ingeniería de materiales y equipos descritos en las especificaciones. Esto
es debido a la necesidad de comunicación considerable entre el grupo que
especifica la ingeniería de materiales y equipos y el grupo que adquiere
estos elementos.
¿Cuáles son los más importantes factores en una organización al decidir el

tipo de contrato? La respuesta la da el examen de la siguiente tabla:
TABLA 3.11. Tipos de Contrato y definiciones
Tipo de contrato Definición

El gerente y proveedores se ponen de acuerdo sobre un precio estable-
Precio fijo
cido para un producto o servicio claramente definido
El gerente rembolsa al proveedor todos los costos incurridos y paga

Costos reembolsables
una tasa adicional como ganancia para el proveedor
Gerente rembolsa el proveedor los gastos incurridos e incorpora

Tiempo y materiales incentivos basados en tasas de rendimiento y en otros conceptos ne-
gociables
150
Se utiliza para presentar alguna información sobre distintos tipos de

contratos como la correcta elección del tipo de contrato es una decisión
estratégica vital que influye en el seguimiento y resultado de la ejecución
de los contratos posteriores.
El contrato de precio fijo (siglas en inglés FFP) coloca el riesgo total del
proyecto en el proveedor. Por lo general reflejan conocidos productos y
servicios que cuentan con varios sustitutos y documentación adecuada.
El de costos reembolsables (sigla en inglés, CPFF) pone la mayoría del

riesgo en el gerente. El gerente reembolsa al proveedor a costos razonables
para promover la pronta entrega de estos productos y servicios, lo que
hace el CPFF la elección adecuada en muchas situaciones. Pueden haber
cláusulas de incentivos para compartir los costos entre el gerente y el
proveedor por los riesgos que implica.
La correcta elección del tipo de contrato debe ajustarse a las características

del proyecto que se considera. Las discrepancias entre los tipos de contrato y
proyecto obstaculizan los jefes de proyecto en su flexibilidad para administrar
y supervisar la ejecución de los contratos y también limitar la ejecución del
proyecto. La elección del tipo de contrato realmente importa.
El contrato de precio fijo consiste en establecer un precio fijo total para un

producto definido o servicio.
1. Contrato de precio fijo firme (FFP)

• Más comúnmente utilizado y favorecido por grandes organizaciones
• Precio de los bienes establecido desde el principio y no sujeta a
cambios a menos que cambie de ámbito de trabajo. Pueden tener
varias variantes o tipos:
1. Contratos de una cuota incentivo (FPIF) al precio fijo. Ofrece al
gerente y al proveedor cierta flexibilidad que permite la desvia-
ción del rendimiento, con incentivos financieros ligados al logro
de ciertas cuotas medibles de acuerdo a una métrica
2. Precios fijos con contratos de ajuste por precio económico (FP-
EPA). Se utiliza cuando el período de ejecución del contrato por
parte del proveedor abarca un número considerable de años

3. Precio fijo pero disposición especial que está atada a índices finan-
cieros y protege tanto el gerente y el proveedor de resultados que
están formalmente más allá de su control.
• Un contrato de precio fijo requiere que un proveedor entregue los
bienes o servicios especificados por un gerente a un precio fijo. Es el
negocio más sencillo y más común de precios. El gerente es responsable
de proporcionar una definición completa de lo que se necesita y de
cuándo es necesario. El proveedor incluye una estimación de sus
costos y de su beneficio en un formato de precio fijo. Si los costos
del proveedor son inferiores a los costos incluidos en su precio, el
proveedor gana ganancias adicionales. Si los costes del proveedor son
más que los que se incluyen en su precio fijo, se reduce la ganancia
del proveedor. Estos se denominan precio.
• En un contrato de precio fijo, el proveedor corre con el riesgo
financiero y por lo tanto generalmente espera un mayor margen de
ganancia. El proceso de cambio de contrato suele ser bastante formal
ya que los proveedores están dispuestos a continuar sin cobertura del
contrato. Por lo tanto, si el contrato estipula que al proveedor se le
pagará $10.000 por un producto después de su entrega y en una fecha
específica, y los gastos del proveedor son solo $6.000, el proveedor
tiene un beneficio de 4.000 dólares en el proyecto. Pero, si los gastos
son $11.000, el proveedor tiene una pérdida de $1.000.
• Largo para determinados proyectos de duración, los proveedores
pueden ser reacios a asumir el riesgo de precio de salario y material
costos de nivel de escalamiento en los contratos de precio fijo. Si
incluye un subsidio para futuros salarios y costos de material de
escalada en sus estimaciones de precio fijo, son conservadores en
la estimación de lo que será esta escalada ya que ganará menos
beneficios si sus estimaciones son demasiado bajos. El gerente que
reconozca este hecho pueden tener el precio fijo en la puja citó al
salario actual y tipos de materiales con disposiciones para ajustar el
precio fijo basado en el aumento real de los salarios y los precios
de los materiales. Disposiciones de escalada nivel de precio de
mano de obra y materiales con frecuencia están vinculadas a índices
gubernamentales publicados para trabajo y tipos de materiales.
• Implica pagos (costo reembolsable) al proveedor para todos los gastos
legales y reales por el trabajo completado, además de una tasa de
ganancia del proveedor.
152
2. Costo más contratos de tarifa fija (CPFF)

• El Proveedor es reembolsado el valor de todos los gastos permitidos
• Proveedor recibe un cuota fija de pago calculado como un porcentaje
de los costos del proyecto estimados inicialmente
3. Costo más contratos de tarifa de incentivo (CPIF)

• Proveedor es rembolsado por todos los gastos permitidos para realizar
la labor de contacto
• Recibe una cuota predeterminada de incentivo basado en lograr
ciertos objetivos de rendimiento
Existe una variedad de la anterior conocida como Contrato de costo más

tarifa de premio que reúne estas características:
• Proveedor se reembolsa los gastos legítimos por compartir un logro
medible
• La mayoría de los honorarios se ganan solamente basado en la
satisfacción de ciertos criterios de amplio rendimiento subjetivos por
parte del gerente
• Generalmente no esta sujeta a apelación.
• El proveedor se compromete en un costo reembolsable con un
contrato de pago de incentivos para proporcionar bienes y servicios
especificados por el gerente de los costos reales del proveedor además
de una cuota basada en el rendimiento. Los incentivos de rendimiento
más comúnmente utilizados en los contratos son para la programación,
la calidad y el costo de rendimiento. Cuotas de incentivos pueden
combinarse con honorarios fijos.
• Contratos de gastos reembolsables se utilizan donde es difícil de
preparar una declaración definitiva de trabajo, como por ejemplo
cuando se requiere el trabajo de desarrollo y existe poca o ninguna
experiencia en que basar la estimación de costos.
• En los contratos de gastos reembolsables, el proveedor lleva el riesgo
financiero ya se reembolsarán los gastos del proveedor.
Los tipos y cantidades de cuotas de incentivos se especifican en un contrato

de pago de incentivos. La base para evaluar el logro de los incentivos de
rendimiento puede definirse en el contrato, o después de la adjudicación

del contrato, cuando se han desarrollado los programas necesarios para

evaluar el rendimiento.
Los principales factores que se consideran para decidir si utilizar tarifa

reembolsable más incentivo contratos son la probabilidad de que los
incentivos trabajando para beneficio de las partes y la posibilidad de
negociar un acuerdo de incentivo eficaces. A veces se denomina costo
más honorarios incentivos contratos, CPIF.
Muchos creen que los costos de contratos reembolsables son más convenientes
para las empresas que tienen altas incertidumbres de altos costos.
Tipos de acuerdos contractuales híbridos

• Útil para cubrir algunos gastos rembolsables y de honorarios fijos
• Utilizado a menudo para el mejoramiento o perfeccionamiento de
habilidades del personal, adquisición de expertos y otro tipo de apoyo
externo
Son utilizados cuando:

• Los incentivos por rendimiento están equilibrados
• Se quiere que el logro de objetivos pueda ser evaluado en mejor forma
• Es importante para que rápidamente se haga una adjudicación.
Es importante en estos casos, revisar los componentes claves de un contrato

de tiempo y materiales y discutir la naturaleza híbrida del tipo de contrato
y sus similitudes con el precio fijo y contratos basados en incentivos. Esto
ayuda a estudiar situaciones en las que los contratos de tiempo y materiales
pueden tener más sentido para una empresa.
Los beneficios de los contratos híbridos son:

• Relación mejorada entre los beneficios y los objetivos del proyecto
• Rendimiento del proyecto se mejora
• Mejor uso compartido de los riesgos
• Mejor evaluación del desempeño y de las acciones correctivas
Otras consideraciones a ser tenidas en cuenta:

• Tiempo requerido para la planificación, negociación y la administración
154
• Mayor equidad y confianza entre el gerente y el proveedor

• La medición del desempeño en términos subjetivos
El propósito fundamental de los incentivos es motivar un rendimiento

deseable en una o más áreas específicas. El principal beneficio es una
relación directa entre los objetivos de lucro y los del proyecto, que resulte
en una ejecución mejorada del proyecto. Los objetivos del proyecto y los
riesgos se discuten durante las negociaciones del contrato y se incorporan
a la estructura de los documentos del contrato.
Las evaluaciones de rendimiento de un contrato hechas en momentos

predeterminados del proyecto (se emplea también el término medio punto
o hito) apoyan los planes de acciones correctivas y refuerzan los requisitos
del proyecto. El proveedor muy probablemente indague sobre el nivel de
satisfacción del cliente con el desempeño que conduzca finalmente a un
mejoramiento de la comunicación.
Sin embargo, estos contratos requieren más tiempo para ser planeados,
negociados y administrados y la medición del desempeño para establecer
las cuotas premio es subjetiva y unilateral. La equidad, mutua confianza
y acuerdos de conformidad con el proceso son importantes en este
momento.
Estos contratos están diseñados para compartir los riesgos del proyecto
y la recompensa entre el gerente y un proveedor. Los incentivos pueden
aplicarse al progreso medido durante el proyecto y proporcionan una
excelente oportunidad para un examen de las medidas correctivas, si se
requieren. Se distinguen dos tipos de criterios los que se pueden clasificar
en dos grupos: objetivos y subjetivos así:
TABLA 3.12. Incentivos y criterios objetivos y Subjetivos
Tipos de Ninguna
Recompensa Sanciones
incentivo acción
Costo Bajo presupuesto Sobrepresupuesto Sobrepresupuesto
Cronograma Completar pronto En el tiempo Completar finales

Objetivo
Se reúne con
Calidad Supera el contrato Bajo contrato
contrato

Incentivos y
Supera Logra A continuación
premios cuota
Subjetivo
Otros Supera Logros A continuación
Riesgo/Beneficio Desincentivo Incentivo

- Descontando eliminado con
éxito de la ejecución
Tarifas con descuentos si no
Tasa de descuento - Honorarios suspendido en
cumplen los criterios
una fase de condicional sobre
acuerdo para proceder a una
fase posterior
Tarifa reducida si no logra Honorarios vinculados al nivel de

Ganancia compartida
beneficios logros alcanzados
Honorarios reducidos si no logra Honorarios aumentan beneficios

Entrega de beneficios
beneficios logre aumento
Resultado de malos resultados en Éxito recompensado por el

Aventurarse
baja o sin equidad aumento en valor de equidad
Muchos proveedores han construido su reputación en proyectos exitosos

pero la reputación también se pierde por proyectos fallidos. Los riesgos y
los beneficios son inherentes en cualquier relación contratante y el mismo
gerente del proyecto incluso puede introducir factores de riesgo/beneficio
específicos y negociables en el proyecto.
Aquí, los criterios de progreso exitoso o fallido o de la entrega son

explícitamente declarados y acordados. Estos criterios pueden incluir
plazos de entrega, calidad de los productos, la satisfacción del cliente y
el logro de los beneficios pactados y pueden ser al final del proyecto o al
momento de registrar un determinado progreso.
Podrán haber clausulas de descuentos de tarifa o sobre cómo compartir

los riesgos y el proveedor puede acordar reducir o eliminar las tarifas, o
podrá establecer condiciones en algunos criterios que midan el avance o
éxito. Compartir la ganancia es de hecho una limitada participación en los
beneficios. Es el cliente quien direcciona los beneficios esperados, tales
como reducción de costos o ganancias y cómo compartir una parte de la
ganancia con el proveedor.
156
El desafío consiste en ponerse de acuerdo sobre la línea de base y los

objetivos del proyecto. Si la ganancia compartida es un componente
significativo del pago al proveedor, el cliente y el proveedor tendrán un
gran interés en el resultado y en la precisión de la medición. La entrega de
un beneficio se refiere a la filosofía de que si el cliente gana, o si gana el
proveedor. Se requiere un mecanismo apropiado y una fórmula clara.
El aventurarse puede ser otra opción explícita en este tipo de contratos y

así el proveedor pasa a convertirse en un socio en igualdad de condiciones
con el proyecto, al establecerse un contrato tipo joint venture por separado.
Puede haber un intercambio de equidad que incluya el esfuerzo, lo cual
puede ser apropiado para entregas de bienes o servicios críticos por su alto
riesgo o porque abarcan varios años.
También se pueden combinar estos enfoques en diferentes contratos.
Riesgo y tipos de contrato

Esta figura proporciona una gama de tipos de contrato de acuerdo al
riesgo. Tenga en cuenta ese tiempo y que los contratos de provisión de
ciertos materiales típicamente involucran mayores niveles de riesgo para
los gerentes.
REEMBOLSO DE LOS COSTOS
Alto Bajo
TIPOS DE CONTRATOS Y RIESGOS
Riesgo del Gerente TIEMPO Y MATERIALES Riesgo del Proveedor
PRECIO FIJO
Bajo Alto
Figura 3.26. Riesgos distribuidos entre la Gerencia y los proveedores según tipo de contrato

3.5 Gestión de concursos y cotizaciones

Es realmente muy raro en la actualidad encontrar proyectos del área de la
teleinformática que se ejecuten y terminen por completo usando recursos
exclusivamente locales de una empresa. Lo corriente es que se formen
equipos de trabajo con programadores tanto internos como externos,
hardware alquilado y propio y con empresas de servicios variados para
realizar estos proyectos.
Incluso gigantes de la industria como Microsoft e Intel™ suelen contratar

empresas independientes en diversos países para probar los nuevos
productos que lanzan al mercado.
Este numeral se concentra en el estudio de los temas alrededor de

la gestión de contratar a empresas externas, mediante concursos y la
presentación de cotizaciones, mostrando las ventajas y desventajas de
así hacerlo y luego rematando con una discusión sobre las mejores
prácticas para elaborar los contratos para posteriormente colaborar con
ellas en el desarrollo y terminación de un proyecto. Se complementa
este tipo de pasos con un análisis del proceso de la negociación y
de las técnicas para resolver los desacuerdos y tratar de alcanzar
soluciones óptimas.
En ningún caso se pretende que el lector salga después de leer este

numeral convertido en un ejecutivo totalmente diestro en estas materias
pues la verdad es que estas habilidades no se adquieren propiamente de la
lectura de un libro como este, sino más bien llevando cabo proyecto con
un espíritu abierto y sereno recordando siempre que lo único constante en
la vida de los proyectos son los cambios.
Outsourcing (Tercerización)
Este término se ha aplicado a la transferencia de funciones y de procesos
de un negocio a otras empresas, muchas de ellas extranjeras. Por ejemplo
cuando alguien compra un ¨router¨ de comunicaciones de x marca, es
posible que hable con un técnico de servicios de la empresa fabricante
que se encuentra en Chile o en Puerto Rico, para solicitarle una asistencia
o requerir un servicio sobre la garantía.
158
La contratación externa se usa ahora para contratar segmentos importantes

del trabajo de un proyecto; para ello observe no más la siguiente figura
para que se dé cuenta de la gran variedad de procesos derivados de un
proyecto que se pueden contratar con agentes externos:
Empresa de Proveedores de
mercadotecnía Bases de datos
Administradores
de redes
Fabricantes de
Proyecto Hardware
TIC
Paquete de
Software aplicativo Administración
de proyectos
Empresa de Abogados
publicidad
Figura 3.27. Posibles contrataciones para un proyecto TIC
Muchos proyectos contratados con entes externos operan en ambientes

virtuales en los que las personas están vinculadas mediante computadoras,
faxes y sistemas de diseño asistidos por computadoras, por lo que raras
veces se ven cara a cara. En muchos proyectos las personas van y vienen
conforme se necesitan sus servicios, en forma parecida a una organización
estructurada por funciones pero no son miembros formales de una empresa,
sino expertos técnicos que han formalizado alianzas temporales con una
organización. Una vez cumplen sus funciones contratadas se mueven a
otros proyectos.
Las ventajas de la contratación externa de una parte del trabajo de un

proyecto son muchas, entre ellas:
1. Reducción de costos: las empresas pueden asegurar precios
competitivos para los servicios contratados, en especial si el trabajo
puede contratarse en el extranjero. Además los costos fijos se reducen
en forma dramática porque la empresa contratante ya no tiene que
mantener al interior los servicios contratados.
2. Terminación más rápida del proyecto: al contratar a personas expertas
en ciertas materias se hace más rápida la entrega, dando lugar

igualmente a más resultados por cada unidad de pago efectuada.

Adicionalmente la contratación externa puede brindar acceso a
equipos más eficientes y productivos. Ejemplo: se pueden contratar 3
ingenieros de software por el precio de uno estadounidense.
3. Alto nivel de experiencia: la empresa que contrata determinados
servicios ya no tiene que mantenerse al día con los avances tecnológicos
y en lugar de ello puede focalizarse en desarrollar otras competencias
del negocio al contratar empresas que poseen el conocimiento en
segmento relevantes del proyecto
4. Flexibilidad: las organizaciones ya no se limitan por los recursos
disponibles sino que buscan una amplia de proyectos en los que
combinan sus recursos con los de otras empresas. Las empresas
pequeñas pueden perfectamente volverse globales al trabajar con
socios extranjeros.
Las desventajas de contratar trabajos con una empresa externa son:

1. Fallas en la coordinación: esta coordinación tan vital en muchos
proyectos informáticos puede ser desafiante en especial si el proyecto
requiere de una alta y estrecha colaboración y ajustes continuos
2. Pérdida de control: puede haber una cierta pérdida del control sobre
el proyecto; el equipo central depende ahora de otras organizaciones
sobre las cuales no tiene autoridad alguna lo caul puede afectar en
gran medida el desempeño de todo el proyecto
3. Conflicto: un proyecto que contrata buena parte de sus trabajos
con entidades externas puede estar más propenso a conflictos
interpersonales al no compartir todos sus integrantes los mismos
valores y prioridades. La confianza mutua tan importante en proyectos
puede deteriorarse en estos casos
4. Temas morales: la contratación foránea de un trabajo puede afectar
la moral interna de la empresa contratante sobre todo cuando este
trabajo contratado ya se ha hecho en el pasado.
Aunque pocas personas discrepan de la afirmación que el beneficio

económico al contratar por fuera sea la principal razón para tercerizar,
hay algunas que discrepan de este concepto y exponen otros motivos
como la capacidad de colaborar y de trabajar estrechamente con colegas
más experimentados. Existe eso sí una base de estudios suficientes sobre
las mejores prácticas que faciliten emplear el outsourcing o tercerización
160
como un mecanismo valido en el mundo contemporáneo, que se refleja

en esta serie de siete prácticas, a saber:
1. Requisitos y procedimientos bien definidos
2. Capacitación extensa y las actividades de construcción de equipos
3. Procesos de manejo de conflictos bien establecidos
4. Revisión frecuente y actualizaciones permanentes del desempeño de
los proyectos
5. Ubicación compartida cuando es necesaria
6. Contratos justos y con incentivos claros y generosos
7. Relaciones de contratación externa a largo plazo.
Los requisitos y procedimientos bien definidos se refieren a que si las expectativas

y los requisitos no están claros o si están sujetos a debate, esto hace muy
complicado el proceso de contratación con entidades externas. Las empresas
exitosas son muy cuidadosas en la selección del trabajo a ser contratado y con
mucha frecuencia solo contratan para productos predeterminados, claramente
definidos y con resultados bien medidos y mensurables.
Por ejemplo, una compañía que desarrolla productos de Software solo contrata
a otras empresas para que prueben sus productos y les informen de sus fallas y
posible correcciones, muchas veces con cláusulas de reserva y privacidad.
No solo se deben especificar los requisitos del trabajo (incluyendo los

mecanismos de seguridad) sino que también se tienen que integrar los
trabajos con los procesos de administración del proyecto, estableciendo
los procedimientos y la terminología a emplear de modo que las dos partes
puedan trabajar armoniosamente.
La capacitación extensa y las actividades de construcción de equipos es

estar permanentemente actualizando al personal para que este a la par
de los funcionarios del ente externo a ser contratado. La capacitación es
extremadamente importante cuando se tiene que interactuar con personas
de diferentes empresas y culturas y es una forma de ir construyendo la
confianza mutua entre una empresa y sus socios externos.
Se suele usar talleres de construcción de equipos con funcionarios claves

de las empresas involucradas y en algunos casos, las empresas encuentran
útil contratar a consultores para que diseñen y desarrollen esos talleres,
cuya duración depende de la experiencia, compromiso y habilidades de

los participantes. Estas sesiones se deben cerrar con una especie de acta
firmada por todos los participantes, que exprese las metas comunes del
trabajo a realizar en el proyecto y los procedimientos para alcanzar los
objetivos del mismo.
Los procesos de manejo de conflictos bien establecidos son necesarios pues

hay que aceptar la idea de que en casi todos los proyectos son posibles los
conflictos, debido a que las personas participantes pueden tener distintos
valores y prioridades. El ascenso es el mecanismo más utilizado en estos
casos y consiste en tratar de resolver un problema en el nivel más bajo de
su ocurrencia y dentro de un plazo de máximo 24 horas.
Si esto no ocurriese entonces es llevado al siguiente nivel administrativo

superior hasta que finalmente se encuentre una solución. Permanecer
inactivos en este tipo de situaciones no es nada aconsejable.
La revisión frecuente y las actualizaciones permanentes del desempeño de

los proyectos implican estar permanentemente revisando los estándares
de evaluación del desempeño de los equipos de trabajo y se hace no
solo analizando los indicadores de costo, tiempo, calidad y esfuerzo
sino también el grado de colaboración entre miembros de los equipos de
trabajo que incluyan personas de otras empresas.
Esto brinda un foro para identificar problemas en un proyecto y poder

resolverlos observando como se hace el trabajo en equipo, la facilidad de
comunicación y la resolución oportuna de problemas. Muchos de estos
foros acuden a encuestas online entre los integrantes de estos equipos
Igualmente la ubicación compartida cuando es necesaria es quizás una

de las formas más empleadas para superar las fricciones entre miembros
de un equipo pues facilita un alto grado de interacción para coordinar
tareas, resolver problemas y formar un vínculo común. La ubicación del
equipo de trabajo en un solo sitio es crucial en muchos proyectos lo que
vale la pena por encima de otras consideraciones como su costo y otros
inconvenientes menores.
Su papel es menos importante cuando se trata de trabajos independientes

que no requieren de un alto grado de colaboración; lo mejor en estos
casos es dejar una reserva para el transporte esporádico.
162
Al disponer de contratos justos y con incentivos claros y generosos

se despeja el camino para tratar a todos los integrantes de los equipos
de trabajo en igualdad de condiciones. Contratos de personal cuya
remuneración está atada al desempeño se han vuelto muy comunes en
proyectos y estas deben ser vinculadas a las prioridades y objetivos del
proyecto; por ejemplo si el alcance de un proyecto es lo crítico se pueden
establecer bonos por exceder las expectativas de desempeño.
Asimismo los contratistas podrán estar sujetos a penalizaciones si se

detecta un desempeño apenas estándar o por no cumplir los plazos de
vencimiento o cuando se sobrepasa el tope del presupuesto asignado.
Las relaciones de contratación externa a largo plazo tienen que ver con el
desempeño exitoso que se logra cuando los contratos cubren un período
de tiempo largo. Un estudio reciente indica que actualmente las grandes
y medianas corporaciones en los Estados Unidos entran en al menos 30
alianzas en comparación con menos de tres a principios de la década de
los noventa.
Se ha comprobado que las ventajas de tener alianzas a largo plazo son:

1. Costos administrativos más reducidos
2. Uso más eficiente de los recursos comunes al contratante y al
contratista
3. Mejor comunicación entre las dos partes
4. Mejorada innovación
5. Mejor desempeño general de estos contratos.
La evaluación de cotizaciones y de precios presentados por diferentes

oferentes al momento de presentarse a un concurso es un tema que
esta fuertemente atado a las diferentes formas, políticas y esquemas de
contratación de cada empresa y que también depende del sector económico
en el que se presenta.
Estos aspectos deben ser analizados durante el proceso de planificación

de los contratos en donde se establece la descripción de los productos y
servicios deseados o necesarios para un proyecto informático, y que van
a ser adquiridos mediante el mecanismo de la contratación externa, la
identificación de los proveedores o vendedores potenciales.

Los resultados de este ejercicio se registran en las solicitudes de compra

(siglas en inglés RFP de Request For Providing) o de contratación de
servicios (RFQ por Request For Quotation) y los criterios con que van a ser
juzgadas las cotizaciones una vez se considere que cumplen los requisitos
exigidos.
La historia de todas las solicitudes de compra o de cotizaciones hace

parte del registro del proyecto y esto es parte del material que alimenta
y luego se analizará en la sección de historias aprendidas al final y cierre
del proyecto.
Una vez se cierra el ciclo de las contrataciones, estas se documentan y se

llevan igualmente al registro histórico del proyecto.
La fase de planeación se considera que se termina en este momento y se

procede entonces a registrar el plan línea de base del proyecto que esta
pronto a ser ejecutado.
164
Capítulo 4 • Ejecución y control
Capítulo 4
Ejecución y control
La ejecución y el control de un proyecto comienza una vez se ha aprobado

el plan general del mismo y se ha creado la así llamada Línea de base (en
inglés baseline). En este momento se han completado los requisitos y los
pasos de la fase de planeación y se esta listo para comenzar la fase de
ejecución del proyecto que casi en forma simultánea abre el proceso de
su control, que en términos algo simplificados se reduce a comparar el
desempeño tangible y medible con el plan con la idea de identificar las
desviaciones, evaluar los cursos de acción alternativos existentes y tomar
las acciones correctivas que sean encontradas como viables y efectivas.
Los ejemplos y casos citados en esta fase se van a mostrar contando con el
respaldo de la herramienta de Microsoft Project de la cual se van a explicar
los procedimientos empleados exclusivamente en la fase de seguimiento.
Todas las explicaciones dadas en los numerales 1.6 y 1.8 relativas a la
variable Tarifa y la herramienta Project en este momento son aplicables,
pero no sobra de nuevo su lectura y la revisión de algunos conceptos.
Después de lograr la aprobación del proyecto y antes de empezar a

ejecutarlo, se usa la opción Proyecto de Project y luego clic en el ícono

Establecer línea base del menú principal (Set baseline en inglés) para
guardar el plan base del proyecto. La figura que aparece al aplicar esta
opción es esta:
Project copia toda la información guardada hasta este momento en los

campos respectivos que se distinguen de los originales por el calificativo
adicional previsto, por ejemplo el campo Duración prevista corresponde al
de Duración, el costo previsto guardará el valor de la variable Costo total, etc.
La ventana Establecer línea de base que se activa, se muestra en la Figura 4.1.
Figura 4.1. Guardar Plan base con Project
166
Un plan base puede ser cambiado e inclusive ser borrado del todo en
Project, pero en la práctica se recomienda que esto solo se haga a través
de un mecanismo formal de aprobación de cambios, tal como lo aconsejan
las directrices del PMI en la parte del Control Integrado de Cambios. Un
número elevado de cambios a un plan base daría lugar a preguntarse si la
fase de planeación se hizo en buena parte en forma descuidada.
Los pasos del seguimiento y control de un proyecto para medir y evaluar

su desempeño, son los siguientes:
1. Establecer o ratificar los mecanismos y los períodos de evaluación del
trabajo realizado
2. Medir el progreso de las tareas que de acuerdo al cronograma fueron
ya comenzadas
3. Comparar el plan contra lo que realmente fue ejecutado en términos
tangibles y
4. Tomar acciones correctivas o no de acuerdo a las variaciones del plan
contra lo tangible.
4.1 Ejecutar y controlar el plan del proyecto

Este grupo de procesos es fundamental para el desarrollo de estrategias y
de planes para el manejo de los siguientes procesos de ajustes por parte de
los integrantes del equipo de trabajo:
1. Manejo de procedimientos para ajustar la programación de las tareas
de acuerdo con los objetivos y el alcance establecido al proyecto
2. Utilizar mecanismos para crear y enviar reportes de avance del proyecto
así como el reporte debido al comité de Control de Cambios
3. Solucionar problemas de remplazo o sustitución de los recursos y su
efecto en la programación de tareas
4. Distinguir y usar indicadores de avance y de meta, y otros mecanismos
para el seguimiento y control.
Procedimientos de reporte y ajustes de la programación

El programa de red del proyecto o cronograma es generalmente empleado
como el punto de partida para el estudio de esta fase, el cual se compara
con el desempeño real. En estos casos es muy utilizado el diagrama de
Gantt que se complementa con otro llamado Gantt de seguimiento para
rastrear y registrar el desempeño del proyecto.

El diagrama Gantt de seguimiento que se muestra mediante la opción

Tareas y luego con un clic en la lista de vistas al extremo izquierdo, trae
dos barras longitudinales por cada tarea; una para el plan previsto (la barra
inferior en color gris normalmente) y la otra para la ejecución real, como
se puede apreciar en la siguiente figura 4.2:
Figura 4.2. Gantt de seguimiento
Si la barra superior (la ejecución) de una tarea no coincide exactamente

con su barra inferior (la del plan) significa que ha habido un adelanto o
un atraso en las fechas de comienzo o de fin programadas de esa tarea;
si esto ocurre en una tarea de la ruta crítica, ocasionará un atraso o un
adelanto de todo el proyecto. Los adelantos o atrasos en una ruta pueden
deberse también al remplazo de un recurso durante el desarrollo de una
tarea o a una revaluación del trabajo pendiente durante la ejecución de
una tarea.
Preliminares del reporte de avances

Actualizar la información del proyecto es quizás la parte que más trabajo
toma durante su desarrollo. Formal y teóricamente hablando se puede
empezar a reportar esta información una vez se aprueba y se guarda el
plan base. Es importante registrar todas las novedades de las variables que
van a servir para el seguimiento del proyecto para que los cálculos arrojen
resultados que reflejen la realidad lo mejor posible y para ello se va a
hacer un repaso de algunos conceptos vistos antes.
168
En el capítulo 1 se explico la forma de crear con Project la variable Tarifa

y quedo pendiente de cómo podía ser insertada con otras variables para
exportarlas a Excel; de inmediato se pasa a explicar el procedimiento para
mandar a esta herramienta los valores de estas variables para allí elaborar
la gráfica de seguimiento mencionada en el numeral 1.6. Lo siguiente debe
ser tenido en cuenta en este momento:
1. Por cada punto de control, los valores que son útiles de las 4 anteriores
variables, son los que se calculan para todo el proyecto.
2. Los cortes o puntos de control se reportan usando la variable de Project,

fecha de estado que es un campo que esta asociado al proyecto y no
a las tareas.
3. Como la fecha de estado es un atributo del proyecto, es necesario

guardar sus valores en un nuevo campo personalizado como tipo
fecha que luego va a ser incluido en una nueva tabla de tareas que
además comprenda los 4 campos mencionados antes. Los valores de
estos cinco campos se van a exportar finalmente a Excel
4. Una vez exportados estos datos a Excel, ver la figura 1.22 en la página
51, posteriormente se clasifican de acuerdo a los cuatro escenarios
descritos en el numeral 1.6.
Se va a comenzar este proceso, moviendo el campo fecha de estado a una

nueva tabla de tareas que posteriormente se explicará cómo se crea; por el
momento se siguen estos pasos:
1. Seleccione la opción del menú principal Proyecto y
2. Dar clic en Campos personalizado y en la ventana que se abre dé

clic al botón Tarea luego clic al de Tipo y de la lista que se despliega
seleccione Fecha. Escoja el campo Fecha1 o el que primero esté
disponible y luego clic en el botón Cambiar nombre… para indicar
que va a cambiarle el nombre
3. Escriba fecha de corte como nuevo nombre de este campo. Observe

esta ventana en la página siguiente:

Figura 4.3. Cambiando el nombre al campo Fecha de corte
170
4. Luego se regresa a la anterior ventana y ahí se indica: Fórmula apa-

reciendo una nueva ventana en la que se indica Campo → proyecto →
Fecha y luego se selecciona el campo Fecha de estado. La ventana que
finalmente aparece es similar a esta:
Figura 4.4. Asigna la fecha de estado como valor del campo Fecha de corte
Una vez creado el campo fecha de corte bajo el dominio de tareas, se

pasa a crear la nueva tabla que va a incluir la fecha de corte más los
cuatro campos mencionados antes; el procedimiento es muy sencillo y
básicamente es seguir estos pasos:
1. Clic en la opción Archivo, luego clic en Tareas y luego en Vistas para
finalmente indicar con clic la opción de más tablas...

2. En la siguiente ventana se indica el nuevo nombre de esta tabla

que puede ser a voluntad del lector o sencillamente use Tarifa_
ControlSeguimiento y finalmente seleccione de la lista de campos, los
que aparecen indicados en esta gráfica:
Figura 4.5. Creando una tabla de seguimiento
3. De por último clic en el botón Aceptar.
El proceso indicado nos ha servido para crear el campo Fecha de Corte y

luego vincularlo al contenido de una nueva tabla, cuyos contenidos deben
ser enviados a Excel en cada fecha de control periódicamente para ir así
llenando los datos con los que finalmente se podrá obtener una gráfica
similar a la que aparece en la Figura 1.22 de la página 54.
Solo resta en este ejemplo, llevar estos datos a Excel y para ello se puede
seguir un proceso relativamente sencillo de Project que consiste en poner
primero visible en una vista de tareas (diagrama Gantt por ejemplo) la
nueva tabla, luego hacer que se guarde un archivo tipo Excel (Archivo →
Guardar como...) lo que provoca que se active un asistente que después
de una serie de pasos fáciles de seguir genera una sesión en Excel con la
información de la nueva tabla.
Se invita a que el lector lo haga, apoyándose con el ejemplo número 1 que

viene en el apoyo de unos ejemplos de esta obra.
172
Reporte de los avances

El mecanismo más sencillo de reportar el progreso de las tareas se basa en
la variable Porcentaje completado, que al momento de reportarse genera,
automáticamente, una serie de cálculos que afectan duraciones, fechas,
costo y trabajo de las tareas. En este libro no se explicará este método pues
aunque es muy simple su uso, no es del todo recomendable puesto que
no asegura que el % de avance este de acuerdo con medidas mucho más
efectivas del trabajo realizado.
El mecanismo del que si nos valdremos para reportar la ejecución es el

de reportar el número de horas que realmente ha trabajado un recurso
en una tarea especifica. Este mecanismo consiste en reportar, para cada
recurso que participa en una tarea, el trabajo –en horas o en porcentaje del
asignado– que realmente ha realizado en una tarea. Este procedimiento es
recomendable cuando en una tarea participan varios recursos y cada uno
tiene claro cuánto esfuerzo debe realizar en esta.
El procedimiento se puede realizar acudiendo a la vista de Uso de tareas

(Task usage) y haciendo clic al recurso al que se le va a reportar una
determinada cantidad de trabajo ejecutado. En este momento se despliega
la ventana mostrada en la Figura 4.3 en la cual se selecciona la casilla
Seguimiento (Tracking).
Figura 4.6. Información de la asignación de un recurso a una tarea

Observe que en esta ventana es posible reportar el avance, tanto en horas

como en porcentaje del trabajo asignado a un recurso en una tarea. Project
se encarga de convertir este reporte en un porcentaje de avance total de
la tarea respectiva. El procedimiento justo explicado no es el único pues
existen otras maneras de hacerlo.
Existen otra serie de formas para el reporte del avance, apropiadas para
ciertos tipos de tareas de un proyecto. Persiguen por un lado evitar los
conflictos que surgen cuando los dueños de algunas tareas adoptan puntos
de vista algo subjetivos en cuanto a la cantidad de trabajo que se hecho
realmente en una tarea y por otra parte, toman en cuenta el balance entre
el costo y el tiempo asignado a una tarea.
Al final del capítulo 1º., en el numeral de narración de algunas opciones

de la planeación flexible (Rolling wave) se hizo una mención especial
para ciertas tareas cortas en duración o de bajo costo. Para este tipo de
tareas más aquellas que tienen una larga duración pero cuya ejecución
se puede fraccionar en un número pequeño de cortes del trabajo que se
esta haciendo, es posible aplicar las siguientes tres reglas, de las cuales las
dos primeras apuntan a las tareas cortas y la última a las tareas de larga
duración y con pocos cortes, a saber:
1. Regla 0/100: todo el crédito del trabajo realizado solo se asignará

cuando la tarea es totalmente terminada. Por lo tanto todo el valor
presupuestado solo se contabilizará a la terminación de toda la tarea.
2. Regla 50-50: este enfoque se aplica de tal forma que el 50% del trabajo
realizado se acredita cuando la tarea apenas comienza y el resto o sea
el otro 50% cuando la tarea respectiva se declara terminada. Es muy útil
cuando la tarea es de muy corta duración y su costo es también muy bajo
3. Porcentajes de terminación con puntos de control ponderados:
combina porcentajes de terminación estimados con puntos de
control muy supervisados y ponderados; es apropiada para tareas de
larga duración y con un número pequeño de puntos de control. Por
ejemplo, una tarea con un presupuesto total de $1.000 se va a reportar
fraccionada en tres puntos de control que representan el 30%, el 50%
y el 100% del presupuesto total asignado, por lo que el costo del
trabajo realizado se hará en valores que no pueden sobrepasar de
$300, $500 y $1.000 respectivamente. Los puntos de control sirven
como mecanismo que posibilita evitar cálculos un tanto optimistas.
174
Mostrar el avance
Una de las formas quizás más sencilla pero menos usada para observar el
avance de un proyecto en el tiempo es mediante las, así llamadas, Líneas
de progreso, que consisten en una representación visual del progreso de
un proyecto mostrada en una vista como la de Gantt y con respecto a una
determinada fecha de control.
Al ser mostrada, Project dibuja unas líneas transversales que conectan las
barras de las tareas que están siendo ejecutadas con una línea vertical que
señala la fecha de control; si una línea transversal aparece a la izquierda
con respecto a la fecha de control, indica que la tarea va atrasada con
respecto a la fecha de control y si aparece a la derecha señala que va
adelantada respecto a la misma fecha.
Esta opción se puede activar dando clic en la opción Project o de Tarea

del menú principal, luego haciendo clic en Formato y luego en el botón
Líneas de progreso:
La distancia horizontal de los picos hasta la línea vertical indica el grado

de adelanto o de atraso con relación a la programación establecida en
la fecha de progreso; si es a la izquierda significa un retraso y si lo es a
la derecha, un adelanto. En la vista que se despliega, se señala la opción
Líneas de progreso (Progress line). Note que las líneas de progreso se
pueden mostrar con relación al plan real o con respecto al plan previsto,
como se muestra en la Figura 4.4 (ver figura página siguiente):

Figura 4.7. Las líneas de progreso
Al ejecutar los pasos anteriores se obtiene la siguiente vista de las líneas de

progreso de un proyecto:
Figura 4.8. Muestra de líneas de progreso
En esta clase de diagramas es conveniente resaltar visualmente la fecha de

estado y para ello sirve seguir este procedimiento asumiendo primero que
el usuario se encuentra en una vista de tareas de Project:
1. Clic en la opción Proyecto y luego clic en la opción Formato.
2. Enseguida hacer clic en la opción Cuadricula que aparece a la
izquierda y luego seleccionar la opción Cuadricula...
176
3. En la ventana que se muestra a continuación seleccionar la variable

Fecha de estado dentro de la lista de variables que aparece a al
izquierda y enseguida escoger el tipo y color de la línea que señalará
la fecha de estado.
La ventana en la que se le da formato a esta fecha es similar a ésta:
Figura 4.9. Formato de la fecha de estado
En la práctica, el método más recomendable para evaluar el trabajo de los

recursos y el manejo del presupuesto consiste en mostrar los indicadores
de seguimiento establecidos por el PMI y a los cuales el autor propone
agregar la variable Tarifa descrita en el capítulo 1. Algunos de estos
indicadores ya fueron mencionados y explicados en el mismo capítulo
1 y la lista completa de indicadores sugeridos para el seguimiento de un
proyecto es esta:
Tabla 4.1. Indicadores usados en la fase de seguimiento y ajuste de un proyecto
Nombre Fórmula Interpretaciones

Presupuesto para terminar el Es el presupuesto
Es el total del presupuesto planeado a
proyecto (Budget At aprobado como
su terminación
Completed = BAC) línea base
el costo total del proyecto a su
Estimado al Terminar (EAC =
BAC / CPI terminación si se sigue al ritmo actual
Estimate At Completed)
de gasto
Negativo si esta sobrepresupuestado y
Varianza de costo (CV) EV – AC
positivo si se esta por debajo
Negativo si esta atrasado y positivo si
Varianza del cronograma (SV) EV – PV
se esta por delante del cronograma.

¿Cuánto se logro en $ por cada $1 gas-

Índice de ejecución de costos
EV / AC tado? Fondos están o no siendo usados
(CPI)
eficientemente
Índice de ejecución del cro- ¿A qué % se está ejecutando el proyec-

EV / PV
nograma (SPI) to con relación a lo planeado?
Usado cuando varianzas del BAC no

han ocurrido o se prevé continuar
gastando a la misma rata.
Costo real + el estimado actualizado
BAC / CPI
Estimado a la terminación del trabajo restante (trabajo de consul-
o
(EAC) tores).
AC + ETC
NOTA: es posible obtener este valor
acudiendo a estudios por parte de
empresas externas que evalúan lo
realizado y lo pendiente.
A partir del actual momento, ¿cuánto

Estimado para terminar (ETC) EAC – AC más costará el proyecto hasta su cul-
minación?
Varianza a la terminación ¿Cuánto por encima o por debajo del

BAC - EAC
(VAC) presupuesto se estará al final?
Si se usa la herramienta Project es conveniente tener presente que algunos

de estos indicadores pueden tener denominaciones distintas de las que
emplea el PMI. Para aclarar esto se muestra a continuación la siguiente
tabla de equivalencias usables en estos casos:
TABLA 4.2. Equivalencia de los indicadores
Indicador Campo equivalente en Project

Valor planeado acumulado (PV) CPTP
Valor real acumulado (AC) CRTR
Valor acumulado (EV) VA (CPTR)
Varianza de costo (CV) VC = EV - AC
Varianza del cronograma (SV) VP = EV - PV
Índice ejecución de costos (CPI) IRC = EV / AC -> Índice rendimiento de Costos
Índice ejecución del IRP = EV / PV -> Índice rendimiento de la programación o

cronograma (SPI) cronograma
Costo previsto calculado para una tarea o grupo de tareas o
Total presupuestado (BAC)
para todo el proyecto
178
Se calcula generalmente con la fórmula: BAC / IRC, pero se

advierte que esta solo es aplicable cuando se asume que el
Estimado a la terminación
proyecto va a seguir marchando con la proyección calculada
(EAC)
hasta ahora. Existen otros enfoques que se analizan posterior-
mente.
Estimado para terminar (ETC) Se usa la fórmula: EAC - AC
Varianza a la terminación
Se calcula con la fórmula: BAC - EAC
(VAC)
NOTAS
1. En los casos de indicadores que en forma predeterminada Project no
trae, se han sugerido métodos para calcularlos.
2. Todos estos indicadores se pueden calcular y mostrar para todo el
proyecto o para un grupo de tareas o para una simple tarea, haciendo
posible el examen de todo el proyecto o de una parte del mismo.
Sobre esta base, el procedimiento de uso de esta serie de factores

consiste en:
1. Haga clic en la opción del menú Vista y luego escoja dentro de la lista
de opciones disponible la opción Más tablas… usando esta ventana:
2. Seleccione Indicadores de costo del valor acumulado en esta lista de

tablas y luego haga un ajuste con un doble clic de los encabezados de
las columnas que sean necesarias para ampliar su contenido.

La información que aparecerá será semejante a la siguiente:
Figura 4.10. Vista de valores acumulados
A esta vista de indicadores es fácil agregar otros indicadores de seguimiento

como el sugerido por el autor al introducir el concepto de Tarifa en el
capítulo 1.
Este análisis quedaría incompleto si no fuese posible registrar y generar

gráficas de seguimiento de un proyecto en las que rápidamente se puedan
estudiar la forma como el proyecto se va desenvolviendo a lo largo de
su cronograma. En este momento la herramienta Project no es del todo
suficiente y se necesita del concurso de Excel, dada su alta capacidad de
crear gráficas. El papel de Project se ve reducido simplemente a proveerle
los datos a Excel en estos casos.
La siguiente es un ejemplo de una gráfica típica del proceso de seguimiento

de un proyecto:
Gráfica de seguimiento del costo y cronograma
$500 125%
$400 100% EAC

$350 85% AC
BAC
$300 75% CV PV
SV
$200 50% EV
$100 55%
Duración del proyecto Final programado

10 20 30 40 50 60 70
Figura 4.11. El seguimiento del costo y del cronograma
180
Las variables valor real, valor planeado y el ganado se identifican con las
letras AC (actual cost), PV (planned value) y EV (Earned value); se observa
que la variable EAC señala la proyección que se hace del costo real a la
terminación del proyecto si se sigue al ritmo actual y que BAC indica el
valor planeado al final del proyecto. También se ve que la varianza del
costo esta indicada como CV (cost variance) y la varianza del programa es
SV (schedule variance).
Como la variable CV es igual a EV - AC entonces es negativo su valor al

igual que la SV puesto que su formula es EV – PV. Valores negativos en
ambas variables indican una situación alarmante en este proyecto; observe
igualmente que la duración del proyecto se ha extendido dado que la
varianza en la terminación (VAC) es negativa (BAC – CET).
Este tipo de gráfica se conoce como curvas S por su forma peculiar.

Existen otras variedades de esta clase de gráficas como la que se muestra
a continuación en la que los indicadores CPI (IRC) y SPI (IRP) se grafican
a lo largo de la duración del proyecto en diferentes puntos de control en
vez de los valores de PV, AC y EV. Los valores del CPI y del SPI se pueden
hallar fácilmente a partir de los valores de PV, AC y EV por las formulas
indicadas en la Tabla 4.2:
EL ANÁLISIS DEL VALOR ACUMULADO (EVA)
Valor
1.5 CPI
1.3
1.1
SPI
0.9
0.7
0.5
Trim. 1 Trim. 2 Trim. 3 Trim. 4 Trim. 5

Figura 4.12. Indicadores CPI (IRC) y SPI (IRP) en varios puntos de control

Los puntos de control mostrados corresponden a las fechas de control

previamente establecidas y que en el diagrama anterior se han marcado
como trimestre 1, luego trimestre 2 etc. Note que el SPI (IRP) ha estado
por debajo de uno a lo largo de los 4 puntos de control mostrando un
preocupante atraso en el cumplimiento del trabajo, mientras que el CPI
(IRC) muestra un buen comportamiento de los costos a partir del 2º.
corte.
Teniendo en cuenta las formulas de estos indicadores de seguimiento, se

pueden analizar a continuación los resultados que resulten de combinar
diferentes y posibles valores de las variables AC y EV, asumiendo que se
tiene una línea base confirmada y que esta se va a mantener invariable
durante este ejercicio. Matemáticamente hablando son cuatro los posibles
resultados alcanzables en estos casos, a saber:
Figura 4.13. Cuatro posibles resultados de las variables PV, AC y EV
El cuadro numerado 1 corresponde al mismo resultado del de la gráfica

4.10 sobre el cual se hizo ya el comentario que corresponde a una
situación de atraso en el cumplimiento del cronograma y un mal manejo
del dinero. La situación mostrada en el cuadro 2 es excelente pues tanto
182
la varianza de costo como la del cronograma son ambas positivas dando

lugar a índices CPI y SPI satisfactorios por ser mayores de uno.
El cuadro 3 es satisfactorio desde el punto de vista del manejo del

presupuesto pero se tiene un cronograma atrasado, mientras que la
situación que se muestra en el cuadro 4 es preocupante en el manejo del
dinero pero se tiene un adelanto en el cronograma.
Hay que recordar al respecto que el estudio de las conclusiones que se

adopten en estas situaciones, debe tener muy presente el momento en que
se efectúa el control con respecto al cronograma total, el análisis de los
recursos financieros disponibles y la valoración que se haga del esfuerzo
aun pendiente de realizar.
Hay que mantener también una aptitud vigilante sobre los parámetros de
calidad que se establecieron en la fase de planeación y sobre las medidas
que se adoptaron respecto al manejo de los riesgos en esta fase.
Se ve conducente aquí volver al estudio de los resultados posibles en

el seguimiento de un proyecto cuando se uso la variable tarifa. En ese
momento se empleó la gráfica 1.22 para clasificar los posibles resultados
de este análisis comparativo:
Trabajo
Óptimo!! Costo real < Planeado y Aceptable! Costo real > Planeado y
Trabajo real > trabajo planeado Trabajo real > trabajo planeado
Planeado Costo $
Pobre! Costo real < Planeado y Pésimo! Costo real > Planeado y
Trabajo real < trabajo planeado Trabajo real < trabajo planeado
Cuatro escenarios posibles en el seguimiento de un proyecto
En el momento que se explicaron los resultados del concepto llamado

tarifa se plantearon cuatro posibles resultados que se denominaron Optima,
Aceptable, Pobre y Pésima. Ahora al efectuar un análisis comparativo entre
estos resultados todos factibles de la tarifa con los extraídos del estudio
sobre la curva S de las variables PV, AC y EV (Fig. 4.12), se llega a estas
conclusiones:

• Una tarifa Pésima corresponde exactamente al resultado numerado

como 1 de la curva S,
• La tarifa Óptima tiene su equivalente en el resultado del control
marcado con el 2.
• Una tarifa Pobre tiene su equivalente en el resultado identificado con
el número 3.
• La tarifa Aceptable equivale al resultado marcado como 4.
Se invita al lector a que examine estas conclusiones y trate de llegar a

alguna decisión respecto a la conveniencia de usar uno de estos métodos
o ambos, quizás uno de ellos como mecanismo de comprobación. Para
muchas personas es natural concluir que resulta más sencillo aplicar
el concepto de tarifa y no el de estudiar y sacar conclusiones sobre la
base de los dos indicadores y de todas las variables involucradas en la
curva S.
Otra confirmación de estas conclusiones proviene cuando se intenta

hallar las posibles combinaciones de valores positivos o negativos para
las varianzas de costo (CV) y del cronograma (SV); resultan en este caso,
cuatro combinaciones posibles a saber:
Varianza de costo
(CV)
+ –
Varianza del cronograma
(SV)
+ –
Las conclusiones que se derivan de este análisis son exactamente las mismas
que se extraigan del uso de la tarifa y de los indicadores CPI y SPI.
Medición del desempeño

Una excelente medición del desempeño técnico es tan fundamental como
la valoración del desempeño del cronograma y del costo presupuestado.
Sucede con mucha frecuencia que al medir el desempeño de un equipo
de programadores se asume que están haciendo el trabajo al ritmo de
productividad planeado lo cual puede que no sea del todo cierto. El valorar
el trabajo de un equipo con mediciones equivocadas de su productividad,
afecta en forma significativa el alcance de un proyecto.
184
El gerente de un proyecto informático debe estar bien informado del

ritmo de avance en las tareas y de las medidas, fechas y controles de su
desempeño, las cuales se vuelven una parte integrante del programa o
cronograma del proyecto.
Es muy difícil especificar para todos los proyectos de tipo informático, el

cómo medir el desempeño técnico porque ello depende de la naturaleza
y alcance del proyecto. Basta solo decir que estos controles deben ser
planeados previamente a lo largo de la duración del proyecto en fechas
prestablecidas que hagan sobretodo mención al logro de objetivos parciales
o de hitos, la forma o mecanismo de medición y los procesos de control de
la Calidad que se van a usar; por último, los administradores de esta clase
de proyectos deben ser creativos para encontrar formas de manejar estos
aspectos tan importantes.
Cambios inesperados en el alcance

Suele suceder que se presenten durante el desarrollo de un proyecto
informático, solicitudes de ¨pequeñas modificaciones¨ que eventualmente
se sumen entre sí hasta llegar a convertirse en cambios significativos y
de alto impacto en el alcance. Existe de hecho en muchas empresas un
término con el cual se denominan esta suma de cambios, aparentemente
y al principio de poco impacto, y es ¨cambios inesperados en el alcance¨.
Por ejemplo, el cliente de una empresa desarrolladora de software solicitó

en el transcurso de unos 3 meses, pequeños cambios en el manejo
de la estructura de cuentas de un paquete de contabilidad y luego de
ser aceptados, la gerencia del proyecto conceptuó que los cambios
introducidos representaban un aumento considerable en el alcance
original del proyecto. Aunque se trató de conciliar y buscar un arreglo en
esta discusión, finalmente el resultado fue un cliente insatisfecho y una
empresa de software que perdió dinero y algo de prestigio.
La mejor defensa en tales casos es primero que todo, dejar clara y bien
definida la declaración del Alcance del proyecto y en segunda instancia
dejar también bien claro lo que no hará o no es el proyecto, es decir
describir todos los aspectos operativos y las funcionalidades que no van a
ser manejados en el proyecto.

Esto no equivale a decir que quedan del todo prohibidos los cambios
al alcance, sino que al permitirlos, se debe dejar bien explícitos tanto
el impacto en el costo como en el tiempo de ser aprobados dichos
cambios y comunicar de ello inmediatamente a todos los interesados
(stakeholders).
Más recomendaciones sobre el uso de software de proyectos

Existen diversas opciones de Project que facilitan entre otras, la entrega
de información de seguimiento elaborada por Project y dirigida a Excel;
existen para ello, varias formas de hacerlo y entre ellas se mencionan las
siguientes:
1. Seleccionado datos en Project y luego copiarlos en Excel con los
clásicos opciones de Copiar y Pegar.
2. Elaborar una tabla en Project con todas las variables que se van a
manejar en Excel y luego decirle a Project que se va a exportar a Excel
los valores de esta tabla (Archivo → Guardar como), lo que provoca
que se active de inmediato un procedimiento asistido.
3. Usar la opción de Project llamada Informes visuales (Proyecto →
Informes visuales) para abrir en forma automática una sesión en Excel
que permite manejar datos mediante plantillas que el usuario puede
programar.
4.2 Integración de equipos, comunicación

y distribución de la información
Las siguientes son las entradas, herramientas y técnicas empleadas
habitualmente y las salidas del proceso de integración del equipo humano:
La siguiente tabla describe las entradas, herramientas y/o técnicas y las

salidas esperadas del proceso de dirigir las actuaciones del equipo encargado
de un proyecto; los dos procesos se van a manejar simultáneamente en
este momento dada la alta integración de los 2 procesos:
186
TABLA 4.5. Entradas, técnicas y Salidas del desarrollo del Equipo
9.3 DESARROLLAR EL EQUIPO DEL PROYECTO

Asignaciones del Personal de Evaluaciones del Desempeño
Habilidades Interpersonales
Proyecto del Equipo
Plan para la Dirección del Actualizaciones a los Factores

Capacitación
Proyecto Ambientales
Actividades de Desarrollo del

Espíritu de Equipo
Reglas básicas
Calendario de los Recursos
Reubicación
Reconocimiento
y Recompensas
El siguiente cuadro describe las entradas, herramientas y salidas de este

importante proceso:
TABLA 4.6. Entradas, técnicas y Salidas de la dirección del Equipo
9.4 DIRIGIR EL EQUIPO DEL PROYECTO

Asignaciones del Personal de Actualizaciones a los Factores
Observación y Conversación
Proyecto Ambientales
Actualizaciones a los Activos

Plan para la Dirección del Evaluaciones del Desempeño
de los Procesos de la Organi-
Proyecto del Equipo
zación
Evaluaciones del Desempeño

Gestión de Conflictos Solicitudes de Cambio
del Equipo
Actualizaciones al Plan para

Informes de Desempeño Registro de Incidentes
la Dirección del Proyecto

Habilidades Interpersonales
organización
La gestión del gerente de un proyecto es clara: asignar tareas o actividades

que se deben realizar bajo algunos parámetros; monitorear o controlar el
cumplimiento puntual de todas y cada una de ellas, resolver problemas,
manejar los conflictos en forma equitativa, brindar retroalimentación a los
interesados y gestionar los cambios.

Para desempeñar una buena labor es recomendable estudiar, en forma

adicional, libros y artículos de administración de personal. Ellos ofrecen
ejemplos de casos de vida real y eventualmente cuando se presenten las
situaciones no deseadas, este acervo vendrá en su ayuda y le apoyará para
tomas buenas decisiones.
Figura 4.14. Dirigir el Equipo del Proyecto, gráfico hecho con base en el libro PMBOK
Uno de los procesos de la gráfica anterior que vale la pena confirmar es

el de realizar el control de cambios en forma integrada, quizás porque la
experiencia nos indica que suele dejarse para cuando el proyecto ya se
esta cerrando y la premura de hacerlo, no deja el margen de tiempo para
hacerlo con toda propiedad.
Este proceso es el testimonio permanente de lo ejecutado por un

equipo humano con todas sus propiedades, fortalezas, debilidades,
malinterpretaciones y errores y que debe servir para mejorar en un futuro
la planeación y ejecución de los proyectos.
La información del avance de las tareas en ejecución debe llegar con

prontitud y a las personas que la gerencia haya designado, contando con
el pleno acuerdo de todos los interesados. En la etapa de planeación, se
elaboro un mapa del flujo de información para mantener a los interesados
188
informados en todos los aspectos del proyecto. La siguiente figura es

un ejemplo de un mapa del flujo de información para un proyecto
informático el cual no pretende ser exclusivo de este tipo de proyectos
ni el único a seguir:
¿Cuál información? ¿Cuándo? ¿Modo? ¿Responsable? ¿Receptor?

Patrocinadores
Logro de un hito o Correo Gerencia del
Bimensual y dueños del
evento importante electrónico proyecto
proyecto
Informe de Costos y Correo Gerencia del Equipo y

Semanal
Tiempo electrónico proyecto clientes
Correo Gerencia del Equipo y

Informe de riesgos Semanal
electrónico proyecto clientes
Asuntos varios
Correo Equipo y
relacionados con Semanal Cualquiera
electrónico clientes
marcha
Agenda reuniones del Coordinador del Equipo y

Semanal Reunión
equipo proyecto clientes
Gerencia del
Desempeño de los Gerente del proyecto y
Bimensual Reunión
contratos proyecto Equipo y
clientes
Gerente y Gerencia del

En cualquier Coordinador del proyecto y
Solicitudes de cambios Documento
momento proyecto y los Equipo y
clientes clientes
Patrocinadores
Decisión de continuar o Gerencia del
Mensual Reunión y dueños del
no con otras fases proyecto
proyecto
Los diagramas de control y los de Gantt son muy adecuados para

supervisar el uso del tiempo; los informes de ejecución de presupuestos
y costos acompañados del cronograma planeado y ejecutado son útiles
para intervenir en estas áreas y lograr hacer correcciones a tiempo. Hay
que tener muy presente que la capacidad de influir en el manejo del
presupuesto, disminuye con el tiempo, por lo que los reportes obtenidos
en forma oportuna y que plenamente identifiquen tendencias adversas
al presupuesto asignado del costo pueden ayudar en gran medida al
gerente del proyecto a realizar cambios que mejoren este aspecto tan
importante.

El modelo integrado del manejo de los costos y del cronograma que

perfectamente puede ser demostrado con la sola variable tarifa, proporciona
al gerente y a todos los interesados, una instantánea del estado actual y
futuro del proyecto.
Distribuir la información
Para el desarrollo de este proceso se requieren las entradas de procesos
previos, se usan las herramientas y se trata de obtener las salidas que se
muestran en la siguiente tabla:

1 Plan de Proyecto 1 Métodos de Comunicación 1 Actualización Activo
2 Herramientas distribución
2 Informes de desempeño
de información
3 Activos procesos
Es necesario convenir con los interesados cómo se reportará el avance

en la ejecución del proyecto, las incidencias, los hechos destacados, los
problemas y los conflictos y es fundamental también acordar el medio de
entrega y la frecuencia de envío de los reportes e informes del caso, sobre
todo en la fase de ejecución como formalmente lo muestra la siguiente
figura: (ver página siguiente)
Gestionar las expectativas de los interesados

Este proceso invita a reunirse con los interesados y trabajar juntos para
satisfacer las necesidades y cumplir con las expectativas. Se busca tener
acuerdos tempraneros para definir cómo se recibirán los entregables y se
deben resolver los incidentes en forma oportuna y justa para todos los
miembros. Las entradas, herramientas y salidas de este proceso son:
190
Figura 4.15. Distribuir la información, gráfico hecho con base en el libro PMBOK.
TABLA 5.1. Entradas, herramientas y Salidas de gestionar las expectativas
Entradas Herramientas y Técnicas Salidas

1 Actualización Activos
1 Registro de interesados 1 Métodos de Comunicación
Procesos
2 Habilidades
2 Gestión de interesados 2 Solicitudes de Cambio
Interpersonales
3 Actualización Plan de
3 Plan de Proyecto 3 Habilidades Directivas
Proyecto
4 Registro de Incidentes 4 Actualización documentos
5 Registro de Cambios
6 Activos de los Procesos
Las reuniones deben ser programadas y previamente deber ser ¨agendadas¨

es decir colocadas en el tiempo y estableciendo los temas a ser tratados, su
orden y el tiempo asignado a cada aspecto y quien va a ser el coordinador
de la misma; no siempre es el Gerente el coordinador de las reuniones ya
que este puede delegar quien lo representa en la reunión o quien hará las
veces de coordinador. Con el uso de tecnologías de la información ya es
muy frecuente ver que estas reuniones se hagan vía Internet en lo que es
llamado reuniones virtuales.

La siguiente figura es un buen elemento que sirve para revisar las entradas,
procesos y técnicas disponibles que son útiles para controlar y vigilar las
expectativas de los interesados, cuestión muy importante en todo proyecto.
Figura 4.16. Gestionar las expectativas de los interesados, hecho con base en el libro PMBOK.
4.3 Aseguramiento de la calidad

TABLA 5.2. Entradas, herramientas y salidas del aseguramiento de la calidad
8.2 REALIZAR EL ASEGURAMIENTO DE CALIDAD

Actualizaciones a los Activos
Plan para la Dirección del
Auditorias de Calidad de los Procesos de la Organi-
Proyecto
zación
Métricas de Calidad Análisis de Procesos Solicitudes de Cambio
Información sobre el desem- Actualizaciones al Plan para

peño del Trabajo la Dirección del Proyecto
Mediciones de Control de Actualizaciones a los Docu-

Calidad mentos del Proyecto
Este proceso pretende auditar los requisitos de calidad y los resultados

obtenidos. La base son las medidas de control de calidad. Ellas garantizan
el uso de las normas apropiadas y las definiciones de la operación del
cliente.
192
Figura 4.17. Realizar el Aseguramiento dela Calidad, gráfico realizado con base en el libro PMBOK.
4.4 Administración de contratos

TABLA 4.6. Proceso de efectuar las adquisiciones.
12.2 EFECTUAR LAS ADQUISICIONES
Entradas Herramientas y Técnicas Salidas

Plan para la Dirección del
Conferencia de Oferentes Vendedores Seleccionados
Proyecto
Documentos de la Técnicas de Evaluación de las Adjudicación del Contrato de

Adquisición Propuestas Adquisición
Criterios de Selección de
Estimaciones Independientes Calendario de los Recursos
Proveedores
Lista de Vendedores
Juicio de Expertos Solicitudes de Cambio
Calificados
Actualizaciones al Plan para

Propuestas de los Vendedores Publicidad
la Dirección del Proyecto
Actualizaciones a los
Documentos del Proyecto Búsqueda en Internet
Documentos del Proyecto
Decisiones de Hacer o Negociación de

Comprar Adquisiciones
Acuerdos para trabajar en

Equipo

organización

A este proceso se llega una vez se han invitado y se han solicitado

cotizaciones a los proveedores, estos ya se han sido seleccionados de
acuerdo al cumplimiento de los requisitos del caso y se han firmado los
contratos de prestación de servicios y/o de entrega de bienes, productos
o resultados específicos. En algunas empresas esto se da como un hecho
porque se cuenta con una lista de proveedores elaborada con anticipación,
lista que es generalmente mantenida y actualizada permanentemente por
la empresa dueña del proyecto.
La siguiente figura sirve para repasar los diferentes procesos, entradas y

resultados esperados en la ejecución de los procedimientos tendientes a
la planeación, y la administración de los diferentes contratos que han sido
aprobados por la Gerencia del proyecto. Los varios aspectos relacionados
con la planeación de los diferentes contratos ya fueron explicados en el
capítulo 3.
Figura 4.18. Efectuar y administrar las adquisiciones, gráfico hecho con base en el libro PMBOK.
194
En la administración de los contratos es vital asignar revisiones periódicas de

las entregas contratadas con el desarrollo y el logro de eventos importantes
en el cronograma del proyecto, los que igualmente pueden o pudieron ser
marcados como hitos del mismo.
4.5 Control del programa del proyecto

Este aspecto es uno de los más importantes en el control de todos los
proyectos sin importar su tamaño y la duración del mismo. Los siguientes
dos numerales brindan explicaciones detalladas a la manera de dos talleres
hechos con sentido muy práctico, que demuestran la enorme importancia
de este grupo de procesos:
4.6 Control presupuestal y el análisis del valor ganado

En estos procesos es fundamental el desarrollo de estrategias y planes
para el manejo de los siguientes procesos por parte de los integrantes del
equipo de trabajo:
1. Solucionar problemas de remplazo y asignación de recursos y su
efecto en la programación y en el presupuesto del proyecto
2. Controlar los riesgos y las alternativas para su manejo y/o
minimización
3. Distinguir y usar indicadores de avance y de meta, y otros mecanismos
para el seguimiento y control.
En esta labor de seguimiento es necesario primero tener ya aprobado el

plan que servirá de comparador es decir el plan Línea de Base resultante
del anterior grupo de procesos y que fue el punto final de la fase de
planeación del proyecto.
En segundo término es conveniente determinar las fechas de corte o de

control y evaluación que dependiendo de la extensión del proyecto puede
ser semanal, mensual o semestral aunque en esto debe notarse es una
decisión que el gerente del proyecto y su equipo de trabajo deben acordar
previamente al inicio de la fase de ejecución. De acuerdo a los principios
no solo del PMI sino de muchas organizaciones, los siguientes son los
principales indicadores usados en la fase de seguimiento y de ajustes al
proyecto:

El pronóstico de terminación brinda un pronóstico del tiempo y de los

costos para terminar un proyecto. Este pronóstico sumado al actual estado
del proyecto suministra una revisión estimada de la fecha y el costo del
proyecto terminado (at completion forecast).
EAC Estimate At Complete: EAC = BAC / CPI, donde BAC = Costo

presupuestado para terminar el proyecto o Costo total presupuestado del
proyecto.
ETC Estimate to Complete: Costo Estimado para terminar el proyecto o sea

ETC = EAC – AC.
Nombre Fórmula Interpretaciones

Costo presupuestado del trabajo
PV (en inglés, programado a ser ejecutado en una
Trabajo planeado *
BCWS=Budgeted Cost of the tarea o grupo de tareas en un período
Costo planeado
Work Scheduled) de tiempo que va a partir de su inicio y
hasta la fecha de corte
AC (en inglés, ACWP.=Actual Trabajo real * Costo El costo real del trabajo ejecutado en
Cost of the Work Performed) real un período dado.
EV (en inglés, El costo presupuestado del trabajo
Trabajo real * Costo
BCWP=Budgeted Cost of the realizado (Valor ganado o en inglés,
planeado
Work Performed) Earned Value)
Negativo si esta sobre-presupuestado y
Varianza de costo (CV) EV – AC
positivo si se está por debajo
Negativo si está atrasado y positivo si
Varianza del cronograma (SV) EV – PV
se está por delante del cronograma.
¿Cuánto se logro en $ por cada $1 gas-

Índice de ejecución de costos
EV / AC tado? Fondos están o no siendo usados
(CPI)
eficientemente
Índice de ejecución del cro- ¿A que % se esta ejecutando el proyec-

EV / PV
nograma (SPI) to con relación a lo planeado?
A partir del actual momento, ¿cuánto

más costará el proyecto hasta su cul-
Estimado a la terminación BAC / CPI o
minación?
(EAC) BAC - EAC
¿Cuánto por encima o por debajo del
presupuesto se estará al final?
A partir del actual momento, cuánto

Estimado para terminar (ETC) EAC – AC más costará el proyecto hasta su cul-
minación?
Varianza a la terminación Cuánto por encima o por debajo del

BAC - EAC
(VAC) presupuesto se estará al final?
196
Con los siguientes talleres se pretende explicar en forma detallada las

formas de cálculo, el uso y las interpretaciones de cada uno de estos
indicadores:
TALLER 1. Una compañía tiene $ 2.000.000 disponible para contratar la

tarea de validar y exportar a una base de datos 10.000 registros planos
de datos. El contratista debe validar los datos de acuerdo a una serie de
protocolos exigentes ya prestablecidos y exportarlos a otro servidor y el
precio acordado por registro es de $200. La compañía estima que 250
registros pueden ser validados y exportados cada hora.
Con lo anterior, el valor planeado o PV en inglés por hora en el proyecto

es determinado simplemente por la multiplicación del número de horas
trabajadas9 por los 250 registros por cada hora presupuestados por su valor
día. Así, por ejemplo, en el hora 18 de trabajo se tiene:
PV = 18 horas x 250 registros/ hr. x $ 200 = $ 900.000
Otra manera de decir esto es que los $ 900.000 representan lo que está
presupuestado o supuesto para esta tarea para la hora 18. El factor PV es
siempre asociado a una fecha específica en la programación; a una rata de
250 registros por hora y a un costo de $200/ registro, esta tarea deberá tomar
40 horas de trabajo para terminarse y tener un PV final de $ 2.000.000.
En contraste, el EV (Earned Value) se calcula tomando para un momento de

corte del proyecto cuánto trabajo realmente ha sido hecho y se costea en
términos de la tarifa presupuestada. Esto es, el indicador toma el número
de registros realmente exportados a una hora determinada y los costea
usando la tarifa de $200.oo presupuestada. Se supone, para este ejemplo,
que en la hora 18 de trabajo, 4.000 registros y no los 4.500 registros
presupuestados han sido exportados, así:
EV = 4.000 registros x $200 = $800.000
En otras palabras, a la hora 18 de trabajo el valor de $800.000 de trabajo

ha sido ejecutado. Ahora, dado que $ 900.000 fue el costo del trabajo que
9. En este caso se asume que el volumen de trabajo realmente trabajado equivale al de horas
reportadas como trabajadas y que es independiente de la productividad o eficiencia de los recursos
empleados.

fue presupuestado a ser ejecutado, el proyecto está $100.000 de trabajo

atrás de lo programado, noticia que no representa un ahorro en los costos
de $ 100.000, sino más bien que el proyecto está atrasado en los $100.000.
Estos $100.000 representan 500 registros o el valor de dos días de trabajo,
lo cual significa que para la hora 18, el proyecto está atrasado dos horas
con respecto a lo programado.
Así el concepto de EV permite al costo del proyecto ser trasladado dentro

del progreso del trabajo del proyecto. A la hora 18, el proyecto tiene hecho
solamente 16 horas de progreso del trabajo.
El análisis se suele también hacer empleando otra forma de llamar a estas

tres variables y que se conocen como CPTP (Costo Presupuestado del
trabajo programado) para la variable PV, CRTR (Costo Real del Trabajo
Realizado) para la variable AC y CPTR (Costo Presupuestado del Trabajo
Realizado), para el indicador EV, a saber:
1. PV o CPTR (en inglés, BCWS=Budgeted Cost of the Work Scheduled)
es el costo presupuestado del trabajo programado a ser ejecutado en
un período dado, o es la suma de los costos de todo el trabajo, más
los esfuerzos aportados, programados a ser completados dentro de
un período de tiempo especificado en el presupuesto original. Por
ejemplo, se puede decir que en un proyecto determinado, a la semana
15, el valor del CPTP es de $ 4.500.000.= y el CPTP en una semana
determinada es de $350.000.=.
2. AC o CRTR (en inglés, ACWP.=Actual Cost of the Work Performed) es
el costo real del trabajo ejecutado en un período dado. Esto es la suma
de los costos para todos los trabajos (Work packages) completados,
más todas las órdenes de trabajo abiertas y los trabajos avanzados.
En una medida del rendimiento del proyecto, el CRTR puede ser
comparada con el CPTP, siguiendo con el ejemplo anterior si el CRTR
a la semana 15 es de $4.550.000.=, quiere decir que se tiene un costo
de $ 50.000 más de lo presupuestado. Sin embargo, este sobrecosto
depende de cuánto trabajo haya sido completado. El sobrecosto
puede significar, que algunas tareas fueron realizadas antes de lo
programado (adelantos) el progreso del trabajo del proyecto debe ser
conocido antes de que el rendimiento del proyecto sea evaluado. Con
la siguiente variable se puede realizar esto.
3. EV o CPTR (en inglés, BCWP=Budgeted Cost of the Work Performed)
es el costo presupuestado del trabajo realizado (Valor ganado o en
198
inglés, earned value). Esto es determinado por la revisión hasta ahora

del rendimiento de las tareas (las completadas, las abiertas y las
adelantadas) además de su presupuesto correspondiente para ver cuáles
fueron los costos supuestos. El CPTR para una tarea ya completada
totalmente es lo mismo que el CPTP para esa misma tarea.
La siguiente tabla nos facilita encontrar rápidamente las equivalencias

de estos indicadores tal y como los denomina el PMI; en los casos de
indicadores que en forma predeterminada esta herramienta no trae, se han
sugerido métodos para calcularlos:
TABLA 4.7. Indicadores, formulas y procesos de cálculo
Indicador Campo equivalente

Valor planeado acumulado (PV) CPTP
Valor real acumulado (AC) CRTR
Valor acumulado (EV) VA (CPTR)
Varianza de costo (CV) VC
Varianza del cronograma (SV) VP
Índice ejecución de costos (CPI) IRC : Índice rendimiento de Costos
Índice ejecución del

IRP : Índice rendimiento de programación
cronograma (SPI)
Total presupuestado (BAC) Costo previsto
Se calcula generalmente con la fórmula: BAC / IRC, pero se

advierte que se aplica asumiendo que el proyecto va a seguir
Estimado a la terminación
marchando con la proyección estimada hasta ahora. Existen
(EAC)
otras formas de hacerlo que van desde contratar una evalua-
ción técnica externa hasta subcontratar el resto del proyecto
Estimado para terminar (ETC) Se usa la fórmula: EAC - AC
Varianza a la terminación
Se calcula con la fórmula: BAC - EAC
(VAC)
Adicionalmente, estos análisis se suelen complementar con el uso de otras

Varianzas.
Cuando se toman juntas, las variables CPTP, CRTR y CPTR pueden ser usadas
para computar unas varianzas, las cuales revelan diferentes aspectos del

estado del proyecto. Cuatro tipos de varianzas pueden ser determinadas:

la contable, la de programación, la de costos y la de tiempo.
AV (Accounting Variance) = CPTP – CRTR (Varianza contable)
SV (Schedule Variance) = CPTR – CPTP (Varianza de programación)
TV (Time Variance) = SD – BCSP (Varianza de tiempo)
CV (Cost Variance) = CPTR – CRTR (Varianza de costo).
Se debe recordar que es absolutamente disponer en estos casos de una

fecha de corte o de estado (en inglés, Status date) y que el valor de la
variable BCSP sea a esta fecha en la que CPTP = CPTR.
TALLER 2. Uso de Indicadores de seguimiento

y el análisis de valor ganado
Usted está administrando un proyecto cuyo objetivo final es entregar un
producto de software terminado. El proyecto tiene siete actividades, con
relaciones de dependencia entre si de comienzo–final. En la siguiente
tabla esta la información de las fechas (en formato mm/dd/aa), duraciones
en días y costos planeados en $ y se sugiere seguir los pasos para hallar
los indicadores de seguimiento PV, AC, EV, CV, CPI y SPI con dos dígitos
de aproximación. La primera fila contiene los datos de resumen de todo
el proyecto.
% de Duración Comienzo Fin Costo

Nombre actividad
avance planeada planeado planeado planeado
Producto liberado 1.0 0% 240 días 01/06/13 12/05/13 $ 295.000
Requerimientos 0% 30 días 01/06/13 02/14/13 $ 30.000
Diseño 0% 60 días 02/24/13 05/09/13 $ 70.000
Prueba del concepto 0% 30 días 05/19/13 06/20/13 $ 45.000
Producto construido 0% 45 días NA 08/22/13 $ 60.000
Producto ensayado 0% 45 días NA 10/24/13 $ 60.000
Producto desplegado 0% 30 días NA 12/05/13 $ 30.000
Producto completo
0% 0 días NA 12/05/13 $0
liberado
200
El proyecto está actualmente en la mitad de la fase de ejecución y la fecha

de control es Junio 20 del 2013. La información del siguiente cuadro
provee el programa y la información del costo a la fecha.
Final
Nombre de la % Duración Inicio Terminación Costo

actividad Terminado actual actual actual actual
Producto liberado 1.0 47.63% 122 días 01/06/13 NA $ 147.000
Requerimientos 100% 35 días 01/06/13 02/21/13 $ 32.000
Diseño 100% 60 días 02/24/13 05/16/13 $ 70.000
Prueba del concepto 90% 27 días 05/19/13 NA $ 45.000
Producto construido 0% 0 días NA NA $0
Producto ensayado 0% 0 días NA NA $0
Producto desplegado 0% 0 días NA NA $0
Producto completo
0% 0 días NA NA $0
liberado
Utilizando el cálculo de la tabla de datos, suministre el reporte de la

situación del proyecto contestando las siguientes preguntas (aproxime a
dos dígitos en los casos de datos numéricos):
1. Qué medida es usada para determinar si el proyecto está adelantado,
atrasado o al día respecto al cronograma y cuál es su valor?
SV – varianza del cronograma
Primero, usted debe determinar el siguiente valor:
AC = $ 147.000 (Costo final a la fecha)
PV = $ 145.000 (Cuál fue el valor planeado del trabajo a la fecha)
EV = $ 140.500 (Cuál es el valor del trabajo ejecutado a la fecha)
($30.000 + $70 .000 + (90% of $ 45.000 = $40.500) = $ 140.500
→ SV = EV – PV SV = $ 140.500 – $ 145.000 = – $ 4.500
2. Qué medida es empleada para determinar el porcentaje de progreso
del proyecto de acuerdo al plan y cual es su valor?
SPI = Índice de la presentación del proyecto
SPI = EV/PV SPI = $ 140.500/ $ 145.000 = 0.969
3. Basado en estos datos del programa, está el proyecto atrasado o
cumple con el cronograma?
→ El proyecto está atrasado.

4. En que porcentaje está el proyecto avanzando comparado con el

porcentaje de progresión planeado?
→ El proyecto está ejecutado en un 96.9% del plan original.
5. Cuál medida es utilizada para determinar si el proyecto está por
encima del presupuesto, por debajo del presupuesto o en el limite, y
cuánto es la diferencia?
CV – Costo variable
AC = $ 147.000 (Costo actual a la fecha)
PV = $ 145.000 (Cuál fue el valor planeado del trabajo a la fecha?)
EV = 149.500 (Cuál es el valor del trabajo hecho a la fecha?)
($ 30.000 + $ 70.000 + (90% de $ 45.000 =$ 40.500) = $ 147.000)
→ CV = EV – AC CV = $ 140.500 - $ 147.000 = - $ 6.500
6. Cual medida es utilizada para determinar la eficiencia del proyecto y
cual es su valor?
CPI – Índice del comportamiento del costo
→ CPI = EV/AC CPI = $ 140.500 / $ 147.000 = 0,956
7. Basado en estas medidas, si el presupuesto está por encima, por debajo
o al límite del presupuesto?
→ El proyecto está por encima del presupuesto.
8. Actualmente, cuanto está haciendo el proyecto por cada peso que
gasta?
→ El proyecto está haciendo $ 0.96 por cada peso que gasta.
9. Basado en el estado actual y comportamiento del proyecto cuanto
usted estima que costará el proyecto a su terminación y en cual medida
basa su estimación?
La estimación completa es el valor que se dice el costo calculado
del proyecto total, basado en la eficiencia del gasto. El estimativo es
calculado en varias formas. Use BAC/CPI para calcular EAC. BAC
(presupuesto total) = $295.000 y el CPI ) índice del comportamiento
del costo = $ 0.956. Esto da un EAC de $ 308.755,40
10. Cuanto más dinero deberá gastar desde el punto actual hasta finalizar
el proyecto? Cual cálculo se debe hacer para sustentar el resultado?
→ Se recomienda usar el de estimación completa. Se calcula restando
AC (costo actual) del costo completo estimado. $ 308.755,40 - $
147.000 = $ 161.577,40
11. El proyecto a su terminación estará por encima, por debajo o de
acuerdo al presupuesto? Que información tiene para sustentar esta
estimación?
202
→ Basado en el estimativo total, el proyecto está por encima del

presupuesto.
El presupuesto estimado a su terminación (BAC) es $ 295.000, el
presupuesto estimado al terminar (EAC) $ 308.755,40
La variación al completar el proyecto (VAC) es BAC – EAC y en este

proyecto es la suma de $ 13.577 por encima del presupuesto.
Ejercicio sobre el valor ganado TALLER No. 2 respuestas correctas:

Debido a que el proyecto está por encima del presupuesto y atrasado en
el cronograma, se debe encontrar una manera para llevar el proyecto a los
resultados estimados a la fecha de corte. Después de revisar las diferentes
opciones y los riesgos relacionados, se ha determinado que la mejor
alternativa es para la ruta más rápida del proyecto permitiendo ensayos
para comenzar temprano durante la actividad de construir el producto.
Esta actividad impone riesgo al proyecto pero puede también permitir
cumplir el cronograma.
Cualquier cálculo de pesos se ha aproximado a dos decimales (Ejemplo...$

456.32). Se recomienda utilizar una calculadora básica o una calculadora
con la que pueda aproximar la varianza. El producto liberado en línea es
una actividad reflejada en el siguiente contenido:
Planeado
Nombre de la % Duración Inicio Terminación Costo

actividad Terminado estimada estimado estimada estimado
Producto liberado 1.0 0% 240 días 01/06/13 12/05/15 $ 295.000,00
Requerimientos 0% 30 días 01/06/13 02/14/13 $ 32.000,00
Diseño 0% 60 días 02/17/13 05/09/13 $ 70.000,00
Prueba del concepto 0% 30 días 05/12/13 06/20/13 $ 45.000,00
Producto construido 0% 45 días 06/26/13 08/22/13 $ 60.000,00
Producto ensayado 0% 45 días 08/25/13 10/24/13 $ 60.000,00
Producto desplegado 0% 30 días 10/27/13 12/05/13 $ 30.000,00
Producto completo
0% 0 días 12/05/13 12/05/13 $ 0,00
liberado

Es agosto 22, el producto está siendo construido y muy temprano las

pruebas han comenzado. A continuación el cuadro con los datos actuales
del cronograma del proyecto y la información de costos. Utilizando esta
información y la información estimada arriba, determine los valores del
comportamiento listados en el resto del ejercicio.
Real
Nombre de la % Duración Inicio Terminación

Costo real
actividad Terminado real real real
Producto liberado 1.0 70% 164.72 días 01/06/13 NA $ 217.000,00
Requerimientos 100% 35 días 01/06/13 02/21/13 $ 32.000,00
Diseño 100% 60 días 02/24/13 05/16/13 $ 70.000,00
Prueba del concepto 100% 30 días 05/19/13 06/27/13 $ 50.000,00
Producto construido 80% 36 días 06/30/13 NA $ 52.000,00
Producto ensayado 22% 10 días 08/04/13 NA $ 13.000,00
Producto desplegado 0% 0días NA NA $ 0.00
Producto completo
0% 0 días NA NA $ 0,00
liberado
Utilizando los cálculos de los datos previos, elabore un reporte del estado
del proyecto, contestando las siguientes preguntas:
1. Basado en las medidas, el proyecto está al día, atrasado o adelantado
con relación al cronograma? Indique que media y cantidad usted está
usando para determinar el estado.
AC = $ 217.000 (Costo actual a la fecha)
PV = $ 205.000 (Valor del trabajo planeado a la fecha
EV = $ 206.200 ( Es el valor del trabajo ejecutado a la fecha)
($ 30.000 + $ 70.000 + $ 45.000 + ($ 80% DE $ 60.000 = $ 48.000)
+ ($ 22% DE $ 60.000 = $13.200) = $ 206.200)
SV = EV – PV SV = $ 206.200 - $ 205.000 = $ 1.200
El proyecto está ligeramente adelantado con relación al cronograma.
2. En que rata porcentual está el proyecto progresando, en comparación
con la rata de progreso planeada?
SPI = EV-PV SPI = $ 206.200 / 205.000 = 1,006
El proyecto está progresando en 100.6% de la rata original planeada.
204
Capítulo 5 • Cierre
3. Está el proyecto por encima, por debajo o de acuerdo al presupuesto?

Cómo lo sabe?
CV = EV – AC CV = $ 206.200 - $ 217.000 = - $ 10.800
El proyecto está por encima del presupuesto.
4. Actualmente, cuántos centavos hasta haciendo por cada peso
gastado?
CPI = EV / AC CPI = $ 206.900 / 217.000 = 0.950
El proyecto está haciendo 95 centavos por cada peso gastado.
5. Basado en el estado y comportamiento actual del proyecto, en cuánto
se estima el costo a la su terminación. El estimado al finalizar (EAC)
es el valor esperado que el proyecto va a costar al finalizar basado
en el gasto eficiente del proyecto. Este es calculado de varias formas.
Use usted BPI para calcular EAC. El BAC (Presupuesto total) es de $
295.000 y el CPI (índice del costo presentado) es de $ 0.95. Esto da un
EAC de $ 310.526.31
6. Cuánto dinero debe ser gastado del punto actual hasta completar el
proyecto?
ETC = EAC – AC ETC = $ 310.526,31 – 217.000 = 93.526.3
7. Estima usted que el proyecto a su terminación estará por encima, por
debajo o de acuerdo al presupuesto?
Basado en el EAC actual de $ 310.526.31 el presupuesto del proyecto
al finalizar está por encima.
8. Cuál es la varianza del presupuesto original y el actual estimado a la
terminación?
VAC = BAC – EAC -$ 15.526,31 = $295.000 - $ 310.526.31.

206
Capítulo 5
Cierre
El cierre contractual
Las entradas, herramientas y los ítems que salen de este proceso a ser
cumplido una vez se ha entregado el producto pactado aparecen en la
siguiente gráfica:
TABLA 5.1. Entradas, técnicas y salidas del Cierre de un proyecto

1 Auditorías de la
1 Plan de Proyecto 1 Adquisiciones cerradas
Adquisición
2 Documentación de
2 Acuerdos negociados 2 Actualizaciones Activos
Adquisición
3 Sistema Gestión de
Registros
En este proceso se realiza el cierre de todos y cada uno de los contratos.

Hay que controlar que todos los entregables sean aceptados y verificar
que todos los pagos se hayan cumplido, así como que se han cerrado
todos y cualquier tipo de reclamos existentes en este momento. Cuando
se trata del cierre de una fase, se verifica cuales contratos siguen vigentes
para las siguientes fases y se documenta y se explican las circunstancias

que pueden aconsejar la continuidad de algunos proyectos. Estos procesos

son llamados en muchas empresas la auditoría. Es de tener presente la
probable intervención en estos casos de entidades públicas del gobierno
sectorial o general sobre todo en proyectos con alto impacto en lo social o
cuando los dueños del mismo son entidades gubernamentales.
De hecho hay en la práctica dos tipos de auditorías:

• Auditorias del proyecto en desarrollo
• Auditorias posteriores al cierre del proyecto.
Estos últimos se enderezan fundamentalmente a mejorar la administración

de los futuros proyectos mientras que los primeros estudian los
requerimientos de cambios, los aprueban o no y van registrando los
cambios para completar los procesos de control con la intención de poder
responder a estas inquietudes:
1. ¿El proyecto entrego los productos y beneficios esperados por todos los
interesados? ¿Se manejo bien el proyecto?, ¿El cliente quedo satisfecho?
2. Evaluar lo que se hizo bien y lo que realmente contribuyo al éxito
3. Reconocer los cambios y su contribución para futuros proyectos.
Lamentablemente, se calcula en forma algo aproximada que más del 90%

de los contratos de los proyectos TIC no se auditan o si se hace, no lo
hacen siguiendo procesos formales; se sabe que las personas aprenden
más lo que no se debe hacer con los errores y no lo que sí se debe hacer
con ellos. Al examinar los errores y los fracasos es posible incorporar las
mejores prácticas en el manejo de proyectos en una organización.
Las auditorías del proyecto en desarrollo emplean mediciones del

desempeño y los confrontan contra los datos pronosticados de todos y
cada uno de los contratos; igualmente hacen una revisión del papel del
proyecto en las prioridades establecidas en la planeación estratégica de una
empresa. También se revisa el desempeño del recurso humano empleado
y los factores externos que podrían afectar al proyecto, por ejemplo,
tecnologías empleadas, regulaciones gubernamentales y la competencia.
La profundidad y el detalle de las auditorías depende de muchos factores

entre ellos, el tamaño de la empresa, la importancia del proyecto, el tipo,
tamaño y prioridad del proyecto y los problemas propios del mismo.
208
Los lineamientos generales que deben observarse antes de realizar una

auditoría de un proyecto en desarrollo son las siguientes:
a) Arranque y asignación del personal a cargo de la auditoría
b) Recopilación y análisis de los datos que comprende dos niveles: nivel
institucional y nivel del equipo del proyecto
c) Elaboración de informes que a su vez comprende: clasificación del
proyecto, análisis, recomendaciones y lecciones aprendidas
d) Apéndice.
El siguiente gráfico muestra los elementos de entrada y salidas del proceso

de cierre administrativo de un proyecto típico:
El cierre administrativo
El cuadro a continuación muestra las entradas, herramientas y las salidas
de este grupo de procesos:
TABLA 5.2. Entradas, herramientas y Salidas del Cierre Administrativo

1 Plan para la dirección del 1 Transición del Producto,
1 Juicio de Expertos
proyecto Servicio o Resultado final
2 Actualizaciones Activos de
2 Entregables aceptados
procesos organización
3 Activos de los procesos de

la organización
Este proceso termina todas las actividades desarrolladas en todos los

procesos que se hayan utilizado y manejado en un proyecto. Se cierran las
fases intermedias y finales y se prepara la documentación correspondiente
a la historia de los controles de cambios autorizados y no autorizados e
igualmente se diligencia el Acta de Cierre del Proyecto. El recurso humano
regresa generalmente a sus sitios habituales de trabajo si provienen de una
dependencia de la empresa dueña del proyecto y enseguida se procede a
realizar la evaluación de su desempeño en el proyecto.
Es altamente probable que en esta fase se requiera del concepto técnico

de expertos en diversas materias para alcanzar un consenso sobre si se

han cumplido o no los requisitos de funcionalidad e integralidad de los

productos que se van a entregar.
En la próxima figura se muestran los pasos, entradas y salidas de este

proceso que es una parte vital de la gestión de integración de todos los
proyectos:
Figura 5.1. Cierre del proyecto o una fase, gráfico hecho con base en el libro PMBOK.
Se invita al lector a que examine cuidadosamente los principales procesos

y subprocesos de este muy importante elemento de la administración
de proyectos y su rol tan primordial en la conformación y estudio de las
lecciones aprendidas.
210
Apéndices
Apéndices
Apéndice A. Introducción a la herramienta MS-Project

El diagrama de Gantt es el que, por defecto, se presenta cuando se inicia
Project. En él se presentan, además de los elementos comunes a las
ventanas de Windows, los que se visualizan en esta figura:
Algunos íconos y opciones de ejecución de las barras de herramientas se

pueden configurar desde el principio, usando la opción del menú principal
Archivo, luego Opciones y finalmente haciendo clic en la opción Barra
de herramientas de acceso rápido; aquí se pueden colocar aquellos
comandos o botones que el usuario considere vitales en su trabajo, como
se puede ver en la siguiente figura:

Note la ubicación de la barra de herramientas —parte superior debajo

del menú principal—, de los botones de esquema, de la barra de edición
—debajo de la barra de herramientas— y de la barra de estado —parte
inferior—. Note también la barra de ayudas provistas por Project: cuando
el usuario personaliza la barra con accesos rápidos esta se ubica en la
parte superior izquierda de la pantalla principal.
En la versión 2010 es muy posible que algunas facilidades no estén

instaladas en su computadora, por lo que se invita al lector a que las
cargue haciendo clic en Archivo → Opciones → Complementos, y en
esta ventana seleccione las que desea manejar de la lista central (note que
en la muestra se seleccionó PERT Analysis): (ver página siguiente)
Por ultimo tenga presente que en la versión 2010 se ha introducido una

opción que facilita listar simplemente las tareas y que se conoce como
Programación manual que tiene efectos muy distintos al anterior mecanismo
de programar las tareas y que en la versión 2010 se llama Programación
automática. Uno solo de estos dos mecanismos de programación debe ser
establecido al momento de empezar a manejar esta herramienta.
212
Apéndices

Apéndice B. Proyectos informáticos de calidad

Es recomendable primero que todo, estudiar los procesos de producción
que van a estar comprendidos en un proyecto de mejoramiento de la
Calidad, ya sea global o específicos en algunos sectores de la cadena de
valores. Una vez se ha conformado el equipo del proyecto uno de los
primeros pasos es observar y analizar dichos procesos, haciendo uso de
diagramas de flujos de procesos semejante al siguiente:
Proceso Actividades
Desarrollo Ádquisición de patente Licencia

de productos
Aprovisionar Recuperación del proceso Compras

materiales
Aseguramiento Del sistema De cada componente

de la calidad
Preparar materiale Conservación Secado al horno

Dar forma
Pintura Impresión Pintura electrostática Pintura manual
Control de calidad Prueba Registro estadístico
Reelaborar Desechos Reelaborar
Envasado Envasado al vacio unidad Empaque en cajas
Envio directo
Almacenaje/distrib.
Almacén Distribuir
Venta Promocionar Comercializar Vender
Estos estudios se ejecutan teniendo muy en cuenta los siguientes aspectos

en cada proceso o subproceso a ser analizado:
1. Límites entre procesos.
2. la configuración de los procesos.
214
Apéndices
3. la métrica de cada proceso.

4. Los objetivos acordados de una CALIDAD mejorada y/o optimizada.
Específicamente para proyectos de Calidad se puede empezar con la

siguiente lista tentativa de los procesos a ser examinados, haciendo notar
que esta lista no es definitiva y que puede ser ampliada o restringida
dependiendo del Alcance del proyecto.
• Inventarios (y su impacto)
• Colas (trabajos en proceso “Work In Process”, de materias primas, de
productos terminados o esperando “algo”)
• Tiempos de entrega del(os) producto(s) y sus respectivos rendimientos
• Entregas a Tiempo, Calidad y la Métrica Operativa
• Capacidad de Producción y mecanismos de Planificación
• Períodos de Inactividad de los Equipos (esto incluye montajes,
adaptaciones y cambios)
• Utilización del espacio de trabajo
• Flujo del Producto y movimientos de materias primas
• Abastecimiento de materiales y/o servicios
• Limpieza & imagen de la Organización
• Aspectos relacionados con los Proveedores Internos y Externos.
Los entregables deseados al término de una fase de evaluación preliminar

de un proyecto de Calidad generalmente se expresan en estos términos:
• Futuro Mapa del Estado de (los) Proceso(s)
• La métrica detallada que ha de ser usada para evaluar el “Estado
Futuro”
• Plan de Acción desarrollado para entregar el “Estado Futuro” del(los)
proceso(s)
• Presupuesto del Trabajo a realizar (el costo evaluado por cada
proceso)
• Garantía del 100% (para alcanzar el “Estado Futuro” aprobado).
Estos estudios comprenden y abarcan algún tiempo pero lo importante

es desarrollarlos con “rapidez, agilidad, eficiencia y teniendo siempre
presente el valor agregado”.
Uno de los más importantes objetivos que se persigue con un proyecto

de mejoramiento u optimización de la Calidad aplicable a un proceso

productivo es evitar o minimizar los así llamados desperdicios o sean

defectos de los mismos que se pueden manifestar en ocho diversas maneras
listadas a continuación:
Almacenamiento innecesario del producto, o de transacciones

1. Inventarios:
o de información
Tiempos de espera entre pasos de un proceso que rompen el

2. Espera:
flujo y lo hacen innecesariamente largo
3. Transporte: Traslado innecesario del producto o de transacciones
4. Movimiento Desplazamientos innecesarios de los empleados
Desarrollo de un proceso o producto más allá de las demandas

5. Sobre-procesado:
del cliente
6. Sobre-producción: Producción que excede a la demanda
Errores que hacen el producto sea considerado inútil o que

7. Defectos:
implican una reparación
8. Uso inadecuado Desarrollo de tareas que infrautilizan o que superan las habili-
de habilidades: dades del operario.
Los desperdicios pueden ser un elemento importante de la métrica que

se emplee para medir un proceso, tanto en el momento en que se analiza
como en el deseable según se exprese en el “Estado Futuro” descrito en un
mapa de los procesos estudiados.
216
Apéndices
Apéndice C. La metodología Scrum

SCRUM: es una metodología de desarrollo muy simple, que requiere
trabajo duro porque no se basa en el seguimiento de un plan, sino en la
adaptación continua a las circunstancias de la evolución del proyecto10
10. (http://www.navegapolis.net/files/s/NST-010_01.pdf)

Visión general del modelo11

Las ventajas de utilizar metodologías ágiles en proyectos de tecnología es
que se tienen entregas parciales en las que se puede evidenciar el avance del
proyecto; Scrum enfatiza la comunicación, colaboración, y el intercambio
rápido y quizás lo más importante la adaptación a los factores externos y
la flexibilidad en el desarrollo ya que este proceso debido a que la mayoría
de los proyectos de tecnología tienen involucrados desarrollo de software a
la medida del cliente, y este proceso puede ser impredecible y complejo12,
aspecto que incrementa el nivel de incertidumbre de los proyectos, por
esto incluir apartes de la metodología Scrum en la implementación de
proyectos garantiza un mejor avance del proyecto.
La adaptación a los cambios es el fuerte de la metodología, esto porque
no existe una etapa de levantamiento de requerimientos sino que se van
construyendo en la ejecución del proyecto, la incertidumbre es un factor
clave por eso se está preparado para asumir cualquier cambio, eliminando
los obstáculos de los proyectos. Las generalidades de la metodología son:
11. http://www.navegapolis.net/files/s/NST-010_01.pdf
12. http://www.scrummethodology.org/
218
Apéndices
Metodología Scrum13
Roles
PRODUCTO OWNER: El cliente puede ser interno o externo, en él se
canaliza las necesidades y es el canal de comunicación con el equipo,
sobre el recaen responsabilidades como: Definir cuáles serán los
requerimientos del proyecto, encaminar el desarrollo estableciendo el
orden del desarrollo priorizando los requerimientos de aquí se establece el
calendario del proyecto, retroalimenta cada iteración, debe estar presente
y participar activamente en las reuniones de planificación y demostración,
así como resolver dudas que tiene el equipo.
SCRUM MASTER: Es el líder del equipo exponiendo las normas y

haciéndolas seguir, antes de comensar una nueva iteración se requiere
que se tenga la lista priorizada para comenzar con la siguiente iteración,
ser el facilitador en las reuniones de planificación, demostración, diarias y
de retrospectiva, eliminar los obstáculos e interrupciones del proyecto.
EQUIPO: son los responsables de llevar a cabo el desarrollo y garantizar

la calidad de lo que hacen, los equipos de desarrollo pueden oscilar entre
5 a 9 personas, cuando se establece la lista priorizada el equipo se divide
el trabajo con el fin de cumplir con los requerimientos priorizados, aquí se
estima el esfuerzo necesario para desarrollar el requerimiento, el trabajo
en equipo es su principal deber.
13. http://www.proyectosagiles.org/como-funciona-scrum

220
Índice temático
Índice temático
A E
Análisis del valor acumulado 122 Ejecución del proyecto 106, 132,
Auditoría 128, 192, 207-209 151, 165, 190, 218
Estructura de rompimiento del trabajo
C 35, 36, 65, 74, 89, 90, 104, 107,
Calidad 121, 124, 125, 126, 129, 109, 111, 115, 119, 140, 142
192, 214
Contratos 35, 88, 116, 153, 193 F
Control de cambios 77, 167, 188 Fase de Desarrollo o Ejecución 4, 11,
Costo real 47-51, 68, 178, 18, 183, 15-30
196, 198, 204 Fase de Planeación 35, 36, 77, 116,
Costos fijos 159 130, 164, 165, 167, 183, 195
Costos previstos o planeados 142, Fases de un proyecto 9, 14, 73, 91,
200 94, 95, 113
Cronograma 84, 88, 91
G
D Gerencia de proyectos 1 , 2, 6
Descomposición del trabajo 11, 35,
103, 115 H
Desempeño de un proyecto 46 Herramientas computarizadas 122
Duración de tarea 36 Hito 35, 76, 93, 116, 155, 185, 189,
195

Indicador IRC (CPI) 47, 68, 178, 179, S
181, 182, 199 Scrum 217-219, apéndice C
Indicador IRP (SPI) 47, 68, 178, 181,
182, 199 T
Incertidumbre 130, 154, 218 Tarea crítica 117, 119, 120
Indicadores 46-48, 51, 54, 60 , 65, Tarea Resumen 68
167, 177, 184, 197, 199, 200 Tarifa 40, 45, 48, 51-57, 65, 66, 68
Tasa de Oportunidad 59
P Tipo de tarea 47, 174
Plan base o previsto 46, 65, 66, 69, Trabajo previsto 68
70, 93, 166, 167, 168 Trabajo real 47-51, 68, 149, 183,
Plantillas 61, 64, 65, 68, 73, 74, 93, 196, 197
105, 111-113, 186 Trabajo restante 178
Porcentaje completado 173 V
Progreso (Avance) de un proyecto 22, Valor acumulado 46, 47, 50, 122,
46, 155, 156, 167, 175, 198 178, 179, 199
Varianza de costos 50, 177, 178, 183,
R 184, 196, 199, 200
Recursos 7, 9, 12, 19, 29, 33, 34-42, Varianza del cronograma 177, 178.
46-49, 56, 60, 62, 64, 74, 80, 184, 196, 199, 201.
84, 90, 107, 113, 114, 137, 139
Recursos de trabajo 47-48
Recursos financieros 183
Red PERT/CPM 108, 109, 119, 212
Bibliografía
Chatfield, Carl (2004), Microsoft Office Project 2007, Step by Step.

Microsoft Press.
Congreso Nacional de Gerencia de Proyectos 2007, Lima Perú. Project
Management Institute.
Manual de Instalación de Microsoft Project 2010.
Monzón C., Edwin (2006), Planificación de Proyectos con MS Project,
Infopuc - Pontificia Universidad Católica del Perú (PUCP).
Office (2010), “Ayuda y Procedimientos para Project Server” [en línea]
disponible en:8 http://office.microsoft.com/es-es/projectserver/
FX100739633082.aspx, recuperado en 2010.
PMI (2008 Edition). A guide to the Project management Body of knowledges.
PMBOK Guide.
PMI (2008), Project Management Institute. A guide to the Project
Management Body of Knowledge 3rd Edition v 1.2, Pennsylvania,
PMI, 2004.
PMI (2008), PMBOK 4ª. Edición. 2008.
PMI (2006), “Practice Standard for Work Breakdown Structures”.
Pennsylvania, 2nd Edition.
Quiroz G., Antonio (2006), Control de la Ejecución de Proyectos con MS
Project. Infopuc–PUCP.
Toro L. Francisco (2009), Gestión de Proyectos: con Enfoque del PMI al
usar Project & Excel. Editorial ECOE Ltda.2010.
Otros textos de su interés
• Gestión de proyectos con

enfoque PMI. Project y Excel,
Francisco J. Toro
• Costos ABC y presupuestos,

Francisco J. Toro
• Gerencia de proyectos
orientada a la salud,
Francisco J. Toro
• Costos, decisiones empresariales,

Carlos A. Rincón
• Cuentas de orden. Hacia la revelación y

el control, Javier E. García
• Información financiera IFRS (NIIF),

Samuel A. Mantilla
• Modelos financieros con Excel,

Jairo Gutiérrez
• Plan Único de Cuentas - PUC,

Enrique Romero Romero
• Planeación y evaluación financiera,

Ángel M. Fierro
• Presupuesto y contabilidad pública,

Enrique Romero Romero
• Pronóstico empresarial,
Carlos J. Bello
• Proyecto de inversión para las PYME,

Juan A. Flórez
Administración
de proyectos
de informática
El manejo de proyectos en el área de la informática ha atraído especial interés
desde hace algún tiempo, por parte de los teóricos y de los practicantes rasos.
Las fases de iniciación, planeación, ejecución y control, y su cierre se describen
en términos de los principios impulsados por el Project Management Institute
(PMI)™, observando las guías generales y enfoques metodológicos que estableció
este instituto para el manejo gerencial de proyectos, los cuales permanecen como
una guía en el uso de mecanismos y métodos aplicables a la gestión de todo tipo
de proyectos.
Dada la gran diversidad de metodologías que en la actualidad han surgido para

el manejo de este tipo de proyectos, el autor optó por explicar sus facilidades y
afinidades en diversos aspectos de las fases de planeación, seguimiento y control.
Por su especial relevancia en los últimos tiempos, se hace una explicación de la
metodología SCRUM al final del libro. Tampoco se pretende entrar en detalles de
las varias técnicas actualmente empleadas por diversas empresas para trazar un
plan estratégico como sostén de sus proyectos de cualquier tipo.
Se hacen múltiples referencias a los principios y recomendaciones trazadas por

el International Technology Infrastructure Library (ITIL) puesto que se ha logrado
constituir en un conjunto bien documentado de mejores prácticas orientadas a
la administración de los servicios de Tecnologías de Información (TI), a través de
un enfoque basado en el análisis de todos los procesos empresariales.
Colección: Ciencias Administrativas

Área: Administración
e-ISBN 978958648817-4

Administración de Proyectos de Informática - Francisco J. Toro López PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Administración de Proyectos de Informática - Francisco J. Toro López PDF

Cargado por

Copyright:

Formatos disponibles

ECOE EDICIONES Francisco J.

Su experiencia profesional actual la

Actualmente es profesor de las

Francisco J. Toro López

Toro López, Francisco J.

Incluye índice temático. -- Bibliografía al final del texto

1. Administración de proyectos informáticos

CDD: 658.404 ed. 23 CO-BoBN– a830395

Colección: Ciencias Administrativas

Primera edición: Bogotá, 2013

© Francisco J. Toro López

Coordinación editorial: Alexander Acosta Q.

Impreso y hecho en Colombia.

Observaciones generales ................................................................ IX

FRANCISCO J. TORO LÓPEZ V

La cadena de valores de los procesos del negocio ................... 33

FRANCISCO J. TORO LÓPEZ VII

Índice temático .............................................................................. 221

Bibliografía .................................................................................... 223

Los ejercicios y ejemplos mencionados vienen en formato de presentación

No es la intención del autor explicar todas o la mayoría de las técnicas

En este orden de ideas, se va a hacer algunas referencias breves a

FRANCISCO J. TORO LÓPEZ IX

conjunto bien documentado de mejores prácticas orientadas a la

Las instrucciones relativas a los ejemplos y casos que usen herramientas

Las teclas de acceso rápido son opciones de un programa que se ejecutan

El término “clic” se utilizará en este libro para aludir a la acción de

A la Memoria de mi inolvidable hermano

Una mención por su generosa y siempre franca aptitud

FRANCISCO J. TORO LÓPEZ XI

FRANCISCO J. TORO LÓPEZ 1

prácticas. Las buenas prácticas, como lo describe el Project Management

En este trabajo se va a hacer constante referencia a los principios y métodos

Estas últimas se usan en empresas que desarrollan constantemente

Es absolutamente necesario decir en este momento que el proceso de llevar a

En los últimos años se ha invertido mucho dinero en la adecuación o

Uno de los objetivos primordiales que se impone es entonces elaborar y

Para el desarrollo de un Plan Estratégico de Tecnología Informática se

FRANCISCO J. TORO LÓPEZ 3

7. Entregar, al término de la prestación del servicio, el informe del Plan

El desarrollo de un Plan Estratégico de Tecnología Informática refuerza y

Al así hacerlo, se obtienen los siguientes beneficios del proceso:

1.2 Industria de la informática en los últimos años

Dos naciones se han destacado últimamente en forma notoria en el

China 1,6 3,7 2,1 4,4

India 0,6 2,8 0,8 2,6

China + India 2,2 6,5 2,9 7,0

EEUU 16,7 16,2 10,8 13,6

Fuente: OMC, 2010.

Los STI suponen más de la mitad de las exportaciones indias de servicios. En

En ese sector, la India se ha destacado por la alta relación calidad-costo de

FRANCISCO J. TORO LÓPEZ 5

Están haciendo, además, procesos subcontratados basados en

El atractivo de la India para la subcontratación internacional de STI

Algunas consideraciones sobre el medio latinoamericano

¿Cuál es la causa principal de tanto fracaso? En casi todas las situaciones,

2. La India es el país con mayor población de habla inglesa en todo el mundo!

Algunos teóricos de los Estados Unidos de Norteamérica (EUA) dicen que

Para cuadrar la traducción y generar una palabra llamativa en Castellano

“Relevant” quiere decir pertinente, aplicable, útil para quienes están

“Achievable” es REALIZABLE, esto es, que un proyecto, en vez de ser un

“Measurable” es MEDIBLE, o sea que a cualquier proyecto, cuando ya está

FRANCISCO J. TORO LÓPEZ 7