Introducción

El desarrollo de la tecnología y la complejidad de los negocios, ha incrementado la

dificultad de la administración de los proyectos, esto genera un entorno complejo de
operación de los proyectos donde de una gestión efectiva depende el éxito o fracaso
de los mismos.
Los proyectos frecuentemente se ven retrasados o sobrepasan lo presupuestado
inicialmente, además de que los clientes o usuarios generalmente se muestran
insatisfechos con la calidad de los resultados. Es por esto que no es de sorprender
que por ejemplo las organizaciones que desarrollan proyectos de software busquen
activamente nuevas maneras de mejorar su desempeño (Boyd, 2001 p.53;
Mathiassen & Pourkomeylian, 2003, p.63).
Por otro lado la necesidad de poder administrar un número cada vez más grande de
proyectos con características variables y disruptivas, con proyectos en diferentes
fases dentro de su ciclo de vida, presenta nuevos y difíciles retos en las
organizaciones (Dooley, Lupton & O'Sullivan, 2005, p.466).
Ante tales necesidades, algunos de los esfuerzos que las organizaciones
generalmente tratan de implementar para mitigar fallas y mantener control de sus
proyectos, son los siguientes (Boyd, 2001, p.423):
- Mejora de la Administración de Proyectos
- Estudios de Factibilidad
- Involucrar a sus clientes
- Buscar asesoría externa

Cualesquiera que sean las respuestas de la administración de los proyectos, estas no

pueden ser efectivamente determinadas sin la identificación de las deficiencias,
carencias, riesgos o necesidades de mejora específicas.
En este sentido, la experiencia, capacidades y habilidades de los líderes de
administración de proyectos son fundamentales para una adecuada administración;
sin embargo, siempre es conveniente complementar su gestión con elementos
sistemáticos tales como:
- Las metodologías de administración de proyectos
1
 - Las técnicas y herramientas aplicables
El presente trabajo escrito profesional, pretende abordar dentro de este último
aspecto, el tablero de control como una herramienta para la toma de decisiones
durante el ciclo de vida de los proyectos, identificando los aspectos estratégicos,
operacionales y operativos que tal herramienta de control debe considerar para la
obtención de información valiosa y que contribuya a la toma de decisiones oportuna.
Todo lo anterior, a través de la investigación de fuentes de información impresas y
electrónicas tales como:
 Tesis, Libros, manuales y metodologías del área de administración de
proyectos.
 Artículos en revistas especializadas de administración de proyectos
 Páginas web oficiales de administración de proyectos.
 Bases de datos para investigación relacionadas con las ciencias sociales
disponibles en BIDI UNAM Y CONRICYT.
El presente trabajo escrito se divide en 3 secciones principales en las cuales se
abordará la siguiente temática:
1) La administración de proyectos. En esta sección se identificarán definiciones
generales de proyectos y de Administración de Proyectos, Identificando como
ésta última se ha constituido en una disciplina de estudio y asimismo cuál es su
relación con la Administración General; en este misma sección se describe el
ciclo de vida de los proyectos para obtener un entendimiento general del
desarrollo de los mismos.
2) Estándares y metodologías de administración de proyectos.Parte esencial en la
ejecución de la Administración de Proyectos la constituyen los estándares y
principios de aplicación general en los proyectos que expertos en esta materia
han identificado para conformar el marco normativo que guía a los líderes y
equipos de trabajo hacia la consecución exitosa de los objetivos de un proyecto
y de la misma gestión de los proyectos.
3) Tableros de control dentro de la administración de proyectos. En esta sección
se aborda la principal temática del presente trabajo, en la cual se describe al
tablero de control como una herramienta para la toma de decisiones en

2
 cualquier proyecto. Se identifican entonces, los tipos de tableros de control y
las sugerencias que los profesionales en esta materia aportan para la
adecuada utilización de dicha herramienta en beneficio de una correcta
ejecución de la administración de proyectos.
1. LA ADMINISTRACIÓN DE PROYECTOS
El origen de la administración de proyectos se remonta a los años 1950 y 1960 por los
logros de la ingeniería, particularmente en los sectores militares y de defensa
(Habermas, 1997, p. 38).
Los primeros teóricos en relación a la administración de proyectos, estaban
convencidos de que los proyectos fueron diseñados para servir al progreso y asegurar
la controlabilidad. Esta sigue siendo la visión dominante de la administración de
proyectos. La Administración de proyectos moderna hace énfasis en la planificación y
control de proyectos y, por lo tanto, el establecimiento de objetivos claros y las
limitaciones al principio del proyecto.
La Administración de proyectos tiene como objetivo optimizar el triangulo: tiempo,
costo y calidad, orientado a la racionalidad y el capitalismo, y a las formas más
eficientes para lograr los objetivos y dar beneficios en el contexto de una economía
competitiva de mercado (Gauthier, 2012, p.8).
Ha habido un largo debate en la comunidad académica de administración en cuanto a
si la "administración de proyectos" es una práctica o una disciplina académica. En lo
que respecta al ámbito de negocio y de Administración, los estudiosos suelen
aparecer desconcertados y poco convencidos de la noción de "administración de
proyectos" (Kwak y Anbari, 2009, p. 435).
Jacques-Bernard Gauthier., afirma que la falta de consenso entre los investigadores
sobre los términos "proyecto" y "administración de proyectos"; se debe a que los
diversos autores tienen diferentes perspectivas ontológicas. Además de esto, los
significados de proyecto y administración de proyectos pueden reflejar un periodo
histórico en el ámbito social (Premoderno, moderno, postmoderno e hipermoderno).
A pesar del debate no resuelto sobre la Administración de proyectos como un campo
de investigación y disciplina, Gauthier (2012, p.7) sostiene:

3
Si la administración de proyectos está para ser una verdadera disciplina científica con
sus propios derechos, primero tiene que haber una asunción explícita o tácita de que
hay un objeto de estudio, dicho de otra forma, un proyecto, un constructo del cual los
investigadores de administración de proyectos puedan hacer uso para efectos
analíticos (Anagnostopoulos, 2004, p.251; Söderlund, 2004, p. 183), en segundo
lugar, debe haber una serie de compromisos ontológicos o presuposiciones, lo que
Lakatos (1970, p. 91) acuñó como el “núcleo duro” (hard core por su traducción al
inglés) de cualquier ciencia. Anagnostopoulos (2004, p.251) señaló: "Si tal núcleo
duro existe en un programa de investigación sobre administración de proyectos,
entonces el proyecto y su administración son los dos candidatos miembros más
elegibles de dicho programa."
Por ello, una doble pregunta merece toda la atención: ¿Qué es un proyecto y, en
consecuencia, que es la administración de proyectos? (Anagnostopoulos, 2004,
p.251); Blomquist y Lundin, 2010 p.10; Morris, 2010, p.139).

1.1 Definiciones de Proyectos

Para efecto de observar las principales características de los proyectos iniciaremos
con las definiciones de diversos autores:
“Un proyecto es un esfuerzo de carácter temporal; con el objetivo de
producir un producto, servicio o resultado único; tienen un inicio y una
finalización definidos; se completan cuando sus metas y objetivos se
han alcanzado” (PMBOK® Guide, 2008, p.5).
“Un proyecto es una unidad de organización dedicada al logro de un
objetivo – La conclusión exitosa de un producto de desarrollo en
tiempo, dentro del presupuesto, de conformidad con especificaciones
de desempeño predeterminadas.” (The Enciclopedya of Management,
1973, p.803)
La ejecución de los proyectos por lo general formarán parte de un proyecto
mayor o de las estrategias de una organización o entidad, por lo que
pertinente considerar la definición de proyectos expuesta por David L. Cleland
y Lewis R. Ireland (2006, p.51):

4
 Un proyecto es una combinación de recursos organizacionales
reunidos para crear algo que no ha existido previamente y que
proveerá de capacidad de desempeño en el diseño y ejecución de las
estrategias organizacionales. Los proyectos tienen un ciclo de vida,
iniciando con una idea y progresando mediante el diseño, ingeniería y
fabriación o construcción, a través del uso de un propietario del
proyecto. Cuatro consideraciones están siempre involucradas en un
proyecto:
 Cuál es el costo?
 Cuanto tiempo es requerido para su realización?
 Que capacidad de desempeño técnico proveerá?
 Cómo los resultados del proyecto concuerdan con el diseño y
