INSTITUTO TECNOLÓGICO

SUPERIOR DE CINTALAPA

ADMINISTRACIÓN DE LA
CONSTRUCCIÓN

 UNIDAD 4: PLANIFICACIÓN,
PROGRAMACIÓN Y CONTROL DE
LOS OBJETIVOS DE PROYECTOS
DE CONSTRUCCIÓN.
 UNIDAD 5: DIRECCIÓN TÉCNICA
Y SUPERVISIÓN DE LA FASE DE
EJECUCIÓN DE PROYECTOS DE
CONSTRUCCIÓN

ING. JOSÉ DANIEL LUNA MACÍAS

ESMERALDA DE JESÚS GUERRA

ESTRADA

INGENIERÍA CIVIL
6º”M”
  Los Requerimientos de un Proyecto
 Actividades en la Gestión de Requerimientos
 Pasos de la Gestión de Requerimientos
 Introducción a la Recopilación de Requerimientos
TAREA 1

 Validar requerimientos con el usuario

 Control de cambios a los requerimientos
 Ciclo de vida: fases del proyecto
 Administración de la configuración
 Alcance del producto vs. Alcance del proyecto
 Importancia y creación de una Estructura de Desglose de
Trabajo (EDT) paso a paso
 Las Tres Principales Ventajas de la Línea Base de un
Proyecto
 Identificar Stakeholders... ¿Por qué molestarse en esto?
 Apostando al caballo ganador
 Lidiando con un “Scope Creep” en proyectos de desarrollo
de software
 Tarea 1.
Subtema 4.1. Planificación, programación y control del Objetivo Configuración y
Alcance

LOS REQUERIMIENTOS DE UN PROYECTO

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

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

Definición de requerimiento y Stakeholders (Interesados)

Según la definición del PMBOK®, un requerimiento es la condición o capacidad

que debe tener un sistema, producto, servicio o componente para satisfacer un
contrato, estándar, especificación, u otros documentos formalmente establecido.

Son todas aquellas características observables que cualquier interesado desea

que estén contenidas en el sistema. Como requisitos se incluyen las
necesidades, deseos y expectativas del patrocinador, cliente, usuarios, y otros
interesados.

Como requerimiento se podría establecer:

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

Definiendo el concepto de stakeholder (interesado) como alguien que está

afectado por el proyecto que se desarrolla, podremos encontrar que hay de dos
tipos:
 Usuarios: Aquellos que utilizaran el sistema.
 Clientes:aquellos que requieren el sistema y son los responsables de su
validación o aprobación.
Es importante distinguir entre estos dos grupos de interesados, dado que
muchas veces podremos encontrarnos que hay un conflicto entre los
 requerimientos de ambos. En la mayoría de los casos, los requerimientos de los
clientes tienen prioridad sobre los requerimientos de los usuarios.

Características de los requerimientos

Un requerimiento debe cumplir ciertos criterios y características:

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

Además de los criterios para los requerimientos individuales, para el conjunto de

ellos debe cumplirse:
 Independiente:Para comprender el requerimiento no debe ser necesario el
conocimiento de otro.
 Consistente: No debe existir ningún conflicto entre requerimientos. Los conflictos
pueden ser:

- Directos: Cuando ante una misma situación, cabe esperar comportamientos

diferentes.
- Indirectos: Se produce cuando no es posible cumplir con dos requisitos al
mismo tiempo, aunque describan funcionalidades distintas.
 Noredundante: Cada requerimiento debe ser formulado una sola vez, y no
sobreponerse con otros requerimientos.
 Completo:Un requerimiento debe ser especificado teniendo en cuenta todas las
condiciones que puedan ocurrir.

Organización y estructura de la gestión de requerimientos.

Según el origen y características, los requisitos pueden dividirse en diferentes
tipos., que pueden representarse en forma de pirámide, en cuyo nivel superior
se sitúan las necesidades de los interesados. En los niveles más bajos son
características, casos de uso y requisitos complementarios tal como se muestra
en la figura:
 Necesidad: Un interesado demanda un requerimiento.
 Característica:
Un servicio proporcionado por el sistema, por lo general
formulado por un analista de negocios.
 Caso de uso: Una descripción del comportamiento del sistema descrito como
una secuencia de acciones.
 Requisitocomplementario: Otro requisito (generalmente no funcional) que no
puede ser contemplado en los casos de uso.
 Caso de prueba: Una especificación de las entradas necesarias para una prueba,
las condiciones de ejecución y resultados esperados. Tiene el papel de
comprobar si los casos de uso derivados de los casos de prueba y los requisitos
complementarios se aplican correctamente.
 Escenario: Una secuencia específica de acciones o una ruta de acceso
específica a través de un caso de uso. Ayudan a derivar en casos de uso a partir
de los casos de prueba y facilitan el diseño e implementación a través de los
casos de uso.

Con bastante frecuencia, a diferentes niveles de los requisitos, se especifican

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

Trazabilidad

La trazabilidad de los requerimientos se refiere a la documentación de la vida de

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

Los requerimientos surgen de diversas fuentes: el cliente, el manager, el usuario

final, etc... Todas y cada una de ellas tienen diferentes requerimientos para el
producto. Utilizando la trazabilidad, puede seguirse el historial de una
característica implementada hasta las personas o grupos que la solicitaron
 durante la generación de los requerimientos, permitiendo un rápido análisis en
cada fase del proyecto para:
 Determinar la visión original y permitir una discusión controlada de los cambios
en el alcance.
 Determinar quéelementos se verán afectados cuando consideramos agregar un
nuevo requerimiento o modificar uno ya existente.
 Verificar que el requerimiento contempla todos lo que el interesado solicitó.
 Evitar
el Gold Platting: Verificar que la aplicación no implementa funcionalidades
no demandadas por el cliente.

ACTIVIDADES EN LA GESTIÓN DE REQUERIMIENTOS

La gestión de requerimientos, entendida como el conjunto de actividades que
abarcan la recopilación, control, análisis, filtrado y documentación de los
requisitos del sistema, consiste en tres actividades fundamentales:

Generación de requerimientos:

Es la habilidad de entender las necesidades de los interesados, y recopilarlos en

un repositorio para futuros análisis. Las necesidades pueden ser expresadas de
forma abstracta y en términos de problemas (Quiero reducir mis ratios de error
en un 35%) o bien concretos y en términos de una solución (Debe haber un botón
rojo de paro en la consola).

En ambos casos las necesidades son conocidas como características

Evaluación de requerimientos:

Es la habilidad de discernir qué características son apropiadas para incluir en el

producto, dado que raramente es posible satisfacer todas las características
demandadas por cada uno de los interesados. La evaluación tiene en
consideración todas las realidades del mercado y toma la decisión acerca de qué
características se implementarán, cuales lo serán en la próxima versión, y cuales
se aplazarán hasta más tarde.

Especificación de requerimientos:

Es la habilidad de detallar el comportamiento de un sistema. En cada estadio del

proceso de desarrollo, variaran la forma y el nivel de detalle en la especificación
de los requerimientos. Para ilustrarlo, considérese un proceso estándar de
desarrollo en cinco fases: Investigación, Viabilidad, diseño, construcción y test,
lanzamiento.
Investigación

En la fase de investigación, se recopilan requerimientos entre los usuarios y los

miembros del equipo de desarrollo. Para cada uno de ellos se formulan
cuestiones similares acerca de cuáles son los logros, las restricciones y las
herramientas o procesos disponibles…Sólo cuando estos requerimientos sean
bien entendidos, se pueden desarrollar los requerimientos funcionales.

Hay que tener muy presente que los requerimientos no pueden ser
completamente definidos al inicio del proyecto. Algunos cambiarán, bien porque
sean simplemente suprimidos, o debido a los intereses y modificaciones que
afecten al ciclo de vida del proyecto.

Por ello, la flexibilidad en los planteamientos y las operaciones, son condiciones

para el éxito.

El entregable del estadio de investigación es un documento de requerimientos

que haya sido aprobado por todos los miembros del equipo. Después, y durante
el desarrollo, este documento será clave para prevenir la corrupción del alcance
o los cambios innecesarios.

Mientras que muchas organizaciones todavía utilizan solo documentos para

gestionar los requerimientos, otras gestionan a partir de herramientas de
software. Estas herramientas permiten gestionar los requerimientos en una base
de datos y acostumbran a tener funciones para automatizar la trazabilidad, como
por ejemplo permitir la vinculación electrónica entre la jerarquía de
requerimientos, el control de versiones y la gestión de cambios

Viabilidad

Durante el estudio de viabilidad, se determinan:

Los costes de los requerimientos: Para los requerimientos de usuario, se

comparan los costes actuales con los futuros, una vez se haya implementado el
nuevo sistema.

Los costes de operación: Indicarán qué departamento tiene presupuesto para

ello y cuál es el retorno de inversión para este producto, incluyendo la reducción
de costes si se desarrolla un nuevo sistema más fácil de utilizar.

Los costes técnicos: Están relacionados con los costes de desarrollo de software
y los costes del hardware. El equipo debe indagar si los nuevos equipos y
herramientas añadirán suficiente potencia de procesamiento para transferir
suficiente carga de trabajo del usuario al sistema que permita un ahorro
significativo de tiempo y costes al personal

El entregable para el estadio de estudio de viabilidad son la programación y el

presupuesto para el proyecto.

Diseño

Asumiendo que los costes han sido determinados con precisión y que los
beneficios a obtener son suficientemente importantes, el proyecto puede pasar
al estadio de diseño. En dicho estadio, la actividad principal de la gestión de
requerimientos es comparar los resultados del diseño con el documento de
requerimientos, para asegurarse de que el trabajo está contemplado dentro del
alcance.

Implementación y test

En el estadio de implementación y test, la actividad principal de la gestión de

requerimientos, es asegurar que el trabajo y el coste se desarrollan de acuerdo
con la programación y el presupuesto, y que las nuevas herramientas cumplen
de hecho con los requerimientos. La herramienta principal utilizada en este
estadio es la construcción de prototipos y el test iterativo. Para una aplicación de
software, la interfaz de usuario puede ser creada en papel y probada con los
usuarios potenciales, mientras está siendo creado el entorno de software. Los
resultados de dichos test son archivados en una guía de diseño de interfaz de
usuario y trasladado al equipo de diseño, cuando este esté listos para desarrollar
la interface. Esto ahorra tiempo y hace el trabajo mucho más fácil.

Lanzamiento

Podría pensarse que la gestión de requerimientos finaliza al entregar el producto,

pero no es del todo cierto. Desde este punto, se recopilan los datos provenientes
de la aceptación de la aplicación, y utilizados posteriormente en la fase de
investigación de la nueva generación o versión. Entonces, el proceso empieza
de nuevo.

PASOS DE LA GESTIÓN DE REQUERIMIENTOS

Una descripción simplificada de la gestión de requerimientos contiene los

siguientes pasos principales:

Establecer un plan de gestión de requisitos

Una de las primeras tareas en el proyecto es desarrollar un Plan de gestión de
requerimientos (RMP son sus siglas en ingles). El RMP describe el enfoque
general para gestionar los requerimientos del proyecto. El documento detalla
cómo se generan, organizan, modifican y trazan los requerimientos en el ciclo de
vida del proyecto. También describe todos los tipos de requerimientos y los
 atributos utilizados en el proyecto. Algunas cuestiones que debe clarificar el RPM
son:
 ¿Cómo deben usarse las herramientas de gestión de requerimientos?
 ¿Qué tipos de requerimientos serán trazados en el proyecto?
 ¿Cuáles son los atributos de estos requerimientos?
 ¿Dóndese crearan los requerimientos-en una base de datos o solo en
documentos?
 ¿Entre cuales requerimientos necesitamos implementar trazabilidad?
 ¿Qué documentos se requieren?
 ¿Qué requerimientos y documentos serán utilizados como contrato con un
proveedor? ¿Qué metodología será utilizada?
 ¿El
cliente necesita algún documento específico para cumplir con su proceso de
desarrollo?
 ¿Cómo se implementará la gestión de cambios?
 ¿Quéproceso garantizará que todos los requerimientos serán implementados y
comprobados?
 Qué requerimientos u opiniones necesitamos para generar informes?

Técnicas para la recopilación de requerimientos

La recopilación de requerimientos es un paso muy importante. Un error o mala
interpretación de un requisito en esta etapa propagará el problema a través del
ciclo de vida de desarrollo.

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

Entrevistas: Son utilizadas para recopilar información de los interesados. Sin

embargo, la predisposición y experiencias de la persona entrevistada influirán en
la obtención de resultados. Es conveniente la utilización de preguntas abiertas
que no sugieran una determinada respuesta.

Análisis de Documentos: Todo establecimiento de requisitos implica un cierto

estudio de los documentos que definen la razón de ser del proyecto, tales como
planes de negocio, estudios de mercado, contratos, etc.…

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

Talleres de Requisitos: Pueden estar diseñados para alcanzar la unificación de

criterios en cuanto a los requisitos de una capacidad en concreto. Conviene que
sean dirigidos y coordinados por un experto, y son normalmente cortos (uno o
varios días). Otras ventajas que a menudo consiguen es alentar el compromiso
de los participantes con el proyecto, fomentando el espíritu de grupo

Creación de prototipos: Consiste en la creación de una versión rápida y poco

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

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

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

Guiones gráficos: Son un conjunto de dibujos que representan un conjunto de

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

Análisis de interfaces: El diseño incorrecto de las interfaces es a menudo una de

las principales causas de sobrecoste y fracaso del producto. La identificación
temprana de las características de las interfaces externas clarifica el ámbito de
aplicación de producto, ayuda en el proceso de evaluación del riesgo, reduce los
costos de desarrollo del producto, y mejora la satisfacción del cliente.

Modelado: Es una representación de la realidad que pretende facilitar la

comprensión. El uso de prototipos y modelos ayuda a eliminar ambigüedades y
contradicciones, contribuyendo de forma notable al éxito del proyecto.

Desarrollo el documento de visión

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

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

El documento de visión debe contener la información esencial acerca del sistema

que está siendo desarrollado. Además de listar todas sus características, debe
contener:
 Una descripción general del producto.
 Un sumario con las capacidades del sistema.
 Toda la información que pueda ser requerida para comprender el propósito del
sistema.
También pueden listarse todas las necesidades de los interesados que no fueron
recogidas en otros documentos

Crear casos de uso

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

Los casos de uso:

 Son iniciados por un actor
 Modelan la interacción entre el interesado y el sistema
 Describen una secuencia de acciones
 Capturan los requerimientos funcionales
 Proporcionan algún valor para un actor
 Representan un completo y significativo flujo de eventos.

Especificación suplementaria
Las especificaciones suplementarias recogen aquellos requerimientos no
funcionales (usabilidad, fiabilidad, rendimiento,..) Y algunos requerimientos
funcionales internos del sistema que, por tanto, son difíciles de contemplar en
los casos de uso.

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

Tan pronto como se recopilan todos los requisitos, deberíamos diseñar una
forma de comprobar si se implementan correctamente en el producto final. Los
casos de prueba mostrarán a los evaluadores qué pasos deben realizarse para
probar todos los requisitos. En este paso nos concentraremos en la creación de
casos de prueba a partir de casos de uso.
Creación de casos de prueba a partir de especificaciones complementarias
El enfoque utilizado en el paso anterior no se aplica a las pruebas de los
requisitos complementarios. Dado que estos requisitos no se expresan como una
secuencia de acciones, el concepto de escenarios no se les aplica, y debe
desarrollarse un enfoque individual a cada uno de los requisitos
complementarios.

En este paso, también se diseñarán pruebas de infraestructura y cuestiones

relacionadas con la plataforma.

Diseño del sistema

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

INTRODUCCIÓN A LA RECOPILACIÓN DE REQUERIMIENTOS

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

Una de las principales formas de obtener dicha información es mediante

reuniones donde el analista debe guiar la entrevista y documentar todos los
puntos importantes que allí se vayan mencionando.

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

Debe de tomar en cuenta la opinión de los diferentes stakeholders del proyecto,

desde el responsable del área a la cual se le está desarrollando el sistema hasta
el usuario final para obtener los requerimientos más completos posibles.

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

Se recomienda utilizar mecanismos que faciliten la retroalimentación y

participación de usuarios, como es el caso de modelos, prototipos no funcionales
y casos de uso.

La información documentada en las minutas no reemplaza a los documentos

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

Durante la fase preliminar (Concepción en el caso del Proceso Unificado) hay

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

Los requerimientos documentados son la base para que el administrador realice

las estimaciones y el plan del proyecto en general. Para lo cual necesitará la
validación del usuario a todos los documentos donde se especifiquen los
requerimientos.

El administrador no debería asumir nada. Es importante que se asegure que está

entendiendo correctamente lo que el usuario quiso decir, por lo que debe validar
la información escrita y de preferencia formalizarla por medio de firmas de
aprobación de los usuarios.

VALIDAR REQUERIMIENTOS CON EL USUARIO

Parte indispensable del proyecto consiste en asegurar que el equipo de

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

El documento de visión debe validarlo el usuario al completarse la fase de

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

CONTROL DE CAMBIOS A LOS REQUERIMIENTOS

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

El problema no son los cambios a los requerimientos, sino el hecho de que se

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

El control de cambios es el proceso mediante el cual se asegura que no se

realicen cambios que afecten el éxito del proyecto, y que aquellos que se
implementen sean analizados, negociados y planeados de una manera
adecuada.
Estando dentro de la fase de Elaboración o después de haber negociado el
alcance y el plan de trabajo, si el usuario llegara a solicitar un cambio a los
requerimientos establecidos, el administrador u otra persona debería de llenar
una solicitud de cambio con la descripción del cambio.

El cambio es analizado y se evalúa el impacto en costo y tiempo, y si es algo

aceptable para los recursos disponibles y el tiempo que se le puede asignar a
dicho proyecto, además de ser aceptado por el usuario y autorizado por la
gerencia, entonces se acepta la solicitud. En caso contrario debe registrarse
como una solicitud rechazada.

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

Independientemente de que la solicitud sea aceptada o rechazada debe

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

CICLO DE VIDA - FASES DEL PROYECTO

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

Cascada + Espiral = Iterativo e Incremental

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

Este ciclo de vida se divide en distintas fases, coincidiendo los procesos

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

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

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

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

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

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

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

ADMINISTRACIÓN DE LA CONFIGURACIÓN

Se debe contar con un directorio con una estructura estándar establecida para
los proyectos, dentro de un repositorio de administración de la configuración
(p.ej. CVS). Si es un proyecto o módulo nuevo se creará un nuevo directorio en
el repositorio. Si se trata de mantenimiento se utilizará el que ya exista para ese
proyecto.

Se deben de establecer y controlar los permisos necesarios para el acceso y

mantenimiento de dicha información para el equipo de trabajo y la gente
involucrada en su elaboración.

Este repositorio puede estar en el servidor central de proyectos y lo debe de

crear el administrador de la configuración al comenzar un nuevo proyecto en la
fase de concepción, a solicitud del líder de proyecto.

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

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

ALCANCE DEL PRODUCTO VS. ALCANCE DEL PROYECTO

Alcance del proyecto y alcance del producto son dos conceptos importantes
dentro de la Gestión de Proyectos que muchas veces se confunden y no se sabe
qué enmarca cada uno de ellos, ambos conceptos están estrechamente
relacionados y vinculados, por lo tanto, es primordial para el Líder de Proyecto
conocer sus significados.

Todo proyecto que se lleva a cabo es con la finalidad de obtener un resultado.

Este resultado puede ser un producto o servicio que se crea con el objetivo de
cubrir o satisfacer una necesidad específica que ha sido identificada.

El alcance del producto lo podemos entender como las características o

funcionalidades que tendrá el producto o servicio que se obtiene como resultado
de un proyecto. Estas características son de tipo técnico, características
relacionadas al plazo de finalización (plazo de entrega) y características de costo
final del producto o servicio. Las funcionalidades que tendrá el producto o
servicio se originan a partir de una serie de requisitos dados por el cliente o la
organización ejecutante, que indican cómo se quiere el producto o servicio. Por
lo tanto, para saber si el alcance del producto se cumplió, se verifica y evalúa
que todos los requisitos dados están incluidos dentro del producto o servicio
resultante, es decir que sea tal cual el cliente lo solicitó. De esta forma se certifica
que el alcance del producto sea el correcto y se logre la satisfacción final del
cliente.

El alcance del proyecto por su parte son las actividades o trabajo que deben
llevarse a cabo para poder entregar el producto o servicio con las características
o funcionalidades requeridas de acuerdo a los requisitos dados por el cliente o
la organización ejecutante. Es decir, es todo el esfuerzo que debe realizarse para
cumplir con el alcance del producto. Entre las distintas actividades que incluye el
alcance del proyecto se pueden encontrar, por ejemplo: gestión de tiempos,
gestión de costos, adquisición del personal necesario, gestión de calidad, gestión
de proveedores, etc.

Además de estas actividades, se encuentran las actividades para elaborar el

producto o servicio en sí. Para saber si el alcance del proyecto se cumplió, se
mide contra el plan de dirección del proyecto (también conocido como plan de
gestión del proyecto), que contiene la línea base del alcance. El plan de dirección
del proyecto es el documento principal que contiene los planes de cada área de
conocimiento (llamados planes subsidiarios) y que guía todo el proyecto.

Por lo tanto se puede decir que como las actividades para elaborar el producto
o servicio son una de las diferentes actividades que se ejecutarán en el proyecto,
el alcance del producto está contenido dentro del alcance del proyecto, tal como
lo muestra el siguiente gráfico:
 Para aclarar más el tema, veamos un ejemplo.

Un importante ejecutivo nos ha encomendado la realización de un proyecto el

cual tiene como objetivo final la construcción de un escritorio para la nueva
oficina que quiere implementar.

Durante las distintas reuniones con el ejecutivo, éste nos ha dado una serie de
características que debe tener el escritorio que desea, las cuales son las
siguientes:

- Escritorio de 4 patas
- 2 cajones, que tenga llave cada uno
- De color negro
- Base de vidrio templado.

Todas esas características mencionadas son los requisitos del cliente que deben
ser plasmados en el producto final, en este caso el escritorio. Estas
características forman parte del alcance del producto. Al final del proyecto, el
ejecutivo revisará y verificará el producto para comprobar que sea tal y como lo
pidió. Si el escritorio fue fabricado como se solicitó, se puede decir que se
cumplió con el alcancel del producto. De lo contrario se tendrán que volver a
revisar los requisitos del cliente para construirlo apegado a ellos.

Para la construcción del producto, además de realizar las actividades para

construir el escritorio, se deben considerar otras actividades como por ejemplo:
determinar el tiempo y costos de fabricación del escritorio; conseguir al personal
necesario como carpinteros, ebanistas, ayudantes; buscar proveedores para
conseguir los materiales como madera, clavos, pegamento, pintura, etc. Todas
estas actividades forman el alcance del proyecto, es decir todo el esfuerzo que
se realizará para finalmente entregar el escritorio.

Como conclusión se puede decir que:

 Todo proyecto se origina a partir de la identificación de una necesidad que debe
ser satisfecha y tendrá como resultado final un producto o servicio.
 El producto o servicio que se quiere obtener tendrá características y
funcionalidades que deben ser cubiertas para satisfacer al cliente.
 Las características del producto o servicio forman el alcance del producto, el cual
será verificado contra los requisitos dados por el cliente para comprobar que se
cumplieron.
 Todo el esfuerzo o actividades que se realizarán para la elaboración del producto
o servicio forman el alcance del proyecto, el cual se verificará contra el plan de
dirección del proyecto que es el documento principal que guía todo el proyecto.
 El alcance del proyecto contiene el alcance del producto.
IMPORTANCIA Y CREACIÓN DE UNA ESTRUCTURA DE DESGLOSE DE
TRABAJO (EDT) PASO A PASO
Para crear la EDT, el trabajo se debe ir descomponiendo en componente más
pequeños y más fáciles de manejar hasta llegar a un nivel de detalle claro y
entendible. Este último nivel de la EDT se le conoce como Paquete de Trabajo y
es el nivel donde se van a mostrar los entregables que tendrá el proyecto.

Cuando se descompone el trabajo, la EDT muestra una representación

organizada de todo el esfuerzo que se requiere para completar el proyecto y
debe estar orientada a los entregables del proyecto que son el resultado del
esfuerzo y no el esfuerzo en sí. Mejor dicho la EDT debe mostrar lo que se va a
entregar (productos entregables) y no las actividades que se realizarán para
obtener los entregables. Esto es un error común, ya que en algunas ocasiones
se cree que en la EDT se muestran las actividades que se van a realizar para
crear el producto. Lo que se muestra son los entregables del proyecto que deben
estar en lenguaje de entregables, es decir se debe mostrar el nombre de algo
que se va a obtener como resultado y se va a entregar. Por ejemplo si uno de
nuestros entregables es un manual de instalación, en la EDT debe mostrarse
Manual de Instalación como producto entregable y no debería aparecer Elaborar
manual de instalación ya que eso sería una actividad que involucra esfuerzo,
tiempo y recursos. En la EDT no se muestra actividades, fechas, ni recursos.

El nivel de detalle que debe tener la EDT debe ser lo suficientemente detallado
para que, en una etapa posterior, se pueda estimar tiempos, costos y recursos
de las actividades para elaborar cada uno de los entregables. Si al descomponer
se llega a un punto en el cual todavía no puede estimarse con precisión los
tiempos, costos y recursos entonces se debería seguir descomponiendo hasta
tener un nivel en el cual sí se puede realizar una estimación más exacta.

Una vez hecha la descomposición y teniendo lista la EDT, se puede decir que se
tiene organizado (de forma jerárquica) y definido el alcance total del proyecto
que se muestra en forma de entregables. De este modo la EDT también sirve
como una buena herramienta de comunicación con los interesados del proyecto
ya que éstos podrán saber, a través de la representación jerárquica que muestra
la EDT, cuáles son los entregables que se elaborarán.

La EDT se crea a partir del Enunciado del Alcance del proyecto. El Enunciado
del Alcance es un documento donde se detalla el alcance total del proyecto, es
decir lo que incluye y no incluye el proyecto, los entregables que se van a
generar, así como los supuestos y restricciones que se van a manejar en el
desarrollo del proyecto. Justamente como en el Enunciado del Alcance del
proyecto se definen los entregables, la EDT se basa en este documento para su
creación.

A continuación veamos un ejemplo de construcción de una EDT paso a paso,

que ayude a entender mejor su estructura, composición y jerarquía.

Una familia decide remodelar los muebles de su sala y comedor y nos ha

encargado la fabricación de todos los muebles que utilizarán en esos 2
ambientes. Una vez definido y aprobado el alcance del proyecto con ayuda del
cliente y habiendo elaborado el Enunciado del Alcance donde se indican los
entregables, supuestos y restricciones, nos disponemos a crear la EDT para
plasmar de forma jerárquica los entregables del proyecto.

La EDT del proyecto se muestra a continuación:

Se puede notar que en el 1er nivel está el nombre del proyecto, en nuestro caso
es Proyecto Muebles. Como el proyecto se trata de fabricar tanto los muebles de
la sala como del comedor, podemos separar los muebles que se fabricarán para
cada uno de estos ambientes. Colocamos Muebles de Sala y Muebles de
Comedor como 2do nivel. Dentro de cada una de estas ramas se irá
descomponiendo más a detalle. Tomemos la rama Muebles de Sala para seguir
explicando el ejemplo. Para el caso de la sala se acordó con el cliente fabricar
las mesas y sillones de ese ambiente por tal motivo utilizamos estas dos
categorías de muebles para ir descomponiendo más los entregables. Si solo
descomponemos hasta el nivel de mesas y sillones, esto sería muy genérico
porque en la sala habrían diferentes tipos de mesas y diferentes tipos de sillones
con lo cual no se ha llegado a un nivel más detallado y se tiene que seguir
descomponiendo. En la rama Mesas tenemos: Mesa de centro y Mesa de
adornos. Mientras que en la rama Sillones tenemos: Sillón de 3 cuerpos, Sillón
de 2 cuerpos y Sillón individual. Se podría seguir descomponiendo aún más ya
que se pudo haber acordado con el cliente fabricar Mesas de adornos de
diferentes tamaños o Sillones individuales de diferentes tipos de material. En ese
caso se tendría que descomponer más a detalle. Para fines del ejemplo
llegaremos sólo hasta el nivel mostrado. La misma secuencia de pasos se sigue
para la rama Muebles de Comedor. Como se mencionó, el último nivel de la EDT
se llama Paquetes de Trabajo y es donde se muestran los entregables que se
elaborarán en el proyecto.

