Administracion Tradicional Vs Administracion actual

Vista previa del material en texto

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
· 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 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: 
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 proyectosexpuesta por David L. Cleland y Lewis R. Ireland (2006, p.51):
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 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.
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 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
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 conuno 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 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 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 :
“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”.
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 enesta estructura de 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
(1916)
	Recientes 
Derivaciones
	Modelo de 10 elementos
	Razones de expansión
	Enfoque principal
	Organizar
	Organizar
	Requerimientos
	Los requerimientos inician y conducen los proyectos.
	Formulación Proactiva
	
	
	Organización
	
	
	Reclutar
	Selección de equipo
	Los equipos son formados en cada proyecto e incluyen contratos con proveedores y outsourcing
	
	Planear
	Planear
	Planeación
	
	
	
	Administración del riesgo y la oportunidad
	La gestión de la incertidumbre de los proyectos implica riesgos y oportunidades particulares
	
	
	
	Control de proyectos
	Controles apropiados evitan incumplimiento de objetivos
	
	Controlar
	Controlar
	Visibilidad
	Es requerido el diseño y la implementación de sistemas para mantener informados a todos los interesados (Stakeholders).
	Control de variaciones
Reactividad
	Coordinar
	
	Status
	Difícil medición de progreso y variaciones, en contraste con una actividad típica de reporteo.
	
	Comandar
	Dirigir
	Acción correctiva
	La innovación es requerida para corregir desviaciones conforme a lo planeado
	
	
	
	Liderazgo
	Generación de energía de equipo para el éxito en lo planeado
	Motivar
	
	
	
	
	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
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."
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
	
Description
	Suited to
control of: 
	 
 Phases 
	Project
Size
	
 Comments 
	
	S
	Q
	T
	$
	
	
	
	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
	YY
	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 
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)
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 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. 
· 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. Mas 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: 
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 generatrabajo 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
· 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.
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.
 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
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 labase 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 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 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.
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 poderosaherramienta para comunicar la estrategia, ganar visibilidad en las operaciones, e identificar los factores clave de rendimiento y valor 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
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 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 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 necesidadesde 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 
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.	
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.shtml, Consultado el 1 de marzo de 2013.
1
51