ejecución de las estrategias organizacionales?
Las preguntas arriba descritas deben ser resueltas paca cada
proyecto que una organización considera, el contexto de las
estrategias en el corto y largo plazo. En este sentido, la
administración de proyectos tendrá una interdependencia con la
administración estratégica.
1.2 Ciclo de vida de los proyectos
Para facilitar la gestión, los directores de proyectos o la organización pueden dividir
los proyectos en fases, con los enlaces correspondientes a las operaciones de la
organización ejecutante. El conjunto de estas fases se conoce como ciclo de vida del
proyecto. Muchas organizaciones identifican un conjunto de ciclos de vida específico
para usarlo en todos sus proyectos.
El ciclo de vida del proyecto define las fases que conectan el inicio de un proyecto con
su fin. Por ejemplo, cuando una organización identifica una oportunidad a la cual le
interesaría responder, frecuentemente autoriza un estudio de viabilidad para decidir si
se emprenderá el proyecto. La definición del ciclo de vida del proyecto puede ayudar
al director del proyecto a determinar si deberá tratar el estudio de viabilidad como la
primera fase del proyecto o como un proyecto separado e independiente. Cuando el
resultado de dicho esfuerzo preliminar no sea claramente identificable, lo mejor es
5
tratar dichos esfuerzos como un proyecto por separado. Las fases del ciclo de vida de
un proyecto no son lo mismo que los Grupos de Procesos de Dirección de Proyectos.
Las fases del ciclo de vida de un proyecto son:
 Inicio
 Planificación
 Ejecución
 Cierre del proyecto.
La transición de una fase a otra dentro del ciclo de vida de un proyecto generalmente
implica y, por lo general, está definida por alguna forma de transferencia técnica.
Generalmente, los productos entregables de una fase se revisan para verificar si
están completos, si son exactos y se aprueban antes de iniciar el trabajo de la
siguiente fase. No obstante, no es inusual que una fase comience antes de la
aprobación de los productos entregables de la fase previa, cuando los riesgos
involucrados se consideran aceptables. Esta práctica de superponer fases, que
normalmente se realiza de forma secuencial, es un ejemplo de la aplicación de la
técnica de compresión del cronograma denominada ejecución rápida.
No existe una única manera, que sea la mejor, para definir el ciclo de vida ideal de un
proyecto. Algunas organizaciones han establecido políticas que estandarizan todos
los proyectos con un ciclo de vida único, mientras que otras permiten al equipo de
dirección del proyecto elegir el ciclo de vida más apropiado para el proyecto del
equipo. Asimismo, las prácticas comunes de la industria a menudo conducen a usar
un ciclo de vida preferido dentro de dicha industria.
Los ciclos de vida del proyecto generalmente definen:
• Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué fase se
debe realizar el trabajo del arquitecto?)
• Cuándo se deben generar los productos entregables en cada fase y cómo se revisa,
verifica y valida cada producto entregable.
• Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente requiere
que los implementadores estén involucrados en las fases de requisitos y de diseño)
• Cómo controlar y aprobar cada fase.

6
Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy
detalladas. Las descripciones muy detalladas de los ciclos de vida pueden incluir
formularios, diagramas y listas de control para proporcionar estructura y control. La
mayoría de los ciclos de vida de proyectos comparten determinadas características
comunes:
 En términos generales, las fases son secuenciales y, normalmente, están
definidas por alguna forma de transferencia de información técnica o transferencia
de componentes técnicos.
 El nivel de coste y de personal es bajo al comienzo, alcanza su nivel máximo en
las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su
conclusión.
• El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con
los objetivos es más elevado al inicio del proyecto. La certeza de terminar con éxito
aumenta gradualmente a medida que avanza el proyecto.
• El poder que tienen los interesados en el proyecto para influir en las características
finales del producto del proyecto y en el coste final del proyecto es más alto al
comienzo y decrece gradualmente a medida que avanza el proyecto.
Una de las principales causas de este fenómeno es que el coste de los cambios y de
la corrección de errores generalmente aumenta a medida que avanza el proyecto.
Aun cuando muchos ciclos de vida de proyectos tienen nombres de fases similares y
requieren productos entregables similares, muy pocos ciclos de vida son idénticos.
Algunos tienen cuatro o cinco fases, pero otros pueden tener nueve o más. En una
misma área de aplicación pueden darse variaciones significativas. El ciclo de vida del
desarrollo de software de una organización puede tener una única fase de diseño,
mientras que otro puede tener fases separadas para el diseño arquitectónico y el
detallado.
Los subproyectos también pueden tener distintos ciclos de vida de proyectos. Por
ejemplo, una empresa de arquitectura contratada para diseñar un nuevo edificio de
oficinas participa primero en la fase de definición del propietario, mientras hace el
diseño, y luego en la fase de implementación del propietario, mientras da soporte al
esfuerzo de construcción. El proyecto de diseño del arquitecto, sin embargo, tendrá su
7
propia serie de fases, desde el desarrollo conceptual, pasando por la definición e
implementación, hasta llegar a la conclusión. El arquitecto puede, inclusive, tratar el
diseño de los edificios y el soporte a la construcción como proyectos separados, cada
uno con su propio conjunto de fases. También podemos ver en la grafica siguiente,
como se relacionan las fases del ciclo de vida de un proyecto, con las personas que
intervienen en él y su impacto en el coste del proyecto.

Figura 1-1 Gente con la habilidad de influir en los costos1

Fuente: PMBOK 2005

Igualmente lo podemos ver como según cambiamos de fase en un proyecto, se
elevan los costos de los posibles cambios y por ende se reduce la posibilidad de
reducirlos dentro del proyecto.
Figura 1-2 Análisis del ciclo de vida de un proyecto

Fuente: PMBOK 2005

8
La conclusión y la aprobación de uno o más productos entregables caracteriza a una
fase del proyecto. Un producto entregable es un producto de trabajo que se puede
medir y verificar, tal como una especificación, un informe del estudio de viabilidad, un
documento de diseño detallado o un prototipo de trabajo. Algunos productos
entregables pueden corresponder al mismo proceso de dirección de proyectos,
mientras que otros son los productos finales o componentes de los productos finales
para los cuales se creó el proyecto. Los productos entregables, y en consecuencia
las fases, son parte de un proceso generalmente secuencial, diseñado para asegurar
el adecuado control del proyecto y para obtener el producto o servicio deseado, que
es el objetivo del proyecto.
En cualquier proyecto específico, las fases se pueden subdividir en subfases en
función del tamaño, complejidad, nivel de riesgo y restricciones del flujo de caja. Cada
subfase se alinea con uno o más productos entregables específicos para el
seguimiento y control. La mayoría de estos productos entregables de las subfases
están relacionados con el producto entregable de la fase principal, y las fases
normalmente toman el nombre de estos productos entregables de las subfases:
requisitos, diseño, construcción, prueba, puesta en marcha, rotación, entre otros,
según corresponda.
Por lo general, una fase del proyecto concluye con una revisión del trabajo logrado y
los productos entregables, a fin de determinar la aceptación, tanto si aún se requiere
trabajo adicional como si se debe considerar cerrada la fase. Con frecuencia, la
dirección lleva a cabo una revisión para tomar una decisión a fin de comenzar las
actividades de la siguiente fase sin cerrar la fase actual, por ejemplo, cuando el
director del proyecto elige la ejecución rápida como curso de acción. Otro ejemplo es
cuando una compañía de tecnología de la información elige un ciclo de vida iterativo
donde más de una fase del proyecto puede avanzar de forma simultánea. Los
requisitos de un módulo se pueden recopilar y analizar antes de que el módulo sea
diseñado y construido. Mientras se lleva a cabo el análisis de un módulo, se puede
comenzar a recopilar los requisitos de otro módulo de forma paralela.
Del mismo modo, se puede cerrar una fase sin la decisión de iniciar alguna otra fase.
Por ejemplo, el proyecto está completo o se considera que el riesgo es demasiado

