CAPÍTULO 12

Auditoría de proyectos

En el capítulo anterior, discutimos el poscontrol. El poscontrol no puede cambiar el pasado, pero intenta
capturar la esencia de los éxitos y fracasos de los proyectos para que los proyectos futuros puedan
beneficiarse de las experiencias pasadas.PMBOK se refiere a esto como “lecciones aprendidas”, un tema que
PMBOK
se aborda en el Capítulo 8 sobre Calidad. Beneficiarse de las experiencias pasadas implica que uno las
comprende, y la comprensión requiere una evaluación. Pero la evaluación de proyectos no se limita al 8.3.3.8
análisis posterior a los hechos. Si bien el proyecto en su conjunto se evalúa cuando se ha completado (la base
para los controles posteriores), la evaluación del proyecto debe realizarse en varios puntos durante el ciclo de
vida, por ejemplo, en las puertas de las fases principales, y especialmente si hay una crisis o problema mayor
en el proyecto.
Un vehículo particularmente útil para la evaluación (pero de ninguna manera el único) es el
auditoría de proyectos, una indagación más o menos formal sobre cualquier aspecto del proyecto. Asociamos la
palabraauditoría con un examen detallado de los asuntos financieros, pero una auditoría de proyecto es muy flexible
y puede centrarse en cualquier asunto que desee la alta dirección. Debido a que los proyectos que una organización
inicia respaldan su estrategia, que a su vez respalda su competitividad general, determinar de manera proactiva
cómo se está desempeñando un proyecto a través de auditorías periódicas del proyecto proporciona información
oportuna sobre el proyecto que se puede aprovechar para aumentar aún más las probabilidades de éxito finalización
del proyecto. Por lo tanto, desde una perspectiva estratégica, las auditorías de proyectos desempeñan un papel
importante al ayudar a garantizar el éxito del proyecto, que posteriormente se traduce en un mayor éxito competitivo.

Tenga en cuenta que también existen otros tipos de auditorías como auditorías éticas, que
puede ser útil cuando se emplea la gestión de proyectos en una organización. Por ejemplo, como
Schaefer et al. (1998, p. 40) nota, “La ética no es una cuestión de bien o mal; es un proceso mediante
el cual una organización evalúa las decisiones ”, ¡un proceso que sin duda es relevante para la gestión
de proyectos! Y además de las auditorías de proyectos, también hay otros tipos de evaluaciones de
proyectos, comocríticas1; ver también Sangameswaran (1995) para más detalles.
El termino evaluar significa fijar el valor o tasar. La evaluación de proyectos evalúa el progreso y
el desempeño de un proyecto en comparación con el progreso y el desempeño planificados de ese
proyecto, o en comparación con el progreso y el desempeño de otros proyectos similares. La
comparación se realiza midiendo el proyecto frente a varios tipos diferentes de estándares. La
evaluación también respalda las decisiones de gestión necesarias para el proyecto. Por lo tanto, la
evaluación debe realizarse y presentarse de una manera y formato que aseguren a la gerencia que se
han considerado todos los datos pertinentes. La evaluación de un proyecto debe tener credibilidad a
los ojos del grupo de gestión para quien se realiza y también a los ojos del equipo de proyecto en el
que se realiza. En consecuencia, la evaluación del proyecto debe ser construida y controlada con el
mismo cuidado que el proyecto mismo.
En este capítulo, describimos la auditoría / revisión / evaluación del proyecto, sus diversas formas y
propósitos, y algunos problemas típicos encontrados al realizar una auditoría / evaluación.

1 La lectura "Una evaluación de las revisiones posteriores al proyecto" al final de este capítulo examina cuatro de estas

evaluaciones y resume los pros y los contras de realizar dichas evaluaciones. 459
460 CAPÍTULO 12 Auditoría de proyectos

12,1 Propósitos de la evaluación: metas

del sistema
Ciertamente, el elemento principal en la evaluación de un proyecto es su "éxito". En un estudio de una
variedad de diferentes tipos y tamaños de proyectos industriales (Shenhar et al., 1997), 127 gerentes
de proyectos (PM) identificaron 13 factores que constituyen cuatro dimensiones independientes del
éxito del proyecto, desde su perspectiva como PM. La primera y más sencilla dimensión es la del
proyecto.eficiencia en cumplir tanto con el presupuesto como con el cronograma. Este ha sido el
enfoque principal de nuestra discusión sobre gestión y control de proyectos hasta ahora, cumpliendo
los objetivos de tiempo, costo y alcance del proyecto. La segunda y más compleja dimensión es la de
impacto / satisfacción del financiador. Esta dimensión incluye el cumplimiento de las especificaciones
técnicas y operativas del proyecto, pero también incluye factores relacionados con la lealtad y la
recompra: satisfacción de las necesidades del financiador, uso real por parte del cliente, resolución de
un problema operativo importante del financiador y el desafío perenne del financiador. satisfacción.

La tercera dimensión es negocio / éxito directo, medido aquí principalmente en términos de nivel de
éxito comercial y participación de mercado. Sin embargo, para los proyectos internos, los factores pueden
incluir medidas como los rendimientos, los tiempos de ciclo, los pasos de procesamiento y la calidad. La
última dimensión, algo más difícil y nebulosa de determinar, espotencial futuro. Esto incluye factores
relacionados con la apertura de un nuevo mercado, el desarrollo de una nueva línea de productos o servicios
o, si se trata de un proyecto interno, el desarrollo de una nueva tecnología, habilidades o competencias. A
continuación, señalaremos algunas dimensiones adicionales para evaluar proyectos que van más allá de las
discutidas por Shenhar et al. (1997).
Más allá de las consideraciones sencillas del éxito del proyecto, otro propósito principal de la
evaluación es ayudar a traducir el logro de las metas del proyecto en una contribución a las metas de
la organización matriz. Para ello, se estudian todas las facetas del proyecto con el fin de identificar y
comprender las fortalezas y debilidades del proyecto. Es el equivalente a una aplicación de Six Sigma
o TQM a la gestión de proyectos. El resultado es un conjunto de recomendaciones de mejoras que
pueden ayudar tanto a los proyectos en curso como a los futuros a:

• Identificar problemas antes

• Aclarar las relaciones de alcance, costo y tiempo
• Mejorar el desempeño del proyecto
• Localizar oportunidades para futuros avances tecnológicos
• Evaluar la calidad de la gestión de proyectos
• Reducir costos
• Mejorar el proceso de identificación y gestión de riesgos
• Acelerar la consecución de resultados
• Identifique errores, corríjalos y evítelos en el futuro
• Brindar información al cliente
• Reconfirmar el interés y el compromiso de la organización con el proyecto.

En aras de la brevedad, nos referiremos a los objetivos declarados del proyecto, incluida la satisfacción
del financiador, como las "metas directas" del proyecto. Sin embargo, ignoran muchos costos y beneficios
para el proyecto, para sus miembros del equipo y para la organización matriz que no están claramente
establecidos como objetivos, como la lista anterior de mejoras del proyecto. La evaluación a menudo hace
recomendaciones que se relacionan con estas contribuciones auxiliares, no planificadas pero importantes
 Propósitos de la evaluación: metas del sistema 461

el proyecto y su padre. Algunos ejemplos de recomendaciones sobre estos "objetivos

auxiliares" incluyen intentos de:

• Mejorar la comprensión de las formas en que los proyectos pueden ser valiosos para la organización.

• Mejorar los procesos de organización y gestión de proyectos, más conocido como la “madurez”
de la gestión de proyectos de la empresa.

• Brindar información y experiencia para ingresar a nuevos mercados.

• Proporcionar un entorno agradable en el que los miembros del equipo del proyecto puedan trabajar juntos de
forma creativa.

• Identificar las fortalezas y debilidades de la organización en el personal relacionado con el proyecto, la

administración general y las técnicas y sistemas de toma de decisiones.

• Identificar y mejorar la respuesta a los factores de riesgo en el uso de proyectos por parte de la empresa.

• Permitir el acceso a la toma de decisiones de políticas del proyecto por parte de partes interesadas externas

• Mejorar la forma en que los proyectos contribuyen al crecimiento profesional de los miembros del equipo del proyecto.

• Identificar al personal del proyecto que tiene un alto potencial de liderazgo gerencial.

La identificación de objetivos auxiliares es una tarea difícil y políticamente delicada. Aunque el adjetivo
“auxiliar” no es un descriptor suficiente, es la mejor palabra que pudimos encontrar. Los sinónimos son “útil”,
“subsidiario”, “accesorio” y cosas por el estilo, y tenemos todas estas cosas en mente. Además, los objetivos
auxiliares generalmente no se identifican abiertamente. Las entrevistas con los responsables de la toma de
decisiones sobre los proyectos ayudarán a exponer los objetivos auxiliares que busca la empresa al apoyar el
proyecto. Pero en su mayor parte, están "ocultos" por accidente, no por un propósito. Encontrarlos a
menudo requiere un razonamiento deductivo. Las decisiones y comportamientos organizacionales implican
metas, a menudo metas muy específicas, que simplemente no se detallan en ninguna parte de los manuales
organizacionales. Por ejemplo, La mayoría de los ejecutivos desean operar sus organizaciones de tal manera
que las personas disfruten del trabajo que hacen y disfruten trabajando juntas, pero solo ocasionalmente las
empresas publican tales declaraciones. Pocas empresas rechazarían este objetivo; ellos simplemente no
abiertamente suscríbete. Aun así, este objetivo en particular afecta las decisiones que se toman en casi todas
las firmas que conocemos.
A veces, sin embargo, los objetivos auxiliares y las partes interesadas que los apoyan pueden identificarse
fácilmente. Algunos ejemplos son: metas que gobiernan el tratamiento de los animales que pueden estar
involucrados en un proyecto, metas que exigen un procesamiento muy específico de la información sobre el
resultado de un proyecto (por ejemplo, medicamentos farmacéuticos) o metas que controlan los procesos de
producción asociados con un proyecto ( p. ej., anticontaminación). Ya sea que estén claramente identificadas o no, y
se midan o no, las metas auxiliares afectan las decisiones tomadas en todos los proyectos.
Un intento razonable de identificar tantos objetivos como sea posible es valioso. Con frecuencia, se requiere el
reconocimiento de un objetivo auxiliar para comprender por qué se toman ciertas decisiones sobre proyectos. El
deseo de identificar a las personas que tienen un alto potencial de liderazgo puede explicar por qué a una persona
determinada con relativamente poca experiencia se le asigna una responsabilidad de proyecto específica. Los
objetivos auxiliares añaden varias dimensiones adicionales a la evaluación de proyectos.
Existen serios problemas asociados con la búsqueda de los objetivos auxiliares de un proyecto.
Primero, y probablemente el más importante, es el hecho obvio de que no se puede medir el desempeño
frente a una meta desconocida. Por lo tanto, si una meta no se reconoce abiertamente, los miembros del
equipo del proyecto no deben temer que su desempeño pueda ser sopesado y considerado deficiente. El
resultado es que las metas que aparecen en la propuesta del proyecto deben ser reconocidas y son una
fuente de ansiedad en los miembros del equipo del proyecto. Pero las metas "no escritas" a menudo se
pueden ignorar. Una vez más, los objetivos auxiliares rara vez se rechazan; simplemente no se mencionan.
No es relevante si se merece o no la ansiedad por alcanzar las metas auxiliares. Particularmente
en esta era de “reestructuración” corporativa, la ansiedad está presente. Es acentuado por el
462 CAPÍTULO 12 Auditoría de proyectos

temer que una evaluación no se lleve a cabo de manera “justa”, con el énfasis adecuado en lo que se
está logrando en lugar de enfatizar las deficiencias. Si la autoimagen del equipo del proyecto es muy
fuerte, esta barrera para encontrar objetivos auxiliares del proyecto puede ser débil, pero nunca está
ausente.
Un segundo problema surge durante los intentos de encontrar los objetivos auxiliares de un proyecto.
Los individuos persiguen sus propios fines mientras trabajan para organizaciones. A veces, sin embargo, las
personas pueden no estar dispuestas a admitir sus metas personales, metas que pueden ver como no del
todo consistentes con los objetivos de la organización. Por ejemplo, una persona puede buscar unirse a un
proyecto para aprender una nueva habilidad, una que aumente la movilidad laboral de esa persona. En
ocasiones, la dirección científica que toman los proyectos de I + D depende tanto de las áreas de interés
actuales de los científicos que trabajan en el proyecto como de la necesidad científica del proyecto. Si bien
tales propósitos no son ilegítimos o poco éticos, rara vez se admiten.
Un tercer problema surge por la falta de confianza. Los miembros de un equipo de proyecto nunca se
sienten cómodos en presencia de un auditor / evaluador. Si el auditor / evaluador es un "forastero",
cualquiera que no pueda ser identificado como miembro del equipo del proyecto, existe el temor de que "no
nos entenderán". Si bien esos temores rara vez son específicos, no obstante son reales. Si el auditor /
evaluador es un "interno", el miedo se centra en la posibilidad de que el interno tenga alguna agenda oculta,
esté buscando alguna ventaja personal a expensas del "resto de nosotros". Se desconfía de los motivos tanto
de los de adentro como de los de afuera. Como resultado, los miembros del equipo del proyecto tienen poco
o ningún incentivo para ser comunicativos acerca de sus objetivos auxiliares individuales o del proyecto.

Finalmente, existe un cuarto problema. Los proyectos, al igual que todas las organizaciones que sirven
a fines humanos, son polivalentes. El conjunto diverso de objetivos directos y auxiliares, de proyectos e
individuales no tiene prioridades claras, determinadas (o aceptadas) organizacionalmente. Varios miembros
del equipo del proyecto pueden tener ideas bastante diferentes sobre qué propósitos son los más
importantes, cuáles son los siguientes y cuáles son los menos importantes. En ausencia de preguntas
directas sobre el asunto, nadie tiene que enfrentarse a la cuestión de quién tiene razón y quién no. Siempre
que los objetivos y prioridades no se hagan explícitos, los miembros del equipo del proyecto pueden acordar
qué las cosas deben hacerse sin necesariamente estar de acuerdo (o incluso discutir)
por qué esas cosas deben hacerse. Por lo tanto, si algunos de los objetivos del proyecto no se debaten
abiertamente, cada miembro puede tolerar los diferentes énfasis de los compañeros del equipo. Nadie se ve
obligado a elegir o incluso a discutir estos asuntos con sus compañeros de trabajo.
Con todo, la tarea de encontrar los objetivos auxiliares de un proyecto es difícil. La mayoría de las
evaluaciones simplemente las ignoran, pero se recomienda al PM que se interese mucho en esta área y
solicite que las evaluaciones incluyan metas auxiliares, las del proyecto y de la organización matriz, si no las
de los individuos. Aunque normalmente uno debe estar satisfecho con medidas cualitativas aproximadas del
logro de metas auxiliares, la información puede ser valiosa. Puede proporcionar información sobre
cuestiones tales como: ¿Qué tipo de cosas motivan a las personas a unirse y trabajar en proyectos? ¿Qué tipo
de recompensas son más efectivas para obtener el máximo esfuerzo del personal del proyecto? ¿Cuáles son
las principales preocupaciones de las personas específicas que trabajan en el proyecto?

En el Capítulo 5, aludimos a la importancia de la “sala de guerra” de gestión de