Nótese en el ejemplo que los componentes de la EDT se han colocado en

lenguaje de entregables como Muebles de Sala, Sillones, Sillón individual. Esto
debido a que la Estructura de Desglose de Trabajo muestra la estructura
jerárquica de los entregables del proyecto. Sería un error colocar el nombre de
una actividad en la EDT, por ejemplo “Fabricar sillón individual”.

Una vez lista la EDT, ésta sirve como base para definir las actividades que se
realizarán para elaborar cada uno de los entregables. Por ejemplo para el
entregable Sillón individual se pueden definir actividades como: definir medidas
de mueble, elaborar plano de fabricación, conseguir madera, unir partes del
mueble, etc. El proceso de definir actividades corresponde a la Gestión de
Tiempos.

Es muy importante asignar un código a cada componente de la EDT para

identificarlos y ubicarlos rápidamente. El código se asigna al “padre” y luego se
le va asignando un código asociado a sus “hijos”. Tomando el EDT construido
se podrían asignar los siguientes códigos:

Junto con la EDT se debe crear también el diccionario de EDT que es un

documento que respalda a la EDT y proporciona una descripción más detallada
de este componente. En este diccionario se puede encontrar información como:
identificador del código, descripción del trabajo, responsable del entregable,
estimados de costos, recursos asociados, criterios de aceptación, entre otros.

Como conclusión final podemos decir que la EDT es uno de los componentes
más importantes dentro de la Gestión de Proyectos porque es la base sobra la
cual se construye el proyecto ya que muestra de forma jerárquica el alcance total
del proyecto a través de entregables y sirve como herramienta de comunicación
con los interesados.
 LAS TRES PRINCIPALES VENTAJAS DE LA LÍNEA BASE DE UN
PROYECTO

Cuando se ha finalizado la planeación de un proyecto y se tienen previstas las

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

¿Qué es una Línea Base?

Primeramente veremos que una Línea Base es un conjunto de valores

almacenados, tales como:
 Calendario original con fechas de inicio y terminación.
 Esfuerzo planificado (puede ser expresado en horas).
 Costo presupuestado.
 Ingresos presupuestados.

¿Por qué una Línea Base?

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

 Capacidad de evaluar el desempeño.
 Cálculo del valor devengado.
 Estimación exacta del futuro mejorado.

Evaluación del desempeño

Si tenemos los conocimientos sobre una planificación anterior, podemos

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

Esta es una forma un tanto rudimentaria de hacer la evaluación del desempeño,

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

Valor Devengado

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

Esto permitirá observar las tendencias en el desempeño y de este modo predecir

los recorridos potenciales. En un nivel de tarea individual, el valor devengado es
un buen indicador para conocer el tiempo y costo utilizado hasta el momento;
comparado con la cifra tiempo/costo que en realidad ha sido gastada.

Sin embargo, se aconseja no transmitir demasiada confianza sobre tales

previsiones, sobre todo en las etapas iniciales del ciclo de vida del proyecto, ya
que pocas tareas han sido iniciadas o completadas; a medida que el tiempo
avanza la exactitud de las predicciones se irán incrementando gradualmente.

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

Estimación mejorada

Cuando se crea un plan se estima cuánto tiempo tomará la realización de cada

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

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

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

Si nuestro software de administración de proyectos tiene una plantilla instalada,

al final de cada proyecto podemos usar los datos de discrepancia para actualizar
dicha plantilla de tareas con las estimaciones ya revisadas.
 Conclusión

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

IDENTIFICAR STAKEHOLDERS... ¿POR QUÉ MOLESTARSE EN ESTO?

Bajo el nombre “Identificar Stakeholders”, el PMI® decidió exaltar esta actividad

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

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

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

los stakeholders:
 Losstakeholders son todas aquellas partes que podrían ser impactados positiva
o negativamente al término del proyecto
 Los stakeholders pueden ganar o perder a través del éxito o fracaso del proyecto

 Los stakeholders pueden tener diferentes niveles de autoridad, los cuales

afectarán su forma de ejercer influencia sobre el proyecto y sus entregables
 Los stakeholders serán afectados por los resultados del proyecto

Es imperativo identificar a todas las personas y organizaciones que serán

impactadas por el proyecto y posteriormente documentar la información
relevante respecto a sus intereses, participación e impactos sobre el éxito del
proyecto. En este ámbito, el PMBOK® sugiere usar dos salidas tempranas para
la identificación de stakeholders en el proyecto:
 La primera disponible es la salida proveniente del desarrollo del Acta Constitutiva
del Proyecto, la cual puede contener una lista de los clientes, patrocinadores,
ejecutivos, equipo del proyecto o entidades que son externas al desarrollo de la
organización participante en el proyecto. Aquí es recomendable sostener un
encuentro por separado con los personajes identificados en el acta y
preguntarles si conocen de otros que puedan figurar como stakeholders.
 Siel proyecto es el resultado de una actividad de aprovisionamiento o está
basado en un contrato establecido, es importante usar los documentos de
adquisición para identificar todas las partes dentro del contrato que podrían ser
stakeholders claves para el proyecto. Los proveedores que participan en el
contrato también podrían ser considerados para la identificación de los
 interesados en el proyecto. Usar un contrato hace el proceso un poco más fácil,
ya que las diferentes interfases del contrato deberían ser enlistadas.

El acta constitutiva del proyecto y las indicaciones de los documentos de

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

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

¿Qué necesitamos saber sobre los stakeholders?, se requiere conocer

diferentes niveles de datos acerca de los interesados identificados para poder
manejar apropiadamente las relaciones con ellos y establecer un Plan de
Comunicaciones. Estos son los factores claves que se deben recoger de los
stakeholders:
 ¿Quién es el stakeholder por su nombre?; No identificar a algún stakeholder
como una clase dentro de un grupo de personas, tal como: Gerente Funcional o
Ejecutivo Senior. Se tiene que solicitar el nombre, información de contacto y
posición adentro de la organización.
 ¿Cuál es la naturaleza de su interés en el proyecto? ¿Personal o profesional?,
Identificar qué ganarán con el éxito o con el fracaso, estableciendo claramente
cuánto y de qué forma. Hay que capturar sus principales necesidades,
expectativa principal e influencia potencial en el proyecto o fase dentro del ciclo
de vida.
 ¿Qué esperan los stakeholders del administrador del proyecto?; La mejor forma
de determinar esto es teniendo un encuentro cara a cara con los stakeholders
claves, tales como clientes o patrocinadores. Esto puede resolver cualquier
diferencia entre lo que ellos esperan y lo que el project manager cree que debería
esperar.
 ¿Qué esperar de los stakeholders?, Este es el lado contrario de la pregunta
previa. Es definitivamente necesario establecer las expectativas y darse cuenta
que no se trata de decirle al stakeholder, lo que debe hacer o cómo actuar. Si se
hace correctamente se le estará proporcionando al stakeholder una descripción
del apoyo que el project manager necesita.
 ¿Cuálesson las prioridades de vigilancia de los interesados? Esto significa que
de los principales elementos de éxito y control, el stakeholder desea mayor
monitoreo sobre el calendario, costos, desempeño y/o calidad.
 A continuación revisaremos la clasificación del desempeño de los stakeholders
en grupos internos o externos y los papeles que juegan dentro de un proyecto.

Stakeholders internos: La mayoría de los stakeholders claves son personas que

laboran dentro de la organización sobre la cual se va a desarrollar el proyecto.
En este grupo encontramos:
 Clientes
internos: Normalmente son personas para quienes el project manager
está haciendo el trabajo y tienen una necesidad particular en que el proyecto
pueda ser dirigido a feliz término. A menudo, los clientes internos pagan por el
proyecto y por lo tanto reciben impactos en sus negocios a partir de los
entregables del proyecto.
 Patrocinador del proyecto: Normalmente, no es una posición específica dentro
de la organización, más bien es un rol jugado en un proyecto. El papel del
patrocinador es típicamente un representante de alta jerarquía quien tiene un
gran interés en los resultados del proyecto. Este rol puede ser invalorable para
el project manager cuando enfrenta problemas o asuntos que van más allá de
su ámbito de influencia. El sponsor puede facilitar decisiones y contribuir con la
asignación de recursos. Un patrocinador puede ser un miembro de la dirección
quien tiene un interés en el éxito o fracaso en el proyecto. Hay que describirles
sus roles, así como las expectativas del administrador del proyecto. Después de
todo, la dirección de la empresa debería estar muy dispuesta a contribuir con el
éxito.
 Equipo central del proyecto: Generalmente están ligados cercanamente para
hacer el trabajo. En la mayoría de los casos el equipo principal es un grupo
relativamente pequeño compuesto a partir de diferentes departamentos de
trabajos necesarios para completar el proyecto.
 Proveedores de recursos funcionales: Asegurar los recursos puede depender del
tipo de estructura de la organización que requiere el proyecto. En los proyectos
se debe solicitar recursos de otros departamentos, pidiéndoselos al gerente
funcional adecuado.
 Supervisordel administrador de proyectos: Simplemente es el jefe del project
manager y tiene un gran interés en el éxito del proyecto. El líder del proyecto
debe mantenerlo informado en todo momento y protegerlo para que no reciba
sorpresas desagradables.
 Diferentes grupos de apoyo: Esos grupos existen dentro de la organización y son
los relativos a la parte legal, contabilidad, procesamiento de datos y recursos
humanos de la empresa. El papel de éstos hacia el proyecto es más de apoyo
que trabajo activo, dependiendo de las necesidades específicas del proyecto.
Aquí hay que considerar si uno de eso grupos debería tener un representante en
las reuniones del equipo principal.

Stakeholders externos: Los de este grupo tienen interés intrínseco en el proyecto

más, aunque no formen parte de la organización. En este grupo encontramos:
 Clientes externos: Se caracterizan típicamente por los contratos.
 Grupos de usuarios: Se debe considerar a los grupos de usuarios si el proyecto
desarrolla o fabrica un producto que será comercializado y vendido a los
 consumidores. El líder del proyecto puede consultar al stakeholder externo
acerca de gustos, desagrados, preferencias y elecciones que tal vez su
estrategia de marketing ha asilado para el futuro o para un producto producido
similarmente.
 Proveedores: El proyecto puede requerir materiales que deben ser conseguidos
a partir de compañías externas. El project manager debe utilizar la lista de
proveedores principales en el caso de que la empresa tenga una.
 Contratistasy consultores: Al igual que ocurre con los materiales, los cuales son
adquiridos a proveedores, el líder del proyecto también puede utilizar tanto a
contratistas como consultores para realizar ciertas labores o requerir de algunos
servicios. En este caso es recomendable usar un criterio basado en el
desempeño y un registro verificable al momento de seleccionar a estos
stakeholders.
Hay que colocar, como mínimo, nombre, información de contacto, posición
dentro de la organización, rol dentro del proyecto, su expectativa primordial, su
principal requerimiento, e influencia potencial en el proyecto o fase durante el
ciclo de vida. Por último, se debe incluir una identificación de los stakeholders,
ya sean internos o externos.

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

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

Puesto que la Estrategia de Administración de Stakeholders puede contener

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

El Registro de Stakeholders y la Estrategia de Administración de Stakeholders

serán insumos esenciales para los procesos de Plan de Comunicación y Manejo
de las Expectativas de los Stakeholders.

Como última recomendación, solamente les puedo decir que tengan cuidado con
otras interfases que ciertamente no son humanas y que no pueden llamarse
stakeholders, pero pueden afectar el proyecto, al menos tanto como cualquier
interfaz humana. Éstas incluyen políticas de la organización, procedimientos,
cultura y otras normatividades.
 APOSTANDO AL CABALLO GANADOR

Planear el proyecto es una actividad muchas veces menospreciada, o por lo

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

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

El plan no es un Gantt

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

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

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

Fácil, ¿No es cierto?

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

1. El problema u oportunidad que se atiende.

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

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

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

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

Este es un vistazo rápido y simple a la planeación, cada rubro mencionado aquí

se puede abordar a mayor profundidad e incluso hay consideraciones
adicionales, que espero poder revisar con ustedes más adelante. Por lo pronto
espero que esta breve explicación les sirva para comenzar su labor de
planeación.

LIDIANDO CON UN “SCOPE CREEP” EN PROYECTOS DE DESARROLLO

DE SOFTWARE

Un Scope Creep es un riesgo significativo en proyectos de desarrollo de

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

¿Qué es un Scope Creep?

El desarrollo de un nuevo software surge generalmente como resultado de la

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

Lo anterior es el “scope” o alcance del proyecto. En esta fase los planes del
proyecto están preparados y basados en la estimación para el desarrollo y
entrega de una funcionalidad determinada, por lo que una fecha de finalización
es acordada.

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

¿Cómo lidiar con un Scope Creep?

Es importante que una especificación funcional esté producida desde el principio,

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

La especificación funcional debe ser acordada y firmada por el cliente y debería

incluir una Definición de Alcance. Esto expresa que solamente la funcionalidad,
la cual está explícitamente descrita en la especificación está incluida en el
alcance del proyecto y que algo no descrito está “fuera de alcance”.

Cuando posteriormente el cliente identifica elementos adicionales, dicha

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

El próximo paso es elaborar el impacto del desarrollo de la nueva funcionalidad:

¿Qué esfuerzo extra será requerido?, ¿Qué efecto tendrá sobre la totalidad de
duración del proyecto?, ¿En qué costos adicionales se incurrirá y cómo afectará
esto al margen del proyecto?.

Si el impacto es insignificante, puede ser acordado para incluir la nueva

funcionalidad en el proyecto existente, pero lo ideal debería ser la realización de
la definición por escrito de una especificación revisada. El peligro aquí es que el
cliente creerá que se ha sentado un precedente, por lo que puede pensar que
futuras revisiones serán realizadas de la misma forma; por eso es importante
comunicar las razones para permitir la revisión en esta instancia.

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

¿Realmente necesitamos una Definición de Alcance?

Uno puede pensar que escribir una especificación lo suficientemente detallada

puede generar que la realización de la Definición de Alcance conlleve más
tiempo (y costo) del que está garantizado por el valor del proyecto como un todo.
Por ejemplo, si se tiene previsto que todo el proyecto tome únicamente unas
pocas semanas y toma cinco días escribir una especificación detallada, un
análisis costo/beneficio mostraría que no vale la pena hacerlo.
Si es el caso, hay que evaluar la probabilidad del riesgo (basándonos en el
conocimiento del cliente y qué tan seguro se está de todos los requerimientos
que han sido identificados) y el posible impacto del aumento en contingencia
suficiente en las estimaciones de tiempo y costos para cubrir todo excepto la
mayor parte de las revisiones principales a la especificación.
 Estimación de Esfuerzo del
Proyecto
 Cuando el cliente quiere todo
para ayer
 Tarea 2.
Subtema 4.2. Planificación, programación y control del Objetivo: Plazo

ESTIMACIÓN DE ESFUERZO DEL PROYECTO

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

En cambio, cuando hablamos de tiempos del proyecto, normalmente nos

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

Si el proyecto sigue un ciclo de vida iterativo incremental, al estilo de UP

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

Cada participante del equipo de trabajo debería de estimar el esfuerzo de sus

actividades, desglosando dichas actividades a un nivel de granularidad tal que
las actividades tengan un esfuerzo menor a 2 o 3 días, y que incluso puede ser
de sólo unas pocas horas.

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

A continuación algunas recomendaciones para realizar la estimación del

esfuerzo del proyecto.

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

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

CUANDO EL CLIENTE QUIERE TODO PARA AYER

No todos los clientes son iguales. No me lo van a creer, pero he llegado a

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

Si la persona que te contrata para realizar el trabajo pareciera no tener idea de

temas como el alcance, presupuesto o requerimientos, puede que sea por pura
ignorancia o irreparable necedad; en todo caso no vamos a discutir ese punto
sino en otro diferente.

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

La culpa la tiene, por lo menos en parte, un autor llamado C. Norticote Parkinson.

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

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

Esta sabiduría popular expresada en estas afirmaciones es la que ocasiona que

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

Un gerente “inteligente” conoce estas leyes y síndromes y posiblemente te dará,

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

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

¡No!

Si la fecha de entrega es percibida como irreal y cumplir lo imposible TIENE que

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

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

Esta sabiduría administrativa es bastante conocida. Y está tan arraigada en el

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

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

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

Si los planificadores están separados de la gente que ejecuta el trabajo y tiene

el conocimiento, las estimaciones seguirán siendo erróneas e irreales, llevando
al equipo a un mal desempeño, alimentando así y “evidenciando” erróneamente
la Ley de Parkinson.

Al final, si el cliente quiere su producto para mañana, terminará obteniéndolo

dentro de un mes. Quizás si hubiera estado de acuerdo en que se le entregara
en dos semanas, lo hubiera tenido en esas dos semanas.
 Seguimiento mediante Earned Value
 Métodos de Estimación de Costos de
Software para Grandes Proyectos
 Manejo Financiero de Proyectos
 Aplicación Práctica de la Técnica del
Valor Ganado con Software
 Análisis de costo/beneficio como una
herramienta de Administración de
Proyectos
Tarea 3.
Subtema 4.3. Planificación, programación y control del Objetivo: Costo

SEGUIMIENTO DEL PROYECTO MEDIANTE EARNED VALUE

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

Muchos administradores de proyecto administran el rendimiento de sus

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

EARNED VALUE también permite la unificación de criterios en el análisis de los

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

En la actualidad, la técnica del EARNED VALUE tiene defensores y detractores,

influidos ambos tanto por experiencias previas como por los comentarios e
influencias de otros miembros de la profesión.

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

Historia

EARNED VALUE es un concepto que en los últimos tiempos ha alcanzado una

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

Surgió originalmente como una extensión de la metodología de planificación de

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

Concepto de EARNED VALUE

Cuando hablamos de EARNED VALUE, generalmente hablamos de una

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

 Establecer un método para determinar cuál es el estado del proyecto y el

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

En consecuencia, el EARNED VALUE es también una medida de progreso. Hay

una relación directa entre EARNED VALUE y tanto por ciento completado. Se
podrían determinar los atributos de este como:

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

Utilización del EARNED VALUE

Para poder obtener un análisis que nos determine correctamente el estado y

rendimiento del proyecto mediante EARNED VALUE, es crítico el diseño de la
WBS, dado que la aplicación del EARNED VALUE supone la medición de lo
actualmente conseguido contra una base de referencia. Sin la línea de base, no
puede haber ninguna medida significativa.

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

 Deben estar definidas las fechas de inicio y fin.

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

Se hace necesario también disponer de un medio para recopilar la información

acerca de los costes reales, dado que la parte más difícil en la aplicación del
EARNED VALUE es la determinación del coste real asumido en un momento
dado.

Indicadores y principales términos de Earned Value

La metodología del EARNED VALUE maneja su propia simbología y conceptos,

los cuales son los siguientes:

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

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

Podremos ver en el siguiente gráfico de coste/tiempo el significado de cada uno

de los términos:
MÉTODOS DE ESTIMACIÓN DE COSTOS DE SOFTWARE PARA GRANDES
PROYECTOS

El software ha alcanzado una mala reputación pues ha sido considerado como

una tecnología perturbadora. Los grandes proyectos de software han tendido a
tener una muy alta frecuencia de exceso de calendarización, costos, problemas
de calidad e indiscutibles cancelaciones. Mientras esta mala reputación a
menudo es merecida, es importante notar que algunos grandes proyectos de
software finalizan a tiempo y con el presupuesto estimado, además funcionan
satisfactoriamente cuando éstos son desplegados.

Los grandes proyectos exitosos difieren en muchos sentidos de los fracasos y

desastres (Jones 2004). Una diferencia importante es, cómo los proyectos
exitosos concluyen a tiempo, dentro de los costos, recursos y estimación de
calidad prevista en un primer término. De un análisis de resultados de las
herramientas de estimación usadas, publicado en “Estimación de Costos de
Software” (Jones 1998), el uso de instrumentos de estimación automatizados
conduce a estimaciones más exactas. A la inversa, los métodos informales o
manuales de llegar en estimaciones iniciales son generalmente inexactos y a
menudo excesivamente optimistas.

Una comparación de 50 estimaciones manuales con 50 estimaciones

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

Solamente cuatro de las estimaciones manuales estuvieron dentro del 10% de

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

Por contraste 22 de las estimaciones generadas por herramientas de estimación

comercial estuvieron dentro del 10% real de los resultados. Aproximadamente
24 fueron conservadoras entre 10% y 25%. Tres fueron conservadoras por más
que 25%. Únicamente una automatizada fue optimista, por cerca del 15%.

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

De modo interesante, las estimaciones manuales y las automatizadas eran

equitativamente cercanas en términos de predicción del esfuerzo de
programación o codificación. Pero las estimaciones fueron muy optimistas
cuando predecían el crecimiento de los requerimientos, esfuerzo del diseño,
esfuerzo de documentación, esfuerzo de administración, esfuerzo de evaluación
y esfuerzo de revisión y reparación. La conclusión de la comparación fue que
tanto las estimaciones manuales como las automatizadas eran equivalentes para
la programación real, pero las estimaciones automatizadas eran mejores para
predecir actividades de no codificación.

Este es un asunto importante para la estimación de grandes aplicaciones de

software. Para proyectos de software por debajo de aproximadamente 1000
puntos de función en tamaño (equivalente a 125,000 declaraciones C), la
programación es el mayor costo de manejo, la exactitud de estimación para
codificación es un elemento clave. Pero para proyectos sobre los 10,000 puntos
de función en tamaño (equivalente a 1,250,000 declaraciones C), tanto la
eliminación de defectos como la producción de documentos son más costosas
que el código por sí mismo. Por lo tanto la exactitud en la estimación de esos
tópicos es un factor clave.

Las estimaciones de tiempo y costo deberían ser exactas, naturalmente. Pero si

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

Debido a que el crecimiento de la estimación de costos es una actividad

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

Mientras estos instrumentos de estimación fueron desarrollados por empresas

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

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

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

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

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

Las estimaciones para grandes proyectos de software necesitan incluir muchas

más actividades que solamente codificar o programar. La Tabla 1 muestra un
modelo de actividad típica para seis clases diferentes de proyectos: aplicaciones
web-based, sistemas de información gerencial (MIS), software outsourced,
software comercial, software de sistemas y proyectos de software militares. En
este contexto los proyectos “web” son aplicaciones diseñadas para apoyar sitios
web corporativos. Las letras (MIS) son las siglas en inglés para Mangement
Information Systems. El “Outsource” en software es similar al MIS, pero realizado
por una contratista externa. El software de “sistemas” es aquel que controla los
dispositivos físicos como sistemas de telecomunicaciones o computadoras. El
software militar constituye todos los proyectos los cuales son obligados para
seguir varios estándares de índole militar. El software comercial se refiere a
paquetes ordinarios como procesadores de palabras, hojas de cálculo y otros
por el estilo.
La Tabla 1 es simplemente ilustrativa, y los números reales de actividades
realizadas y los porcentajes de esfuerzo para cada actividad pueden variar. Para
estimar proyectos reales, el instrumento de estimación presentaría el conjunto
más probable de actividades para ser realizadas. Entonces el Project Manager
o el especialista en estimación de costos ajustaría el conjunto de actividades que
corresponden a la realidad del proyecto. Algunos instrumentos de estimación
permiten a los usuarios añadir actividades adicionales que no son parte del
conjunto de actividades originales.

Generadores de Costos para Grandes Sistemas de Software: Trabajo

Administrativo y Eliminación de Defectos

En conjunto, los grandes proyectos de software dedican más esfuerzo a la

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

La invención de métricas de puntos de función (Albrecht 1984) ha hecho de la

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

Tabla 2: Ilustra ejemplos de tamaño de documentación seleccionada a partir de

sistemas, proyectos web, MIS, Outsource, Comercial, Sistemas y dominios de
software militar.

Al menos una herramienta comercial de estimación de software puede incluso

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

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

Defecto

Un aspecto clave de la estimación de costo de software es predecir el tiempo y

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

La secuencia típica es estimar los volúmenes de defecto por un proyecto y

entonces estimar la serie de revisiones, inspecciones y pruebas que utilice el
proyecto. La eficiencia en la eliminación de defecto de cada paso también serán
estimada. Los costos y esfuerzo para la preparación, ejecución y reparación de
defectos asociados con la actividad de eliminación también serán estimadas.

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

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

La Tabla 3 presenta valores de promedio aproximados, pero en el rango de cada

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

Un factor clave para la estimación exacta involucra la eliminación de defectos a

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

Es más fácil estimar proyectos de software que utilizar controles de calidad

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

La Tabla 4 ilustra las variaciones en prevención de defectos típicos y métodos

de remoción de defectos entre los seis dominios ya discutidos. Por supuesto,
muchas variaciones pueden ocurrir en esos modelos.

(Los valores de eficiencia acumulativos en la Tabla 4 son calculados así: Si el

número de partida de defectos es 100, y hay dos etapas de prueba consecutivas
que cada una elimina el 50% de los defectos presentes, entonces la primera
prueba removerá 50 defectos y la segunda prueba quitará 25 defectos. La
eficacia acumulativa de ambas pruebas es de 75%, porque 75 de los 100
defectos posibles fueron eliminados.)

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

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

La Tabla 4 simplifica demasiado la situación, ya que las actividades de

eliminación de defecto tienen eficiencias variables para los requerimientos,
diseño, codificación, documentación, y categorías de defectos mal reparados.
Del mismo modo, las malas reparaciones durante la evaluación serán colocadas
detrás del conjunto de defectos no detectados.
La baja eficiencia de la mayoría de las formas de la eliminación de defectos
explica por qué una larga serie de actividades de remoción de defectos son
necesarias. Esto explica por qué la estimación de eliminación de defecto es
crítica para la exactitud total de la estimación de costos de software para grandes
sistemas. Debajo de los 1000 puntos de función las series pueden incluir más de
una docena de tipos de revisión, inspección y actividad de evaluación.

Cambios de requerimientos y estimación de software

Un aspecto importante de estimación es la relación con el índice en el cual los

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

El cambio de requerimientos puede ocurrir en cualquier momento, pero los datos

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

Para estimaciones hechas tempranamente en el ciclo de vida, varias

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

Por supuesto, la mejor respuesta a una estimación con un volumen significativo

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

Cuando son usadas para verdaderos proyectos de software, las suposiciones

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

- La experiencia de personal con proyectos similares

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

Las herramientas de estimación automatizadas proporcionan a los usuarios con

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

Resumen y Conclusiones

La estimación de software es simple en teoría, pero difícil y compleja en realidad.

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

Las herramientas comerciales de estimación de software están lejos de ser

perfectas y ellas también pueden equivocarse. Pero la estimación automatizada
frecuentemente supera a las estimaciones humanas en términos de exactitud y
siempre en términos de velocidad y rentabilidad. Sin embargo, ningún método
de estimación está completamente libre de error. La actual “mejor práctica” para
la estimación de costos de software debe usar una combinación de herramientas
de estimación de costos de software acoplados con las herramientas de
administración de proyectos de software, bajo la dirección cuidadosa de project
managers de software experimentados y especialista en estimación.
MANEJO FINANCIERO, UN FACTOR DE ÉXITO EN LA EJECUCIÓN DE UN
PROYECTO
La gestión financiera es una función que permite unificar la planificación,
presupuestación, contabilidad, pagos, informes financieros, controles internos,
auditoría, adquisiciones y desembolsos para respaldar la ejecución. Es un
elemento crítico en el éxito de un proyecto.