9
alto para permitir la continuidad del proyecto. La conclusión formal de la fase no
incluye la autorización de la fase posterior. Para un control efectivo, cada fase se
inicia formalmente para producir una salida, dependiente de la fase, del Grupo de
Procesos de Iniciación, que especifique lo que está permitido y lo que se espera para
dicha fase. Se puede realizar una revisión al final de cada fase con el objetivo explicito
de obtener la autorización para cerrar la fase actual e iniciar la fase posterior. En
ocasiones, se pueden obtener ambas autorizaciones en una sola revisión. Las
revisiones al final de cada fase son también conocidas como: salidas de fase,
entradas a la fase o puntos de cancelación.

Figura 1-3 Secuencia de fases típicas en un ciclo de vida del proyecto

Fuente: PMBOK 2005

Muchos proyectos están vinculados con el trabajo continuo de la organización
ejecutante. Algunas organizaciones aprueban formalmente los proyectos sólo tras
haber concluido un estudio de viabilidad, un plan preliminar o alguna otra forma
equivalente de análisis. En estos casos, la planificación o el análisis preliminar
adquiere la forma de un proyecto separado. Por ejemplo, se pueden presentar fases
adicionales como resultado de desarrollar y probar un prototipo antes de iniciar un
proyecto para el desarrollo del producto final. Algunos tipos de proyectos,
especialmente los proyectos de desarrollo de servicios internos o productos nuevos,
se pueden iniciar de manera informal durante un período limitado que permita
obtener la aprobación formal de fases o actividades adicionales.
Las fuerzas impulsoras que crean los estímulos para un proyecto se conocen
habitualmente como problemas, oportunidades o requisitos de negocio. El efecto de
10
estas presiones es que, en general, la dirección debe priorizar esta solicitud con
respecto a las necesidades y a las demandas de recursos de otros posibles
proyectos.
La definición del ciclo de vida del proyecto también identificará qué tareas de
transición al final del proyecto están incluidas y cuáles no, a fin de vincular el proyecto
con las operaciones de la organización ejecutante. Por ejemplo, cuando se envía un
nuevo producto a fabricación o comercializa un nuevo programa de software. Debe
tenerse cuidado en distinguir entre el ciclo de vida del proyecto y el ciclo de vida del
producto.
Por ejemplo, un proyecto emprendido para colocar en el mercado un nuevo ordenador
de escritorio es sólo un aspecto del ciclo de vida del producto. La Figura 1-4 ilustra el
ciclo de vida del producto que comienza con el plan de negocio, pasa por la idea,
hasta llegar al producto, las operaciones y la retirada del producto. El ciclo de vida del
proyecto atraviesa una serie de fases para crear el producto. Proyectos adicionales
pueden incluir una actualización del rendimiento del producto. En algunas áreas de
aplicación, tales como el desarrollo de nuevos productos o el desarrollo de software,
las organizaciones consideran el ciclo de vida del proyecto como parte del ciclo de
vida del producto.

Figura 1-4 Relación entre el ciclo de vida del producto y el ciclo de vida del
proyecto

Fuente: PMBOK 2005

1.3 Definiciones de administración de proyectos
En concordancia con los proyectos, es adecuado revisar las definiciones de
administración de proyectos de varios autores :
11
 “La administración de proyectos, es una serie de actividades incorporadas
en el proceso de hacer que las cosas se ejecuten en un proyecto, mediante
el trabajo de miembros del equipo del proyecto y otras personas, con el fin
de alcanzar el cronograma del proyecto, el costo y los objetivos técnicos de
desempeño” (Cleland y Ireland, 2006, p.51).
“Planeación, programación y control de una serie de tareas integradas de
tal forma que los objetivos del proyecto son alcanzados de forma exitosa y
cumpliendo de la mejor forma las expectativas de los grupos interesados
del proyecto (Kerzner, 2004, p. 2).
“Es la aplicación de conocimiento, habilidades, herramientas y técnicas
hacia actividades de proyecto para alcanzar los requerimientos de éste
(PMBOK 2005, p.6)”.
“La administración de proyectos es la forma de planear, organizar, dirigir y
controlar una serie de actividades realizadas por un grupo de personas que
tienen un objetivo especifico; el cual puede ser (crear, diseñar, elaborar,
mejorar, analizar, etc.) un problema o cosa.” (Rodríguez, 2002, p1)
Para introducirnos en el análisis de los conceptos de administración de proyectos,
abordaremos el concepto de administración general, el cual nos dará el punto de
partida teórico. Posteriormente identificaremos su relación y las diferencias
específicas con la administración de proyectos:
“La Administración es un proceso claro que consiste en planear,
organizar, actuar y controlar con el propósito de determinar y alcanzar
los objetivos de la organización mediante el empleo de personas y
recursos para ello.” (Terry, 2012, p10)
Atendiendo a varias categorías en los conceptos de administración, Reinaldo O. Da
Silva (2003, p.6), llega a la siguiente definición:
“La administración es un conjunto de actividades dirigido a aprovechar los
recursos de manera eficiente y eficaz con el propósito de alcanzar uno o
varios objetivos o metas de la organización”.

12
Las definiciones anteriores incluso, no tienen una variación en escencia importante de
los principios básicos originalmente publicados por Henry Fayol en 1916, señalando
los elementos necesarios para una administración general efectiva:
 Planeación
 Organización
 Coordinación
 Comando
 Control
La combinación de estos elementos y sus 14 principios proveen una estructura de
gestión directiva:
1. División del trabajo
2. Responsabilidad relacionada con autoridad
3. Disciplina
4. Unidad de mando
5. Unidad de dirección
6. Subordinación de los intereses individuales a los de interés general
7. Remuneración del personal
8. Centralización
9. Línea de autoridad (escalar)
10. Orden
11. Equidad
12. Estabilidad y administración de personal
13. Iniciativa (apasionamiento)
14. Espíritu de cuerpo (interdependencia en un organismo).
En este sentido, Kevin Forsberg (2000, p.20) menciona:
Tales elementos y principios aún continúan siendo utilizados por los profesionales de
administración de proyectos en su búsqueda para describir el modelo y naturaleza de
la administración de proyectos.
Los administradores de proyectos ejecutan las tradicionales funciones de Planeación,
Organización, Coordinación, Dirección y Control. El hecho de que la mayoría de los
textos de administración escritos desde 1916 están basados en esta estructura de
13
Fayol, con sólo menores variaciones y adornos, es un tributo a la vigencia de este
pensamiento tradicional.
1.4 Principales diferencias entre administración general y administración de
proyectos.
Forsberg señala que 4 de los 14 principios de Fayol no son aplicables en la
administración de proyectos:
- Responsabilidad relacionada con autoridad
- Unidad de mando
- Línea de autoridad (escalar) y
- Estabilidad
- Tales principios son a menudo omitidos en la administración de proyectos,
derivado de que no son deseables o no pueden ser logrados en un ambiente
de proyectos.
Con base en lo anterior, Kevin Forsberg sugiere una estructura aplicable a la
administración de proyectos, la cual se describe en la tabla 1.
Tabla 1-1 Relación de la administración tradicional y la administración de
proyectos.
Fayol Recientes Modelo de 10 Enfoque
(1916) Derivacione elementos Razones de expansión principal
s
Requerimient Los requerimientos inician y
Organizar os conducen los proyectos.
Organiza Organización
r Selección de Los equipos son formados en cada
Reclutar equipo proyecto e incluyen contratos con Formula
proveedores y outsourcing ción
Planeación Proactiv
Administració La gestión de la incertidumbre de a
n del riesgo y los proyectos implica riesgos y
Planear Planear la oportunidades particulares
oportunidad
Control de Controles apropiados evitan
proyectos incumplimiento de objetivos
Visibilidad Es requerido el diseño y la Control
Controla implementación de sistemas para de
r Controlar mantener informados a todos los variacio
interesados (Stakeholders). nes
Coordina Status Difícil medición de progreso y
14
 r variaciones, en contraste con una