proyectos (oficina, PMO) como un lugar de reunión para el equipo del proyecto, un área
de visualización de los gráficos que muestran el progreso del proyecto, un repositorio
central para los archivos del proyecto y informes y una oficina para el PM y otros
administradores del proyecto. La sala de guerra es también la "casa club" de los
miembros del equipo del proyecto y sirve para un importante objetivo auxiliar. Es para el
proyecto lo que el pub local era para "esa vieja pandilla mía". La camaradería asociada
con un proyecto exitoso y bien administrado proporciona una gran satisfacción a los
miembros del equipo. La PMO, por lo tanto, satisface una necesidad emocional además
de cumplir con sus objetivos administrativos más mundanos y directos. Sin embargo, las
mejores PMO (Baker, 2007) también ofrecen el mejor liderazgo de proyectos en la
organización y están orgullosas de ello.
 La auditoría del proyecto 463

12,2 La auditoría del proyecto

La auditoría del proyecto es un examen completo de la gestión de un proyecto, su metodología

y procedimientos, sus registros, sus propiedades, sus presupuestos y gastos, y su grado de
finalización. Puede tratar el proyecto como un todo o solo una parte del proyecto. El informe
formal puede presentarse en varios formatos, pero debe, como mínimo, contener comentarios
sobre los siguientes puntos:

1. Estado actual del proyecto. ¿El trabajo realmente terminado coincide con el nivel de
terminación planificado?
2. Situación futura. ¿Son probables cambios significativos en el cronograma / costo / alcance? Si es así, indique la
naturaleza de los cambios.

3. Estado de tareas cruciales. ¿Qué avances se han realizado en las tareas que podrían decidir el
éxito o el fracaso del proyecto?

4. Evaluación de riesgos. ¿Cuál es el potencial de fracaso del proyecto o pérdida monetaria?

5. Información pertinente a otros proyectos. Qué lecciones aprendidas del proyecto

¿Se está auditando se puede aplicar a otros proyectos que está llevando a cabo la organización?

6. Limitaciones de la auditoría. ¿Qué supuestos o limitaciones afectan los datos de la auditoría?

Tenga en cuenta que la auditoría del proyecto no es una auditoría financiera. Los procesos de auditoría
son similares en que cada uno representa una investigación cuidadosa del tema de la auditoría, pero los
resultados de estos procesos son bastante diferentes. La principal distinción entre los dos es que la auditoría
financiera tiene un alcance limitado. Se concentra en el uso y preservación de los activos de la organización.
La auditoría del proyecto tiene un alcance mucho más amplio y puede tratar el proyecto como

Gestión de proyectos en la práctica

Lecciones de la auditoría de 110 proyectos cliente / para hacer concesiones entre estos objetivos. Este nivel de
autoridad debe estar presente tanto del lado del cliente como del
servidor y de sistemas abiertos
lado del contratista.

En una auditoría de 11 años de 110 clientes / servidores y proyectos de
sistemas abiertos, un auditor redujo las diferencias entre el éxito y el
fracaso a cuatro conceptos fundamentales.
1. Objetividad en cuanto a alcance, presupuesto, plazos y
diseño de solución. La falta de objetividad en estas áreas es
una de las causas básicas del fracaso de un proyecto. Las
decisiones relativas al caso de negocio para iniciar el
proyecto y establecer todos sus parámetros deben
analizarse en busca de sesgos y diligencia inadecuada.
4. Responsabilidad suficiente para garantizar que todas las partes se
desempeñen según lo prometido o sean definitivamente responsables.
La rendición de cuentas debe detallarse a fondo en los contratos
originales y las órdenes de compra. Debe incluir detalles sobre el
campeón del proyecto, el estimador original, los proveedores, el
equipo del cliente y los usuarios, y el equipo del contratista.
Mantener los proyectos cortos, por ejemplo, de menos de 6
meses, evita que la responsabilidad se diluya a través de la
rotación de personal.

2. Personas con experiencia en todos los niveles del

Preguntas
proyecto. Tener gente con experiencia tanto del lado del
cliente como del lado del contratista ayuda en varias áreas:
1. ¿Cuál de los cuatro conceptos es el más importante, en
mantener una actitud cooperativa de resolución de
su opinión?
problemas, hacer cumplir los hitos y los entregables, usar 2. Amplíe el tema 3.
técnicas profesionales de gestión de proyectos y mantener 3. ¿Qué lecciones podría haber esperado que no
la participación continua del usuario. parecen estar incluidas?
3. Autoridad emparejada con responsabilidad. Dado que un proyecto
generalmente se establece con un cierto alcance pero con un Fuente: T. Ingram, "Cliente / servidor e imágenes: a tiempo, dentro del

presupuesto y un cronograma limitados, el PM debe tener la autoridad presupuesto, como se prometió", PM Network, Vol. 9.
464 CAPÍTULO 12 Auditoría de proyectos

TABLA 12.1 Comparación de auditorías financieras con auditorías de proyectos

Auditorías financieras Auditorías de proyectos

Estado Confirma el estado de la empresa en Debe crear una base para y confirmar el
relación con el estándar aceptado estado de cada proyecto.

Predicciones Estado de bienestar económico de Estado futuro del proyecto

la empresa

Medición Principalmente en términos financieros Términos financieros más cronograma,

progreso, uso de recursos, estado de los
objetivos auxiliares

Mantenimiento de registros Formato dictado por Sin sistema estándar, utiliza cualquier
sistema regulaciones legales y sistema deseado por la organización
estándares profesionales individual o dictado por contrato

Existencia de Se necesitan registros mínimos para No existen registros, el banco de datos debe
sistema de informacion iniciar la auditoría diseñarse y utilizarse para iniciar la auditoría.

Recomendaciones Por lo general, pocos o ninguno, a A menudo se requiere y puede

menudo restringido a la gestión del cubrir cualquier aspecto del
sistema de contabilidad. proyecto o su gestión.

Calificaciones para Acostumbrado a calificar declaraciones si Las calificaciones se centran en las deficiencias
el informe de auditoría las condiciones lo exigen, pero fuerte del proceso de auditoría (por ejemplo, falta de
presión gerencial para no hacerlo experiencia técnica, falta de fondos o tiempo)

un todo o cualquier componente o conjunto de componentes del proyecto. La Tabla 12.1 enumera las principales
diferencias entre las auditorías financieras y de proyectos.
Si bien la auditoría del proyecto puede estar relacionada con cualquier aspecto de la gestión del
proyecto, no es una auditoría de gestión tradicional. Las auditorías de gestión están destinadas
principalmente a garantizar que los sistemas de gestión de la organización estén en su lugar y operativos. La
auditoría del proyecto va más allá. Entre otras cosas, está destinado a garantizar que el proyecto esté siendo
apropiadamente administrado. Algunos sistemas de gestión se aplican bastante bien a todos los proyectos:
por ejemplo, las técnicas de planificación, programación, presupuestación, etc. Por otro lado, algunas
prácticas de gestión deben diferir con diferentes tipos de proyectos. Ver Sangameswaran
(1995) y Corbin et al. (2001) para obtener una guía sobre lo que se debe y no se debe hacer en la auditoría.
Sostenemos que los proyectos de software no sonsignificativamente diferente a otros tipos de proyectos.
Estamos en esa posición, pero también notamos que poseen unas características únicas dignas de
reconocimiento y respuesta, de ahí el auge de la gestión ágil para proyectos de alcance incierto. Por ejemplo,
los proyectos basados en computadoras suelen ser muy intensivos en mano de obra, mientras que muchos
proyectos de fabricación, por ejemplo, son muy intensivos en capital. Un gerente reflexivo simplemente no
adoptará el mismo enfoque gerencial para cada uno. La necesidad y el valor de un estilo participativo (Six
Sigma, TQM, participación de los empleados, etc.) están bien establecidos en el caso de proyectos intensivos
en mano de obra donde los problemas a menudo están mal estructurados. Si el proyecto es intensivo en
capital y se caracteriza por problemas bien estructurados, la necesidad y el valor de un estilo participativo
sonrelativamente disminuido. (El lector no debe leer estas declaraciones como una degradación del valor de
la gestión participativa. Simplemente es más valiosa y relevante en algunos casos que en otros).

En resumen, la auditoría de gestión analiza los sistemas de gestión y su uso. La auditoría del
proyecto estudia los aspectos financieros, administrativos y técnicos del proyecto como un conjunto
integrado aplicado a un proyecto específico en un entorno organizacional específico.
 La auditoría del proyecto 465

Profundidad de la auditoría

Hay varias limitaciones prácticas que pueden limitar la profundidad del auditor del proyecto
investigación. El tiempo y el dinero son dos de los límites más comunes (y obvios) sobre la profundidad de la
investigación y el nivel de detalle que se presenta en el informe de auditoría. Por supuesto, existen costos asociados
con el proceso de auditoría / evaluación por encima de los costos habituales del tiempo profesional y administrativo
empleado en la realización de la auditoría. La acumulación, el almacenamiento y el mantenimiento de datos
auditables son elementos de costo importantes. Recuerde que dicho almacenamiento puede ser de importancia
crítica para cumplir con la prueba de “debida diligencia” que se indica en el Capítulo 11. (Recuerde también que la
destrucción de datos comerciales puede ser ilegal en determinadas circunstancias).
También son graves, pero menos cuantificables, dos costos que a menudo se pasan por alto. Primero,
no importa cuán hábil sea el evaluador, un proceso de auditoría / evaluación siempre distrae a quienes
trabajan en el proyecto. Ningún proyecto está completamente poblado de individuos cuya autoestima es tan
alta que la evaluación es recibida sin ansiedad. La preocupación por el resultado de la auditoría tiende a
producir un nivel excesivo de actividad de autoprotección, lo que, a su vez, reduce el nivel de actividad
dedicado al proyecto. En segundo lugar, si el informe de evaluación no se redacta con un tono “constructivo”,
la moral del proyecto se verá afectada.2 Dependiendo de la gravedad de la caída de la moral, el trabajo en el
proyecto puede sufrir un serio revés.
Es lógico variar la profundidad de la investigación en función de las circunstancias y necesidades únicas
de cada proyecto. Si bien una auditoría se puede realizar en cualquier nivel que desee la organización, cuatro
niveles distintos se reconocen fácilmente y se utilizan ampliamente: la auditoría general, la auditoría
detallada, la auditoría técnica y la auditoría de riesgos. Normalmente, la auditoría general está más limitada
por el tiempo y los recursos y, por lo general, es una breve revisión del proyecto, que aborda ligeramente las
seis inquietudes señaladas anteriormente. Una auditoría detallada típica se lleva a cabo cuando se requiere
un seguimiento de la auditoría general. Esto tiende a ocurrir cuando la auditoría general ha revelado un nivel
inaceptable de riesgo o mal desempeño en alguna (s) parte (s) del proyecto.
A veces, la auditoría detallada no puede investigar problemas a un nivel técnico
satisfactorio porque el auditor no posee el conocimiento técnico necesario. En tales casos, se
requiere una auditoría técnica. Las auditorías técnicas normalmente las realiza un técnico
calificado bajo la guía directa del auditor del proyecto. En el caso de tecnología muy avanzada o
secreta, puede ser difícil encontrar auditores técnicos calificados dentro de la organización. En
tales casos, no es raro que la firma utilice consultores académicos que hayan firmado los
documentos de confidencialidad apropiados. Aunque no es una regla estricta y rápida, la
auditoría técnica suele ser la más detallada.
Si bien la organización suele iniciar las auditorías generales, detalladas y técnicas, el PM tiene la
responsabilidad de realizar auditorías de riesgo en los puntos apropiados de la ejecución del
proyecto. Ubicado enPMBOK, Las auditorías de riesgos se utilizan para investigar la eficacia con la
PMBOK
que se identifican y gestionan los riesgos del proyecto. Dado que las auditorías de riesgos son
responsabilidad del PM, pueden incorporarse a las reuniones de rutina del proyecto o realizarse como 11.6.2.2
actividades independientes independientes.

Momento de la auditoría

Dado que todos los proyectos de tamaño o importancia significativa deben ser auditados, las primeras
auditorías generalmente se realizan al principio de la vida del proyecto. Cuanto antes se descubra un
problema, más fácil será resolverlo. Las primeras auditorías a menudo se centran en los problemas técnicos
para asegurarse de que los problemas técnicos clave se hayan resuelto o estén bajo un ataque competente.

2Se aconseja al evaluador que recuerde dos principios fundamentales: (1) La crítica constructiva no se siente tan
constructiva para el criticado; y (2) Arregle primero, luego culpe, si le queda algo de energía.
466 CAPÍTULO 12 Auditoría de proyectos

Por lo general, las auditorías realizadas más adelante en el ciclo de vida de un proyecto tienen un valor menos
inmediato para el proyecto, pero tienen más valor para la organización matriz. A medida que se desarrolla el
proyecto, es menos probable que los problemas técnicos sean motivo de preocupación. La conformidad con el
cronograma y el presupuesto se convierte en el principal interés. Las cuestiones de gestión son cuestiones de gran
interés para las auditorías realizadas al final de la vida del proyecto (por ejemplo, eliminación de equipos o
reasignación de personal del proyecto).
Las auditorías posteriores al proyecto se llevan a cabo con varios objetivos básicos en mente. Primero, una auditoría

posterior al proyecto es a menudo una necesidad legal porque el cliente especificó dicha auditoría en el contrato. En segundo

lugar, la auditoría posterior al proyecto es una parte importante del Informe posterior al proyecto, que a su vez es la principal

fuente de retroalimentación gerencial para la empresa matriz. En tercer lugar, la auditoría posterior al proyecto es necesaria

para contabilizar todas las propiedades y los gastos del proyecto.

En la Tabla 12.2 se muestran observaciones adicionales sobre la oportunidad y el valor de las auditorías.

Formato y uso del informe de auditoría

El tipo de proyecto que se audita y los usos para los que está destinada la auditoría dictan algunos detalles
del formato del informe de auditoría. Sin embargo, dentro de cualquier organización en particular, es útil
establecer un formato general al que deben ajustarse todos los informes de auditoría. Esto hace posible que
los administradores de proyectos, los auditores y la dirección de la organización tengan la misma
comprensión y expectativas del informe de auditoría como dispositivo de comunicación. Si el informe de
auditoría debe servir como un dispositivo de comunicación, también debe haber una lista de distribución
predeterminada para dichos documentos. Cuando la distribución está muy restringida, es casi seguro que el
informe se convierta en el foco de conflictos y tensiones interpersonales e intergrupales.
Si bien algunos PM insisten en un formato complicado para los informes de evaluación adaptado a sus
proyectos individuales, cuanto más simple y directo sea el formato, mejor. La información debe organizarse
de modo que facilite la comparación de los resultados previstos con los reales. Las desviaciones significativas
de los resultados reales de los pronosticados deben destacarse y explicarse en una serie de comentarios.
Esto facilita el trabajo del lector y tiende a mantener las preguntas enfocadas en temas importantes en lugar
de trivialidades. Este arreglo también reduce la probabilidad de que los altos directivos participen en
"expediciones de pesca" en busca de algo "incorrecto".

TABLA 12.2 Calendario y valor de las auditorías / evaluaciones de proyectos

Etapa del proyecto Valor

Iniciación Valor significativo si la auditoría se realiza temprano, antes de que se complete el 25
por ciento de la etapa de planificación inicial

Estudio de factibilidad Muy útil, particularmente la auditoría técnica

Plan preliminar/ Muy útil, especialmente para establecer estándares de medición para garantizar la
presupuesto programado conformidad con los estándares.