Contar con información financiera oportuna y relevante permite construir una

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

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

El desarrollo de todo tipo de proyectos y en especial aquellos de alguna

magnitud, que son los que concentran nuestro mayor interés, precisan apelar a
diferentes fuentes internas y externas (nacionales e internacionales) para su
cabal financiamiento. En efecto, son muchas y muy variadas las modalidades
utilizadas en el financiamiento de proyectos de diferente tipo, que determinan
pautas o formatos distintos en la programación y organización financiera para la
ejecución de un proyecto.

Tres etapas se deslindan o distinguen en la administración financiera para éste

propósito: identificación de una estrategia de financiación; la planificación
financiera y el cierre financiero. En consecuencia el líder del proyecto y los
responsables del tema deberán abordarlas con suficiente rigor:

 Identificación de una estrategia de financiación: La posibilidad de

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

La estrategia financiera debe conjugar y hacer valer todas las fortalezas

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

Este escenario resulta particularmente interesante, puesto que, en el diseño y

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

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

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

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

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

La desagregación tecnológica del proyecto (EDP) nos permite identificar

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

Es claro que el reto de los gestores de proyectos es atender armónicamente los

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

Dada la magnitud de la mayoría de proyectos aquí referenciados, se precisa la

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

El plan financiero debe atender entre otros los siguientes requisitos:

 Los patrocinadores o gestores del proyecto deberán garantizar la consecución

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

Se trata de concertar fuerzas antagónicas mutuamente dependientes que

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

 Cierre financiero: Quizá uno de los retos más difíciles para los propietarios de
un proyecto de alguna magnitud es precisamente garantizar la llegada oportuna
de los recursos financieros suficientes para la realización de todas y cada una
de las actividades programadas durante la ejecución, vale decir, estructurar el
“cierre financiero”. Aquí surgen dos modalidades extremas: por un lado el
propietario se encarga de conseguir los recursos y contrata a una firma
especializada para la ejecución del proyecto. Una tendencia más moderna es
que la firma ejecutora sea también la responsable de gestionar los recursos y
hacerse responsable de su devolución o pago a través de los flujos generados
durante la operación. En cualquier circunstancia e independiente de quien
asuma la responsabilidad, es preciso protocolizar el cierre financiero, para lo cual
es preciso diseñar y aplicar refinados modelos de ingeniería financiera, puesto
que se necesita tomar decisiones en torno a:
 Monto de endeudamiento requerido: el estudio de factibilidad y los
diseños definitivos ofrecen toda la información pertinente para dimensionar
las necesidades de capital para la financiación del proyecto tanto en el periodo
de ejecución como durante la operación. La determinación del nivel de
endeudamiento apropiado se establece a partir de:
 Monto de las inversiones fijas y diferidas necesarias para la ejecución.
 El monto de las necesidades del capital de trabajo que proscriba cualquier
conato de parálisis por falta de recursos.
 Costos financieros que hay que asumir por la financiación de la ejecución
y los demás egresos derivados de la administración del crédito.
 Un margen de seguridad que permita cubrir eventuales situaciones no
previstas.
Si las circunstancias de orden técnico lo permiten en algunos proyectos se
puede programar el inicio de operaciones antes de la terminación total del
proyecto (crecimiento en forma modular), lo que origina la disponibilidad
temprana de ciertos ingresos que alivien las cargas derivadas de los créditos.
Dado que esto afecta directamente la cronología y ejecución presupuestal el
gerente del proyecto debe tener especial interés en esta estrategia que
debe ser analizada e impulsada si resulta válida y es concurrente a los
propósitos del proyecto.
 Determinación del grado máximo de apalancamiento: la razón deuda/capital
que determina el nivel máximo de apalancamiento depende de:

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

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

El nivel de apalancamiento corresponde a un equilibrio entre la capacidad

del proyecto de convocar y emplear recursos ajenos y la posibilidad real de
pagarlos con los flujos derivados de la operación. Un apalancamiento
exagerado pone en peligro el proyecto al no producir los flujos suficientes que
requiere el servicio de la deuda, pero el no aprovechar adecuadamente la
capacidad de endeudamiento puede acarrear, al mismo tiempo, costos de
oportunidad. En resumen, la capacidad de endeudamiento corresponde al
nivel de deuda que el proyecto es capaz de servir por completo durante el
periodo de amortización del préstamo. Se suele calcular a partir del flujo de
efectivo descontado año por año.
Se trata pues de establecer la cantidad máxima de apalancamiento a la cual
se puede acceder, teniendo en cuenta las características financieras del
proyecto y las condiciones establecidas por los prestamistas. Uno de los
trabajos que deben realizar los asesores financieros de los propietarios del
proyecto o de los gestores del mismo, es la elaboración de modelos que
garanticen la inclusión de toda clase de variables pertinentes relacionadas
con los flujos de caja previstos en diferentes escenarios, que permitan
argumentar válidamente ante los prestamistas las solicitudes de crédito
correspondientes, basadas en la capacidad de endeudamiento. La experiencia
y el conocimiento de estos expertos permiten valorar diferentes paquetes de
financiación que brinde el costo de capital más atractivo, asumiendo diferentes
niveles de riesgo.

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

El programa de utilización de fondos a largo plazo debe concordar con las
erogaciones necesarias para la construcción, instalación y puesta en marcha.
Los prestamistas suelen ser un tanto desconfiados y requieren que los
patrocinadores o propietarios y los inversionistas de capital apliquen una
cantidad significativa de recursos a la inversión inicial (como prueba de
confianza en su propio negocio) antes de comenzar a irrigar el proyecto con
sus recursos. Este requisito asegura que los prestamistas, propietarios e
inversionistas de capital adquieren un compromiso firme desde los primeros
momentos.
 Estimación del flujo de caja periodo por periodo: desde luego, que un
plan financiero técnicamente concebido debe compaginar armónicamente la
necesidad de recursos financieros para realizar las diferentes actividades y
los flujos de ingresos derivados de los compromisos acordados con
prestamistas e inversionistas, de lo contrario el proyecto tendrá que apelar a
financiaciones costosas de corto plazo. En principio la información financiera
derivada de los estudios de factibilidad suele presentarse en períodos anuales,
 sin embargo, los asesores de las partes tendrán que corroborar en escala
mensual o semanal según el caso, el comportamiento de los flujos de caja.
 Selección de monedas para financiar el proyecto: cuando se acuerda recibir
dinero por concepto de aporte o crédito o recursos originados en las ventas,
y también se acuerda el pago de acreencias en diferentes monedas se puede
incurrir en un riesgo de tipo de cambio que es preciso mitigar, por esa razón,
los patrocinadores o propietarios negociarán basados en algún modelo
multimoneda que mitigue y controle este riesgo.
 Estimación del horizonte del proyecto o su vida útil: es claro que el
vencimiento de la deuda de un proyecto no debe exceder su vida útil. Algunos
proyectos de extracción de minerales o petróleo, según la tasa de producción
pueden determinar con precisión su vida útil y ajustar a propósito el esquema
de financiación. Si bien es cierto que el gerente del proyecto solamente tiene
que preocuparse por los sucesos de todo orden acaecidos durante la
ejecución, también es cierto que además de la nueva capacidad instalada, el
gerente es responsable de entregar al operador unas finanzas sanas,
respaldadas por una capacidad de producción o de prestación de servicios
que genere recursos suficientes para atender las acreencias originadas en las
grandes inversiones de la ejecución.

De lo anterior se desprende que el dimensionamiento del monto requerido, la

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

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

Dentro del concepto de proyecto en ejecución la función financiera ocupa un

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

Las principales tareas encomendadas a la función financiera son las siguientes:

 Elaboración y proyección de presupuestos y flujos de fondos acordes con las

diferentes actividades programadas.

 Fijaciónde políticas en torno al comportamiento de los activos: en cuanto a los

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

 Definición y planeación de la estructura de endeudamiento 2: la función financiera

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

Por otro lado, la imagen de solidez corporativa se resentirá y la confianza por

parte de terceros (bancos y corporaciones) también se afectará, pero además la
autonomía de la firma y su operación podrá quedar comprometida.

Si bien es cierto que la política de financiamiento la define la empresa matriz, los

directivos del proyecto decidirán si acuden directamente al mercado de capitales
con la emisión de bonos, o si se aproxima al ahorro primario mediante la
colocación de acciones. Debemos insistir en que los recursos propios tienen un
"costo de oportunidad" cuya estimación es una de las tareas primordiales y
permanentes de la función financiera.

 La asunción de compromisos financieros con agencias, bancos, fabricantes y

proveedores nacionales e internacionales requiere estudio, organización y
notable trabajo de detalle para consolidar y apuntalar los contratos
correspondientes y el cierre financiero. Cabe anotar que entre las cartas de
intención y los primeros giros pueden transcurrir algunos meses especialmente
si se trata de agencias internacionales que exigen autorizaciones y avales de
parte de las respectivos gobiernos o entidades nacionales, lo cual supone por
parte del proyecto contar con profesionales con conocimiento e iniciativa para
garantizar la culminación exitosa de los diferentes trámites.

Esta función se encarga también de las operaciones financieras de rutina que

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

 Garantizar la elaboración oportuna y confiable de los estados financieros y sus

análisis correspondientes.

 Estudioy colocación de pólizas de seguro que garanticen su cabal cubrimiento

en todo tipo de riesgos.

 Elaboración de listados actualizados de los bienes del proyecto que pueden

servir de garantía ante terceros. Es claro que entre más avance la ejecución, el
patrimonio del proyecto se irá incrementando y por ende su capacidad de
respaldar acreencias.
 Adelantarlas estrategias adecuadas de cubrimiento del proyecto en ejecución
en contra de los procesos de devaluación e inflación.

La política financiera está afectada continuamente por situaciones no

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

Una de las tareas más importantes de la administración financiera del proyecto

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

En resumen la función financiera incluye todas las acciones encaminadas a

determinar el nivel de recursos necesarios, su distribución entre los distintos
usos, y localización y ponderación de fuentes para garantizar la ejecución del
proyecto.

APLICACIÓN PRÁCTICA DE LA TÉCNICA DEL VALOR GANADO CON

SOFTWARE
Siglas como EAC, SAC, CPTP, IDA, BCWP, AC, SV, IRC, BAC y muchas más
son términos recurrentes cuando se pretende usar la Técnica del Valor Ganado
o Earned Value, lo que en primera instancia daría la impresión de ser una
herramienta muy compleja, y por lo tanto, aleja a los potenciales interesados en
usarla.

Lo anterior proviene de que se puede encontrar que en algunos libros en español

se usa terminología en inglés (formato antiguo y actual) y en otros se puede notar
que se utiliza terminología en español. Por lo tanto, se tienen dos y hasta tres
formas para reflejar el mismo parámetro.

Por ejemplo, para indicar el índice de atraso o adelanto en la programación se

puede encontrar con: SPI (Schedule Performance Index), IRP (Índice de
Rendimiento de Programación) e IDA (Índice de Desempeño de Agenda).

Pues bien, a pesar de que son muchos parámetros con los que se puede
encontrar, los conceptos son sólo tres que se combinan y los software de
programación los usan.

Para explicar como los software usan esta técnica, imagine una tarea de 10 días
con un recurso a 8 horas diarias y con un costo de $100/hora y que se planifica
con un comportamiento normal, es decir, al final del tercer día habrá avanzado
un 30%.

Obviamente, hay tareas que no tienen este comportamiento, pero lo que nos
interesa es el comportamiento del proyecto como un todo, a nivel de resumen
del proyecto, por lo que las pocas tareas de comportamiento anormal tienen una
baja ponderación en el resultado global del proyecto, dado que debiera existir
una gran cantidad de tareas de comportamiento normal.

Lo más probable es que el avance a cierta fecha de control sea inferior a lo

programado y los costos sean superiores a lo presupuestado.

Imagine entonces que ahora estamos parados al final del día 4, que el avance
fue sólo de un 30% y el costo real fue de $ 110/hora (aquí presumimos órdenes
de cambio aprobadas).

Ahora podemos calcular:

1. Al final del día 4 debiera hemos avanzado un 40% y hemos gastado

(40%*80h)*$100/h=$3,200
2. Para un avance real de 30% debiera haber gastado (30%*80h)*$100/h=$2,400
3. Para este avance de 30% gasté realmente (30%*80h)*$110/h=$2,640
4. Por simple regla de tres el proyecto demorará 13,3 días o 10d/(2,400/3,200)
5. Por simple regla de tres el proyecto costará $8,800 o $ 8,000/(2,400/2,640)

• Los $3,200 es lo que se llama Costos Presupuestado del Trabajo Programado

(CPTP) o Budgeted Cost of Work Scheduled (BCWS) o Planned Value (Valor
Planificado).
• Los $2,400 es lo que se llama Costos Presupuestado del Trabajo Real (CPTR)
o Budgeted Cost of Work Performed (BCWP) o Earned Value (Valor Ganado).
• Los $2,640 es lo que se llama Costos Real del Trabajo Real (CRTR) o Actual
Cost of Work Performed (ACWP) o Actual Cost (AC).

Hay algo que se asume en el cálculo anterior de 2 y 3 y que pasa desapercibido,

cálculo que se hace posterior al día de inicio del proyecto: se asume que se
sabían cuántas horas duraba el proyecto y que se sabía el costo presupuestado
por hora. El avance real es una observación del momento y el costo real es al
momento de realizar el cálculo.

Esta información que ya se conocía es la que requieren todos los software para
poder trabajar con la Técnica del Valor Ganado. Es la información de
programación y presupuestación previa y que se guarda en lo que se llama Línea
de Base.

Qué cuidados debemos tener:

1. Hacer la programación desagregando hasta el nivel en que humanamente

pueda llevar un control (estimar un porcentaje de avance físico de la tarea y un
costos real)
2. Generar la hoja de recursos con sus costos
 3. Asignar los recursos a las tareas
4. Ajustar plazos y costos
5. GUARDAR LA LÍNEA BASE (que no es más que copiar esta información en
paralelo para ocuparla a futuro y compararla con lo real que voy ingresando en
cada fecha de control)

Una vez guardada la Línea de Base y de haber ingresado a la fecha de control

el avance real por tarea y el costo real por tarea, estamos en condiciones de
pedirle al software cualquiera de los datos siguientes:

1. El índice de rendimiento de programación del proyecto.

2. La duración estimada del proyecto.
3. El índice de rendimiento de programación del proyecto para terminarlo
dentro de lo programado.
4. El índice de rendimiento de costos del proyecto.
5. El costo estimado del proyecto.
6. El índice de rendimiento de costos del proyecto para terminarlo dentro de
lo presupuestado.
7. Otros

Es increíble como ingresando solo 2 datos por tarea (avance y costo real)
obtengo información valiosa para tomar acciones correctivas en aquellas tareas
que se están alejando de lo previsto.

Estos análisis se deben hacer durante todo el proyecto, pero en particular al 5%

de la duración del proyecto, al 10% y al 15%. ¿Por qué?: son las instancias en
que las buenas prácticas indica que todavía puedo “enderezar” el proyecto. Si el
cálculo lo hago más adelante y mis índices no son buenos, difícilmente podré
“enderezar” el proyecto, dado que si mi planificación no fue buena tan cerca del
inicio del proyecto, por qué debiera serlo más lejos del inicio del proyecto?. De
otra forma, si no veo bien a 10 metros, no puedo pretender ver bien a 1000
metros.

En resumen, esta técnica utiliza sólo 3 conceptos claves:

1. Costo Presupuestado del Trabajo Programado (CPTP) o Budgeted Cost of

Work Scheduled (BCWS) o Planned Value (Valor Planificado).
2. Costo Presupuestado del Trabajo Real (CPTR) o Budgeted Cost of Work
Performed (BCWP) o Earned Value (Valor Ganado).
3. Costo Real del Trabajo Real (CRTR) o Actual Cost of Work Performed (ACWP)
o Actual Cost (AC).

Los combina como se muestra a continuación y entrega información del estado

del proyecto a la fecha de control y el comportamiento que tendrá el proyecto a
futuro si no se toman acciones correctivas (si no tratamos de “enderezarlo”). Esta
información los software la entregan a nivel de tareas, fases y proyecto.

Un punto importante: las fases o tareas de resumen son tareas de resumen de

tareas, por lo tanto, para que no correr el riesgo de duplicar costos, no hay que
asignar recursos a las tareas de resumen. Las tareas de resumen son eso: de
resumen y aglutinan ponderando adecuadamente las tareas anidadas.

PARÁMETROS DE LA TÉCNICA DEL VALOR GANADO

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

ANÁLISIS DE COSTO/BENEFICIO COMO UNA

HERRAMIENTA DE ADMINISTRACIÓN DE PROYECTOS

Durante las últimas décadas, el sector minero en el Perú ha crecido

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

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

Las corporaciones mineras empezaron a invertir siguiendo sus propias reglas

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

En cuanto a los actores gubernamentales y el Estado en general, el problema

fue, sobre todo al inicio, el excesivo enfoque en los problemas de corto plazo
solamente: el Gobierno Nacional se centró en resolver conflictos puntuales entre
las corporaciones mineras y las comunidades de los alrededores, cohibiendo el
enfrentamiento, pero sin mucho éxito en reparar la imagen de la actividad minera,
aunque con fuerte intensidad en la creación o mejoramiento de las regulaciones
ambientales y de seguridad, para orientar el comportamiento de las
corporaciones.

El comienzo de una solución real se concretó cuando los sectores público y

privado se hicieron conscientes de las diferencias entre sus visiones: el sector
privado necesitaba tener un contexto cómodo para invertir en los proyectos
mineros, con estabilidad jurídica, y los actores sociales necesitaban tener
seguridad personal y operativa alrededor de las áreas de los proyectos mineros,
asegurando su salud y la calidad del medio ambiente. Al mismo tiempo, el Estado
reconoció que necesitaba una visión para su papel dentro del sector minero,
asegurando la habilidad de convertir la inversión minera en desarrollo local,
regional y nacional. La habilidad de estos tres involucrados principales (sociedad
civil, Estado y sector privado) dentro del sector minero, para reconocer sus
diferencias entre las visiones particulares, ha permitido que encuentren una
visión común con base en aspectos comunes entre las tres visiones.

Todos los actores han sido gradualmente incorporados en un diálogo

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

Las comunidades también entienden que priorizar el diálogo con las

corporaciones en lugar de siempre recurrir a la protesta o las medidas de fuerza
en primer lugar, pueden tener más autoridad para poder decidir sobre los montos
de apoyo de parte de las corporaciones y sobre los alcances en los cuales
invertir, reforzando la capacidad de producir de la misma manera que venían
produciendo de tal manera que no se causa disrupciones culturales en la
economía local, pero se accede ordenada y progresivamente a mayores
volúmenes y opciones de mercados para un desarrollo integral. El Estado por su
lado, entiende que muchas de las políticas de desarrollo (educación básica local
y programas de salud básica y preventiva) que son muy difíciles de implementar
sin apoyo social y con bajos recursos, encuentran más opciones de
cofinanciamiento con corporaciones privadas creando asociaciones público
privadas en un entorno armónico con los actores sociales.

El hecho concreto es que esta nueva forma de pensar (lo que podría llamarse
una nueva cultura de gestión), basada en herramientas adecuadas de análisis
de costo/beneficio, permiten crear acuerdos entre el Estado (como autoridad
representante de la sociedad como un todo) y las corporaciones mineras. Esto
ha sido inicial pero exitoso en Perú, debido a que la administración pública (o por
lo menos una gran cantidad de entidades que han renovado su gestión) ha
empezado a abrir su mente tanto como las corporaciones privadas más lúcidas,
así como los líderes comunales y nativos basados en sus intuiciones culturales
de gestión de sus comunidades (aun cuando probablemente los documentos
técnicos recién empiezan a reconocer los enormes avances en gestión integral
de muchas de las comunidades nativas o rurales), apostando a visiones
aterrizadas, integrales y de más largo plazo.

Operativamente, las tareas principales en las cuales las corporaciones y el

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

Sin embargo, el impacto logrado todavía no es suficiente. El nivel de conflicto

entre las corporaciones y comunidades todavía es importante aunque sea menor
en el Perú. La legislación todavía está más enfocada en los procesos técnicos
de minería y necesita ser más precisa en los mecanismos de “aterrizaje” de las
corporaciones en el territorio de explotación y más detallada en las relaciones
con las comunidades y los actores sociales, además de instructiva en la relación
con todos los niveles de gobierno. Mucho más se requiere hacer sobre la
comunicación para todos los actores, particularmente contra el enorme
desconocimiento que todavía hay de cuál es el rol del Estado, cuál de la
empresa, cuál el de los actores sociales, además de identificar, discutir, acordar,
y difundir cuáles son los deberes de cada uno. El nivel de protección ambiental
es mejor que la década pasada pero todavía muchos ciudadanos están
fuertemente afectados por la polución y algunas corporaciones son más que
negligentes acerca del cumplimiento de la legislación existente, sin contar la
existencia y proliferación de pequeños productores mineros informales sin
mucha capacidad de monitoreo de su impacto.

Una de las tareas más importantes, pero tal vez menos visibles, es definir y
escribir formalmente la visión de cada uno de los actores, y finalmente la visión
conjunta de la minería peruana (sector minero peruano). Aún el Gobierno
Nacional necesita entender que las actividades mineras sólo son la expresión
más concreta de un sistema mucho más complejo, que necesita ser entendido y
definido como un sistema de “producción” de desarrollo sostenible, y necesita
usar todas las herramientas de gestión disponibles en el mercado, tales como la
estructuración de visión, el análisis de costo/beneficio alrededor de la visión
definida, el desarrollo de programas de mejoramiento y mucho más importante,
la habilidad de comunicar resultados a los ciudadanos y corporaciones, acerca
del avance en la construcción de la visión planificada. En pocas palabras, el
Estado debe desarrollar y traducir las mejores prácticas de gestión de proyectos
para aplicarlos a un “proyecto” grande y complejo en el cual la visión común sea
el “alcance” y la construcción una “operación” de desarrollo sostenible basada
en las actividades mineras sea la tarea principal.

Si todos los niveles del Estado (pero con el liderazgo del Estado Nacional) no
comprenden que el mejoramiento y clarificación de las visiones es una función
del Estado, no podrá alentar la definición de una visión conjunta, y estará siempre
atareado con la resolución de conflictos de corto plazo entre las partes. Si todos
los niveles del Estado participan activamente en el proceso de reconocimiento,
construcción, mejoramiento y comunicación de la visión, no serán capaces de
tomar las decisiones correctas. Si la visión del sector minero peruano es
finalmente definida, cada ciudadano, cada corporación y cada agencia de
gobierno serán más exitosos en la contribución a dicha visión común. En el Perú,
esperamos que las herramientas de gestión disponibles5 contribuyan a acelerar
la mejora de la comprensión de un cambio de variables de medición del estado
del sector minero: debemos abandonar las variables que miden como éxito
estatal el nivel de exportaciones de mineral o la cantidad de conflictos resueltos,
se debe definir indicadores de desarrollo (satisfacción sostenible) de los
ciudadanos y corporaciones en climas de mayor diálogo y construcción conjunta:
todo un reto de las herramientas de gestión.
 Seguimiento del proyecto
 Aseguramiento de la calidad
 Planificación de la calidad en un proyecto
 El seguimiento del proyecto: En Dios
confiamos, los demás traigan sus datos
 Fase de evaluación de un proyecto de
software: mucho más que evaluación
 Gestión de la calidad
 Kaizen y Kaikaku: Dos formas de implantar
proyectos ágiles
 Tarea 4.
Subtema 4.4. Planificación, programación y control del Objetivo: Calidad

SEGUIMIENTO DEL PROYECTO

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

El administrador del proyecto debe de reunirse con cierta frecuencia planeada

(por ejemplo una vez a la semana) con los miembros del equipo para comparar
los avances contra lo planeado, identificar problemas que pudieran poner en
riesgo el proyecto y planear las acciones correctivas necesarias para garantizar
el éxito del proyecto.

Para contar con un proyecto exitoso es indispensable mantener un control o

seguimiento a todos los parámetros básicos del proyecto:

 Alcance. Cantidad y Estado de los requerimientos, número de cambios

 Tiempo. Cumplimiento de las fechas y retrasos contra lo planeado.
 Progreso. Avance real vs planeado, desviación de fechas compromiso dado el
trabajo terminado, productividad actual contra esperada, desviación proyectada.
 Costo. Costos reales vs planeados, rentabilidad planeada vs esperada,
rentabilidad proyectada
 Calidad. Defectos, resultados de pruebas y revisiones, ritmo en que se han
encontrado y corregido los errores
 Riesgos. Número de riesgos, ritmo en que se han resuelto

El líder del proyecto debe enviar o presentar en una reunión un reporte del
estatus del proyecto al gerente responsable con información como la
anteriormente mencionada. En dichas reuniones deben de revisarse los planes,
los cuales deben de actualizarse y en caso necesario realizar las correcciones
necesarias para corregir cualquier desviación.

Puede ser de bastante utilidad utilizar una herramienta de software para llevar el
control de los avances y el estado del proyecto. Esto facilita concentrar la
información para que sea analizada con las personas interesadas, como sería el
gerente de proyectos y/o el cliente.

ASEGURAMIENTO DE LA CALIDAD

“Quality control” y “Quality assurance” son conceptos muy importantes, a pesar

de que muchos Project Managers tienen sólo una vaga idea de qué significa
 cada uno y cuál es la diferencia entre ellos. Aquí trataremos de explicar estos
conceptos

Primero deberíamos definir que es Calidad:

La calidad es “la totalidad de las funciones y características de un producto o

servicio que cumplen y satisfacen las necesidades o requerimientos implícitos o
explícitos del mismo” (ISO 9001:2000)

La calidad es “el grado en el que un conjunto de características inherentes

cumple con los requisitos” (American Society for Quality)

La Administración de la Calidad incluye la creación y seguimiento de políticas y

procedimientos para asegurar que el proyecto cumpla con los objetivos
establecidos (sin desviarse de los requerimientos). Incluye las actividades de
Planificación, Aseguramiento y Control de la calidad.

La Gestión de la Calidad aborda tanto la Administración de Calidad del Proyecto

(aplicable a todos los proyectos) como a la Administración de la Calidad del
Producto (específicas y particulares de cada producto). De acuerdo al PMBOK®:
“La gestión de Calidad Moderna complementa la Dirección de Proyectos y
abarca distintas disciplinas o industrias”

David Shuster en su libro “Teaming for Quality” nos dice sin embargo que la
Administración de la Calidad no es un subproceso del Project Management, sino
que a su criterio son disciplinas gerenciales co-equivalentes. Quality
Management y Project Management comparten:

 Filosofías de gerenciamiento comunes

 Foco en el cliente, procedimientos y política
 Satisfacción de las necesidades y requerimientos del cliente
 Enfoque en la calidad de los procesos
 Principios de teaming (grupos de trabajo)
 Estructuras ordenadas, formales, documentadas, medibles

QM y PM se diferencian en que el enfoque de Project Management es temporario

(finaliza con el proyecto) mientras que el de calidad es mejora continua y
permanente, a los efectos de este artículo podemos concluir como resumen que
“La Calidad es el grado en que el proyecto cumple con los requisitos”

El manejo y gestión de la calidad en el proyecto significa que se debe

comprender las expectativas de calidad del cliente y con ellas establecer un plan
proactivo para cumplirlas. El Plan de Calidad contiene varios puntos y
actividades pero los más importantes son las tareas referidas a los procesos de
Control de Calidad y Aseguramiento de Calidad.