actividad típica de reporteo. Reactivi
Acción La innovación es requerida para dad
correctiva corregir desviaciones conforme a lo
Comand
Dirigir planeado
ar
Liderazgo Generación de energía de equipo Motivar
para el éxito en lo planeado
Fuente: Forsberg, K., Mooz, H. y Cotterman F. (2000). Visualizing Project
Management, a model for Business and Technical Success. John Wiley and Sons,
p.38.
Forsberg menciona (2000, p.35), mientras que el modelo de Fayol y sus derivaciones
tienen una validez permanente para la administración general, estas presentarían
carencias al:
- Buscar su aplicación en la administración de proyectos y su relativa corta
duración.
- Direccionar el rol de los requerimientos como iniciadores y conductores del
proyecto
- No proveer suficiente detalle para manejar procesos de proyecto altamente
complejos particularmente aquellos con alto riesgo y de alta tecnología.
En la tabla 1 se resaltan en negritas los elementos que cubren los aspectos arriba
relacionados, de acuerdo a Forsberg; es relevante mencionar que las técnicas que
se utilizan para cumplir con los elementos referidos, son situacionales y deben ser
aplicadas aquellas que mejor se adaptan al momento en se encuentra un proyecto y
a sus circunstancias de equipo o individuales.
Por ejemplo, tales elementos se aplican frecuentemente en la Organización en cada
una de las fases de un proyecto y de manera similar el elemento Visibilidad aplicará
aquellas técnicas que mejor cubran las necesidades de información de cada fase del
ciclo de vida del proyecto.
Cabe destacar de la tabla arriba referida, la distinción entre proactividad y reactividad
en el Control de Proyectos que se observa en la última columna y es particularmente
importante, dado que éste comprende aquellas técnicas que contribuyen a que los
eventos ocurran conforme a los planeado y que aquellos eventos no planeados no
sucedan (control proactivo), mientras que los tres elementos de control de
variaciones definen los medios para detectar y corregir los resultados no planeados
(control reactivo).
Por otro lado, la figura que dirige todo el proceso administrativo de forma general en
una organización es el Director general, quien a su vez delega responsabilidades por
áreas funcionales. En el caso del ámbito de los proyectos este rol lo cumple el
administrador de proyectos, que igualmente delega responsabilidades no por áreas
funcionales sino por subproyectos o tareas, es pertinente ahora hablar del
administrador de proyectos.

2. ESTÁNDARES Y METODOLOGÍAS DE ADMINISTRACIÓN DE PROYECTOS

15
2.1 Antecedentes
En revisiones hasta el año 2005 se han identificado hasta 150 metodologías
relacionadas con la administración de proyectos, reconocidas por diversos
organismos directamente vinculados con esta área profesional.
Refiriéndose a proyectar metodologías de Administración, Jason Charvat (2003, p.54)
observa que:
"A lo largo de los años, incluso los involucrados en la Administración de proyectos
han observado que los proyectos tienen características en común que se pueden
formalizar en un proceso estructural, lo que les permite gestionar los proyectos más
eficazmente. Cada fase puede llevarse al cierre de forma típica y de alguna manera
lógica antes de que la siguiente fase del proyecto se inicie, y los resultados de cada
fase, proporcionan el punto de partida para la siguiente fase, las estimaciones de
costos y programación, los planes, los requisitos y las especificaciones deben ser
actualizados y evaluados. al final de cada fase, antes de decidir si se debe continuar
con el proyecto. "
Derivado de que existen metodologías específicas para tipos de proyectos, de las
cuales por ejemplo las metodologías de administración de tecnología se han
desarrollado notablemente, Jason Charvat hace una distinción entre estas
metodologías y las metodologías de administración de proyectos:
A este respecto, Charvat hace la siguiente distinción: La metodología de
Administración de proyectos es el marco del proyecto y el marco identifica los
segmentos del mismo; sin embargo, las metodologías de gestión específicas
proporcionan el medio de selección de la Administración apropiada para el grado
particular de atención de cada proyecto y de igual forma, las técnicas de
Administración de proyectos (y su grado de formalidad o “ceremonia”) deben
adaptarse a los riesgos y oportunidades específicos del mismo.
En este sentido Charvat puntualiza:
“Algunas metodologías de los proyectos se centran exclusivamente en la tecnología
en sí misma, mientras que otros se centran más en un enfoque de gestión de
proyectos genéricos. Usted debe considerar cuidadosamente la metodología a utilizar
en función de las necesidades de la organización."

16
Como sustento de los comentarios arriba referidos, Charvat adiciona a su análisis una
tabla donde se incluyen tanto las metodologías de administración de proyectos, como
las metodologías de desarrollo de tecnología (como las que han evolucionado de
forma importante), así como una metodología clásica de construcción de edificios,
como forma de comparación (Tabla 2-1).

Tabla 2-1
Suited to Project
Description S Q T of:
control $ Phases Size Comments
Project Management Frameworks Methodologies
Rational Unified Process Y Y Y Y Y M, L 1, 2, 3, 4
PRINCE2 Y Y Y Y Y M, L 4
System Development Life Cycle (SDLC) Y Y N ? Y S, M, L 3, 4, 6
Solutions-based Project Methodology Y Y N N Y S, M 3, 5
TenStep Y Y Y N N S, M 5
Technology Development Management Methodologies
The "Agile" Group:
Extreme Programming (XP) N Y N N N S, M 5
Scrum N Y N N N S, M 5
Crystal N Y N N N S, M 5, 7
Dynamic Sys. Development (DSDM) Y Y Y ? Y S, M 5
Rapid Applications Development (RAD) Y Y Y ? Y M, L 5
Unicycle Y Y Y Y Y S, M, L 4
Code-and-fix Approach N N N N N S 7
V-methodology Y Y Y Y Y M, L 4
Waterfall Y Y Y Y Y M, L 4, 6
Open Source N N N N N S, M 5
Spiral Y Y N N Y M, L 4
Synchronize and Stabilize Y Y N N Y M, L
Reverse Engineering Development Y Y N N Y M, L 4
General Publication Methodology Y Y N ? Y M 4, 8
Structured System Analysis & Design Y Y N N Y M, L 4
Pramis Y Y Y Y Y M, L 4
Offshore Development Y Y Y Y Y L 4
General Drug Development N Y N N Y L 4
Classic Building Construction Y ? Y Y Y M, L 4

Comparación de varias metodologías desde una perspectiva de administración de proyectos

Comments:
S = Scope; Q = Quality; T = Time & $ = Cost
1. Y, N, ?: Yes, No, Undetermined

17
 2. S, M, L: Small, Medium or Large projects
3. Arguably an IT/software development methodology, i.e. belongs under Technology Management
4. High management ceremony
5. Low management ceremony
6. Classic "waterfall" sequence
7. Not suited to virtual teams
8. For book and periodical publishing

También llama la atención sobre lo que él llama metodologías "ligeras" y "pesadas",

es decir, aquellos con poca o ninguna “ceremonia” y aquellos con “ceremonia”
considerable (como se observa en la Figura 1) necesaria por la complejidad del
proyecto. Como él mismo dice:
“Porque el tamaño del proyecto y complejidad afecta el tipo de metodología que se ha
seleccionado, es crucial que los directores de proyecto determinen la configuración
del terreno en primer lugar. La Figura 2 (abajo) es una matriz de selección, que
muestra los diferentes tamaños (es decir, pequeños, medianos o grandes) de los
proyectos que pueden encontrarse. Esta matriz sirve como una guía para el tipo de
metodología que debe emplear para su proyecto. La selección de la metodología
incorrecta para su proyecto puede ser desastroso " Por lo tanto, la figura 2-1 sirve
como un gráfico de gran utilidad:
Figura 2-1 Matriz Charvat para selección de metodología de administración de
proyectos

A continuación se describe brevemente las principales metodologías de

administración de proyectos.
2.2 Project Management Body Of Knowledge (PMBOK)