Programa de referencia Menos útil, plan congelado, flexibilidad del equipo limitada

Evaluación de datos por Marginalmente útil, equipo a la defensiva ante los hallazgos
equipo de proyecto

Implementación Más o menos útil, dependiendo de la importancia de la metodología del proyecto

para una implementación exitosa

Postproyecto Más o menos útil, dependiendo de la aplicabilidad de los hallazgos a

proyectos futuros.
 La auditoría del proyecto 467

en cada dato y frase del informe. Una vez más, les recordamos a los PM el dicho
"Nunca dejes que el jefe se sorprenda".
Deben evitarse los comentarios negativos sobre personas o grupos asociados con el proyecto.
Redacte el informe con un estilo claro, profesional y sin emociones, y limite su contenido a la
información y los problemas que sean relevantes para el proyecto. Los siguientes elementos cubren
mínimo información que debe incluirse en el informe de auditoría.

1. Introducción Esta sección contiene una descripción del proyecto para proporcionar un marco de
comprensión para el lector. Los objetivos del proyecto (metas directas) deben estar claramente
delineados. Si los objetivos son complejos, puede ser útil incluir partes explicativas de la
propuesta de proyecto como una adición al informe.

2. Estado actual El estado debe informarse en el momento de la auditoría y, entre otras

cosas, debe incluir las siguientes medidas de desempeño:
Costo: Esta sección compara los costos reales con los costos presupuestados. Los períodos de
tiempo para los que se realizan las comparaciones deben definirse claramente. Como se señaló en el
Capítulo 7, el informe debe centrarse en ladirecto Cargos hechos al proyecto. Si también es necesario
mostrar proyectototal costos, con todos los gastos generales, estos datos de costos deben presentarse
en un adicional juego de mesas.
Cronograma: Se debe informar el desempeño en términos de eventos o hitos planificados (véanse
las Figuras 10.15 y 11.5 como ejemplos). Las partes completadas del proyecto deben identificarse
claramente y el porcentaje de finalización debe informarse en todas las tareas sin terminar para las que
es posible realizar estimaciones. Asegúrese de que el método utilizado para estimar el porcentaje de
finalización no engañe a los lectores (consulte la Sección 10.3).
Alcance: Esta sección compara el trabajo completado con los recursos gastados. Los gráficos
o tablas de valor ganado (ver Figuras 10.7 y 10.13) pueden usarse para este propósito si se
desea, pero pueden carecer del nivel de detalle apropiado. El requisito aquí es la información
que ayudará a identificar problemas con tareas específicas o conjuntos de tareas. Con base en
esta información, se hacen proyecciones con respecto al momento y los montos de los gastos
planificados restantes.
Calidad: Si se trata de un problema crítico o no, depende del tipo de proyecto
que se audite. La calidad es una medida del grado en que la salida de un sistema
se ajusta a características preespecificadas. Para algunos proyectos, las
características preespecificadas están tan vagamente expresadas que la
conformidad no es un gran problema. A veces, un proyecto puede producir
resultados que superan con creces las especificaciones originales. Por ejemplo,
un proyecto puede requerir un subsistema que cumpla con ciertos estándares
mínimos. Es posible que la empresa ya haya producido un subsistema de este
tipo, uno que cumpla con los estándares muy por encima de los requisitos
actuales. Puede resultar eficiente, sin menos eficacia, utilizar el sistema
previamente diseñado con su exceso de rendimiento. Si hay una especificación
de calidad detallada asociada con el proyecto,
3. Estado futuro del proyecto Esta sección contiene las conclusiones del auditor con respecto al progreso
junto con recomendaciones para cualquier cambio en el enfoque técnico, el cronograma o el
presupuesto que deben realizarse en las tareas restantes. Excepto en circunstancias inusuales, por
ejemplo, cuando los resultados hasta la fecha indiquen claramente la indeseabilidad de alguna tarea
planificada previamente, el dictamen del auditor debe considerar solo el trabajo que ya se ha
completado o que está bien encaminado. No se deben hacer suposiciones sobre problemas técnicos
que aún están bajo investigación en el momento de la auditoría. Los informes de auditoría / evaluación
del proyecto no son documentos apropiados para reescribir la propuesta del proyecto.
468 CAPÍTULO 12 Auditoría de proyectos

4. Problemas críticos de gestión Todos los asuntos que el auditor considere que requieren un
seguimiento cercano por parte de la alta dirección deben incluirse en esta sección, junto con una
breve explicación de las relaciones entre estos asuntos y los objetivos del proyecto. Una breve
discusión de las compensaciones de tiempo / costo / alcance brindará a la alta gerencia
información útil para tomar decisiones sobre el futuro del proyecto.

5. Gestión de riesgos Esta sección debe contener una revisión de los principales riesgos asociados con el
proyecto y su impacto proyectado en el tiempo / costo / alcance del proyecto. Si existen decisiones
alternativas que pueden alterar significativamente los riesgos futuros, pueden anotarse en este punto
del informe. Una vez más, observamos que el informe de auditoría no es el lugar adecuado para
adivinar a quienes redactaron la propuesta de proyecto. El Informe posterior al proyecto, por otro lado,
a menudo contendrá secciones sobre el tema general de "Si supiéramos entonces lo que sabemos
ahora".

6. Advertencias, limitaciones y suposiciones Esta sección del informe puede colocarse

al final o puede incluirse como parte de la introducción. El auditor es responsable de la
precisión y puntualidad del informe, pero la alta dirección aún conserva la responsabilidad
total de la interpretación del informe y de cualquier acción basada en los hallazgos. Por
esa razón, el auditor debe incluir específicamente una declaración que cubra cualquier
limitación sobre la exactitud o validez del informe.

Responsabilidades del auditor / evaluador del proyecto

En primer lugar, el auditor debe "decir la verdad". Esta afirmación no es tan simplista como podría
parecer. Es un reconocimiento del hecho de que hay varios niveles de verdad asociados con cualquier
proyecto. El auditor debe abordar la auditoría de manera objetiva y ética y asumir la responsabilidad
de lo que se incluye y excluye de la consideración en el informe. El conocimiento de los sesgos de las
distintas partes interesadas en el proyecto, incluidos los propios sesgos del auditor, es esencial, pero
se requiere un cuidado extremo si el auditor desea compensar dichos sesgos. (Una nota que cierta
informaciónmayo ser sesgado suele ser suficiente.) Las áreas de investigación fuera del área de
experiencia técnica del auditor deben reconocerse y buscarse asistencia cuando sea necesario. El
auditor / evaluador debe mantener la independencia política y técnica durante la auditoría y tratar
todos los materiales recopilados como confidenciales hasta que la auditoría se publique formalmente.

Walker y col. (1980) desarrollan un caso aún más sólido a favor de la "independencia" del
auditor. Argumentan que la independencia es esencial para la capacidad de la administración de
recopilar información que sea oportuna y precisa. También enumeran los siguientes pasos para
realizar una auditoría:

• Reúna un pequeño equipo de expertos experimentados

• Familiarizar al equipo con los requisitos del proyecto.
• Auditar el proyecto in situ
• Después de la finalización, informe a la gestión del proyecto.
• Producir un informe escrito de acuerdo con un formato preestablecido
• Distribuya el informe al PM y al equipo del proyecto para su respuesta.
• Haga un seguimiento para ver si se han implementado las recomendaciones

Si la alta dirección y el equipo del proyecto van a tomar en serio la auditoría / evaluación,
toda la información debe presentarse de manera creíble. La precisión de los datos debe
comprobarse cuidadosamente, al igual que todos los cálculos. La determinación de qué
información incluir y excluir es algo que no se puede tomar a la ligera. Finalmente, el auditor
debe participar en una evaluación continua del proceso de auditoría en busca de formas de
mejorar la efectividad, eficiencia y valor del proceso.

12,3 El ciclo de vida de la auditoría del proyecto
Hasta ahora, hemos considerado la auditoría y la evaluación del proyecto como si fueran una misma cosa. En
la mayoría de los casos lo son. La auditoría contiene una evaluación y un evaluador debe realizar algún tipo
de auditoría. Consideremos ahora la auditoría como un documento formal requerido por contrato con el
cliente. Si el cliente es el gobierno federal, la naturaleza de la auditoría del proyecto se define con más o
menos precisión, al igual que el proceso de auditoría.
Gestión de proyectos en la práctica
Auditoría de un proyecto en problemas en los laboratorios
químicos de los estados atlánticos
Atlantic States Chemical Laboratories (ASCL) recibió un contrato
de una empresa emprendedora, Oretec, para realizar un tipo
único de análisis químico en aleaciones especiales que habían
creado en sus propios laboratorios con el interés de identificar
aleaciones comerciales potencialmente exitosas. El contrato
enfatizó la calidad del esfuerzo y la velocidad de los análisis de
laboratorio continuos. La duración del contrato sería indefinida,
con un pago mensual de $ 100.000. El oficial de enlace de Oretec
tendría acceso al trabajo de laboratorio de ASCL para observación.
A medida que avanzaba el trabajo, el oficial de
enlace se involucró más en el proyecto, presionando al
equipo para que modificara su enfoque y se saltara los
procedimientos habituales de repetición de verificación
en aras del tiempo. En dos ocasiones, el equipo de ASCL
ideó un análisis que indicaba que se podía producir un
producto comercialmente exitoso. El oficial de enlace
quedó satisfecho con el esfuerzo y pidió sugerencias
sobre cómo producir el producto comercialmente. Sin
embargo, las pruebas en Oretec indicaron que estos
enfoques no funcionarían. A medida que pasó el punto
medio del proyecto, la presión por más análisis y más
rápidos aumentó aún más, y el oficial de enlace se volvió
más beligerante y difícil de complacer. Poco después, el
presidente de ASCL recibió una carta de Oretec
expresando una serie de quejas y rescindiendo el
contrato con efecto inmediato.
La auditoría informó lo siguiente:
1. Puntos de vista general:
• El enfoque original del proyecto era sólido, pero el
oficial de enlace del cliente lo modificó; sin embargo,
todavía se hicieron hallazgos importantes.
• Los análisis en sí mismos se realizaron correctamente.
• Hubo varios éxitos analíticos durante el proyecto
(cada uno identificado).
• La comercialización no era responsabilidad de ASCL
sino del cliente, incluso si ASCL sugirió algunos
procesos posibles.
El ciclo de vida de la auditoría del proyecto 469
• Hubo una participación excesiva del oficial de enlace
en la gestión del proyecto, incluidos frecuentes
cambios de dirección.
• ASCL no documentó los cambios y las decisiones de
gestión de proyectos en curso, ni tampoco se los
comunicó al cliente.
2. Análisis de las críticas del cliente (aproximadamente la mitad de las críticas
los icismos eran válidos, se describen los detalles).
3. Otros puntos importantes:
• Los procesos de comercialización propuestos por ASCL,
de hecho, se han utilizado con éxito en casos similares.
Las pruebas del cliente que indican su inaceptabilidad son
incorrectas.
• Los informes proporcionados por ASCL y criticados por el
cliente como incompletos fueron redirigidos por el oficial
de enlace para ser preparados de manera rápida e
informal. Los informes de éxito del análisis del proyecto
no habrían sido comprensibles para la gerencia del
cliente, solo para el personal técnico o el oficial de enlace.
• La gerencia de ASCL brindó orientación / apoyo
insuficiente al líder del proyecto en sus relaciones con
el cliente.
4. Recomendación: Establecer un procedimiento formal para identificar
proyectos de alto riesgo en la etapa del contrato y luego monitorearlos
cuidadosamente para detectar desviaciones del plan. Los factores que
contribuyeron a convertir este proyecto en un proyecto de alto riesgo
fueron financiamiento inadecuado, tiempo insuficiente, pocas
posibilidades de éxito, un cliente poco sofisticado y un acceso excesivo
a las actividades del proyecto en curso por parte del cliente.
Preguntas
1. ¿Fue este un buen uso del concepto de auditoría?
2. ¿Cuál fue el principal problema de este proyecto?
3. A pesar de la recomendación, ASCL ya había implementado una
lista y un sistema de “proyectos problemáticos”. ¿Por qué crees
que puede que no haya captado este proyecto en particular?
¿Funcionará mejor el nuevo procedimiento?
Fuente: J. Meredith, proyecto de consultoría.
470 CAPÍTULO 12 Auditoría de proyectos

Como el proyecto en sí, la auditoría tiene un ciclo vital compuesto por una progresión ordenada
de eventos bien definidos. Hay seis de estos eventos.

1. Inicio de la auditoría del proyecto Este paso implica iniciar el proceso de auditoría, definir el
propósito y el alcance de la auditoría y recopilar información suficiente para determinar la
metodología de auditoría adecuada.

2. Definición de la línea de base del proyecto Esta fase del ciclo normalmente consiste en
identificar las áreas de desempeño que se evaluarán, determinar los estándares para cada área
a través de evaluaciones comparativas o algún otro proceso, determinar las expectativas de
desempeño de la gestión para cada área y desarrollar un programa para medir y reunir los
requisitos. información.

Ocasionalmente, no existen estándares convenientes o pueden determinarse mediante evaluaciones

comparativas. Por ejemplo, se desarrolló un modelo de precios de productos básicos como parte de un
gran proyecto de marketing. No existían datos de referencia que pudieran servir para ayudar a evaluar
el modelo. Debido a que el producto se vendió mediante licitación abierta, la empresa utilizó sus
procedimientos de licitación estándar. Los resultados formaron datos de referencia con los que se
podría probar el modelo de precios "como si". La tabla 12.3 muestra los resultados de una de esas
pruebas. CCC es la empresa y los contratos por los que licitay ganó, junto con los ingresos asociados
(precio neto de la mina × tonelaje), se muestran. Se muestra información similar para el Modelo C, que
se usó "como si", por lo que la columna de Ingresos del Modelo C muestra esas ofertas en el modelo
hubiera ganado, si realmente se hubiera utilizado.

3. Establecimiento de una base de datos de auditoría Una vez que se establezcan los estándares de referencia,
comienza la ejecución de la auditoría. El siguiente paso es crear una base de datos para que la utilice el equipo
de auditoría. Por ejemplo, considere la base de datos requerida por la prueba del modelo de precios de la CCC
en la Tabla 12.3. Dependiendo del propósito y alcance de la auditoría, la base de datos puede incluir
información necesaria para la evaluación de la organización, gestión y control del proyecto, estado del proyecto
pasado y actual, desempeño del cronograma, desempeño de costos y calidad de la producción, así como planes
para el futuro el proyecto. La información puede variar desde una descripción altamente técnica del
desempeño hasta una descripción basada en el comportamiento de la interacción de los miembros del equipo
del proyecto.

Debido a que el propósito y el alcance de las auditorías varían ampliamente de un proyecto a otro y para
diferentes momentos en cualquier proyecto dado, la base de datos de auditoría es con frecuencia bastante
extensa. La base de datos requerida para las auditorías del proyecto debe especificarse en el plan maestro del
proyecto. Si se hace esto, la información necesaria estará disponible cuando sea necesario. No obstante, es
importante evitar recopilar "cualquier cosa que pueda ser útil", ya que esto puede imponer requisitos
extraordinarios de recopilación y almacenamiento de información en el proyecto.