Control de calidad (“Quality Control”) se refiere a las actividades de calidad

asociadas con la creación de los entregables del proyecto. El control de calidad
se utiliza para verificar y medir que el entregable tenga la calidad aceptable y
que está completo y correctamente finalizado. Ejemplos de acciones de control
de calidad incluyen las actividades de “Peer reviews” de procesos o tareas, los
procedimientos de testing, mediciones e inspecciones, entre otras

El Aseguramiento de la Calidad se refiere a los procesos que se utilizan para

generar los entregables. Esta función puede ser ejecutada por el equipo de
trabajo, la Oficina de Administración de Proyectos o terceras partes. Ejemplos
de actividades de aseguramiento de calidad incluyen los procesos de checklists
y las auditorías de calidad. Por ejemplo, si el proyecto está siendo auditado por
quality assurance, el auditor podría no ser capaz de decir si el contenido
específico o resultado del entregable es aceptable o no (quality control).

Sin embargo, el auditor debería ser capaz de informar si el entregable podría

considerarse aceptable basado en el estudio de los procesos que se emplearon
para su construcción (quality assurance). Esa es la razón por la cual un auditor
de proyectos o QA puede realizar la revisión del mismo, a pesar de que no
conozca en profundidad las características y especificaciones del entregable. Él
no puede medir la calidad del producto final, pero conoce qué tan bien o no
fueron los procesos que se ejecutaron para producir el producto del proyecto.

Un ejemplo sencillo extraído de un artículo publicado al respecto es el siguiente:

Supongamos que el Líder de Proyecto solicita al sponsor que apruebe el
documento Requerimientos del Negocio del proyecto. ¿Si usted fuera el sponsor
coómo validaría que el documento es completo y correcto?

Una respuesta podría ser revisar el documento y validarlo con los requerimientos
del negocio reales. Si opta por esta solución estaría realizando una actividad de
control de calidad, dado que sus acciones están enfocadas en validar el
entregable por si mismo.

Supongamos que el documento tiene muchas páginas y que usted como sponsor
no tiene el conocimiento, el tiempo o la intención de hacer una revisión de su
contenido. En este caso usted podría preguntarle al administrador del proyecto
que le describa el proceso que utilizó para crear el documento. Supongamos que
recibe la siguiente respuesta:

PM: “Me reuní con ocho de los principales usuarios en una sesión. Después de
la misma documenté los requerimientos y solicité al grupo su feedback,
modificaciones, etc. Tomé las actualizaciones y con el documento actualizado
me reuní con los representantes de Finanzas, Manufactura, Compras y
Marketing y ellos agregaron los requerimientos necesarios para soportar los
estándares de la compañía. Tuvimos reuniones adicionales con cuatro gerentes
de cada área que resultaría críticamente impactada por el sistema. Cada jefe de
área agregó algunos requerimientos adicionales. Con el documento completo
solicité la aprobación (sign-off) de los responsables y usted puede comprobar las
firmas en la última página”

El sponsor podría sentirse plenamente confortable con el documento debido a

esta explicación. Ésta es la diferencia con el método anterior, el control de
calidad se focaliza en medir y verificar el entregable propiamente dicho, el
aseguramiento de la calidad se focaliza en los procesos que fueron utilizados
para crear el entregable. Ambas son técnicas poderosas para la administración
de la calidad en proyectos y deben ser realizadas para asegurar que nuestro
producto o resultado final cumpla con los requerimientos de calidad de nuestros
clientes.

Como conclusión, podemos decir que durante el proceso de Aseguramiento de

la Calidad el foco está en la auditoría de los distintos procesos y las fases del
proyecto para garantizar que cumplan con los estándares de calidad impuestos
o las normas y políticas organizacionales. Durante el proceso de Control de
Calidad estaremos más interesados en realizar inspecciones (revisiones
técnicas formales, pruebas, etc.) Sobre el producto o servicio durante su
desarrollo o ya finalizado de manera de asegurar que está conforme con las
especificaciones de calidad establecidas.

PLANIFICACIÓN DE LA CALIDAD EN UN PROYECTO

Cuando preguntamos a alguien no introducido en los conceptos de la

administración de proyectos, cuál es el parámetro más importante, siempre surge
la palabra calidad, que curiosamente no está entre la triple restricción de alcance,
coste y tiempo. En la mayoría de los casos entendemos por calidad que el
proyecto vaya más allá de los requisitos para los que ha sido desarrollado, y
nada más lejos de la realidad. Otorgar más prestaciones o extras de los
requeridos por el cliente es lo que se denomina “Gold Plating”, y es una práctica
nada recomendable porque nos hace incurrir en costes que probablemente no
aporten valor para nuestro cliente, o en su caso, están más allá del alcance y
costes acordados.

Llegados a este punto, hay que remarcar que la calidad está implícita, y debe
ser considerada, en cada uno de los puntos de la triple restricción, determinando
cómo satisfacer cada uno de ellos con el propósito de asegurar los objetivos,

Tradicionalmente se asegura la calidad midiendo los resultados del proyecto

mediante el control de calidad, y analizando dichos datos en el proceso de
aseguramiento de la calidad. Podría pensarse que la simple inspección de todos
los productos y niveles de servicio de nuestro proyecto es el mejor método de
garantizar nuestro proyecto, y nada más lejos de la realidad. Hacerlo así no nos
impedirá que nos encontremos con disconformidades por parte del cliente,
además de suponer graves sobrecostes. La manera de asegurar que el proyecto
cumple con los requerimientos para los que ha sido desarrollando es asegurando
la calidad según los procedimientos desarrollados en el plan de calidad.

Por tanto, la calidad debe ser planificada; es un proceso que en la versión actual
del PMBOK® se conoce como PLAN DE CALIDAD (QUALITY PLAN ).

Propósitos del Plan de Calidad

El plan de calidad se centra en detallar las normas de calidad para el proyecto y

los criterios de calidad que se utilizan para medir y determinar si los resultados
 son los esperados, además de crear y documentar un plan para cumplir con esas
normas.

Dicho proceso, que se efectúa durante la fase de planificación del proyecto, está
basado en la política de calidad de la organización y tendrá por objeto desarrollar
un plan que determine:

 Los estándares, normas de calidad y regulaciones que afectan a nuestro

proyecto
 Los estándares que deberán desarrollarse específicamente para nuestro
proyecto
 La manera de asegurar la conformidad con dichos estándares
 Los procesos y planes de mejora continua
 Las métricas que se utilizarán para medir los resultados del proyecto
 Los procesos que se utilizaran para aplicar dichas métricas
 El grado de calidad del producto y cualidades que deben ser poseídas por los
entregables del proyecto

Proceso de Planificación de calidad

Para llegar a determinar todos los aspectos de calidad del proyecto, no

solamente deben centrarse los esfuerzos en el control y la verificación, sino que
debe seguirse un proceso orientado a determinar cómo dicha verificación es
llevada a cabo, procesada y transmitida:

1. Determinar qué debe ser sometido a verificación y control

Generalmente serán los entregables. Cualquier entregable importante debe ser
sometido a cierto control de calidad, entendiéndose por entregable importante
aquel que forme parte del resultado final del proyecto.

2. Establecer la manera más adecuada de efectuar el control

Si el resultado final es un entregable que debe cumplir un estándar, el control de
calidad debería centrarse en el cumplimiento de dicho estándar, asegurándose
esto mediante una auditoría.

3. Desarrollar la programación de las actividades de calidad

La mayoría actividades de calidad se realizan justo antes de completar el
entregable, aunque si los plazos de desarrollo son lo suficientemente largos,
deben programarse actividades intermedias.

4. Determinar los interesados y participantes de las actividades de calidad

Obviamente, los responsables del entregable, pero también puede ser necesaria
la participación de expertos, e incluso del cliente final del entregable, para
asegurar un común entendimiento de la información suministrada.

5. Describir las herramientas y técnicas de calidad que deben ser utilizadas

Las herramientas y técnicas utilizadas garantizarán que se contemplan todos los
 aspectos del proyecto, y no solo los aspectos importantes, no dispersando los
esfuerzos y la atención de los miembros del equipo.

Herramientas y Técnicas

Si bien existe gran cantidad de propuestos de diferentes autores acerca de cómo

desarrollar las actividades de calidad, mencionaremos aquellas especificadas en
el PMBOK® por ser las más representativas en el desarrollo de proyectos. Como
bien se especifica en dicho estándar, existen muchas otras que pueden ser útiles
para cierto tipo de proyectos o en determinadas áreas de aplicación.

Análisis Coste-Beneficio
Estudio para determinar el coste total de los gastos previstos de implementación
de los requerimientos y planes de calidad, comparándolos con los costes de la
NO CALIDAD derivados de la no implementación de dichos planes:

 Mayor reproceso
 Menor productividad
 Mayores costes de garantía
 Menor satisfacción del cliente
 Retrasos

Coste de la Calidad (COQ)

El coste de la calidad se refiere a la suma de todos los costes de la vida del
producto realizados para asegurar el cumplimiento de los requerimientos:

 Formación
 Equipo
 Documentación
 Tiempo de los procesos

También los costes derivados de incumplir dichos requerimientos

 Costes de reproceso por no cumplir con los requisitos

 Garantías

Los costes de incumplir los requerimientos pueden ser

 Internos: fallos encontrados por el equipo del proyecto

 Externos fallos encontrados por el cliente

Diagramas de Control
Se utilizan para visualizar en una gráfica el comportamiento de las características
del producto a lo largo del tiempo, para determinar si un proceso es estable o no,
o si tiene unas características uniformes y predecibles.

Con ello podremos identificar si la magnitud observada se encentra dentro de los

márgenes de medida preestablecidos., o bien identificar el momento en que se
produce una disconformidad con dichos márgenes. En procesos continuos,
 como por ejemplo un sistema de producción, no se observan todos los productos
o eventos, sino que periódicamente se selecciona una muestra de la producción
actual.

En un diagrama de control podremos observar los límites de las especificaciones

superior e inferior (valores máximo y mínimo permisibles), establecidos por lo
general en ±3σ (99.73% de las medidas dentro de los limites).

Hay diversos comportamientos en la medida del sistema que determinan que

este se encuentra fuera de control, haciéndose necesario emprender acciones
correctoras:

 Unas medidas de datos exceden un límite de control

 Dos medidas consecutivas más allá de los límites de advertencia (Habitualmente
±2σ).
 Siete medidas consecutivas o más en el mismo lado de la media (por encima o
por debajo).
 Cinco medidas consecutivas que entran en la misma dirección (indica una
tendencia)

Estudios Comparativos (Benchmarking)

Utilizados para comparar las prácticas desarrolladas en proyectos anteriores con
las establecidas para el proyecto en curso.

Con ello generaremos ideas de mejora, y obtendremos una base con la que
comparar la coherencia del resultado de nuestras mediciones, efectuadas
durante el proceso control de calidad.

Diseño de Experimentos
Los modelos de diseño de experimentos (DOE) son modelos estadísticos que
siguen una metodología basada en la experimentación, con el objetivo de
determinar qué factores influyen en una variable determinada, además de
cuantificar dicha influencia.

Sus resultados serían:

 Determinar la cantidad y el tipo de pruebas a efectuar

 Obtener las ecuaciones de modelado del sistema a partir de sus factores
 Identificar la influencia de cada uno de los factores en el proceso

Muestreo Estadístico
El muestreo estadístico consiste en seleccionar una parte de la población para
su inspección para conseguir que los resultados de dicha muestra sean
extrapolables al total de dicha población.

La frecuencia y el tamaño de la muestra deben especificarse en el Plan de

Calidad, anotando el número de pruebas, los rechazos esperados, etc. Y también
el coste de efectuar el muestreo.
 Este proceso permite ahorrar recursos, y a la vez obtener resultados parecidos
a los que se alcanzarían si se realizase un estudio de toda la población.

Diagramas de Flujo
Los diagramas de flujo son una manera de representar gráficamente el flujo y la
secuencia de procesos a través de los sistemas. Describen qué operaciones y
en qué secuencia se requieren para alcanzar un resultado o producto, ilustrando
la secuencia de las operaciones que se realizarán.

Los diagramas de flujo facilitan la comunicación entre los involucrados en el

proyecto, y permiten la comprensión de problemas largos y complicados.

Metodologías Propietarias de Gestión de la Calidad

Existen diferentes metodologías de gestión de la calidad, desarrolladas por
instituciones y entidades privadas, que actualmente se consideran modelos de
referencia en la gestión de la calidad. Los principales son:

 SixSigma: metodología de mejora de procesos, centrada en la reducción de la

variabilidad de los mismos. La meta de 6 Sigma es llegar a un máximo de 3,4
defectos por millón de unidades.

 Lean Manufacturing: es una filosofía de gestión enfocada a la reducción de los

7 tipos de "desperdicios" (sobreproducción, tiempo de espera, transporte, exceso
de procesado, inventario, movimiento y defectos) en productos manufacturados.

 CMMI:es un modelo para la mejora y evaluación de procesos para el desarrollo,

mantenimiento y operación de sistemas de software.

Herramientas Adicionales de Planificación de Calidad

En el desarrollo de los planes de calidad, no solo se utilizan elementos propios
de la calidad, sino que se recurre también a técnicas más propias de otros
procesos y fases de la gestión de proyectos:

 Tormenta de ideas: herramienta de trabajo grupal que facilita el surgimiento de

nuevas ideas sobre un tema o problema determinado. La lluvia de ideas es una
técnica de grupo para generar ideas originales en un ambiente relajado.

 Diagramas de afinidad: forma de organizar la información reunida en sesiones

de lluvia de ideas.

 Análisis de campos de fuerzas: Ve el cambio como fuerzas diferentes y

contrapuestas que compiten entre sí. Para propiciar el cambio hay que ver la
relación que existe entre las dos.

 Técnicas de grupo nominal: técnica empleada para facilitar la generación de

ideas y el análisis de problemas. Este análisis se lleva a cabo de un modo
altamente estructurado, permitiendo que al final de la reunión se alcance un buen
número de conclusiones sobre las cuestiones planteadas.
 Diagramas matriciales: es una representación gráfica de las relaciones
existentes entre diferentes tipos de factores y la intensidad de las mismas, en
términos cualitativos.

 Matrices de priorización: es una herramienta que ayuda a comparar y escoger

racionalmente entre varias opciones, con base en unos criterios para fijar
prioridades o tomar una decisión.

Contenido del Plan de Calidad

El Plan de calidad del proyecto debe ser redactado con el objetivo de ofrecer un
acceso fácil a los requisitos de calidad.

La lista siguiente enumera los contenidos que deben incluirse en un plan de

calidad detallado:

 Responsabilidades de la gestión: describen las responsabilidades de calidad

de todos los interesados.

 Sistema de calidad: documenta los procedimientos de calidad existentes que

han sido estandarizados y utilizados dentro de la organización.

 Documentos de calidad: procedimientos para el mantenimiento de los registros

de calidad (métricas, informes de variación, listas de comprobación etc.) Durante
la ejecución del proyecto y para después de la finalización del mismo.

 Control del diseño: procedimientos para la revisión del diseño, cambios de

diseño y exenciones de requisitos.

 Control de la documentación: proceso de control de la documentación del

proyecto en cada fase del mismo.

 Compras: requisitos de calidad para la subcontratación de cualquier parte del

proyecto.

 Criterios de aceptación: conjunto de criterios específicos y medibles, que el

usuario/cliente utilizará para verificar si el proyecto está completo y es correcto.
Constituirán la base para la firma de aceptación del proyecto.

 No conformidades: define los procedimientos para gestionar y solventar

inconformidades. Los procedimientos incluyen:

 La definición de responsabilidades
 La definición de las condiciones
 La disponibilidad de la documentación necesaria

 Acciones correctivas:procedimientos para tomar acciones correctivas para los

problemas encontrados durante la ejecución del proyecto.

 Auditoríasde calidad: se debe planificar e implementar una auditoría interna

durante cada fase del proyecto.
 Formación: requisitos de capacitación para el equipo del proyecto.

Excelencia del Plan de Calidad

El desarrollo de un plan de calidad es un proceso que debe desarrollarse en

equipo, ya que su éxito depende tanto de la comunicación de la información
como de la planificación de actividades. Bajo esta premisa, el jefe de proyecto
preparará los planes y acciones para contrarrestar cualquier debilidad o
deficiencia en la ejecución del proyecto, asegurando así que efectivamente
cumplen todos los estándares de calidad.

El plan no sólo debe ser una lista específica y detallada de todas las normas de
calidad y requisitos, sino que también debería incluir todas las medidas
adoptadas para garantizar que se cumplan.

EL SEGUIMIENTO DEL PROYECTO:

EN DIOS CONFIAMOS, LOS DEMÁS TRAIGAN SUS DATOS

Imagina el plan de proyecto perfecto, un plan basado en necesidades y objetivos

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

Planear no es todo

Malas noticias, tu proyecto podría fallar a pesar de las ventajas de lo mencionado

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

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

Parámetros de control

Es conveniente ponernos de acuerdo en el significado del concepto “proyecto

fracasado”. Normalmente nos hace pensar en proyectos que terminan en
situaciones como las siguientes:

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

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

Es decir, nos referimos a que alguno(s) de los parámetros básicos de planeación

y control del proyecto no se cumplió, por ejemplo alcance, tiempo o costo.

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

¿Y a qué se refiere este seguimiento o monitoreo del proyecto? Va mucho más

allá de simplemente asomarse a ver cómo van las tareas asignadas.

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

en:

Proveer una adecuada visibilidad a la administración sobre la situación del

proyecto para identificar oportunamente cualquier desviación contra lo planeado
con el objetivo de tomar decisiones oportunas para corregirlas.

Visibilidad

Tú, como líder o administrador del proyecto eres responsable de conocer en

todo momento qué pasa con el proyecto; a eso se refiere la visibilidad. Para
lograr esto debes de mantenerte muy atento a todo lo que sucede en el proyecto,
debes realizar las preguntas adecuadas a los participantes y buscar y analizar
los datos importantes del mismo.

Preguntas a resolver

Algunas preguntas fundamentales que debes poder contestar:

 ¿Cuál es el avance en las tareas de los recursos contra lo planeado? (cuánto

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

Cuando identifiques las desviaciones hazlo con las unidades de medición

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

Es importante saber que el proyecto ya se retraso 5 días, pero también debes de

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

Frecuencia del monitoreo

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

Aunque, si notas que las cosas se están poniendo feas en tu proyecto, aumenta
la frecuencia con que realices el seguimiento. Quizás tengas que estar revisando
con detalle el estado del proyecto todos los días, o incluso varias veces al día,
para evitar que las cosas se pongan peor.

Créeme, si las cosas se pueden poner mal, hay grandes probabilidades de que
así sea. Pero, además, siempre se pueden poner peor. Así que es mejor hacer
algo para evitar que esto suceda.

Técnicas de seguimiento

¿Y cómo deberías de realizar el seguimiento? A continuación las técnicas

básicas que normalmente utilizamos para este fin:

 Reuniones. Reuniones con el equipo de trabajo de manera grupal y/o individual

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

La gente en los proyectos suele odiar la documentación y por lo tanto los

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

Lo desafortunado del asunto es que los reportes generados suelen representar

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

Si tienes los recursos económicos para invertir en una buena herramienta de

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

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

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

Recomiendo que por lo menos se incluyan estas secciones, puede ser un

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

 Progreso. ¿Ya terminamos lo que teníamos que terminar a la fecha? ¿cuánto

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

Toma de decisiones

Si consigues mantenerte informado oportunamente de lo que ocurre con el

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

El liderazgo y la toma de decisiones

El seguimiento es otra oportunidad para demostrar el verdadero liderazgo de la

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

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

Aquí de lo que se trata es de actuar, ¡y rápido! Recuerda que el tiempo es oro,

y entre más tardes en resolver las causas de los problemas las desviaciones
seguirán aumentando y por lo tanto el éxito del proyecto se irá alejando cada vez
más de tu vista.

Si no actúas rápido el proyecto se retrasará más de lo que ya está, costará más

de lo que ya está costando, y tu cliente pensará dos veces antes de volver a
contratarte.

Analiza y elimina las causas de las desviaciones

Recuerda analizar con cuidado y buscar las causas reales por las cuales el
proyecto se está desviando de su rumbo y entonces elimina dichas causas lo
antes posible.
 Como ejemplo, uno de los integrantes de tu equipo puede estar retrasándose
porque:

 No tiene la información suficiente para trabajar (¡proporciónasela!)

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

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

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

Recuerda que un carro de carreras sin alguien que lo maneje eficientemente

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

Recuerda que ser líder (administrador, gerente o director) de proyectos no

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

Ser un líder de proyecto requiere ciertas habilidades, pero también conocimiento

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

FASE DE EVALUACIÓN DE UN PROYECTO DE SOFTWARE–MUCHO MÁS

QUE EVALUACIÓN

En este artículo se describirán algunos de los beneficios de la fase de evaluación

de un proyecto de desarrollo de software, y cómo asegurar que la empresa y el
administrador de proyecto puedan crecer.

Definición de la Fase de Evaluación

Es muy difícil definir "fase de evaluación". Para ilustrar la idea de este artículo,
la fase de evaluación se referirá a la fase en la cual las evaluaciones exhaustivas
comienzan a ser realizadas en los productos de desarrollo (generalmente por
evaluadores designados). Para objetivos de discusión, la evaluación exhaustiva
comienza desde las etapas de integración y hasta la prueba de sistema. Muchos
refieren a esta etapa como la “Etapa QA” (Quality Assurance o Aseguramiento
de la Calidad), a causa de la complejidad del concepto “QA” y la descripción
enorme, este artículo se adherirá al concepto “fase de evaluación”.

Objetivos de la Fase de Evaluación

Antes de que estudiemos el aporte de la fase de evaluación al proyecto, es

importante entender los objetivos declarados en esta fase. Las respuestas
aceptadas de estas interrogantes son las siguientes:

 Permitir que las partes interesadas en el producto reciban una medición de su

calidad y cumplimiento de sus requerimientos.
 Demostrar que el software hace lo que se supone debe hacer (Definición
problemática y parcial).
 Encontrar las brechas o entre lo que se supone que debe hacer o no el software
y lo que realmente hace o no (definición completa más ligera).

Esto es efectivamente el propósito principal de la fase de evaluación – una fase

importante y crítica para el éxito del proyecto.

Sin embargo, ¿esto es el objetivo exclusivo?. ¿Es el trabajo de los evaluadores

catalogados de este modo?. En la mayoría de los casos la respuesta es positiva
sin mucha vacilación, ya que la tarea de ellos está enfocada a marcar una “V” la
calidad del producto como es percibido por muchos, lo que resulta en la carencia
de la atención administrativa.
La mayor parte de los focos en el proyecto, al igual que el entusiasmo
administrativo, está en la etapa de desarrollo (en su sentido tradicional: el mundo
de los desarrolladores de software).

En vista de esto, los administradores tienden a poner menos énfasis en la

planeación de la fase de evaluación en las etapas de planificación del proyecto
y se presta mucha mayor atención a esta etapa (y tienen razón, así es). Pero en
realidad este estímulo demuestra que no es trivial. De lo contrario no sería
necesario.

Muchos de los project managers recuerdan la fase de evaluación sólo en el

último minuto. Pocos se involucran e integran a ésta en las etapas de
planificación y únicamente los “meticulosos” hacen alusión a la planeación de la
evaluación como una parte integral de la planeación del proyecto por sí misma.

Funciones adicionales de la "Fase de Evaluación"

La experiencia en campo muestra que la actitud simplista en la fase de

evaluación reduce su aporte al proyecto. La fase de evaluación oculta mucho
valor para el administrador del proyecto y la empresa en general:

A. Primero y muy importante, y en concordancia con el objetivo declarado, la

fase de evaluación otorga una visión de calidad del producto del proyecto. Ésta
es la clásica y obvia contribución de los managers implicados. Ya después de la
rotación de la primera evaluación, los sentimientos viscerales de aquellos
involucrados comienzan a desaparecer y a transformarse basados en
evaluaciones más científicas. Hay un reporte de estado que comienza a hacerse
más claro por primera vez, permitiendo al project manager un suspiro de alivio
(incluso un poco) para primera vez o bien comenzar a preocuparse (pero esta
vez fuera del conocimiento…).

B. Al principio de la etapa de redacción del plan de evaluación (antes del

comienzo de la evaluación): muchos problemas aparecen en los documentos de
diseño: ambigüedad, manejo de casos extremos, imprecisión y otros. Esto
resulta en una gran precaución, puntualidad y meticulosidad que caracteriza el
personal de pruebas. Su entrenamiento y personalidades son las que los
empujan a realizar preguntas (a diferencia de la gente de desarrollo quienes
tienen una tendencia mayor de interpretar de manera subjetiva). Por lo general
el costo de encontrar estos problemas en una etapa posterior es mucho mayor.

Ejemplo: En un proyecto el cual fue planeado para tomar tres meses (dos
semanas de diseño, un mes para el desarrollo, dos semanas para la evaluación
y una semana de instalación), la redacción del plan de evaluación fue demorada
una semana antes del inicio de la evaluación. Durante la escritura de éste (por
el estudio de muchos casos extremos) el evaluador se avalancha con un número
de preguntas relacionadas a las temas que no quedaron claros en el diseño.
Estas preguntas motivan un cambio básico en el diseño y consecuentemente en
el desarrollo. El resultado fue de dos semanas de retraso total en el proyecto.
Además del evaluador, nadie prestó atención a estos incidentes tempranos.
C. La transferencia del estado de desarrollo a la fase de evaluación se
caracteriza normalmente vinculando las diferentes terminaciones de los
productos del proyecto. En muchos casos unos pocos desarrolladores trabajan
en un número de partes diferentes del software. A veces una etapa en sí misma
es dedicada a la evaluación de la integración. A veces la fase de evaluación
constituye la primera oportunidad para ver todos los componentes diferentes
trabajando juntos. Este es el momento en el cual las “excavadoras de túneles”
de ambos lados se encuentran. A veces únicamente en esta etapa convergen
los últimos detalles finalizados de las interfaces y la configuración específica.

Ejemplo: En un proyecto para un cliente determinado, una configuración de un

sistema específico fue requerida, por lo cual se definieron algunos parámetros
diferentes. Durante el desarrollo el software, éste fue revisado con una variedad
de parámetros sin ninguna conexión con las especificaciones del cliente. Durante
las pruebas, los evaluadores también insistieron en revisar las demandas
específicas del cliente y las evaluaciones revelaron contradicciones funcionales
precisamente en estos casos.

D. Continuando con el párrafo anterior al ejemplo, la fase de evaluación

comienza desde la instalación (no necesariamente el primero pero sí el más
importante) del software y/o del producto. Esta es la primera vez que el producto
en sí pasa las manos (y no sólo documentos). Hay dos transferencias que son
las siguientes:

1) Tecnológica: La transferencia de un ambiente (desarrollo) a otro ambiente

(pruebas). Es posible referirse a esta operación como el primer ensayo para la
instalación operacional y para examinar la calidad del proceso de instalación en
sí mismo.

Ejemplo: En un proyecto, la instalación del producto en la transferencia de la fase

de desarrollo a la evaluación duró aproximadamente dos días. El plan de
instalación operacional tuvo un plazo de tiempo de sólo 6 horas. Como
consecuencia de la instalación ampliada, la empresa estuvo forzada a asignar
otra semana para reducir el tiempo de instalación. El proyecto demoró otra
semana pero una sorpresa desafortunada fue evitada durante la noche de la
instalación operacional.

2) Transferencia de conocimiento: El producto es más que su tecnología. El