18
El Management Body Of Knowledge Guide (PMBOK) es un conjunto de estándares
para la administración de proyectos aplicable en diversos tipos de industrias. Estos
estándares describen los procesos, herramientas y técnicas de administración de
proyectos. Estos estándares entendidos como mejores prácticas, son emitidos por el
Instituto de Administración de proyectos (PMI por sus siglas en inglés), a través de la
recopilación de experiencia e investigación de sus afiliados.
Estos estándares se relacionan con otras disciplinas de administración de proyectos
tales como la administración de programas y la administración de portafolios de
(proyectos).
Esta guía se segmenta en 9 áreas de conocimiento en la administración de proyectos:
 Integración
 Alcance
 Tiempo
 Costo
 Calidad
 Recursos humanos
 Comunicaciones
 Riesgos
 Adquisiciones
La guía PMBOK, refiere 42 procesos de administración de proyectos, distribuidos en 5
grupos de procesos que son típicamente ejecutados en cualquier proyecto (Inicio,
Planeación, Ejecución, Monitoreo y Control, Cierre). Los grupos no corresponde a
fases dentro de los proyectos (los proyectos son usualmente divididos en fases tales
como análisis, diseño, construcción, prueba, etc). Los grupos de procesos pueden ser
ejecutados en cada fase del proyecto o subproyecto.
2.3 PRojects IN Controlled Environments (PRINCE2)
La administración estructurada de proyectos significa gerenciar proyectos en una
forma lógica y organizada, siguiendo etapas claramente definidas. PRINCE 2 es un
método de administración estructurada de proyectos y constituye una descripción
escrita de esa forma lógica y organizada de gerenciar. El autor nos presenta una

19
breve descripción de esta metodología de certificación, sobre la base de su
experiencia como consultor del tema.
Esta metodología fue creada en Londres en 1989 como una iniciativa del gobierno
para apoyar y garantizar la forma de desarrollar proyectos. Estaba dirigida en un inicio
al área de Sistemas de Información y luego se convirtió en el estándar a seguir por
todas las entidades gubernamentales en el país y en años siguientes se expendió por
toda Europa y el mundo.
La mayoría de multinacionales han ido adoptando esta metodología de
gerenciamiento de proyectos.
Esta metodología es una combinación de 8 procesos, 8 componentes y de 3 técnicas.
Procesos:
 Starting UP a Project: surge la necesidad de realizar algo.
 Initiating a Project: inicia el proyecto con sus métricas.
 Directing a Project: administración del proyecto per se.
 Managing stage bounderies: manejo efectivo de las diferentes etapas.
 Controlling a Stage: midiendo la eficiencia del proyecto.
 Managing product delivery: garantizando la entrega de lo deseado.
 Closing a Project: cierre formal de un proyecto.
 Planning: planeación de todos los recursos involucrados.
Componentes:
 Organisation: define la estructura organizacional del proyecto.
 Plans: define los pasos a seguir, los reportes de recursos, etc.
 Controls: administración de los procesos.
 Business Case: define los beneficios del negocio.
 Quality Management: define y mide la calidad del proyecto.
 Configuration Management: define las características y cómo serán medidos
los productos a entregar de acorde a sus especificaciones.
 Change Control: define el proceso y procedimiento a seguir si hay algún
cambio.

20
  Management of Risk: define las variables a considerar y como medir los
riesgos que deben tomarse en un proyecto.
Técnicas:
1) Product-Based Planning: esta técnica involucra otros tres elementos que nos
ayudan a la definición de los productos a entregar, bajo el concepto de producto a
entregar es aquel que se definió como la realización y entrega de los
requerimientos solicitados:
2) Change Controls: esta técnica nos garantiza someter a procesos toda la
gerencia del proyecto basada en tener bajo control cualquier cambio que ocurra.
3) Quality Reviews: esta técnica nos ayuda a revisar los estándares ya existentes
y también poder buscar nuevos que puedan ser aplicados. También nos ayuda a
tener procedimientos exitosos así como tener un acercamiento a revisar cada uno
de los elementos y productos a entregar. En esta técnica también involucra la
correcta toma de decisiones del proyecto, el manejo de proveedores y el manejo
de la información.
Cabe mencionar que esta metodología no provee de herramientas como lo son el
uso de diagramas de Gantt, análisis de redes, análisis financiero, cuadros de
riesgo, etc. Más bien esta metodología deja abierto para que cada gerente de
proyecto utilice las herramientas que desee, ya que de igual forma las utilizará
para el desarrollo del mismo, pero no limita su uso.
2.4 Metodologías AGILE de Administración de proyectos
Las metodologías de desarrollo ágil se basan fundamentalmente en la colaboración
con los usuarios de software durante todo el proceso de desarrollo, la facilidad para
adaptar el producto a cambios en requerimientos y en la entrega incremental del
producto. Basadas en el Manifiesto Ágil, han sido aceptadas y son utilizadas en
proyectos donde los requerimientos detallados son inicialmente desconocidos y se
van construyendo durante el proceso de desarrollo a partir de interacciones con los
usuarios y de la retroalimentación obtenida a partir de las mismas.
El Manifiesto Ágil incluye cuatro postulados y una serie de principios asociados. Sus
postulados son:

21
1) Valorar al individuo y a las interacciones del equipo de desarrollo por encima del
proceso y las herramientas. Tres premisas sustentan este principio:
a) los integrantes del equipo son el factor principal de éxito de un proyecto;
b) es más importante construir el equipo de trabajo que construir el entorno; y
c) es mejor crear el equipo y que éste configure el entorno en base a sus
propias necesidades.
2) Valorar el desarrollo de software que funcione por sobre una documentación
exhaustiva. El principio se basa en la premisa que los documentos no pueden
sustituir ni ofrecer el valor agregado que se logra con la comunicación directa entre
las personas a través de la interacción con los prototipos. Se debe reducir al mínimo
indispensable el uso de documentación que genera trabajo y que no aporta un valor
directo al producto.
3) Valorar la colaboración con el cliente por sobre la negociación contractual. En el
desarrollo ágil el cliente se integra y colabora con el equipo de trabajo como un
integrante más. El contrato en sí no aporta valor al producto, es sólo un formalismo
que establece líneas de responsabilidad entre las partes.
4) Valorar la respuesta al cambio por sobre el seguimiento de un plan. La evolución
rápida y continua deben ser factores inherentes al proceso de desarrollo. Se debe
valorar la capacidad de respuesta ante los cambios por sobre la capacidad de
seguimiento y aseguramiento de planes pre-establecidos.
El ciclo de desarrollo que aplican las Metodologías Ágiles es iterativo e incremental.
Este modelo permite entregar el software en partes pequeñas y utilizables, conocidas
como incrementos. Cada iteración se puede considerar como un mini-proyecto en el
que las actividades de análisis de requerimiento, diseño, implementación y testing son
llevadas a cabo con el fin de producir un subconjunto del sistema final. El proceso se
repite varias veces produciendo un nuevo incremento en cada ciclo hasta que se
elabora el producto completo. Si bien todas las metodologías ágiles adoptan este
ciclo, cada una presenta sus propias características
Las metodologías ágiles más comúnmente usadas se describen a continuación.
 Scrum
 Cristal Methodologies
22
  Dynamic Systems Development Method
 Adaptive Software Development
 Feature-Driven Development
2.4 El proceso de control en la administración de proyectos
Las actividades de control proveen una oportunidad para la gente de tener iniciativa
contra desviaciones respecto de lpo planeado (proactividad), identificar fuerzas que
causan una desviación, realizar correcciones de forma inmediata (Reactividad)
cuando una desviación ocurre y finalmente redirigir para capitalizar una desviación
cuando una corrección es menos factible.
La mayoría de los textos de gestión de proyectos se describen control de
proyectos como la comparación reales al plan (de estado). Mientras que el
monitoreo y seguimiento de los costos y datos de programación es un paso hacia
el control reactivo, no es de control de proyectos sin diseño e implementación de
un control adecuado sistemas en el primer lugar y respondiendo con acciones
correctivas a variaciones significativas.
Se define como el proceso de control del proyecto, tanto control proactivo como
reactivo, un sistema dual diseñado e implementado para reducir el riesgo:
• Control de línea de base proactiva.
• Control de rendimiento reactiva.
• El control proactivo del plan del proyecto y los cambios en el plan.
• Control de varianzas reactiva en el rendimiento al plan del proyecto.
• Técnicas de gestión que ayudan a asegurar que los resultados se producen
como previsto, y que los resultados no planificados no suceden.
• La acción correctiva tomada cuando los resultados no planificados ocurren.
Esta sección se ocupa de las funciones de definición y establecimiento de
los cinco elementos esenciales comunes a todos los sistemas de control. Ellos
son:
1. Cosas que hay que controlar. La función que debe ser controlado a un
estándar de rendimiento.
2. Control estándar. La norma aprobada de rendimiento.