4. Análisis preliminar del proyecto Una vez que se establecen los estándares y se recopilan
los datos, se emiten juicios. Algunos auditores evitan el juicio sobre la base de que una
responsabilidad tan delicada pero importante debe reservarse a la alta dirección. Pero el
juicio a menudo requiere una comprensión bastante sofisticada de los aspectos técnicos
del proyecto y / o de la estadística y la probabilidad, temas que pueden eludir a algunos
gerentes. En tal caso, el auditor debe analizar los datos y luego presentar el análisis a los
gerentes de manera que comuniquen el significado real de los hallazgos de la auditoría. Es
deber del auditor informar al PM sobre todos los hallazgos y juicios.antes de publicar el
informe de auditoría. El propósito de la auditoría es mejorar el proyecto que se audita, así
como mejorar todo el proceso de gestión de proyectos. No pretende ser un dispositivo
para avergonzar al PM.
5. Preparación del informe de auditoría Esta parte del ciclo de vida de la auditoría incluye la preparación
del informe de auditoría, organizado por cualquier formato que se haya seleccionado para su uso. Un
conjunto de recomendaciones, junto con un plan para implementarlas, también es parte del informe de
auditoría. Si las recomendaciones van más allá de las prácticas normales de la
 El ciclo de vida de la auditoría del proyecto 471

TABLA 12.3 Rendimiento frente a datos de referencia

Rendimiento de la oferta para el modelo "C"

Otorgar

Destino Tonelaje Oferta CCC Oferta modelo "C" Precio neto de la mina Ingresos CCC Ingresos del modelo "C"

D1-2 3800 X $ 4.11 $ 15,618

D1-7 1600 X 3,92 6.272

D2-7 1300 X 4.11 5.343

D3-2 700 X 5.13 3,591

D3-3 500 X 5.22 $ 2,610

D3-4 600 X 5.72 3.432

D3-5 1200 X 5.12 6.144

D3-6 1000 X 5.83 5.830

D4-6 700 X 4.88 3.416

D4-8 600 X 5.34 3.204

D5-1 500 X 3,54 1,770

D6-1 1000 X X 4.02–3.92 4.020 3.920

D6-2 900 X 4.35 3.915

D6-5 200 X 3,75 750

D6-6 800 X 3,17 2.536

D7-5 1600 X 5.12 8.192

D7-8 2600 X 5.29 13,754

D8-2 1600 X X 4.83 7728 7.728

D8-3 2400 X 4.32 10,368

Los ingresos totales $ 20,793 $ 99,348

Tonelaje total 4700 21.500

Red de mina promedio $ 4,42 $ 4.62

organización, necesitarán el apoyo del nivel de gestión de formulación de políticas. Este

apoyo debe buscarse y verificarseantes de se publican las recomendaciones. Si no se
recibe apoyo, las recomendaciones deben modificarse hasta que sean satisfactorias. La
Figura 12.1 es una página de un extenso y detallado conjunto de recomendaciones que
resultaron de un proyecto de evaluación realizado por una agencia privada de servicios
sociales.
6. Terminación de la auditoría del proyecto Al igual que con el proyecto en sí, una vez que la
auditoría haya cumplido su tarea designada, el proceso de auditoría debe terminarse. Cuando
se publiquen el informe final y las recomendaciones, habrá una revisión del proceso de
auditoría. Esto se hace con el fin de mejorar los métodos para realizar la auditoría. Cuando
finaliza la revisión, la auditoría está realmente completa y el equipo de auditoría debe
disolverse formalmente.
472 CAPÍTULO 12 Auditoría de proyectos

Informe final, evaluación de la agencia, planta física del

subcomité II, gestión de la oficina, prácticas de personal

Resumen de recomendaciones

Recomendaciones que requieren acción de la Junta.

1. La Junta de _______ debe continuar sus esfuerzos para obtener fondos adicionales para nuestra
partida salarial.

2. El costo de la cobertura de seguro de Blue Cross and Blue Shield para empleados individuales
debe ser asumido por _______.
Recomendaciones que pueden ponerse en práctica Orden presidencial a comités, personal
u otros.
3. El Comité de la Cámara debería activar, con primera prioridad, la sustitución del sistema de
calefacción / aire acondicionado. Además, este comité debe brindar asistencia y apoyo al
Secretario del Director Ejecutivo en los procedimientos de mantenimiento y reparación.
4. Se debe establecer una biblioteca profesional incluso si los trabajadores a tiempo parcial deben compartir espacio
para lograr esto.

5. Nuestras necesidades de seguros deben reevaluarse.

6. Todas las actividades relacionadas con la alimentación en las reuniones deben delegarse en alguien que no sea el
Secretario del Director Ejecutivo.

7. Opinión de la mayoría: los puestos de asistente administrativo y contable necesitarán más

tiempo en el futuro. Opinión minoritaria: los puestos de auxiliar administrativo, contable y
auxiliar estadístico deben combinarse.
8. El Comité de Prácticas de Personal debe revisar las descripciones de trabajo del Contador y
Asistente de Estadística y establecer rangos de salario para esos dos puestos y el de Asistente
Administrativo.
9. El diálogo entre el Director Ejecutivo, su secretaria y el Asistente Administrativo debe continuar
en un esfuerzo por agilizar los procedimientos de la oficina y agilizar el manejo del papeleo.

10. La descripción escrita del Comité de Prácticas del Personal debe incluir la membresía de un
representante del personal no profesional.
11. El Comité de Prácticas del Personal debe estudiar, con miras a la acción, la práctica del personal de trabajo de casos
a tiempo parcial versus a tiempo completo.

FIGURA 12.1 Ejemplos de recomendaciones para una agencia de servicios sociales.

12,4 Algunos elementos esenciales de una

auditoría / evaluación

Para que una auditoría / evaluación (en adelante, simplemente a / e) se lleve a cabo con habilidad y precisión,
para que sea creíble y generalmente aceptable para la alta dirección, el equipo del proyecto y el cliente, se
deben cumplir varias condiciones esenciales. El equipo de a / e debe ser seleccionado adecuadamente, todos
los registros y archivos deben ser accesibles y debe preservarse el contacto libre con los miembros del
proyecto.

El equipo de A / E

La elección del equipo de a / e es fundamental para el éxito de todo el proceso. Puede parecer
innecesario señalar que los miembros del equipo deben seleccionarse debido a su capacidad para
contribuir al procedimiento a / e, pero a veces los miembros se seleccionan simplemente porque son
 Algunos elementos esenciales de una auditoría / evaluación 473

disponible. El tamaño del equipo generalmente dependerá del tamaño y la complejidad del proyecto. Para un
proyecto pequeño, una persona a menudo puede manejar todas las tareas del a / e, pero para un proyecto
grande, el equipo puede requerir representantes de varios distritos diferentes. Las áreas típicas que pueden
proporcionar a los miembros del equipo son:

• El proyecto en sí, incluido el PM, el propietario del proyecto y el patrocinador del proyecto.
• La PMO o gerente de la oficina de programas
• El departamento de contabilidad / controlador
• Áreas de especialidad técnica
• El financiador
• El departamento de marketing
• Gerencia senior
• Compras / gestión de activos
• El departamento de personal
• El departamento de administración legal / de contratos

La función principal del equipo de a / e es realizar un examen minucioso y completo del proyecto o de
algún aspecto preespecificado del proyecto. El equipo debe determinar qué elementos se deben llamar la
atención de la gerencia. Debe presentar información y hacer recomendaciones de tal manera que maximice
la utilidad de su trabajo. El equipo es responsable de las observaciones constructivas y los consejos basados
en la formación y la experiencia de sus miembros. Los miembros deben mantenerse alejados de la
participación personal en los conflictos entre el personal del equipo del proyecto y de las rivalidades entre los
proyectos. El a / e es un proceso muy disciplinado, y todos los miembros del equipo deben someterse
voluntaria y sinceramente a esa disciplina.

Acceso a los registros

Para que el equipo de a / e sea eficaz, debe tener libre acceso a toda la información relevante para el
proyecto. Esto puede presentar algunos problemas en proyectos gubernamentales que pueden clasificarse
por razones de seguridad nacional. En tales casos, un subgrupo del equipo de a / e puede estar formado por
personas calificadas ("autorizadas").
La mayor parte de la información necesaria para un a / e provendrá de los registros del equipo
del proyecto y los de la Oficina de Gestión del Proyecto, y / o de varios departamentos como
contabilidad, personal y compras. Obviamente, la recopilación de datos es responsabilidad del equipo
a / e, y esta carga no debe pasarse al equipo de gestión del proyecto, aunque el equipo del proyecto
es responsable de recopilar los datos habituales sobre el proyecto y mantener los registros del
proyecto. -hasta la fecha durante la vida del proyecto.
Además de los registros formales del proyecto, parte de la información más valiosa proviene de
documentos anteriores al proyecto; por ejemplo, la correspondencia con el financiador que llevó a la RFP, las
minutas del Comité de Selección de Proyectos y las minutas de los comités de alta dirección que decidió
dedicarse a un área específica de interés técnico. Claramente, los informes de estado del proyecto, los
memorandos técnicos relevantes, las órdenes de cambio, la información sobre la organización del proyecto y
los métodos de gestión, y la información financiera y sobre el uso de recursos también son importantes. Es
posible que el equipo de a / e tenga que extraer gran parte de estos datos de otros documentos porque la
información requerida a menudo no está en la forma necesaria. La recopilación de datos requiere mucho
tiempo, pero un trabajo cuidadoso es absolutamente necesario para una a / e eficaz y creíble.
A medida que se recopila información, debe organizarse y archivarse de manera sistemática. Es
necesario desarrollar métodos sistemáticos para separar la información útil. Lo más importante es que se
necesitan reglas de detención para evitar que la recopilación y el procesamiento de datos continúen mucho
más allá del punto de rendimientos decrecientes. Deben establecerse prioridades para garantizar que
474 CAPÍTULO 12 Auditoría de proyectos

se realizan análisis importantes antes que los de menor importancia. Además, se necesitan
salvaguardias contra la duplicación de esfuerzos. El desarrollo cuidadoso de formularios y
procedimientos ayudará a estandarizar el proceso tanto como sea posible.

Acceso al personal del proyecto y a otros

El contacto entre los miembros del equipo de a / e y los miembros del equipo del proyecto, o entre el equipo
de a / e y otros miembros de la organización que tengan conocimiento del proyecto, debe ser gratuito. Una
excepción es el contacto entre el equipo de a / e y el financiador; tales contactos sonno hecho sin
autorización de la alta dirección. Esta restricción se mantendría incluso cuando el financiador esté
representado en el equipo de auditoría y también debería aplicarse a los clientes internos.
En cualquier caso, hay varias reglas que deben seguirse al contactar al personal del proyecto. Se
debe tener cuidado para evitar malentendidos entre los miembros del equipo de a / e y los miembros
del equipo del proyecto. El personal del proyecto siempre debe estar al tanto del a / e en curso. Deben
evitarse los comentarios críticos. Particularmente grave es la práctica de emitir opiniones y
comentarios sobre el terreno, improvisados, que pueden no ser apropiados o representar la opinión
de consenso del equipo de a / e.
Sin duda, el equipo de a / e encontrará oposición política durante su trabajo. Si el proyecto
es un tema de tensión política, las partes opuestas seguramente intentarán cooptar (o
repudiar) al equipo de a / e. En la medida de lo posible, deben evitar involucrarse. A veces, la
información se puede dar a los miembros del equipo de forma confidencial. Se deben hacer
intentos discretos para confirmar dicha información a través de fuentes no confidenciales. Si no
se puede confirmar, no se debe utilizar. El auditor / evaluador debe proteger las fuentes de
información confidencial y no debe convertirse en un conducto para críticas no verificables del
proyecto.

12,5 Medición
La medición es una parte integral del proceso de a / e. Muchos temas de qué y cómo medir se
han discutido en capítulos anteriores, particularmente en el Capítulo 2. Varios aspectos de un
proyecto que deben medirse son obvios y, afortunadamente, bastante fáciles de medir. En su
mayor parte, no es difícil saber si se ha completado un hito y cuándo. Podemos observar
directamente el hecho de que se han vertido los cimientos de un edificio, que se han recopilado
y entregado a la imprenta todos los materiales necesarios para un informe anual corporativo, o
que se han alquilado todos los contratos para la rehabilitación de un complejo de
apartamentos. A veces, por supuesto, la consecución de un hito puede no ser tan evidente.
Puede ser difícil saber cuándo ha terminado un experimento químico, y es casi imposible saber
cuándo un programa informático complejo finalmente está “libre de errores”.

De manera similar, el desempeño contra el presupuesto y el cronograma planeados generalmente no presenta

problemas importantes de medición. Puede que estemos un poco inseguros de si un tiempo de finalización
programado de “nueve días” debe incluir los días de fin de semana, pero la mayoría de las organizaciones adoptan
convenciones para aliviar estos problemas menores de conteo. Medir los gastos reales contra el presupuesto
planificado es un poco más complicado y depende de una comprensión profunda de los procedimientos utilizados
por el departamento de contabilidad. Es común imbuir los datos de costos con niveles más altos de realidad y
precisión de lo que se justifica.
Cuando los objetivos de un proyecto se han expresado en términos de ganancias, tasas de rendimiento
o flujos de efectivo descontados, como en los modelos de selección financiera discutidos en el Capítulo 2, los
problemas de medición pueden ser más obstinados. El problema no suele girar en torno a las convenciones
contables utilizadas, aunque si esas convenciones no se han establecido claramente
 Medición 475

establecido de antemano, puede haber amargas discusiones sobre qué costos se asignan
apropiadamente al proyecto individual que se está evaluando. Una tarea mucho más
difícil es determinar qué ingresos deben asignarse al proyecto.
Suponga, por ejemplo, que una empresa farmacéutica crea un proyecto para el desarrollo de un nuevo
fármaco y, al mismo tiempo, establece un proyecto para desarrollar e implementar una estrategia de
marketing para el nuevo fármaco potencial y dos fármacos aliados existentes. Suponga además que todo el
programa tiene éxito y se generan grandes cantidades de ingresos. ¿Cuántos ingresos deberían asignarse al
crédito del proyecto de investigación farmacológica? ¿Cuánto al proyecto de marketing? Dentro del proyecto
de marketing, ¿cuánto debería destinarse a cada uno de los subproyectos para los medicamentos
individuales? Si todo el programa se trata como un solo proyecto, el problema es menos grave; pero la I + D y
el marketing se encuentran en diferentes áreas funcionales de la organización matriz, y cada una puede
evaluarse sobre la base de su contribución a la rentabilidad de la empresa matriz. Las bonificaciones de fin
de año de los gerentes de división están determinadas en parte (a menudo en gran parte) por la rentabilidad
de las unidades que administran. La figura 12.2 ilustra los datos de referencia del proyecto establecidos para
un nuevo producto. Esta figura muestra el uso de múltiples medidas que incluyen

FIGURA 12.2 Datos de marketing de referencia para un nuevo producto.

476 CAPÍTULO 12 Auditoría de proyectos