producto combina procesos, interfaz de usuario, terminología y más. En un
mundo utópico los evaluadores no necesitan el producto para familiarizarse con
éste (ellos ya están implicados en la fase de diseño). En la práctica esto no
sucede. La fase de pruebas tiene que comenzar con la capacitación apropiada
del personal de pruebas. Esta formación es el fundamento inicial para el material
de entrenamiento del producto. Por lo tanto, la transferencia de conocimiento
constituye la primera indicación del proceso de entrenamiento y la asimilación
requerida.

Ejemplo: Un proyecto que consistió en muchas interfaces de usuario, el

programa de adiestramiento estaba enormemente basado en datos y
conclusiones que fueron reportadas por los evaluadores (basados en su
experiencia personal).

E. La fase de pruebas no es una fase consecutiva y homogénea. Por naturaleza

es una etapa cíclica conducida en rotaciones (sin relación con la metodología de
la completa administración de proyectos). Los jugadores importantes participan
en estas rotaciones: gerentes de producto, equipo de desarrollo y el project
manager. La tensión organizacional creada entre el evaluador y el evaluado, la
necesidad de tomar muchas pequeñas decisiones (a veces también son
grandes) en ocasiones generan la formación de algunas comunicaciones inter-
organizacionales: ¿Cuál es el defecto?, ¿Cuál es el cambio?, ¿Qué es crítico?,
¿Cuándo reparar?, ¿Sí hay que reparar?. Esta comunicación mejora el
funcionamiento del equipo en otros proyectos y así contribuye a la mejora de los
procesos en la empresa. Por una buena razón, las herramientas para administrar
los defectos/cambios fueron las primeras en ser asimiladas en el proceso de
administración del proyecto. Para mejorar las habilidades de organización y
comunicación.

Ejemplo: Había una carencia de comunicación entre dos empresas que fueron
socias en un proyecto de desarrollo, que incluyó un número de desarrollos y
ciclos de prueba. Las etapas de diseño y desarrollo se vieron afectadas a raíz de
las diferencias de entendimiento y metodología del trabajo que casi condujo a
una paralización completa del proyecto en la fase de evaluación conjunta. A la
luz de esto, muchos esfuerzos administrativos fueron invertidos para definir el
proceso de trabajo y la comunicación, la cual está basada en métodos de trabajo
acordados y tecnología de soporte. Estos procesos que fueron definidos en la
fase de pruebas ayudaron al resto de los ciclos en el proyecto.

F. El proceso de pruebas incluye un formato estructurado de medición:

estadísticas de defectos, porcentaje de cobertura, medidas funcionales del
producto y la mayoría de sus medidas no funcionales. Al "panel de control" del
administrador del proyecto se le añade inmediatamente muchos indicadores que
reducen la incertidumbre y mejoran su capacidad de planificar la continuación
del proyecto.

Ejemplo: En un proyecto irregular en la empresa, fueron realizadas las

evaluaciones cuidadosamente, para el tiempo de pruebas (debido a las
innovaciones en el proyecto: de nueva interfase y empleo de un nuevo producto
de anaquel). Al principio de la fase de pruebas, el gerente de pruebas comenzó
a advertir sobre una estadística de base diaria a los resultados de las pruebas:
defectos y porcentajes de cobertura. El análisis de los resultados mostró el paso
de las pruebas y suministró un instrumento objetivo para planificar la
continuación del proyecto.

Utilización del Potencial Oculto de la Fase de Pruebas

De lo ya mencionado puede verse que el proceso de pruebas constituye un

esquema importante para los gerentes. Para el administrador del proyecto esto
es un instrumento central que le permite controlar el proyecto entero (y no sólo
la calidad del producto). Para el resto de los gerentes es un instrumento bueno
para el control de la empresa, y aún más, una oportunidad de aprender, mejorar
y asimilar procesos.

La fase de pruebas indica la madurez de la empresa, la calidad de procesos de

diseño, procesos de desarrollo y más. Un buen proceso de diseño no indicará un
proceso inferior de prueba, pero sí lo contrario. Desde este punto de vista los
que se confunden entre los conceptos " pruebas de producto " y "aseguramiento
de la calidad" (QA) tienen razón (por bondad y no a favor de). En el amplio
sentido del significado, el concepto de aseguramiento de la calidad se refiere a
todos los procesos de la empresa y no sólo a la calidad del producto. Y el
argumento es que la manera de examinar la calidad del producto indica la calidad
de los procesos de empresa.

La conclusión obvia es dedicar mucha más atención a la fase de pruebas y

proveer el ambiente necesario para asegurar su ejecución de una forma correcta
y apropiada –para ser precisos con la sincronización correcta: aclaratoria de los
contenidos que están siendo evaluados, congelando el código, interés por el
ambiente de pruebas apropiado y conveniente y la aprobación de todos los
socios en el proyecto sobre el plan de pruebas.

Además, el project manager debería involucrar activamente a los evaluadores

en todas las fases, e incluso administrar el hito del inicio de pruebas. De ser
posible, es recomendable comenzar a probar ciclos tan temprano como sea
(aunque haya muchas desventajas en un inicio temprano, es necesario saber
cómo administrarlos). La cooperación entre el jefe del proyecto y el gerente de
pruebas es crítica.

Al nivel de empresa, la importancia debe ser aplicada al personal encargado de

las pruebas (y en especial sus directivos) con el fin de maximizar el potencial de
la contribución global a la compañía más allá de la calidad del producto en sí.

Por último, hay casos en los cuales es correcto usar metodologías del mundo de
pruebas en otros procesos de la empresa como puede ser el uso de las
mediciones. Un ejemplo extremo incluye la etapa de desarrollo en la fase de
pruebas para forzar una estructura “ágil” en el proyecto si es requerida (sobre
todo si la empresa no es experta en esto).

Ejemplo: En un proyecto de cuatro meses y debido a las condiciones de certeza

(presión del tiempo y características del cliente) fue conocido de antemano que
habrían cambios en los requerimientos durante el desarrollo. La empresa decidió
iniciar los ciclos de pruebas en una etapa más temprana. Todos los mecanismos
de revisión de defectos en alta frecuencia y versiones administración de
desarrollo acordadamente sirvieron como puntos de modificación en el diseño.
En estas frecuencias encontradas (una vez cada dos días, en un formato corto)
todas las partes interesadas estuvieron presentes: los diseñadores,
desarrolladores, evaluadores y el administrador del proyecto. El proyecto recibió
un tipo de administración ágil natural y familiar sin ninguna necesidad de
capacitación específica. Esta decisión aseguró el éxito del proyecto.
Resumen

La fase de pruebas de un proyecto tiene un objetivo principal, importante y bien

conocido pero más allá de esto, constituye una amplia gama de oportunidades
para mejorar los procesos en la empresa y ocultar dentro del alto valor para el
project manager. Las conciencias de este potencial en la etapa inicial y sus usos
pueden servir como un elemento estratégico que asegure el éxito de los
proyectos y como una fuerza conductora para estudios de grandes periodos y
desarrollo.

GESTIÓN DE LA CALIDAD

Uno de los problemas que se afrontan actualmente en la esfera de la informática

es el proceso de la calidad del software. Desde la década del 70, este tema ha
sido motivo de preocupación para especialistas, ingenieros, investigadores y
comercializadores de software.

La calidad del software es el conjunto de cualidades que lo caracterizan y que

determinan su utilidad y existencia. La calidad es sinónimo de eficiencia,
flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad,
seguridad e integridad.

En términos generales la calidad de software puede definirse como el grado en

que un conjunto de características inherentes al software cumple con unos
requisitos explícitos e implícitos.

La implantación de un sistema de calidad en una organización ayuda a mejorar

la gestión del desarrollo de software, y esto traerá como consecuencia una
disminución de los problemas y errores, favoreciendo las relaciones y
comunicación entre las personas y grupos de organización, y de éstos con los
clientes.

La gestión de la calidad va tomando cada día mayor importancia en el ámbito del

desarrollo de software. De esta forma, los esfuerzos encaminados a integrar la
gestión de la calidad dentro de la gestión de los proyectos deben generar
también un aumento de la productividad.

Este artículo se basa en caracterizar los cuatro procesos que se encargan de

definir las actividades para determinar los objetivos y las responsabilidades
relativos a la calidad, de modo que percibamos como la gestión de la calidad
dentro de la ingeniería del software va encaminada al aseguramiento de la
calidad del software a lo largo del proceso de desarrollo del mismo.

La obtención de un software con calidad implica la utilización de metodologías o

procedimientos, estándares para el análisis, diseño, programación y prueba del
software que permitan uniformar la filosofía de trabajo, en aras de lograr una
mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la
 productividad, tanto para la labor de desarrollo como para el control de la calidad
del software.

Gestión de la calidad de software: Conjunto de actividades de la función

general de la dirección que determina la calidad, los objetivos y las
responsabilidades y se implanta por medios tales como:

1. Planificación de la Calidad del Software.

2. Control de la Calidad del Software.
3. Aseguramiento de la Calidad del Software.
4. Mejora de la Calidad del Software 1

1. La Planificación de la Calidad del Software

Es la parte de la Gestión de la Calidad encargada de realizar el proceso

administrativo de desarrollar y mantener una relación entre los objetivos y
recursos de la organización; y las oportunidades cambiantes del mercado.

El objetivo es modelar y remodelar los negocios y productos de la empresa, de

manera que se combinen para producir un desarrollo y utilidades satisfactorias.

Los aspectos a considerar en la Planificación de la Calidad de Software son:

Modelos/Estándares de Calidad de Software a utilizar, Costos de la Calidad de
Software, Recursos humanos y materiales necesarios, entre otras.

El plan de calidad define los atributos de calidad más importantes del producto a
ser desarrollado y define el proceso de evaluación de la calidad.

En la Planificación de la Calidad de Software se debe determinar:

 Rolde la Planificación.
 Requerimientos de la Calidad de Software.
 Preparación de un Plan de Calidad de Software.
 Implementación de un Plan de Calidad de Software
 Preparar un Manual de Calidad.

2. El Control de la Calidad del Software

Son las técnicas y actividades de carácter operativo, utilizadas para satisfacer

los requisitos relativos a la calidad. Son las inspecciones, revisiones y pruebas
para asegurar la calidad del producto centradas en 2 objetivos fundamentales:

 Mantener bajo control un proceso.

 Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

El control de calidad del software se ha convertido, por tanto en una parte

esencial de los programas de control de calidad. La atención de los requisitos
específicos de la calidad del software es una actividad que esta integrada a
través del programa de procesamientos de información de la calidad.
 Está formado por actividades que permiten evaluar la calidad de los productos
de software desarrollados. El aspecto a considerar en el Control de la Calidad de
Software es la “Prueba del Software”.

Las pruebas son elementos críticos para determinar la calidad del software. Es
el proceso de ejecutar un programa con intención de encontrar defectos. Es un
proceso destructivo que determina el diseño de los casos de prueba y la
asignación de responsabilidades.

Objetivos de las pruebas:

 Encontrar defectos en el software.

 Una prueba tiene éxito si descubre un defecto.
 Una prueba fracasa si hay defectos pero no los descubre.
 Ejecución de un programa con la intención de descubrir un error.
 Técnica experimental para la búsqueda de errores en los programas.

Algunos principios de las pruebas recogen lo siguiente:

 Las pruebas deberían planificarse mucho antes de que comiencen.

 No son posibles las pruebas exhaustivas: El número de permutaciones de
camino para incluso programas pequeños es excepcionalmente grande. Por ese
motivo es imposible ejecutar todas las combinaciones de caminos durante las
pruebas.
 Para ser más eficaces, las pruebas deberían ser realizadas por un equipo
independiente: El ingeniero de software que creo el sistema no es el más
adecuado para realizar las pruebas del software, ya que consciente o
inconscientemente tiende a probar lo que sabe que funciona.

Existen varios tipos de pruebas que pueden realizarse durante el proceso de

desarrollo de software como son:

 Unitarias: Pretenden probar cada función en un archivo de programa simple (una

clase en terminología de objetos).
 Integración: Pretenden comprobar la integración de los componentes, es decir,
la comunicación a través de interfaces, acceso incoherente a estructuras de
datos globales.

Las pruebas de integración pueden realizarse de forma ascendente o

descendente

 Validación:Pretende comprobar que se satisfacen los requisitos.

 Sistema: Se centran en comprobar la recuperación, seguridad, resistencia,
rendimiento.

Asociado a los tipos de pruebas existen también técnicas de pruebas que ayudan
a definir conjuntos de casos de pruebas aplicando ciertos criterios, como son:
 Pruebas de caja blanca: Se centra en comprobar la interacción interna de los
componentes del sistema.
 Pruebas de caja negra: “Se centran en los requisitos funcionales del software. O
sea, la prueba de de caja negra permite al ingeniero del software obtener un
conjunto de condiciones de entrada que ejerciten completamente todos los
requisitos”.

La prueba demuestra hasta qué punto las funciones del software parecen
funcionar de acuerdo con las especificaciones y parecen alcanzarse los
requisitos de rendimiento. Además, los datos que se van recogiendo a medida
que se lleva a cabo la prueba proporcionan una buena indicación de la
confiabilidad del software e indican la calidad del software como un todo.

Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede

demostrar que existen defectos en el software.

3. El Aseguramiento de Calidad del Software

Es el conjunto de actividades planificadas y sistemáticas necesarias para aportar

la confianza que el software satisfará los requisitos dados de calidad. Se trata de
una actividad de protección que se aplica a lo largo de todo el proceso de
ingeniería del software.

Se diseña para cada aplicación antes de comenzar a desarrollarla y no después.

El aseguramiento de la calidad del software engloba:

 Un enfoque de gestión de calidad.

 Métodos y herramientas de Ingeniería del Software.
 Revisiones técnicas formales aplicables en el proceso de software.
 Una estrategia de prueba multiescala.
 El control de la documentación del software y de los cambios realizados.
 Procedimientos para ajustarse a los estándares de desarrollo del software.
 Mecanismos de medición y de generación de informes.

Todo el que esté involucrado en el proceso de desarrollo del software es

responsable de la calidad desarrolladores, analistas, arquitectos, jefes de
proyectos, clientes y aquellas personas que en los proyectos llamamos grupo de
aseguramiento de la calidad.

Las actividades del grupo de aseguramiento de la calidad son:

 Establecimiento del plan de aseguramiento de la calidad para un proyecto.

 Participación en el desarrollo de la descripción del proceso de software.
 Revisión de las actividades de ingeniería del software.
 Auditorías de los procesos de software designados para verificar el ajuste con
los definidos como parte del proceso de software.
 Registrar lo que no se ajuste a los requisitos e informar a los superiores.
  Coordinar el control de cambio.

CMMI v1.2 en el área de proceso de aseguramiento de la calidad propone:

 Elaborar objetivamente los procesos.

 Evaluar objetivamente los artefactos y servicios.
 Comunicar y asegurar la resolución de las no conformidades.
 Establecer registros.

Además de estas actividades, el grupo de aseguramiento de la calidad coordina

el control y la gestión de cambios y; ayuda a recopilar y analizar las métricas del
software.

Las métricas son escalas de unidades sobre las cuales puede medirse un
atributo cuantificable. Cuando se habla de software nos referimos a la disciplina
de recopilar y analizar datos basándonos en mediciones reales de software, así
como a las escalas de medición.

Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores
de métricas se derivan de los requisitos del cliente o de los usuarios y, por lo
tanto, actúan como restricciones dentro del proyecto.

Las medidas de Calidad del Software deben comenzar desde la especificación y

terminar con la implementación, implantación y mantenimiento o post-
implantación. Debe aplicarse a lo largo de todo el proceso de Ingeniería de
Software. Básicamente, la medición es una fase normal de cualquier actividad
industrial Sin mediciones es imposible perseguir objetivos comerciales normales
de una manera racional.

4. La Mejora de la Calidad del Software

Es la parte de la Gestión de la Calidad que contribuye, por medio de las

mediciones, a los análisis de los datos y auditorías, a efectuar mejoras en la
calidad del software.

Las auditorías según el estándar ISO 19011:2002 se define como: proceso

sistemático, independiente y documentado para evaluar el estado actual
(evidencias de la auditoría) y evaluarlas de manera objetiva con el fin de
determinar la extensión en que se cumplen los criterios de auditoría.

Una Auditoría de Calidad tiene como objetivo:

 Mostrar la situación real para aportar confianza y destacar las áreas que pueden
afectar adversamente esa confianza.
 Suministrar una evaluación objetiva de los productos y procesos para corroborar
la conformidad con los estándares, las guías, las especificaciones y los
procedimientos.
Los resultados de la auditoría son documentados y remitidos al director de la
organización auditada, a la entidad auditora, y cualquier organización externa
identificada en el plan de auditoria. El informe incluye la lista de elementos no
conformes u otros aspectos para las posteriores revisiones y acciones. Cuando
se realiza el plan de auditoría, las recomendaciones son informadas e incluidas
en los resultados de la auditoría.

Para implementar un programa de mejoras es necesario definir procesos, decidir

qué se quiere mejorar, definir qué medidas serán necesarias recoger, cómo y
dónde tomarlas, gestionarlas mediante herramientas, utilizarlas para la toma de
decisiones y reconocer las mejoras.

Cuando el proceso a mejorar es el de desarrollo del software, es importante

definir qué objetivos se quieren alcanzar, para reducir el número de medidas y,
en consecuencia, el coste de recopilarlas y el impacto sobre la actividad de
producción de software.

Conclusiones

La calidad ha dejado de ser un tópico y es necesario que forme parte de los

productos o servicios que comercializamos para nuestros clientes. El cliente es
el mejor auditor de la calidad, él exige el nivel que está dispuesto a pagar por
ella, pero no más. Por tanto, debemos de cuantificar cuál es el nivel de calidad
que nos exige para poder planificar la calidad de los productos que se generen
a lo largo de la producción del producto o servicio final.

Al analizar las necesidades de nuestros clientes, deberemos tener en cuenta la

previsible evolución de sus necesidades y tendencias en cuanto a
características. Deberemos tener en cuenta la evolución tecnológica del entorno
de producción de nuestros productos para suministrarlos con el nivel tecnológico
adecuado.

La Calidad de Software es resultado del movimiento global dentro del proceso

de mejoramiento continuo de los modelos y/o estándares de producción en todos
los sectores, en particular, cuando éste se concentra en la producción de
sistemas de información y software especializado.

KAIZEN Y KAIKAKU: DOS FORMAS DE IMPLANTAR PROYECTOS ÁGILES

Hace ya casi dos años, hubo un poco de inconformidades muy evidentes con
respecto de Scrum. Puede que se iniciara con un ensayo que titulé “Declive y
Caída de Agile”, que se remonta a Noviembre del 2008 y que después se volvió
a encender con una participación de Martin Fowler que se llamó "Scrum flácido".
En infoq se publicó un resumen, por si desean ver algunos vínculos al respecto
de todo aquel debate.

De hecho, no era mi intención atacar Scrum. Mi verdadero punto puede

encontrarse en los párrafos de cierre de mi ensayo: “Es naturaleza humana sólo
hacer lo que nos resulta conocido y divertido y eso es lo que ha sucedido con lo
Agile”. Pero no acusé a Scrum ni a la Scrum Alliance de hacer que la situación
fuese peor.

Unas cuantas personas se levantaron para defender a Scrum. Tobias Mayer,

que comentaba sobre mi ensayo original, fue particularmente elocuente:
“Escuchen. Scrum no es una metodología. No es un proceso. Es una
infraestructura para sacar a la luz la disfunción organizacional. En realidad,
Scrum no hace NADA. La gente hace las cosas. La infraestructura de Scrum, si
se enseña de manera efectiva, le da a las personas la oportunidad de despertar
y conocerse de una buena vez. Si no lo hacen, se quedarán sin negocio. Bien.
Los otros sabrán cómo hacer cambios rápidamente y, es muy probable, llamarán
a buenos consultores en ingeniería. Olvídense del "Agile", pues sólo son buenas
prácticas de software, han existido mucho antes de que la etiqueta de “Agile” se
les aplicara para denominarlas de manera colectiva. Además de ser un
manifiesto, Agile en realidad no es algo en concreto”.

Y esto es absolutamente correcto.

Así que, ¿qué está sucediendo? ¿Por qué hay tantas implementaciones Agile
que están fallando?

Kaizen
Kaizen significa "mejoramiento continuo". Viene del japonés, y está asociado con
lo que conocemos como manufactura esbelta [Lean], así que se trata de una
palabra que está de moda en estos momentos [y lleva décadas en vigor dentro
de otros rubros. N. Del E.]. Pero la mejora continua ha sido una parte principal
de los procesos Agiles desde que se les concibió. Incluso se trata del 12°
principio en el manifiesto: "en intervalos regulares, el equipo reflexiona acerca
de cómo hacerse más efectivo, luego afina y ajusta su conducta en
consecuencia".

Un equipo Agile debe observar de manera continua qué es lo que está haciendo
y esforzarse por mejorar. Los métodos de Agile apoyan esta idea al exponer
problemas. Diana Larsen me lo describió de esta forma (y creo que estaba
citando a Esther Derby): "Es como manejar con un parabrisas sucio. Todo está
bien hasta que viras hacia donde se está poniendo el sol. Es entonces cuando
no podrás ver nada. Dirás: ‘¿de dónde salió toda esta suciedad?' Pero siempre
estuvo ahí —el sol no ocasionó que apareciera todo ese polvo, sólo lo hizo
visible".

Así que sí, un equipo Agile debe inspeccionar y adaptarse continuamente, y lo

Agile nos brinda las herramientas para hacer justo eso. Y... Hay algunas cosas
que, al principio, no serán visibles para los equipos.

¿El kaizen ayudará a estos equipos? Eventualmente. ¿Significa eso que

debamos dejarlos colgados hasta que se sequen —esperar a que todo salga
mal, catastróficamente, y entonces esperar que ellos aprendan de sus errores?
Tengan en cuenta que eso es lo que estamos observando en el campo: los
equipos comienzan bien, y luego tienen dificultades. Es una buena entrada
monetaria para nosotros los consultores, pero preferiría que las personas no se
metieran en esos problemas en absoluto.

Kaikaku

Kaikaku también viene del japonés, aunque aún no está tan en boga como kaizen
(pero denle tiempo). Significa "transformación"; es cambio rápido —la
introducción de enfoques completamente nuevos.

Ahora, en honor a la verdad, kaikaku es una forma de kaizen. Kaizen no

necesariamente significa cambio gradual, pero es la forma más popular con la
que se le asocia.

Como término de uso popular, kaikaku está en contraste al kaizen. Es un cambio

rápido: contratar a un coach para que dirija a tu equipo; leer un libro e
implementar las ideas tal cual están escritas; conducir un taller para mapeo del
flujo de valor y hacer cambios significativos.

Donde se equivocaron

Ahora, llegamos a la parte donde varias implementaciones Agile se han

equivocado —hay que nota que no fueron no todas ellas. Ciertamente, no las de
ustedes. Pero muchas sí).

Hay dos maneras de que las implementaciones de Agile se desvíen y produzcan

errores:

1. Primera, los equipos aplican kaizen dentro de las limitantes de sus hábitos y
patrones establecidos. Hacen mejoras menores, pero se pierden u omiten todas
las ideas transformativas.

2. Segunda, los equipos subestiman el costo humano del cambio. Cuando en

efecto implementan cambios significativos, lo hacen de manera gradual y
eventualmente se agotan.

De hecho, también existen muchas maneras más en las que las cosas pueden
salir mal, entre las cuales, como mínimo, destacan la inclusión de la cultura
organizacional y el compromiso gerencial, pero en este artículo yo me enfoco en
cómo los equipos incluyen nuevas prácticas).

Perderse Ideas Transformativas

Jeffrey Liker lo dice en The Toyota Way: "[El gerente] dice es hora de
convertirnos en un equipo. Así que todos se agrupan en la sala de conferencias
para trabajar en el mejoramiento de la productividad. Lo que es probable que
suceda es que los integrantes del equipo se concentrarán en reducir la cantidad
de tiempo que toma desempeñar los procesos de valor agregado, el trabajo que
ellos desempeñan o trabajarán en cuestiones de comodidad como ajustar la
iluminación a niveles óptimos o instalar un dispensador de agua fría. Durante el
proceso [de este ejemplo], los trabajadores laboran individualmente, así que es
natural que sólo se concentren en sus tareas individuales".

Ahora, vamos a considerar el caso de un experto en TPS [Lean] que llega y

analiza este proceso que empleamos como ejemplo. De inmediato, el experto
observaría que no existe flujo y que hay una gran cantidad de desperdicio. La
primera tarea para el experto en TPS podría ser mejorar el flujo y eliminar la
mayor parte del inventario que se está interponiendo en la unión de las
operaciones.

Para los equipos resulta muy difícil cambiar sus hábitos de trabajo. Lo intentarán
y harán cambios, pero sin la exposición a nuevas ideas esos cambios será
incrementales y producto de la evolución, no de una revolución. Los equipos
Cascada harán cascadas menores. Los equipos ced (centrados en
documentación) mejorarán sus documentos. Las culturas orientadas a la culpa
se las ingeniarán para inventar maneras más eficientes de asignar
culpabilidades.

Varias de las mayores oportunidades que ofrece Agile son las ideas
transformativas. Son ideas del tipo de desarrollo centrado en pruebas, equipos
co-localizados e interfuncionales, participación intensiva del cliente, fases
simultáneas, y una disposición de cero defectos. Estas son las ideas más
extravagantes. La mayoría de los equipos mal llamados "Agile" no están llevando
a cabo ninguna de estas cosas, y muy pocos las están llevando a cabo todas.

Algunas cosas no se pueden alcanzar mediante el cambio gradual.

Agotarse eventualmente

En The Art of Agile Development, Shane y yo escribimos: "La incomodidad y una

particular sensación de caos son normales para cualquier equipo que esté
pasando por un cambio, pero esto no lo hace menos intimidante como reto.
Pueden esperar que dicha sensación caótica continúe durante dos meses,
cuando menos. Dense de cuatro a nueve meses para de verdad sentirse
completamente cómodos con su nuevo proceso. Sin embargo, hemos de
hacerles notar que si están adoptando XP de manera incremental, esto les
llevará más tiempo.

... Pueden [adoptar XP en incrementos], pero si tienen un proyecto de nueva

creación, de hecho es más fácil y rápido adoptar todas las prácticas de una vez.
El caos y la incertidumbre del cambio son los que hace que adoptar XO sea
difícil, no las prácticas en sí mismas. Si adoptan XP de manera incremental, cada
nueva práctica romperá el equilibrio por el que estarán luchando para lograrlo.
De hecho, extenderán el periodo de caos e incertidumbre, haciendo que la
transición sea aún más difícil".

Pueden introducir iteraciones (o Sprints) y después integración continua, y luego

desarrollo con base en pruebas, y entonces diseño incremental continuo, para
luego añadir clientes en las instalaciones, y a continuación un espacio de trabajo
compartido, y luego programación pareada, y además...
O al menos pueden intentarlo. A los equipos les lleva años cumplir con esta listas
y es agotador. No conozco de alguno que lo haya logrados todavía. ¡En serio! Ni
uno —y antes de que me digan que no necesitaban todas esas cosas, déjenme
decirles que ni siquiera las probaron. Eso no es kaizen; eso es rendirse.

O bien, pueden tomarse cerca de seis meses, más o menos, y hacerlo todo al
mismo tiempo. El cambio gradual es menos atemorizante, pero no es ni más fácil
ni más exitoso.

Comiencen con Kaikaku

He trabajado con muchos equipos Agile y he conversado con aún más

integrantes de este tipo de equipos. El argumento final es este: los equipos Agile
de alto desempeño inician con kaikaku. Comienzan con algo probado, dicen que
van a dar su mejor esfurzo y entonces... En realidad lo hacen.

Luego continúan con kaizen, inspeccionando y adaptándose de manera