23
3. La autoridad de control. La persona u organización autorizada para imponer la
norma y podrán establecer excepciones.
4. Mecanismo de control. El foro o técnica que mide cumplimiento de la norma.
5. Indicación de Varianza. La identificación de f leyes en el control proceso o
violaciones de la norma.
Los sistemas de control están diseñados para controlar los logros del plan del
proyecto. De gran importancia son aquellos controles necesarios para gestionar un
riesgo significativo y métodos de proceso-sensibles, tales como agentes de unión
y otros procesos en donde el medio ambiente y la contaminación pueden afectar la
calidad del resultado. Procesos maduros, bien establecidos deben mejorar
continuamente para lograr aún mayor consistencia de los resultados. Nuevos
procesos pueden requerir frecuentes auditorías para verificar que los resultados
son los esperados. A medida que los procesos de maduración y se ha
comprobado que sea fiable, las auditorías se puede reducir y posiblemente
eliminar.

El control de variaciones/desviaciones está diseñado para detectar prácticas o

rendimiento considerado deficiente. Las variaciones pueden resultar de aplicación
si proscrito de las normas o desviaciones de los estándares.

Este sistema de acción correctiva se basa en los elementos de gestión de la

visibilidad, de estado, y la acción correctiva para cerrar el bucle de control de
proceso reactivo. Los tres son necesarios para el control de reactivo. Nos dirigimos
a cada uno de estos elementos en capítulos separados.
Ejemplos de control dentro de la línea de base de negocios incluyen
programación, la financiación, los cambios, la calidad del personal, nivel de
plantilla, personal clave, las prácticas de trabajo, y la conducta ética. Personal
ejemplos de controles de seguridad incluyen alta presión, radiación, toxinas, de
alta tensión, las superficies resbaladizas, bordes afilados, espacio superior,
elevadores de escalera, y la calidad del aire.

24
 Se necesitan controles de procesos para administrar las funciones importantes del
proyecto y para el control del riesgo. Sin controles de procesos adecuados, los
datos pueden perderse o pasado por alto. Los proyectos más pequeños a menudo
son vulnerables debido al exceso de confianza que los detalles pueden ser
informalmente "Tener en cuenta".
Las lecciones aprendidas en relación con los controles incluyen:
 Los grandes proyectos tienen trayectorias complejas de comunicación;
 Detalles se pierden, mal interpretados o pasados por alto.
 Proyectos Geográficamente dispersos suelen tener comunicación informal
 caminos; Detalles se pierden, mal interpretados o pasados por alto.
 Proyectos de alta fiabilidad deben ser construidos para cumplir los estándares,
detalles se pierden, se interpreta o pasados por alto.
 Los proyectos de larga duración tienen rotación de personal; Detalles se
pierden, mal interpretados o pasados por alto.
 Los proyectos con los subcontratistas tienen la comunicación y legales
complejidad;
Detalles se pierden, mal interpretados o pasados por alto. De ello se desprende
que los grandes proyectos, de largo, de alta fiabilidad utilizando subcontratistas
necesitan un control completo y eficaz proceso.

Análisis de proyectos fallidos revela a menudo la causa de la falta de ser la falta de

controles y de elusión de los controles existentes suficientes.

En resumen, los proyectos con procesos inadecuados controles suele fallar.

Proyectos que tienen los procesos de control apropiados tienen una buena
oportunidad para el éxito. Pero ¿cuál es el nivel "adecuado" de control que el
"sweet spot", donde se logra el control y sin burocracia innecesaria?

3 TABLEROS DE CONTROL DENTRO DE LA ADMINISTRACIÓN DE

PROYECTOS
3.1 Que son los tableros de control
25
La idea detrás de tableros o paneles de control fue el resultado de sistemas de apoyo
en las decisiones en los años 1970. Con el aumento de la red a finales de 1990,
tableros de control relacionados con la empresa comenzaron a aparecer. Algunos
tableros fueron presentados para dar seguimiento a los flujos inherentes a los
procesos de negocio, mientras que otros se utilizan para monitorear que tan bien se
está ejecutando la estrategia de negocio.
El tablero de control (TdC) es una herramienta, del campo de la administración de
empresas, aplicable a cualquier organización y nivel de la misma, cuyo objetivo y
utilidad básica es diagnosticar adecuadamente una situación. Se lo define como el
conjunto de indicadores cuyo seguimiento y evaluación periódica permitirá contar con
un mayor conocimiento de la situación de su empresa o sector apoyándose en nuevas
tecnologías informáticas.
El diagnostico y monitoreo permanente de determinados indicadores e información ha
sido y es la base para mantener un buen control de situación en muchas de las
disciplinas de la vida. Como ejemplo de estos podemos señalar a la: medicina,
basada en mediciones para el diagnostico de la salud de los pacientes, a la aviación,
cuyos indicadores de tablero de control sintetiza la información del avión y del entorno
para evitar sorpresas y permite a los pilotos dirigir el avión a buen puerto; el tablero de
un sistema eléctrico o de una represa son otros ejemplos. En todos estos casos el
Tablero permite a través del color de las luces y alarmas ser el disparador para la
toma de decisiones. En todos estos ejemplos es fundamental definir los indicadores a
monitorear.
El tablero de control se considera un conjunto de indicadores que a través de su
seguimiento y control periódico, proporciona información esencial (Endeavor México,
2006, p.10).
El tablero de control traduce la estrategia y la misión de una organización en una
amplio conjunto de medidas de la actuación que proporcionan la estructura necesaria
para un sistema de Administración y medición estratégica (Harold Kerzner 2011,
p.199) provee una definición aplicada a la administración de proyectos:
Un tablero de control de administración de proyectos es una presentación visual de un
pequeño número de indicadores críticos o indicadores clave de desempeño tales que

26
las partes interesadas y el personal del proyecto puede ver la información necesaria a
simple vista con el fin de tomar decisiones informadas. Toda la información debe ser
claramente visible en una sola pantalla.
Kerzner (2011, p.198) En el ámbito de gestión administrativa, inicialmente los tableros
de control se construyeron para representar a las medidas financieras que incluso los
ejecutivos podían entender. Tal vez el acontecimiento más importante que afectó a
estos tableros de control fue la introducción de la importancia de los indicadores clave
de rendimiento como parte de Enfoque de Balanced Scorecard publicado por . Kaplan
y Norton a mediados de 1990.

3.2 Tipos de tableros de control dentro de la administración de proyectos de

software.
Algunas personas confunden los tableros de control con los cuadros de mando
integral (Balance Scorre Cards o BSC por sus siglas en inglés). Hay una diferencia
entre los cuadros de mando integral. De acuerdo con Eckerson:
Los tableros de control son mecanismos de representación visual utilizados
para una orientación operacional sistema de medición del desempeño que
miden el desempeño contra objetivos y los umbrales a partir de datos en el
momento adecuado.
El cuadro de mando integral es una representación visuales utilizados en
una actuación orientada estratégicamente sistema de medición que
representen el progreso hacia el logro estratégico metas y objetivos
mediante la comparación de rendimiento frente a los objetivos y umbrales.
Ambos cuadros de mando son los mecanismos de visualización dentro de
un sistema de medición del desempeño que transmiten información crítica.
La principal diferencia entre los cuadros de mando es que el monitor
tableros procesos operacionales, tales como los utilizados en la gestión de
proyectos,
Los tableros de control son más como los paneles de automóviles. Estos dejan que
los especialistas operativos y sus supervisores monitoreen los eventos generados por
los procesos clave del negocio. A diferencia de los automóviles, sin embargo, la