precio, ventas unitarias, participación de mercado, costos de desarrollo, gastos de capital y otras medidas de
desempeño.
No existe una solución teóricamente aceptable para tales problemas de medición, pero hay soluciones
políticamente aceptables. Todas las decisiones de asignación de costos / ingresos deben tomarse cuando se
inician los diversos proyectos. Si se hace esto, las batallas se libran "por adelantado" y la equidad de las
asignaciones de costos / ingresos deja de ser un problema tan serio. Siempre que las asignaciones se
realicen mediante una fórmula, se evitan los conflictos mayores o, al menos, se mitigan.
Si se utilizan modelos de puntuación multiobjetivo en lugar de modelos financieros para la selección de
proyectos, los problemas de medición se agravan un poco. Hay más elementos para medir, algunos de los
cuales son objetivos y se miden con relativa facilidad. Pero algunos elementos son subjetivos y requieren
técnicas de medición razonablemente estándar para que las medidas sean fiables. Los métodos de
entrevistas y cuestionarios para la recopilación de datos deben elaborarse y llevarse a cabo cuidadosamente
si se quiere tomar en serio las puntuaciones del proyecto. Los pesos de los criterios y los procedimientos de
puntuación deben decidirse al inicio del proyecto.

Una nota para el auditor / evaluador

Un amable crítico y colega usa lo que él llama las "reglas de participación" para explicar a sus
estudiantes cómo programar entrevistas, realizar entrevistas, obtener copias, limitar el alcance de las
actividades y manejar las muchas tareas mundanas incluidas en los proyectos de auditoría /
evaluación. Si bien la frase "reglas de compromiso" nos parece un poco belicosa, tenemos algunos
consejos similares para el auditor / evaluador.
Por encima de todo, el a / e necesita "permiso para ingresar al sistema". Es difícil describir con precisión
lo que se quiere decir con esa frase, pero todo auditor o evaluador experimentado lo sabrá. La alta dirección
puede asignar a un individuo el trabajo de encabezar un equipo de auditoría / evaluación, pero esto no
implica automáticamente que el personal del proyecto aceptará a esa persona como un a / e legítimo. Habrá
varios indicadores si no se acepta el a / e. Las llamadas telefónicas del a / e se devolverán solo en momentos
en que el a / e no esté disponible. Las solicitudes de información serán aceptadas cortésmente, pero se
proporcionará poca o ninguna información, aunque lo serán las abundantes y sinceras disculpas y las
excusas semi creíbles. Las entrevistas con los miembros del equipo del proyecto serán extrañamente sin
contenido. Los intentos de determinar las metas auxiliares del proyecto no tendrán éxito, al igual que los
intentos de que los miembros del equipo discutan el conflicto intrateam. Todos serán bastante agradables,
pero de alguna manera las promesas de cooperación no se convierten en realidad. Siempre hay buenas
excusas y miradas de inocencia con los ojos muy abiertos.
Si el a / e es razonablemente agradable y mantiene una actitud tranquila y relajada, el equipo del
proyecto generalmente comienza a extender una confianza limitada. El primer paso habitual es permitir el
acceso calificado a / e a la información sobre el proyecto. De repente se encuentra información que falta en
los archivos oficiales del proyecto. A continuación, se le ha otorgado al a / e un permiso tentativo para
ingresar al sistema. Si el a / e maneja esta información con delicadeza, sin ignorar ni enfatizar las deficiencias
del proyecto y al mismo tiempo reconocer y apreciar las fortalezas del proyecto, se extenderá la confianza y
el permiso para ingresar al sistema ya no será tentativo.
La creación de confianza es un proceso lento y delicado que se frustra fácilmente. El a / e debe
comprender la política del equipo del proyecto y las relaciones interpersonales entre sus miembros y
debe tratar este conocimiento confidencial con respeto. Sobre esta base se construye la confianza y
se construye una auditoría / evaluación significativa. Hay una propensión casi universal para que el a /
e imite al sargento de Jack Webb. Viernes en el antiguo programa de televisión Dragnet: "Dígame los
hechos, señora". No es tan simple, ni los procesos que involucran a seres humanos son tan simples.

En el siguiente capítulo, pasamos al estado final del proceso de gestión de proyectos, la

terminación. Allí veremos cuándo terminar un proyecto y las diversas formas de llevar a cabo la
terminación.

Resumen
Este capítulo inició nuestra discusión de la parte final del texto,
terminación del proyecto. Un paso final importante en el proceso de
terminación es la evaluación del proceso y los resultados del
proyecto, también conocido como auditoría. Aquí analizamos los
propósitos de la evaluación y lo que debería abarcar: el proceso de
auditoría y las consideraciones de medición, las demandas impuestas
al auditor y la construcción y diseño del informe final.
Los puntos específicos hechos en el capítulo son:
• Los propósitos de la evaluación están dirigidos a metas,
ayudando al proyecto a lograr sus objetivos, y también
apuntan a lograr objetivos auxiliares no especificados, a veces
ocultos, pero firmemente sostenidos.
• El informe de auditoría debe contener al menos el estado actual del
proyecto, el estado futuro esperado, el estado de las tareas
cruciales, una evaluación de riesgos, información pertinente a otros
proyectos y cualquier salvedad y limitación.
Glosario
Auditoría Una investigación formal sobre algún tema o Evaluar Para establecer un valor o tasar.
aspecto de un sistema.
Análisis de riesgo Una evaluación de los resultados
Base Un estándar de rendimiento, comúnmente probables de una política y su probabilidad de
establecido desde el principio para comparaciones ocurrencia, generalmente realizada
posteriores.
Preguntas
Revisión de material Preguntas
1. Dé algunos ejemplos de objetivos de proyectos auxiliares.
2. ¿Cuándo se debe realizar una auditoría durante un proyecto? ¿Hay un
"mejor" momento?
3. ¿Qué ocurre en cada etapa del ciclo de vida de la auditoría?
4. ¿Qué elementos deben incluirse en el informe de estado de la auditoría?
5. ¿Qué acceso se requiere para una auditoría precisa?
6. ¿Por qué la medición es un problema particular en la auditoría?
7. ¿Qué es una "línea de base"?
8. ¿Cuál es el propósito de un análisis de riesgos?
9. ¿Cuáles son las condiciones esenciales de una auditoría creíble?
Preguntas 477
• La profundidad y el tiempo de la auditoría son elementos críticos de la auditoría
porque, por ejemplo, es mucho más difícil alterar el proyecto basándose en una
auditoría tardía que en una auditoría temprana.
• La difícil responsabilidad del auditor es ser honesto al presentar de
manera justa los resultados de la auditoría. Esto incluso puede requerir la
interpretación de datos en ocasiones.
• El ciclo de vida de la auditoría incluye el inicio de la auditoría, la definición de la
línea base del proyecto, el establecimiento de una base de datos, el análisis
preliminar del proyecto, la preparación de informes y la terminación.
• Se deben cumplir varias condiciones esenciales para una auditoría
creíble: un equipo de a / e creíble, suficiente acceso a los registros y
suficiente acceso al personal.
• La medición, en particular de los ingresos, es un problema especial.
para comparar dos o más escenarios o
políticas.
Preguntas para debatir en clase
10. En un proyecto típico, ¿cree que las evaluaciones breves frecuentes o las
evaluaciones importantes periódicas son mejores para establecer el
control? ¿Por qué?
11. ¿Cree que las evaluaciones de proyectos se justifican por sí mismas?
12. ¿Qué pasos se pueden tomar para aliviar la amenaza percibida para los
miembros del equipo de una evaluación externa?
13. ¿Qué retroalimentación, si la hubiera, debería recibir el equipo del proyecto de la
evaluación?
14. Durante la auditoría del proyecto, se puede perder una gran cantidad
de tiempo si no se adopta un método sistemático de manejo de la
información. Explique brevemente cómo se puede desarrollar este
método sistemático.
478 CAPÍTULO 12 Auditoría de proyectos

15. “La evaluación de un proyecto es otro medio de control del
proyecto”. Comentario.
dieciséis. ¿Por qué es mejor confiar en varias fuentes de información que
en unas pocas?
17. ¿Cuáles podrían ser algunas de las ventajas y desventajas de las
siguientes fuentes de información: (a) gráficos, (b) informes
escritos y (c) observación de primera mano?
19. ¿Qué tipo de informes se pueden enviar a los financiadores?
20. ¿Cuáles identificaría como las responsabilidades éticas de un
auditor?
21. Dada la gran variedad de elementos que debe evaluar un auditor, ¿qué
debería hacer el PM dado que la base de evaluación del proyecto estaba
claramente establecida en el plan del proyecto? ¿Qué pasa con los objetivos
auxiliares?

18. ¿Por qué es importante utilizar auditores externos en lugar de

auditores internos que estarían más familiarizados con la empresa y
el proyecto?

Incidentes para discusión

Servicios de pensiones de Gerkin Preguntas
¿Es este un buen uso de la técnica de auditoría? ¿Será de ayuda aquí? ¿Por
Dana Lasket fue la PM de un proyecto con el objetivo de determinar
qué o por qué no?
la viabilidad de trasladar una parte significativa de la capacidad
informática de Gerkin a otra ubicación geográfica. La finalización del
proyecto estaba prevista para 28 semanas. Dana había motivado al Empresa general de construcción naval
equipo del proyecto y, al final de la vigésima semana, el proyecto
General Ship Building tiene un contrato con el Departamento de Marina
estaba según lo programado.
para construir tres nuevos portaaviones durante los próximos 5 años.
La semana siguiente, durante una conversación informal durante un
Durante la construcción del primer barco, el PM formó un equipo de
almuerzo, Dana descubrió que el vicepresidente de finanzas tenía serias
auditoría para auditar el proceso de construcción de los tres barcos.
dudas sobre la validez de las suposiciones que el equipo estaba usando
Después de seleccionar a los miembros del equipo de auditoría, solicitó
para decidir qué computadoras debían reubicarse.
que desarrollaran un conjunto de requisitos mínimos para los proyectos y
Dana trató de convencerlo de que estaba equivocado durante dos
lo usaran como línea de base en la auditoría. Al revisar los documentos del
reuniones de seguimiento, sin éxito. De hecho, cuanto más hablaban, más
contrato, un miembro del equipo de auditoría descubrió una discrepancia
convencido estaba el vicepresidente de que Dana estaba equivocada. El
entre los requisitos mínimos del contrato y los requisitos mínimos de la
proyecto estaba demasiado avanzado para cambiar cualquier supuesto sin
Marina. Con base en sus hallazgos, le ha dicho al primer ministro que ha
causar retrasos importantes. Además, era probable que el vicepresidente
decidido ponerse en contacto con la oficina local de contratos de la Marina
heredara la responsabilidad de implementar los planes aprobados para la
e informarles del problema.
nueva ubicación. Por esas razones, Dana sintió que era esencial resolver el
desacuerdo antes de la finalización programada del proyecto. Dana solicitó
Preguntas
que se asignara un auditor del proyecto para auditar el proyecto,
prestando especial atención a las suposiciones hechas para identificar las Si fuera el primer ministro, ¿cómo manejaría esta situación? ¿Cómo se puede

computadoras que se moverán. asegurar un financiador de la finalización satisfactoria del contrato?

Proyecto de clase integradora continua

En este punto (o quizás si ha surgido un problema especial en el proyecto), ella misma o alguien ajeno al proyecto. Siga las pautas del capítulo
el Instructor debe hacer que el proyecto sea auditado. Los posibles para realizar la auditoría. Una alternativa es mostrar cómo el informe
auditores incluyen a los miembros de la clase que han terminado las del Historiador se relaciona con una evaluación completa posterior al
tareas del proyecto, el historiador, el instructor mismo o proyecto.
 Caso 479

Bibliografía
Baker, B. "En común". Diario de gestión de proyectos, Sep-
diciembre de 2007.
Corbin, D., R. Cox, R. Hamerly y K. Knight. “Gestión de proyectos
de revisiones de proyectos”.PM Network, Marzo de 2001.
Sangameswaran, A. "A Key to Effective Independent Project
Reviews". PM Network, Abril de 1995.
Schaefer, AG y AJ Zaller. "La auditoría de ética para
organizaciones sin fines de lucro".PM Network, Abril de 1998.
Shenhar, AJ, O. Levy y D. Dvir, "Mapeo de las dimensiones del éxito
del proyecto". Diario de gestión de proyectos, Junio de 1997.
Walker, MG y R. Bracey. “Auditoría independiente como control del
proyecto”.Datamación, Marzo de 1980.

El siguiente caso se refiere a un programa de desarrollo de misiles multifásico del Ejército de EE. UU. La primera fase
fue difícil, y seis pruebas de vuelo consecutivas terminaron en falla, y el contratista pagó millones de dólares en
multas por las fallas. Sin embargo, las siguientes dos pruebas fueron exitosas y el Pentágono decidió omitir una
tercera prueba planificada y pasar directamente a la siguiente fase del programa: desarrollo de ingeniería y
fabricación. Sin embargo, antes de hacerlo, se solicitó a la Oficina de Responsabilidad del Gobierno de EE. UU. Una
auditoría del progreso del programa hasta la fecha. El caso informa los problemas subyacentes revelados por la
auditoría y las lecciones aprendidas por los directores de programa.

Caso
proceso de desarrollo del interceptor y resultó en interceptores que
Defensa del área de gran altitud del teatro
no estaban equipados con instrumentos suficientes para
(THAAD): cinco fallas y contando (B)3 TomCross, Alan
proporcionar datos de prueba óptimos.
Beckenstein y Tim Laseter
• La garantía de calidad recibió un énfasis y recursos insuficientes
Era julio de 2004. John West y Joy Adams habían pasado por muchas cosas durante el tiempo de producción de los componentes, lo que resultó
desde que comenzó el programa THAAD en 1992. Se habían realizado once en componentes poco confiables.
pruebas de vuelo THAAD en la Fase de Definición del Programa y
• El contrato para desarrollar el interceptor era un contrato de
Reducción de Riesgos (PDRR). Después de seis fallas iniciales, la primera
costo más tarifa fija, un tipo de contrato que colocaba todo el
intercepción exitosa de misil a misil de un objetivo de misil balístico se
riesgo financiero del programa en el gobierno y no incluía
logró el 10 de junio de 1999, durante la Prueba de vuelo 10. West y Adams
disposiciones que pudieran usarse para responsabilizar al
reflexionaron sobre las lecciones del contrato que habían aprendido.
contratista por un desempeño inferior al óptimo. .

Las fallas en las pruebas de vuelo habían sido causadas principalmente

Estudio GAO — junio de 1999
por defectos de fabricación más que por problemas con la tecnología avanzada.
Los estudios realizados tanto por el Departamento de Defensa como por
Estos fracasos impidieron que el ejército demostrara que podía emplear de
fuentes independientes identificaron los siguientes problemas
manera confiable la tecnología de "golpear para matar" fundamental para el
subyacentes en el programa THAAD:
éxito de THAAD. El programa reestructurado abordó cada uno de los cuatro

• El programa comprimido de pruebas de vuelo del programa no permitió problemas subyacentes del programa. Eso

las pruebas en tierra adecuadas y, como resultado, los funcionarios no

pudieron detectar problemas antes de las pruebas de vuelo. El
cronograma también dejó tiempo insuficiente para las pruebas previas al
vuelo, el análisis posterior al vuelo y las acciones correctivas.
• El requisito de poder implementar rápidamente un sistema
prototipo temprano desvió la atención del contratista y la
administración del proyecto del gobierno de lo normal.
• alargó el programa de pruebas de vuelo y aumentó las pruebas en
tierra
• eliminó el requisito de los primeros interceptores prototipo
desplegables
• Aumentó el énfasis en la calidad del contratista, incluido su
compromiso, liderazgo y personal de aseguramiento de la calidad.

• modificó el contrato de costo más tarifa fija para proporcionar