continua, preguntando porqué es que algo que no les gustó funciona y porqué
algo que sí les gustaba no funciona. Nunca acaba de aprender o mejorar. Pero
esto comienza con una transformación.

Para lograr un equipo Agile de alto desempeño, comiencen con kaikaku.

También necesitarán otras cosas, como el compromiso de parte de los directivos
y apoyo desde la base. Estas cosas están más allá del alcance de este pequeño
ensayo. Pero una vez que las condiciones estén dadas para adoptar la
metodología Agile, usen kaikaku. Realicen un gran cambio. Contraten a un coach
o llévenlo a acabo siguiendo el libro. Una vez hecho esto, apliquen kaizen.
Presten atención, sean receptivos, inspeccionen y adapten.

La ideología y metodología Kaizen es importante... Y no es toda la historia.

Ustedes requieren de más que sólo el cambio gradual para llegar a donde
quieren encontrarse.
 SECCIÓN I, CAPITULO IV, TITULO
SEGUNDO DEL REGLAMENTO DE
OBRAS PUBLICAS Y SERVICIOS
RELACIONADOS CON LAS MISMAS
Tarea 5.
Subtema 5.1 Perfil del Residente de Obra y Superintendente de Construcción
Subtema 5.2 Perfil del Supervisor

REGLAMENTO DE LA LEY DE OBRAS PÚBLICAS Y SERVICIOS

RELACIONADOS CON LAS MISMAS

SECCIÓN I
DE LOS RESPONSABLES DE LOS TRABAJOS

Artículo 112.- El titular del Área responsable de la ejecución de los trabajos

designará al servidor público que fungirá como residente, debiendo tomar en
cuenta los conocimientos, habilidades y capacidad para llevar a cabo la
supervisión, vigilancia, control y revisión de los trabajos; el grado académico; la
experiencia en administración y construcción de obras y realización de servicios;
el desarrollo profesional y el conocimiento en obras y servicios similares a
aquéllos de que se hará cargo. La designación del residente deberá constar por
escrito.
Para efectos de lo dispuesto en el primer párrafo del artículo 53 de la Ley, se
considerará que la residencia se encuentra ubicada en el sitio de ejecución de
los trabajos, cuando se localice en la zona de influencia de la ejecución de los
mismos en los casos en que las características, complejidad y magnitud de los
trabajos haga necesario establecer la residencia de esta manera, para lo cual el
titular del Área responsable de la ejecución de los trabajos dejará constancia en
el expediente respectivo de las justificaciones con las que se acredite dicha
necesidad.
Las dependencias y entidades que contraten de manera ocasional obras y
servicios y no cuenten con áreas o estructuras especializadas para tales fines ni
con servidores públicos con las aptitudes descritas en el primer párrafo del
presente artículo deberán prever, durante la etapa de planeación de las obras o
servicios de que se trate, las acciones necesarias para obtener el apoyo de
dependencias o entidades que se relacionen con la naturaleza de la obra o
servicio a ejecutar y que cuenten con servidores públicos que reúnan los
requisitos señalados en el primer párrafo de este artículo, a efecto de que éstos
puedan fungir como residentes, para lo cual deberán celebrar las bases de
colaboración o acuerdos de coordinación que correspondan.
Artículo 113.- Las funciones de la residencia serán las siguientes:
I. Supervisar, vigilar, controlar y revisar la ejecución de los trabajos;
II. Tomar las decisiones técnicas correspondientes y necesarias para la
correcta ejecución de los trabajos, debiendo resolver oportunamente
las consultas, aclaraciones, dudas o solicitudes de autorización que
presente el supervisor o el superintendente, con relación al
cumplimiento de los derechos y obligaciones derivadas del contrato;
III. Vigilar, previo al inicio de los trabajos, que se cumplan con las
condiciones previstas en los artículos 19 y 20 de la Ley;
IV. Verificar la disponibilidad de los recursos presupuestales necesarios
para la suscripción de cualquier convenio modificatorio que implique la
erogación de recursos;
V. Dar apertura a la Bitácora en términos de lo previsto por la fracción III
del artículo 123 de este Reglamento, así como por medio de ella, emitir
las instrucciones pertinentes y recibir las solicitudes que le formule el
superintendente. Cuando la Bitácora se lleve por medios
convencionales, ésta quedará bajo su resguardo;
VI. Vigilar y controlar el desarrollo de los trabajos, en sus aspectos de
calidad, costo, tiempo y apego a los programas de ejecución de los
trabajos, de acuerdo con los avances, recursos asignados y
rendimientos pactados en el contrato. Cuando el proyecto requiera de
cambios estructurales, arquitectónicos, funcionales, de proceso, entre
otros, deberá recabar por escrito las instrucciones o autorizaciones de
los responsables de las áreas correspondientes;
VII. Vigilar que, previamente al inicio de la obra, se cuente con los proyectos
arquitectónicos y de ingeniería, especificaciones de calidad de los
materiales y especificaciones generales y particulares de construcción,
catálogo de conceptos con sus análisis de precios unitarios o alcance
de las actividades de obra o servicio, programas de ejecución y
suministros o utilización, términos de referencia y alcance de servicios;
VIII. Revisar, controlar y comprobar que los materiales, la mano de obra, la
maquinaria y equipos sean de la calidad y características pactadas en
el contrato;
IX. Autorizar las estimaciones, verificando que cuenten con los números
generadores que las respalden;
X. Coordinar con los servidores públicos responsables las terminaciones
anticipadas o rescisiones de contratos y, cuando se justifique, las
suspensiones de los trabajos, debiéndose auxiliar de la dependencia o
entidad para su formalización;
XI. Solicitar y, en su caso, tramitar los convenios modificatorios necesarios;
XII. Rendir informes con la periodicidad establecida por la convocante, así
como un informe final sobre el cumplimiento del contratista en los
aspectos legales, técnicos, económicos, financieros y administrativos;
XIII. Autorizar y firmar el finiquito de los trabajos;
XIV. Verificar la correcta conclusión de los trabajos, debiendo vigilar que el
Área requirente reciba oportunamente el inmueble en condiciones de
operación, así como los planos correspondientes a la construcción final,
los manuales e instructivos de operación y mantenimiento y los
certificados de garantía de calidad y funcionamiento de los bienes
instalados;
XV. Presentar a la dependencia o entidad los casos en los que exista la
necesidad de realizar cambios al proyecto, a sus especificaciones o al
contrato, a efecto de analizar las alternativas de solución y determinar
la factibilidad, costo, tiempo de ejecución y necesidad de prorrogar o
modificar el contrato, y
XVI. Las demás funciones que las disposiciones jurídicas le confieran, así
como aquéllas que le encomienden las dependencias y entidades.
Artículo 114.- En atención a las características, complejidad y magnitud de
los trabajos el residente podrá auxiliarse por la supervisión en términos de lo
dispuesto por el segundo párrafo del artículo 53 de la Ley, la cual tendrá las
funciones que se señalan en este Reglamento, con independencia de las que
se pacten en el contrato de supervisión.
Cuando no se cuente con el auxilio de la supervisión, las funciones a que se
refiere el artículo 115 de este Reglamento estarán a cargo de la residencia.
Artículo 115.- Las funciones de la supervisión serán las que a continuación
se señalan:
I. Revisar de manera detallada y previamente al inicio de los trabajos, la
información que le proporcione la residencia con relación al contrato,
con el objeto de enterarse de las condiciones en las que se desarrollará
la obra o servicio y del sitio de los trabajos, así como de las diversas
partes y características del proyecto, debiendo recabar la información
necesaria que le permita iniciar los trabajos de supervisión según lo
programado y ejecutarlos ininterrumpidamente hasta su conclusión;
II. Participar en la entrega física del sitio de la obra al superintendente y
proporcionar trazos, referencias, bancos de nivel y demás elementos
que permitan iniciar adecuadamente los trabajos;
III. Obtener de la residencia la ubicación de las obras inducidas y
subterráneas y realizar con el contratista el trazo de su trayectoria;
IV. Integrar y mantener al corriente el archivo derivado de la realización de
los trabajos, el cual contendrá, entre otros, los siguientes documentos:
a) Copia del proyecto ejecutivo, incluyendo el proceso constructivo, las
normas, las especificaciones y los planos autorizados;
b) Matrices de precios unitarios o cédula de avances y pagos
programados, según corresponda;
c) Modificaciones autorizadas a los planos;
d) Registro y control de la Bitácora y las minutas de las juntas de obra;
e) Permisos, licencias y autorizaciones;
f) Contratos, convenios, programas de obra y suministros, números
generadores, cantidades de obra realizadas y faltantes de ejecutar y
presupuesto;
g) Reportes de laboratorio y resultado de las pruebas, y
h) Manuales y garantía de la maquinaria y equipo;
V. Vigilar la adecuada ejecución de los trabajos y transmitir al contratista
en forma apropiada y oportuna las órdenes provenientes de la
residencia;
VI. Dar seguimiento al programa de ejecución convenido para informar al
residente sobre las fechas y las actividades críticas que requieran
seguimiento especial, así como sobre las diferencias entre las
actividades programadas y las realmente ejecutadas, y para la
aplicación de retenciones económicas, penas convencionales,
descuentos o la celebración de convenios;
VII. Registrar en la Bitácora los avances y aspectos relevantes durante la
ejecución de los trabajos con la periodicidad que se establezca en el
contrato;
VIII. Celebrar juntas de trabajo con el superintendente o con la residencia
para analizar el estado, avance, problemas y alternativas de solución,
 consignando en las minutas y en la Bitácora los acuerdos tomados y
dar seguimiento a los mismos;
IX. Vigilar que el superintendente cumpla con las condiciones de
seguridad, higiene y limpieza de los trabajos;
X. Revisar las estimaciones a que se refiere el artículo 130 de este
Reglamento para efectos de que la residencia las autorice y,
conjuntamente con la superintendencia, firmarlas oportunamente para
su trámite de pago, así como comprobar que dichas estimaciones
incluyan los documentos de soporte respectivo;
XI. Llevar el control de las cantidades de obra o servicio realizados y de
las faltantes de ejecutar, cuantificándolas y conciliándolas con la
superintendencia; para ello, la supervisión y la superintendencia
deberán considerar los conceptos del catálogo contenido en la
proposición del licitante a quien se le haya adjudicado el contrato, las
cantidades adicionales a dicho catálogo y los conceptos no previstos
en el mismo;
XII. Llevar el control del avance financiero de la obra considerando, al
menos, el pago de estimaciones, la amortización de anticipos, las
retenciones económicas, las penas convencionales y los descuentos;
XIII. Avalar las cantidades de los insumos y los rendimientos de mano de
obra, la maquinaria y el equipo de los conceptos no previstos en el
catálogo de conceptos contenido en la proposición del licitante a quien
se le haya adjudicado el contrato, presentados por la superintendencia
para la aprobación del residente;
XIV. Verificar que los planos se mantengan actualizados, por conducto de
las personas que tengan asignada dicha tarea;
XV. Analizar detalladamente el programa de ejecución convenido
considerando e incorporando, según el caso, los programas de
suministros que la dependencia o entidad haya entregado al contratista,
referentes a materiales, maquinaria, equipos, instrumentos y
accesorios de instalación permanente;
XVI. Coadyuvar con la residencia para vigilar que los materiales, la mano de
obra, la maquinaria y los equipos sean de la calidad y características
pactadas en el contrato, vigilando que la superintendencia presente
oportunamente los reportes de laboratorio con sus resultados;
XVII. Verificar la debida terminación de los trabajos dentro del plazo
convenido;
XVIII. Coadyuvar en la elaboración del finiquito de los trabajos, y
XIX. Las demás que le señale la residencia o la dependencia o entidad en
los términos de referencia respectivos.
Artículo 116.- Cuando la supervisión sea realizada por terceros, las
dependencias y entidades observarán, además de los lineamientos a que se
refiere el segundo párrafo del artículo 53 de la Ley, las siguientes previsiones:
I. Las funciones señaladas en el artículo anterior, así como las que
adicionalmente prevean las dependencias y entidades para cada caso
particular, deberán ser congruentes con los términos de referencia
respectivos y asentarse en el contrato que se suscriba, y
II. Tanto en los términos de referencia como en el contrato deberán
especificarse los productos o los documentos esperados y su forma de
 presentación. Entre los documentos señalados, deberán incluirse los
informes que serán presentados con la periodicidad establecida por la
convocante, los cuales serán el respaldo de las estimaciones
correspondientes y deben contemplar como mínimo los siguientes
aspectos:
a) Las variaciones del avance físico y financiero de la obra;
b) Los reportes de cumplimiento de los programas de suministro de
materiales, mano de obra, maquinaria y equipo;
c) Las minutas de trabajo;
d) Los cambios efectuados o por efectuar al proyecto;
e) Las pruebas de laboratorio realizadas o por realizar en la ejecución de
los trabajos;
f) Los comentarios explícitos de las variaciones registradas en el periodo,
en relación a los programas convenidos, así como la consecuencia o
efecto de dichas variaciones para la conclusión oportuna de la obra y
las acciones tomadas al respecto, y
g) La memoria fotográfica.
Artículo 117.- El superintendente deberá conocer con amplitud los
proyectos, normas de calidad y especificaciones de construcción, catálogo
de conceptos o actividades de obra o servicio, programas de ejecución y de
suministros, incluyendo los planos con sus modificaciones, especificaciones
generales y particulares de construcción y normas de calidad, Bitácora,
convenios y demás documentos inherentes, que se generen con motivo de la
ejecución de los trabajos.
La dependencia o entidad podrá reservarse en el contrato el derecho de
solicitar en cualquier momento, por causas justificadas, la sustitución del
superintendente y el contratista tendrá la obligación de nombrar a otro que
reúna los requisitos exigidos en el contrato.
Artículo 118.- Si el contratista realiza trabajos por mayor valor del contratado,
sin mediar orden por escrito de parte de la dependencia o entidad,
independientemente de la responsabilidad en que incurra por la ejecución de
los trabajos excedentes, no tendrá derecho a reclamar pago alguno por ello,
ni modificación alguna del plazo de ejecución de los trabajos.
Cuando los trabajos no se hayan realizado de acuerdo con lo estipulado en
el contrato o conforme a las órdenes escritas de la dependencia o entidad,
ésta podrá ordenar su demolición, reparación o reposición inmediata con los
trabajos adicionales que resulten necesarios, los cuales se harán por cuenta
del contratista sin que tenga derecho a retribución adicional alguna por ello.
En este caso, la dependencia o entidad, si lo estima necesario, podrá ordenar
la suspensión total o parcial de los trabajos contratados en tanto no se lleve
a cabo la demolición, reposición o reparación indicadas, sin que esto sea
motivo para ampliar el plazo señalado para su terminación.
Artículo 119.- Los trabajos quedarán bajo la responsabilidad del contratista
hasta el momento de su entrega a la dependencia o entidad, por lo que
quedará a su cargo, entre otros aspectos, la conservación y la limpieza de los
mismos.
Artículo 120.- El contratista estará obligado a coadyuvar con la autoridad
competente en la extinción de incendios comprendidos en las zonas en que
se ejecuten los trabajos objeto del contrato, con el personal y elementos de
que disponga para ese fin. El contratista deberá dar aviso al residente de la
existencia de incendios, de su localización y magnitud.
Artículo 121.- El contratista tendrá la obligación de notificar al residente la
aparición de cualquier brote epidémico en la zona de los trabajos objeto del
contrato y, de ser posible, coadyuvar a combatirlo con los medios de que
disponga. También enterará al residente cuando con los trabajos se afecten
las condiciones ambientales y los procesos ecológicos de la zona en que se
realicen los propios trabajos.
 SECCIÓN III, CAPITULO IV, TITULO
SEGUNDO DEL REGLAMENTO DE
OBRAS PUBLICAS Y SERVICIOS
RELACIONADOS CON LAS MISMAS
 SECCIÓN IV, CAPITULO IV, TITULO
SEGUNDO DEL REGLAMENTO DE
OBRAS PUBLICAS Y SERVICIOS
RELACIONADOS CON LAS MISMAS.
Tarea 6.
Subtema 5.3 Control del ejecutor. Avance físico. Avance financiero. Control de
especificaciones técnicas

REGLAMENTO DE LA LEY DE OBRAS PÚBLICAS Y SERVICIOS

RELACIONADOS CON LAS MISMAS

SECCIÓN III
DE LA FORMA DE PAGO

Artículo 127.- Las cantidades de trabajos presentadas en las estimaciones

deberán corresponder a la secuencia y tiempo previsto en el programa de
ejecución convenido, así como a los estándares de desempeño que, en su caso,
se establezcan en la convocatoria a la licitación pública y en el contrato.
Las dependencias y entidades deberán establecer en el contrato el lugar en que
se realizará el pago y las fechas de corte, las que podrán referirse a fechas fijas,
o bien, a un acontecimiento que deba cumplirse.
El atraso que tenga lugar por la falta de pago de estimaciones no implicará
retraso en el programa de ejecución convenido y, por tanto, no se considerará
como causa de aplicación de penas convencionales ni como incumplimiento del
contrato y causa de rescisión administrativa. Tal situación deberá documentarse
y registrarse en la Bitácora.
El retraso en el pago de estimaciones en que incurran las dependencias y
entidades diferirá en igual plazo la fecha de terminación de los trabajos,
circunstancia que deberá formalizarse, previa solicitud del contratista, a través
del convenio respectivo. No procederá dicho diferimiento cuando el retraso en el
pago derive de causas imputables al contratista.
Artículo 128.- Una vez analizados y calculados los importes de las estimaciones,
las dependencias y entidades deberán considerar para su pago los derechos e
impuestos que les sean aplicables, así como retener el importe de los mismos,
cuando corresponda, de conformidad con las disposiciones fiscales aplicables.
Dentro del plazo a que se refiere el segundo párrafo del artículo 54 de la Ley, la
dependencia o entidad deberá revisar la factura y, si reúne los requisitos
administrativos y fiscales, tramitar y realizar el pago de la misma al contratista.
El contratista será el único responsable de que las facturas que se presenten
para su pago cumplan con los requisitos administrativos y fiscales, por lo que la
falta de pago por la omisión de alguno de éstos o por su presentación incorrecta
no será motivo para solicitar el pago de los gastos financieros a que hace
referencia el artículo 55 de la Ley.
En caso de que las facturas entregadas por los contratistas para su pago
presenten errores o deficiencias, la dependencia o entidad, dentro de los tres
días hábiles siguientes al de su recepción, indicará por escrito al contratista las
deficiencias que deberá corregir. El periodo que transcurra entre la entrega del
citado escrito y la presentación de las correcciones por parte del contratista no
se computará para efectos del segundo párrafo del artículo 54 de la Ley.
Artículo 129.- Las dependencias y entidades considerarán la posibilidad de
utilizar medios de comunicación electrónica para la presentación y autorización
de las estimaciones con base en las cuales se realice el pago a los contratistas,
siempre que cuenten con los sistemas electrónicos que garanticen la
inalterabilidad y confiabilidad de la información y previamente obtengan la
autorización de la Secretaría de la Función Pública.
Las dependencias y entidades que estén en posibilidad de realizar el pago a
contratistas por medios electrónicos, de conformidad con el párrafo anterior,
deberán dar al contratista la opción de recibirlos por dichos medios, de lo
contrario, se deberá justificar tal circunstancia ante el órgano interno de control
correspondiente.
Artículo 130.- En los contratos de obras y servicios únicamente se reconocerán
los siguientes tipos de estimaciones:
I. De trabajos ejecutados;
II. De pago de cantidades adicionales o conceptos no previstos en el
catálogo original del contrato;
III. De gastos no recuperables a que alude el artículo 62 de la Ley, y
IV. De los ajustes de costos.
Las estimaciones autorizadas por la residencia se considerarán como
documentos independientes entre sí, por lo que cada una podrá ser
negociada para efectos de su pago.
Artículo 131.- El pago de las estimaciones no se considerará como la
aceptación plena de los trabajos, ya que la dependencia o entidad tendrá el
derecho de reclamar por trabajos faltantes o mal ejecutados y, en su caso,
del pago en exceso que se haya efectuado.
Artículo 132.- Los documentos que deberán acompañarse a cada estimación
serán determinados por cada dependencia o entidad, atendiendo a las
características, complejidad y magnitud de los trabajos, los cuales serán,
entre otros, los siguientes:
I. Números generadores;
II. Notas de Bitácora;
III. Croquis;
IV. Controles de calidad, pruebas de laboratorio y fotografías;
V. Análisis, cálculo e integración de los importes correspondientes a cada
estimación;
VI. Avances de obra, tratándose de contratos a precio alzado, y
VII. Informe del cumplimiento de la operación y mantenimiento conforme al
programa de ejecución convenido, tratándose de amortizaciones
programadas.
Artículo 133.- En los contratos bajo la condición de pago sobre la base de
precios unitarios se tendrán por autorizadas las estimaciones que las
dependencias y entidades omitan resolver respecto de su procedencia,
dentro del término que para tal efecto dispone el primer párrafo del artículo
54 de la Ley.
En todos los casos, el residente deberá hacer constar en la Bitácora la fecha
en que se presentan las estimaciones.
En el caso de que el contratista no presente las estimaciones en el plazo
establecido en el primer párrafo del artículo 54 de la Ley, la estimación
correspondiente se presentará en la siguiente fecha de corte, sin que ello dé
lugar a la reclamación de gastos financieros por parte del contratista.
Artículo 134.- En los contratos celebrados bajo la condición de pago a precio
alzado las dependencias y entidades podrán optar por estipular el pago del
importe de los trabajos hasta su total terminación o cuando se finalice cada
actividad principal de los trabajos, conforme a lo dispuesto por el artículo 222
de este Reglamento y de acuerdo a las fechas pactadas.
Cuando las características, magnitud y complejidad de los trabajos que se
vayan a realizar lo requieran, las dependencias y entidades podrán solicitar
en la convocatoria a la licitación pública, la invitación a cuando menos tres
personas y la solicitud de cotización, según corresponda, que los
participantes establezcan fechas críticas a las que se ajustarán sus
programas de ejecución, con el objeto de que en el contrato correspondiente
se pacte el pago respectivo y que los trabajos puedan tener la continuidad
necesaria para su oportuna terminación. En todos los casos, las fechas
críticas deben corresponder a porcentajes parciales de ejecución de trabajos,
ser congruentes con el financiamiento requerido por el participante y ser
claramente medibles, así como congruentes con la red de actividades, la
cédula de avances y pagos programados y, en general, con los programas
de ejecución pactados.
Artículo 135.- En los contratos que celebren las dependencias y entidades
cuya condición de pago se haya pactado mediante amortización programada,
se establecerán los plazos, términos y condiciones en los que se efectuarán
los pagos, los que deberán ser acordes con el programa de amortización
convenido.
Artículo 136.- El pago de los ajustes de costos directos y del costo por
financiamiento se efectuará en las estimaciones de ajuste de costos
siguientes al mes en que se haya autorizado el ajuste, aplicando al importe
de las estimaciones el incremento desglosado correspondiente a los factores
que se autoricen para cada tipo de ajuste, debiéndose aplicar los últimos que
se tengan autorizados.
Todos los factores de ajuste concedidos deberán acumularse entre ellos.
Artículo 137.- La autorización del pago de los gastos no recuperables deberá
constar por escrito, acompañando la documentación que acredite su
procedencia, sin necesidad de celebrar convenio alguno.
El pago de las estimaciones de gastos no recuperables autorizados
debidamente comprobados se realizará conforme a los términos y
condiciones del segundo párrafo del artículo 54 de la Ley.
Una vez calculados los importes de los gastos no recuperables en términos
de este artículo, no se podrán aplicar a dichos importes los porcentajes por
concepto de indirectos, financiamiento y utilidad a que se refieren los artículos
212, 214 y 219 de presente Reglamento.

SECCIÓN IV
DE LOS ANTICIPOS

Artículo 138.- El importe de los anticipos que se otorguen con base en los
contratos de obras o de servicios, será el que resulte de aplicar el porcentaje
señalado en la convocatoria a la licitación pública al monto total de la
proposición, si los trabajos se realizan en un solo ejercicio. Cuando los
trabajos se realicen en más de un ejercicio el monto del anticipo se obtendrá
aplicando el porcentaje señalado en la convocatoria a la licitación pública al
monto total de la asignación presupuestal autorizada para el contrato en el
ejercicio de que se trate.
Para determinar el porcentaje de los anticipos que se otorgarán conforme al
presente artículo, las dependencias y entidades deberán tener en cuenta las
características, complejidad y magnitud de los trabajos, los que tendrán por
objeto apoyar la debida ejecución y continuidad de las obras y servicios.
Previamente a la entrega del anticipo, el contratista deberá presentar al Área
responsable de la ejecución de los trabajos un programa en el que se
establezca la forma en que se aplicará dicho anticipo, lo cual deberá
precisarse en la convocatoria a la licitación pública y en el contrato. El área
mencionada deberá requerir al contratista la información conforme a la cual
se acredite el cumplimiento del citado programa; tal requerimiento podrá
realizarse en cualquier momento durante la vigencia del contrato.
En el caso de que el contratista no cumpla el programa a que se refiere el
párrafo anterior por causas debidamente justificadas y acreditadas ante el
Área responsable de la ejecución de los trabajos, dicho programa deberá ser
modificado conforme a las nuevas condiciones que se hubieren presentado.
Artículo 139.- En el supuesto a que se refiere la fracción IV del artículo 50
de la Ley, cuando las condiciones de los trabajos requieran que se otorgue
un anticipo superior al cincuenta por ciento de la asignación presupuestal
aprobada para el contrato, el Área responsable de la contratación deberá
informar a la Secretaría de la Función Pública, previamente a la entrega del
anticipo, señalando las razones que lo sustenten.
Para los efectos de lo dispuesto por la fracción V del artículo 50 de la Ley, el
Área responsable de la contratación autorizará otorgar como anticipo hasta
el monto total de la asignación autorizada al contrato durante el primer
ejercicio.
Artículo 140.- El diferimiento del programa de ejecución convenido a que se
refiere la fracción I del artículo 50 de la Ley, sólo procederá cuando exista
atraso en la entrega del anticipo que se pactó realizar en una sola exhibición
o, cuando se hubiere pactado su entrega en varias parcialidades, exista
atraso en la entrega de la primera parcialidad.
Artículo 141.- El importe del anticipo se pondrá a disposición del contratista
contra la entrega de la garantía prevista en la fracción I del artículo 48 de la
Ley.
Cuando el contratista no ejerza el anticipo otorgado en la forma pactada en
el contrato y conforme al programa a que se refiere el párrafo tercero del
artículo 138 de este Reglamento, las dependencias y entidades no podrán
exigirle cargo alguno, salvo en el supuesto a que se refiere el último párrafo
del artículo 50 de la Ley.
Artículo 142.- Para los efectos de la Ley y este Reglamento, una vez
autorizado el anticipo correspondiente al contrato de que se trate, o bien, al
convenio modificatorio respectivo, las dependencias y entidades deberán
considerarlo como un importe pagado.
Artículo 143.- Para la amortización de los anticipos otorgados se procederá
de la siguiente manera:
I. El anticipo se amortizará del importe de cada estimación de trabajos
ejecutados que presente el contratista conforme al programa de
ejecución convenido; dicha amortización deberá ser proporcional al
porcentaje de anticipo otorgado, sin perjuicio de lo dispuesto en la
fracción III incisos a), b) y c) de este artículo;
II. Cuando respecto de los contratos en los que se consideraron anticipos,
se celebren convenios modificatorios que no prevén anticipos para
ejecutar los trabajos que amparen, no se realizará amortización alguna
ni afectación en el ajuste de costos.
En el caso de que por el cambio del ejercicio presupuestario, los
convenios modificatorios señalados en el párrafo anterior hayan sido
considerados para actualizar la asignación presupuestaria del ejercicio
siguiente de acuerdo con lo dispuesto en el tercer párrafo del artículo
23 de la Ley, la amortización del anticipo se realizará aplicando el
porcentaje establecido en el contrato considerando la asignación
presupuestaria actualizada, y
III. El procedimiento de amortización deberá realizarse conforme a lo
siguiente:
A) Cuando los trabajos se realicen en un solo ejercicio, se considerará lo
siguiente:
1. El importe del anticipo otorgado en el ejercicio se amortizará en el mismo
periodo del ejercicio en que se otorgue;
2. Cuando en la estimación presentada no se logre amortizar el anticipo
conforme al importe previsto en el programa de ejecución convenido, por
causas imputables al contratista, dicho importe se sumará al que corresponda
amortizar en la siguiente estimación de acuerdo al mencionado programa, y
3. Cuando por causas no imputables al contratista no se logre amortizar el
anticipo otorgado conforme a los importes establecidos en el programa de
ejecución convenido, la amortización del importe pendiente se ajustará de
acuerdo a la modificación de dicho programa;
B) En el caso de que los trabajos se ejecuten en más de un ejercicio, se
atenderá a lo siguiente:
1. El importe del anticipo otorgado se amortizará en el mismo ejercicio en que
se otorgue;
2. Cuando no se logre amortizar el anticipo otorgado en el ejercicio por
causas imputables al contratista, el saldo pendiente por amortizar se
descontará del importe a otorgar como anticipo en el siguiente ejercicio. En
este supuesto, en las estimaciones correspondientes a los trabajos atrasados
que se presenten en el siguiente ejercicio, no serán afectadas por concepto
de amortización de anticipo. En el caso de que no se amortice el anticipo
otorgado en los ejercicios subsecuentes se aplicará lo previsto en los párrafos
anteriores del presente numeral;
3. En caso de que el anticipo no se amortice en el ejercicio en que se otorgue
por causas no imputables al contratista, el saldo por amortizar no se
reintegrará en ese ejercicio y el anticipo previsto para el siguiente se
entregará cuando inicien los trabajos programados para este último ejercicio.
El porcentaje de la amortización del anticipo en el siguiente ejercicio será el
resultado de dividir el anticipo no amortizado del ejercicio de que se trate,
más el anticipo concedido en el siguiente ejercicio, entre el importe total de
los trabajos a ejecutar en el siguiente ejercicio, conforme al programa de
ejecución convenido.
En el caso previsto en el presente numeral, el anticipo del siguiente ejercicio
se entregará siempre y cuando el contratista acredite haber aplicado el
anticipo del ejercicio anterior conforme al programa a que se refiere el tercer
párrafo del artículo 138 de este Reglamento;
C) En caso de que el anticipo se otorgue conforme a lo señalado en el primer
párrafo de la fracción V del artículo 50 de la Ley, deberá procederse de la
siguiente manera:
1. El porcentaje de la amortización del anticipo en el primer ejercicio será el
resultado de dividir el importe del anticipo concedido en el primer ejercicio
conforme al programa de ejecución convenido, entre el importe total de los
trabajos a ejercer en el primero y segundo ejercicios, conforme al programa
de ejecución convenido;
2. El porcentaje de la amortización del anticipo en el segundo ejercicio será
el resultado de dividir el saldo por amortizar del primer ejercicio más el
anticipo concedido en el segundo, entre el importe total de los trabajos a
ejercer en el segundo ejercicio, conforme al programa de ejecución
convenido. En caso de que los trabajos se ejecuten en más de dos ejercicios
el porcentaje de amortización para el tercer ejercicio y subsecuentes deberá
calcularse conforme a lo establecido en el presente numeral, amortizándolo
en términos de lo dispuesto en el inciso a) de esta fracción, y
3. Cuando no se logre amortizar el anticipo otorgado en el ejercicio de que se
trate, se procederá conforme a lo señalado en los numerales 2 y 3 del inciso
b) de esta fracción, según corresponda, y
D) En caso de que exista un saldo faltante por amortizar, éste deberá
liquidarse totalmente en la estimación final.
 SECCIÓN II, CAPITULO IV, TITULO