27
mayoría de los tableros de control empresariales no muestran acontecimientos en
"tiempo real" a medida que ocurren, sino que los muestra en el "momento adecuado",
cuando los usuarios necesitan verlos. Esto podría ser cada segundo, minuto, hora,
día, semana o mes, dependiendo de los procesos de negocio, su volatilidad, y lo
importante que es para el negocio. Sin embargo, la mayoría de los elementos de un
cuadro de mando se actualizan con una latencia que puede medirse en cuestión de
minutos u horas.
Los cuadros de mando a menudo muestran el rendimiento visual, utilizando
diagramas o gráficos simples, tales como manómetros y medidores. Sin embargo, los
gráficos del tablero de instrumentos se han actualizado en el lugar, haciendo que la
gráfica de "parpadeo" o cambiar de forma dinámica. Irónicamente, las personas que
controlan los procesos operativos a menudo encuentran la ostentación visual
distracción y prefieren ver los datos en su forma original, como números o texto, tal
vez acompañada de gráficos visuales.
Los tableros de control de tipo estratégico, son más bien conocidos como cuadros de
mando integral, y por el contrario a los tableros de control operativos, parecen más
gráficos de rendimiento utilizados para seguimiento del progreso hacia el logro de
metas. Los cuadros de mando (BSC), suelen mostrar instantáneas mensuales de los
datos resumidos de los ejecutivos de negocios que rastrean los objetivos estratégicos
y de largo plazo, o instantáneas diarias y semanales de los datos para los
administradores que necesitan para trazar el progreso de su grupo de proyectos hacia
el logro de metas. En ambos casos, los datos se resumen bastante para que los
usuarios pueden ver su estado general de un vistazo.
Como los tableros de control (tableros de control), los cuadros de mando (scorecards)
también hacen uso de tablas y gráficos visuales para indicar el estado de rendimiento,
las tendencias, y la variación respecto a los objetivos. El más alto de los usuarios
están en la organización, más que prefieren ver el rendimiento codificado visualmente.
Sin embargo, la mayoría de los cuadros de mando también contienen (o debería
contener) una gran cantidad de comentario textual que interpreta los resultados de
rendimiento, se describen las medidas adoptadas y previsiones de resultados futuros.

28
Aunque los términos se usan indistintamente, la mayoría de los directores de
proyectos prefieren utilizar cuadros de mando y / o panel de informes en lugar de
cuadros de mando. Eckerson define tres tipos de paneles:
Cuadros de mando operativos supervisan los procesos operativos básicos y son
utilizados principalmente por los trabajadores de primera línea y sus supervisores que
tratan directamente con los clientes y gestionar la creación y entrega de productos y
servicios de la organización. Cuadros de mando operacionales proporcionan
principalmente información detallada que se resume sólo a la ligera. Por ejemplo, un
comerciante en línea Web puede rastrear las transacciones a nivel de producto y no a
nivel del cliente. Además, la mayoría de las métricas en un panel de control operativo
se actualizan sobre una base intradía, que van desde minutos a horas, dependiendo
de la aplicación. Como resultado, los tableros de instrumentos operativos hacen
énfasis en el seguimiento más de análisis y de gestión.
Cuadros de mando tácticos rastrean los procesos y proyectos que sean de interés
para un segmento de la organización o un grupo limitado de personas de los
departamentos. Los gestores y analistas de negocios utilizan paneles tácticas para
comparar el rendimiento de sus áreas o proyectos, los planes presupuestarios,
previsiones o resultados del último período. Por ejemplo, un proyecto para reducir el
número de errores en una base de datos de cliente puede utilizar un tablero táctico
para visualizar, controlar y analizar los avances en los 12 meses anteriores a lograr
99,9 por ciento libre de defectos de los datos del cliente en 2007.
Cuadros de mando estratégicos supervisar la ejecución de los objetivos estratégicos y
se aplican con frecuencia con un cuadro de mando integral, a pesar de Gestión de
Calidad Total, Six Sigma y otras metodologías se utilizan también. El objetivo de un
cuadro de mando estratégico es alinear la organización en torno a los objetivos
estratégicos y conseguir cada grupo que marcha en la misma dirección. Para ello, las
organizaciones desplegar cuadros de mando personalizados a todos los grupos en la
organización y, a veces a todos los individuos también. Estos cuadros de mando "en
cascada", que por lo general se actualizan semanalmente o mensualmente, dan
ejecutivos de una poderosa herramienta para comunicar la estrategia, ganar
visibilidad en las operaciones, e identificar los factores clave de rendimiento y valor

29
comercial. Cuadros de mando estratégicos destacan la gestión de más de
seguimiento y análisis.
3.3 Errores en la utilización de los tableros de control en la administración de
proyectos de software.
Muchos cuadros de mando no proporcionan valor debido a problemas de diseño, no
la tecnología. Tableros de control eficaces no son campanas, semáforos, luces
brillantes. El diseño del tablero de control es la comunicación efectiva. La mayoría de
la gente no puede entender que la visualización de la información es una ciencia, no
un arte.
3.4 Factores de éxito de los tableros de control en la administración de
proyectos.
Hay tres pasos fundamentales que deben tenerse en cuenta al utilizar cuadros de
mando,
(1) el público objetivo para el tablero de instrumentos,
(2) el tipo de panel de control que se utilizará, y
(3) la frecuencia con que se actualiza la información. Algunos cuadros de mando del
proyecto se centran en los indicadores de rendimiento clave que forman parte de la
medición del valor ganado. Estos paneles pueden necesitar ser actualizado a diario o
semanalmente. Cuadros de mando relativas a la salud financiera de la empresa.
Los cuadros de control empresariales se están convirtiendo en el "must have" de la
tecnología de inteligencia de negocios para los ejecutivos y usuarios de negocios a
través de la América corporativa. Soluciones Dashboard han estado alrededor por
más de una década, pero se han visto recientemente resurgimiento en popularidad a
causa del avance de permitir que la inteligencia de negocio y tecnologías de
integración.
El diseño de un tablero de control eficaz es más difícil de lo que parece, porque va a
comprimir grandes cantidades de información de negocios en una pequeña área
visual. Cada componente tablero debe equilibrar efectivamente su parte de espacio
en pantalla con la importancia de la información que está impartiendo al espectador.
Objetivos de diseño

30
Los tableros de control pueden tener muchos formatos, desde informes glorificados a
tarjetas de negocio altamente estratégicos. Este artículo se refiere a tableros
operacionales o tácticos empleados por los usuarios de negocio en la realización de
su trabajo diario, estos paneles pueden apoyar directamente a los objetivos
estratégicos de alto nivel o estar atado a una función de negocios muy específico. El
objetivo de un panel de control operacional es proporcionar a los usuarios de negocio
con información relevante y procesable que les da poder para tomar decisiones
eficaces de manera más eficiente de lo que podían sin un panel. En este contexto,
"relevante" la información que está directamente vinculada a la función del usuario y
el nivel de la organización.
Por ejemplo, no sería adecuado para proporcionar el CFO con métricas detalladas
sobre el tráfico del sitio web, pero adecuada para presentar los costos de uso en
relación con el consumo de ancho de banda. Información "accionable" se refiere a los
datos que alertarán al usuario en cuanto a cuándo y qué tipo de acción se debe tener
con el fin de cumplir con los objetivos operativos o estratégicos. Tableros de control
eficaces requieren un diseño extremadamente eficiente, que tenga en cuenta el papel
de un usuario juega dentro de la organización y de las tareas y responsabilidades que
el usuario realiza sobre una base semanal / diaria específicos.
Definición de indicadores clave de rendimiento
El primer paso en el diseño de un tablero de control es entender lo que los
indicadores clave de rendimiento (KPI usuarios) son responsables y que KPIs desean
gestionar a través de su solución de cuadro de mandos. Un KPI se puede definir
como una medida (real o abstracta) que indica el rendimiento relativo en relación a un
objetivo de destino. Por ejemplo, podríamos tener un KPI que mide un número
específico, como por ejemplo las ventas diarias de internet con una meta objetivo de $
10.000.
En otro caso, puede ser que tengamos un KPI más abstracto que mide la "salud
financiera", como una combinación de varios indicadores clave de rendimiento, tales
como cuentas por cobrar pendientes, crédito disponible y las ganancias antes de
impuestos y depreciación. Dentro de este escenario, el KPI de nivel superior
"financiero" sería una combinación de tres medidas diferentes y su desempeño en