3 Reimpreso con permiso Copyright de la fundación de la Escuela Darden incentivos y sanciones basados en el desempeño e introdujo
de la Universidad de Virginia, Charlottesville, VA. un grado de competencia en el programa.
480 CAPÍTULO 12 Auditoría de proyectos
A pesar de estos cambios, la confiabilidad de los interceptores de prueba
de vuelo restantes siguió siendo una preocupación porque la mayoría de los
componentes se produjeron cuando el sistema de garantía de calidad del
contratista era inadecuado.
Lecciones aprendidas sobre el desempeño de los contratos
• Los misiles THAAD PDRR aún no habían demostrado
ninguna capacidad militar. Adquirir una cantidad
significativa de misiles del diseño actual para respaldar un
concepto de despliegue de contingencia no fue prudente.
El hardware de los misiles restantes se había construido y
adquirido varios años antes, y solo se podían realizar
cambios o actualizaciones menores en el hardware
existente. Hasta que se construyó un nuevo hardware que
incorporó los cambios de diseño necesarios y procesos
mejorados de fabricación, garantía del producto y pruebas,
no había ninguna razón para esperar una mejora
significativa en el rendimiento del misil THAAD.
• La financiación y la orientación estables del programa fueron
fundamentales para el éxito del programa. Eso fue especialmente cierto
con un programa complejo de tecnología “de vanguardia” como THAAD.
Las presiones para presentar rápidamente un prototipo, los recortes
presupuestarios, la reestructuración del programa y la aplicación
incorrecta de los principios de la reforma de adquisiciones influyeron
fuertemente en las decisiones programáticas. La Oficina de
Administración de Programas y el contratista hicieron concesiones que
eran necesarias para cumplir con un presupuesto y un cronograma
impulsados por el requisito de implementación temprana del Sistema de
Evaluación Operativa del Usuario.
• Era necesario mejorar el diseño a nivel de los componentes, las pruebas
de calificación, los procesos de control de calidad y los procedimientos de
aseguramiento y prueba del producto en la fabricación del interceptor.
Las pruebas de calidad a nivel de componentes mejoradas para confirmar
tanto el diseño como la confiabilidad mejorarían en gran medida la
confiabilidad y proporcionarían una mayor confianza en el sistema y
subsistemas integrados de misiles.
• Era necesario realizar más pruebas de simulación en tierra y
hardware en el circuito del conjunto de misiles THAAD, y
especialmente del buscador. Debido a la fuerte influencia de DOT &
E, la Oficina de Administración de Programas había contratado un
equipo para revisar las capacidades de prueba del hardware en el
circuito del contratista y del gobierno. El equipo proporcionaría
recomendaciones sobre dónde se necesitaban mejoras para
permitir la prueba de misiles integrados de extremo a extremo y
para probar subsistemas críticos (por ejemplo, sistema de control de
actitud de desvío, buscador, paquete de aviónica, etc.).
Lecciones aprendidas en administración de contratos
• Un entorno sólido de trabajo en equipo (concepto de Battle Rhythm)
al principio del ciclo de vida del programa, incluidas todas las partes
interesadas de THAAD (DCMA, THAAD Program Office (TPO), el
contratista principal y los subcontratistas) fue fundamental para
resolver problemas potenciales antes de cualquier hito importante /
puntos de decisión de financiamiento. Esto dio como resultado un
entorno empresarial proactivo y orientado a la solución, donde los
problemas se identificaron con resolución en tiempo real.
• El contratista principal DCMA Commander necesitaba participar
pate activamente en el proceso de la tarifa de adjudicación, y las partes
interesadas de THAAD debían participar en el proceso de la tarifa de
adjudicación, para abordar los factores de riesgo del programa en ese momento,
según lo determina la Junta de tarifas de adjudicación, para enfocar los
esfuerzos de mitigación de riesgos del contratista para reducir el riesgo del
programa y para asegurar el éxito general de la misión.
• Utilización de un sistema de gestión de datos electrónicos para
proporcionar a todos los jugadores información en tiempo real de todos
los aspectos del programa, desde las modificaciones básicas del contrato
hasta los minutos de IPT y las matrices del programa, que habían sido
fundamentales para el éxito de la iniciativa Battle Rhythm.
El programa THAAD entró en la fase de desarrollo de ingeniería
y fabricación (EMD) en 2000, con la adjudicación de un contrato de
3.800 millones de dólares a Lockheed Martin Space Systems
Company. West y Adams habían utilizado las lecciones aprendidas del
contrato e incorporado incentivos únicos en el contrato de EMD
(Anexo 1).
Entre 2000 y 2003, los ingenieros de THAAD reelaboraron todo el sistema y
solucionaron muchos de sus problemas y redundancias inherentes. En mayo de
2004, comenzó la producción de 16 misiles de prueba de vuelo en las nuevas
instalaciones de producción de Lockheed Martin en el condado de Pike, Alabama.
Las pruebas de vuelo del sistema EMD estaban programadas para comenzar a
principios de 2005 y continuar hasta 2009. Se esperaba que el sistema entrara en
producción a baja tasa, para respaldar la capacidad operativa inicial (IOC) en
2007.
Luego, en la fase de desarrollo, THAAD estaba
implementando una estrategia de desarrollo de bloques
diseñada para poner el sistema THAAD en manos de
nuestros soldados lo más rápido posible, utilizando la última
tecnología de la manera más asequible. Cada bloque de dos
años (Bloque 2004, 2006 y 2008) se basó e integró con las
capacidades del bloque predecesor. El programa continuó
perfeccionando y madurando el diseño del sistema para
garantizar que el elemento se desempeñara a un estándar
aceptable y pudiera producirse de manera eficiente y
mantenerse. Esto se lograría mediante la continuación de las
actividades actuales de diseño y desarrollo de componentes,
pruebas sólidas en tierra y programas de garantía de
calidad. Las pruebas de vuelo se reanudarían a finales de
2004 en White Sands Missile Range,
Preguntas
1. ¿Cree que se trataba de una auditoría financiera, una auditoría de proyecto o una
auditoría de gestión? ¿Por qué?
2. ¿El propósito de la auditoría era ejercer control cibernético, control
pasa / no pasa o control posterior al proyecto? Explicar.
 Caso 481

Adquisición del ejército

ReformaBoletin informativo
Incentivos especiales para pruebas de vuelo exitosas
en el contrato de honorarios de adjudicación THAAD

El contrato de desarrollo de ingeniería y fabricación (EMD) de Theatre High Altitude Area Defense
(THAAD) por $ 3.8 mil millones se otorgó a Lockheed Martin Space Systems Company, Missile and Space
Operations (LMSSC / M & SO), Sunnyvale, CA, el 28 de junio de 2000. El El contrato THAAD EMD es un
contrato del tipo de tarifa de adjudicación. Las áreas de desempeño funcional son técnica, gerencial,
cronograma y costo.

Se hizo hincapié en la importancia de que las pruebas de vuelo se realicen según lo

programado y dentro de los costos al incluir en el contrato un conjunto de tarifas de adjudicación
con incentivos especiales para las interceptaciones de pruebas de vuelo exitosas para los
primeros dos intentos de vuelo en White Sands Missile Range (WSMR) y Kwajalein Missile. Rango
(KMR). Si Lockheed Martin logra una intercepción exitosa en los primeros dos intentos en WSMR,
recibirán $ 25 millones en tarifa de premio. Sin embargo, si no tienen éxito después del primer
intento, LM compartirá $ 15 millones del costo del contrato. Si Lockheed Martin logra una
intercepción exitosa en los primeros dos intentos de KMR, recibirán $ 25 millones en tarifa de
premio. Sin embargo, si no tienen éxito después del primer intento, LM compartirá $ 20 millones
del costo del contrato.

El uso del proceso de contratación alfa para el desarrollo del alcance del trabajo (SOW) y el Plan
Maestro y el Cronograma Maestro integrados, así como la preparación / evaluación de propuestas,
proporcionaron al gobierno un contrato de mejor valor. El Plan Maestro Integrado (IMP)
proporciona las narrativas del proceso, los eventos y los criterios para el programa EMD. El programa maestro
integrado (IMS) proporciona las tareas detalladas y el programa para implementar el IMP. Ambos documentos se
desarrollaron durante el proceso de contratación alfa, lo que redujo sustancialmente el tiempo normal de
negociación y promovió una mejor comprensión de los requisitos de EMD y
el enfoque propuesto por el contratista para cumplir con estos requisitos.

EXHIBICIÓN 1 Boletín de la reforma de adquisiciones del ejército.

3. Dados los comentarios en el caso, ¿supone que la razón de la 5. Dados los elementos mínimos de una auditoría de proyecto presentes
auditoría fue mejorar proyectos futuros o conocer las razones por en la Sección 12.2, ¿qué elemento (s) habrían sido primarios para el
las que no se cumplieron las metas del proyecto y, en caso de ser equipo de auditoría? ¿Por qué? ¿Qué sección habría contenido los
estas últimas, sus metas directas o auxiliares? "problemas subyacentes" informados en el caso?

4. ¿Cree que la GAO fue la mejor opción para un equipo de auditoría?

¿Contaría con la confianza del personal del proyecto?

La siguiente lectura muestra que las auditorías y evaluaciones de proyectos ayudan a ampliar el conocimiento sobre las buenas
prácticas de proyectos y mejoran la comprensión de los miembros de la organización sobre las funciones vecinas. Sin embargo,
la mayoría de las auditorías / evaluaciones actuales parecen ser superficiales, basadas en suposiciones ingenuas, y las
soluciones para las dificultades del proyecto tienden a ser superficiales. Sin embargo, las auditorías y evaluaciones fueron
experiencias de aprendizaje importantes y están infravaloradas en las organizaciones en términos de la información que
pueden proporcionar sobre una buena gestión de proyectos.
482 CAPÍTULO 12 Auditoría de proyectos
Leer
Una evaluación de las revisiones posteriores al proyecto4 JS Busby
Beneficios potenciales
Muchas organizaciones se propusieron realizar revisiones posteriores al
proyecto y por algunas razones de peso:
• Las personas no aprenden automáticamente de su propia
experiencia, ni siquiera como individuos aislados. Tienen que
poner a prueba nuevas experiencias con sus conocimientos
existentes y revisar esos conocimientos para aprender. Un
buen ejemplo es aprender sobre las personas. Puedes
encontrarte con una persona en varias ocasiones, pero no
aprendes de estas ocasiones en un sentido profundo hasta que
tomas una decisión sobre la persona (Eraut, 1994). Es en este
punto que reúne las diferentes experiencias que ha tenido y
saca algunas conclusiones coherentes. El resultado es que, si
quieres aprender de la experiencia, tienes que reflexionar
conscientemente sobre ella.
• El conocimiento de lo ocurrido suele estar disperso entre varias personas.
Hacemos muchas cosas, especialmente en organizaciones, donde los
resultados no son directamente observables. (Es posible que no sepamos,
por ejemplo, con qué facilidad los usuarios de nuestro nuevo diseño de
producto se adaptan a las demandas que se les hacen). Por lo tanto,
necesitamos consultar a otras personas para conocer los resultados de
nuestro desempeño.
• El conocimiento necesario para diagnosticar los resultados está
igualmente disperso entre varias personas. Por ejemplo, la gente
suele hacer suposiciones erróneas acerca de por qué otros fallan en
sus deberes, y estos conceptos erróneos deben corregirse si se
quieren identificar remedios razonables para tales fallas. Entonces,
nuevamente, si queremos aprender de la experiencia, debemos
hacerlo colectivamente.
• La difusión es importante, a menudo de forma crítica. Las
organizaciones rara vez son tan especializadas que todas las tareas
de tipo X siempre van al individuo A. Algunas organizaciones
parecen organizar las cosas de tal manera que las tareas siempre
van a las personas menos calificadas para realizarlas. Por lo tanto, lo
que una persona aprende al realizar un proyecto debe difundirse a
otras personas que podrían desempeñar funciones similares en el
futuro. Y, por supuesto, esta difusión no ocurre de forma natural.
Los errores repetidos son una característica de la vida
organizacional. Aprender de la experiencia dentro de una
organización tiene que ser una actividad pública y registrada.
En algunas organizaciones, las revisiones retrospectivas son una
parte natural e integral de sus operaciones; entre ellos se incluyen
organizaciones que gozan de gran prestigio, como las fuerzas aéreas
militares (Lipshitz, Popper y Oz, 1996).
4Reimpreso de Diario de gestión de proyectos, con permiso, Copy-
right Project Management Institute, Inc.
Posibles inconvenientes
Sin embargo, la realidad es que las revisiones posteriores al proyecto
a menudo se reducen y, a veces, caen en completo desuso. Incluso
cuando se llevan a cabo con entusiasmo, sus resultados no se
difunden bien. Las razones de esta negligencia incluyen:
• Llevan tiempo. Esto es especialmente un problema en las empresas
orientadas a proyectos, ya que los gerentes de proyectos quieren
minimizar los costos asignados a sus proyectos (particularmente hacia el
final), y los beneficiarios de las revisiones posteriores al proyecto son los
proyectos futuros, no los actuales.
• Las revisiones implican repasar los eventos por los que es probable
que los participantes del proyecto se sientan cínicos o
avergonzados. Esperar un nuevo trabajo es más atractivo.
• El mantenimiento de las relaciones sociales suele ser más importante para la
mayoría de las personas que un diagnóstico preciso de eventos aislados. Las
personas pueden mostrarse reticentes a participar en actividades que puedan
generar culpas, críticas o recriminaciones (Argyris, 1977).
• Mucha gente piensa que la experiencia es un maestro necesario y
suficiente por derecho propio. Según este punto de vista, si tienes
una experiencia, necesariamente aprenderás de ella, y si no has
tenido la experiencia, no aprenderás de otra persona que la haya
tenido. Intentamos sugerir anteriormente que esto no es así, pero
muchas personas creen que sí y están predispuestas a las revisiones
posteriores al proyecto. Entonces, la pregunta es, dadas las razones
convincentes de ambas partes, ¿debemos realizar revisiones
posteriores al proyecto? ¿Y cómo debemos llevarlos a cabo?
El estudio
Se estudiaron cuatro reuniones de revisión posteriores al proyecto en tres
empresas. Todos los proyectos involucrados en el estudio tenían valores
de varios cientos de miles a unos pocos millones de dólares, y todos
involucraron una extensa actividad de diseño y desarrollo de ingeniería.
Las tres empresas suministraron bienes de equipo a usuarios industriales,
aunque provenían de diferentes sectores: una en equipos eléctricos, una
en una planta de recubrimiento y una en maquinaria para productos de
precisión. Una de las empresas tenía la política de realizar siempre
revisiones posteriores al proyecto, pero las otras dos solo lo hacían de
forma intermitente.
Se realizaron análisis del discurso de las reuniones de revisión
posteriores al proyecto (Stubbs, 1983). Este tipo de análisis implica una
inspección detallada de lo que sucedió en las reuniones. Significa dividir las
transcripciones en pequeñas unidades de habla, típicamente oraciones, y
elaborar la estructura de la conversación que estas oraciones comprenden
en términos generales más que en términos particulares. La ventaja del
análisis del discurso es que brinda una imagen detallada y completa de lo
que realmente ocurre y genera evidencia bastante clara para cualquier
conclusión que extraiga. El inconveniente es que lleva mucho tiempo y no
se pueden cubrir muchas situaciones. Por lo tanto, las observaciones que
discutiremos más adelante en el artículo se basan en evidencia clara, pero
no podemos