SEGUNDO DEL REGLAMENTO DE
OBRAS PUBLICAS Y SERVICIOS
RELACIONADOS CON LAS MISMAS
Tarea 7.
Subtema 5.4 Uso de la bitácora de obra

REGLAMENTO DE LA LEY DE OBRAS PÚBLICAS Y SERVICIOS

RELACIONADOS CON LAS MISMAS

SECCIÓN II
DE LA BITÁCORA

Artículo 122.- El uso de la Bitácora es obligatorio en cada uno de los contratos

de obras y servicios. Su elaboración, control y seguimiento se hará por medios
remotos de comunicación electrónica, para lo cual la Secretaría de la Función
Pública implementará el programa informático que corresponda.
La Secretaría de la Función Pública autorizará que la elaboración, control y
seguimiento de la Bitácora se realice a través de medios de comunicación
convencional cuando las dependencias y entidades así lo soliciten en los
siguientes casos:
I. Cuando por virtud del sitio donde se realicen los trabajos existan
dificultades tecnológicas que impidan llevar la Bitácora a través de
medios remotos de comunicación electrónica;
II. Cuando se ejecuten trabajos derivados de caso fortuito o fuerza mayor;
III. Cuando el uso de la Bitácora a través de medios remotos de
comunicación electrónica ponga en riesgo la seguridad nacional o la
seguridad pública, en términos de las leyes de la materia, y
IV. Si las dependencias y entidades realizan de manera ocasional obras y
servicios.
La información contenida en la Bitácora podrá ser consultada por la
Secretaría de la Función Pública o por los órganos internos de control en el
ejercicio de sus facultades de inspección, vigilancia y control.
Artículo 123.- Las dependencias y entidades usarán la Bitácora atendiendo
al medio de comunicación a través del cual se opere.
Para el uso de la Bitácora electrónica y la Bitácora convencional, se
considerará lo siguiente:
I. Las hojas originales y sus copias deben estar siempre foliadas y
referidas al contrato de que se trate;
II. El contenido de cada nota deberá precisar, según las circunstancias de
cada caso: número, clasificación, fecha, descripción del asunto,
ubicación, causa, solución, prevención, consecuencia económica,
responsabilidad si la hubiere y fecha de atención, así como la
referencia, en su caso, a la nota que se contesta;
III. Se deberá iniciar con una nota especial relacionando como mínimo la
fecha de apertura, datos generales de las partes involucradas, nombre
 y firma del personal autorizado, domicilios y teléfonos, datos
particulares del contrato y alcances descriptivos de los trabajos y de las
características del sitio donde se desarrollarán; la inscripción de los
documentos que identifiquen oficialmente al residente y, en su caso, al
supervisor, así como al superintendente por parte del contratista,
quienes serán los responsables para realizar registros en la Bitácora,
indicando, en su caso, a quién o a quiénes se autoriza para llevar a
cabo dichos registros.
Además de lo dispuesto en el párrafo anterior, se establecerá un plazo
máximo para la firma de las notas, debiendo acordar las partes que se
tendrán por aceptadas una vez vencido el plazo;
IV. El horario en el que se podrá consultar y asentar notas, el que deberá
coincidir con las jornadas de trabajo de campo;
V. Todas las notas deberán numerarse en forma seriada y fecharse
consecutivamente respetando, sin excepción, el orden establecido;
VI. Se prohibirá la modificación de las notas ya firmadas, inclusive para el
responsable de la anotación original;
VII. Cuando se cometa algún error de escritura, redacción o cualquier otro
que afecte la debida comunicación entre las partes, la nota deberá
anularse por quien la emita, señalando enseguida de dicha nota la
mención de que ésta ha quedado anulada y debiendo abrir, de ser
necesario, otra nota con el número consecutivo que le corresponda y
con la descripción correcta;
VIII. No se deberá sobreponer ni añadir texto alguno a las notas de Bitácora,
ni entre renglones, márgenes o cualquier otro sitio; de ser necesario
adicionar un texto, se deberá abrir otra nota haciendo referencia a la de
origen;
IX. Se deberán cancelar los espacios sobrantes de una hoja al completarse
el llenado de las mismas;
X. Cuando se requiera, se podrán ratificar en la Bitácora las instrucciones
emitidas vía oficios, minutas, memoranda y circulares, refiriéndose al
contenido de los mismos, o bien, anexando copias;
XI. Deberá utilizarse la Bitácora para asuntos trascendentes que deriven
de la ejecución de los trabajos en cuestión;
XII. El residente, el superintendente y, en su caso, el supervisor deberán
resolver y cerrar invariablemente todas las notas que les correspondan,
o especificar que su solución será posterior, debiendo en este último
caso relacionar la nota de resolución con la que le dé origen, y
XIII. El cierre de la Bitácora se consignará en una nota que dé por
terminados los trabajos. En atención a las características, complejidad
y magnitud de los trabajos la residencia podrá realizar la apertura de
una Bitácora por cada uno de los frentes de la obra, o bien, por cada
una de las especialidades que se requieran.
Artículo 124.- Para el uso de la Bitácora convencional, además de lo
señalado en el artículo anterior, se considerará lo siguiente:
I. Se deberá contar con un original para la dependencia o entidad y al
menos dos copias, una para el contratista y otra para la residencia o la
supervisión;
II. Las copias deberán ser desprendibles, no así las originales;
III. Las notas o asientos deberán efectuarse claramente, con tinta indeleble
y letra legible;
IV. La nota cuyo original y copias aparezcan con tachaduras y
enmendaduras será nula;
V. Una vez firmadas las notas de la Bitácora, los interesados podrán retirar
sus respectivas copias, y
VI. La Bitácora deberá permanecer en la residencia a fin de que las
consultas requeridas se efectúen en el sitio.
Artículo 125.- Cuando se presenten cualquiera de los eventos que a
continuación se relacionan, se deberá efectuar el registro en la Bitácora
mediante la nota correspondiente conforme a lo siguiente:
I. Al residente le corresponderá registrar:
A) La autorización de modificaciones al proyecto ejecutivo, al procedimiento
constructivo, a los aspectos de calidad y a los programas de ejecución
convenidos;
B) La autorización de estimaciones;
C) La aprobación de ajuste de costos;
D) La aprobación de conceptos no previstos en el catálogo original y
cantidades adicionales;
E) La autorización de convenios modificatorios;
F) La terminación anticipada o la rescisión administrativa del contrato;
G) La sustitución del superintendente, del anterior residente y de la
supervisión;
H) Las suspensiones de trabajos;
I) Las conciliaciones y, en su caso, los convenios respectivos;
J) Los casos fortuitos o de fuerza mayor que afecten el programa de
ejecución convenido, y
K) La terminación de los trabajos;
II. Al superintendente corresponderá registrar:
A) La solicitud de modificaciones al proyecto ejecutivo, al procedimiento
constructivo, a los aspectos de calidad y a los programas de ejecución
convenidos;
B) La solicitud de aprobación de estimaciones;
C) La falta o atraso en el pago de estimaciones;
D) La solicitud de ajuste de costos;
E) La solicitud de conceptos no previstos en el catálogo original y cantidades
adicionales
F) La solicitud de convenios modificatorios, y
 G) El aviso de terminación de los trabajos, y
III. A la supervisión le corresponderá registrar:
A) El avance físico y financiero de la obra en las fechas de corte señaladas
en el contrato;
B) El resultado de las pruebas de calidad de los insumos con la periodicidad
que se establezca en el contrato o mensualmente;
C) Lo relacionado con las normas de seguridad, higiene y protección al
ambiente que deban implementarse, y
D) Los acuerdos tomados en las juntas de trabajo celebradas con el
contratista o con la residencia, así como el seguimiento a los mismos.
El registro de los aspectos señalados en las fracciones anteriores se realizará
sin perjuicio de que los responsables de los trabajos puedan anotar en la Bitácora
cualesquiera otros que se presenten y que sean de relevancia para los trabajos.
Artículo 126.- Por lo que se refiere a contratos de servicios, la Bitácora deberá
contener como mínimo las modificaciones autorizadas a los alcances del
contrato, las ampliaciones o reducciones de los mismos y los resultados de las
revisiones que efectúe la dependencia o entidad, así como las solicitudes de
información que tenga que hacer el contratista para efectuar las labores
encomendadas.
 SECCIÓN V, CAPITULO IV, TITULO
PRIMERO DE LA LEY GENERAL
DEL EQUILIBRIO ECOLÓGICO Y
LA PROTECCIÓN AL AMBIENTE.
Tarea 7.
Subtema 5.6 Mitigación de afectaciones al medio ambiente

LEY GENERAL DEL EQUILIBRIO ECOLÓGICO Y LA PROTECCIÓN AL

AMBIENTE

SECCION V
Evaluación del Impacto Ambiental

ARTÍCULO 28.- La evaluación del impacto ambiental es el procedimiento a

través del cual la Secretaría establece las condiciones a que se sujetará la
realización de obras y actividades que puedan causar desequilibrio ecológico o
rebasar los límites y condiciones establecidos en las disposiciones aplicables
para proteger el ambiente y preservar y restaurar los ecosistemas, a fin de evitar
o reducir al mínimo sus efectos negativos sobre el medio ambiente. Para ello, en
los casos en que determine el Reglamento que al efecto se expida, quienes
pretendan llevar a cabo alguna de las siguientes obras o actividades, requerirán
previamente la autorización en materia de impacto ambiental de la Secretaría:
I.- Obras hidráulicas, vías generales de comunicación, oleoductos,
gasoductos, carboductos y poliductos;

II.- Industria del petróleo, petroquímica, química, siderúrgica, papelera,

azucarera, del cemento y eléctrica;

III.- Exploración, explotación y beneficio de minerales y sustancias

reservadas a la Federación en los términos de las Leyes Minera y
Reglamentaria del Artículo 27 Constitucional en Materia Nuclear;

IV.- Instalaciones de tratamiento, confinamiento o eliminación de residuos

peligrosos, así como residuos radiactivos;

V.- Aprovechamientos forestales en selvas tropicales y especies de difícil

regeneración;

VI. Se deroga.

VII.- Cambios de uso del suelo de áreas forestales, así como en selvas y
zonas áridas;
 VIII.- Parques industriales donde se prevea la realización de actividades
altamente riesgosas;

IX.- Desarrollos inmobiliarios que afecten los ecosistemas costeros;

X.- Obras y actividades en humedales, manglares, lagunas, ríos, lagos y

esteros conectados con el mar, así como en sus litorales o zonas
federales;

XI. Obras y actividades en áreas naturales protegidas de competencia de la

Federación;

XII.- Actividades pesqueras, acuícolas o agropecuarias que puedan poner

en peligro la preservación de una o más especies o causar daños a los
ecosistemas, y

XIII.- Obras o actividades que correspondan a asuntos de competencia

federal, que puedan causar desequilibrios ecológicos graves e
irreparables, daños a la salud pública o a los ecosistemas, o rebasar
los límites y condiciones establecidos en las disposiciones jurídicas
relativas a la preservación del equilibrio ecológico y la protección del
ambiente.
El Reglamento de la presente Ley determinará las obras o actividades a que se
refiere este artículo, que por su ubicación, dimensiones, características o
alcances no produzcan impactos ambientales significativos, no causen o puedan
causar desequilibrios ecológicos, ni rebasen los límites y condiciones
establecidos en las disposiciones jurídicas referidas a la preservación del
equilibrio ecológico y la protección al ambiente, y que por lo tanto no deban
sujetarse al procedimiento de evaluación de impacto ambiental previsto en este
ordenamiento.

Para los efectos a que se refiere la fracción XIII del presente artículo, la
Secretaría notificará a los interesados su determinación para que sometan al
procedimiento de evaluación de impacto ambiental la obra o actividad que
corresponda, explicando las razones que lo justifiquen, con el propósito de que
aquéllos presenten los informes, dictámenes y consideraciones que juzguen
convenientes, en un plazo no mayor a diez días. Una vez recibida la
documentación de los interesados, la Secretaría, en un plazo no mayor a treinta
días, les comunicará si procede o no la presentación de una manifestación de
impacto ambiental, así como la modalidad y el plazo para hacerlo. Transcurrido
el plazo señalado, sin que la Secretaría emita la comunicación correspondiente,
se entenderá que no es necesaria la presentación de una manifestación de
impacto ambiental.
ARTÍCULO 29.- Los efectos negativos que sobre el ambiente, los recursos
naturales, la flora y la fauna silvestre y demás recursos a que se refiere esta Ley,
pudieran causar las obras o actividades de competencia federal que no requieran
someterse al procedimiento de evaluación de impacto ambiental a que se refiere
la presente sección, estarán sujetas en lo conducente a las disposiciones de la
misma, sus reglamentos, las normas oficiales mexicanas en materia ambiental,
la legislación sobre recursos naturales que resulte aplicable, así como a través
de los permisos, licencias, autorizaciones y concesiones que conforme a dicha
normatividad se requiera.

ARTÍCULO 30.- Para obtener la autorización a que se refiere el artículo 28 de

esta Ley, los interesados deberán presentar a la Secretaría una manifestación
de impacto ambiental, la cual deberá contener, por lo menos, una descripción de
los posibles efectos en el o los ecosistemas que pudieran ser afectados por la
obra o actividad de que se trate, considerando el conjunto de los elementos que
conforman dichos ecosistemas, así como las medidas preventivas, de mitigación
y las demás necesarias para evitar y reducir al mínimo los efectos negativos
sobre el ambiente.
Cuando se trate de actividades consideradas altamente riesgosas en los
términos de la presente Ley, la manifestación deberá incluir el estudio de riesgo
correspondiente.

Si después de la presentación de una manifestación de impacto ambiental se

realizan modificaciones al proyecto de la obra o actividad respectiva, los
interesados deberán hacerlas del conocimiento de la Secretaría, a fin de que
ésta, en un plazo no mayor de 10 días les notifique si es necesaria la
presentación de información adicional para evaluar los efectos al ambiente, que
pudiesen ocasionar tales modificaciones, en términos de lo dispuesto en esta
Ley.

Los contenidos del informe preventivo, así como las características y las
modalidades de las manifestaciones de impacto ambiental y los estudios de
riesgo serán establecidos por el Reglamento de la presente Ley.

ARTÍCULO 31.- La realización de las obras y actividades a que se refieren las

fracciones I a XII del artículo 28, requerirán la presentación de un informe
preventivo y no una manifestación de impacto ambiental, cuando:

I.- Existan normas oficiales mexicanas u otras disposiciones que regulen las
emisiones, las descargas, el aprovechamiento de recursos naturales y,
en general, todos los impactos ambientales relevantes que puedan
producir las obras o actividades;
 II.- Las obras o actividades de que se trate estén expresamente previstas por
un plan parcial de desarrollo urbano o de ordenamiento ecológico que
haya sido evaluado por la Secretaría en los términos del artículo
siguiente, o

III.- Se trate de instalaciones ubicadas en parques industriales autorizados

en los términos de la presente sección.

En los casos anteriores, la Secretaría, una vez analizado el informe preventivo,

determinará, en un plazo no mayor de veinte días, si se requiere la presentación
de una manifestación de impacto ambiental en alguna de las modalidades
previstas en el reglamento de la presente Ley, o si se está en alguno de los
supuestos señalados.

La Secretaría publicará en su Gaceta Ecológica, el listado de los informes

preventivos que le sean presentados en los términos de este artículo, los cuales
estarán a disposición del público.

ARTÍCULO 32.- En el caso de que un plan o programa parcial de desarrollo

urbano o de ordenamiento ecológico del territorio incluyan obras o actividades
de las señaladas en el artículo 28 de esta Ley, las autoridades competentes de
los Estados, el Distrito Federal o los Municipios, deberán presentar dichos planes
o programas a la Secretaría, con el propósito de que ésta emita la autorización
que en materia de impacto ambiental corresponda, respecto del conjunto de
obras o actividades que se prevean realizar en un área determinada, en los
términos previstos en el artículo 31 de esta Ley.

ARTÍCULO 33.- Tratándose de las obras y actividades a que se refieren las

fracciones IV, VIII, IX y XI del artículo 28, la Secretaría notificará a los gobiernos
estatales y municipales o del Distrito Federal, según corresponda, que ha
recibido la manifestación de impacto ambiental respectiva, a fin de que éstos
manifiesten lo que a su derecho convenga.

La autorización que expida la Secretaría, no obligará en forma alguna a las

autoridades locales para expedir las autorizaciones que les corresponda en el
ámbito de sus respectivas competencias.
ARTÍCULO 34.- Una vez que la Secretaría reciba una manifestación de impacto
ambiental e integre el expediente a que se refiere el artículo 35, pondrá ésta a
disposición del público, con el fin de que pueda ser consultada por cualquier
persona.
Los promoventes de la obra o actividad podrán requerir que se mantenga en
reserva la información que haya sido integrada al expediente y que, de hacerse
pública, pudiera afectar derechos de propiedad industrial, y la confidencialidad
de la información comercial que aporte el interesado.

La Secretaría, a solicitud de cualquier persona de la comunidad de que se trate,

podrá llevar a cabo una consulta pública, conforme a las siguientes bases:

I.- La Secretaría publicará la solicitud de autorización en materia de impacto

ambiental en su Gaceta Ecológica. Asimismo, el promovente deberá
publicar a su costa, un extracto del proyecto de la obra o actividad en
un periódico de amplia circulación en la entidad federativa de que se
trate, dentro del plazo de cinco días contados a partir de la fecha en
que se presente la manifestación de impacto ambiental a la Secretaría;

II.- Cualquier ciudadano, dentro del plazo de diez días contados a partir de
la publicación del extracto del proyecto en los términos antes referidos,
podrá solicitar a la Secretaría ponga a disposición del público en la
entidad federativa que corresponda, la manifestación de impacto
ambiental;

III.- Cuando se trate de obras o actividades que puedan generar

desequilibrios ecológicos graves o daños a la salud pública o a los
ecosistemas, de conformidad con lo que señale el reglamento de la
presente Ley, la Secretaría, en coordinación con las autoridades
locales, podrá organizar una reunión pública de información en la que
el promovente explicará los aspectos técnicos ambientales de la obra
o actividad de que se trate;

IV.- Cualquier interesado, dentro del plazo de veinte días contados a partir
de que la Secretaría ponga a disposición del público la manifestación
de impacto ambiental en los términos de la fracción I, podrá proponer
el establecimiento de medidas de prevención y mitigación adicionales,
así como las observaciones que considere pertinentes, y

V.- La Secretaría agregará las observaciones realizadas por los interesados

al expediente respectivo y consignará, en la resolución que emita, el
proceso de consulta pública realizado y los resultados de las
observaciones y propuestas que por escrito se hayan formulado.

ARTÍCULO 35.- Una vez presentada la manifestación de impacto ambiental, la

Secretaría iniciará el procedimiento de evaluación, para lo cual revisará que la
solicitud se ajuste a las formalidades previstas en esta Ley, su Reglamento y las
normas oficiales mexicanas aplicables, e integrará el expediente respectivo en
un plazo no mayor de diez días.

Para la autorización de las obras y actividades a que se refiere el artículo 28, la

Secretaría se sujetará a lo que establezcan los ordenamientos antes señalados,
así como los programas de desarrollo urbano y de ordenamiento ecológico del
territorio, las declaratorias de áreas naturales protegidas y las demás
disposiciones jurídicas que resulten aplicables.

Asimismo, para la autorización a que se refiere este artículo, la Secretaría deberá

evaluar los posibles efectos de dichas obras o actividades en el o los
ecosistemas de que se trate, considerando el conjunto de elementos que los
conforman y no únicamente los recursos que, en su caso, serían sujetos de
aprovechamiento o afectación.
Una vez evaluada la manifestación de impacto ambiental, la Secretaría emitirá,
debidamente fundada y motivada, la resolución correspondiente en la que podrá:

I.- Autorizar la realización de la obra o actividad de que se trate, en los

términos solicitados;

II.- Autorizar de manera condicionada la obra o actividad de que se trate, a

la modificación del proyecto o al establecimiento de medidas
adicionales de prevención y mitigación, a fin de que se eviten, atenúen
o compensen los impactos ambientales adversos susceptibles de ser
producidos en la construcción, operación normal y en caso de
accidente. Cuando se trate de autorizaciones condicionadas, la
Secretaría señalará los requerimientos que deban observarse en la
realización de la obra o actividad prevista, o

III.- Negar la autorización solicitada, cuando:

A) Se contravenga lo establecido en esta Ley, sus reglamentos, las normas

oficiales mexicanas y demás disposiciones aplicables;

B) La obra o actividad de que se trate pueda propiciar que una o más

especies sean declaradas como amenazadas o en peligro de extinción
o cuando se afecte a una de dichas especies, o
 C) Exista falsedad en la información proporcionada por los promoventes,
respecto de los impactos ambientales de la obra o actividad de que se
trate.

La Secretaría podrá exigir el otorgamiento de seguros o garantías respecto del

cumplimiento de las condiciones establecidas en la autorización, en aquellos
casos expresamente señalados en el reglamento de la presente Ley, cuando
durante la realización de las obras puedan producirse daños graves a los
ecosistemas.

La resolución de la Secretaría sólo se referirá a los aspectos ambientales de las

obras y actividades de que se trate. Artículo reformado DOF 13-12-1996

ARTÍCULO 35 BIS.- La Secretaría dentro del plazo de sesenta días contados a

partir de la recepción de la manifestación de impacto ambiental deberá emitir la
resolución correspondiente.

La Secretaría podrá solicitar aclaraciones, rectificaciones o ampliaciones al

contenido de la manifestación de impacto ambiental que le sea presentada,
suspendiéndose el término que restare para concluir el procedimiento. En ningún
caso la suspensión podrá exceder el plazo de sesenta días, contados a partir de
que ésta sea declarada por la Secretaría, y siempre y cuando le sea entregada
la información requerida.

Excepcionalmente, cuando por la complejidad y las dimensiones de una obra o

actividad la Secretaría requiera de un plazo mayor para su evaluación, éste se
podrá ampliar hasta por sesenta días adicionales, siempre que se justifique
conforme a lo dispuesto en el reglamento de la presente Ley. Artículo adicionado
DOF 13-12-1996

ARTÍCULO 35 BIS 1.- Las personas que presten servicios de impacto ambiental,
serán responsables ante la Secretaría de los informes preventivos,
manifestaciones de impacto ambiental y estudios de riesgo que elaboren,
quienes declararán bajo protesta de decir verdad que en ellos se incorporan las
mejores técnicas y metodologías existentes, así como la información y medidas
de prevención y mitigación más efectivas.
Asimismo, los informes preventivos, las manifestaciones de impacto ambiental y
los estudios de riesgo podrán ser presentados por los interesados, instituciones
de investigación, colegios o asociaciones profesionales, en este caso la
responsabilidad respecto del contenido del documento corresponderá a quien lo
suscriba.
ARTÍCULO 35 BIS 2.- El impacto ambiental que pudiesen ocasionar las obras o
actividades no comprendidas en el artículo 28 será evaluado por las autoridades
del Distrito Federal o de los Estados, con la participación de los municipios
respectivos, cuando por su ubicación, dimensiones o características produzcan
impactos ambientales significativos sobre el medio ambiente, y estén
expresamente señalados en la legislación ambiental estatal. En estos casos, la
evaluación de impacto ambiental se podrá efectuar dentro de los procedimientos
de autorización de uso del suelo, construcciones, fraccionamientos, u otros que
establezcan las leyes estatales y las disposiciones que de ella se deriven. Dichos
ordenamientos proveerán lo necesario a fin de hacer compatibles la política
ambiental con la de desarrollo urbano y de evitar la duplicidad innecesaria de
procedimientos administrativos en la materia.
ARTÍCULO 35 BIS 3.- Cuando las obras o actividades señaladas en el artículo
28 de esta Ley requieran, además de la autorización en materia de impacto
ambiental, contar con autorización de inicio de obra; se deberá verificar que el
responsable cuente con la autorización de impacto ambiental expedida en
términos de lo dispuesto en este ordenamiento.