31
relación con los objetivos específicos. Definir los KPI correctos específicos al lector
potencial es uno de los pasos más importantes de diseño, ya que establece las bases
y el contexto para la información que será posteriormente visualizado en el panel de
control.
Definición de información de apoyo para el análisis
Además de definir los indicadores clave de rendimiento, es útil identificar la
información que un usuario quiere ver el fin de diagnosticar el estado de un KPI dado.
Nos referimos a esa información no KPI como "análisis de apoyo", ya que proporciona
el contexto y la información de diagnóstico para los usuarios finales para ayudar a
entender por qué un KPI se encuentra en un estado determinado. A menudo, estos
análisis de apoyo toman la forma de las representaciones más tradicionales de
visualización de datos, tales como tablas, gráficos, tablas, y con más paquetes de
visualización avanzada de datos, animación what-if o escenarios de análisis
predictivo.
Para cada KPI en un panel dado que debe decidir si desea proporcionar apoyo
analítico y, en caso afirmativo, qué tipo de información se serán necesarios para
apoyar el análisis de ese KPI. Por ejemplo, en el caso de un KPI presentación de
informes sobre el envejecimiento por cobrar, es posible que desee proporcionar al
usuario una lista de las cuentas debido a saldos últimos 90 días. En este caso,
cuando un usuario ve que el envejecimiento KPI es una tendencia en la dirección
equivocada, él / ella puede hacer clic en un icono de análisis de apoyo para que
aparezca un cuadro de cuentas debido ordenadas según la saldo pendiente. Esta
información sería entonces ayudar al usuario en su / su capacidad de decidir lo que,
en su caso, necesitan medidas que deben adoptarse en relación a la condición del
KPI.

4. CONCLUSIONES
La literatura consultada nos permite realizar las siguientes conclusiones:
La administración de proyectos se encuentra actualmente reconocida como una
disciplina que se alimenta de la teoría administrativa alimentada en sus principios y

32
marco de funcionamiento (metodologías y estándares) por la experiencia práctiva de
los profesionales relacionados con esta materia.
Los proyectos se encuentran presentes en las operaciones diarias de las
organizaciones desde el momento en que se identifican una serie de actividades con
objetivos y duración definidos. Derivado del desarrollo de los negocios y su
complejidad cada vez más las organizaciones se encuentran administrando uno o
varios proyectos que cuentan con objetivos alineados a las estrategias de negocio.
Esto nos indica que en la medida que las organizaciones logran proyectos exitosos,
estos contribuyen al logro de metas, objetivos y por ende de su misión y visión De ahí
la importancia de que los proyectos se encuentren correctamente administrados.
Como herramienta para una para la adecuada administración de proyectos, los
tableros de control proporcionar la información relevante de la situación de uno o
varios proyectos, en distintos niveles de gestión. Operativos, tácticos y estratégicos.
Los tableros de control deben contar con elementos básicos en esos 3 niveles de
decisión que permitan contar con una herramienta integral que contribuye con
información útil y oportuna, tales como:
- Establecer vínculo entre los diversos tipos de tablero de control, alineando los
objetivos de los proyectos con las estrategias de negocio de la organización
- Establecer tableros de control en los 3 niveles de toma de decisión: operativo,
táctico y estratégico.
- Determinar y consensuar los factores de medición de desempeño que mejor
cubren las necesidades de información de los usuarios de los tableros de
control.
- La información de los tableros de control debe ser mínina, clara, y confiable.
- Considerar los principios básicos de diseño de acuerdo al tipo de usuario de los
tableros de control.
- Considerar los objetivos de control desde un enfoque preventivo como
detectivo.
- Implementar los elementos tecnológicos que faciliten la alimentación de los
tableros de control, las

33
Referencia Bibliográfica
Charvat, Jason (2003). Project Management Methodologies: Selecting, Implementing,
and Supporting Methodologies and processes for projects. John Wiley & Sons, p. 54-
55 y 168.
Cleland, David L.; Ireland, Lewis R.(2006), Project Management: Strategic Design and
Implementation, McGraw-Hill Osborne Media, p. 51.
Dixon, M. (2000). Project management body of knowledge, 2005, pp. 1-105.
Forsberg, K., Mooz, H. y Cotterman F. (2000). Visualizing Project Management, a
model for Business and Technical Success. John Wiley and Sons, pp. 19-24, 35-45.
Eckerson, Wayne W. (2006) Performance Dashboards : Measuring, Monitoring and
Managing Your Business, John Wiley and Sons; pp. 293, 295.
George R. Terry (1953),Principles of Management, Homewood 111 Richard D. Irwin,
p. 160.
Government of Commerce (2011), Directing Successful Projects with PRINCE2™, 5a.
edición.
Kerzner, H. (2011). Project Management Metrics, KPIs, and Tableros de control : A
Guide to Measuring and Monitoring Project Performance, John Wiley & Sons, Inc. pp.
197-280.
Lakatos, I. (1970). Falsification and methodology of scientific research programmes. In
I. Lakatos & A. Musgrave (Eds.), Criticism and the growth of knowledge, Cambridge,
England: Cambridge University Press, (pp. 91–196).
Project Management Institute (2008). A Guide to the project management body of
knowledge (PMBOK guide) 4th ed. Newtown Square, Pennsylvania, pp.1-51.
Robert S. Kaplan, David P. Norton (2002). El cuadro de mando integral / Barcelona :
Administración 2000, p.1.
Reinaldo O. Da Silva (2003), Teorías de la administración. Thomson Paraninfo, p. 4.
The Enciclopedya of Management (1973) p.803.

Revistas:
Anagnostopoulos, K. P. (2004). Project management: Epistemological issues and
standardization of knowledge. Operational Research, 4(3), pp. 249–260.

34
Boyd, A. (2001). The five maxims of project satisfaction. Aslib Proceedings, 53 (10), p.
423.
Blomquist, T., & Lundin, R. A. (2010). Projects: Real, virtual of what? International
Journal of Managing Projects in Business, 3(1), pp. 10–21.
Dooley, L., Lupton, G., & O'SULLIVAN, D. (2005). Multiple project management: A
modern competitive necessity. Journal of Manufacturing Technology Management,
16(5), 466.
Gauthier, Jacques-Bernard, (2012). Foundations of Project Management Research:
An Explicit and Six-Facet Ontological Framework. Project Management Journal, 43,
No. 5, 5–23, p. 7. (Published online in Wiley Online Library (wileyonlinelibrary.com).
DOI:10.1002/pmj.21288)
Mathiassen, L., & Pourkomeylian, P. (2003). Managing knowledge in a software
organization. Journal of Knowledge Management, 7(2), p. 63.
Morris, P. (2010). Research and the future of project management. International
Journal of Managing Projects in Business, 3(1), pp. 139–146.
Söderlund, J. (2004a). Building theories of project management: Past research,
questions for the future. International Journal of Project Management, 22(3), pp. 183–
191.
Söderlund, J. (2004b). On the broadening scope of the research on projects:
A review and a model for analysis. International Journal of Project Management, 22(8),
pp. 655–667.

Páginas de internet:
Apm Group. PRojects IN Controlled Environments.
http://www.prince2.org.uk/home/home.asp, consultado en 1 de abril 2013.
Rodríguez, J. (2002). Administración de proyectos de desarrollo de sistemas de
información.http://www.monografias.com/trabajos15/sistnformacion/sistinformacion.sht
ml, Consultado el 1 de marzo de 2013.

35