afirma que verá lo mismo en las revisiones posteriores al proyecto en otras
organizaciones.
¿Cómo aprendió la gente?
Lo primero de interés fue cómo la gente, en conjunto,
aprende de las revisiones de proyectos.
Argumento dialéctico
Primero, los participantes solían recurrir a una forma dialéctica de
argumentación. Una persona daría voz a una explicación de algo, otra
volvería con una explicación contradictoria, y alguien encontraría una
tercera explicación que incorporara las dos anteriores, es decir, un caso de
tesis, antítesis y síntesis. Por ejemplo, en un caso, los participantes
intentaban explicar por qué se había perdido una reunión de traspaso.
Una persona pensó que la otra parte simplemente había ignorado una
solicitud de participación, la otra parte argumentó que había recibido una
notificación inadecuada de la reunión, y la síntesis era simplemente que
las dos partes no tenían conocimiento suficiente de las limitaciones de
tiempo de las otras. Este tipo de argumento refleja el hecho común de que
hay varios lados de un evento, y ninguna persona por sí sola tiene
suficiente información para considerar todos los lados del argumento. Una
persona puede argumentar un caso, otra puede argumentar lo contrario y
la reunión puede llegar a una conclusión sobre dónde se encuentra la
mejor explicación.
Ensayo del evento
En segundo lugar, se produjeron muchos ensayos o repeticiones mentales
de las secuencias de eventos. Por ejemplo, un caso común involucró a los
participantes que recordaron sus interacciones con los clientes sobre los
cambios sucesivos en los requisitos de diseño. Este tipo de repetición es un
proceso natural porque una de las pruebas de siA causado B es si lo
precedió, y construir una imagen de las secuencias de eventos, por lo
tanto, nos ayuda a inferir por qué las cosas sucedieron como sucedieron.
Dicho esto, hay dos salvedades. La primera es que, a pesar de la
importancia del tiempo y los plazos durante los proyectos, los
participantes de la revisión ensayaron verbalmente las secuencias de los
eventos, pero no compararon los tiempos con esos eventos. (Hubo un par
de excepciones a esto.) Y en segundo lugar, la precedencia es solo una
indicación parcial de causalidad y las personas son susceptibles de inferir
causalidad cuando no existe ninguna (Tversky y Kahneman, 1982).
Simulación mental
La tercera cosa que se observó fue que era muy común una especie de
simulación mental. Esta simulación casi siempre tomó la forma de
averiguar qué habría sucedido si las prácticas de las personas hubieran
sido diferentes. Por ejemplo, en un caso, los participantes de la revisión
razonaron sobre cómo el resultado habría sido diferente si hubieran
utilizado un proveedor diferente. Este tipo de simulación utilizó los
modelos mentales informales que tenían los participantes sobre cómo un
evento causó otro. Entonces, en el caso de razonar sobre el uso de un
proveedor diferente, un participante haría una declaración sobre cómo el
uso del proveedor alternativo habría significado una mayor necesidad de
coordinación de esfuerzos. Y otro participante luego argumentó que esto
habría dado lugar a una fecha límite incumplida ya que no había personal
disponible para realizar este esfuerzo.
La simulación es algo similar a la reproducción, excepto que
involucró eventos hipotéticos en lugar de eventos reales. El alcance
de esta simulación es significativo de varias formas. Para comenzar,
Leer 483
avanzar desde hacer algo hasta su resultado, llamado
razonamiento causal, es algo que sabemos que la gente prefiere
instintivamente a lo contrario, razonamiento diagnósticoTversky y
Kahneman, 1982). El razonamiento diagnóstico implica trabajar
desde algún resultado hasta la acción que lo causó. Las personas
generalmente tienen menos facilidad con el razonamiento
diagnóstico que con el razonamiento causal. El razonamiento causal
también puede ser más aceptable socialmente porque evita la
pregunta de quién hizo qué, concentrándose en cambio en lo que
sucedería si alguien hiciera otra cosa. El resultado de esto,
desafortunadamente, es una falta de diagnóstico profundo. En lugar
de rastrear la cadena, o red, de causas y efectos, la gente busca
posibles soluciones y trabaja para simular sus resultados.
Sin embargo, sería un error pintar la simulación como una
estrategia totalmente equivocada. En particular, hay un
beneficio secundario, ya que puede ayudarlo a aprender de muy
pocos ejemplos. Si tiene un número muy reducido de
experiencias por las que razonar, tal vez solo una, es difícil sacar
conclusiones fiables. Simulando lo que habría sucedido si las
cosas hubieran sido un poco diferentes, se puede ampliar
efectivamente la muestra de experiencias de las que sacar
conclusiones (March, Sproull y Tamuz, 1991).
Estructura de revisión
Las revisiones que se observaron difirieron en su estructura general.
En las dos empresas cuyas revisiones eran nuevas, la estructura de la
revisión coincidía con la estructura del proyecto. Los presidentes
dividieron el proyecto en etapas aproximadamente cronológicas,
pidieron a las personas que dijeran qué tan exitosos fueron los
resultados y los alentaron a averiguar por qué los menos exitosos
resultaron serlo. En la empresa que había tenido experiencia en la
realización de revisiones, el presidente pidió a las personas que
compilaran listas individuales de cosas buenas y malas que habían
observado sobre el proyecto, y luego animó a los participantes a
agruparlas bajo un conjunto de títulos comunes. Esta estructura se
adoptó porque la organización había descubierto con el enfoque
cronológico que las revisiones duraban demasiado. En nuestras
observaciones, los procesos de discusión que tuvieron lugar, y la
eficacia de los exámenes, parecía no tener relación con la estructura
general. Los éxitos y fracasos parecían ser comunes a las diferentes
estructuras. También se observó que la estructura prevista de las
revisiones se desviaba fácilmente. Los eventos están tan densamente
interconectados que los participantes a menudo tuvieron que pasar
de un tema a otro para reconstruir lo que sucedió porque se dieron
cuenta al examinar el primer tema de que otro era más importante.
La única característica que diferenciaba las reseñas, de una manera
que parecía importar, era la presencia de forasteros. El presidente de una
revisión había invitado a los directores de nuevos proyectos a asistir a la
revisión, que era una forma importante de difundir los resultados. No
hubo evidencia aparente de que la presencia de personas externas
inhibiera el funcionamiento de la revisión, pero sí significó que las
personas externas obtuvieron una comprensión bastante profunda de lo
que había tenido éxito y fracasado en el proyecto bajo revisión. No solo
vieron los titulares, sino que también vieron el razonamiento que condujo
a las conclusiones de la revisión y tuvieron una idea del contexto en el que
se había llevado a cabo el proyecto. Este sentido del contexto suele ser
vital para obtener una comprensión significativa de cómo las cosas tienen
éxito o fracasan.
484 CAPÍTULO 12 Auditoría de proyectos
Referencias históricas
Nuestra siguiente observación se refiere a cómo los participantes de la
revisión se referían a la historia. En principio, las referencias históricas
deben ser fundamentales para el proceso de diagnóstico. No puede saber
si un evento en un solo proyecto (como un terremoto o una quiebra) es
único, frecuente o sistémico a menos que examine otros proyectos
completados. De hecho, hubo pocas referencias históricas; sólo seis se
realizaron en 12 horas de reuniones de revisión. Los que había tenían tres
funciones distintas:
1. Usar eventos históricos como evidencia para alguna explicación de
eventos.
2. Demostrar que hubo algún cambio en la firma al
contrastar los eventos recientes con los históricos.
3. Explicar el comportamiento de las personas. (Por ejemplo, históricamente la
gente se había acostumbrado a trabajar de una manera particular y seguía
trabajando de esa manera incluso cuando se volvía menos apropiado).
Había No referencias históricas que simplemente ayudaron a las personas
a comprender si los eventos en el proyecto que se estaba revisando eran
sistémicos. Por lo tanto, podría argumentar que, como medio de aprender de
una experiencia específica, las revisiones posteriores al proyecto no se basaron
de manera efectiva en una experiencia más amplia.
¿Qué aprendió la gente?
Como era de esperar, parte del aprendizaje que tuvo lugar implicó la
diseminación del conocimiento de prácticas exitosas y no exitosas.
Por ejemplo, en una revisión, los gerentes de proyectos nuevos
pudieron escuchar acerca de las consecuencias de tener una sola
persona ejerciendo roles tanto técnicos como gerenciales.
Evidentemente fue una mala práctica. Es imposible saber, por
supuesto, si estos gerentes de nuevos proyectos reproducirían
realmente esas prácticas en circunstancias similares. Entonces solo
podemos decir que ha habido difusión de lo que se llama
conocimiento “proposicional”, conocimiento que, esencialmente, se
puede articular pero no necesariamente practicar.
Parte del conocimiento que se aprendió no fue tanto el conocimiento
de la tarea como el conocimiento que ayudó a las relaciones sociales. Por
ejemplo, la gente descubriría lo difícil que era el trabajo de otros,
entendería cuán severas eran las restricciones bajo las que otros operaban
y cuán difícil podría ser para otros ayudar. Conocer los puntos de vista de
otras personas es un tipo de conocimiento importante para los miembros
efectivos de las organizaciones y, evidentemente, no siempre se aprende
durante la actividad laboral normal.
Otro tipo de conocimiento importante fue la complejidad. Por
ejemplo, hubo varios casos en los que los participantes individuales
pensaron que sabían por qué había ocurrido algún evento, pero en
las revisiones descubrieron que la explicación estaba mucho más
confusa. El caso de una reunión de traspaso tardía ilustró esto: todos
habían tenido ideas diferentes sobre por qué había sido tarde, pero
todas resultaron ser demasiado simplificadas. Cada individuo
atribuyó el retraso a una sola causa, mientras que la realidad resultó
ser una combinación compleja de varias causas. Aunque este tipo de
aprendizaje, o realmentedesaprender, es tan bueno como cualquier
otro, la gente se siente menos feliz con él. Hace que sus modelos de
su mundo sean menos definidos y más
Complicado. Y generalmente significa que, contrariamente a lo
que podrían haber pensado, muchos problemas no tienen
remedio sencillo.
¿Cómo aprendió la gente?
La siguiente pregunta que se abordó en el análisis fue qué tan bien
fue el proceso de aprendizaje en las revisiones. Aunque pueda
parecer injusto hacerlo, nuestro enfoque fue buscar fallas y
limitaciones en el proceso de razonamiento que tuvo lugar. Es injusto
porque podría dar la impresión errónea de que el nivel general de
aprendizaje era deficiente. Lo hicimos porque es más fácil identificar
problemas que éxitos. También da pistas sobre cómo se pueden
mejorar las revisiones.
Problemas de atribución
Primero, las revisiones demostraron sesgo de atribución. Una
manifestación del sesgo de atribución es que los participantes en un
proceso tienden a sobreenfatizar el papel del medio ambiente y
subestimar su propia participación al explicar los resultados. Se podría
esperar que las reuniones de revisión tiendan a culpar a factores que
escapan al control de los participantes y a las partes no representadas en
las revisiones por problemas durante el proyecto. Nuestras observaciones
indicaron una fuerte tendencia a explicar los problemas refiriéndose a
otras partes. Sólo en dos ocasiones un individuo admitió un error o la
necesidad de cambiar una forma de trabajar. Dicho esto, de vez en cuando
un participante decía algo como "Está bien, el cliente era el problema, pero
¿había algo que pudiéramos haber hecho?" Es característico de los
individuos y empresas más exitosos tener un "locus de control interno"; es
decir, creer que los eventos están bajo su control, pues entonces dedican
esfuerzos a ejercer el control. Por lo tanto, es importante preguntar qué se
podría haber hecho para remediar un problema, incluso si cree que tuvo
causas externas.
Concreción excesiva
Es difícil proporcionar evidencia objetiva, pero el análisis al menos
sugirió que los participantes de la revisión eran demasiado
específicos en sus diagnósticos. Por ejemplo, ubicar un equipo en un
lugar donde era difícil de instalar y mantener se diagnosticó como un
deslizamiento. No se intentó determinar si reflejaba una dificultad
más general para visualizar problemas de instalación y
mantenimiento durante el diseño del equipo. Demasiada
especificidad significa pasar por alto problemas mayores, abordar
causas intermedias en lugar de básicas e implementar soluciones
que son demasiado elaboradas. Hubo muy pocos ejemplos de
generalización durante la revisión; muy pocas ocasiones en las que
los participantes preguntaron algo como "¿Es este un caso de un
problema mayor?" o "¿Nos falta algo más grande?"
En general, los participantes de la revisión fueron, por lo tanto, demasiado
concretos en sus diagnósticos. El resultado inevitable es estrictamente
aprendizaje incremental: el aprendizaje mediante pequeñas revisiones del
conocimiento actual en lugar de reemplazos al por mayor del mismo. El
resultado del aprendizaje incremental persistente es la incapacidad de
reaccionar a los grandes cambios en el entorno. No teníamos indicios de que
ninguna de las empresas se enfrentara actualmente a cambios tan grandes, pero
la mayoría de las organizaciones los afrontan en algún momento y habituarse al
aprendizaje incremental significa que no estarán en condiciones de afrontar
grandes cambios.