Asimismo, la Secretaría, a solicitud del promovente, integrará a la autorización

en materia de impacto ambiental, los demás permisos, licencias y autorizaciones
de su competencia, que se requieran para la realización de las obras y
actividades a que se refiere este artículo.
 SECCIÓN V, CAPITULO IV, TITULO SEGUNDO
DEL REGLAMENTO DE OBRAS PUBLICAS Y
SERVICIOS RELACIONADOS CON LAS
MISMAS.
 SECCIÓN VI, CAPITULO IV, TITULO SEGUNDO
DEL REGLAMENTO DE OBRAS PUBLICAS Y
SERVICIOS RELACIONADOS CON LAS
MISMAS.
 SECCIÓN VII, CAPITULO IV, TITULO SEGUNDO
DEL REGLAMENTO DE OBRAS PUBLICAS Y
SERVICIOS RELACIONADOS CON LAS
MISMAS.
 SECCIÓN VIII, CAPITULO IV, TITULO
SEGUNDO DEL REGLAMENTO DE OBRAS
PUBLICAS Y SERVICIOS RELACIONADOS CON
LAS MISMAS.
 SECCIÓN IX, CAPITULO IV, TITULO SEGUNDO
DEL REGLAMENTO DE OBRAS PUBLICAS Y
SERVICIOS RELACIONADOS CON LAS
MISMAS.
Tarea 8.
Subtema 5.5 Confección de planos según lo construido
Subtema 5.7 Recepción de obra

REGLAMENTO DE LA LEY DE OBRAS PÚBLICAS Y SERVICIOS

RELACIONADOS CON LAS MISMAS

SECCIÓN V
DE LA SUSPENSIÓN DE OBRA

Artículo 144.- Cuando ocurra la suspensión de los trabajos, el servidor público

designado por la dependencia o entidad lo notificará al contratista señalando las
causas que la motivan, la fecha de su inicio y de la probable reanudación de los
trabajos, así como las acciones que debe considerar en lo relativo a su personal,
maquinaria y equipo de construcción.
La fecha de terminación de los trabajos se prorrogará en igual proporción al
periodo que comprenda la suspensión de los mismos, sin modificar el plazo de
ejecución convenido. Lo anterior se formalizará mediante el acta circunstanciada
de suspensión.
El suministro deficiente del proveedor de materiales y equipos de instalación
permanente no será motivo de suspensión de los trabajos cuando dicho
suministro sea responsabilidad del contratista.
Artículo 145.- El contratista podrá solicitar, a partir de la determinación de la
suspensión de los trabajos, el pago de los gastos no recuperables a que hace
referencia la fracción I del artículo 62 de la Ley y que se generen durante la
suspensión. La solicitud del contratista deberá presentarse en las fechas de corte
para el pago de estimaciones estipuladas en el contrato.
Artículo 146.- Tratándose de suspensión de trabajos, el pago de gastos no
recuperables a que se refiere la fracción I del artículo 62 de la Ley se limitará a
lo siguiente:
I. A las rentas de equipo o, si resulta más barato, a los fletes del retiro y
regreso del mismo al sitio de los trabajos;
II. A la mano de obra programada que permanezca en el sitio de los
trabajos durante el periodo de la suspensión que no haya sido
trasladada a otro frente de trabajo o a otra obra y que se encuentre
registrada en la Bitácora o en el documento de control de asistencia
que definan las partes;
III. Al monto correspondiente a los costos indirectos que se hayan
generado durante el periodo de suspensión.
Los costos indirectos que se considerarán son los previstos en el
artículo 213 del presente Reglamento, con independencia de la
condición de pago establecida en el contrato de que se trate, y
 IV. El costo por mantenimiento, conservación y almacenamiento cuando
no impliquen un costo indirecto.
Para la determinación de los gastos a que se refiere este artículo se
deberán considerar como elementos razonables para su cálculo los
programas y costos originalmente propuestos por el contratista,
debiéndose ajustar con el último porcentaje de ajuste de costos
autorizado antes de la suspensión. En el caso de los contratos
celebrados bajo la condición de pago a precio alzado, el contratista
podrá tomar como referencia los conceptos que se señalan en el
Capítulo Sexto del Título Segundo del presente Reglamento, para
acreditar los gastos no recuperables en que haya incurrido.
Artículo 147.- En todos los casos de suspensión de los trabajos la dependencia
o entidad deberá levantar un acta circunstanciada en la que hará constar como
mínimo lo siguiente:
I. El lugar, fecha y hora en que se levanta el acta;
II. El nombre y firma del residente y del superintendente, así como del
servidor público autorizado para ordenar la suspensión en los términos
del artículo 60 de la Ley;
III. Los datos de identificación de los trabajos que se suspenderán. Si la
suspensión es parcial sólo se identificará la parte correspondiente y las
medidas que habrán de tomarse para su reanudación;
IV. Las razones o las causas justificadas que dieron origen a la
suspensión;
V. Una relación pormenorizada de la situación legal, administrativa,
técnica y económica en la que se encuentren los trabajos o la parte que
se vaya a suspender, debiendo hacer constancia del personal y equipo
que se retira y del que se autoriza su permanencia, de acuerdo con el
programa de ejecución convenido;
VI. El tiempo de duración de la suspensión. Cuando la reanudación de los
trabajos esté ligada a un hecho o acto de realización cierta pero de
fecha indeterminada el periodo de la suspensión estará sujeto a la
actualización de ese evento, sin perjuicio de que se pueda optar por la
terminación anticipada;
VII. Las acciones que seguirá la dependencia o entidad, las que deberán
asegurar los bienes y el estado de los trabajos, así como procurar la
conclusión de los mismos;
VIII. El programa de ejecución convenido que se aplicará, el cual deberá
considerar los diferimientos que origina la suspensión, ajustando sin
modificar los periodos y procesos de construcción indicados en el
programa de ejecución convenido en el contrato, y
IX. En su caso, las medidas de protección que resulten necesarias para
salvaguardar los trabajos realizados, el lugar de trabajo, sus
instalaciones y equipos.
Artículo 148.- Si durante la vigencia del contrato existen suspensiones de los
trabajos cuyos periodos sean reducidos y difíciles de cuantificar, las partes
podrán acordar que los periodos sean agrupados y formalizados mediante la
suscripción de una sola acta circunstanciada.
Artículo 149.- Cuando las suspensiones se deriven de un caso fortuito o fuerza
mayor no existirá responsabilidad alguna para las partes, debiendo únicamente
suscribir un convenio donde se reconozca el plazo de la suspensión y las fechas
de reinicio y terminación de los trabajos, sin modificar el plazo de ejecución
establecido en el contrato. En caso de que los trabajos se dañen o se destruyan
y requieran ser rehabilitados o repuestos, éstos deberán pagarse mediante la
celebración de un convenio en los términos del artículo 59 de la Ley, siempre
que no se trate de deficiencias o incumplimientos anteriores imputables al
contratista.
Cuando las suspensiones se deriven de un caso fortuito o fuerza mayor sólo será
procedente el pago de gastos no recuperables por los conceptos siguientes:
I. La plantilla de veladores y personal de conservación y vigilancia de las
instalaciones y obras, asignados durante la suspensión;
II. Los costos de administración de obra en cuanto a honorarios, sueldos
y prestaciones del personal técnico y administrativo estrictamente
necesario y que tenga una función específica durante la suspensión, y
III. La mano de obra programada que permanezca en el sitio de los
trabajos durante el periodo de la suspensión, que no haya sido
trasladada a otro frente de trabajo o a otra obra y que se encuentre
registrada en la Bitácora o en el documento de control de asistencia
que definan las partes.

SECCIÓN VI
DE LA TERMINACIÓN ANTICIPADA DEL CONTRATO

Artículo 150.- La terminación anticipada de los contratos procederá sólo en los

casos expresamente señalados en el artículo 60 de la Ley, por lo que no podrá
celebrarse ningún acuerdo entre las partes para tal efecto.
Artículo 151.- En todos los casos de terminación anticipada de los contratos se
deberán realizar las anotaciones correspondientes en la Bitácora, debiendo la
dependencia o entidad levantar un acta circunstanciada en la cual se hará
constar como mínimo lo siguiente:
I. Lugar, fecha y hora en que se levanta;
II. Nombre y firma del residente y del superintendente;
III. Descripción de los trabajos cuyo contrato se termine anticipadamente;
IV. Importe contractual;
V. Relación de las estimaciones o de gastos aprobados hasta antes de
que se hubiera definido la terminación anticipada;
VI. Descripción pormenorizada del estado que guardan los trabajos;
VII. Periodo de ejecución de los trabajos, precisando la fecha de inicio y
terminación contractual y el plazo durante el cual se ejecutaron los
trabajos;
VIII. Razones o causas justificadas que dieron origen a la terminación
anticipada, así como una relación pormenorizada de la situación legal,
administrativa, técnica y económica en la que se encuentre el contrato
que se vaya a terminar anticipadamente;
IX. Acciones tendientes a asegurar los bienes y el estado que guardan los
trabajos, y
 X. Periodo en el cual se determinará el finiquito de los trabajos y el importe
al que ascenderán los gastos no recuperables.
Artículo 152.- Tratándose de una terminación anticipada los gastos no
recuperables serán los siguientes:
I. Los gastos no amortizados por concepto de:
A) La construcción de oficinas, almacenes, bodegas, campamentos e
instalaciones en el sitio de los trabajos. Al ser liquidados estos gastos,
las construcciones serán propiedad de la Federación o de la entidad,
según se trate;
B) La renta de oficinas, almacenes, bodegas, campamentos e instalaciones
por el contratista, con el objeto de atender directamente las
necesidades de la obra;
C) La instalación, el montaje o retiro de plantas de construcción o talleres, y
D) La parte proporcional del costo de transporte de ida y vuelta de la
maquinaria o equipo de construcción y de plantas y elementos para
instalaciones de acuerdo con el programa de utilización, y la expedición
de la garantía de cumplimiento del contrato;
II. El importe de los materiales y equipos de instalación permanente
adquiridos por el contratista y que se encuentren en el sitio de los
trabajos, camino a éste o terminados o habilitados en los talleres o
fábricas correspondientes, siempre que cumplan con las
especificaciones de calidad y que la cuantía sea acorde con los trabajos
pendientes de ejecutar según los programas convenidos, y
III. La liquidación del personal obrero y administrativo directamente
adscrito a la obra, siempre y cuando no sean empleados permanentes
del contratista.
Artículo 153.- Para la elaboración del finiquito de los trabajos que se derive de
la terminación anticipada del contrato deberán observarse las reglas que se
establecen en la Sección IX de este Capítulo.

SECCIÓN VII
DE LA RESCISIÓN ADMINISTRATIVA DEL CONTRATO

Artículo 154.- La rescisión administrativa de los contratos deberá ser el último

medio que utilicen las dependencias y entidades, ya que en todos los casos, de
manera previa, deberán promover la ejecución total de los trabajos y el menor
retraso posible.
Las dependencias y entidades optarán por aplicar retenciones o penas
convencionales antes de iniciar el procedimiento de rescisión cuando el
incumplimiento del contrato derive del atraso en la ejecución de los trabajos.
Las dependencias y entidades, en lugar de iniciar la rescisión respectiva del
contrato, podrán efectuar modificaciones al mismo a fin de reprogramar la
ejecución de los trabajos, siempre y cuando no impliquen variaciones
sustanciales al proyecto original, ni se celebren para eludir en cualquier forma el
cumplimiento de la Ley o los Tratados, para que se concluya la obra o servicio
contratado por resultar más conveniente para el Estado que la rescisión del
contrato, lo cual se deberá acreditar mediante las constancias correspondientes,
mismas que se integrarán al expediente respectivo. Lo anterior, sin perjuicio de
la aplicación de las penas convencionales por atraso que, en su caso, resulten
procedentes.
Artículo 155.- Sin perjuicio de lo previsto en el artículo anterior, la dependencia
o entidad podrá iniciar en cualquier momento el procedimiento de rescisión
previsto en el artículo 61 de la Ley, motivando la rescisión en alguna de las
causales previstas en el artículo 157 de este Reglamento. Si es el contratista
quien decide rescindir el contrato será necesario que acuda ante la autoridad
judicial federal y obtenga la declaración correspondiente.
Artículo 156.- Cuando se obtenga la resolución judicial que determine la
rescisión del contrato por incumplimiento de alguna de las obligaciones
imputable a la dependencia o entidad, se estará a lo que resuelva la autoridad
judicial.
Artículo 157.- Las dependencias y entidades, sin perjuicio de lo dispuesto por el
artículo 154 de este Reglamento, rescindirán administrativamente el contrato
cuando el contratista:
I. Por causas imputables a él, no inicie los trabajos objeto del contrato
dentro de los quince días siguientes a la fecha convenida sin causa
justificada conforme a la Ley y este Reglamento;
II. Interrumpa injustificadamente la ejecución de los trabajos o se niegue
a reparar o reponer alguna parte de ellos que se haya detectado como
defectuosa por la dependencia o entidad;
III. No ejecute los trabajos de conformidad con lo estipulado en el contrato
o sin motivo justificado no acate las órdenes dadas por el residente;
IV. No dé cumplimiento a los programas de ejecución convenidos por falta
de materiales, trabajadores o equipo de construcción y, a juicio de la
dependencia o entidad, el atraso pueda dificultar la terminación
satisfactoria de los trabajos en el plazo estipulado.
No implicará retraso en el programa de ejecución convenido y, por tanto, no
se considerará como incumplimiento del contrato y causa de su
rescisión, cuando el atraso tenga lugar por la falta de pago de
estimaciones o la falta de información referente a planos,
especificaciones o normas de calidad, de entrega física de las áreas de
trabajo y de entrega oportuna de materiales y equipos de instalación
permanente, de licencias y permisos que deba proporcionar o
suministrar la contratante, así como cuando la dependencia o entidad
haya ordenado la suspensión de los trabajos;
V. Sea declarado en concurso mercantil o alguna figura análoga;
VI. Subcontrate partes de los trabajos objeto del contrato sin contar con la
autorización por escrito de la dependencia o entidad;
VII. Transfiera los derechos de cobro derivados del contrato sin contar con
la autorización por escrito de la dependencia o entidad;
 VIII. No dé a la dependencia o entidad y a las dependencias que tengan
facultad de intervenir, las facilidades y datos necesarios para la
inspección, vigilancia y supervisión de los materiales y trabajos;
IX. Cambie su nacionalidad por otra, en el caso de que haya sido
establecido como requisito tener una determinada nacionalidad;
X. Si siendo extranjero, invoque la protección de su gobierno en relación
con el contrato;
XI. Incumpla con el compromiso que, en su caso, haya adquirido al
momento de la suscripción del contrato, relativo a la reserva y
confidencialidad de la información o documentación proporcionada por
la dependencia o entidad para la ejecución de los trabajos, y
XII. En general, incumpla cualquiera de las obligaciones derivadas del
contrato. Las dependencias y entidades, atendiendo a las
características, magnitud y complejidad de los trabajos, podrán
establecer en los contratos otras causas de rescisión.
Artículo 158.- En la notificación que las dependencias y entidades realicen al
contratista respecto del inicio del procedimiento de rescisión del contrato, se
señalarán los hechos que motivaron la determinación de darlo por rescindido
relacionándolos con las estipulaciones específicas que se consideren han sido
incumplidas.
Artículo 159.- El acta circunstanciada de la rescisión a que hace referencia el
segundo párrafo del artículo 62 de la Ley deberá contener como mínimo lo
siguiente:
I. Lugar, fecha y hora en que se levanta;
II. Nombre y firma del residente y, en su caso, del supervisor y del
superintendente;
III. Descripción de los trabajos y de los datos que se consideren relevantes
del contrato que se pretende rescindir;
IV. Importe contractual considerando, en su caso, los convenios de
modificación;
V. Descripción breve de los motivos que dieron origen al procedimiento de
rescisión, así como de las estipulaciones en las que el contratista
incurrió en incumplimiento del contrato;
VI. Relación de las estimaciones o de gastos aprobados con anterioridad
al inicio del procedimiento de rescisión, así como de aquéllos
pendientes de autorización;
VII. Descripción pormenorizada del estado que guardan los trabajos;
VIII. Periodo de ejecución de los trabajos, precisando la fecha de inicio y
terminación contractual y el plazo durante el cual se ejecutaron los
trabajos;
IX. Relación pormenorizada de la situación legal, administrativa, técnica y
económica en la que se encuentran los trabajos realizados y los
pendientes por ejecutar, y
X. Constancia de que el contratista entregó toda la documentación
necesaria para que la dependencia o entidad pueda hacerse cargo y,
en su caso, continuar con los trabajos.
La determinación de dar por rescindido administrativamente el contrato
no podrá ser revocada o modificada por la dependencia o entidad.
 En el caso de que en el procedimiento de rescisión se determine no
rescindir el contrato, se reprogramarán los trabajos una vez notificada
la resolución correspondiente.
Artículo 160.- Las dependencias y entidades junto con el contratista podrán
conciliar, dentro del finiquito de los trabajos, los saldos derivados de la rescisión
con el fin de preservar los intereses de las partes.
Artículo 161.- Las dependencias y entidades podrán hacer constar en el finiquito
de los trabajos, la recepción de los trabajos realizados por el contratista hasta la
rescisión del contrato, así como de los equipos y materiales que se hubieran
instalado en la obra o utilizados en la prestación del servicio o se encuentren en
proceso de fabricación, siempre y cuando sean susceptibles de utilización dentro
de los trabajos pendientes de realizar, debiendo en todo caso ajustarse a lo
siguiente:
I. Sólo podrá reconocerse el pago de aquellos materiales y equipos que
cumplan con las especificaciones particulares de construcción, normas
de calidad y hasta por la cantidad requerida para la realización de los
trabajos pendientes de ejecutar, de acuerdo con el programa de
ejecución convenido vigente, a la fecha de rescisión del contrato;
II. El reconocimiento de los materiales y equipos de instalación
permanente se realizará invariablemente a los precios estipulados en
los análisis de precios del contrato o, en su caso, a los precios de
mercado. Los precios del contrato se afectarán con los ajustes de
costos que procedan sin considerar ningún cargo adicional por costos
indirectos, financiamiento, fletes, almacenajes y seguros;
III. Se deberán reconocer al contratista los anticipos amortizados, así
como los pagos que a cuenta de materiales y fabricación de equipos
realizó el contratista al fabricante o proveedor de los mismos, siempre
y cuando éste se comprometa a entregarlos, previo el pago de la
diferencia a su favor, y
IV. En el caso de que existan fabricantes o proveedores que tengan la
posesión o propiedad de los equipos y materiales que necesiten las
dependencias y entidades para la continuación de los trabajos, éstas
podrán, bajo su responsabilidad, subrogarse en los derechos que tenga
el contratista, debiendo seguir los criterios señalados en las fracciones
anteriores.
Artículo 162.- El sobrecosto a que se refiere la fracción II del artículo 62 de la
Ley es la diferencia entre el importe que le representaría a la dependencia o
entidad concluir con otro contratista los trabajos pendientes y el costo de los
trabajos no ejecutados al momento de rescindir el contrato.
Artículo 163.- Para la determinación del sobrecosto a que se refiere la fracción
II del artículo 62 de la Ley y su importe, las dependencias y entidades procederán
conforme a lo siguiente:
I. Cuando la dependencia o entidad rescinda un contrato y exista una
proposición solvente que permita adjudicar el contrato al licitante que
la haya presentado en los términos que señala la fracción VI del artículo
42 de la Ley, el sobrecosto será la diferencia entre el precio de dicha
 proposición y el importe de los trabajos no ejecutados conforme al
programa vigente, aplicando los ajustes de costos que procedan, y
II. Cuando una proposición no sea solvente en los términos señalados en
la fracción anterior, la determinación del sobrecosto deberá reflejar el
impacto inflacionario en el costo de los trabajos no ejecutados conforme
al programa vigente hasta el momento en que se notifique la rescisión,
calculado conforme al procedimiento de ajustes de costos pactado en
el contrato, debiendo agregarse un importe equivalente al diez por
ciento de los trabajos pendientes de ejecutar.

SECCIÓN VIII
DE LA RECEPCIÓN DE LOS TRABAJOS

Artículo 164.- Para iniciar el procedimiento de recepción de los trabajos, el

contratista deberá notificar la terminación de los trabajos a través de la Bitácora
o excepcionalmente por escrito, para lo cual anexará los documentos que lo
soporten e incluirá una relación de las estimaciones o de los gastos aprobados,
monto ejercido y créditos a favor o en contra.
Las dependencias y entidades, dentro de un plazo no mayor a quince días
naturales a partir del día siguiente a aquél en que reciban la notificación a que
se refiere el párrafo anterior, iniciarán el procedimiento de recepción de los
trabajos.
Artículo 165.- Si la dependencia o entidad encuentra deficiencias en la
terminación de los trabajos durante la verificación que para tal efecto se realice,
deberá solicitar al contratista la reparación que corresponda conforme a las
condiciones requeridas en el contrato.
En el supuesto previsto en el párrafo que antecede, el plazo de verificación de
los trabajos pactado en el contrato se podrá prorrogar por el periodo que
acuerden las partes para la reparación de las deficiencias; en este periodo, no
se aplicarán penas convencionales. Lo anterior, sin perjuicio de que la
dependencia o entidad opte por la rescisión del contrato.
Las reparaciones de las deficiencias a que alude este artículo no podrán consistir
en la ejecución total de conceptos de trabajo pendiente de realizar. En este caso,
no se procederá a la recepción y se considerará que los trabajos no fueron
concluidos en el plazo convenido.
Artículo 166.- En la fecha señalada, la dependencia o entidad recibirá
físicamente los trabajos y levantará el acta correspondiente, la que contendrá
como mínimo lo siguiente:
I. Lugar, fecha y hora en que se levante;
II. Nombre y firma del residente y del supervisor de los trabajos por parte
de la dependencia o entidad y del superintendente por parte del
contratista;
III. Descripción de los trabajos que se reciben;
IV. Importe contractual, incluyendo el de los convenios modificatorios;
 V. Periodo de ejecución de los trabajos, precisando las fechas de inicio y
terminación contractual y el plazo en que realmente se ejecutaron,
incluyendo los convenios modificatorios;
VI. Relación de las estimaciones o de gastos aprobados a la fecha, así
como los pendientes de autorización;
VII. Declaración de las partes de que se entregan los planos
correspondientes a la construcción final, así como los manuales e
instructivos de operación y mantenimiento correspondientes y los
certificados de garantía de calidad y funcionamiento de los bienes
instalados y
VIII. Constancia de que el contratista entregó a la residencia o a la
supervisión los documentos derivados de la realización de los trabajos.
En el acto de entrega física de los trabajos el contratista exhibirá la
garantía prevista en el artículo 66 de la Ley.
Artículo 167.- Las dependencias y entidades podrán efectuar recepciones
parciales de los trabajos cuando sin estar éstos concluidos, a juicio de la
dependencia o entidad, existan trabajos terminados, identificables y susceptibles
de utilizarse y conservarse, debiendo levantar el acta circunstanciada
correspondiente, la cual contendrá en lo procedente lo previsto en el artículo
anterior.

SECCIÓN IX
DEL FINIQUITO Y TERMINACIÓN DEL CONTRATO

Artículo 168.- Para dar por terminados, parcial o totalmente, los derechos y
obligaciones asumidos por las partes en un contrato, éstas deberán elaborar el
finiquito de los trabajos correspondiente, salvo en los supuestos a que se refiere
el tercer párrafo del artículo 64 de la Ley. Deberá anexarse al finiquito el acta de
recepción física de los trabajos.
Una vez elaborado el finiquito de los trabajos, únicamente quedarán subsistentes
las acciones que deriven del mismo, así como la garantía que se contempla en
el artículo 66 de la Ley, por lo que no procederá reclamación alguna de pago
formulada por el contratista con posterioridad a la formalización del finiquito o,
en su caso, vencido el plazo señalado en el tercer párrafo del artículo 64 de la
Ley.
Artículo 169.- La dependencia o entidad deberá notificar al contratista, a través
de su representante legal o del superintendente, la fecha, lugar y hora en que se
llevará a cabo el finiquito de los trabajos.
Artículo 170.- El documento donde conste el finiquito de los trabajos formará
parte del contrato y deberá contener como mínimo lo siguiente:
I. Lugar, fecha y hora en que se realice;
II. Nombre y firma del residente y, en su caso, del supervisor de los
trabajos por parte de la dependencia o entidad y del superintendente
por parte del contratista;
 III. Descripción de los trabajos y de los datos que se consideren relevantes
del contrato correspondiente;
IV. Importe contractual y real del contrato, el cual deberá incluir los
volúmenes realmente ejecutados de acuerdo al contrato y a los
convenios celebrados;
V. Periodo de ejecución de los trabajos, precisando la fecha de inicio y
terminación contractual y el plazo en que realmente se ejecutaron,
incluyendo los convenios;
VI. Relación de las estimaciones, indicando cómo se ejecutaron los
conceptos de trabajo en cada una de ellas y los gastos aprobados,
debiendo describir los créditos a favor y en contra de cada una de las
partes, señalando los conceptos generales que les dieron origen y su
saldo resultante, así como la fecha, lugar y hora en que serán
liquidados;
VII. Las razones que justifiquen la aplicación de penas convencionales o
del sobrecosto;
VIII. Datos de la estimación final;
IX. Constancia de entrega de la garantía por defectos y vicios ocultos de
los trabajos y cualquier otra responsabilidad en que haya incurrido el
contratista, y
X. La declaración, en su caso, de que el contratista extiende el más amplio
finiquito que en derecho proceda, renunciando a cualquier acción legal
que tenga por objeto reclamar cualquier pago relacionado con el
contrato.
Cuando la liquidación de los saldos se realice dentro de los quince días naturales
siguientes a la firma del finiquito de los trabajos, el documento a que se refiere
este artículo podrá utilizarse como el acta administrativa que extingue los
derechos y obligaciones de las partes en el contrato, debiendo agregar
únicamente una manifestación de las partes de que no existen otros adeudos,
por lo que se dan por terminados los derechos y obligaciones que genera el
contrato respectivo, sin derecho a ulterior reclamación. Si no es factible el pago
en el término indicado, se procederá a elaborar el acta administrativa prevista en
el último párrafo del artículo 64 de la Ley.
Artículo 171.- Si del finiquito de los trabajos resulta que existen saldos a favor
del contratista, la dependencia o entidad deberá liquidarlos dentro del plazo a
que alude el segundo párrafo del artículo 54 de la Ley.
Si del finiquito de los trabajos resulta que existen saldos a favor de la
dependencia o entidad, el importe de los mismos se deducirá de las cantidades
pendientes por cubrir por concepto de trabajos ejecutados y si ello no fuera
suficiente, deberá exigirse su reintegro conforme a lo previsto por el artículo 55
de la Ley. En caso de no obtenerse el reintegro, la dependencia o entidad podrá
hacer efectivas las garantías que se encuentren vigentes.
Artículo 172.- El acta administrativa que da por extinguidos los derechos y
obligaciones formará parte del contrato y deberá contener como mínimo lo
siguiente:
I. Lugar, fecha y hora en que se levante;
II. Nombre de los asistentes y el carácter con que intervienen en el acto;
III. Descripción de los trabajos y de los datos que se consideren relevantes
del contrato correspondiente;
IV. Relación de obligaciones y la forma y fecha en que se cumplieron, y
V. Manifestación de las partes de que no existen adeudos y, por lo tanto,
de que se dan por terminadas las obligaciones que generó el contrato
respectivo, sin derecho a ulterior reclamación, por lo que se podrán
cancelar las garantías correspondientes.