Diagnóstico superficial
Otra característica de las revisiones fue la ausencia de un
diagnóstico profundo. En la sección anterior se mencionó
que los participantes preferían el razonamiento causal
(razonamiento hacia adelante de causa a efecto) al
razonamiento diagnóstico (efecto a causa). También eran
muy reacios a pedir diagnósticos a otros. Nadie, durante el
transcurso de las revisiones, preguntó un diagnóstico "por
qué"; solo preguntaron aclarando "por qué", como en "¿por
qué fue pobre?" que significa "¿de qué manera era pobre?"
en lugar de "¿cuáles fueron las causas de que fuera pobre?"
La explicación en la última sección de la ausencia de
diagnóstico fue cognitiva, involucrando los estilos preferidos
con los que los individuos razonan. Probablemente se podría
agregar una convención social. Los participantes bien
podrían haber sido reacios a preguntar a los demás por qué
habían hecho algo porque estaban reacios a amargar sus
relaciones con ellos.
Organizaciones como las que se estudian aquí también promueven
fuertemente la norma de ser constructivos: los gerentes prefieren a las
personas que “acuden a ellos con soluciones, no con problemas”, y es
virtualmente una respuesta automática cuando se les pregunta sobre el
valor de la crítica decir que es importante "siempre que sea constructivo".
Esta norma significa que las personas se abstendrán de explorar las causas
detrás de un problema a menos que sepan que pueden proporcionar una
solución; no tanto porque sean intrínsecamente reacios a criticar, sino
porque saben que a otros en la organización no les parece bien criticar
gratuitamente.
Falta de datos
Otro problema que surgió del análisis fue la falta de referencia a datos de
resultados objetivos, especialmente costos y escalas de tiempo que no hubieran
sido difíciles de recopilar de los registros de las empresas. En algunos casos, los
participantes pasaron mucho tiempo tratando de recordar cuándo sucedieron
las cosas. En otros casos, existía una incertidumbre obvia sobre qué tan bien se
había desempeñado financieramente el proyecto. Ambas condiciones podrían
haber sido respondidas fácilmente con una pequeña investigación en el registro.
Dado que estos resultados son tan fundamentales para las ideas de la mayoría
de las personas sobre el éxito del proyecto, se podría argumentar que dichos
resultados deberían ser fundamentales para el proceso de revisión. Hubo una
ocasión en la que los costos estuvieron disponibles y fueron una parte
importante de la revisión. Esto implicó costos de remediación: es decir, los costos
necesarios para corregir errores o problemas en partes anteriores del proyecto.
Incluso allí, sin embargo, las cifras no eran claras porque los participantes
desconocían la base contable que las sustentaba. En cierto sentido, las
convenciones contables son irrelevantes para el diagnóstico de problemas de
proyectos, pero, cuando uno no sabe cuáles son, es difícil saber qué tan grandes
fueron los problemas que realmente se encontraron.
De hecho, durante las revisiones se hicieron muchas más referencias
a las prácticas que a los resultados. En lugar de examinar en qué medida,
digamos, los costos se desviaron del presupuesto y averiguar por qué, la
mayoría de las veces la gente examinó cómo trabajaban y si podrían
haberlo hecho mejor. Esto parece poner el carro delante del caballo, y uno
podría atribuirlo a los participantes principalmente técnicos que muestran
muy poca preocupación por los asuntos comerciales. Pero hay razones
para preocuparse más por las prácticas
Leer 485
que los resultados. En primer lugar, los resultados, como el
desempeño financiero, se determinan conjuntamente por las
actividades de los miembros del proyecto y el entorno en el que
trabajan. Esto significa que un desempeño financiero deficiente
no necesariamente indica malas prácticas. También significa que
lo que los miembros del proyecto tienen más control directo son
sus prácticas, no los resultados del proyecto. Por lo tanto, tienen
un incentivo natural para examinar las prácticas en lugar de los
resultados. En segundo lugar, los resultados globales de
empresas complejas como los proyectos generalmente brindan
una retroalimentación deficiente cuando se componen de
muchos tipos diferentes de actividades. Es como tratar de
aprender una habilidad compleja, como conducir, diciéndole
solo cuánto tiempo tomó su viaje completo. Para los
participantes de la revisión,
Errores de interpretación
Incluso cuando se hacía referencia a los resultados, las personas a veces
parecían cometer errores de interpretación. Por ejemplo, en un caso
resultó que la ubicación de un equipo era deficiente porque dificultaba el
mantenimiento del equipo. El equipo era pequeño, de bajo valor y
necesitaba relativamente poco mantenimiento, por lo que el problema se
descartó por ser muy pequeño y no dio lugar a más discusiones. Diríamos,
sin embargo, que este fácil despido comete el error de asumir que los
resultados menores reflejan causas menores. La cuestión de la capacidad
de mantenimiento es importante para los clientes en las industrias de
plantas industriales, a veces crítica. Este error interpretativo sugirió que los
ingenieros de la organización tenían muy poca conciencia del tema, tal vez
por falta de capacitación, falta de proceso formal, o la falta de
transferencia de conocimientos entre diferentes ingenieros. Nada de esto
fue explorado. Naturalmente, las organizaciones con tiempo y recursos
limitados prestan más atención a los grandes resultados, no a los
pequeños. El peligro de hacerlo de manera irreflexiva es que uno pasa por
alto los grandes problemas simplemente porque, en ocasiones aisladas,
no tienen grandes resultados. Sin embargo, más adelante, el resultado
puede ser importante y adverso; Un buen aprendizaje estimulado por un
resultado adverso menor podría generar grandes dividendos en el futuro.
¿Qué tan valioso fue?
Después de que se llevaron a cabo las revisiones, se entrevistó a los
participantes, durante unos 10 minutos cada uno, y el investigador habló
informalmente con los miembros de las otras revisiones inmediatamente
después de que terminaron. Ninguno de los participantes los descartó como
inútiles, pero ninguno brindó un apoyo incondicional a las revisiones. En
particular, existía escepticismo sobre cualquier perspectiva de que las revisiones
realmente tuvieran un efecto positivo. Parte de este escepticismo residía sin
duda en el cinismo de la gente hacia las organizaciones, condicionado por una
larga experiencia en actividades de gestión que no condujo a una mejora
evidente. Pero parte de ello radica en la naturaleza poco convincente de los
remedios que se exploraron en las revisiones. Dos de las revisiones se
apresuraron claramente hacia el final, por lo que los remedios recibieron solo un
tratamiento superficial. Sin embargo, incluso en los demás, no se analizaron los
remedios, sólo propuesto y brevemente impugnado. No se exploraron los
efectos secundarios y no se planificó la implementación. En el mejor de los casos,
solo hubo un reconocimiento en una de las revisiones de que alguien tendría que
irse y planificar los remedios en más
486 CAPÍTULO 12 Auditoría de proyectos
detalle. Dado que las intervenciones organizacionales tienen invariablemente
efectos secundarios desfavorables, y que su implementación es generalmente
prolongada y desordenada, la gente naturalmente será escéptica acerca de los
remedios que reciben sólo una atención superficial.
En total, existieron una serie de limitaciones en el proceso de
aprendizaje durante el curso de las revisiones. En secciones anteriores se
mencionó el descuido de la historia, la falta de generalización y la falta de
un diagnóstico profundo. Se acaba de mencionar el tratamiento superficial
dado a los remedios. Sin embargo, también resultó evidente a partir de los
análisis que estas revisiones tenían una serie de funciones importantes:
• Le dieron a las personas la oportunidad de demostrar su
preocupación por los objetivos de la organización.
• Ayudaron a las personas a corregir los conceptos erróneos que habían
aprendido en el curso de la actividad normal del proyecto.
• Le dieron a la gente la oportunidad de explicar y justificar sus
acciones de una manera que no siempre estuvo abierta a ellos
durante el proyecto.
• Sugirieron prácticas disponibles que no habían sido realizadas
por quienes podrían haberlas utilizado.
• Promovieron remedios colectivos y engendraron sentimientos de
compromiso con ellos. En ocasiones, los remedios fueron
descartados por su superficialidad, como se explicó, pero al menos
se expresaron colectivamente.
• Las revisiones tenían una función de difusión importante, aunque esto
requiere compartir los resultados de la revisión con personas externas. La
mayoría de los participantes de la revisión que han trabajado en el
proyecto bajo el microscopio dicen cosas como "Ya sabía X". Pero por lo
general no se les ocurre dar vueltas a otros proyectos contándole a la
gente acerca de X, tal vez porque no se dan cuenta de que X es
importante para los demás, no sabían que conocían a X hasta que se
señaló, o simplemente estaban demasiado ocupados para pensar en algo.
hacer con X. Cualquiera que sea el caso, las revisiones posteriores al
proyecto (siempre que invite a personas externas) ayudaron a X a salir. Sin
embargo, encontramos que las personas generalmente subestimaron la
función de difusión de las revisiones posteriores al proyecto.
¿Qué debe hacer usted?
Las deficiencias
Las tres mayores deficiencias en las revisiones que se estudiaron
fueron que las personas eran demasiado específicas, ahistóricas y no
diagnosticadas. Ser demasiado específico en su aprendizaje en
realidad se refiere a dos cosas diferentes. Una forma de ser
demasiado específico es tener una visión demasiado estrecha del
proceso sobre el que está aprendiendo. Si piensa en un proyecto de
ingeniería solo en términos de lo que el director del proyecto puede
afectar, por ejemplo, no se preguntará si hay algo que aprender
sobre, digamos, el proceso de asignación de directores de proyecto.
La otra forma de ser demasiado específico es ver lo que está
aprendiendo de manera demasiado literal. Si resulta que un producto
falla porque el grosor de la pared de una pieza diseñada era
insuficiente, podría diagnosticar esto como una falla al especificar el
grosor de pared adecuado.
con el ingeniero jefe. Pero podría ir a un nivel más general y diagnosticar
esto como una falla entre los diseñadores para comprender los extremos
del deber operativo que deben cumplir sus productos. A continuación,
podría pensar en soluciones para dar a los diseñadores una mayor
exposición a los clientes que utilizan sus productos. Ambos tipos de
sobreespecificidad hacen que el aprendizaje sea menos efectivo de lo que
debería ser. Por lo tanto, los mensajes intentan aprender sobre el sistema
más grande, no solo las actividades del día a día, y tratan de pensar en
fallas particulares como ejemplos de tipos más generales de fallas.
¿Cuánto piensa la gente sobre la historia? La respuesta parece
ser "no mucho", ya que sólo se produjeron seis referencias de
cualquier tipo a la experiencia histórica a lo largo de las revisiones. El
gran problema deno Al referirse a la historia es que no aprenderá
qué tipos de problemas son únicos y qué tipos son característicos o
sistémicos. Además, tendrá una confianza excesiva en cualquier
remedio que planee. Pero, habiendo dicho esto, la forma en que usa
la historia no es clara. Hay dos aforismos comunes sobre el
aprendizaje de la historia que parecen contradecirse: uno es "No hay
nada nuevo bajo el sol" y el otro es "La historia nunca se repite". El
primero sugiere que conocer la historia es esencial porque el futuro
se parecerá a ella. El segundo sugiere que conocer la historia es
peligroso porque puede estar atrapado en la creencia de que el
futuro será el mismo que el pasado. El punto importante es mirar la
historia en el nivel correcto de generalidad. Su próximo desarrollo de
producto será único porque en todos sus detalles diferirá en muchos
aspectos de los desarrollos anteriores. Al mismo tiempo,
simplemente no podría hacerlo si fuera completamente único.
Todavía tienes que pasar por procesos muy similares, lidiar con
procesos muy similarestipos de objetos, etc.
Finalmente, el diagnóstico verdadero estuvo en su mayoría ausente.
¿Por qué, dado el grado en que se alienta a las personas a adoptar análisis
de causa-efecto, diagramas de espina de pescado, dispositivos de
resolución de problemas, etc., no practican el diagnóstico causal? Al igual
que con otros asuntos, puede tomar su explicación de la psicología
individual o del comportamiento organizacional. La explicación psicológica
tiene que ver con la distinción entre razonamiento causal y razonamiento
diagnóstico que se mencionó anteriormente. Los individuos simplemente
parecen encontrar más fácil razonar de causa a efecto que viceversa. La
explicación organizativa es que la mayoría de la gente considera que es un
requisito social evitar la crítica directa entre ellos, especialmente si tienen
que mantener algún tipo de relación a largo plazo. La mayoría de las
personas no van a sacrificar las buenas relaciones a largo plazo en aras de
uno o dos diagnósticos precisos de eventos que no se pueden deshacer. Y
probablemente hayan llegado a su propio diagnóstico privado de eventos
de todos modos, y no ven la necesidad de un diagnóstico colectivo. El
hecho de que el diagnóstico colectivo pueda ser mejor que el privado
puede que ni siquiera se les ocurra. Además, es una norma social ser
constructivo, enfatizando la búsqueda de mejores caminos en lugar del
diagnóstico de un mal camino. Desafortunadamente, la consecuencia de
toda esta evasión muy razonable del diagnóstico profundo es una
comprensión superficial y, muy probablemente, remedios incorrectos que
tratan los síntomas en lugar de las causas. Las autopsias ineficaces, como
las personas ineficaces, evitan el conflicto en nombre de fines a largo
plazo, pero, en última instancia, sacrifica los fines a largo plazo por la
comodidad a corto plazo. Conseguir que una organización haga lo
contrario (perseguir fines a largo plazo y soportar la falta de

comodidad a corto plazo) es en última instancia una prueba de liderazgo,
coraje moral, persuasión y voluntad.
Recomendaciones
Recomendamos las siguientes "consignas" para los asesores de
revisión:
1. Fomente el diagnóstico profundo. Utilice diagramas de causa-efecto si es probable
que le sirvan de ayuda.
2. Fomente la atención a la historia. Pregunte si históricamente han
ocurrido cosas similares.
3. Fomente el examen del sistema más grande más allá de los
límites inmediatos del proyecto.
4. Desaliente la categorización simplista. Hay poco que no pueda
atribuirse a “problemas de comunicación” en proyectos complejos,
pero categorizar algo de esta manera es solo un punto de partida
para el diagnóstico, no un punto final. Es fácil señalar como un
problema de comunicación, por ejemplo, dos personas que hacen
suposiciones diferentes sobre quién tiene la responsabilidad de una
acción en particular. Un diagnóstico adecuado examinaría cómo
surgen los diferentes supuestos y por qué persisten incluso cuando
conducen a errores.
5. Planifique los remedios correctamente examinando los efectos secundarios
y pensando en la implementación. Si esto tiene que ser objeto de una
segunda reunión, que así sea. Los presidentes deben tener la madurez
para darse cuenta de que los remedios sugeridos pero no planificados
simplemente profundizarán el cinismo de los participantes de la revisión.
6. Invite a personas externas clave a realizar revisiones posteriores al proyecto
para ayudar en la difusión. En una de las revisiones que estudiamos, se
invitó a gerentes de nuevos proyectos, y esto probablemente fue mucho
más efectivo en la difusión que lo que hubieran sido los resúmenes
escritos. Los resúmenes escritos tienden a escribirse desde el punto de
vista de una sola persona, por lo que a menudo uno no sabe cuán
polémicos eran ciertos temas. Y estos resúmenes a menudo carecen de los
detalles de los que depende la adopción de una nueva práctica.
La mayoría de la gente probablemente consideraría tales prácticas
como de sentido común. Por lo tanto, es importante tener en cuenta que
estas prácticas a menudo no se materializaron, incluso entre las personas
altamente inteligentes, conocedoras y reflexivas que realizaron las
revisiones que estudiamos.
Leer 487
Resumen
En general, a la luz de este estudio, nos pronunciaríamos firmemente
a favor de las revisiones posteriores al proyecto (siempre que no las
llame “autopsias”). Pudimos detectar fallas en las que vimos, pero
aún eran valiosas. Y la mayoría de las organizaciones con las que
trabajamos no las habían dirigido antes, por lo que juzgarlas por ser
las primeras no sería razonable. Este estudio, aunque limitado, señala
la dirección para investigaciones adicionales en esta importante área
de la gestión de proyectos.
Referencias
Argyris, C. (1977, septiembre-octubre). Aprendizaje de doble ciclo en
las organizaciones.Harvard Business Review, 115-125.
Eraut, M. (1994). Desarrollar conocimientos profesionales y
Competencia (pag. 51). Londres: Falmer Press.
Lipshitz, R., Popper, M. y Oz, S. (1996). Construir organizaciones
de aprendizaje: el diseño e implementación de organizaciones
Mecanismos de aprendizaje tradicionales. Revista de comportamiento aplicado
Ciencias, 32 (3), 292-305.
March, JG, Sproull, LS y Tamuz, M. (1991). Aprendiendo de
muestras de uno o menos.Ciencias de la Organización,
2 (1), 1-13.
Stubbs, M. (1983). Análisis del discurso. Oxford: Basil Blackwell.
Tversky, A. y Kahneman, D. (1982). Esquemas causales en juicios
bajo incertidumbre. En D. Kahneman, P. Slovic y A.
Tversky (Eds.), Juicio bajo incertidumbre: heurística y
Sesgos (págs. 117-128). Prensa de la Universidad de Cambridge.
Preguntas
1. ¿Por qué cree que las organizaciones tienden a ignorar las evaluaciones posteriores al
proyecto?
2. ¿Cómo se podría implementar el concepto de hacer que tales evaluaciones
sean obligatorias?
3. Evaluar sus consejos para realizar evaluaciones posteriores al proyecto.
4. ¿Cómo afecta la comprensión de cómo aprenden las personas a las auditorías
y evaluaciones de proyectos?
5. ¿Cómo puede un auditor / evaluador evitar las deficiencias descritas en
el artículo?
6. Resume las recomendaciones del autor.