J. Eduardo Caarnano, PMP
PRACTICO
Tecnicas, Hetramientas y conocipnioatos
PROJECT MANAGEMENT PRÁCTI CO Técnicas, Herramientas y Documentos
4
J. Eduardo Caamaño, PMP
5
© J. Eduardo Caamaño, 2012
ER-0830/2004
PUBLICACIONES VÉRTICE, S.L. C/ Ter, 2-4-6. Pol. Ind. El Viso 29006 Málaga. Tfno: 902532432 www.editorialvertice.com
[email protected]
ISBN: 978-84-9931-137-1 DEPÓSITO LEGAL: MA-1895-2012
No está permitida la reproducción total o parcial de esta obra bajo cualquiera de sus formas gráfi cas o aud iovisuales sin la autorización previa y por escrito de los titulares del depósito legal. Impreso en España - Printed in Spain
Dedicado a Eleonora, mi esposa y compañera de muchos desafíos. A mis padres (in memoriam), por su importante esfuerzo y paciencia para proprocionarme la mejor formación posible. Desde el lejano año de 1990, he trabajado en ocho diferentes empresas, y tuve la suerte de haber conocido a compañeros y jefes que han tenido la generosidad de compartir sus conocimientos y experiencias, aportando valor a mi trabajo y fortaleciendo mi carrerra profesional. Este libro contempla, de alguna forma, muchas de las enseñanzas que he recibido a lo largo de todos estos años.
11
INDICE
Prefacio......................................................................................................................................19 Objetivo y convenciones.........................................................................................................21 El PMI y el PMBOK®.................................................................................................................21 Terminología.............................................................................................................................21 Referencias................................................................................................................................22 ¿Qué tienes que saber acerca del Project Management?....................................................23 Organización de la obra...........................................................................................................25 Capítulo 1 - Introducción...................................................................................................................31 Introducción..............................................................................................................................32 1.1 Las Técnicas y las herramientas......................................................................................33 1.2 La documentación..............................................................................................................33 1.3 Entradas y salidas..............................................................................................................35 1.4 ¿Qué es un proyecto?........................................................................................................35 1.5 ¿Por qué los proyectos fallan?.........................................................................................38 1.6 ¿Qué es el Project Management?.....................................................................................38 1.6.1 Ventajas y factores de éxito del Project Management............................................39 1.6.2 ¿Cómo se implementa el Project Management en la organización?....................41 1.7 Los stakeholders del proyecto..........................................................................................42 1.7.1 Stakeholders internos.................................................................................................43 1.7.2 Stakeholders externos................................................................................................43 1.7.3 La gestión de los interesados....................................................................................45 1.7.3.1 Técnicas y herramientas.........................................................................................45 1.7.3.1.1 Matriz poder/interés.........................................................................................45 1.7.3.1.2 Diagrama de Venn............................................................................................46 1.7.3.1.3 Matriz de los interesados................................................................................47 Capítulo 2 - El Ciclo de Vida del Proyecto........................................................................................49 Introducción..............................................................................................................................50 2.1 El ciclo de vida del proyecto.............................................................................................50 2.1.1 Características del ciclo de vida del proyecto.........................................................51 2.1.2 La triple restricción del proyecto..............................................................................52 2.1.3 Las líneas base de un proyecto.................................................................................55 2.2 Los procesos y fases de un proyecto..............................................................................56 2.2.1 Inicio.............................................................................................................................60 2.2.1.1 Reunión de apertura del proyecto..........................................................................63 2.2.2 Planificación................................................................................................................64 2.2.2.1 Relación entre los procesos...................................................................................65 2.2.2.2 ¿Cómo puedo estar seguro de que he planificado lo suficiente?......................67 2.2.2.3 Las estimaciones.....................................................................................................67 2.2.3 Ejecución......................................................................................................................69 2.2.4 Seguimiento y control.................................................................................................69 2.2.5 Cierre............................................................................................................................70 2.2.5.1 Entrega de todos los productos y/o servicios del proyecto...............................71 2.3 Las actividades del proyecto.............................................................................................72
13
2.4 Los entregables del proyecto...............................................................................................72 2.4.1 La lista de entregables del proyecto..............................................................................73 2.5 Caso Práctico......................................................................................................................73 Capítulo 3 - Selección de Proyectos.................................................................................................79 Introducción..............................................................................................................................81 3.1 Criterios para la selección de proyectos.........................................................................81 3.1.1 Criterios financieros para la selección de proyectos.............................................82 3.1.1.1 Analisis beneficio-coste......................................................................................83 3.1.1.2 Punto de equilibrio...............................................................................................83 3.1.1.3 Valor presente neto - VPN...................................................................................84 3.1.1.4 Tasa interna de retorno – TIR..............................................................................87 3.1.1.5 Periodo de reembolso..........................................................................................89 3.1.1.6 Retorno sobre la inversión – RSI........................................................................90 3.1.2 Criterios no financieros para la selección de proyectos........................................90 3.1.2.1 Tributos ponderados...........................................................................................91 3.1.2.2 Toma de decisiones.............................................................................................91 3.1.2.3 Análisis del árbol de decisiones.........................................................................93 3.1.2.4 Proceso de análisis jerárquico...........................................................................93 Capítulo 4 - Gestión de la Integración...............................................................................................99 Introducción............................................................................................................................ 100 4.1 Desarrollo del acta de constitución del proyecto.........................................................101 4.1.1 Técnicas y herramientas..........................................................................................101 4.1.1.1 Juicio de expertos..............................................................................................101 4.1.2 Documentación generada en este proceso...........................................................101 4.2 Desarrollo del plan de proyecto......................................................................................102 4.2.1 Técnicas y herramientas..........................................................................................102 4.2.1.1 Metodología de planificación del proyecto.....................................................102 4.2.1.2 Conocimientos y habilidades de los interesados...........................................103 4.2.1.3 Sistema de información de gestión de proyectos..........................................103 4.2.1.4 Valor del trabajo realizado.................................................................................103 4.2.1.5 Juicio de expertos..............................................................................................103 4.2.2 Documentación generada en este proceso............................................................103 4.3 Gestión y ejecución del plan de proyecto.....................................................................104 4.3.1 Técnicas y herramientas..........................................................................................104 4.3.1.1 Habilidades de gestión en general...................................................................104 4.3.1.2 Conocimientos acerca del producto y/o servicio...........................................104 4.3.1.3 Sistema de autorización de trabajo..................................................................105 4.3.1.4 Evaluación de progresión o reuniones de seguimiento................................106 4.3.1.5 Sistema de información de gestión de proyectos..........................................106 4.3.1.6 Procedimientos de la organización..................................................................106 4.3.1.7 Juicio de expertos..............................................................................................106 4.3.2 Documentación generada en este proceso............................................................106 4.4 Monitorización y control del trabajo del proyecto........................................................107 4.4.1 Técnicas y herramientas..........................................................................................107 4.4.1.1 Juicio de expertos..............................................................................................107 4.4.2 Documentación generada en este proceso............................................................107 4.5 Control integrado de cambios.........................................................................................107 4.5.1 Técnicas y herramientas..........................................................................................108 4.5.1.1 Sistema de control de cambios........................................................................108 4.5.1.2 Estudio de viabilidad..........................................................................................114 4.5.1.3 Gestión de la configuración..............................................................................115 4.5.1.4 Informes de progreso.........................................................................................116 14
4.5.1.5 Sistema de información de gestión de proyectos.........................................117 4.5.1.6 Juicio de expertos.............................................................................................117 4.5.1.7 Reunión de control de cambios.......................................................................117 4.5.2 Documentación generada en este proceso............................................................117 4.6 Cierre del proyecto o fase................................................................................................118 4.6.1 Técnicas y herramientas...........................................................................................118 4.6.6.1 Juicio de expertos.............................................................................................118 4.6.2 Documentación generada en este proceso............................................................118 Capítulo 5 - Gestión del Alcance.....................................................................................................119 Introducción............................................................................................................................ 120 5.1 Recopilar requisitos.........................................................................................................121 5.1.1 Técnicas y herramientas..........................................................................................123 5.1.1.1 Entrevistas.........................................................................................................123 5.1.1.2 Grupos de opinión............................................................................................124 5.1.1.3 Talleres facilitados............................................................................................124 5.1.1.4 Técnicas de creatividad en grupo...................................................................125 5.1.1.5 Técnicas de toma de decisión en grupo........................................................126 5.1.1.6 Cuestionarios y encuestas..............................................................................127 5.1.1.7 Observaciones..................................................................................................127 5.1.1.8 Prototipos..........................................................................................................127 5.1.2 Documentación generada en este proceso............................................................128 5.2 La definición del alcance.................................................................................................128 5.2.1 Técnicas y herramientas..........................................................................................129 5.2.1.1 Requisitos del proyecto...................................................................................129 5.2.1.2 Enunciación del alcance del proyecto............................................................129 5.2.1.3 Planificación gradual........................................................................................130 5.2.1.4 Descomposición...............................................................................................130 5.2.1.5 Juicio de expertos............................................................................................131 5.2.1.6 Análisis del producto.......................................................................................131 5.2.1.7 Talleres Facilitados...........................................................................................132 5.2.2 Documentación generada en este proceso............................................................132 5.3 Creación de la EDT...........................................................................................................132 5.3.1 Técnicas y Herramientas..........................................................................................132 5.3.1.1 Estructura Detallada del Trabajo - EDT..........................................................132 5.3.1.2 Estructura de desglose del producto – EDP..................................................138 5.3.1.3 Otros tipos de estructuras de desglose.........................................................138 5.3.1.4 El diccionario de la EDT...................................................................................139 5.3.2 Documentación generada en este proceso............................................................139 5.4 Verificación del alcance...................................................................................................139 5.4.1 Técnicas y herramientas..........................................................................................140 5.4.1.1 Inspección.........................................................................................................140 5.4.2 Documentación generada en este proceso............................................................140 5.5 Control de cambios del alcance.....................................................................................141 5.5.1 Técnicas y herramientas..........................................................................................141 5.5.1.1 Análisis de variación........................................................................................141 5.5.1.2 Sistema de control de cambios del alcance..................................................142 5.5.1.3 Planificación adicional.....................................................................................142 5.5.2 Documentación generada en este proceso............................................................142 Capítulo 6 - Gestión del Tiempo......................................................................................................143 Introducción............................................................................................................................ 145 6.1 Definición de las actividades...........................................................................................147 6.1.1 Técnicas y herramientas..........................................................................................148 15
6.1.1.1 Estructura detallada del trabajo – EDT...............................................................148 6.1.1.2 Descomposición...............................................................................................148 6.1.1.3 Planificación gradual........................................................................................148 6.1.1.4 Plantillas........................................................................................................... 148 6.1.1.5 Juicio de expertos............................................................................................149 6.1.2 Documentación generada en este proceso............................................................149 6.2 Secuenciación de actividades.........................................................................................149 6.2.1 Técnicas y herramientas..........................................................................................150 6.2.1.1 Diagramas de red..............................................................................................150 6.2.1.2 Método de diagramación con flechas.............................................................150 6.2.1.3 Método de diagramación por precedencia....................................................151 6.2.1.4 Método del camino crítico................................................................................156 6.2.1.5 Determinación de dependencias.....................................................................163 6.2.1.6 Aplicación de adelantos y retrasos.................................................................164 6.2.1.7 Plantillas de red de cronograma.....................................................................164 6.2.2 Documentación generada en este proceso............................................................164 6.3 Estimación de los recursos de las actividades.............................................................165 6.3.1 Técnicas y herramientas..........................................................................................165 6.3.1.1 Juicio de expertos.............................................................................................165 6.3.1.2 Datos de estimación publicados..........................................................................165 6.3.1.3 Estimación ascendente....................................................................................165 6.3.1.4 Software de gestión de proyectos..................................................................166 6.3.2 Documentación generada en este proceso............................................................168 6.4 Estimación de duración de actividades.........................................................................169 6.4.1 Técnicas y herramientas..........................................................................................171 6.4.1.1 Juicio de expertos............................................................................................171 6.4.1.2 Estimación analógica.......................................................................................171 6.4.1.3 Estimación paramétrica...................................................................................172 6.4.1.4 Técnica de evaluación y revisión de programas...........................................173 6.4.1.5 Base histórica de proyectos............................................................................174 6.4.1.6 Juicio de expertos.............................................................................................175 6.4.1.7 Técnica delphi...................................................................................................175 6.4.1.8 Reserva de tiempo............................................................................................176 6.4.2 Documentación generada en este proceso............................................................177 6.5 Desarrollo del cronograma del proyecto.......................................................................177 6.5.1 Técnicas y herramientas..........................................................................................178 6.5.1.1 Método del camino crítico................................................................................178 6.5.1.2 Gestión de proyectos por cadena crítica.......................................................178 6.5.1.3 Nivelación de recursos....................................................................................181 6.5.1.4 Análisis “¿Qué pasa si...?”..............................................................................181 6.5.1.5 Aplicación de adelantos y retrasos.................................................................182 6.5.1.6 Ejecución rápida...............................................................................................183 6.5.1.7 Compresión.......................................................................................................183 6.5.1.8 Gráfico de barras de Gantt...............................................................................185 6.5.1.9 Grafico de hitos.................................................................................................188 6.5.2 Documentación generada en este proceso............................................................189 6.6 Control del cronograma...................................................................................................189 6.6.1.1 Medición del rendimiento.................................................................................190 6.6.1.2 Índice de desempeño del cronograma...........................................................190 6.6.1.3 Software de gestión de proyectos..................................................................190 6.6.1.4 Nivelación de recursos....................................................................................191 6.6.1.5 Análisis “¿Qué pasa si...?”..............................................................................191
16
6.6.1.6 Aplicación de adelantos y retrasos................................................................191 6.6.1.7 Compresión del cronograma...........................................................................191 6.6.1.8 Sistema de control de cambios del cronograma..........................................191 6.6.1.9 Planificación adicional.....................................................................................191 6.6.2 Documentación generada en este proceso............................................................192 Capítulo 7 - Gestión de Costes.......................................................................................................193 Introducción............................................................................................................................194 7.1 Estimación de costes.......................................................................................................196 7.1.1 Técnicas y herramientas..........................................................................................197 7.1.1.1 Juicio de expertos............................................................................................197 7.1.1.2 Estimación por analogía..................................................................................197 7.1.1.3 Estimación ascendente....................................................................................197 7.1.1.4 Estimación paramétrica...................................................................................197 7.1.1.5 Técnica de evaluación y revisión de programas...........................................197 7.1.1.6 Análisis de reserva...........................................................................................197 7.1.1.7 Software de estimación para la gestión de proyectos.................................198 7.1.1.8 Análisis de propuestas para licitaciones.......................................................198 7.1.1.9 Estructura detallada del trabajo - EDT............................................................198 7.1.1.10 Estructura de desglose de costes - EDC.....................................................198 7.1.1.11 Tasas de recursos...........................................................................................200 7.1.1.12 Técnica delphi.................................................................................................200 7.1.1.13 Base histórica de proyectos..........................................................................200 7.1.1.14 Plan de cuentas...............................................................................................200 7.1.2 Documentación generada en este proceso...........................................................201 7.2 Establecimiento del presupuesto...................................................................................201 7.2.1 Técnicas y herramientas..........................................................................................201 7.2.1.1 Suma de costes................................................................................................201 7.2.1.2 Análisis de reserva...........................................................................................201 7.2.1.3 Juicio de expertos............................................................................................201 7.2.1.4 Relaciones históricas.......................................................................................202 7.2.1.5 Conciliación del límite del financiamiento.....................................................202 7.2.2 Documentación generada en este proceso............................................................202 7.3 Control de costes..............................................................................................................202 7.3.1 Técnicas y herramientas..........................................................................................204 7.3.1.1 Valor del trabajo realizado...............................................................................204 7.3.1.2 Proyecciones.....................................................................................................209 7.3.1.3 Índice de desempeño del trabajo por completar...........................................210 7.3.1.4 Índice del desempeño del coste......................................................................210 7.3.1.5 Software de gestión de proyectos..................................................................211 7.3.1.6 Planificación adicional.....................................................................................211 7.3.1.7 Sistema de control de cambios de costes.....................................................211 7.3.2 Documentación generada en este proceso............................................................212 Capítulo 8 - Gestión de la Calidad..................................................................................................213 Introducción............................................................................................................................215 8.1 Planificación de la calidad...............................................................................................216 8.1.1 Técnicas y herramientas..........................................................................................217 8.1.1.1 Análisis beneficio-coste...................................................................................217 8.1.1.2 Análisis de los costes de calidad....................................................................218 8.1.1.3 Diagramas de control.......................................................................................219 8.1.1.4 Estudios comparativos....................................................................................220 8.1.1.5 Diseño de experimentos..................................................................................221 8.1.1.6 Muestra estadística...........................................................................................222
17
8.1.1.7 Diagrama de flujo..............................................................................................222 8.1.1.8 Metodologías propietarias de gestión de la calidad.....................................224 8.1.1.9 Análisis de campos de fuerza.........................................................................225 8.1.1.10 Listas de verificación.....................................................................................227 8.1.2 Documentación generada en este proceso............................................................227 8.2 Aseguramiento de la calidad...........................................................................................227 8.2.1 Técnicas y herramientas..........................................................................................228 8.2.1.1 Auditorias de calidad.......................................................................................228 8.2.1.2 Informe de auditoria.........................................................................................229 8.2.2 Documentación generada en este proceso............................................................229 8.3 Control de calidad............................................................................................................230 8.3.1 Técnicas y herramientas..........................................................................................230 8.3.1.1 Mediciones de calidad......................................................................................230 8.3.1.2 El Ciclo PDCA....................................................................................................232 8.3.1.3 Inspección.........................................................................................................233 8.3.1.4 Gráfico de control.............................................................................................233 8.3.1.5 Listas de verificación.......................................................................................234 8.3.1.6 Diagramas de Pareto........................................................................................236 8.3.1.7 Diagrama de causa-efecto...............................................................................238 8.3.1.8 Muestra estadística..........................................................................................240 8.3.1.9 Análisis de tendencias.....................................................................................241 8.3.1.10 Diagramas de flujo.........................................................................................241 8.3.1.11 Diagramas de interrelación............................................................................242 8.3.1.12 Diagramas de dispersión...............................................................................243 8.3.1.13 Diseño de experimentos................................................................................246 8.3.1.14 Histogramas....................................................................................................246 8.3.1.15 Diagrama matricial..........................................................................................248 8.3.1.16 Matriz de priorización.....................................................................................256 8.3.2 Documentación generada en este proceso............................................................256 Capítulo 9 - Gestión de los Recursos Humanos......................................................................257 Introducción............................................................................................................................258 9.1 Desarrollo de los recursos humanos.............................................................................260 9.1.1 Técnicas y herramientas..........................................................................................261 9.1.1.1 Organigramas...................................................................................................261 9.1.1.2 Relaciones de Trabajo o Redes Sociales.......................................................262 9.1.1.3 Matriz de responsabilidades............................................................................262 9.1.1.4 Estructura de desglose de la organización – EDO.......................................265 9.1.2 Documentación generada en este proceso............................................................266 9.2 Adquisición de personal..................................................................................................267 9.2.1 Técnicas y herramientas..........................................................................................268 9.2.1.1 Asignación previa.............................................................................................268 9.2.1.2 Negociación.......................................................................................................269 9.2.1.3 Adquisición.......................................................................................................269 9.2.1.4 Equipos virtuales..............................................................................................270 9.2.2 Documentación generada en este proceso............................................................270 9.3 Desarrollo del equipo......................................................................................................271 9.3.1 Técnicas y herramientas..........................................................................................271 9.3.1.1 Teoría de Tuckman...........................................................................................271 9.3.1.2 Habilidades interpersonales............................................................................273 9.3.1.3 Formación..........................................................................................................273 9.3.1.4 Reglas básicas..................................................................................................274 9.3.1.5 Reubicación.......................................................................................................274
18
9.3.1.6 Reconocimiento y recompensas..........................................................................275 9.3.2 Documentación generada en este proceso..................................................................275 9.4 Gestión del equipo.................................................................................................................275 9.4.1 Técnicas y herramientas.................................................................................................276 9.4.1.1 Evaluación de rendimiento....................................................................................276 9.4.1.2 Gestión de conflictos.............................................................................................278 9.4.1.3 Registro de incidencias.........................................................................................278 9.4.1.4 Habilidades interpersonales.................................................................................278 9.4.1.5 Diagramas de red...................................................................................................278 9.4.1.6 Histograma de recursos........................................................................................278 9.4.1.7 Calendario de recursos.........................................................................................280 9.4.2 Documentación generada en este proceso..................................................................280 Capítulo 10 - Gestión de las Comunicaciones................................................................281 Introducción.................................................................................................................................. 283 10.1 Identificación de los interesados.......................................................................................291 10.1.1 Técnicas y herramientas...............................................................................................292 10.1.1.1 Matriz poder/interés.............................................................................................292 10.1.1.2 Juicio de expertos................................................................................................292 10.1.2 Documentación generada en este proceso................................................................292 10.2 Planificación de las comunicaciones.................................................................................292 10.2.1 Técnicas y herramientas...............................................................................................293 10.2.1.1 Análisis de requisitos de comunicaciones........................................................293 10.2.1.2 Tecnología de las comunicaciones....................................................................293 10.2.1.3 Modelos de comunicación..................................................................................294 10.2.1.4 Métodos de comunicación..................................................................................296 10.2.2 Documentación generada en este proceso................................................................296 10.3 Distribución de la información............................................................................................296 10.3.1 Técnicas y herramientas...............................................................................................297 10.3.1.1 Sistemas de gestión de la información..............................................................297 10.3.1.2 Lista de distribución de la información.............................................................297 10.3.1.3 Control de versiones............................................................................................298 10.3.2 Documentación generada en este proceso................................................................298 10.4 Gestión de las expectativas de los interesados................................................................299 10.4.1 Técnicas y herramientas...............................................................................................299 10.4.1.1 Métodos de comunicación..................................................................................299 10.4.1.2 Habilidades interpersonales...............................................................................299 10.4.1.3 Habilidades de gestión........................................................................................300 10.4.2 Documentación generada en este proceso................................................................300 10.5 Informes de rendimiento.....................................................................................................300 10.5.1.1 Análisis de variación...........................................................................................301 10.5.1.2 Métodos de proyección.......................................................................................301 10.5.1.3 Sistemas de informes..........................................................................................301 10.5.1.4 Análisis de tendencias.........................................................................................302 10.5.1.5 Análisis del valor del trabajo realizado..............................................................302 10.5.2 Documentación generada en este proceso................................................................302 Capítulo 11 - Gestión de Riesgos...................................................................................303 Introducción.................................................................................................................................. 305 11.1 Planificación de la gestión de riesgos...............................................................................310 11.1.1 Técnicas y herramientas...............................................................................................310 11.1.1.1 Análisis y reuniones de planificación.................................................................310 11.1.2 Documentación generada en este proceso................................................................311 11.2 Identificación de riesgos.....................................................................................................311
19
11.2.1 Técnicas y herramientas........................................................................................313 11.2.1.1 Revisión de la documentación......................................................................313 11.2.1.2 Técnicas de recopilación de información....................................................314 11.2.1.3 Listas de verificación.....................................................................................314 11.2.1.4 Análisis de hipótesis o supuestos................................................................314 11.2.1.5 Técnicas de diagramación.............................................................................314 11.2.1.6 Análisis DAFO.................................................................................................315 11.2.1.7 Juicio de expertos..........................................................................................316 11.2.1.8 Tormenta de ideas..........................................................................................316 11.2.1.9 Técnica de grupo nominal.............................................................................318 11.2.1.10 Técnica Delphi...............................................................................................319 11.2.1.11 Técnica crawford slip...................................................................................319 11.2.1.12 Entrevistas.....................................................................................................319 11.2.1.13 Mapa conceptual...........................................................................................320 11.2.1.15 Estructura de desglose de riesgos - EDR..................................................323 11.2.1.16 Lecciones aprendidas..................................................................................324 11.2.2 Documentación generada en este proceso..........................................................324 11.3 Análisis cualitativo de riesgos......................................................................................324 11.3.1 Técnicas y herramientas........................................................................................325 11.3.1.1 Probabilidad de riesgos y valoración de impactos.....................................325 11.3.1.2 Evaluación de la calidad de los datos sobre riesgos.................................328 11.3.1.3 Categorización de riesgos.............................................................................328 11.3.1.4 Método de los escenarios..............................................................................328 11.3.1.5 Método de los impactos cruzados...............................................................331 11.3.1.6 Evaluación de la urgencia de los riesgos....................................................334 11.3.1.7 Juicio de expertos..........................................................................................334 11.3.2 Documentación generada en este proceso..........................................................334 11.4 Análisis cuantitativo de riesgos....................................................................................334 11.4.1 Técnicas y herramientas........................................................................................336 11.4.1.1 Técnicas de recopilación y representación de datos.................................336 11.4.1.2 Análisis cuantitativo de riesgos y de modelado.........................................336 11.4.1.3 Juicio de expertos..........................................................................................336 11.4.1.4 Entrevistas.......................................................................................................337 11.4.1.5 Análisis del árbol de decisiones...................................................................337 11.4.1.6 Simulación de Montecarlo.............................................................................343 11.4.2 Documentación generada en este proceso..........................................................344 11.5 Plan de respuesta al riesgo...........................................................................................344 11.5.1 Técnicas y herramientas........................................................................................345 11.5.1.1 Estrategias para riesgos negativos o amenazas........................................345 11.5.1.2 Estrategias para riesgos positivos u oportunidades..................................347 11.5.1.3 Plan de contingencia......................................................................................348 11.5.1.4 Gestión de reservas.......................................................................................348 11.5.1.5 Gestión del riesgo residual............................................................................349 11.5.1.6 El plan B...........................................................................................................350 11.5.1.7 Juicio de expertos..........................................................................................350 11.5.2 Documentación generada en este proceso..........................................................350 11.6 Supervisión y control de riesgos.................................................................................351 11.6.1 Técnicas y herramientas........................................................................................352 11.6.1.1 Reevaluación de los riesgos.........................................................................352 11.6.1.2 Auditorías de riesgos.....................................................................................352 11.6.1.3 Análisis de variación......................................................................................352 11.6.1.4 Medición del desempeño técnico.................................................................352
20
11.6.1.5 Análisis de reserva.........................................................................................353 11.6.1.6 Reuniones sobre el estado del proyecto.....................................................353 11.6.1.7 Análisis de hipótesis o supuestos................................................................353 11.6.2 Documentación generada en este proceso..........................................................353 Capítulo 12 - Gestión Compras y Contratos...................................................................355 Introducción............................................................................................................................356 12.1 Plan de compras y contratos........................................................................................357 12.1.1 Técnicas y herramientas............................................................................................357 12.1.1.1 Base histórica de proyectos.........................................................................357 12.1.1.2 Análisis "com prar o hacer"..........................................................................358 12.1.1.3 Análisis del árbol de decisiones...................................................................359 12.1.1.4 Juicio de expertos..........................................................................................359 12.1.2 Documentación generada en este proceso..........................................................359 12.2 Conducción de compras...............................................................................................360 12.2.1 Ciclo de compras....................................................................................................360 12.2.1.1 Preparación y solicitud de propuestas..............................................................360 12.2.1.2 Preselección de los proveedores.......................................................................361 12.2.1.3 Tipos de respuesta...............................................................................................362 12.2.1.4 Licitaciones o convocatorias..............................................................................362 12.2.1.5 Criterios de valoración........................................................................................363 12.2.1.6 Adjudicación del contrato...................................................................................364 12.2.1.7 Confección del contrato......................................................................................364 12.2.2. Documentación generada en este proceso.........................................................365 12.3 Administración del contrato.........................................................................................366 12.3.1 Técnicas y herramientas........................................................................................367 12.3.1.1 Sistema de control de cambios del contrato..............................................367 12.3.1.2 Revisiones e informes de desempeño.........................................................367 12.3.1.3 Inspecciones y auditorías.............................................................................367 12.3.1.4 Sistemas de pago...........................................................................................367 12.3.1.5 Administración de reclamaciones................................................................368 12.3.1.6 Sistema de gestión de registros...................................................................368 12.3.2. Documentación generada en este proceso.........................................................369 12.4 Cierre del contrato.........................................................................................................369 12.4.1 Técnicas y herramientas........................................................................................370 12.4.1.1 Auditorías de la adquisición.........................................................................370 12.4.1.2 Acuerdos negociados....................................................................................370 12.4.1.3 Sistema de gestión de registros..................................................................371 12.4.2. Documentación generada en este proceso........................................................371 Capítulo 13 - Gestión de Conflictos................................................................................373 Introducción............................................................................................................................374 13.1 Las siete fuentes de conflicto en proyectos...............................................................375 13.2 Técnicas de resolución de conflictos..........................................................................375 13.2.1 Alternativa de resolución de disputas............................................................376 13.3 Diez principios para la resolución de conflictos........................................................377 Capítulo 14 - Las Organizaciones...................................................................................379 Introducción............................................................................................................................380 14.1 Tipos de organizaciones...............................................................................................380 14.1.3 La organización matricial.......................................................................................382 Capítulo 15 - El Project Manager............................................................................................385 Introducción............................................................................................................................386 15.1 El Project Manager, ¿nace o se hace?.........................................................................386 15.2 Las responsabilidades de un Project Manager..........................................................387
21
15.3 Las habilidades del Project Manager.............................................................................387 15.4 La certificación PMP®..........................................................................................................389 15.5 El Código de ética y conducta profesional de PMI...........................................................393 Capítulo 16 - 20 Reglas de Oro del Project Management....................................................395 Introducción.................................................................................................................................. 396 Capítulo 17 - Documentos del Proyecto..........................................................................399 Introducción.................................................................................................................................. 400 Apénd ice A - Documentos del Proyecto.........................................................................403 Apéndice B - Siete Proyectos que se convertieron en Siete Maravillas..........................473 Apéndice C - Personas Mencionadas.............................................................................489 Apéndice D - Siglas........................................................................................................ 505 Apéndice E - Listado de Técnicas................................................................................... 506 Bibliografía................................................................................................................................515
22
23
Prefacio Los prefacios son casi como los proyectos: anticipan una realidad. Pero los proyectos, por su parte, anticipan la lectura de una realidad que todavía no se ha hecho realidad. Los prefacios son, además, una prelectura de una realidad concretizada. De hecho, es posible, y muchas veces también recomendable, leer los prefacios solamente cuando se termina la lectura de una obra. Existen libros sin prefacio, de la misma forma que también existen realidades concebidas y construidas sin proyectos formalmente establecidos. Si te digo la verdad, los prefacios podrían incluso ser descartados. En este caso en concreto, me pondría triste, pues no habría sido posible participar de este más reciente y, por qué no decirlo, proyecto “condenado al éxito” de Eduardo Caamaño. En la vida gerencial, en las administraciones públicas o en las empresas, ya no es posible concebir o construir realidades sin proyectos, sinónimo simultaneo de “sueño”, de descripción en el presente, en realidad a ser construida, de visión o de “vista previa” de una voluntad expresa, de un valor a ser obtenido, en una determinada velocidad, de la búsqueda de una verdad aún no comprobada. Visión, valor, velocidad, verdad, atributos incorporados y un compromiso de todo gerente. Un Project Manager es, ante todo, un gerente. Y un gerente, seguramente, lo reconozca o no, sea consciente o no, es, ante todo, un Project Manager. Hace cuarenta años, Laura Dantas, especialista en desarrollo organizacional, compatriota de Eduardo Caamaño, identificaba categorías de profesionales y académicos que lidiaban con el tema al que ella se dedicó como profesional. Lo tomo prestado y lo adapto para el contexto de proyectos, posibles audiencias para este libro. Habrá los “proyectólogos”, investigadores en la búsqueda de la conceptualización derivada del campo. Habrá los proyectistas, especialistas en búsqueda de soluciones del día a día, puesto que estarán en el campo. Habrá los “proyecteólogos” para los cuales la materia del Project Management es una teología, pues todo lo explica y todo lo puede. Otros, los “proyectoleros”, de los cuales hablar de un tema, entrar y estar “en la ola” del Project Management es la manera de seguir en el “top de la ola”. ¿A quién recomiendo esta lectura? A los dos primeros tipos de audiencia, puesto que a los dos últimos sería una gran pérdida de tiempo. Joseph Chias, renombrado autor de marketing en España, durante la presentación de uno de sus libros, comentaba que existen formas diferenciadas de abordar un tema en una obra. Las adapto a este libro, diciendo que una de las formas es la académica, destinada al avance de la teoría. La otra forma, la práctica, que ayuda a resolver problemas. La tercera, práctica con base teórica, que sintetiza, en el actor, los elementos esenciales para la acción consciente y consecuente. Los que van a leer esta obra se encuentran en la tercera categoría. Para los que quieren y necesitan saber más para enseñar y practicar, esta obra servirá como un guíon, un consejero en forma de páginas, como un “vademécum” comentado. Instrumental, pero no instrumentalista. Práctico, como los guías de diagnóstico diferencial de los médicos. Pero no confundas esta obra, con sus 184 herramientas y más de 50 modelos de documentos, como un motor de búsqueda, solamente un glosario más en tu librería.
25
Por detrás de los capítulos, de los flujos, de los formularios, existen muchos casos prácticos, “cicatrices” de experiencias, musculatura fortalecida por los años de aplicación de los conceptos de administración, de marketing, de Project Management, en el duro juego de la vida empresarial, que no pocas veces, le hace valer su etimología, deniega el ocio, deniega la reflexión, desdeña el plano, parte para la acción sin mirar las consecuencias. Voluntad sin visión. Velocidad sin verdad. Verdad sin valor. Me siento honrado por la invitación de escribir el prefacio de este primer libro de Eduardo. Reconozco en su letra las palabras y la práctica del autor, cuya carrera profesional llevo siguiendo desde hace años, desde los tiempos en que, todavía en Brasil, fue construyendo (ya proyectando) esta obra. Ya se van seis años. Fue un placer compartir con él algunos proyectos de consultoría; primero con el joven estudiante, luego con el adulto, dedicado colega de trabajo, y más tarde, como competente y fiable socio. Juntos observamos no solamente la realidad de Brasil, sino también la de Cuba y de México. Te invito a compartir esta experiencia de Eduardo, traducida en libro. Disfrute de la lectura. Aprecie y aprenda, como yo, de la obra del dilecto autor. Luiz Estevam Lopes Gonçalves Administrador. Maestro en Administración Pública Escuela Brasileña de Administración Pública y de Empresas EBAPE Fundación Getulio Vargas. Actualmente, ocupa el cargo de gerente de Operaciones Internacionales, en la Dirección Internacional de la Fundación Getulio Vargas, donde trabaja desde hace seis años. Fue director executivo de la Interamerican Network for Public Administration Education (INPAE), director del Grupo Consultores Asociados, Superintendente de Mesbla S. A. Trabajó, además, en el departamento de administración y recursos humanos del Citibank y American Field Service en Brasil. Como consultor y profesor, ha actuado en las Américas (Argentina, Chile, Estados Unidos y México) Caribe, Europa (España, Italia y Portugal), África (Angola, Cabo Verde e Guinea-Bissau). Director de proyectos de consultoría y formación en proyectos de planificación estratégica, marketing, investigación de marketing internacional y desarrollo empresarial local. Desde hace 40 años trabaja con proyectos de investigación de marketing como ejecutivo de agencias especializadas brasileñas, (IPOM, AUDI-TV, AUDI-CONSUMO, AUDI-MARKET) y también como consultor independiente, actuando en proyectos realizados en Brasil y en el exterior contratado por empresas privadas, nacionales e internacionales, agencias gubernamentales y organismos internacionales.
26
Objetivo y convenciones Esta obra pretende recoger los aspectos prácticos de la puesta en marcha de un proyecto. No es, desde luego, un libro donde se recoja toda la teoría acerca del Project Management, puesto que para ello sería necesario hacer una obra de dimensiones tales que no la haría manejable. El mercado dispone, además, de obras inmejorables de autores consagrados acerca de la teoría del Project Management. Por lo tanto, si usted busca una publicación que le auxilie a la hora de preparar la documentación de un proyecto o que le proporcione las herramientas más adecuadas para realizar estimaciones, tomar decisiones importantes o desarrollar su equipo, creo que esta puede ser la obra adecuada. De todas formas, un libro no puede prescindir de la teoría, aunque mi propuesta sea la de proporcionarle un libro práctico, no puedo dejar de introducirle algunos conceptos teóricos sobre las disciplinas que forman parte del Project Management. No obstante, he tenido el cuidado de introducir la teoría mínima necesaria para que usted pudiera familiarizarse con los conceptos más importantes de cada capítulo.
El PMI y el PMBOK® El Project Management, traducido al español como Dirección Integrada de Proyectos, es una disciplina ampliamente aplicada en las organizaciones de todo el mundo. Su representante más importante, el PMI (Project Management Institute), es actualmente la mayor organización mundial sin ánimo de lucro, dedicada a desarrollar la disciplina de Dirección Integrada de Proyectos. Su sede central está en Pensilvania y tiene más de 219.000 miembros en 125 países. El PMI desarrolla diversos estándares de Project Management alrededor de todo el mundo. Uno de los más conocidos es el Project Management Body of Knowledge (PMBOK®), que es mundialmente reconocido y está aprobado como un estándar por el American National Standards Institute (ANSI) con más de un millón de copias en circulación. Este libro ha sido estructurado y basado en la metodología difundida por el PMI y sus estándares; en concreto, está basado en la versión IV del PMBOK® (actualmente la última versión).
Terminología Uno de los factores clave del éxito de un proyecto es la comunicación eficaz. Para asegurar una comunicación adecuada es necesario establecer un vocabulario consistente, de conceptos precisos y con una fluidez de lenguaje que permita el entendimiento entre los integrantes de un proyecto. Por tratarse de un estándar americano, he decidido añadir la traducción original en inglés de los términos, herramientas, técnicas y documentos utilizados en Project Management, y que son detenidamente explicados en esta obra. Esto facilitará su búsqueda de nuevas fuentes de investigación en otras obras y en internet. Además, los términos de Project Management son reconocidos mundialmente en inglés por los profesionales del sector.
27
Todos los términos en inglés estarán en letra cursiva y vendrán inmediatamente después de su correspondiente al español. Los términos PMI, PMP, Project Management Profesional y PMBOK® son marcas registradas y pertenecen al Project Management Institute.
Referencias Esta obra no pretende traer nada de novedoso. Su objetivo principal es proporcionar al lector una referencia centralizada de las herramientas, las técnicas y los documentos más comúnmente utilizados en el ámbito del Project Management, explicando a fondo cómo se desarrollan y cuál es el momento oportuno de su aplicación Las metodologías citadas a continuación se consideran referencia, principalmente en ámbitos relacionados con el Project Management y estándares de calidad, y en ningún momento esta obra busca con su mención el uso interesado de estas marcas ni manifestar cualquier participación y/o autoría de las mismas. Su mención, por lo tanto, es únicamente formativa, buscando, en todo momento, facilitar a los lectores la comprensión, adaptación y divulgación de las disciplinas, metodologías, estándares y normas presentes en el ámbito del Project Management. Las metodologías de Project Management y calidad considerados estándares internacionales, y cuyas orientaciones son mencionadas a lo largo de esta obra, son los siguientes: Madurez Máxima en Dirección de Proyectos a Nivel Organizacional (Organizational Project Management Maturity Model - OPM3®): Desarrollado bajo la supervisión del PMI, el OPM3® es una norma diferente de las herramientas o modelos disponibles en la actualidad. El OPM3® funciona sobre la base de un ciclo continuo de optimización del conocimiento, la evaluación y la mejora. Diseñado para que fuera fácil de comprender y usar, es escalable y flexible, y puede personalizarse. Funciona con la mayoría de los programas de calidad existentes, a fin de satisfacer las diversas necesidades y objetivos de la organización. Web: http://opm3online.pmi.org; PRINCE2® (Projects IN Controlled Environments): El PRINCE2® fue originalmente desarrollado por la CCTA (Central Computer and Telecommunications Agency) que, actualmente, forma parte de la Oficina de Comercio Gubernamental del gobierno del Reino Unido (Office of Government Commerce - OCG). Desde 1989, se viene usando como un estándar para la gestión de proyectos, sobre todo en el Reino Unido. Este método fue inicialmente desarrollado solo para proyectos TIC, y su última versión, el PRINCE2®, es compatible con la gestión de todo tipo de proyectos. La revisión más reciente se publicó el 16 de junio de 2009 por la OGC siendo denominada esta versión como PRINCE2® 2009 Refresh. Web: www.prince2.com; Método en V (V-Model - German Project Management Method): Es el estándar utilizado para los proyectos de la Administración Federal de Alemania. Es un método de gestión de proyectos comparable al PRINCE2® y describe tanto métodos para la gestión como para el desarrollo de sistemas. Es, además, una representación gráfica del ciclo de vida del desarrollo de sistemas. En él se resumen las principales medidas que deben adoptarse en relación con las prestaciones correspondientes en el marco del sistema informático de validación. Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Se describen las actividades y los resultados que deben producirse durante el desarrollo del producto. La letra “V” significa "Verificación y Validación". Web: www.v-modell.iabg.de;
28
HERMES: Siguiendo el ejemplo del gobierno británico y el alemán, el gobierno de Suiza ha desarrollado su propio método de gestión de proyectos denominado HERMES, que es una metodología de desarrollo de software basada en el método en V. Su objetivo principal es brindar apoyo a todos los implicados en la planificación del proyecto, desde el comprador, al Project Manager y los colaboradores del mismo. El Método HERMES mejora la transparencia del proyecto, facilita el seguimiento de los avances de los trabajos y permite correcciones más rápidas y específicas. Web: www.hermes.admin.ch; ISO 9000: La ISO 9000 y sus series designan un conjunto de normas sobre calidad y gestión continua de calidad, establecidas por la Organización Internacional para la Estandarización (International Organization for Standardization - ISO). Se pueden aplicar en cualquier tipo de organización o actividad orientada a la producción de bienes o servicios. Las normas recogen tanto el contenido mínimo como las guías y herramientas específicas de implantación o los métodos de auditoría. La ISO 9000 especifica la manera en que una organización opera, sus estándares de calidad, tiempos de entrega y niveles de servicio. Web: www.iso.org; Modelo de Madurez de Capacidades (Capability Maturity Model – CMM®): Es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementación de software por la Carnegie-Mellon University para el SEI (Software Engineering Institute). El SEI es un centro de investigación y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de América. Web: www.sei.cmu.edu; Six Sigma®: Es una metodología de mejora de procesos que busca reducir y, si posible, eliminar los defectos o fallos en la entrega de un producto o servicio. El objetivo principal del Six Sigma es alcanzar un máximo de 3,4 defectos por un millón de eventos u oportunidades. Esta cifra es conocida como DPMO (Defects Per Million Opportunities), es decir: 6 Sigma = 3.4 DPMO. En la metodología Six Sigma un defecto se entiende como “cualquier evento en que un producto o servicio no logra cumplir los requisitos del cliente”. Existe una escala de sigmas que clasifica su eficiencia: 1 sigma = 690.000 DPMO (30.23% de eficiencia); 2 sigma = 308.000 (DPMO = 69.12% de eficiencia); 3 sigma = 66.800 DPMO (93.33% de eficiencia); 4 sigma = 6.210 DPMO (99.994% de eficiencia); 5 sigma = 230 DPMO (99.99994% de eficiencia); 6 sigma = 3,4 DPMO (99.9999966% de eficiencia). Obtener la cifra de 3,4 defectos en un millón de oportunidades, es una meta muy ambiciosa, y extremadamente difícil de lograr, pero no imposible. Web: www.isssp.com. Todas las demás marcas registradas que se mencionan, usan o citan en la presente obra son propiedad de los respectivos titulares.
¿Qué tienes que saber acerca del Project Management? El Project Management para muchos es un arte. También podemos decir que es una ciencia, una metodología, una disciplina o, incluso, una filosofía. Gestionar un proyecto conlleva, entre otras cosas, aplicar conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para satisfacer sus requisitos. Es un proceso por el cual se planifica, ejecuta y controla, buscando alcanzar los resultados deseados.
29
Un proyecto, por su naturaleza, necesita de una figura central que pueda conducirlo al éxito, gestionar las expectativas de los interesados y proporcionar los medios y los esfuerzos necesarios para que un proyecto finalice acorde con su plan. Es una práctica bastante distinta de las llevadas a cabo por algunas organizaciones que ponen en marcha proyectos sin dueño, o “sin padre”, o con muchos dueños, cuyas responsabilidades no son claras y, a la hora de un posible éxito, todos quieren llevarse los méritos; por otro lado, cuando ocurre lo contrario, no resta nadie para asumir la responsabilidad. La persona que buscamos para asumir todos estos compromisos es el Project Manager, que será el encargado de gestionar toda una serie de procesos y áreas de conocimiento que interaccionan entre sí y tienen grados de complejidad distintos.
Figura 1: Los elementos del Project Management
En las obras publicadas en inglés, los términos Project Manager y Project Management son conceptos muy claros y, por ello, no es frecuente que aparezcan otros términos para definir dichos conceptos. Por otro lado, en las obras escritas o traducidas en español, el Project Manager puede aparecer como “Gerente de Proyectos”, “Gestor de Proyectos”, “Director de Proyectos” o “Administrador de Proyectos”. De la misma forma, el Project Management, a veces, es traducido como “Gerencia de Proyectos”, “Gestión de Proyectos”, “Dirección Integrada de Proyectos” o “Administración de Proyectos”. Cada uno de estos términos puede tener diferentes matices y/o interpretaciones y, por lo tanto, son muchas veces utilizados sin un criterio correctamente definido. Para evitar confusiones, esta obrará mantendrá los términos originales del inglés de Project Manager y Project Management.
30
Organización de la obra Igual que las distintas fases de un proyecto, los capítulos de este libro son independientes, pero, al mismo tiempo, se enlazan entre sí. El contenido está dividido de esta forma:
·
Capítulo 1 - Introducción: Presenta los conceptos básicos del proyecto, la definición de Project Management y los personajes implicados.
·
Capítulo 2 - Ciclo de vida del proyecto: El ciclo de vida del proyecto es el conjunto de actividades necesarias para alcanzar el objetivo del proyecto. Estas actividades son organizadas o agrupadas en fases para facilitar su gestión.
·
Capítulo 3 - Selección de proyectos: Las organizaciones necesitan adoptar metodologías y/o utilizar técnicas que les permitan elegir los proyectos que puedan aportar los mejores beneficios, por una cuestión principalmente financiera, pero también por una cuestion de preservación de imagen de organización competitiva y, sobre todo, competente. Este capítulo explica las técnicas más utilizadas para elegir los proyectos más adecuados para una organización.
·
Capítulo 4 - Gestión de la integración: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que los varios elementos del proyecto estén adecuadamente coordinados.
·
Capítulo 5 - Gestión del alcance: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto incluya todo el trabajo necesario, y solamente el necesario, para completar el trabajo con éxito.
·
Capítulo 6 - Gestión del tiempo: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar la planificación y la ejecución del proyecto en un plazo adecuado. Esta área incluye también el levantamiento de las actividades del proyecto (su definición, secuencia y duración estimada).
·
Capítulo 7 - Gestión de costes: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto será ejecutado dentro del presupuesto aceptado. Esta área incluye también las estimaciones de los costes del proyecto, la asignación del presupuesto y el control de los costes.
·
Capítulo 8 - Gestión de la calidad: Incluye los procesos, técnicas, herramientas y documentos necesarios para asegurar que el proyecto irá satisfacer las necesidades por las cuales fue iniciado. Esta área también incluye la planificación, la garantía y el control de la calidad.
·
Capítulo 9 - Gestión de los recursos humanos: Incluye los procesos, técnicas, herramientas y documentos necesarios para realizar el uso más efectivo de las personas involucradas en el proyecto. Esta área también incluye la planificación organizacional, la formación y el desarrollo del equipo del proyecto.
·
Capítulo 10 - Gestión de las comunicaciones: Incluye los procesos, técnicas,
31
herramientas y documentos necesarios para asegurar la adecuada generación, diseminación y almacenamiento de las informaciones del proyecto. Esta área también incluye la planificación y la distribución de la información.
32
•
Capítulo 11 - Gestión de riesgos: Incluye los procesos, técnicas, herramientas y los documentos relacionados con la identificación y análisis de los riesgos del proyecto. Esta área también incluye la identificación de los riesgos, su cuantificación y establecimiento de medidas preventivas y correctivas.
·
Capítulo 12 - Gestión de compras y contratos: Incluye los procesos, técnicas, herramientas y documentos necesarios para la adquisición de bienes y servicios fuera de la organización ejecutora del proyecto. Esta área también incluye la confección de plan de compras, levantamiento de potenciales proveedores, licitaciones, contratación, administración y cierre de contratos.
·
Capítulo 13 - Gestión de conflictos: Un conflicto ocurre cuando dos situaciones antagónicas no pueden darse simultáneamente. En muchos casos, ambas situaciones presentan importantes ventajas y desventajas, lo que resulta difícil elegir la opción más adecuada. A veces, los conflictos ocurren entre personas influyentes en el proyecto que no admiten que sus intereses sean ignorados. Son situaciones que normalmente repercuten negativamente en el resultado del proyecto. Este capítulo incluye las técnicas más eficientes de la gestión de conflictos.
·
Capítulo 14 - Organizaciones: El tipo de organización dependerá del sector de actuación de la empresa, de los tipos de proyectos que desarrolla y de la complejidad de la empresa. En este capítulo se analizarán los tipos más comunes de organizaciones y su relación con los proyectos;
·
Capítulo 15 - El Project Manager: Cuando un proyecto es puesto en marcha, un equipo profesional empieza a llevar a cabo todas las actividades definidas en el plan. Desde hace no mucho tiempo, este trabajo era realizado de forma descoordinada, ya que cada profesional involucrado desarrollaba su labor de forma independiente, sin la supervisión de una figura central. No había un norte común, lo único que existían eran requisitos sueltos que iban siendo cumplidos sobre la marcha y, con mucha suerte, se encajaban para formar un producto o resultado. Es por esta razón que surge la figura del Project Manager, un profesional independiente y habilitado para coordinar las actividades y conducir el proyecto a su objetivo planificado.
·
Capítulo 16 - 20 reglas de oro del Project Management: Como he mencionado anteriormente, el Project Management es, para muchos profesionales, un arte. Una búsqueda constante de equilibrio en que el Project Manager será constantemente puesto a prueba, lidiando conflictos, revisando estimaciones y soportando presiones por parte del cliente, de los patrocinadores y sus superiores. Como profesional, el Project Manager debe seguir unas pautas imprescindibles para obtener resultados favorables. Este capítulo trata de aportar algunas “reglas de oro” que no pueden ser ignoradas.
·
Capítulo 17 - Documentos del proyecto: Uno de los factores de éxito de un proyecto es la documentación de su desarrollo, desde la fase inicial hasta el cierre. La documentación es crítica para todo el equipo que desarrolla el proyecto y es fundamental para el cliente. Son muchos los documentos que forman parte de un proyecto y cada uno tiene su importancia acorde con el momento en que es aplicado. Este capítulo presenta la forma adecuada de confeccionar, organizar y gestionar los documentos utilizados en proyectos, desde su fase inicial hasta el cierre.
33
Además, esta obra presenta una serie de Apéndices de relevante contenido:
·
Apéndice A - Documentos del proyecto: Facilita un amplio listado de documentos que componen la documentación básica que un proyecto debe tener, organizada por las fases del ciclo de vida de un proyecto. Cada documento incluye una breve descripción de su uso y objetivos, y además, sugiere los campos mínimos que deberían formar parte de su composición.
·
Apéndice B - Siete proyectos que se convertieron en siete maravillas: En este Apéndice, analizaremos las siete maravillas del mundo antiguo bajo en enfoque del Project Management. Todas estas construcciones, sin lugar a dudas, han pasado por algún tipo de planificación, se encontraron bajo innumerables riesgos y, de alguna forma, contaba con alguna figura similar al Project Manager, para la dirigir todo el proyecto.
·
Apéndice C - Personas mencionadas: Las personas que aparecen en este Apéndice han sido mencionadas a lo largo de toda esta obra. Todos ellos han contribuido, de alguna forma, en el enriquecimiento y la comprensión de la que ponemos llamar “filosofía del Project Management”.
·
Apéndice D - Siglas: Presenta un listado de las siglas más comúnmente utilizadas en el ámbito del Project Management.
·
Apéndice E - Listado de técnicas: Este apéndice facilita un listado de todas las técnicas presentadas en este libro.
34
Un poco de teoría...
36
Capítulo 1 Intro ducción “Un viaje de mil millas comienza con el primer paso” Lao Tsé1, filósofo chino
38
Introducción Eric Verzuh2, en su libro The Fast Forward MBA in Project Management, hace una mención a un texto bíblico que podemos, de alguna forma, relacionarlo con el Project Management. En el Libro de Lucas3, capítulo 14 (28-30), se encuentra el siguiente texto: "Porque ¿quién de vosotros, queriendo edificar una torre, no se sienta primero y calcula los gastos, a ver si tiene lo que necesita para acabarla? No sea que después de que haya puesto el cimiento, y no pueda acabarla, todos los que lo vean comiencen a hacer burla de él, diciendo: «Este hombre comenzó a edificar y no pudo acabar»". Este pasaje bíblico nos demuestra que en aquella época ya había inquietudes muy similares a las que afrontamos hoy en día. Desde tiempos muy remotos, algunas tribus se reunían para construir abrigos y cultivar la tierra, labores que, aunque primitivas, exigían un mínimo de planificación. Desde hace más de cinco mil años, el hombre construye templos monumentales como las pirámides del antiguo Egipto, la gran muralla China o los acueductos romanos, emprendimientos que seguramente contaban con la coordinación de alguna figura muy similar al Project Manager de nuestros días. Es casi seguro que Imhotep 4, el primer arquitecto conocido en la historia, responsable de la construcción de la primera gran pirámide, la “pirámide escalonada de Saqqara”, sufrió los problemas típicos de un Project Manager moderno: la pirámide necesitó la extracción, acarreo y montaje de miles de toneladas de piedra; desafío notable, ya que nunca se había usado anteriormente en grandes construcciones. Tuvo que organizar todo el proceso de construcción, controlando el trabajo y a cientos de obreros, y muy probablemente tuvo problemas de plazos y recursos, sin contar la presión ejercida por su patrocinador, el faraón Necherjet5. Fue a partir del siglo XX cuando el Project Management empezó a definir los estándares que conocemos actualmente, principalmente a partir de la década de los 50, durante la guerra fría, donde se desarrollaron proyectos militares de gran complejidad, como fueron los espaciales y de defensa. El proyecto Manhattan, que culminó en la fabricación de la primera bomba atómica de la historia, es reconocido como el primer proyecto que utiliza técnicas modernas de Project Management. En aquella época, se evidenció la necesidad de coordinar los equipos y las disciplinas diferentes que trabajaban de forma simultánea en un mismo proyecto que requerían el trabajo concurrente y sincronizado. Bernard Schriever6, un general de la fuerza aérea estadounidense que se encargó, durante los años 50 y 60, de competir y ganar la batalla a la Unión Soviética en la construcción de misiles de medio y largo alcance, y de trasladar al espacio la carrera armamentística entre las dos superpotencias, es considerado como uno de los padres del Project Management actual, por haber desarrollado durante la guerra fría el concepto de concurrencia, integrando todos los elementos del plan de desarrollo en un solo programa y presupuesto, ejecutándolos y controlándolos en paralelo y no secuencialmente. De esta forma, logró reducir considerablemente los tiempos de ejecución de los proyectos militares que eran realizados en aquel entonces, como era el proyecto Thor (sistema de armas ideado para disparar proyectiles cinéticos desde la órbita terrestre para dañar objetivos en el suelo). Con el tiempo, estas técnicas y herramientas fueron siendo mejoradas y aplicadas de acuerdo con el tipo de proyecto desarrollado y con cada estructura organizacional. Siguiendo los pasos de la industria militar, la industria automovilística comenzó a aplicar las técnicas del Project
39
Management, con el objetivo de coordinar equipos funcionales diferentes.
40
Comenzaron entonces a surgir las técnicas que conocemos actualmente, como la descomposición de tareas (EDT – Estructura Detallada de Trabajo), los cronogramas y los histogramas. La propia tecnología naturalmente fue colaborando en la optimización y el uso apropiado del Project Management mediante programas informáticos que realizan cálculos y simulaciones y que gestionan una cantidad ingente de documentos de un proyecto. Actualmente, el Project Management ha emergido como una metodología de administración esencial para la organización, sobre todo en las empresas cuyas políticas se enfocan a la planificación y el control de sus actividades. Prácticamente, todos los objetos que forman parte de nuestro día a día, como los móviles, ordenadores, coches, entre otros, son diseñados y desarrollados bajo las técnicas del Project Management. Los proyectos, además, forman parte de nuestro cotidiano. Es un esfuerzo que tenemos que invertir para generar un resultado que puede ser tanto profesional como personal. Infelizmente, las estadísticas muestran que la gran mayoría de los proyectos termina después del plazo definido, consumiendo mucho más que los presupuestos adjudicados y, en muchos casos, aportando una calidad inferior a la deseada. Algunos proyectos ni siquiera llegan a su fin, son simplemente abandonados porque no llegaban a ningún sitio. Es por estas y otras razones por lo que, desde los egipcios hasta la actualidad, ha sido necesario desarrollar, de alguna manera, una metodología que pudiese integrar todas las necesidades de un emprendimiento, sea cual fuese, de forma que los objetivos pudiesen ser alcanzados satisfactoriamente.
1.1 Las Técnicas y las herramientas La palabra técnica tiene origen del griego τέχνη, y es un conjunto de conocimientos prácticos utilizados para obtener un resultado concreto, en el campo del arte, de la ciencia, de la tecnología o en cualquier otra actividad. El dominio de una determinada técnica requiere una destreza que puede ser manual o intelectual y que, generalmente, depende de la utilización de herramientas. La herramienta, por su parte, es definida por la Real Academia Española como “instrumento, por lo común de hierro o acero, con que trabajan los artesanos”. El origen de la herramienta está íntimamente ligado al origen de la humanidad. Una de las primeras herramientas utilizadas por el hombre fue el mazo, que fue evolucionado a través del tiempo, hasta convertirse en el martillo, tal y como lo conocemos a día de hoy. Han pasado los siglos, el hombre ha evolucionado y, con él, también han evolucionado las herramientas. Ambas, tanto las técnicas como las herramientas, fueron las responsables, mediante el conocimiento del hombre, de las grandes hazañas de la humanidad, desde la construcción de los primeros hogares de la antigüedad, hasta la llegada del hombre a la luna, en 1969.
1.2 La documentación Uno de los factores de éxito de un proyecto es el desarrollo de una documentación completa y bien estructurada, desde la fase inicial hasta su cierre. La documentación es crítica para todo el equipo que desarrolla el proyecto y fundamental para el cliente. Además, una vez finalizado el proyecto, su documentación será una valiosa fuente de consulta, de donde se podrá extraer informaciones importantes, como las previsiones realizadas a determinadas actividades, planes, estimaciones,
41
etcétera. Son muchos los documentos que forman parte de un proyecto y cada uno tiene su importancia, acorde con el momento que es aplicado. Juntos constituyen una herramienta poderosa, que dará respaldo a todas las acciones realizadas por el Project Manager y su equipo, y se convertirá en una importante base histórica de consulta para futuros proyectos similares. La documentación también sirve para:
·
Referencia para futuros cambios: Aunque el proyecto esté completo y entregado, el cliente podrá solicitar en el futuro un upgrade del proyecto original, añadiendo nuevas funciones o mejoras que, en su momento, no existían. Son casos que suelen ocurrir, por ejemplo, en proyectos tecnológicos. La documentación podrá, por lo tanto, servir como base para la planificación de un nuevo proyecto.
·
Datos históricos para estimaciones de plazos y costes: Proyectos completados con éxito son una excelente fuente de información para proyectos futuros siempre que su documentación esté completa y haya sido desarrollada adecuadamente. La estimación de costes y plazos, por ejemplo, no suele ser una tarea sencilla, y la posibilidad de poder acceder a estimaciones anteriores podrá ser de gran valor para realizar nuevas estimaciones más realistas.
·
Apoyo al Project Managers novatos: La carrera del Project Manager es fundamentada a base de mucho estudio. Un Project Manager es un profesional que se dedica al desarrollo de muchas áreas de conocimiento y la documentación de un proyecto siempre será una excelente fuente de estudio. ¿Cómo se ha desarrollado la EDT de un determinado proyecto? ¿Cómo se llegó a esta decisión? ¿Por qué ha sido necesario realizar un cambio tan significativo en una fase tan avanzada? Estas, entre otras cuestiones que se encuentren correctamente registradas en la documentación de un proyecto, serán muy útiles a las nuevas generaciones del Project Managers.
·
Apoyo al equipo del proyecto: Como referencia, la documentación del proyecto podrá ayudar al equipo ejecutor a lidiar con situaciones inesperadas. Un problema similar puede haber ocurrido en algún proyecto anterior y su documentación podrá aportar aclaraciones importantes.
·
Referencia para evaluaciones: En muchas organizaciones, se utiliza la documentación para evaluar la performance del Project Manager y de su equipo en proyectos similares.
42
1.3 Entradas y salidas El PMBOK® basa su metodología de gestión de procesos en entradas, herramientas y salidas. Podemos imaginar cada proceso como si se tratara de una máquina que recoge las entradas (la información recopilada para el proyecto) y la transforma en salidas, a través de herramientas (fórmulas matemáticas, gráficos, estimaciones...). Las salidas darán el soporte necesario para que el proyecto avance sin incidencias (cronogramas, líneas base, estimaciones, planes de contingencia, análisis de riesgo...). Todos los procesos del Project Management basados en la guía PMBOK® poseen entradas, herramientas y salidas.
Figura 2: Entradas y salidas de un proyecto
·
Entradas: Toda y cualquier información recopilada en reuniones, datos históricos, entrevistas, entre otros.
·
Técnicas y herramientas: Procedimientos y recursos utilizados para procesar las entradas recibidas que serán posteriormente transformadas en salidas.
·
Salidas: La documentación o los recursos que serán utilizados para dar soporte al Project Manager y a su equipo a lo largo del ciclo de vida del proyecto (planes, cronogramas, estimaciones, presupuestos, manuales...).
1.4 ¿Qué es un proyecto? Un proyecto es una actividad que puede desarrollarse tanto en el ámbito personal como en el empresarial. Se trata de un intento de lograr un objetivo específico mediante la ejecución de determinados trabajos previamente planificados, bajo un estricto seguimiento y control de fases interdependientes. Para que un emprendimiento pueda ser considerado un proyecto, debe poseer las siguientes características:
·
Ser un emprendimiento temporario: Un proyecto se caracteriza por tener un comienzo y un fin definidos. Aunque ambas fechas puedan cambiar por razones ajenas, llegará el momento en que el proyecto será iniciado y tendrá que tener su fin formalizado. Normalmente, el final se alcanza cuando se ha logrado el objetivo del proyecto y los interesados acepten, formalmente, su finalización.
43
Sin embargo, en algunos casos, desgraciadamente muy frecuentes, un proyecto puede ser “forzado” a terminar cuando su ejecución no alcanza el resultado esperado, o cuando el proyecto empieza a consumir una cantidad de recursos muy superior a la inicialmente establecida, y la inversión realizada deja de ser viable. La duración de un proyecto puede variar desde unos pocos días, como, por ejemplo, la reforma de una cocina, o puede llegar a varios años, como fue el caso del proyecto que llevó el hombre a la luna. Además, todo proyecto debe empezar con alguna documentación inicial, que declara el inicio de su ciclo de vida.
·
Tener limitaciones: Los proyectos normalmente cuentan con recursos limitados. Estos pueden ser financieros, de plazo, de personal o de maquinaria. La cantidad de recursos dedicada a un proyecto dependerá, sobre todo, de la capacidad financiera de la organización o de la disponibilidad de los recursos dentro de la organización.
·
Ser realizado por personas: Y son emprendidos en todos los niveles de una organización. Pueden ser desarrollados por una única persona o por todo un departamento. Pueden involucrar a una pequeña oficina o pueden cruzar fronteras afectando a decenas de empresas. Normalmente, el equipo formado para realizar un proyecto raramente se mantiene tras su cierre. La mayoría de los proyectos son ejecutados por un equipo creado con el propósito único de acometerlos, y es disuelto cuando se completa el proyecto.
·
Ser realizado para crear un producto o servicio único: Llevar a cabo un proyecto conlleva hacer algo que no ha sido hecho antes y que no será hecho otra vez (bajo las mismas condiciones) y por esta razón es considerado “único”. Aunque muchos proyectos poseen características muy similares, siempre habrá algún factor que los distinga. Podemos imaginar, por ejemplo, la construcción de una urbanización de diez edificios que tendrán la misma estructura y fachada. La construcción de cada edificio es un proyecto único, aunque todos los edificios sean iguales y estén ubicados sobre el mismo terreno. Eso porque cada edificio podrá ser construido en diferentes épocas: uno en el verano, el otro en el invierno; por personal distinto: unos más eficientes y capacitados que otros, y en diferentes condiciones económicas o financieras, lo que obliga a que la construcción de cada edificio necesite de un plan de proyecto específico.
·
Ser elaborado de forma progresiva: El concepto de elaboración progresiva es la forma por la cual los proyectos son desarrollados bajo los estándares del Project Management. El plan diseñado para el proyecto es ejecutado paso a paso, progresando a través de incrementos y es realizado cuidadosa y detalladamente. Un proyecto es definido en principio de forma muy genérica y se van incrementando los detalles a medida que el equipo del proyecto desarrolle mejor el entendimiento del servicio o producto resultante. De esta forma, el plan de proyecto recibirá un flujo constante de información renovada y, sobre todo, más precisa y completa.
·
Tener un objetivo definido: Todo proyecto intenta lograr un objetivo final. Para el cliente, lo que realmente importa es que el proyecto diseñado resulte en un producto o servicio cuya calidad cumpla con sus requisitos. Para la empresa ejecutora, el objetivo primario es entregar el proyecto dentro del plazo y presupuesto estimados y que los resultados alcanzados favorezcan su posición en el mercado.
44
Generalmente, el objetivo de un proyecto se define en función del alcance, tiempo y coste. Como ejemplos de proyectos podemos incluir:
· · · · · · · ·
El desarrollo de un nuevo producto o servicio. La realización de una boda. El diseño de un nuevo avión. La reforma de un local. La construcción de un puente. La implantación de un nuevo sistema de telefonía. La realización de un espectáculo. El rodaje de una nueva película.
Todos los proyectos poseen un grado de incertidumbre (o riesgo), que, como se podrá apreciar en el capítulo 11, Gestión de riesgos, pueden ser confrontados, reducidos, transferidos o evitados, todo dependerá de la política de la organización y del estilo de gestión del Project Manager asignado. Normalmente, el equipo del proyecto realiza una planificación antes de la fase de ejecución del proyecto. Esta planificación es preparada en base de ciertos supuestos y estimaciones, como, por ejemplo, el coste, el tiempo y la disponibilidad de los recursos necesarios para la ejecución del proyecto. Basado en las experiencias de proyectos anteriores se podrá también estimar la probabilidad y el impacto de incidencias que pueden ocurrir durante su ejecución. Conforme avanza el proyecto, si las actividades programadas son ejecutadas sin grandes incidencias, el grado de incertidumbre suele disminuir, puesto que muchas de las suposiciones iniciales serán reemplazadas por hechos reales. Por ejemplo, una vez que se termina la programación del primer módulo de un programa informático, se podrá estimar mejor la cantidad de tiempo y esfuerzos necesarios para iniciar el siguiente módulo. Sin embargo, aunque el grado de incertidumbre sea menor en fases más avanzadas del proyecto, el nivel de riesgo se verá incrementado, ya que el impacto causado por una incidencia importante repercutirá de forma más contundente.
Existe un concepto equivocado de que un proyecto es algo muy complejo y de difícil gestión, y por ello se han desarrollado tantas herramientas, técnicas y documentos. Pero, si nos paramos un momento a pensar, estamos, a veces sin darnos cuenta, planificando y ejecutando una serie de pequeños proyectos todos los días, tan sencillos como salir de compras un sábado por la tarde. Para ello, es necesario planificar la hora en la que pretendemos salir de casa, qué medio de transporte utilizaremos, si llevamos el coche, cuál será el recorrido elegido, si hay gasolina suficiente y dónde aparcaremos. Además, para salir de compras un sábado por la tarde, hay que tener en cuenta un presupuesto orientativo de gastos los posibles riesgos implicados en este sencillo paseo vespertino (lluvia, dificultades de aparcar, atascos...).
45
1.5 ¿Por qué los proyectos fallan? Un estudio realizado por las empresas Gartner Inc en 2002 nos revela que un proyecto tiene una gran probabilidad de no cumplir satisfactoriamente las estimaciones realizadas. Sus resultados acusan lo siguiente:
· · · ·
El 90% de los proyectos ejecutados son entregados con retraso. El 50% son entregados con un presupuesto mayor que el previsto. El 50% no cumple sus objetivos. El 30% son cancelados antes de su conclusión.
De acuerdo con uno de los autores más conocidos del Project Management, el doctor. J. Davidson Frame7, los proyectos fallan mayoritariamente por dos razones: a) fallos de estimaciones, y b) fallos en la implementación. Jason Charvart8, autor del libro Project Management Methodologies, nos revela otras de las principales razones de fracaso en los proyectos:
· · · · · · · ·
El coste y los plazos inicialmente estimados no son revisados. Los planes no son seguidos correctamente. El Project Manager no tiene formación suficiente. El alcance del proyecto cambia sin control. La metodología aplicada no es la correcta. La comunicación es escasa. No se realizan suficientes pruebas. La teoría del Project Management no es aplicada correctamente.
1.6 ¿Qué es el Project Management? La situación que describiré a continuación no es exclusiva del Project Management. Infelizmente, ocurre en muchos ámbitos, como el derecho, la economía o, aún peor, en la medicina. Hay mucha gente que piensa que puede gestionar un proyecto comprando un programa o leyendo un par de libros. El Project Manager es una profesión que, aunque todavía no esté totalmente reconocida en España, tiene un peso importantísimo en EEUU y en varios países de Europa. La profesión de Project Manager exige mucha preparación y, sobre todo, experiencia suficiente para aplicar correctamente sus conocimientos y habilidades a las actividades del proyecto para satisfacer sus requisitos. Es un proceso por el cual se planifica, se ejecuta y se controla, buscando alcanzar los resultados deseados. Es un trabajo que normalmente involucra:
·
Demandas contrapuestas sobre alcance, tiempo, coste, riesgos y calidad: Como veremos más adelante, un proyecto es un sistema dinámico que tiene que mantenerse constantemente en equilibrio. Gestionar un proyecto es un esfuerzo que conlleva a administrar una serie de actividades integradas. Si una determinada actividad no produce los resultados esperados, podrá afectar a otras áreas del proyecto. Un cambio en el alcance, por ejemplo, casi siempre afectará el coste del proyecto, así como la reducción del plazo de entrega de un producto, y por ello, podrá repercutir negativamente en su calidad.
46
•
Interesados con diferentes expectativas y necesidades: Los interesados, según explica la sección 1.7, tienen diferentes intereses en el desarrollo de un proyecto y poseen diferentes necesidades y expectativas. La expectativa de un interesado normalmente es subjetiva y, a veces, difícil de satisfacer, puesto que cada individuo posee diferentes niveles de valor. Por esta razón es importante, desde la fase inicial del proyecto, poner las cosas muy claras a los interesados, definiendo correctamente sus requisitos, de forma que sus expectativas se transformen en necesidades identificadas y reales.
·
Planificación, control y organización de las actividades que forman parte del proyecto: Es imprescindible que se realice un seguimiento y un control del proyecto durante su ejecución. Suena demasiado obvio, pero son muchas las organizaciones que nunca han hecho un plan y, en algunos casos, hay empresas que poseen la triste mentalidad de que “hacer un plan es un trabajo añadido innecesario”. Por otro lado, no tiene sentido exagerar en la planificación de un proyecto, si este no lo necesita. La planificación tiene que ser siempre proporcional al tamaño y sobre todo a la complejidad del proyecto. Por ejemplo, un proyecto muy pequeño puede necesitar tan solamente de una buena planificación hecha en Excel, donde se establezcan las líneas bases mínimas necesarias.
1.6.1 Ventajas y factores de éxito del Project Management Podemos decir que un proyecto bien sucedido es aquel que ha sido desarrollado dentro de las expectativas de tiempo, coste y calidad. Además, el cliente debe sentirse satisfecho con el trabajo realizado y/o el producto/servicio entregado. Conforme avancemos, nos daremos cuenta de la cantidad de planificación que implica la puesta en marcha de un proyecto. De hecho, planificar, aunque sea fundamental, no es suficiente para lograr buenos resultados. Para lograr el éxito en los resultados establecidos por la organización, es imprescindible contar también con:
·
La información correcta, completa y actualizada para poder planificar, ejecutar y controlar un proyecto de forma adecuada.
·
La comunicación eficaz, exacta y distribuida a las personas correctas en el tiempo apropi ado.
·
El compromiso de las personas involucradas para hacer las cosas bien, evitando conflictos y trabajando en sinergia.
Entre los beneficios que nos puede aportar el Project Management podemos destacar:
· · · · · · ·
Reducción del ciclo de desarrollo. Reducción de costes. Decisiones más eficaces. Menos improvisación. Cumplimento de plazos. Anticipación de problemas. Creación de un producto/servicio de calidad.
47
·
Comunicación eficaz.
48
No obstante, históricamente, los proyectos tienen una tasa de éxito muy baja. Cerca del 25% de los proyectos son concluidos con éxito. Es decir, el 75% de los proyectos no logra alcanzar los objetivos establecidos. No obstante, existen algunas reglas básicas que pueden minimizar el riesgo de que un proyecto sea incluido en esta triste estadística:
·
Tener los objetivos claramente definidos: Incluido el compromiso del equipo para alcanzar todas las metas definidas.
·
Un proyecto necesita planificación: De la misma manera, es imprescindible que se realice un control del proyecto durante su ejecución.
·
Contar con un Project Manager competente: Un profesional que desarrolle esta función debe tener las habilidades inherentes de su puesto, como detalla el capítulo 15, El Project Manager, que es el principal responsable del proyecto.
·
Apoyo de la dirección: Es muy importante que la dirección de la organización sea consciente de la importancia del proyecto y proporcione todos los medios necesarios para asegurar su buen desarrollo.
·
Tener un equipo de proyecto competente: Un proceso de selección bien planificado y la inversión en formación son factores clave para un proyecto bien desarrollado ya que su éxito depende de la buena labor del equipo;
·
Disponibilidad suficiente de recursos: Si existe un factor que puede arruinar un proyecto es la falta de recursos, sean financieros, de personal o de equipos. Antes de empezar, el Project Manager debe asegurarse de que podrá disponer de los recursos suficientes para desarrollar un proyecto.
·
Canales de comunicación adecuados: La información es uno de los factores clave de éxito, que deberá fluir de una forma controlada que alcance a las personas correctas en el momento adecuado.
·
Mecanismos de control: Un proyecto no puede sufrir demasiadas desviaciones que modifiquen la estructura del plan original. El Project Manager debe contar con mecanismos e instrumentos que le permitan mantener el proyecto dentro de la línea base establecida.
·
Feedback constante: Todos los involucrados en el proyecto deben intercambiar opiniones, sugerencias, experiencias o cualquier otra información que colabore con el avance del proyecto. Reuniones de seguimiento y elaboración de informes deben formar parte de las actividades rutinarias del proyecto.
·
Respuestas inmediatas al cliente: Es fundamental mantener al cliente siempre informado, aunque no se traten de buenas noticias. El cliente puede ser un gran aliado, pero, al mismo tiempo, puede tornarse un gran escollo. Todo dependerá de la relación que el Project Manager mantenga con él.
·
Mecanismos que permitan afrontar los problemas: Todo proyecto necesita de un plan
49
de contingencia (descrito en la sección 11.5.1.3) o cualquier otro mecanismo que permita que el equipo reaccione y aplique la respuesta más adecuada.
50
1.6.2 ¿Cómo se implementa el Project Management en la organización? ·
Diseminando en toda la organización sus principios y metodologías: Para poder desarrollar de manera eficaz el Project Management en las empresas, es necesario, principalmente, adoptar una cultura volcada en la gestión integrada de proyectos, involucrando y capacitando sus equipos de trabajo y disponiendo de personal cualificado que comprenda y que, ante todo, valore el Project Management.
·
Desarrollando individuos y formando equipos de proyecto: Trabajar utilizando la metodología del Project Management es, sobre todo, trabajar en equipo. Los individuos involucrados en cada proyecto deben trabajar en sinergia, creando resultados que maximicen las cualidades de cada uno de los recursos asignados al proyecto.
·
Implementando normas y procedimientos: Otro factor importante en el Project Management es disponer de herramientas que puedan soportar de forma adecuada las gestiones desarrolladas por el Project Manager. El mercado dispone de una serie de soluciones a las empresas que permiten aumentar la eficacia de su gestión, integrando los departamentos de la empresa y unificando la información. De este modo, se puede obtener, en minutos en lugar de días, la información necesaria para tomar sus decisiones en función de la situación real de un determinado proyecto, principalmente en lo que conlleva a afrontar un determinado grado de riesgo.
El Project Management es un tema que se está volviendo muy difundido por su flexibilidad. Los conceptos de “proyecto” y de “Project Management” pueden ser aplicados en cualquier segmento empresarial, en cualquier industria, y pueden incluso ser utilizadso en el ámbito personal. Una boda, por ejemplo, puede perfectamente ser considerada como un proyecto. Conlleva la gestión de costes, de plazos, de recursos humanos y, sobre todo, la gestión de un cierto grado de riesgo. Todos los proyectos tienen características conceptuales parecidas. Todas ellas poseen, de alguna forma, una fase inicial, una fase de planificación, control, ejecución y una fase de cierre.
51
1.7 Los stakeholders del proyecto También conocidos como “interesados”, son individuos y/u organizaciones que están involucradas en el proyecto, tienen intereses en su desarrollo y poseen diferentes necesidades y expectativas. El cliente, el Project Manager, el equipo del proyecto y el patrocinador obviamente pertenecen a este grupo. Sin embargo, cualquiera que se vea afectado positiva o negativamente con los resultados producidos por el proyecto es un potencial interesado. No obstante, los interesados más importantes del proyecto son el cliente, que se convertirá en el usuario del servicio y/o producto generado, y el patrocinador, que es el que invierte recursos financieros al proyecto. Sin ellos, el proyecto difícilmente seguirá adelante. Los interesados pueden ejercer una fuerte influencia en el proyecto. Por esta razón es fundamental:
·
Identificarlos: Cada proyecto está formado por un grupo de interesados distintos, que podrán tener un grado de influencia más importante que en otros. Normalmente, son cinco los interesados clave: el Project Manager, el equipo del proyecto, el patrocinador, la dirección y el cliente. Sin embargo, en algunos proyectos, pueden existir otros interesados importantes, cuya identificación, a veces, no resultará sencilla. La mejor forma de identificar a los interesados de un proyecto es haciéndose la siguiente pregunta: “¿quién con tribuye al proye cto?”.
·
Definir sus funciones: El Project Manager, por ejemplo, es la persona responsable de realizar un proyecto, coordinando el equipo y trabajando para que los resultados sean los esperados. El equipo del proyecto realiza el trabajo necesario para que se alcancen los objetivos definidos, y la dirección toma algunas decisiones importantes, generalmente en los momentos más críticos. Otro interesado importante es el patrocinador, que es quien invierte recursos financieros al proyecto y que, a veces, tiene la última palabra acerca de su alcance y de otras variables.
·
Identificar su grado de influencia: El grado de influencia de un interesado normalmente está vinculado a su cargo o posición en el proyecto. Dependiendo del cargo que ocupe, su opinión puede tener una repercusión importante en el proyecto, colaborando para su progreso o, incluso, determinando su cierre.
·
Determinar sus requisitos: En términos del Project Management, los requisitos son condiciones que deben ser satisfechas o que pueden proporcionar a un sistema, servicio o producto, la capacidad de producir un determinado resultado.
·
Garantizar su satisfacción: Se suele decir que “el cliente siempre tiene la razón”, pero el Project Manager tiene un lema distinto: “Lo que realmente importa es cumplir con las expectativas de los interesados”. El Project Manager debe preocuparse por satisfacer a cada interesado del proyecto, y es importante tener claro que los interesados también pueden aportar mucho en tanto que a ellos les interesa que el proyecto se desarrolle correctamente.
Los interesados de un proyecto pueden ser básicamente de dos tipos, internos o externos:
52
1.7.1 Stakeholders internos ·
La dirección: Los directores de la empresa podrán o no estar directamente involucrados en un proyecto. En grandes proyectos de mucha visibilidad, la dirección suele implicarse con más frecuencia, lo que incrementa la comunicación con el Project Manager y facilita la adquisición de recursos materiales y contratación de personal cualificado. Por otro lado, si el proyecto se desarrolla de forma problemática, sus debilidades estarán muy expuestas, y el soporte inicial de la dirección se volverá en presión que muchas veces será muy perjudicial para el ambiente del proyecto.
·
El Project Manager: Resultaría injusto decir que el Project Manager es el principal interesado del proyecto, porque la verdad es que nadie lo es. La puesta en marcha de un proyecto depende de todos los interesados, ya que cada uno realiza su aportación acorde con el papel que ocupa. No obstante, se puede decir que el Project Manager es el interesado más involucrado, puesto que participa directamente de todo el proyecto, desde la fase inicial hasta su cierre.
·
La organización ejecutante: Es el ámbito donde un proyecto será desarrollado o por lo menos una parte importante de él. Es la organización ejecutante la que provee los medios materiales, tecnológicos, financieros y de recursos humanos para la puesta en marcha del proyecto.
·
Los integrantes del equipo del proyecto: Son los recursos asignados y quienes trabajaran directamente en el desarrollo de los entregables del proyecto. El equipo de proyecto es normalmente formado por profesionales con diferentes conocimientos, experiencias y habilidades que puedan asegurar la buena ejecución del proyecto.
1.7.2 Stakeholders externos ·
El cliente: Es la persona, grupo de personas o empresas que se beneficiarán directamente del producto o servicio desarrollado por la empresa ejecutante. Generalmente, están altamente involucrados en la planificación y ejecución del proyecto y es quien formalmente acepta o no la entrega de cada fase prevista, hasta que se alcance la totalidad del proyecto contratado.
·
El gobierno: Muchos proyectos son desarrollados con fondos públicos, a través de concursos y/o licitaciones. Además, en algunos sectores, los proyectos son desarrollados de acuerdo con algunas normativas, como es el caso, por ejemplo, de la industria farmacéutica. El Project Manager tendrá que estar atento a ciertas restricciones impuestas por las normativas que afecten a su proyecto. Los proyectos que son resultantes de una licitación pública normalmente tienen todo su alcance, plazos, presupuestos y procedimientos atados a un concurso público, que deberá ser respetado.
·
Los proveedores: Muchos proyectos dependen bastante de los servicios prestados por buenos proveedores, como suele ocurrir, por ejemplo, en los proyectos de construcción: la buena calidad de los materiales (hormigón, ladrillos, parqués...) y de mano de obra (fontaneros, electricistas, encofradores...) son esenciales para que el proyecto cumpla con
53
los requisitos mínimos de calidad. La dependencia no se limita solamente en lo que se refiere a la calidad de los productos y/o a los servicios prestados por los proveedores.
54
Una entrega tardía o temprana de los productos contratados, o un incremento del coste de la mano de obra, podrá comprometer seriamente el proyecto.
·
Terceros: A veces, una organización no tiene suficiente personal propio para ejecutar los trabajos previstos. Esta situación suele ocurrir en grandes proyectos, como son los del sector de la construcción y de las telecomunicaciones. En este caso, es común contratar mano de obra externa. El Project Manager deberá conocer todas las cláusulas que forman parte del contrato establecido con empresas externas, para que no existan divergencias que comprometan el desarrollo del proyecto.
·
El patrocinador: Todo proyecto tiene un patrocinador. Normalmente, el patrocinador del proyecto es alguien perteneciente a la organización, que identifica la necesidad de poner en marcha un proyecto para lograr un resultado determinado, sea estratégico, financiero o tecnológico. Cuando el proyecto es demandado por un cliente fuera de la organización, el patrocinador ejercerá el rol de interlocutor entre el cliente y la empresa ejecutora del proyecto. En resumen, es la persona que apuesta por el proyecto y que proveerá el soporte necesario para que su inversión alcance los objetivos determinados.
También podemos incluir en este grupo a los acreedores, sindicatos, prensa, organizaciones no gubernamentales o la opinión pública, entre otros. Lograr una armonía entre los interesados del proyecto es otro factor de éxito importante y un gran desafío para el Project Manager. Lograr esta armonía es posible si el Project Manager es capaz de incentivar la participación de los interesados, creando un ambiente de colaboración. Se trata de una complicada labor, puesto que, normalmente, los interesados tienen objetivos diferentes que pueden entrar en conflicto. Por ejemplo:
·
El director técnico solicita un cambio en el alcance del proyecto que puede comprometer las fechas planificadas por el equipo técnico para la finalización de alguna fase.
·
El proyecto puede ser afectado por alguna ley que sea aprobada durante su desarrollo.
·
Un integrante clave del equipo técnico puede dejar la empresa.
·
El cliente puede solicitar un cambio importante en alguno componente del proyecto que comprometa toda la planificación realizada.
La participación de los interesados del proyecto debe ser siempre positiva, añadiendo conocimiento y valor al proyecto. Uno de los grandes desafíos del Project Manager es resolver los conflictos que se produzcan durante el proyecto, encontrando la solución apropiada. Algunas de las más importantes estrategias de conflicto son descritas en el capítulo 13 – Gestión de Conflictos.
55
1.7.3 La gestión de los interesados Es notoria la fuerte influencia que los interesados ejercen sobre un proyecto, ya que algunos de ellos tienen en su poder el control de muchos recursos de la organización, y, por esta razón, el Project Manager deberá ser capaz de administrar eficazmente sus relaciones. Como figuras importantes que son, y además con intereses conflictivos (aunque casi todos desean que el proyecto termine exitosamente), se hace necesario identificar sus expectativas y desarrollar una gestión que permita mantenerlos de nuestro lado, como verdaderos aliados del proyecto, puesto que, en algunos casos, cualquier interesado puede echarlo todo a perder. Su gestión conlleva seguir los siguientes pasos:
· · · · ·
Identificar quiénes son. Identifi car su papel. Identificar el impacto que el proyecto tendrá para los diferentes interesados. Valorar su influencia en el proyecto. Identificar las relaciones entre los interesados y sus objetivos en común.
Una gestión eficaz de los interesados traerá beneficios al proyecto, por ejemplo:
· · · ·
Facilitará la toma de decisiones. Mejorará la fluidez de la información y de la comunicación. Incrementará el nivel de satisfacción. Aportará estabilidad al proyecto.
Su adecuada gestión podrá realizarse con el auxilio de la primera herramienta de esta obra, presentada a continuación.
1.7.3.1 Técnicas y herramientas 1.7.3.1.1 Matriz poder/interés (Power/interest matrix) Como he dicho anteriormente, existen interesados que controlan los recursos críticos de la organización, así como hay interesados que, incluso, pueden llegar a influenciar directamente en la estabilidad emocional del Project Manager (por ejemplo, la familia). Cada interesado es dotado de un determinado grado de influencia y poder sobre un proyecto. Este grado es medido por la capacidad que cada uno tiene de ejercer una presión sobre otros. La tabla que hay a continuación, llamada de matriz poder/interés y desarrollada por Gerry Johnson 9 y Kevan Scholes10, clasifica a los distintos interesados en función de su poder y grado de interés que pueden mostrar en un determinado proyecto. Esta matriz nos puede ayudar a establecer la relación que se debe mantener con cada uno de los interesados.
56
NIVEL DE INTERÉS BAJO BAJ O PODER ALTO
(A) Trabajadores Asoc. Empresariales (C) Gobierno Proveedores
ALTO (B) Sociedad (D) Socios Cliente
Figura 3: Matriz interés/poder
Como se podrá apreciar en el ejemplo, los interesados del grupo “D” son los que más presión pueden ejercer sobre los demás y, por ello, se hace necesario desarrollar estrategias de negociación y toma de decisiones que nos permitan tener a este grupo involucrado de forma positiva en el proyecto. Por otro lado, el grupo “C” tiene el poder directo de parar de ejecutar sus labores o dejar de suministrar algún producto o servicio necesario para el buen desarrollo del proyecto. Por esta razón, se puede considerar que la organización debe conocer el nivel exacto de interés que muestran los interesados de este grupo, para asegurar una negociación eficaz en el caso de que surja algún tipo de conflicto.
1.7.3.1.2 Diagrama de Venn (Venn´s diagram) El diagrama de Venn recibe este nombre de su creador, John Venn 11, matemático y filósofo británico. Estos diagramas son normalmente utilizados en las matemáticas, y son conocidos como “teoría de conjuntos”: diagramas utilizados para ilustrar la relación entre conjuntos, representados por círculos. La forma en que estos círculos se sobreponen entre sí muestra las posibles relaciones lógicas entre los conjuntos que representan. En este caso, utilizaremos este diagrama para representar las relaciones entre los interesados del proyecto:
Figura 4: Diagrama de Venn
57
Cada conjunto ilustrado en este diagrama representa a un interesado del proyecto. El área donde los círculos se superponen representa el objetivo en común que tienen los interesados que se relacionan directamente. Aunque en casi todos los casos, todos los interesados tienen objetivos en común, muchas veces, durante el desarrollo del proyecto; algunos de estos interesados pueden tener objetivos específicos, muchas veces determinados por la relación directa que mantienen. En el diagrama, el patrocinador no tiene una relación directa con el cliente; sin embargo, tiene objetivos en común con la gerencia y con el Project Manager.
1.7.3.1.3 Matriz de los interesados (Stakeholder´s matrix) La matriz de los interesados es muy similar a la matriz de responsabilidades (descrita en la sección 9.1.1.3) y sirve para determinar la relación entre los interesados y sus funciones en cada fase del proyecto. La naturaleza y el alcance de cada fase asignarán la función de cada interesado.
INICIO
PM, EP, GE
OPINIÓN REQUERI DA CL
PLANIFICACIÓN
PM, EP
EX
PM
PM
EJECUCIÓN
PM, EP
EX
PM
PM, EP
CONTROL
PM, EP
CL
PM
PM
PARTICIPA NTE
REVISIÓ N REQUERI CL
RESPONS ABLE GE
CL: Cliente, PM: Project Manager, EP: Equipo del Proyecto, GE: Gerencia, EX: Experto Figura 5: Matriz de participación de los principales interesados
58
Capítulo 2 El ciclo de vida del pro yecto “A menudo, quienes vacilan en hacer planes es porque dudan también en su capacidad de cumplir” Michael Levine12, escritor estadounidense
60
Introducción Todos los proyectos tienen un fin vinculado a la obtención de un resultado, que puede ser un producto o un servicio, generado a través de la ejecución de una serie de actividades previamente planificadas. Algunas de estas actividades se agrupan en fases para facilitar su gestión. Al conjunto de estas fases se le denomina “ciclo de vida”. El ciclo de vida de un proyecto contiene cuatro elementos básicos que serán profundizados a continuación:
· · · ·
Fases. Actividades. Entregables. Procesos.
2.1 El ciclo de vida del proyecto Como he comentado anteriormente, los proyectos son un emprendimiento único que conlleva un cierto grado de incertidumbre y riesgo. Por esta razón, normalmente, un proyecto es dividido en fases puntuales para tornar su control más efectivo. A este conjunto de fases le llamaremos, tal y como he dicho antes, “ciclo de vida del proyecto”. El ciclo de vida representa el progreso lineal de un proyecto, desde la fase inicial hasta su cierre, como ilustra la figura 6:
Figura 6: Estructura de la gestión de proyectos
61
2.1.1 Características del ciclo de vida del proyecto El ciclo de vida también define el comienzo y el fin de un proyecto. Además, determina las acciones posteriores a su conclusión, es decir, que es útil para vincular el proyecto con las operaciones continuas de la organización. Las descripciones del ciclo de vida del proyecto pueden ser muy generales o muy detalladas. Cuanto más detalladas, mejor estructuradas estarán documentalmente, proporcionando al proyecto una importante base documental donde se guardaran los trabajos realizados y sus resultados.
Figura 7: Influencias durante los procesos de un proyecto
Normalmente, el ciclo de vida de un proyecto posee las siguientes características:
·
El coste y el personal involucrado son bajos al comienzo, aumentan según avanza el proyecto y caen súbitamente cuando el proyecto se aproxima de su cierre.
·
Cuando un proyecto se encuentra en su fase inicial, la probabilidad en completarlo con éxito es muy baja y, por lo tanto, el riesgo y la incertidumbre son altos. Conforme el proyecto avanza, la probabilidad de terminar con éxito aumenta progresivamente.
·
Los interesados en el proyecto ejercen mucha influencia en el comienzo del proyecto. Su poder de influencia disminuye progresivamente a medida que el proyecto avanza.
Aunque muchos ciclos de vida contengan elementos y fases similares, pocos son idénticos. Algunos proyectos presentan cuatro o cinco fases, otros pueden llegar a presentar más de diez fases. Todo dependerá del sector empresarial donde el proyecto es desarrollado, la forma en que la organización ejecuta sus proyectos o cómo serán las características del producto o servicio que será entregado. Sin embargo, todos los ciclos de vida tienen una cosa en común: todos tienen una fase inicial, una fase final y, por lo menos, una fase intermediaria.
62
Una fase es concluida cuando se terminan los trabajos necesarios para llevar a cabo la obtención de uno o más entregables. Un entregable es el producto o servicio resultante del trabajo realizado durante una determina fase, como, por ejemplo, la colocación del pavimento en una obra es el resultado de una de las fases de construcción de un edificio. Cuando se finaliza una fase, es recomendable revisar todo el trabajo realizado y evaluar los resultados obtenidos, sobre todo en lo que se refiere al cumplimiento del plazo y el uso de los recursos financieros y humanos. Esta evaluación será útil para asegurar el buen rendimiento en la siguiente fase de ejecución del proyecto. Normalmente, los entregables de la fase precedente son aprobados antes del comienzo de la siguiente. Existen proyectos en los que las fases se superponen, es decir, que una fase puede iniciar antes de que termine la precedente. De todas formas, la evaluación general del proyecto entre sus fases o en los periodos de transición es importante para su buen desarrollo. Dividir un proyecto por fases conlleva los siguientes beneficios:
· · ·
Permiten controlar mejor el avance de todo el proyecto. Disminuye su complejidad. Reducen la incertidumbre y el nivel de riesgo.
2.1.2 La triple restricción del proyecto Un proyecto es un sistema dinámico que tiene que mantenerse constantemente en equilibrio. Gestionar un proyecto es un esfuerzo que conlleva administrar una serie de actividades integradas. Si una determinada actividad no produce los resultados esperados, podrá afectar a otras áreas del proyecto. El cambio del alcance casi siempre afectará el coste del proyecto, así como la reducción del plazo de entrega de un producto, podrá repercutir negativamente en su calidad. El Project Management busca resolver estas interacciones de forma activa. En esta materia se menciona con mucha frecuencia la triple restricción del proyecto (Project Triple Constraint), que representa la interacción entre el alcance, el plazo y el coste en la forma de un triángulo:
Figura 8: La triple restricción del proyecto
63
• Alcance: El término “alcance” representa el trabajo necesario para producir exactamente los requisitos establecidos por el cliente. En el desarrollo del proyecto es muy probable que el cliente solicite alguna modificación en relación al alcance original, lo que, normalmente, se traduce en añadirle más requisitos, que podrán provocar un incremento en los costes y en los plazos de entrega del proyecto.
·
Tiempo: Es la duración prevista para completar el proyecto. De acuerdo con un estudio realizado por las empresas Gartner Inc, el 90% de los proyectos ejecutados son entregados con retraso, lo que nos lleva a pensar que el plazo es una variable muy difícil de estimar y extremadamente complicada de cumplir, por ello se hace necesario dedicar un tiempo importante de planificación y control.
·
Coste: El 50% de los proyectos son entregados con un presupuesto mayor que el previsto, según el mismo estudio realizado por las empresas Gartner. Esto ocurre normalmente porque no se ha tenido en cuenta una serie de costes internos, externos, fijos y variables que un proyecto puede contemplar.
Es importante resaltar que, durante todo el desarrollo del proyecto, el Project Manager tendrá el desafío de mantener la triple restricción del proyecto equilibrada constantemente. Si el cliente decide cambiar una de las restricciones, las otras dos, seguramente, serán afectadas. Equilibrar este triángulo es una de las claves para obtener los resultados esperados de un proyecto. La búsqueda de este equilibrio está en saber priorizar el elemento más importante del proyecto, y eso dependerá, sobre todo, de la organización que lo gestiona, del propio Project Manager, de los patrocinadores y de las características del proyecto. Decidir es una labor constante para el Project Manager. En muchos casos, las decisiones serán tomadas atendiendo a las prioridades de la triple restricción del proyecto. Si el cliente establece una fecha determinada como prioridad, el Project Manager intentará hacer lo posible para que esta fecha sea respectada, reduciendo, por ejemplo, el alcance del proyecto, muchas veces comprometiendo su calidad. Para garantizar la entrega del proyecto en la fecha determinada por el cliente, esta acción probablemente incrementará el coste. Teóricamente, parece sencillo, pero, en la práctica, puede representar un serio problema al Project Manager. Priorizar uno de los componentes de la triple restricción casi siempre provoca un impacto negativo en los demás componentes. Estos cambios de prioridad muchas veces no son planificados y casi siempre conllevan serios problemas.
64
Para acabar este apartado, presentaré una anécdota que encontré en cierta ocasión en internet, sobre un ejecutivo que estaba obsesionado en reducir los costes de los proyectos en detrimento de su calidad. Se cuenta una historia de un gerente que, no pudiendo aprovechar sus entradas para un concierto donde se escucharía la sinfonía inconclusa de Franz Schubert, se las entregó al director financiero de su empresa, que era famoso por su agresiva postura de reducción de costes; una obsesión que muchas veces causaba problemas en la ejecución de algunos proyectos llevados a cabo por la empresa donde trabajaba. El lunes siguiente, el gerente recibió del director financiero el siguiente informe: Tras asistir atentamente la sinfonía inconclusa de Franz Schubert, si tuviera la oportunidad, recomendaría los siguientes puntos al director de la orquesta:
·
Durante lapsos considerables, los cuatro músicos que tocaban oboe no tenían nada que hacer. Ellos podrían ser eliminados y su trabajo dividido entre toda la orquesta.
·
Cuarenta violines tocando notas idénticas. Esto me parece una duplicación innecesaria, y esa parte de la orquesta debería ser drásticamente reducida. Para obtener mayor volumen de sonido, podrían ser usados amplificadores electrónicos.
·
Fue absorbido mucho esfuerzo en la ejecución de bemoles y sostenidos. Esto parece un refinamiento excesivo, recomiendo que todas las notas sean redondeadas a la próxima nota simple. Si esto se hiciera, sería posible usar becarios y operadores no especializados.
·
No veo ninguna finalidad práctica en la repetición por los metales de los mismos pasajes que ya fueron ejecutados por las cuerdas. Si todos estos pasajes redundantes fuesen eliminados, el concierto podría reducirse a veinte minutos.
·
Según este análisis, puedo afirmar que si el compositor Franz Schubert hubiera conocido la reingeniería, definitivamente habría podido concluir su sinfonía y ser más eficiente en el uso de la orquesta y el tiempo.
Por suerte, esta historia es ficticia, pero todos los días son ejecutados centenares de proyectos con presupuestos muy reducidos, que, ciertamente, culminarán en un resultado de muy baja calidad. Es por esta razón que existen edificios que se desploman en la primera tormenta, programas que no funcionan y negocios que no prosperan. Recuerde: Uno de los factores de éxito en el Project Management es el equilibrio.
65
2.1.3 Las líneas base de un proyecto Las líneas base de un proyecto son un conjunto de fechas de inicio y fin, duraciones de trabajo planificadas y los costes previstos durante la fase inicial del proyecto. Se trata de una “fotografía” del proyecto en el momento en que se realizaron las primeras estimaciones. Además, representan el plan original aprobado por los interesados. Estas informaciones serán la referencia principal por donde se realizarán las mediciones y eventuales desviaciones que se produzcan a lo largo del ciclo de vida del proyecto. Un seguimiento correcto de las líneas base permitirá al Project Manager poner en marcha acciones preventivas o correctivas que posibiliten poner en proyecto otra vez dentro de la línea base original establecida. Conforme el proyecto avance, las líneas base serán contrastadas con la situación actual del proyecto, que proveerá las desviaciones reales en función de los planes establecidos. Estas comparaciones son realizadas en momentos puntuales del proyecto, normalmente durante la finalización de una fase o en el momento en que el proyecto alcance uno de sus hitos. Sin embargo, forma parte de las buenas prácticas verificar la evolución de la línea base en las reuniones que se celebran con los integrantes del equipo ejecutor. Un proyecto cuenta normalmente con tres líneas base, que son las de alcance, coste y plazo.
·
La línea base del alcance (scope baseline): Representa la suma de todos los entregables del proyecto. Además, refleja todo el trabajo necesario para concluir un proyecto. Es representada por la EDT (descrita en la sección 5.3).
·
La línea base del plazo (schedule baseline): Determina el tiempo total necesario para desarrollar todos los entregables definidos en la línea base del alcance. Puede ser representada por el cronograma del proyecto (descrito en la sección 6.5).
·
La línea base del coste (cost baseline): Es el presupuesto del proyecto (descrito en la sección 7.2). Representa la inversión monetaria total necesaria para desarrollar todos los entregables definidos en la línea base del alcance. La línea base del coste no incluye un eventual presupuesto de contingencia o cualquier otra reserva monetaria.
La línea base del alcance es normalmente la primera en ser desarrollada; luego se suceden las líneas base de plazo y coste. A partir de entonces, el proyecto ya cuenta con una línea base general definida. En algunos casos puede existir una limitación importante de tiempo y recursos financieros. Cuando esto ocurre, se establecen primero las líneas base de coste y plazo, y a continuación se define la línea base de alcance en función de los recursos disponibles.
66
Figura 9: La línea base de un proyecto
Cualquiera de las líneas base del proyecto pueden sufrir modificaciones conforme el proyecto avanza. Toda vez que se introduzcan cambios, la línea base anterior es abandonada y toda la monitorización será realizada en función de la nueva línea base. Siempre que se produzcan cambios en una de las líneas base del proyecto, las otras líneas deberán ser reajustadas. De todas formas, aunque se abandonen las líneas bases anteriores, es importante comparar las desviaciones producidas durante el desarrollo del proyecto. Para diseñar una línea base es importante disponer, principalmente, de los siguientes datos:
·
Las estimaciones de coste del proyecto, desglosados por fase o por actividades, desde la fase inicial hasta el cierre del proyecto.
·
El cronograma original del proyecto, desglosado por fases o por actividades.
·
También se pueden diseñas líneas base del consumo de recursos disponibles para el proyecto (materia prima, instalaciones, maquinaria, equipos, personal, entre otros).
2.2 Los procesos y fases de un proyecto Como los proyectos suelen tener un grado de incertidumbre muy alto, se hace necesario organizarlo en fases para que, de esta forma, sea posible administrar mejor su evolución, reducir la incertidumbre y, por consiguiente, los riesgos involucrados. Una fase es un conjunto de actividades relacionadas con el objetivo de obtener un resultado previamente esperado. Cada proyecto, dependiendo de su naturaleza y complejidad, tendrá sus fases divididas y organizadas de forma que mejor permita su gestión. Sin embargo, para desarrollar una administración eficaz, es importante realizar, en cada fase, cuatro procesos básicos imprescindibles: inicio, planificación, ejecución/control y cierre.
67
•
Inicio: Se inicia tras la asignación del Project Manager a través del acta de constitución del proyecto (Project Charter, descrito en el apéndice A, doc nº 001). El inicio del proyecto es la primera etapa de su ciclo de vida e incluye las primeras actividades tras la aprobación formal del proyecto. En este proceso, se definen los objetivos, el alcance, las propuestas y los entregables que serán producidos.
·
Planificación: Es un proceso muy importante y, desafortunadamente, muy despreciado por las empresas. Es el momento donde se realizan las estimaciones del proyecto, se confecciona el plan de proyecto (Project Management Plan, descrito en el apéndice A, doc nº 003) y se define su estrategia de ejecución, además de los procedimientos de control. Existen organizaciones que suelen fundir este proceso con el anterior, lo que no es aconsejable.
·
Ejecución/control: Es el proceso que pone en marcha todo lo planificado anteriormente. Normalmente, el 90% de los recursos son consumidos en esta fase, que termina cuando el objetivo del proyecto ha sido completamente alcanzado.
·
Cierre: Suele ser el proceso más corto del proyecto y, sin embargo, uno de los más importantes. En esta etapa, el producto o servicio desarrollado es puesto en marcha, el cliente realiza las pruebas de aceptación y, una vez comprobado que los requisitos establecidos se cumplen, el proyecto es formalmente finalizado, lo que suele suceder mediante la firma de una aceptación formal (Formal Aceptance, descrito en el apéndice A, doc nº 050).
68
Figura 10: Procesos del proyecto
69
Si trasladamos estos conceptos a un proyecto personal, como, por ejemplo, las vacaciones de verano, podremos observar cómo estos procesos marcan de forma muy clara el ciclo de vida de un proyecto:
·
Inicio: Se determinan cuántos días de vacaciones disponemos, qué tipo de vacaciones queremos organizar (playa, montaña...), qué distancia pretendemos recurrir y la cantidad de dinero que podemos invertir. Además, se buscan informaciones acerca de la ciudad, las tarifas de los hoteles, la disponibilidad de vuelos o la ruta y las distancias que deberán ser recorridas en el caso de viajes de coche.
70
•
Planificación: En función de los resultados obtenidos, se determinan la duración de las vacaciones, la asignación un presupuesto y los recorridos realizados, acorde con el calendario previsto.
·
Ejecución/control: Empiezan las vacaciones. Si el traslado es realizado en avión, se tratará de llegar puntualmente al local de embarque. Si viajamos de coche, intentaremos cumplir la ruta en los tiempos planificados. En la ciudad, disfrutaremos del hotel y de las atracciones de las que la ciudad ofrece. Si surgen incidencias (el hotel no satisface las exigencias mínimas, el coche sufre alguna avería, el vuelo ha sido cancelado...), se ponen en marcha las acciones correctivas correspondientes.
·
Cierre: La vuelta a casa. Se guardarán las fotos y los recuerdos del viaje y se pagarán las facturas referentes a las reservas, compras y dietas realizadas durante las vacaciones.
Para proyectos pequeños, estos procesos representan toda la vida del proyecto. No obstante, en proyectos muy grandes, podrán repetirse en cada fase de su ciclo de vida, según se ha ilustrado en la figura 11.
Figura 11: Fases y procesos de un proyecto
71
No existe un proceso más importante, aunque uno consuma más tiempo y recursos que otro. Cada proceso tiene su importancia y el proyecto depende del buen desarrollo de cada uno para alcanzar sus objetivos. Si un proceso no es bien realizado, seguramente el siguiente sufrirá sus efectos negativos, y así será sucesivamente, provocando daños que podrán ser irreparables.
Figura 12 – Ciclo de vida representativo de un proyecto de desarrollo de software
Organizar un proyecto en fases nos puede aportar una serie de beneficios, entre ellos:
·
Facilita el control del proyecto: Al dividir el proyecto por fases, se permite al Project Manager y al equipo tener un enfoque más restrictivo. De esta forma, el control del proyecto se vuelve más sencillo, ya que todas las atenciones están volcadas a la fase que se está desarrollando.
·
Disminuye la complejidad del proyecto: Proyectos complejos, como son los de la construcción, suelen contener muchas actividades e involucrar a grandes equipos, y por ello, su administración pude ser muy complicada. Mediante la organización de un proyecto por fases, su gestión se torna más sencilla, puesto que las metas estarán enfocadas al término de la fase en curso, no del proyecto como un todo.
·
Reduce la incertidumbre: La falta de información es la principal razón del aumento de la probabilidad de riesgo en un proyecto. Realizando una gestión de proyectos por fases, se dedica una atención especial a los riesgos específicos de la fase que se está ejecutando, facilitando su supervisión y control.
72
2.2.1 Inicio Es el proceso de autorizar formalmente un nuevo proyecto. Generalmente, los proyectos son autorizados como resultado de una o más de las siguientes causas:
·
Una demanda de mercado: Una empresa de informática autoriza un proyecto para desarrollar un sistema de gestión para un segmento de mercado que todavía no cuenta con una herramienta eficaz.
·
Una necesidad de negocio: Una organización autoriza un proyecto para poner en marcha la creación de una nueva unidad de negocio para la obtención de nuevos clientes.
·
Requisito del cliente: Una constructora autoriza un proyecto para construir una urbanización de viviendas en la zona vieja de la ciudad.
·
Un avance tecnológico: El gobierno autoriza un proyecto para el desarrollo de un satélite que pueda monitorizar la sequía que compromete el ecosistema de una determinada región.
·
Una necesidad legal: Un establecimiento comercial autoriza un proyecto para implantar unos procedimientos exigidos por una nueva ley que les afecta directamente.
·
Una necesidad social: Una organización no gubernamental autoriza un proyecto para desarrollar una forma alternativa de suministrar energía eléctrica a pueblos muy aislados de un determinado país.
Aunque esta fase parezca la más “corta” de un proyecto, no podemos subestimarla, dado que, en esta fase, se asientan las bases fundamentales de un proyecto, como, por ejemplo:
· · · · · · ·
Las necesidades y requisitos del cliente. Los objetivos del proyecto. Las restricciones y supuestos. Los contratos y presupuestos. Los hitos. La identificación de los interesados. La asignación del Project Manager y su equipo.
Esta es, además, la fase donde el riesgo se encuentra en su nivel más alto, ya que son muchas las incertidumbres, y la organización cuenta con muy poca información. Es una fase en que también se produce un elevado número de cambios. Existen varias formas de empezar un proyecto. La más correcta es mediante la publicación del acta de constitución del proyecto (project charter). Se trata básicamente del primer documento desarrollado para un proyecto ya aprobado y que formaliza su inicio e identifica los grupos de interés, el equipo que se encargará de su desarrollo. Pero, sobre todo, es el documento que concederá autoridad al Project Manager para desempeñar sus funciones. Las instrucciones de cómo confeccionar el acta de constitución del proyecto están descritas en el apéndice A, doc nº
73
001.
74
Además del acta de constitución del proyecto, es importante empezar desde esta fase la identificación de las restricciones y supuestos del proyecto. Las restricciones suelen limitar las opciones del Project Manager y de su equipo, pero, por otro lado, son importantes para determinar hasta dónde se puede llegar. Los supuestos, por su lado, reflejarán la disponibilidad del equipo adjudicado, las fechas de comienzo de actividades, las cláusulas contractuales, entre otros. Los supuestos son importantes, pues dan el norte al proyecto. Si no se formalizan, el proyecto no empezará, o si llega a empezar, evolucionará sin un rumbo claramente definido. El concepto más amplio de restricciones y supuestos está descrito a continuación:
Las restricciones del proyecto Una restricción es un factor que impone un determinado límite al desarrollo de una determinada actividad. Las restricciones tradicionales de un proyecto son las siguientes:
·
De coste: Un proyecto puede ser cancelado por falta de recursos económicos que le permitan seguir adelante, ya que su puesta en marcha depende de múltiples variables financieras, como, por ejemplo, los costes de mano de obra, materiales o infraestructuras.
·
De tiempo: En algunos casos, el plazo es la principal restricción de un proyecto. En la década de los 90, muchas empresas de software tuvieron que afrontar el problema del año 2000, más conocido como el “Efecto 2000” o “Year 2000 Problem - Y2K”. Sus aplicaciones informáticas corrían el riesgo de parar de funcionar si no se implantasen las correcciones adecuadas. Bancos, empresas de telefonía y multinacionales de grande porte invirtieron millones de dólares para evitar que ocurriese una “catástrofe electrónica”, que felizmente no llegó a ocurrir. Fueron realizados proyectos cuyo límite era el milenio que se acercaba. El año 2000 no podría ser postergado.
·
De alcance: Son los requisitos del proyecto. Un proyecto se considera finalizado cuando el resultado alcanzado corresponde a los requisitos especificados por el cliente.
Un proyecto puede tener otras restricciones importantes:
·
Tecnológicas: Durante toda la historia de la humanidad, muchos científicos lograron descubrir inventos que tuvieron que esperar años, y muchas veces siglos, para ser puestos en marcha, simplemente porque no existía la tecnología necesaria para realizarlos. La genialidad de Leonardo Da Vinci 97 le llevó a diseñar una infinidad de aparatos ingeniosos, desde instrumentos científicos hasta maquinas voladoras. El helicóptero de Da Vinci97 fue diseñado en el siglo XV, que, lógicamente, por limitaciones tecnológicas no pudo ser puesto en práctica hasta comienzos del XX, quinientos años más tarde.
·
De recursos humanos: Disponer del equipo adecuado en el momento oportuno. Desafortunadamente, esta regla es muy difícil de lograr. Una empresa puede disponer recursos financieros y tecnológicos para desarrollar el proyecto que se proponga; no obstante, si no dispone de los recursos humanos adecuados, pocas serán las posibilidades de éxito. Muchos proyectos son puestos en marcha con equipos incompletos, tanto en cantidad como en calidad, y la consecuencia de esta debilidad se refleja en los resultados obtenidos.
75
•
Legales, burocráticas y políticas: Son restricciones que están directamente asociadas a la organización ejecutante del proyecto o al país donde el proyecto será desarrollado. Las mayores dificultades en la realización de un proyecto provienen de legislaciones específicas. Los proyectos de construcción de centrales hidroeléctricas, por ejemplo, dependen de un amplio estudio de impacto ambiental que puede llevar años para ser realizado. La burocracia de algunos países que exigen una infinidad de licencias y permisos para la ejecución del proyecto o algunas cuestiones políticas son también restricciones importantes que pueden impedir que un proyecto sea desarrollado sin percances.
·
Culturales: Algunos proyectos pueden sufrir cambios en su diseño, por determinadas razones culturales, sobre todo en lo referente a la percepción de la calidad. Es decir, satisfacer las necesidades y expectativas de los clientes, que pueden ser diferentes, dependiendo de la región en que se desarrolla el proyecto. Para solventar este tipo de restricción, se realizan estudios de percepción de calidad, que constituyen un elemento fundamental para comprender la forma por la cual un determinado cliente reacciona delante de un nuevo producto o servicio.
·
Organizacionales: La forma en que una empresa aprovecha sus recursos humanos, su política de compras, gastos e inversiones y su política interna.
Será el conjunto de objetivos y restricciones que definirá las primeras estrategias y el primer borrador del plan de proyecto.
Los supuestos del proyecto El término “supuesto” en el ámbito del Project Management se refiere a los factores que son considerados verdaderos para realizar una planificación o estimación coherente, sin que sea necesario demostrar su fiabilidad. Por ejemplo:
·
“Los componentes importados desde China vendrán con sus manuales escritos en inglés”;
·
“Cuando termine la fase de diseño, tendremos cuatro ingenieros disponibles full time”;
·
“En la segunda quincena de septiembre, el 50% de las pruebas estarán realizadas”.
Es importante que estos supuestos sean acordados y documentados. Normalmente, los supuestos de un proyecto son plasmados en el acta del proyecto (Project Charter, véase también apéndice A, doc nº 001) o en el plan de proyecto (Project Management Plan, apéndice A, véase doc nº 003). Estos supuestos forman parte de la elaboración progresiva de la planificación del proyecto y por poseer un cierto grado de incertidumbre, conllevan a un cierto grado de riesgo. Es importante contar con especialistas para realizar estos supuestos, para, de esta forma, minimizar riesgos eventuales. Una vez considerados verdaderos, serán tomados en cuenta a la hora de confeccionar cronogramas y otros documentos del proyecto.
76
Hay casos en que algunos Project Managers menos experimentados simplemente ignoran la fase inicial del proyecto. Se trata de un fallo importante que, seguramente, les cobrará factura más adelante. Un proyecto no debería comenzar sin una fase inicial formalizada con un mínimo de datos que, a posteriori, alimentarán de forma más concreta la fase de planificación. La fase de inicio es la adecuada para realizar una primera toma de datos que serán más refinados y fiables, según avance el proyecto. Es de suma importancia que los objetivos sean claramente definidos en esta fase, aunque sufran cambios más adelante. Lo importante es partir de algún objetivo concreto que sea, sobre todo, realizable. Además, es fundamental definir las restricciones del proyecto. Una restricción es un factor que puede imponer un límite importante al desarrollo de un proyecto, pudiendo, inclusive, culminar en su cancelación.
2.2.1.1 Reunión de apertura del proyecto (Kickoff meeting) La reunión de apertura del proyecto, también conocida como Kickoff Meeting, es el momento oportuno de reunir al cliente, al equipo del proyecto y a los interesados para declarar formalmente el comienzo del proyecto y asegurarse de que todos los involucrados conocen sus funciones y responsabilidades. Como ocurre en cualquier reunión formal, es importante tener una agenda y divulgar el acta de constitución del proyecto. Esta agenda debe incluir, por lo menos, los puntos que se expresan a continuación:
· · · · ·
Motivos por los que el proyecto será llevado a cabo. Presentación de las especificaciones del proyecto. Presentación del equipo del proyecto. Presentación del cronograma del proyecto. Apuntar las actividades previstas para la próxima reunión.
La reunión de apertura es una oportunidad única de empezar bien el proyecto. Formalizando todos los puntos anteriores, el Project Manager podrá asegurarse de que todos los involucrados son conscientes de los compromisos asumidos y de las expectativas del proyecto. Por esta razón, esta reunión debe ser bien preparada y organizada. Es importante transmitir seguridad y una buena impresión a los involucrados. En el caso de no ser posible reunir a todos los involucrados en el proyecto, como mínimo es importante garantizar la asistencia de los más importantes. Toda la información recogida en esta reunión deberá formar parte de la documentación del proyecto que será distribuida posteriormente. La duración de esta reunión es proporcional a la complejidad del proyecto.
77
De la misma forma que una reunión de apertura puede llevar algunas horas, en algunos casos puede necesitar de uno o más días.
2.2.2 Planificación La planificación funciona como una especie de mapa que nos aporta las instrucciones y orientaciones para que podamos llegar con éxito a un determinado lugar y es un proceso que es desarrollado durante todo el ciclo de vida del proyecto. Aunque todos los procesos son importantes, planificar es fundamental. Sin embargo, en muchas ocasiones, es el proceso más olvidado por las personas que desarrollan la ejecución de un proyecto. Hay casos, desafortunadamente muy frecuentes, en que existe la necesidad de empezar repentinamente un proyecto para cubrir una necesidad puntual y, cuando esto ocurre, el proceso de planificación a veces se reduce simplemente a confeccionar un cronograma. Planificar significa mucho más que confeccionar una sencilla tabla orientativa de fechas, que, aislada, no sirve para mucho. Un Project Manager que no sea capaz de realizar junto con su equipo una buena planificación, pasará una buena parte del proyecto “apagando fuegos”. La mala costumbre de no planificar ocurre con frecuencia en las organizaciones. Normalmente, las personas saltan de la fase de inicio (cuando esta existe) a la fase de ejecución sin antes dedicar un solo momento a la planificación. Es decir, que, en algunos casos, la organización ya empieza un proyecto, ejecutándolo, de forma totalmente irresponsable e inconsecuente. La mentalidad que a veces se aprecia es: “Si ya hemos hecho proyectos similares a este, ¿por qué tenemos que planificarlo todo otra vez?”. Como he comentado anteriormente, a pesar de que la empresa haya realizado un proyecto muy similar en ocasiones anteriores, algunos elementos o circunstancias seguramente habrán cambiado y toda la planificación anterior no podrá ser totalmente aprovechada.
Figura 13: Ciclo de planificación de un proyecto
78
2.2.2.1 Relación entre los procesos La planificación es un proceso que tiene una interacción muy importante con el proceso de seguimiento y control, puesto que ambos se alimentan mutuamente de los resultados obtenidos durante el proceso de ejecución. Cuando se detecta una desviación en la ejecución del proyecto, se planificará otra vez las actividades correspondientes para mantenerlo bajo control.
Figura 14: Relación entre los procesos de planificación y control
Planificar aporta una serie de beneficios, entre ellos:
· · ·
Reduce la incertidumbre: Una planificación adecuada permitirá el desarrollo de medidas preventivas y correctivas para que los resultados esperados sean alcanzados. Aumenta el entendimiento: Planificar aporta al equipo la información necesaria para que se entienda el proyecto de forma clara y objetiva. Produce eficiencia: Una vez definido el plan de proyecto y los recursos necesarios para llevarlo a cabo, se podrá organizar el trabajo de forma optimizada de manera que, al final, se pueda terminar el proyecto en el plazo, dentro del presupuesto estimado y utilizando los recursos de forma adecuada. Hay casos en que es posible, incluso, terminar un proyecto antes del plazo, consumiendo menos recursos que los originalmente asignados y, lo más importante, sin afectar su calidad. Es interesante cómo en muchas empresas las personas se quejan de que no hay tiempo para planificar, pero cuando las cosas salen mal, hay que buscar tiempo adicional para rehacer todo el trabajo no planificado.
Planificar incluye, como mínimo, el alcance, el coste, el plazo, los recursos y los riesgos involucrados. En relación al alcance, es necesario desglosar las fases del proyecto en componentes más pequeños y manejables, de forma en que se pueda visualizar la dimensión total del trabajo involucrado. Con este nivel de detalle disponible, será más fácil estimar la cantidad de dinero que será invertido en cada componente, su tiempo de duración y los recursos necesarios para desarrollarlo. Una forma de hacer este desglose de forma eficaz es a través del uso de una herramienta llamada “Estructura Detallada del Trabajo – EDT” (WBS - Work Breakdown Structure), que descompone los trabajos establecidos para un proyecto, organizando y definiendo su alcance total (esta herramienta es descrita en detalle en la sección 5.3). Todas estas informaciones deberán estar reunidas en el plan de proyecto (Project Management Plan, descrito en el apéndice A, doc nº 003). Este documento servirá como una especie de “mapa” que orientará a los involucrados desde el comienzo hasta el final del proyecto.
79
Algunos Project Managers suelen ser demasiado optimistas en el momento de planificar. Existe una tendencia en pensar que las cosas saldrán perfectas, que los plazos serán respetados, que difícilmente algún factor exterior influirá negativamente en el proyecto y que no habrá espacio para el surgimiento de conflictos. Este tipo de razonamiento tan solo conllevará al fracaso del proyecto, sobre todo cuando empiecen a surgir los primeros problemas. Como consecuencia, todas las estimaciones positivas empezarán a desmontarse en una especie de “efecto dominó”, que conllevará a un ambiente bastante desfavorable. Para evitar caer en este tipo de errores, es importante que el Project Manager intente realizar una previsión de los posibles resultados de un proyecto en distintos escenarios, normalmente en un escenario optimista y otro pesimista. Estos escenarios ayudarán al Project Manager a definir una línea base. Si acaso algún evento tienda a dislocarse a un escenario más pesimista, el Project Manager podrá contar con alguna reserva de emergencia. Esta reserva podrá ser financiera, de plazos o de recursos y será estimada acorde con los resultados de proyectos similares y, sobre todo, a través de la experiencia y juicio de expertos.
Figura 15: Línea base x reserva Es importante tener en cuenta que la planificación no es un evento aislado que ocurre entre el inicio del proyecto y su ejecución. Es una actividad que debe ser realizada constantemente. Planificar no es crear un plan al comienzo del proyecto y, después, dejarlo archivado en algún sitio para “echarle un vistazo” de vez en cuando. Se trata de una documentación de apoyo importante que debe ser actualizada constantemente.
80
2.2.2.2 ¿Cómo puedo estar seguro de que he planificado lo suficiente? Está claro que no existe una forma sencilla de saberlo. Lo que se intenta hacer es planificar lo máximo posible para reducir el nivel de incertidumbre y poder tener más control sobre el proyecto. La pregunta entonces sería: “¿Cuánta planificación necesito?”, y la respuesta podrá encontrarse tras el análisis de los siguientes factores:
·
La complejidad del proyecto: La regla es sencilla. El nivel de planificación es proporcional a la complejidad del proyecto.
·
El tamaño del proyecto: Proyectos muy grandes requieren un esfuerzo importante de coordinación, ya que contienen una cantidad ingente de informaciones que pueden perderse fácilmente si no se realiza un control intensivo sobre ellas. Este tipo de proyecto debe tener una planificación formal y muy bien definida.
·
El nivel de incertidumbre: Cuando el nivel de incertidumbre es alto, es común que se desarrollen planes muy elaborados utilizando técnicas sofisticadas. Esta práctica no suele obtener buenos resultados, porque si el nivel de incertidumbre es alto, el Project Manager no dispondrá de suficientes informaciones que le permitan desarrollar planes precisos. Además, con escasa información acerca del futuro, cualquier plan que se elabore sufrirá varias modificaciones a lo largo del proyecto, hasta que se alcance un nivel de incertidumbre gestionable. Es importante confeccionar un plan equilibrado, acorde con la información disponible.
Cuanto más complejo y largo sea el proyecto, más planificación será necesaria para mantenerlo bajo control. Los proyectos más pequeños y más simples tienen un margen de riesgo más pequeño. De todas formas, todo es una cuestión de sentido común. Como normalmente no se puede estar pendiente constantemente de la evolución de un proyecto en conjunto, es importante determinar las fases clave y los hitos más importantes y estar atento a sus resultados. Los hitos, también conocidos como milestones, son puntos utilizados en el cronograma que, normalmente, señalizan un evento importante del proyecto, la conclusión de una determinada actividad, decisión o fase.
2.2.2.3 Las estimaciones Según Tom DeMarco13, “Una estimación es una predicción que tiene la misma probabilidad de estar por encima o por debajo del valor actual”. Una estimación, por definición, busca determinar un resultado cuantitativo aproximado. Para que un proyecto pueda ejecutarse dentro del plan establecido, es muy importante saber la duración de las actividades, cuánto costará desarrollarlas y qué recursos serán necesarios para llevarlas a cabo. Para ello, es fundamental realizar buenas estimaciones. De lo contrario, el proyecto se tornará un “agujero negro”, absorviendo todo lo que encuentra, sin proporcionar los resultados esperados. Sin embargo, realizar estimaciones no es una tarea nada fácil, todo lo contrario. En el comienzo del proyecto, si no fuesen identificados todos los entregables, algunos interesados pueden cambiar algún punto en concreto y, generalmente, el tiempo para realizar estimaciones suele ser muy limitado.
81
Para poder contar con una estimación realista, es necesario contar básicamente con dos factores:
·
Experiencia del equipo y de expertos: Se trata de un recurso importante para realizar estimaciones más o menos precisas. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia y formación especializada. Entre ellos, podemos incluir consultores veteranos, integrantes del equipo del proyecto, proveedores especializados...
·
La documentación de proyectos anteriores similares: Un proyecto debe disponer de una documentación completa en la que figuren todas las gestiones, planes, estimaciones y cualquier otro registro que el Project Manager considere relevantes. Una documentación bien estructurada servirá de soporte en la comunicación entre los integrantes del equipo, provee de soporte a los departamentos involucrados y servirá en el futuro como una base histórica fiable de consulta.
Existe un detalle importante que puede afectar a los resultados de las estimaciones de un proyecto: el carácter del equipo, de los interesados y del propio Project Manager. Hay casos en que existe una cierta tendencia pesimista u optimista que influye a la hora de estimar costes y plazos. Un proyecto puede tener estimaciones de plazo muy optimistas que serán difíciles de cumplir, como puede también tener estimaciones pesimistas que necesitarán de una reserva financiera importante, que podrá dificultar eventuales aprobaciones para su puesta en marcha. Además, como las estimaciones normalmente cruzan datos de plazo y coste, hay un margen enorme de arruinar cualquier plan. En estimaciones demasiado optimistas, los plazos son reducidos y no se incrementan los costes, cuando, normalmente, los costes aumentan cuando los plazos son acortados.
Las estimaciones normalmente fallan Uno de los factores de fracaso más comunes en el proyecto son las actividades “subestimadas”, que conllevan a un incremento importante de presupuesto y a un incumplimiento del cronograma. Esto ocurre normalmente por las siguientes razones:
· · ·
Demasiado optimismo por parte de las personas involucradas. No se tienen en cuenta el tiempo consumido por reuniones o las tareas administrativas, entre otros factores. No se prevén posibles bajas laborales.
82
·
No se tienen en cuenta los días festivos, vacaciones o periodos estivales.
83
• · ·
No se realizan consultas a las lecciones aprendidas de proyectos anteriores similares. En algunos casos, el equipo no conoce totalmente el alcance del proyecto. Falta de experiencia por parte del Project Manager, del líder técnico o del propio equipo.
2.2.3 Ejecución Es la fase en que se pone en marcha todo el plan de proyecto. En este momento, el Project Manager estará monitorizando el desarrollo de las actividades planificadas y establecidas en las fases anteriores. Durante esta fase, el equipo estará plenamente dedicado al desarrollo del proyecto. Es también la fase donde la comunicación deberá fluir constantemente. Además, en esta fase es importante realizar reuniones de seguimiento para recopilar informaciones sobre su progreso. En este momento, el Project Manager conducirá el proyecto estrictamente acorde con el plan. Si acaso, por algún motivo, el resultado producido no es el esperado, el equipo deberá documentar todas las incidencias para que se puedan realizar las oportunas valoraciones y estudiar posibles cambios y/o acciones correctivas.
2.2.4 Seguimiento y control Controlar es una palabra que muchas veces nos lleva a pensar en autoritarismo. No obstante, cuando hablamos del Project Management, controlar no es sinónimo de ser autoritario. Se trata de verificar si el equipo está haciendo bien las cosas y cumpliendo con el plan. Simplemente consiste en mantener el proyecto dentro de su curso. Haciendo una analogía, es como un conductor que está en una carretera y por un despiste, sale de su carril, pero corrige su trayectoria y luego vuelve a estar centrado en su recorrido. Básicamente, el control del proyecto se resume en analizar los resultados y las variaciones de la ejecución de los trabajos y asegurarse de que sus objetivos están siendo cumplidos. Además, se realizan las mediciones necesarias que puedan identificar posibles variaciones con respecto al plan y, consecuentemente, tomar las acciones correctivas adecuadas o, lo que sería lo mejor, las acciones preventivas para anticiparse a posibles problemas. Por ejemplo, si una fecha de conclusión de una actividad se acerca, pero todavía está lejos de terminar, el Project Manager deberá incluir horas extra, aumentar el número de recursos dedicados a la actividad o, si es posible, reajustar el cronograma del proyecto. La mejor manera de hacer una medición adecuada es observar la evolución de una actividad en su detalle. Es decir, si una determinada actividad necesita de diez acciones, se medirá la conclusión de cada acción por separado. De esta forma, se obtendrá el porcentaje del trabajo realizado en esta actividad. Haciendo una simple analogía, un Project Manager no puede observar la evolución de un bosque en conjunto. Es necesario acompañar el desarrollo de cada árbol, teniendo en cuenta que la debilidad de un árbol puede afectar el crecimiento de los demás, comprometiendo así el desarrollo de todo el bosque. La esencia del Project Management es la búsqueda constante del equilibrio. No se puede adoptar una postura de negligencia de cara al control de un proyecto, pero tampoco el Project Manager tiene que llevar la gestión al nivel de una obsesión.
84
Estar soportado por una buena documentación y, sobre todo, escuchar la palabra de expertos y de personas con experiencia en la gestión de proyectos similares también son factores que contribuirán para el control eficaz del proyecto. Existen algunas acciones que, realizadas de forma adecuada, contribuirán positivamente en un control efectivo del proyecto:
·
Reconfirmar el plan de proyecto: Antes de empezar una fase importante, es elemental revisar con los miembros del equipo si los trabajos propuestos todavía son posibles de ponerse en marcha de la forma en que establece el plan de proyecto.
·
Registrar toda la información relevante: Durante la fase ejecución, es muy importante que el equipo registre todas las informaciones que consideren útiles para el proyecto en curso y/o para proyectos futuros similares, como, por ejemplo, resultado de pruebas, fechas reales de comienzo y conclusión de las tareas del proyecto y el número de horas consumidas en cada tarea. Los resultados colectados serán confrontados con los resultados previstos en el plan.
·
Realizar acciones correctivas: Siempre que se comparan los resultados obtenidos con los previstos se obtendrán informaciones que darán al Project Manager la oportunidad de poder, en tiempo, realizar acciones correctivas que eviten que el proyecto pierda su dirección.
·
Mantener al equipo informado: La comunicación es otro factor crucial en el control del proyecto. Mantener al equipo informado, a través reuniones de seguimiento e informes de estado, aportará seguridad a todos e incrementará la coordinación entre los involucrados.
2.2.5 Cierre El cierre es un proceso que básicamente asegura que todas las actividades que forman parte del proyecto han sido correctamente finalizadas. Normalmente, esta fase exige una aceptación escrita del cliente formalizando la correcta recepción de todos los entregables previstos en el proyecto. Todos los proyectos tienen que llegar a la fase de cierre. Es verdad que, en algunos casos, un proyecto termina de forma abrupta y prematura, y eso suele ocurrir cuando las cosas no han salido bien y se decide terminarlo antes que se produzca un desastre. No obstante, cuando se decide por la puesta en marcha de un proyecto, se espera que este finalice acorde con el plan establecido, con todas las actividades desarrolladas, y los productos y servicios producidos entregados correctamente al cliente. Tan importante como empezar bien un proyecto es terminarlo de forma adecuada. Normalmente, el equipo del proyecto está muy motivado en hacer las cosas bien cuando se empieza un nuevo proyecto, sin embargo, la motivación no es la misma en su cierre. El desgaste provocado por los problemas y conflictos ocurridos o las perspectivas generadas hacia nuevos proyectos son algunas de las causas que perjudican su buen cierre.
85
En ocasiones muy frecuentes, el equipo es disuelto inmediatamente tras su conclusión. Cuando esto ocurre, se pierde una valiosa oportunidad de recoger información sobre las lecciones aprendidas, las conclusiones y las recomendaciones al equipo que dará posteriormente soporte al proyecto.
Incluso, en los proyectos en que no se hayan producido los resultados esperados, se pueden recoger informaciones que ayudarán a evitar que se produzcan los mismos errores en un emprendimiento similar. En la fase de cierre se realiza, además, una evaluación general de los trabajos realizados, suministrando información que servirá de consulta para la planificación y la ejecución de proyectos futuros. Esta información es almacenada en un documento llamado Libro de Notas del Proyecto (Project Notebook, descrito en el apéndice A, doc nº 053)
2.2.5.1 Entrega de todos los productos y/o servicios del proyecto ·
Documentación: La documentación muchas veces es vista como un simple papeleo burocrático, dado el tiempo que se invierte en dejarla actualizada conforme el proyecto avanza. Realmente, mantener la documentación de un proyecto es un esfuerzo importante, además de todo el trabajo que implica ejecutar un proyecto acorde con su plan. Sin embargo, en muchas ocasiones, el equipo o el Project Manager echan de menos la documentación de un proyecto anterior cuando están buscando alguna solución para un problema determinado. Toda la documentación confeccionada durante el proyecto debe tener un fin acordado por todos los interesados. Basado en este acuerdo, algunos documentos serán archivados en carpetas y otros son destruidos. Mucha documentación servirá como base para proyectos futuros. Además, es importante respectar el contenido confidencial de los documentos.
·
Cierre de los contratos: Normalmente, un proyecto es estructurado en función de varios contratos entre los interesados (proveedores, clientes, socios...). Como parte importante del proceso de cierre, es fundamental realizar una revisión final en los contratos acordados, con el fin de certificar que no existen puntos pendientes. Igual que los contratos, es importante realizar esta misma revisión en el plan de proyecto y en las actas de reunión. Además, es elemental consultar el departamento financiero la eventual existencia de facturas no pagadas.
·
Aceptaciones: Es el cliente quien decide si el proyecto ha terminado y es el Project Manager quien deberá demostrar que el producto o servicio contratado ha sido entregado dentro de las especificaciones solicitadas. Es importante obtener todas las aprobaciones pendientes, siempre de forma escrita. Normalmente, todas estas aceptaciones culminan con una aceptación final, que confirma que no existe ningún trabajo pendiente que deba ser realizado. En algunos casos, el cliente aceptará el final del proyecto tras realizar algunas verificaciones puntuales a través de pruebas. Se suelen crear listas de verificación (checklists, descrita en la sección 8.3.1.5) que irán a pautar los puntos en que el producto no puede fallar. El resultado de esta lista de verificación determinará la aceptación final del
86
proyecto.
·
Cierre Formal del Proyecto: Todos los proyectos deben contar con un cierre formal que deberá estar reflejado en el cronograma del proyecto.
El Project Manager, los representantes del equipo, los patrocinadores, los clientes y otros grupos de interés deberán fijar una reunión que formalmente cierre el proyecto. La agenda de esta reunión deberá describir principalmente:
87
•
Un breve resumen histórico del proyecto.
· · ·
Los objetivos cumplidos y no cumplidos. Los beneficios del proyecto para el cliente. Las lecciones aprendidas.
Además, es importante asumir el éxito o el fracaso de un proyecto. Muchas veces es evidente que un proyecto ha sido concluido de forma exitosa o no. En algunos casos, puede que algo haya ocurrido de forma no planificada y, como consecuencia, que se produzca algún factor que perjudique el proyecto. Por ejemplo, un programa puede haber sido entregado en la fecha planificada, pero algunos pueden haber sido entregados con fallos importantes. Los resultados de éxito o fracaso de un proyecto serán muy útiles como “lecciones aprendidas”, que aportarán valiosos conocimientos para futuros proyectos. Es de responsabilidad del Project Manager formalizar el cierre de las fases, contratos, cobros y toda la documentación del proyecto. Estas gestiones deben ser realizadas en el tiempo oportuno, antes de que el equipo sea deshecho y reasignado a otros proyectos. Es importante también divulgar a toda organización el cierre formal del proyecto. El equipo será oficialmente disuelto para ser asignado a nuevos proyectos y, a la vez, los departamentos de compras, contabilidad y administración realizarán las gestiones correspondientes al cierre final. La documentación generada desde el inicio deberá ser debidamente archivada para eventuales consultas.
2.3 Las actividades del proyecto Una actividad es un componente del proyecto que, organizado de forma integrada con otras actividades, forma el trabajo total para la realización de un proyecto. Una actividad tiene un identificador propio, un tiempo de ejecución estimado, un coste presupuestado y un pool de recursos asignados.
2.4 Los entregables del proyecto Todos los proyectos culminan en un resultado concreto. Este resultado puede ser un producto, un servicio o la combinación de ambos. Los elementos individualmente generados en cada fase del proyecto son conocidos como “entregables”. Existen dos tipos de entregables: internos y externos. Los entregables internos son aquellos producidos para auxiliar el avance del propio proyecto. Normalmente, son los resultados de una actividad que son necesarios para poder empezar la actividad siguiente (por ejemplo, la producción de un diseño es necesaria para poder montar un prototipo). Los entregables externos son aquellos que serán entregados a algún interesado externo del proyecto (el cliente, el usuario final, el patrocinador, entre otros.) Los entregables externos deben ser claramente definidos por los interesados, que serán los encargados en su aprobación en el momento de la entrega.
88
2.4.1 La lista de entregables del proyecto Es muy importante, antes de definir el alcance del proyecto, conocer cuáles serán exactamente los entregables que este proyecto generará. Muchos proyectos invierten mal sus recursos en entregables que no aportarán lo que realmente el cliente necesita. Esto se traduce en un desperdicio de tiempo y dinero, además de provocar una mala sensación. Para evitar esta situación, se confecciona una lista de entregables. Su procedimiento de desarrollo es muy sencillo y resulta bastante eficaz. Una de las formas más sencillas de definir los entregables de un proyecto es a través de la organización de una reunión entre todos los interesados del proyecto y cada uno de ellos escribirá en una hoja de papel cuáles son sus deseos en relación al proyecto que se desarrollará. Esta “lista de deseos” es libre y muchas veces será muy extensa, lo que ya demuestra cómo muchos proyectos empiezan con una sobrecarga de entregables innecesaria. Cada interesado entrega su hoja y, utilizando el sentido común, se van eliminando todos los deseos innecesarios. Es importante registrar la justificativa por la cual el deseo fue eliminado. Un listado de deseos rechazados y sus justificativas correspondientes podrán ser utilizados en proyectos futuros. Los artículos que no fueron eliminados dejarán de ser deseos y ganaran el estatus de “entregables potenciales”. A partir de este momento, estos entregables potenciales pertenecerán a una lista de requisitos del proyecto, donde se realizará un análisis todavía más riguroso. Una vez realizado este filtro final, la lista de requisitos, ampliamente justificada y detallada, formará parte de la línea base de alcance (que será la EDT, descrita en la sección 5.3) y, partir de ahí, se empezarán a desarrollar las líneas base de tiempo y coste del proyecto. En un proyecto pequeño, este filtro podrá ser realizado por todos los interesados presentes. En proyectos grandes, normalmente se forma una junta para realizar esta gestión. Esta técnica corresponde a un grupo de técnicas ampliamente explicada en el proceso de definición del alcance, sección 5.2, del capítulo 5.
2.5 Caso Práctico Cuando hablamos del Project Management, lo primero que nos viene a la mente son los grandes proyectos tecnológicos, o de ingeniería. Como he comentado al principio, un proyecto posee características bien definidas que pueden encajar perfectamente tanto en emprendimientos profesionales como personales. Por esta razón, terminaremos este capítulo utilizando los conceptos anteriormente explicados (actividades, fases, procesos y entregables) en un proyecto personal muy importante: la realización de una boda. De esta forma, podremos visualizar de una forma muy sencilla dos cosas: cómo estos conceptos se aplican en la práctica y cómo un proyecto personal puede perfectamente ser administrado utilizando las técnicas del Project Management.
89
La boda de Jacobo y Marta Jacobo y Marta se van a casar en verano, precisamente en el mes de septiembre. Quieren disfrutar de las agradables temperaturas del final de la estación y aprovechar las ofertas de viaje que por estas épocas suelen ser menos concurridas que en los meses de julio y agosto. Ambos saben que la celebración de una boda conlleva a la administración de una serie de factores que incluyen, entre otras cosas:
·
Un presupuesto.
·
Una fecha que no puede ser aplazada.
·
La contratación de profesionales que actuarán de forma coordinada en el día de la celebración de su boda.
Como es natural, los novios tienen un alto grado de expectativa en relación a este evento que, sin duda, es inolvidable en la vida de cualquiera. Para ello, contrataron el personal que formará el equipo (fotógrafo, florista, imprenta, músicos...), a través de recomendaciones muy fiables. Además, ambos tuvieron el cuidado de planificarlo todo con mucha antelación. A partir de esta introducción, empezaremos a definir el conjunto de actividades, fases y procesos que fueron conceptualmente explicados anteriormente y organizarlos en el proyecto de la boda de Jacobo y Marta:
La lista de actividades
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Planificación y definición de la fechas. Búsqueda, acuerdos y contratación de la iglesia. Búsqueda, acuerdos y contratación del florista. Búsqueda, acuerdos y contratación de los músicos. Búsqueda, acuerdos y contratación de la imprenta. Búsqueda, acuerdos y contratación del modista. Búsqueda, acuerdos y contratación del fotógrafo. Búsqueda, acuerdos y contratación del restaurante. Búsqueda, acuerdos y contratación del viaje de luna de miel. Búsqueda, acuerdos y contratación del alquiler de un coche. Preparación de la lista de invitados. Envío de las invitaciones. Primera prueba del vestido. Segunda prueba del vestido. Tercera prueba del vestido. Primera prueba del traje. Segunda prueba del traje. Llamadas de confirmación a los profesionales contratados.
90
19. 20.
Ejecución de la boda. Celebración en el restaurante.
91
Podríamos tener, por lo tanto, las siguientes fases:
1. 2. 3. 4. 5. 6.
Búsqueda y contratación de profesionales. Pruebas de indumentaria. Gestión de invitaciones. Llamadas de seguimiento y verificación. Realización de la boda. Celebración final.
Fases y personal implicado (interesados) FASES
1
2 3 4
Búsqueda y contratación de profesionales
Pruebas de indumentaria Gestión de las invitaciones Llamadas de seguimiento y verificación
5
Realización de la boda
6
Celebración final
92
PERSONAL IMPLICADO Novios, familiares, amigos y los profesionales implicados (personal de la iglesia, florista, músicos, imprenta, modista, fotógrafo, personal del restaurante, alquiler de un coche y agencia de viajes) Novios y modista Novios y familiares Novios, familiares y profesionales implicados correspondientes Novios, familiares y profesionales implicados correspondientes Novios, familiares y profesionales implicados correspondientes
Distribución de las actividades en las fases FASE
ACTIVIDADES
ENTREGA BLES
Planificación de fechas Confeccionar plan Inicial
Dimensión de la ceremonia
Plan de la boda
Búsqueda de profesionales Contratación de iglesia Contratación de florista Contratación de músicos Contratación de imprenta Realizar contrataciones
Contratación de modista Contratación de fotógrafo Contratación del restaurante
Contrat os de servici os
Contratación del viaje Alquiler de un coche 1ª prueba del vestido 2ª prueba del vestido Realizar las pruebas
3ª prueba del vestido 1ª prueba del traje
Ropa s aprob adas
2ª prueba del traje Confección del listado de invitados Envío de invitaciones Ejecutar gestiones prenupciales
Llamada a los contratados para confirmar las gestiones oportunas Llamada a los invitados para confirmar la recepción de invitación
Realizar la boda
Realización de la ceremonia
Celebrar
Realización de la cena
Viajar
Viaje de luna de miel
93
Confirma ciones de invitados y profesion ales Boda realizada Cena realizada Viaje realizado
... ¡Y ahora vamos a la práctica !
94
Capítulo 3 Selección de pro yectos “El requisito del éxito es la prontitud en las decisiones” Francis Bacon14, filósofo inglés
96
Algunas cosas en las que NO puedes pensar acerca de la selección de proyectos “Somos capaces de asumir cualquier proyecto sin restricciones”. No existe una empresa, país o persona que pueda contar con una capacidad ilimitada de recursos. Las empresas que gestionan proyectos deben tener en cuenta su capacidad operacional y asumir los proyectos cuya demanda de recursos sea compatible con su capacidad. “A un que no lo parezca, nuestro equipo está capacitado para trabajar en muchos proyectos a la vez”. Esta afirmación tiene una relación directa con la anterior. Todas las empresas cuentan con una capacidad limitada de recursos y, por ello, debería asumir un número máximo de proyectos simultáneos que les permita ejecutarlos sin incidencias. La gestión de los recursos humanos en los proyectos puede ser fácilmente desarrollada mediante el uso de calendarios (descritos en la sección 9.4.1.7), que son definidos a través de los cronogramas del proyecto. En los calendarios se definen los días y el horario que cada integrante del equipo estará dedicado a cada proyecto en que haya sido asignado. Además, un Project Manager no debe asumir muchos proyectos a la vez o su capacidad de administrarlos se verá comprometida. “No piensen mucho. El mejor proyecto es aquel que nos aportará más ingresos”. La selección de un determinado proyecto incluye una serie de diferentes variables y, en muchos casos, la variable financiera no es la más importante. Existen proyectos que no generan ganancias, pero sí pueden aportar una visibilidad a la empresa en su sector de actuación. En realidad, el mejor proyecto es aquel que satisface la necesidad inmediata de la empresa ejecutante. “Quien tiene que decidir qué proyectos vamos a trabajar es la dirección” La puesta en marcha de un proyecto dependerá de la decisión de una serie de interesados que se basarán en los resultados obtenidos de las técnicas presentadas en este capítulo. “Para elegir un proyecto, nada mejor que la intuición”. Es cierto que la intuición puede llegar a ser útil, sobre todo cuando la toma de decisiones se realiza bajo un alto nivel de incertidumbre y presión para llegar a la decisión correcta. Sin embargo, la intuición no puede ser el único recurso disponible. En el artículo intitulado “Don´t trust your gut” (No confíe en su intuición), publicado en la revista Harvard Business Review, su autor, Eric Bonabeau15, nos hace la siguiente reflexión: “La confianza en la intuición es comprensible. Ante la confusión terrenal, la gente pone su fe en fuerzas místicas. Esto es peligroso. La intuición tiene su lugar en la toma de decisiones -no se debe ignorar el instinto así como no se ignora la conciencia-, pero quien piense que puede reemplazar la razón arriesga a engañarse. Alejada de un análisis riguroso, la intuición es una guía insegura e inestable, puede lle var tanto al éxito como al fracaso. Cuanto más numerosas sean las opciones, mayores los datos por ponderar y más imprevistos los desafíos por enfrentar, menos deberá utilizarse la intuición y más el
97
razonamiento y el análisis”.
Introducción Un proyecto normalmente es fruto de una necesidad. Todo comienza cuando una persona, un departamento o una empresa necesitan de un producto o servicio que todavía no existe, y si existe, necesita de incrementos. Son varias las razones por las que se ponen proyectos en marcha. Algunas son más tangibles y lucen más que otras. A veces, un proyecto es creado para aprovechar un momento oportuno del mercado o para disminuir la cantidad de problemas que un determinado factor provoca. Desgraciadamente, las organizaciones no disfrutan de recursos infinitos, y por ello no pueden poner en marcha todos los proyectos que les gustaría desarrollar. Por esta razón, las organizaciones son obligadas a decidir qué proyectos rechazarán y qué proyectos serán puestos en marcha. Esta decisión, normalmente, es tomada de acuerdo con los recursos disponibles en la empresa (personal, maquinaria, plazos y fondos financieros), o en muchos casos, por la importancia estratégica que un proyecto puede aportar. Es importante que la organización pueda establecer un proceso formal de selección de proyectos a través de criterios que le permitan realizar una elección coherente que debe ser muy estudiada, puesto que, en algunos casos, y dependiendo de su importancia, el proyecto elegido podrá determinar el rumbo de la empresa hacia el futuro. Además, el proyecto elegido consumirá los recursos de la empresa durante un periodo de tiempo que puede ser de unos meses o quizás años. Por esta razón, es fundamental que los proyectos elegidos sean los que aportarán beneficios, financieros o estratégicos, algo difícil de prever sin que se realicen estudios previos. Por lo menos en el ambiente empresarial, lo que lleva una organización a poner en marcha un proyecto es la oportunidad de obtener beneficios financieros. La forma más sencilla y eficaz de verificar si un proyecto puede ser rentable para la empresa es comparando las ganancias financieras del proyecto con sus costes. Existen varias técnicas que auxilian la organización para elegir el proyecto conveniente y que ofrecen distintos enfoques. Este capítulo presentará una serie de técnicas que podrán ser muy útiles a la hora de decidir qué proyectos serán desarrollados.
3.1 Criterios para la selección de proyectos Las organizaciones necesitan adoptar metodologías que les permitan elegir los proyectos que les aporten los mejores beneficios por una cuestión ante todo financiera, pero también para poder preservar su imagen de organización competitiva y, sobre todo, competente. Seleccionar un proyecto no es una decisión sencilla. Para que un proyecto tenga éxito, además de tener que contar con buenos recursos, tendrá que depender de una infinidad de variables cuyos resultados podrán o no ser previstos. Elegir un modelo o un criterio de selección de proyectos es una tarea que implica el cumplimiento de una serie de requisitos importantes que deberán tenerse en cuenta. William E. Souder 16, en su libro Project Selection and Economic Appraisal, establece algunos:
•
Realismo: El criterio elegido deberá reflejar la realidad de la situación actual, incluyendo los múltiples objetivos que puedan tener la empresa y sus gerentes. Por ejemplo: el proyecto “A” podrá incrementar su participación en su mercado de actuación y el proyecto
98
“B” podrá incrementar su competitividad. ¿Cuál es el mejor? El modelo deberá estar alineado con los objetivos estratégicos de la organización, sin dejar de tener en cuenta las limitaciones que todas las empresas suelen tener (costes, personal, plazos...).
99
• Capacidad: El modelo debe ser el capaz de generar resultados que permitan realizar comparaciones con escenarios diferentes, optimizando el proceso de decisión.
·
Flexibilidad: Para cumplir correctamente con el requisito anterior, el modelo tiene que ser flexible, es decir, debe permitir modificar variables y generar diferentes resultados, de acuerdo con el escenario que se aplique.
·
Manejo: Un modelo de selección de proyectos debe ser de fácil comprensión y los resultados generados no deberán ser difíciles de interpretar. Para ellos, los datos utilizados en el modelo deberán ser exactos, actualizados y no excesivos.
·
Coste: El proceso para la extracción de los datos, el tratamiento de los mismos y el análisis de los resultados no debe ser costoso ni consumir demasiado tiempo.
Jack R. Meredith17, en su libro Project Management, A Managerial Approach, añade un requisito más:
·
Easy Computerization: Es decir, los resultados generados deben tener un formato que permita su almacenamiento, tratamiento y distribución en una herramienta ofimática.
Los criterios de selección de proyectos pueden dividirse básicamente en dos categorías: financieros o no financieros. Se podrá utilizar uno de ellos o ambos, todo dependerá de los objetivos y de las necesidades de cada organización. Es importante resaltar que la elección adecuada del modelo de selección de criterios dependerá, sobre todo, de la naturaleza del proyecto. Eric Verzuh2, en su libro The Portable MBA in Project Management, nos hace una reflexión muy importante que merece la pena plasmarla aquí:
·
Los modelos de selección de proyectos no toman decisiones: Son las personas, no el modelo, las que responden por la responsabilidad de la decisión. La dirección de la empresa puede “delegar” en un modelo la tarea de tomar la decisión, pero no podrá abstenerse de la responsabilidad de las eventuales consecuencias producidas por dicha decisión.
·
Cualquier modelo de decisión, por más sofisticado que pueda parecer, solo podrá reflejar una parte de la realidad: De hecho, la vida real es demasiado compleja y un modelo, como mucho, podrá reflejar una parte del escenario. No obstante, la elección de un modelo o criterio de selección adecuado nos puede aportar resultados muy valiosos que nos podrá conducir al camino correcto.
El uso combinado de herramientas financieras y no financieras podrá asegurar resultados más fiables para la selección de un proyecto o de una acción.
3.1.1 Criterios financieros para la selección de proyectos Los criterios financieros para la selección de proyectos nos proporcionan unos indicadores que nos permiten evaluar el atractivo económico del proyecto. Estos indicadores también sirven para realizar comparaciones entre diferentes alternativas de inversión en el abanico de potenciales proyectos de
100
la organización.
101
3.1.1.1 Analisis beneficio-coste (Benefit-cost analysis – BCA)
Descrito en la sección 8.1.1.1
3.1.1.2 Punto de equilibrio (Break even point) El grafico del punto de equilibrio (también conocido como break even point) es uno de los métodos de selección de proyectos más sencillos de utilizar. Se trata de un gráfico que compara el coste total estimado de dos alternativas en un determinado periodo de tiempo. El punto de equilibrio es el punto en el que:
· · · ·
Una alternativa empieza a tener un coste menor que la otra. Las ganancias igualan a las perdidas. Una inversión generará una rentabilidad positiva. Los ingresos igualan a los costes.
Lograr el punto de equilibrio no devolverá las perdidas ocurridas en el pasado. Tampoco acumulará una reserva para pérdidas futuras. Además, no proporcionará un retorno sobre la inversión. Sin embargo, podrá decirnos cuál es la alternativa más rentable, a través de las proyecciones que esta herramienta puede producir. El gráfico del punto de equilibrio es confeccionado con el uso de dos ejes: “X” (tiempo) e “V” (coste total del proyecto). La escala de valores utilizada será la que el punto de equilibrio se encuentra en el medio del eje de coste. Una nueva alternativa (el proyecto que será puesto en marcha) normalmente tendrá un único coste fijo asociado. Este coste se llamará “coste fijo del proyecto”. El coste variable del proyecto es el que seguirá ocurriendo mientras la nueva alternativa esté en operación. Un ejemplo bastante sencillo es la compra de una nueva máquina de producción de tornillos que reemplazará a la antigua que sigue en operación en una fábrica. La nueva máquina produce más piezas por hora y tiene un mantenimiento más barato. Suponemos que esta nueva máquina tiene un coste de treinta mil euros. Este coste solamente ocurrirá una vez (en el momento de la compra), con lo cual su coste fijo será de treinta mil euros. El equipo antiguo, que todavía sigue en funcionamiento, no tiene ningún coste fijo asociado. Las dos alternativas tendrán un coste variable asociado y, cuando se comparan los costes variables de la maquina antigua y de la nueva, es importante asociar los mismos costes para ambas alternativas. En este caso, el coste variable puede ser, por ejemplo, su consumo energético, su coste de operación... Si la máquina antigua en funcionamiento produce mil piezas por mes, se espera que la nueva máquina produzca, por lo menos, el mismo número. Además, se estima que el coste variable de la nueva máquina sea menor que el de la antigua.
102
Figura 16: Punto de equilibrio Según ilustra la figura 16, el gráfico del punto de equilibrio tendrá las siguientes características:
·
La línea del coste variable de la máquina nueva deberá presentar una subida menor que la línea del coste variable de la antigua.
·
La línea de coste variable de la máquina nueva empieza en el mismo punto del eje “Y” (coste total) del coste fijo de su adquisición. Por otro lado, la línea del coste variable de la máquina antigua empezará en el punto cero del eje “Y”.
·
En algún momento, el total de la línea del coste de la máquina nueva (la suma de coste variable más el coste fijo) se cruzará con el coste variable de la antigua. Este es el punto conocido como el “punto de equilibrio”.
·
Al alcanzar el punto de equilibrio, el dinero ahorrado en el coste variable de la máquina nueva comparado con de la antigua es igual a la inversión de la máquina nueva. O sea, es el punto donde el coste total de las dos alternativas es exactamente el mismo. Cuanto más temprano este punto sea alcanzado, mejor estará justificada la compra de la nueva máquina.
·
A partir del punto de equilibrio, la diferencia entre las dos líneas de coste total traducirá en la reducción de costes proporcionada por la adquisición de la nueva máquina.
3.1.1.3 Valor presente neto VPN (Net present value – NPV) El valor presente neto (VPN) o valor actual neto (VAN) es uno de los métodos más utilizados para determinar si un proyecto es financieramente viable. Su fórmula permite calcular el valor presente de un determinado número de flujos de caja futuros, originados por una inversión. Su propósito es
103
medir el valor agregado con que contribuye el proyecto a la organización
104
Para realizar el cálculo del VPN es importante tener a mano las siguientes informaciones:
·
La inversión inicial previa: Es el valor que será invertido inicialmente por la organización para poner en marcha un proyecto. Este valor incluye la inversión realizada en maquinaria, instalaciones, personal...
·
Las inversiones durante la operación: Incluye las inversiones realizadas para el reemplazo o renovación de maquinaria, ampliación de locales, nuevas contrataciones de personal...
·
Los flujos netos de efectivo – FNE: Son aquellos flujos de efectivo que el proyecto debe generar después de su puesta en marcha.
·
La tasa de descuento: Es una medida financiera que se aplica para determinar el valor actual de un pago futuro.
·
El número de periodos que dure el proyecto: Estos periodos normalmente son equivalentes a un año fiscal.
Cómo se calcula el VPN Supongamos que una organización tiene que elegir entre dos proyectos para poner en marcha uno de ellos y ha elegido el cálculo del VPN como el criterio definitivo de elección. El proyecto “A” contiene las siguientes características: Valor de la inversión inicial: 10.000 euros Los flujos netos de efectivo (FNE) durante los próximos cinco años son los siguientes: Año 1: 2.000 euros Año 2: 3.000 euros Año 3: 3.000 euros Año 4: 2.000 euros Año 5: 5.000 euros
Figura 17: Flujos netos de efectivo del proyecto “A”
Para desarrollar la evaluación de estos proyectos se estima una tasa de descuento anual del 15%: Como se puede observar en la figura 17, la inversión inicial aparece en el periodo cero, y con la señal negativa, ya que se ha realizado un desembolso de dinero por el valor de 10.000 euros y, por lo tanto, debe registrarse como tal. Los importes de los FNE de los periodos 1 al 5, son positivos; esto quiere decir que en cada periodo los ingresos de efectivo son mayores a las salidas. Como el dinero tiene un valor diferente en el tiempo, el siguiente paso es conocer el valor de cada uno de los FNE en el periodo cero. Para esto, se descontará cada uno de los flujos a su tasa de
105
descuento, que será del 15%. La fórmula que utilizaremos es la siguiente:
106
VPN = - 10.000 + [2.000 / (1.15)1] + [3.000 / (1.15)2] + [3.000 / (1.15)3] + [2.000 / (1.15)4] + [5.000 / (1.15)5] VPN = - 10.000 + [1739 + 2268 + 1973 + 1144 + 2486] VPN = -390
Cada flujo será dividido por su tasa de descuento elevada a una potencia que es equivalente al número del periodo donde se espera dicho resultado. Una vez realizada esta operación, se habrá calculado el valor de cada uno de los FNE a euros de hoy, que, en este ejemplo, es de 9.610,00. Basado en este resultado, ¿podemos decir que el proyecto es viable? Según lo descrito anteriormente, el VPN tiene como propósito principal medir el valor agregado con que contribuye el proyecto a la firma. Por ello, se pueden presentar, entonces, las siguientes situaciones:
·
Si el resultado obtenido es positivo, entonces el VPN es positivo. Por lo tanto, se está añadiendo valor y el proyecto debe aceptarse.
·
Si el resultado obtenido es negativo, entonces el VPN es negativo. De esta forma, se está destruyendo valor y el proyecto debe rechazarse.
·
Cuando se tienen varios proyectos con VPN positivo, entonces se debe escoger el que tenga mayor VPN. Este proyecto es el que crea más valor para la organización.
·
Existen casos en que el VPN es igual a cero. Esto quiere decir que el proyecto no estará añadiendo ni destruyendo valor, por lo menos en términos financieros. No obstante, es importante tener en cuenta que un proyecto puede no proporcionar valor financiero, pero sí que podrá aportar otro tipo de beneficios (tecnológicos, funcionales, entre otros).
En el ejemplo descrito anteriormente, el VPN obtenido ha sido negativo. La inversión realizada resultaría en una pérdida de 390 euros, es decir, no se debería poner este proyecto en marcha. Por otro lado, el proyecto “B” contará con la misma inversión inicial del proyecto “A” (10.000 euros); sin embargo, contará con diferentes flujos netos de efectivo durante los próximos cinco periodos, tal como ilustra la figura 18:
Figura 18: Flujos netos de efectivo del proyecto “B”
Tal y como ha ocurrido con el proyecto “A”, se toma como tasa de descuento al 15%. Así, la formula se desarrollará de la siguiente forma: VPN = VPN VPN =
10.0 3.08 8
+ [6.000 / (1.15)1] + [3.000 / (1.15)2] + [3.000 + [5217 + 2268 + 1973 + 1144 + 2486]
107
/ (1.15)3] + [2.000 / (1.15)4] + [5.000 / (1.15)5]
Como el resultado es positivo, el proyecto “B” maximizaría la inversión en 3.088 euros a una tasa de descuento del 15% y, por lo tanto, el proyecto debe ejecutarse.
108
Como se podrá observar, la diferencia entre los dos proyectos reside en los flujos netos de efectivo del primer periodo. El proyecto “A” contiene unos ingresos inferiores que el proyecto “B”, lo que, en definitiva, determina la elección de la puesta en marcha del proyecto “B”.
3.1.1.4 Tasa interna de retorno – TIR (Internal rate of return - IRR) La tasa interna de retorno – TIR es la tasa de interés con la cual el valor presente neto – VPN (descrito en la sección anterior), es igual a cero. El VPN es calculado a partir del flujo de caja anual, donde se trasladan todos los valores futuros al presente. Es también un indicador de la rentabilidad de un proyecto, es decir, a mayor TIR, mayor rentabilidad. Es ampliamente utilizada para decidir la aceptación o rechazo de un proyecto. Para ello, la TIR se compara con una tasa mínima o tasa de coste, el coste de oportunidad de la inversión. Si la tasa de rendimiento del proyecto (expresada a través de la TIR) supera la tasa de coste, se acepta la inversión. De lo contrario, se rechaza.
Poniendo un ejemplo: Los técnicos de una empresa industrial están estudiando dos propuestas para la adquisición de una máquina. La propuesta “A” presenta una máquina que cuesta 100.000 euros y con una vida útil prevista de cinco años. La propuesta “B” presenta una maquina con el doble de la capacidad de la primera, y con una vida útil prevista de diez años, con un precio de compra de 175.000 euros. Ambas máquinas tendrán valor de reventa cero tras el periodo de su vida útil. La máquina con menor capacidad (propuesta “A”) puede atender plenamente a la producción prevista para los próximos cinco años. Como, a partir del sexto año, se prevé un aumento importante de la producción, la compra de la máquina pequeña a día de hoy implicaría la necesidad de compra de otra máquina con las mismas características al final del quinto año por el mismo precio de la actual (100.000 euros). Comprando esta máquina, los ingresos líquidos anuales (ya descontados todos los costes, con excepción de la depreciación) serían los siguientes:
· · ·
55.000 euros al año para los cinco primeros años. 70.000 euros para los dos años siguientes. 95.000 euros para los tres últimos años.
Si se decide comprar la máquina grande (propuesta “B”), los ingresos líquidos anuales serían:
· · ·
58.000 euros para los próximos dos años. 65.000 euros para los tres años siguientes. 95.000 euros para los cinco últimos.
109
¿Cuál sería la mejor opción de compra? Los diagramas representativos de los flujos de caja de las dos propuestas serían los siguientes:
110
Propuesta “A” Máquina pequeña (valores expresos en 1.000 euros)
Figura 19: Flujo de caja de la propuesta “A”
Propuesta B Máquina grande (valores expresos en 1.000 euros)
Figura 20: Flujo de caja de la propuesta “B”
La opción elegida deberá ser la que presenta la mayor TIR
La TIR de la propuesta “A” es la siguiente:
Utilizando una calculadora financiera, se obtiene i = TIR 42,42% al año
111
La TIR de la propuesta “B” es la siguiente: En este caso, la TIR es de 36,49% al año. Por lo tanto, la TIR de la propuesta “A” (máquina pequeña) es mayor que la TIR de la propuesta “B” (máquina grande), por lo tanto, la mejor opción de compra es la primera.
3.1.1.5 Periodo de reembolso (Payback periodPP) El periodo de reembolso (payback period - PP) es el tiempo necesario para recuperar una inversión inicial. El periodo de reembolso, además, puede representar la cantidad de tiempo que toma para el presupuesto de un proyecto y para que recupere su inversión final. La figura 21 ilustra el flujo de caja de una propuesta de inversión. ¿Cuánto tiempo es necesario hasta que los flujos de caja acumulados de una inversión alcancen o superen su coste inicial? Según la figura 21, se realiza una determinada inversión inicial de 100.000 €. En el año siguiente, la empresa recupera 40.000 €, quedando descubierta en 60.000 €. El flujo de caja del segundo año es de exactamente 60.000 €, o sea, la inversión se ha recuperado en dos años, o en otras palabras, el periodo de reembolso es de dos años. Si un proyecto exigiera un periodo de reembolso de tres años, en este caso, la inversión sería aceptable.
Figura 21: Flujo de caja
¿Cómo se calcula el periodo de reembolso? Para calcular el periodo de reembolso se utiliza la siguiente fórmula: Suponemos que un proyecto cueste 5.000 €. ¿Cuál sería el periodo de reembolso de esta inversión? El coste inicial es de 5.000 €. Tras los dos primeros años, los flujos de caja totalizan 3.000 €. Después del tercer año, los flujos de caja alcanzan la cifra de 8.000 €; por lo tanto, el proyecto fue pagado en algún momento entre el final del segundo año y el comienzo del tercero. Como el flujo de caja acumulado en los dos primeros años es de 3.000 €, es necesario recuperar los otros 2.000 € en el tercer año. El flujo de caja del tercer año es de 5.000 €, es decir habrá que esperar 2.000 € / 5.000 € = 0,40 años. El periodo de reembolso es, por tanto, de 2,4 años o cerca de dos años y cinco meses.
112
1
FLUJO DE CAJA 1.000 €
2
2.000
€
3
5.000
€
AÑO
Figura 22: Cálculo del periodo de reembolso
3.1.1.6 Retorno sobre la inversión – RSI (Return on investment – ROI) El retorno sobre la inversión – RSI (return on investment – ROI) es un porcentaje que se calcula en función de la inversión y los beneficios obtenidos para cuantificar la viabilidad de un proyecto. La fórmula más sencilla de obtenerlo es la siguiente:
ROI = (beneficio obtenido - inversión) / inversión Utilizando un sencillo ejemplo: La puesta en marcha de un proyecto ha exigido una inversión total de 1.000 euros. Los beneficios generados por este proyecto han alcanzado la cifra de 3.000 Euros. En este caso vamos a tener un ROI de:
(3.000 – 1.000) / 1000 = 2 2 * 100 = 200% De esta forma, el proyecto ha obtenido un retorno del 200%, es decir, una excelente inversión. Se pueden desarrollar fórmulas bastante más sofisticadas que el ROI, de todas formas, este ejemplo ilustra exactamente toda la dinámica de resultados generados por esta herramienta.
3.1.2 Criterios no financieros para la selección de proyectos Hay ocasiones en las que una empresa no puede asumir el desarrollo de muchos proyectos simultáneos por no disponer de recursos, sean humanos, financieros o materiales. En este caso, las empresas normalmente se inclinan por los proyectos más rentables, y para ello existe una serie de criterios financieros, como los que hemos visto antes, que pueden proveer el valor aproximado de ganancias (o pérdidas) que un proyecto puede llegar a generar. Sin embargo, en muchos casos, el resultado financiero no es el más importante que una empresa necesita saber para decidir por un proyecto u otro. Existen proyectos que no generan ganancias, pero sí pueden aportar una visibilidad a la empresa en su sector de actuación. De hecho, muchas empresas de tecnología no generan ganancias financieras a corto plazo con sus productos innovadores, pero pueden presumir de haber sacado al mercado una tecnología puntera que les situará como referencia en un determinado segmento.
113
A continuación, veremos cuáles son las herramientas que pueden ayudar a elegir la elección de desarrollar un determinado proyecto, basado en resultados no financieros.
3.1.2.1 Tributos ponderados (Decision matrix) Analizaremos los atributos determinados por una constructora para la adquisición de un terreno en un barrio de la ciudad. Son muchos los barrios que ofrecen terrenos aptos para construir. La elección del barrio para la construcción de la urbanización será realizada en función de los resultados determinados por cada atributo. Han sido elegidos cuatro atributos que la constructora considera relevantes: seguridad, comunicación, comercio y transportes, y se les ha adjudicado una escala de pesos entre 0.10 y 0.25, según establecido por la constructora.
OPCIONE S Barrio A Barrio B
SEGURI DAD (.25) pun tot tos al 0,7 3 5 0,7 3 5 0,5 2 0
COMUNICACIÓN COME RCIO TRANSPORTES (.20) (.25) (.10) punto total punt tot punt total s os al os 0,5 1 0,2 2 2 0,2 0 0,7 4 0,8 3 3 0,3 5 0,7 4 0,8 3 4 0,4 5
PUNTOS
1.65 2.60 2.45
Figura 23: Tabla de atributos ponderados
Se multiplican los pesos de cada atributo por el valor definido a cada barrio. El resultado determinará la mejor opción. En el ejemplo, utilizando cuatro atributos y una escala de cuatro valores, el barrio B es la mejor la alternativa para la construcción de viviendas, puesto que ha logrado la mejor puntuación en relación a las alternativas restantes. Es importante resaltar que el resultado es directamente influenciado por los pesos determinados, como figura en el ejemplo presentado. Otra constructora podría atribuir pesos distintos para cada atributo, cambiando el resultado final. Eso quiere decir que los valores resultantes de la matriz de decisión no son absolutos, pues dependerán de la evaluación dada por cada empresa, en función de sus valores.
3.1.2.2 Toma de decisiones (Decision making) En muchas ocasiones, una empresa se encontrará delante de una situación que les exigirá tomar una decisión que, en muchos de los casos, dependerá de los valores o experiencias del grupo encargado de realizar dicha decisión, lo que normalmente puede generar un conflicto de interés dentro del grupo.
114
Para realizar una toma de decisiones exenta de criterios personales, es importante establecer un conjunto de reglas que permita que esta decisión sea tomada de forma coherente y lo menos arriesgada posible. Los modelos clásicos de toma de decisiones normalmente están asociados al proceso de resolución de problemas, que se inicia de la siguiente manera: 1. Identificar el problema. 2. Determinar las alternativas. 3. Implementar la decisión elegida. En este caso, no estamos delante de un problema, lo que tenemos es un abanico de posibles proyectos en que necesitaremos elegir el que mejor atienda nuestras necesidades. De esta forma, el proceso seria el siguiente:
Figura 24: Ciclo de la toma de decisiones
El proceso de toma de decisiones se puede desarrollar de dos formas: cualitativa y cuantitativa. El análisis cualitativo se basa, sobre todo, en la experiencia del decisor, mientras que en el análisis cuantitativo, la decisión es tomada en base a los datos y las informaciones obtenidas de proyectos anteriores similares.
Figura 25: Proceso de la toma de decisiones
Un proceso de toma de decisión puede caer en tres categorías:
·
Toma de decisiones bajo certidumbre: El tomador de decisiones conoce los datos de forma determinista.
·
Toma de decisiones bajo riesgo: Los datos se describen mediante distribuciones de probabilidad.
·
Toma de decisiones bajo incertidumbre: En esta situación, no es posible asignar a los datos, pesos relativos que representen su grado de relevancia en el proceso de decisión.
115
3.1.2.3 Análisis del árbol de decisiones (Decision tree analisys)
Descrita en la sección 11.4.1.5.
3.1.2.4 Proceso de análisis jerárquico (Analytic hierarchy process AHP) Desarrollado por el matemático Thomas L. Saaty18 en los años setenta, el proceso analítico jerárquico - PAJ (más conocido por su sigla en inglés: Analytic Hierarchy Process - AHP) es una técnica utilizada para facilitar el proceso de toma de decisiones complejas, mediante la confección gráfica de un modelo jerárquico que tratará de organizar la información, descomponerla y analizar sus partes. Utilizando las palabras del propio autor: “Se trata de desmesurar un problema y a continuación unir todas las soluciones de los sub problemas en una solución”. Un PAJ es diseñado de la siguiente forma:
1. Modelar el problema como una jerarquía El primer paso consiste en modelar el problema como una jerarquía. De esta forma, será posible explotar los aspectos del problema en niveles que podrán ir desde un nivel general hasta un nivel bien detallado, luego expresarlos en la forma multinivel que el PAJ requiere.
2. Definir las jerarquías Se puede decir que una jerarquía es un sistema de organización donde cada elemento es subordinado por uno o más elementos. Uno de los diagramas de jerarquía más conocidos en el Project Management es la EDT (estructura de diagrama de trabajo, descrito en la sección 5.3). En el caso del PAJ, podemos utilizar este tipo de diagrama para resolver un problema de decisión complejo, construyendo una estructura de información robusta, que nos pueda proporcionar una toma de decisión correcta y bien documentada. La jerarquía de un PAJ empieza por un objetivo general en el nivel superior, que se desglosará en un nivel inferior en un grupo de alternativas para alcanzar el objetivo deseado. Entre los dos, se posicionará un grupo de criterios que relacionarán las alternativas con el objetivo.
116
Figura 26: Jerarquía básica de un PAJ
El diseño de cualquier jerarquía PAJ es libre siempre y cuando obedezca la estructura ilustrada en la figura 26. Su formato dependerá de la naturaleza del problema y de las necesidades de la empresa. A medida que el proceso de diseño y análisis del PAJ avanza, su estructura podrá cambiar, así como sus criterios y/o valores, estableciendo nuevos resultados que influenciarán directamente en la toma de decisión.
3. Establecer prioridades Una vez que la jerarquía se ha construido, se establecerán las prioridades de todos sus nodos. Las prioridades son los números que serán asignados a estos nodos y que representan los pesos relativos de los nodos en cualquier grupo. Por definición, la prioridad de un objetivo es siempre mil, valor que representa la suma de las prioridades de los criterios, así como de las alternativas. De esta forma, un nodo con una prioridad .200 tiene el doble del peso de una prioridad .100, o diez veces más peso que uno con prioridad .020 y así sucesivamente. El concepto de “peso” puede representar “importancia”, “preferencia”, “necesidad” o cualquier factor considerado importante por los decisores. Las prioridades serán distribuidas sobre la jerarquía de acuerdo con su estructura y sus valores dependerán de la información introducida. Es importante tener en cuenta que el objetivo, los criterios y las alternativas estarán siempre estrechamente relacionadas.
117
Figura 27: PAJ con valores asignados
Normalmente, un PAJ es confeccionado durante una sección de lluvia de ideas, o brainstorming (descrito en la sección 11.2.1.8) y, por esta razón, es diseñado con valores por defecto, tal y como ilustra la figura 27, con las prioridades de cada nivel sumando mil en total. Es importante iniciar el diseño de un PAJ con valores por defecto, porque durante el proceso puede aparecer uno o más criterios nuevos, y de esta forma, será necesario distribuir los valores por igual. Si por ejemplo se adiciona un quinto criterio a la jerarquía, la prioridad por defecto de cada criterio sería .200. Si hay sólo dos alternativas, cada una tendrá una prioridad por defecto de .500. A continuación, analizaremos un PAJ aplicado a la compra de equipo Informático para un determinado proyecto. Una empresa necesita comprar equipos que puedan responder técnicamente a las necesidades del proyecto, y tras un breve análisis de las ofertas disponibles en el mercado, han encontrado cuatro fabricantes que comercializan los mejores equipos. Los técnicos del proyecto han establecido cuatro criterios de decisión para la compra de los PC’s: memoria, disco duro, procesador y pantalla. El PAJ de este proceso de decisión será diseñado de la siguiente forma:
Figura 28: PAJ para la compra de PC´s. El objetivo está pintado de color negro, los criterios en gris y las alternativas en blanco. Todas las alternativas (cuatro diferentes fabricantes de PC´s) están desglosados en el nivel más bajo de la jerarquía.
118
En algunos PAJ se podrán crear subcriterios. Es decir, se podría desglosar la pantalla por ejemplo en: tamaño en pulgadas, resolución... En el disco duro se podría también hacer un desglose que incluiría: capacidad, velocidad... Cuando un PAJ contiene muchos sub criterios, los cálculos se vuelven más complejos y esto requerirá el uso de un software especializado. Volvamos a nuestro PAJ: El Project Manager junto con su equipo tendrán que establecer los pesos de cada criterio elegido. Para ello, será necesario comparar cada elemento, uno contra el otro, y decidir cuál es el más importante en cada caso. Se realizarán comparaciones de valor de seis pares: memoria/HD, memoria/procesador, memoria/pantalla, HD/procesador, HD/pantalla, procesador/pantalla. Primero se comparará memoria x HD. Habrá que decidir cuál de estos dos componentes es el más importante. En algunos proyectos técnicos que necesitan ejecutar programas de cálculo estructurales o diseño de planos, la memoria es imprescindible. Sin embargo, en proyectos que necesiten estos tipos de software, no podemos prescindir de un disco duro rápido, con lo cual, la decisión de determinar si la memoria es más importante que el HD, o al revés, no es una tarea sencilla. De todas formas, el PAJ es una herramienta flexible, donde es posible en cualquier momento del proceso, cambiar los valores de importancia de cada criterio. Vamos suponer que, finalmente, el equipo ha decidido que la memoria es ligeramente más importante que el disco duro. El PAJ entonces requerirá que se establezca un valor numérico para esta decisión. Para ello se utiliza una tabla de comparaciones, como la que podemos apreciar a continuación: ESCALA DE COMPARACIÓN POR PARES INTENSIDAD DE IMPORTANCIA 1 3 5 7
DEFINICI ÓN Importa ncia idéntica Importa ncia modera Importa ncia fuerte Importa ncia muy
EXPLICACIÓN Dos elementos contribuyen de forma idéntica al objetivo La experiencia y el juicio de expertos establecen que un elemento es ligeramente más importante que otro La experiencia y el juicio de expertos establecen que un elemento es más importante que otro Un elemento es bastante más importante que otro, según demostrado en la práctica
Los valores 2, 4, 6 y 8 pueden ser utilizados para expresar valores intermediarios. Figura 29: Tabla de escala de comparación por pares
119
Ahora que conocemos los criterios de elección y hemos establecido la escala de comparación de pares, ha llegado el momento de hacer el cruce de esta información. El equipo ha establecido los siguientes valores:
· · · · · ·
La memoria tiene una importancia moderada sobre disco duro (3). La memoria tiene una importancia muy fuerte sobre el procesador (7). La memoria es moderadamente más importante que la pantalla (3). El HD es extremadamente más importante que la pantalla (9). EL HD y tiene la misma importancia que el procesador (1). El procesador es bastante más importante que la pantalla (7).
Con estos valores, confeccionaremos la siguiente tabla:
CRITERIO A
B
MÁS IMPORTAN TE
INTENSID AD
Memoria
HD
A
3
Memoria
Procesador
A
7
Pantalla
A
9
HD HD
Procesador
A
1
Procesador
Pantalla
A
7
Figura 30: Juicio realizado por el Project Manager y su equipo para la compra de equipos informáticos para el proyecto.
Un software especializado utilizará cálculos matemáticos para convertir los valores de las prioridades de cada uno de los cuatro criterios. Los detalles de los cálculos están fuera del alcance de libro debido sobre todo a su complejidad. Sin embargo, podrás tener la información completa de esta herramienta en el proprio libro de Thomas Saaty18 “Fundamentals of Decision Making and Priority Theory” de RWS Publications Una vez realizados los cálculos, el programa traerá las prioridades resultantes de los valores anteriormente establecidos. Debido a la flexibilidad del PAJ, es posible en cualquier momento del proceso, cambiar los valores de importancia de cada criterio y con ello, cambiar el valor de las prioridades.
120
Figura 31: PAJ de la adquisición de equipos informáticos para un proyecto. Los criterios tenían originalmente un valor de .250 cada uno. Después de establecer la escala de comparación por pares y realizar los correspondientes cálculos, las prioridades han dejado de tener la misma importancia y pasaron a tener una importancia acorde con los valores establecidos por el PM y su equipo técnico
121
Capítulo 4 Gestión de la integración “La cooperación es la convicción plena de que nadie puede llegar a la meta si no llegan todos” Virginia Burden Tower 19, escritora y autora de libros estadounidense
122
Algunas cosas en las que NO puedes pensar acerca de la gestión de la integración “No podemos esperar la aprobación formal de cambios. Hazlo ya” Un proyecto es un emprendimiento que afecta a una serie de variables integradas entre sí (costes, plazos, recursos humanos, calidad...). Uno de los grandes desafíos del Project Manager es ejecutar un proyecto “tal y como ha sido planificado”, y para ello, es importante evitar que se produzcan cambios. Cuando esto es inevitable, el Project Manager tendrá que hacerlo de forma planificada, documentada y aprobada por las partes afectadas, puesto que un cambio mal introducido podría desestabilizar todo el proyecto.
Introducción La gestión de la integración consiste en asegurar la integración y coordinación de los elementos del proyecto que compiten entre sí.
Figura 32: Integración de las áreas de la aplicación en un proyecto. El objetivo principal de la gestión de la integración es coger todas las áreas de aplicación del proyecto y literalmente “integrarlas” en una gran y única pieza, como si de un engranaje se tratara.
El Project Manager es, ante todo, un integrador, y por ello, la gestión de la integración tiene que ser la más importante desde su punto de vista, puesto que él es la única persona que debe conocer y tener la visión total del proyecto. Su responsabilidad reside en asegurar el buen avance del proyecto, realizando un seguimiento adecuado y poniendo en marcha las acciones preventivas y/o correctivas adecuadas. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de la integración de un proyecto incluye procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar todos los procesos de la gestión de proyectos. Son ellos:
· · · · · ·
Desarrollar el acta de constitución del proyecto. Desarrollar el plan para la dirección del Proyecto. Dirigir y gestionar la ejecución del proyecto. Monitorizar y controlar el trabajo del proyecto. Realizar el control integrado de cambios. Cerrar el proyecto o fase.
123
4.1 Desarrollo del acta de constitución del proyecto (Proceso que corresponde a la fase de inicio del proyecto) El objetivo de este proceso es autorizar formalmente el inicio de un proyecto o fase, documentando sus requisitos iniciales, necesidades, objetivos y expectativa de los interesados. Esta autorización normalmente viene de un interesado externo, como puede ser, por ejemplo, un patrocinador. La presencia del Project Manager en la elaboración de este documento es muy recomendada, puesto que es el documento que otorgará al Project Manager la autoridad necesaria para disponer de los recursos asignados al proyecto.
4.1.1 Técnicas y herramientas 4.1.1.1 Juicio de expertos (Expert judgement) El juicio de expertos es muy útil para poner en marcha este proceso. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia o que ha asistido a alguna formación especializada y que puede aportar muchas informaciones. Entre ellos, se incluyen los consultores, los integrantes del equipo del proyecto, algún proveedor especializado...
En todas las empresas en que he trabajado, me he encontrado con profesionales que tenían siempre mucho que aportar. No existe escuela que enseñe más que la experiencia, y por ello, disponer de la opinión de un profesional experimentado es un recurso imprescindible para tomar la decisión correcta.
4.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto)
I
DOC nº 001 - Acta de constitución del proyecto (Project charter)
124
4.2 Desarrollo del plan de proyecto (Proceso
que corresponde a la fase de planificación del proyecto)
Este proceso es el que define, prepara, integra y coordina todos los planes subsidiarios del proyecto (riesgos, calidad, alcance, costes...). Es quizás el documento más importante de un proyecto, puesto que contiene las estimaciones, los objetivos, las responsabilidades y todo lo que se refiere a la planificación del proyecto. Su elaboración progresiva y su actualización constante lo hacen imprescindible en la gestión de cualquier proyecto. El plan de proyecto es un documento formal y aprobado por la dirección y es utilizado principalmente para la administrar las fases, interacciones, actividades y toda la planificación de un proyecto. Las instrucciones de cómo confeccionarlo se encuentran en el Apéndice A, doc nº 003. El plan de proyecto, tiene fundamentalmente, los siguientes objetivos:
·
Organizar el proyecto: El plan de proyecto contiene una estructura que permite localizar fácilmente cualquier información, como el cronograma, el equipo asignado, sus funciones y responsabilidades, restricciones, entre otros.
·
Generar documentación: Como podremos observar en los capítulos siguientes, la gestión correcta de un proyecto implica en la confección de una serie de documentos que van siendo incorporados al plan de proyecto. Uno de los factores de éxito de un proyecto es la correcta confección y actualización de su documentación, que además servirá como una valiosa fuente de consulta histórica para futuros emprendimientos similares.
·
Proveer información: Un plan de proyecto es un documento que se actualiza en función del avance de los trabajos, ofreciendo a cualquier interesado, una visión exacta de todas las estimaciones realizadas y el estado actual en que se encuentran.
·
Gestionar las líneas base: Cuando se inicia un nuevo proyecto, se elaboran sus líneas base, que, normalmente, son de costes, plazos y de alcance. A partir de estas líneas base, se establecen todas las previsiones iniciales, con lo cual es fundamental que se encuentren actualizadas y que reflejen fundamentalmente el estado actual que el proyecto se encuentra.
4.2.1 Técnicas y herramientas 4.2.1.1 Metodología de planificación del proyecto (Project plan methodologies) Cualquier enfoque estructurado que permita guiar el equipo hacia un plan sostenible y eficaz es válido para el desarrollo del plan de proyecto. No importa si la metodología es sencilla, como la utilización de formularios o plantillas estándar, o compleja, como, por ejemplo, el uso de un software del Project Management integrado (descrito en la sección 6.3.1.4). Normalmente, una organización utiliza una serie de técnicas combinadas que les auxilia en la elaboración de un plan de proyecto eficiente, como las que son presentadas en este libro. 125
No obstante, uno de los recursos más valiosos que una organización puede tener es su “capital intelectual”. Los conocimientos y habilidades de los involucrados en el proyecto son cruciales para el buen desarrollo del plan de proyecto (ver sección a continuación).
4.2.1.2 Conocimientos y habilidades de los interesados (Stakeholder´s knowledge and habilities) Un plan de proyecto incluye una serie de estimaciones de costes y de plazos, además de un análisis de los riesgos del proyecto, entre muchas otras cosas. La confección de un plan de proyecto eficaz dependerá sobre todo de los conocimientos y habilidades de su equipo, de los patrocinadores o de cualquier persona que esté involucrada. El Project Manager debe proporcionar los medios para que los interesados puedan desarrollar y aportar las informaciones adecuadas.
4.2.1.3 Sistema de información de gestión de proyectos (Project management information system - PMIS) El Project Management information system (PMIS) es una herramienta utilizada en el Project Management para recoger, tratar y distribuir la información a través de medios electrónicos o manuales. Un ejemplo de PMIS es el Microsoft Project que ayuda a estar al día y controlar el trabajo, la programación y el presupuesto de los proyectos. Otro programa que se encaja en este ámbito, es el Microsoft Outlook que administra el tiempo, el calendario, los contactos y la información enviada y recibida por las personas involucradas en el proyecto.
4.2.1.4 Valor del trabajo realizado (Earned value management) Descrito en la sección 7.3.1.1
4.2.1.5 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
4.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I DOC nº 003 – Plan de proyecto (Project Management Plan) 126
4.3 Gestión y ejecución del plan de proyecto (Proceso que corresponde a la fase de ejecución del proyecto) Este es el proceso que pone en marcha todo lo definido en el plan de proyecto y que realiza la implantación de cualquier cambio resultante de acciones correctivas y/o preventivas. Este proceso incluye, además, los esfuerzos necesarios para alcanzar los resultados determinados por el plan de proyecto. La ejecución de un plan de proyecto eficaz conlleva al desarrollo de las siguientes actividades:
· · · · · · · · ·
Concluir con éxito las actividades que forman parte del proyecto. Alinear el equipo con los objetivos del proyecto. Gestionar el progreso de los trabajos. Incentivar la fluidez de la comunicación entre los involucrados. Desarrollar acciones preventivas. Utilizar técnicas y herramientas de gestión. Realizar reuniones periódicas. Identificar y monitorizar desvíos. Poner en marcha acciones correctivas, cuando sea necesario.
Estas son tareas típicas de la fase de ejecución y control, que es la fase en que el plan de proyecto es, de hecho, puesto en marcha.
4.3.1 Técnicas y herramientas 4.3.1.1 Habilidades de gestión en general (General management Hability) La responsabilidad final del Project Manager es asegurar la ejecución del proyecto dentro del plazo y de los costes estimados, garantizando la calidad de los servicios y productos entregados. Esto exige una administración eficaz de todas las disciplinas que hemos analizado en este libro: la comunicación, los recursos humanos, los contratos, el alcance, los riesgos, los costes, entre otros. Esta responsabilidad podrá variar en función de la complejidad del proyecto, del tipo de la organización que lo ejecuta, del interés del cliente, entre otros factores.
4.3.1.2 Conocimientos acerca del producto y/o servicio (Knowledge on the product and/or service) Como ya hemos comentado, unas de las características más importantes del Project Manager es la de líder. No obstante, para ejercer el liderazgo y defender su posición en momentos críticos del proyecto, el Project Manager tiene que ser capaz de hablar con los involucrados más importantes del proyecto (el cliente, el equipo, el patrocinador...) con mucha propiedad, y para ello, es imprescindible tener amplios conocimientos acerca del producto o servicio resultante del proyecto que se está desarrollando. 127
Conocer a fondo el servicio y/o producto que será generado, aportará al Project Manager, algunas ventajas importantes, como por ejemplo:
· · · · · ·
Selección de los proveedores más adecuados. Respuesta adecuada a los eventuales riesgos. Equilibrio entre costes, tiempo, alcance y calidad. Mejora en la comunicación entre los interesados. Reducción de la incertidumbre. Mejor control general en la ejecución del proyecto.
Para ello, es importante entender cómo el producto o servicio será desarrollado, su valor (comercial, estratégico...), sus funcionalidades, sus fortalezas y eventuales debilidades.
4.3.1.3 Sistema de autorización de trabajo (Work authorization system – WAS) El sistema de autorización de trabajo (conocido como Work authorization system - WAS en inglés), es un procedimiento que determina las acciones necesarias para autorizar u obtener la autorización de la ejecución de un determinado trabajo. Este procedimiento debe incluir también la documentación y los requisitos necesarios para ejecutar este tipo de gestión. Este documento es muy utilizado, además, para gestionar y mantener bajo control los trabajos que no formen parte del alcance previsto, evitando de esta forma, que se produzcan incidencias en los costes, plazos o consumo de recursos del proyecto. El sistema de autorización de trabajo funciona básicamente de la siguiente forma:
·
Uno de los integrantes del equipo del proyecto redacta un “Documento de autorización de trabajo” (Work authorization document – WAD, descrito en el Apéndice A doc nº 043). Este documento es enviado al Project Manager (o a las personas con autorización para aprobar este tipo de solicitud) donde se describe el trabajo (o el listado de trabajos) que necesitan ser ejecutados.
·
El Project Manager reenvía el WAD a los departamentos correspondientes para que se especifiquen las fechas hábiles, las duraciones, costes y recursos estimados para el desarrollo de los trabajos listados en el WAD.
·
El personal encargado realizará las eventuales comprobaciones que correspondan (sobre todo en lo que se refiere a las estimaciones generales de los trabajos) y devolverá el WAD al Project Manager con toda la información necesaria para que se juzgue su viabilidad.
·
Cuando el WAD haya sido aprobado y firmado por todas las partes involucradas, el Project Manager autorizará el inicio de los trabajos.
·
Este documento formará parte de todo el ciclo de vida del proyecto y su contenido podrá ser incrementado con nuevos trabajos, valores, plazos o cualquier cambio relevante que haya sido debidamente aprobado previamente.
128
4.3.1.4 Evaluación de progresión o reuniones de seguimiento (Follow-up meetings) Las reuniones de seguimiento tienen como principales objetivos verificar el avance de un proyecto, intercambiar informaciones y revisar las estimaciones, entre otras cosas. Es imprescindible incluir estas reuniones como una actividad del cronograma del proyecto, puesto que suelen consumir un tiempo considerable y deben tener una frecuencia regular, para proporcionar un seguimiento coherente al proyecto. En el capítulo 10, “Gestión de las Comunicaciones”, se amplía detalladamente la forma correcta de organizar una reunión de seguimiento.
4.3.1.5 Sistema de información de gestión de proyectos (Project Management information system - PMIS) Descrita en la sección 4.2.1.3.
4.3.1.6 Procedimientos de la organización (Organization procedures) Las organizaciones deben establecer procedimientos que les permitan desarrollar su trabajo obedeciendo una serie común de pasos claramente definidos, que posibiliten la ejecución de cada tarea correctamente, reduciendo la probabilidad de errores. Estos procedimientos pueden ser de índole técnica, administrativa u operacional, deben estar claramente definidos y no deben ser excesivos.
4.3.1.7 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
4.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I DOC nº 043 – Documento de autorización de trabajo (WAD - Work authorization document)
I DOC nº 045 – Actas de reunión del proyecto (Project meeting minutes) 129
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
4.4 Monitorización y control del trabajo del proyecto (Proceso que corresponde a la fase de control del proyecto) Este es el proceso en el que se puede notar una actuación intensiva por parte del Project Manager. Su labor incluye recolectar, medir y distribuir la información de rendimiento del proyecto, a la vez que elabora tendencias, ajusta métricas, mejora procesos y, sobre todo, trabaja para mantener el proyecto en su curso planificado.
4.4.1 Técnicas y herramientas 4.4.1.1 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
4.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 039 – Solicitud de cam bios (Change requests)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
4.5 Control integrado de cambios (Proceso que corresponde a la fase de control del proyecto) Este es el proceso donde se decide si un cambio solicitado podrá ser implementado o no, acorde con un procedimiento previamente establecido. Los cambios en un proyecto son inevitables y pueden ser solicitados por cualquier interesado del proyecto, impuesto por alguna ley o exigido por 130
factores relacionados con la competencia y/o el mercado. La implantación de un cambio es una gestión que se hace de forma planificada, valorando, sobre todo, su impacto y las posibles consecuencias. Nadie puede asumir que un proyecto será ejecutado sin que se produzcan cambios. Cualquier tipo de proyecto, durante su ciclo de vida, estará sujeto a modificaciones que podrán repercutir tanto en el alcance como en sus plazos y costes. En proyectos como los de la construcción, que suelen ser más estables, algunos cambios no llegan a afectar el desarrollo del proyecto. En proyectos más sensibles, como son los de informática, un único cambio, dependiendo de su dimensión, puede llevar todo el proyecto al fracaso. El desafío del Project Manager consiste en cómo manejar estos cambios, minimizando los eventuales impactos provocados. De los factores que normalmente generan cambios en un proyecto, podemos destacar:
· · · ·
Cambios en los requisitos del cliente. Aprobación de leyes o reglamentaciones. Nuevas tecnologías. Cambios en el entorno macroeconómico.
Aparte de estos factores externos, frecuentemente nos podemos encontrar con proyectos que son débilmente estructurados: el equipo tiene un plan, pero no lo organiza de forma adecuada y, conforme el proyecto avanza, algunos conceptos se van aclarando mejor y, como consecuencia, las especificaciones anteriormente realizadas tendrán que ser modificadas. Hay casos en que se hace necesario parar el trabajo y empezarlo otra vez. Proyectos desarrollados de esta forma suelen consumir mucho más recursos que los asignados originalmente y difícilmente son terminados. Por otro lado, aunque exista una planificación detallada, estructurada y bien organizada, el cambio puede ser inevitable. A medida que el proyecto avanza, se producen modificaciones, añadidos, observaciones que hacen que la especificación original cambie y produzca un impacto en el trabajo planificado. En algunos casos, los cambios son el reflejo de la madurez del personal involucrado que ha evolucionado en su forma de pensar y ha decidido de alguna manera mejorar aspectos antes ignorados que aportarán beneficios al proyecto sin perjudicar su línea base planificada.
4.5.1 Técnicas y herramientas 4.5.1.1 Sistema de control de cambios (Change control System) Casi todos los proyectos que son desarrollados sufren cambios por alguno motivo. Cuanto más largo y complejo sea un proyecto, mayor es la posibilidad de que sufra algún cambio. En casi todos los casos, los cambios en un proyecto son inevitables, y por ello es importante estar preparado para afrontar el momento de realizar las eventuales acciones correctivas, cuando estos cambios ocurran. De las situaciones más comunes de solicitud de cambios podemos destacar:
· ·
La aprobación de una nueva ley. Una petición inesperada por parte del cliente. 131
· · ·
Un cambio de tecnología. Un cambio de estrategia organizacional. Un error o una omisión en la línea base del alcance.
También podemos encontrar las siguientes situaciones:
·
El cliente solicita que se incluyan nuevos elementos al producto.
·
El líder técnico solicita que se incrementen los plazos de entrega de un determinado elemento.
·
Los técnicos solicitan la compra de nuevos equipos que no estaban previstos en el presupuesto original.
·
Una nueva ley puede frenar el desarrollo de un determinado componente.
·
La competencia puede desarrollar algún tipo de producto que nos obligue a cambiar nuestra estrategia.
Un proyecto es estructurado de forma integral y cualquier cambio en el proyecto podrá repercutir en su estructura principal o provocar un determinado impacto. Para evitar que se produzcan cambios en un proyecto de forma arbitraria y sin planificación, se utiliza un sistema de control de cambios que establecerá la forma como un determinado cambio en el proyecto será administrado. Los cambios solicitados deberán ser previamente analizados por una junta de expertos que se encargará de aprobar, rechazar o postergar las solicitudes de cambios. Esta junta de expertos normalmente está compuesta por líderes técnicos, consejeros y directivos que cuentan con la autoridad suficiente para aprobar o rechazar una solicitud de cambio. Las solicitudes de cambios se desarrollan a través de un procedimiento específico, según ilustra la figura 33. Las acciones deben estar respaldadas por una documentación que registre todo el proceso de solicitud de cambios.
132
Figura 33: Flujo de control de cambios del alcance
133
Solicitud de de cambios: Es el proceso que permite a cualquier interesado solicitar una petición de cambio en el proyecto. A priori, se identifican las necesidades de realizar un determinado cambio en el proyecto y a continuación se genera un documento formal de solicitud de cambios (change requests, descrito en el Apéndice A, doc nº 039), que será remitido al Project Manager.
Figura 34: Peticiones de cambio
Revisión de la solicitud de cambios: Esta acción es realizada por el Project Manager que encargará a una junta de expertos la realización de un estudio que determine la viabilidad de dicha petición. Es importante resaltar que, en algunos casos, el propio Project Manager tiene la autonomía para rechazar esta petición, antes mismo de enviársela a la junta de expertos. De hecho, este proceso sirve como una especie de “filtro”, puesto que en algunos proyectos producen una cantidad desproporcionada de peticiones que muchas veces son contraproducentes. Estudio de viabilidad: Cuando la petición de cambio ha pasado satisfactoriamente por la revisión del Project Manager, una junta de expertos realizará un estudio que determinará la viabilidad de cambio solicitado (descrito en la sección 4.5.1.2). Los criterios aceptación de un cambio normalmente pasan por las siguientes evaluaciones:
· · · · ·
Requisitos necesarios para la puesta en marcha de los cambios solicitados. Posibles alternativas. Costes y beneficios. Riesgos. Posibles impactos en los costes, plazos, recursos y calidad del proyecto.
Después de realizar las evaluaciones anteriormente citadas, el estudio de viabilidad culminará con una de las siguientes conclusiones:
·
Se podrá encajar el cambio solicitado sin afectar los recursos consumidos ni los plazos: Esta es la situación más sencilla y más optimista. Ocurre en los casos en que la junta de expertos analiza la petición de cambio y entiende que este cambio no será significativo lo suficiente para provocar cualquier impacto al proyecto.
·
Se podrá encajar el cambio solicitado, pero afectará el plazo final del proyecto: En este caso, el plazo de conclusión del proyecto será aplazado para poder encajar el cambio solicitado, sin necesidad de incrementar los recursos utilizados.
134
•
Se podrá encajar el cambio solicitado, sin cambiar el plazo, pero necesitará consumir más recursos: El proyecto necesitará de más recursos para poder realizar el cambio solicitado sin aplazar su plazo de finalización.
·
Se podrá encajar el cambio solicitado, pero afectará el plazo final del proyecto y necesitará consumir más recursos: Los recursos y plazos disponibles no serán suficientes para encajar el cambio solicitado. Los cambios solicitados empiezan provocar impactos significativos.
·
Se podrá encajar el cambio solicitado cambiando la estrategia del proyecto y priorizando las entregas más urgentes: Es muy frecuente que un proyecto sufra grandes cambios a lo largo de su ciclo de vida, que conllevan a modificaciones importantes en el plan, que exigirá una amplía revisión en la documentación del proyecto, de los plazos de entrega y del presupuesto.
·
No se podrá encajar el cambio solicitado sin realizar un cambio radical en el proyecto: Hay casos en que los cambios solicitados son tan drásticos que prácticamente anularía toda la planificación anteriormente realizada. El presupuesto, los plazos y los recursos estimados, todo tendría que ser totalmente revisado. En situaciones de esta magnitud la junta de expertos solo podrá optar por dos salidas:
a) Rechazar el cambio solicitado y seguir con el proyecto original (aceptando todos los riesgos implicados). b) Anular el proyecto en marcha, planificarlo otra vez y arrancar un proyecto nuevo con los cambios incluidos (asumiendo todos las consecuencias que está decisión podrá provocar). Finalmente, tras realizar todos los análisis necesarios para determinar la decisión más adecuada a la petición de cambio, la junta de expertos emitirá un informe de respuesta a la solicitud de cambios que podrá contener las siguientes conclusiones:
·
Rechazar la petición de cambio: Son muchas las razones por las que la junta de expertos podría rechazar una petición de cambio, como, por ejemplo, que los cambios solicitados puedan provocar un impacto importante que no generaría beneficios que justifiquen dicho cambio o que el cambio solicitado no añadiría ningún valor al proyecto o, asimismo, que los costes generados por dicho cambio podrán ser muy altos.
·
Solicitar más información: Es posible que la junta de expertos no sea capaz de llegar a una conclusión, por la escasez de información remitida por la persona que ha solicitado el cambio. En este caso, la junta solicitará más datos para que se pueda realizar una investigación adecuada.
·
Aprobar la petición de cambios: Si el cambio solicitado cumple con los requisitos determinados por la junta de dirección, esta procederá con la aprobación formal de esta solicitud.
·
Aprobar la petición de cambio con restricciones: Hay casos en que la junta de expertos aprueba la petición de cambio, pero impone algunas restricciones. En este caso, el solicitante evaluará si los cambios propuestos podrán ser puestos en marcha bajo las 135
restricciones impuestas por la Junta de Expertos.
136
Los criterios de aprobación o rechazo de una determinada solicitud de cambios normalmente tendrán en cuenta los siguientes criterios:
·
Posibles impactos en el proyecto, derivados de la implantación de los cambios propuestos.
·
Posibles impactos en el proyecto, derivados de la no implantación de los cambios propuestos.
Implantación: Consiste en implantar los cambios aprobados y autorizados por la junta de expertos. El Project Manager, entonces, remitirá al solicitante la autorización para la realización de los cambios, y realizará las siguientes gestiones:
· · · ·
Comunicar a todos los involucrados del proyecto los cambios que serán realizados. Planificar la forma como los cambios serán implantados. Realizar la Implantación de los cambios previstos. Actualizar la documentación correspondiente.
Una buena gestión de cambios de un proyecto empieza en la línea base que debe ser establecida en el principio del proyecto, sobre todo porque la peticiones de cambios que vayan siendo aprobadas modificarán su estructura de modo que se quedará muy distinta a la línea base original. Sin embargo, la organización contará con importantes registros de los cambios solicitados, aceptados y rechazados que servirán de referencia en proyectos futuros similares. Además, con la línea base siempre actualizada, será posible evaluar el impacto real de los cambios solicitados. Es importante que el Project Manager tenga el cuidado de preservar las líneas bases originales de alcance, costes y plazos para poder realizar comparativas entre las primeras líneas bases estimadas y las líneas base realizadas.
Figura 35: Proyecto realizado con pocos cambios en el alcance
137
Figura 36: Proyecto realizado con muchos cambios en el alcance
En los contratos confeccionados para el proyecto, es muy recomendable que se establezcan claramente quienes son las personas que tienen autoridad para iniciar y aceptar los cambios. La implementación de cambios no autorizados es frecuentemente la causa de muchas disputas, por ello, todo cambio solicitado solamente debe ser aceptado o rechazado por la(s) persona(s) autorizada(s) según establecido en una cláusula contractual correspondiente. Se trata de una medida preventiva que evitará una eventual pérdida de control sobre el proyecto debido a la implementación de cambios no autorizados. Algunos de los cambios aceptados deberán ser incorporados de manera formal al contrato, puesto que podrán provocar modificaciones importantes en los planes de gestión del proyecto, políticas, procedimientos, costes o cronogramas. Por otro lado, pueden existir los cambios impugnados (reclamaciones, conflictos, apelaciones, etc.), que son aquellos cambios solicitados respecto de los cuales el adquiridor y el proveedor no logran acordar la compensación correspondiente debido a los mismos. Estos cambios son documentados, procesados y gestionados a lo largo del ciclo de vida del contrato, obedeciendo los términos contractuales acordados.
138
4.5.1.2 Estudio de viabilidad (Feasibility study) Como su propio nombre indica, el estudio de viabilidad es una forma de determinar si un determinado cambio es viable. Se trata de una herramienta que nos ayudará a contestar una pregunta muy frecuente en el entorno empresarial: “¿Podemos seguir por este camino?”. El estudio de viabilidad es algo imprescindible y que debe ser realizado antes de poner en marcha un cambio. Sus resultados podrán ahorrarnos dinero y tiempo, además de prevenirnos de eventuales riesgos que quizás no serían correctamente identificados al no realizarse este tipo de estudio. Un estudio de viabilidad completo deberá realizar el análisis de los siguientes apartados:
·
Viabilidad técnica o tecnológica: A través de un análisis de las alternativas tecnológicas disponibles para el proyecto, se determinan los requisitos y dificultades de implantación. Además, el estudio de la viabilidad técnica determinará si la empresa y su plantilla cuentan con la experiencia y el conocimiento suficientes para su desarrollo, y si los equipos disponibles pueden soportar los requisitos técnicos necesarios.
·
Viabilidad financiera: El análisis financiero es uno de los estudios que se realizan con más frecuencia, ya que suele ser uno de los factores que determinan la aprobación de un cambio. Este estudio analizará la capacidad de la empresa en asumir los costes generados, si el cambio incrementará la receta de la empresa y consecuentemente, impactará positivamente en sus ganancias.
·
Viabilidad legal: Determina si el cambio puede llegar a tener algún conflicto con la legislación vigente, como por ejemplo, alguna normativa medioambiental.
·
Viabilidad operacional: Determinará si la empresa posee las condiciones necesarias o cuenta con los recursos apropiados para realizar un cambio.
·
Viabilidad de plazos: Determina si el cambio podrá ser realizado dentro de un plazo viable.
·
Viabilidad de mercado: Determinará si el cambio tiene salida comercial y si existe un mercado consumidor.
·
Viabilidad de recursos: Este apartado contempla cuestiones acerca de la capacidad de la empresa de desarrollar el cambio propuesto en función de su plantilla, instalaciones, equipos, entre otros.
139
4.5.1.3 Gestión de la configuración (Configuration management) Esta técnica es muy utilizada en entornos de desarrollo de software, debido, básicamente, a la inestabilidad que este tipo de proyecto conlleva. En el ámbito del desarrollo de software es un hecho común que los requisitos inicialmente establecidos cambien a medida que el proyecto evoluciona, muchas veces provocando errores que generan múltiples versiones del código fuente del programa. Por todo ello, la gestión de la configuración es una técnica muy oportuna, puesto que permite llevar un correcto control de los cambios producidos a lo largo de la evolución del proyecto, manteniendo de esta forma, la integridad del producto, desde la fase de requisitos hasta alcanzar la fase final de pruebas, asegurando sobre todo:
·
La validez de todo producto obtenido durante cualquiera de sus fases de desarrollo.
·
La producción de cambios controlados.
·
La disponibilidad de una versión única y estable para todos los involucrados que la manejan.
Esta gestión, además, facilita el mantenimiento del sistema, aportando la información adecuada que permitirá realizar una valoración del impacto de un cambio solicitado, reduciendo de esta forma, el tiempo de implantación de dicho cambio. Una adecuada gestión de la configuración puede además, hacer un control global del sistema, aportar informaciones acerca del estado de su desarrollo y reducir el número de errores que puedan llegar a producirse, generando un sistema estable, fiable y acorde con los requisitos del cliente. Según la gestión de la configuración definida en MÉTRICA v3, los elementos de configuración del software incluyen:
· · · · · ·
Ejecutables. Código fuente. Modelos de datos. Modelos de procesos. Especificaciones de requisitos. Pruebas.
Y para cada uno de estos elementos se almacenará al menos:
· · · ·
Nombre. Versión. Estado. Localización.
140
MÉTRICA es una metodología de planificación, desarrollo y mantenimiento de sistema de TI promovida por el Ministerio de Administraciones Públicas del Gobierno de España para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas. Esta metodología propia está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC 12207 (Information Technology - Software Life Cycle Processes) así como en la norma ISO/I EC 15504 SPICE (Software Process Improvement And Assurance Standards Capability Determination).
4.5.1.4 Informes de progreso (Progress report) Los informes de progreso pueden ser muy útiles para realizar un control efectivo de los costes del proyecto, y, además, se trata de una forma muy sencilla de hacerlo. En muchos casos, el Project Manager determina cuánto trabajo ha sido realizado, solicitando a su equipo un porcentaje estimado del trabajo realizado en cada actividad. No obstante, en muchos casos, el equipo no tiene claro un criterio que determine realmente el porcentaje de avance de una determinada actividad, como por ejemplo decir que “en la actividad 5.4.2 está casi un 90%”. Este porcentaje no pasa de un sencillo “pálpito”, que poco o nada podrá aportar al control de costes del proyecto. De hecho, en muchos casos, encontramos actividades que han alcanzado rápidamente el 90% del trabajo realizado y luego se quedan en este procentaje para siempre. Es importante dividir todo el trabajo en paquetes de menor duración, como establece la EDT (descrita en la sección 5.3). De esta forma, trabajando con cortos plazos de finalización de estos paquetes, la estimación del trabajo realizado se vuelve más sencilla. Por otro lado, existe una forma muy práctica de reportar el avance de un proyecto, sin recurrir a intuiciones sin fundamento. Se puede determinar con más exactitud, el avance de una determinada actividad a través de dos reglas diferentes: REGLA 50/50: La actividad obtiene un 50% de crédito cuando se inicia el trabajo, y el restante 50% se obtiene al finalizarlo.
141
Figura 37: Regla 50/50
REGLA 0/1 00: Una actividad es considerada 100% realizada cuando esté formalmente finalizada.
Figura 38: Regla 0/1 00
La principal ventaja de aplicar esta regla del 50/50, o la del 0/100, es que elimina la necesidad de determinar el porcentaje completado, que en la gran mayoría de las veces será un porcentaje equivocado.
4.5.1.5 Sistema de información de gestión de proyectos (Project management information system - PMIS) Descrita en la sección 4.2.1.3.
4.5.1.6 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
4.5.1.7 Reunión de control de cambios (Change control meetings) La reunión de control de cambios ocurre siempre que se produce una petición de cambio en un proyecto. Su objetivo es realizar un estudio acerca de una petición de cambio, sus consecuencias e impactos en el proyecto. Una junta de expertos se encargará de aprobar o rechazar los cambios solicitados y, además, generará un informe con sus conclusiones. Esta reunión forma parte del sistema de control de cambios (descrita en la sección 4.5.1.1).
4.5.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)
I DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
I DOC nº 046 – Plan de acciones correctivas (Corrective action plan)
I DOC nº 054 – Lecciones aprendidas (Lessons learned)
I DOC nº 039 – Solicitud de cam bios (Change requests)
144
I Actualizaciones al estado de las solicitudes de cambio (Change requests status updates) - Las que correspondan al proceso
145
4.6 Cierre del proyecto o fase (Proceso que corresponde a la fase de cierre del proyecto) En un proyecto, es importante que todo esté debidamente documentado. La documentación es una forma que el Project Manager tiene de controlar su avance, los cambios implementados y cualquier incidencia o información relevante. Cuando se termina el proyecto o una de sus fases, el Project Manager deberá realizar una revisión general de todos los cierres de fases anteriores, asegurando de esta forma el correcto cumplimiento de los objetivos definidos. Cualquiera sea la razón por la cual un proyecto se haya finalizado, su cierre debe pasar por un proceso formal.
4.6.1 Técnicas y herramientas 4.6.6.1 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
4.6.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I Actualizaciones a los activos de los procesos de la organización (Organizational process assets update) - Las que correspondan al proceso.
146
Capítulo 5 Gestión del alcance “No tiene sentido decir que lo hacemos lo mejor que podemos. Tenemos que lograr hacer lo que es necesario” Winston Churchill 20 , estadista, historiador, escritor y orador británico
147
Algunas cosas en las que NO puedes pensar acerca de la gestión del alcance “¿Por qué no aprovechamos y le añadimos al cliente unas funciones extra al producto? ¡Seguro que le va a encantar!” Al principio, lo que suena como algo muy positivo podrá provocar un gran dolor de cabeza. Añadir más elementos sin que el cliente los hubiera solicitado podría significar un importante incremento de riesgo en el proyecto, que consecuentemente se traduciría en retrasos en los plazos establecidos. Si ocurre alguna incidencia en este sentido, lo primero que el cliente dirá es que los problemas empezaron a partir del momento que el Project Manager decidió añadir elementos al producto que no figuraban en los requisitos originales. Al cliente se le debe entregar solamente lo solicitado, ni más ni menos. Añadir “extras” es una pérdida de tiempo que no aportará ningún beneficio al proyecto.
“Olvídense de los requisitos del cliente. Nosotros sabemos lo que hacemos” Los requisitos funcionan básicamente como el hilo conductor de un proyecto y reflejan exactamente las necesidades y expectativas del cliente. La correcta captura y entendimiento de dichos requisitos permitirá, entre otras cosas, gestionar las necesidades del proyecto de forma estructurada, mejorar la capacidad de predecir costes, plazos y riesgos, adoptar las acciones preventivas adecuadas y sobre todo asegurar a aceptación final del cliente. “El alcance completo lo definimos en una fase más avanzada” No todos los proyectos pueden tener su alcance definido durante su fase inicial. Es un reto muy difícil de alcanzar, sobre todo en proyectos innovadores, como son los de desarrollo de software, diseño de un nuevo móvil, por ejemplo. Cuando es posible disponer de toda la información para definir el alcance completo en la fase inicial del proyecto, lo ideal es definirlo sobre la marcha, a través de metodologías de planificación gradual, mitigando de esta forma los riesgos implicados.
Introducción El alcance del proyecto es el trabajo que debe realizarse para entregar un producto con las características y funciones específicas, o como define el PMBOK® de forma muy acertada, la gestión del alcance debe “incluir los procesos requeridos para asegurar que el proyecto incluya todo el trabajo necesario, y solamente el trabajo necesario, para completar el proyecto con éxito”. En otras palabras:
·
Verificar constantemente que las tareas asignadas al proyecto están siendo completadas de acuerdo con el plan.
·
Rechazar cualquier actividad adicional no prevista en el proyecto o que no forme parte de la EDT.
·
Evitar a todo coste el “gold plating” (entregar más cosas que las el cliente ha solicitado). 148
La correcta gestión del alcance es imprescindible, pues a partir de ella se desarrollarán las estimaciones de plazo, costes y recursos. Una de las razones por la cual un proyecto falla, es porque su alcance ha sido mal definido. Son varias las razones que comprometen el alcance del proyecto. Una de las razones más comunes es que muchas veces el cliente tiene una idea supervalorada del proyecto, es decir, el cliente cree que el proyecto irá generar algo espectacular. Además, en las primeras reuniones con el equipo, normalmente el cliente tiene la sensación que el equipo tiene el proyecto totalmente claro en la mente, con lo cual no es imprescindible planificar el alcance. Es un raciocinio equivocado que inevitablemente irá provocar serios problemas más tarde. Además, existen casos en que un Project Manager no tiene la costumbre de desarrollar una EDT (véase también 5.3), que es una herramienta clave en la gestión del alcance. Bajo el enfoque de la cuarta edición del PMBOK®, la Gestión del Alcance de un proyecto incluye los procesos y actividades necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarlo con éxito. Incluye los siguientes procesos:
· · · · ·
Recopilar requisitos. Definir el alcance. Crear la EDT. Verifi car el alcance. Controlar el alcance.
5.1 Recopilar requisitos (Proceso que corresponde a la fase de planificación del proyecto) La recopilación de requisitos es el proceso que documenta las necesidades de los interesados y que define los objetivos del proyecto. Uno de los factores de suceso de un proyecto depende del cuidado que se tenga en obtener correctamente los requisitos de un cliente y él saber gestionarlos adecuadamente. Se puede decir que los requisitos son “los intereses documentados del cliente”. Allí residen sus expectativas, ilusiones y deseos que en algunos casos pueden ser muy subjetivos o mal aclarados, y por ello es fundamental su completa documentación. Los requisitos además, constituyen la base de la EDT (véase también sección 5.3) y son el marco de planificación de costes, plazos y recursos.
A veces el cliente no sabe lo que quiere Una reunión de recopilación de requisitos tiene como objetivo desarrollar una documentación completa que permita al equipo del proyecto el pleno entendimiento de todo el trabajo que deberá ser ejecutado para cumplir las expectativas del cliente. El problema reside cuando es el propio cliente el que no tiene claro lo que necesita, puesto que muchas veces viene influenciado o amparado por “ideas” mal fundamentadas y con escasa información. 149
Al no tener clara la definición de requisitos, cualquier intento de desarrollo de sus exigencias será una total pérdida de tiempo y dinero. Es fundamental que el cliente tenga claro sus requisitos de forma que permita al equipo del proyecto comprehender cada parámetro que conducirá el objetivo final que el proyecto pretende alcanzar. No obstante, es importante tener en cuenta que el cliente muchas veces no es un experto y por ello no tendrá plenas condiciones de proporcionar la información necesaria para establecer claramente los requisitos del proyecto. Por todo ello, la comunicación es un factor clave en la recopilación de requisitos. Es fundamental que cliente sepa exponer exactamente lo que desea y el equipo de proyecto debe entender claramente sus necesidades. Si un cliente no es un experto, debería contar con profesionales que pudiesen aportarle las aclaraciones que necesita para cumplir con sus necesidades. En caso contrario, hay que intentar guiarle y lograr que entienda exactamente lo que necesita y cuál es el resultado final esperado.
(1) Cómo el cliente lo explicó, (2) cómo el líder del proyecto lo ha entendido, (3) cómo el analista lo diseñó, (4) forma en que el programador lo escribió, (5) forma en que el consultor de negocios lo describió, (6) cómo el proyecto fue documentado, (7) qué el departamento de operaciones ha instalado, (8) cómo se le factura al cliente, (9) la forma en la que recibe soporte, (10) lo que el cliente realmente quería. Figura 39: Requisitos del cliente. Si el cliente no es capaz de expresar claramente sus necesidades o si el equipo de proyecto no logra comprenderlas correctamente, el resultado final de un proyecto podrá convertirse en un auténtico desastre.
150
5.1.1 Técnicas y herramientas 5.1.1.1 Entrevistas (Interviews) La entrevista es una técnica que consiste en reunir a una o más personas, especialistas en una determinada materia, con el objetivo de recopilar datos que puedan ser útiles a alguna cuestión relacionada con un proyecto. Tiene una gran importancia en el proceso de recopilación de requisitos, puesto que permite obtener determinadas conclusiones sobre lo que se está investigando.
Ventajas:
·
Es una técnica sencilla, de bajo coste y muy flexible que permite obtener datos relevantes.
·
La información recopilada es muy superior a la obtenida cuando está limitada a la lectura de una respuesta escrita.
·
Se pueden captar los gestos, tonos de voz, énfasis..., que aportan una importante información sobre el tema y sobre todo sobre las personas entrevistadas.
No obstante, la principal ventaja de la entrevista reside en la capacidad que esta técnica tiene de poder extraer directamente del entrevistado sus verdaderas sensaciones, expectativas, puntos de vistas, opiniones y deseos, que serían muy difíciles de obtener a través de otro medio menos directo.
Desventajas:
·
Si el entrevistador no logra producir una pauta adecuada, no será posible extraer del entrevistado la información que se necesita.
·
Puede haber por parte del entrevistado, un cierto desinterés en responder las preguntas propuestas. También hay casos de personas que se inhiben ante un entrevistador, y por ello, les cuesta responder con seguridad.
·
Es común encontrarse con interlocutores que mienten, deforman o exageran en sus respuestas, perjudicando de esta forma la calidad de los resultados esperados.
De acuerdo con el objetivo que se pretenda alcanzar, se puede desarrollar una entrevista estándar, que planteará a los entrevistados exactamente las mismas preguntas y en el mismo orden. Como principal desventaja, este tipo de entrevista no permite expresar la opinión del entrevistador. Sin embargo, sus resultados son muy fáciles de procesar, simplificando el proceso comparativo. Por otro lado, existen las entrevistas “no estructuradas”, que se caracterizan por su flexibilidad, aunque se rige a su objetivo principal. Su principal ventaja es la capacidad de 151
adaptación acorde con el entrevistado o la situación, permitiendo además profundizar sus reflexiones.
152
Como desventajas, requiere una inversión importante de tiempo y los resultados obtenidos no más difíciles de tabular.
5.1.1.2 Grupos de opinión (Focus groups) Esta técnica consiste en reunir un determinado grupo de personas para discutir un asunto específico de carácter técnico, comercial, político, organizacional, entre otros aspectos. En el caso de la recopilación de requisitos, podemos, por ejemplo, imaginar que el grupo esté formado por potenciales clientes de un producto y/o servicio. Es similar a la lluvia de ideas (brainstorming, véase también sección 11.2.1.8), pero tiene un matiz fundamental que de mantener el grupo constantemente enfocado en una determinada cuestión. Con un moderador encargado de hacer las preguntas y dirigir la discusión, su objetivo es coordinar el grupo para que esté debidamente enfocado y no se distancie del tema de estudio, por ello viene el nombre en inglés: “focus group”. Toda la dinámica de la reunión está pensada para que los participantes se sientan cómodos y a gusto para poder expresar sinceramente sus opiniones y sugerencias. En el mundo del marketing, este tipo de reuniones son consideradas una herramienta fundamental para extraer los deseos y necesidades de un determinado grupo de clientes y/o consumidores. Las informaciones generadas son de extremo valor para la creación de los requisitos que compondrán un futuro servicio o producto. Para que las secciones de grupos de opinión sean exitosas, es importante cumplir con algunos requisitos:
·
Impedir que el grupo pierda el foco central de la sección y pierda tiempo en asuntos de poca trascendencia.
·
Elaborar un guión de desarrollo que servirá para iniciar y cerrar la discusión.
·
Limitar la participación y la duración de la reunión (no deberían sobrepasar las dos horas).
·
Es habitual que algunos participantes se dejen llevar por la presión del grupo, cambiando su opinión, lo que produciría una cierta “contaminación” en los resultados. Es importante que el moderador esté bien entrenado para saber manejar adecuadamente el grupo.
5.1.1.3 Talleres facilitados (Facilitated workshops) Muchos proyectos sufren cambios importantes en su alcance, principalmente porque la recopilación de sus requisitos no ha sido correctamente realizada. Frecuentemente, nos encontramos con requisitos provenientes de resultados cruzados, mal documentados y muchas veces recopilados de personas que no tienen claro los objetivos del proyecto. La obtención de requisitos fiables depende de la puesta en marcha de un ambiente controlado y con la participación de las personas adecuadas. Y esto se puede conseguir, a través de talleres facilitados. 153
Los talleres facilitados son secciones en donde se reúnen los interesados del proyecto para definir los requisitos de un producto o servicio. Para que estas secciones proporcionen una información fiable, es fundamental que los interesados que formen parte de estas reuniones, conozcan el sector afectado y tengan experiencia en proyectos anteriores similares. Este grupo emitirá una opinión fundamentada en un análisis de los objetivos del proyecto, las necesidades y expectativas del cliente, el entorno de su negocio, etcétera. Uno de los talleres facilitados más conocidos en la industria del software es el JAD (joint applicaion development - desarrollo conjunto de aplicaciones). Su filosofía cumple con la idea básica de los talleres facilitados*:
La gente que hace un trabajo tiene la mejor comprensión de ese trabajo. ·
La gente entrenada en tecnologías de la información tiene la mejor comprensión de las posibilidades de esas tecnologías.
·
Los sistemas de información y los procesos del negocio raramente existen en forma aislada - Más bien trascienden los límites de cualquier sistema u oficina y afectan el trabajo en departamentos relacionados. La gente que trabaja en estas áreas relacionadas tiene una percepción valiosa del papel del sistema dentro de una comunidad más amplia.
·
Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan juntos en un proyecto como socios iguales.
* Fuente: Wikipedia. Los talleres facilitados pueden generar los requisitos exactos que el proyecto necesita, además de proporcionar mejor las metas comunes del proyecto y el fortalecimiento del grupo involucrado en su desarrollo.
5.1.1.4 Técnicas de creatividad en grupo (Group creativity techniques) Una de las habilidades más impresionantes del ser humano es la creatividad, que, sin lugar a dudas, ha sido una de las bases fundamentales para el avance del hombre en el campo de las artes, la arquitectura, la ingeniería, la informática y los negocios en general. Acorde con Diane E. Papalia 21 en su libro Psicología del desarroio, la creatividad consiste en la habilidad de ver las cosas bajo una nueva perspectiva e inventar luego soluciones nuevas, originales y eficaces. Existirían por lo tanto dos tipos de pensamiento que se relacionarían con la resolución de problemas y la creatividad:
·
El pensamiento divergente, que es la capacidad para descubrir respuestas nuevas y originales.
·
El pensamiento convergente, que lo define como la capacidad para descubrir una única respuesta correcta.
154
Estos pensamientos estarían también altamente relacionados con la motivación, los conocimientos previos, el aprendizaje, la independencia de carácter y la determinación. Todos estos conceptos se encajan perfectamente en uno de los aspectos más recalcados en este libro: un proyecto de éxito depende sobre todo de reunir las personas ciertas, en el momento oportuno, con los conocimientos adecuados y, según lo que establece lo anterior, con capacidad de descubrir soluciones nuevas y originales. Son muchas las técnicas para fomentar y motivar la imaginación de las personas, algunas de ellas se encuentran ampliamente explicadas en este libro, las podrá encontrar en los puntos a continuación:
·
Lluvia de ideas (Brainstorming): Descrita en la sección 11.2.1.8.
·
Técnica de grupo nominal (Nominal group technique): Descrita en la sección 11.2.1.9.
·
Técnica delphi (Delphi technique): Descrita en la sección 6.4.1.7.
·
Técnica crawford slip (Crawford´s slip writing method): Descrita en la sección 11.2.1.11.
·
Mapa conceptual (Concept map): Descrita en la sección 11.2.1.13.
·
Diagrama de afinidad (Affinity diagram): Descrita en la sección 11.2.1.14.
5.1.1.5 Técnicas de toma de decisión en grupo (Group decision making) La tomas de decisión en grupo es un proceso que reúne a un grupo de personas con el objetivo de tomar, de forma conjunta, la mejor decisión posible frente a una determinada situación. Algunos de los métodos más utilizados para llegar a una decisión en grupo son:
·
Unanimidad: Ocurre cuanto todos los participantes están de acuerdo en poner en marcha una única línea de acción.
·
Mayoría: La decisión elegida cuenta con el apoyo de por lo menos 51% de los miembros del grupo.
·
Pluralidad: El bloque más grande de todo el grupo de participantes toma la decisión, aunque no se alcance la mayoría.
·
Dictadura: Cuando una persona decide el curso de la acción, sin considerar la posición de los demás.
155
5.1.1.6 Cuestionarios y encuestas (Questionnaries and surveys) Las encuestas pueden ser útiles en la recopilación de requisitos, y como dicho anteriormente, siempre y cuando los encuestados sean profesionales del sector con experiencia y provistos de conocimientos que aporten calidad a los resultados de la encuesta. Estos resultados se obtienen a partir de un conjunto de preguntas dirigidas a una muestra representativa o al conjunto total de de una población estadística en estudio, formada por profesionales, empresas o entes institucionales y con el objetivo, en nuestro caso, de recopilar los requisitos necesarios para desarrollar un determinado producto y/o servicio. La encuesta tiene la ventaja de ser una acción de bajo coste y que suele recopilar la información exacta. No obstante, la calidad de los resultados obtenidos dependerá fundamentalmente de dos factores: de la selección de las preguntas correctas y de la elección de los encuestados adecuados.
5.1.1.7 Observaciones (Job shadowing) Ampliamente utilizada en las escuelas secundarias americanas, es conocida como Job Shadowing, esta técnica trata de introducir a jóvenes estudiantes en ambientes reales de trabajo (oficinas, talleres, bufetes, entre otros), donde podrán observar en primera persona, como trabajan los profesionales en sus áreas de actuación y hacerles preguntas acerca de su trabajo. Esta experiencia les aportará la información que necesitan para conocer mejor determinadas profesiones y ayudarles a decidir acerca de su futuro profesional. En el campo del Project Management, esta técnica es utilizada para observar de forma directa como un profesional realiza su trabajo y ejecuta sus procesos, de esta forma, el observador podrá constatar cómo se hace el trabajo y descubrir determinados requisitos desconocidos. Son extremadamente útiles para procesos detallados, cuando las personas tienen dificultades en detectar sus propias necesidades o no tienen claro cómo pueden mejorar sus proceso de trabajo.
5.1.1.8 Prototipos (Prototypes) Un prototipo es básicamente un modelo operativo que contiene todas las características funcionales del producto que se pretende fabricar y es utilizado para hacer simulaciones y probar sus debilidades y fortalezas. Dado que es tangible, el prototipo permite hacer experimentos muy próximos a lo que llegaría a ser el producto final, en lugar de sóoo debatir de forma abstracta sobre sus requisitos. 156
5.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 004 – Documentación de requisitos (Requirements documentation)
I
DOC nº 005 – Plan de gestión de requisitos (Requirements management plan)
I
DOC nº 006 – Matriz de rastreabilidad de requisitos (Requerimiens traceability matrix)
5.2 La definición del alcance
(Proceso que corresponde a la fase de planificación del proyecto) Esta fase normalmente es plagada por el entusiasmo general. Existe una sensación de que todo puede ser hecho y que el proyecto será desarrollado sin incidencias. Es una sensación un poco peligrosa, pues conllevará a confeccionar un alcance muy complejo con más artículos de los que realmente el producto o el servicio necesitan para cumplir su objetivo, que además de innecesarios, no interesarán al cliente. Cualquier problema que surja a raíz de ellos, conllevará a pérdidas importantes de tiempo y recursos. Para impedir que esto ocurra, es importante reunir el equipo del proyecto y a los principales interesados para hacer una lista de los artículos que deben salir del primer borrador del alcance. Una vez realizado este filtro, llegaremos a lo que llamamos de “listado de requisitos”, que formará parte del plan de gestión de requisitos (véase también Apéndice A, doc nº 005) Este listado contendrá todos los elementos que el equipo y los interesados juzguen importantes para el proyecto. Si posible, es recomendable realizar una segunda ronda de verificaciones para comprobar si el listado de requisitos disponible hasta el momento, puede ser aún más reducido. Para asegurarse de que todos los artículos que están en este listado son realmente necesarios, es prudente que se desarrollen justificativas razonables para seguir manteniéndolos. Los artículos eliminados durante las secciones de verificación, no serán olvidados. Es recomendable documentar estos artículos en una “lista de requisitos excluidos”, que también formará parte del plan de gestión de requisitos (véase también Apéndice A, doc nº 005). Si no se documentan los artículos descartados en una lista de exclusión, estos volverán una y otra vez, siempre que se realice el proceso de definición del alcance. Una vez completada el listado de requisitos, el Project Manager podrá definir con su equipo, cuáles serán los entregables (deliverables) del proyecto. Un entregable, de acuerdo con el PMBOK® es “todo producto, resultado o elemento mensurable, tangible y verificable que deba entregarse para finalizar un proyecto, o parte de un proyecto”. Estos entregables deben ser formalmente aprobados por los interesados del proyecto, sobre todo por el cliente y los patrocinadores. No puede haber dudas que estos entregables, resultado de todos los filtros realizados en gestiones de definición del alcance, son los entregables definitivos del proyecto.
157
Además es importante definir los resultados que cada entregable debe atingir y cuáles serán los criterios de aceptación. Estos cuidados iníciales evitarán que el alcance sea modificado durante el desarrollo del proyecto. El cambio de alcance es un factor crítico que, al ser cambiado, puede producir impactos negativos. Un alcance bien definido no debería sufrir ningún tipo de replanificacion posterior.
Figura 40: Acciones resultantes de los cambios en el alcance Realizadas todas las verificaciones pertinentes, será posible desarrollar los “paquetes de trabajo”. Estos paquetes, son las actividades necesarias para llevar a cabo la producción de un entregable. Para ello, usaremos una herramienta llamada estructura detallada del trabajo - EDT” o, WBS, su sigla en inglés. (Véase también la sección 5.3).
5.2.1 Técnicas y herramientas 5.2.1.1 Requisitos del proyecto (Project requirements)
Descrito en el documento nº 004 del Apéndice A.
5.2.1.2 Enunciación del alcance del proyecto (Project scope statement)
Descrito en el documento nº 007 del Apéndice A.
158
5.2.1.3 Planificación gradual (Rolling wave project planning – RWPP) La planificación gradual (Rolling Wave Project Planning – RWPP) es una técnica muy utilizada en proyectos que poseen un grado muy alto de incertidumbre, donde no se puede planear mucho más adelante, como pueden ser los proyectos de desarrollo de software. Una situación muy frecuente que nos encontramos es la de tener que empezar inmediatamente un proyecto, sin que este cuente con un alcance totalmente definido y no disponga de toda la información necesaria para planificar todo el proyecto. Esta técnica tiene un concepto extremadamente sencillo: se planifica hasta donde se pueda, es decir, hasta donde se tiene visibilidad o hasta donde la información obtenida en las fases anteriores nos permita llegar. Se va ejecutando lo planificado y a medida que el proyecto avanza y se recopila más información, se retoma la planificación de las siguientes fases. Para ello, el proceso más coherente es partir de una EDT (descrita en la sección 5.3) que contemple todas las fases y objetivos del proyecto. Se detallan entonces, las actividades de la primera fase, y conforme avanza el proyecto, se recopila más información. Al finalizar esta primera fase, las informaciones y conocimientos adquiridos serán utilizados en la EDT para planificar las actividades de la siguiente fase, en un ciclo que se mantiene hasta concluir el proyecto. Este procedimiento permite ejecutar el proyecto planificando la fase siguiente sobre la marcha. De todas formas, esta herramienta solo funcionará correctamente si el equipo y los interesados hayan establecido y reconocido previamente las fechas inicio y fin de la fase de cada una de las fases del proyecto.
Figura 41: Estimaciones basadas en desarrollo gradual
5.2.1.4 Descomposición (Decomposition) Utilizando la técnica de la descomposición, se hace la definición del alcance sobre cada componente en que descompone el proyecto o sobre las tareas de bajo nivel en que se descomponen otras tareas. Las definiciones de bajo nivel se combinan para producir la definición de cada actividad, y consecuentemente, de cada fase, hasta llegar al proyecto completo.
159
La forma más conocida y más utilizada para hacer la descomposición del alcance de un proyecto es la técnica de la estructura detallada del proyecto – EDT (Work Breakdown Structure – WBS), descrita en la sección 5.3.
5.2.1.5 Juicio de expertos (Expert judgement)
Descrito en la sección 4.1.1.1
5.2.1.6 Análisis del producto (Product analysis) El análisis del producto es una herramienta que tiene como objetivo conocer en profundidad todas las características generales de un producto, y con ello buscar mejorar la calidad de su desarrollo y fabricación. Es un análisis que se realiza a través de distintas etapas, cada una de ellas tratando de conocer los diferentes entornos de un mismo producto. El análisis del producto se desarrolla de la siguiente forma:
·
Análisis Morfológico: Define la forma del producto y sus características geométricas (volumen, ergonomía, etc.);
·
Análisis Funcional: Define sus funciones y si estas cumplen con los objetivos planteados cuando ha sido creado;
·
Análisis Estructural: Define qué elementos tiene y cómo se relacionan. Para ello es necesario el despiece del objeto y estudiar sus partes.
·
Análisis de Funcionamiento: Define su funcionamiento, y si cumple correctamente con sus especificaciones;
·
Análisis Tecnológico: Define su elaboración y sus materiales, cómo ha sido desarrollado y que procesos fueron realizados para su fabricación;
·
Análisis Económico: Define su valor en función de sus costes (directos e indirectos), de diseño y fabricación, su logística de distribución y su precio final al consumidor;
·
Análisis Comparativo: Define sus diferencias y/o similitudes con otros productos; comparando sus funcionalidades, efectividades y precisión.
·
Análisis Relacional: Define su entorno y analiza sus elementos vinculables, por ejemplo: Si es un producto que necesita de energía eléctrica, que potencia necesitará para desempeñar su función correctamente, etc.
160
Una vez finalizado el estudio completo del producto, sus resultados podrán aportar una serie de informaciones útiles que podrán mejorar su diseño y sus prestaciones. A nivel de Project Management, se podrá, de forma más precisa, establecer los costes, plazos y los recursos necesarios para su desarrollo.
5.2.1.7 Talleres Facilitados (Facilitated Workshops) Descrito en la sección 5.1.1.3
5.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del Proyecto) I
DOC nº 007 – Enunciación de Alcance del Proyecto (Project Scope Statement)
I
DOC nº 056 – Actualizaciones a los Documentos del Proyecto (Project Document Updates)
5.3 Creación de la EDT
(Proceso que corresponde a la fase de planificación del proyecto ) Este proceso consiste en subdividir todos los entregables de un proyecto en componentes más pequeños y más fáciles de manejar. Para ello, se utiliza la Estructura Detallada de Trabajo - EDT (Work Breakdown Structure – WBS), que realiza una descomposición jerárquica de las actividades del proyecto necesarias para lograr un determinado objetivo. La EDT organiza y define el alcance total de proyecto y facilita la estimación de sus costes, plazos y recursos.
5.3.1 Técnicas y Herramientas 5.3.1.1 Estructura Detallada del Trabajo EDT (Work Breakdown Structure – WBS) También conocida como WBS (Work Breakdown Structure), es una de las herramientas más útiles y más populares en Project Management. Es sencilla y fácil de utilizar. Comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto. Cerca de 95% de las actividades de un proyecto pueden ser identificadas a través de esta herramienta. Además, sirve tantos para proyectos grandes como para pequeños. Es considerada por muchos, como la “fundación” del proyecto, puesto que aporta toda la información necesaria para realizar un seguimiento eficaz. 161
Es una técnica fundamental de planificación de un proyecto y es muy útil para:
·
Organizar y definir el alcance total del proyecto: Una regla básica de la EDT es: Si no se encuentra en la EDT, no puede formar parte del alcance;
·
Mejorar las estimaciones de los plazos, costes y recursos que serán consumidos;
·
Facilitar la comunicación entre los implicados del proyecto, permitiendo visualizar de forma gráfica el trabajo necesario para llevar a cabo sus actividades;
·
Determinar las responsabilidades de cada integrante del equipo;
·
Definir la línea base del alcance.
Características Tiene un formato de árbol jerárquico, donde se organizan las actividades y se las agrupan en un primer nivel. A partir de este nivel, se desglosa el proyecto en subniveles, hasta llegar al último nivel, que constituye los paquetes de trabajo, que tienen un nivel de detalle que permita el control req uerido por él. Una EDT tiene que contemplar todas las actividades de un proyecto, tiene que estar bien organizada y es fundamental que las actividades descritas en la EDT sean completamente entendidas por el equipo que las va a desarrollar. Si alguna actividad no está clara para el equipo, es aconsejable desglosarla en niveles más detallados.
Principales Elementos
·
Código de Cuentas (Code of Accounts): Sistema numérico utilizado para identificar los elementos de la EDT;
·
Plan de Cuentas (Chart of Accounts): Es un sistema numérico financiero utilizado para identificar cada elemento de la Estructura Detallada de Trabajo y para monitorizar los costes del proyecto por categoría (Ej.: mano de obra, materiales, maquinaria, etc.). El plan de cuentas es confeccionado de acuerdo con el plan de cuentas “maestro” desarrollado por la organización y que contiene las principales actividades de todos los proyectos desarrollados por la empresa;
·
Paquetes de Trabajo (Work Packages): Es el entregable que se encuentra en el último nivel del árbol jerárquico de la EDT;
·
Diccionario de la EDT (WBS Dictionary): Contiene la descripción detallada de los componentes que forman parte de cada actividad y cómo ellos serán desarrollados. Véase también doc 009, en el Apéndice A.
162
¿Cómo se confecciona una EDT? Para empezar a confeccionar una EDT es necesario identificar las tareas necesarias para llevar a cabo el desarrollo de un proyecto. Estas tareas deben ser divididas en fases y en secuencia cronológica. Un ejemplo muy sencillo de confección de una EDT es la pintura de una habitación, trabajo que representa uno de los entregables del proyecto de reforma de una casa.
1. Preparar Materiales 1.1 Comprar pintura 1.2 Comprar masilla 1.3 Comprar escalera 1.4 Comprar accesorios
3. Pintar el dormitorio 3.1 Lijar pared 3.2 Tapar grietas 3.3 Primera mano de pintura 3.4 Segunda mano de pintura
2. Preparar dormitorio 2.1 Retirar ropas 2.2 Retirar cuadros y espejos 2.3 Desmontar muebles
4. Limpiar el dormitorio 4.1 Tirar o guardar el resto de la pintura 4.2 Limpiar pinceles y rodillos 4.3 Guardar o tirar accesorios 4.4 Retirar la protección del suelo 4.5 Montar los muebles
2.4 Cubrir el suelo
Figura 42: EDT de una pintura de un dormitorio
163
A cada elemento de una EDT se le asigna un identificador único (normalmente numérico). Los trabajos que no estén en la EDT quedan fuera del alcance del proyecto. Según ilustra el ejemplo de la pintura de un dormitorio, la EDT descompone las tareas de un proyecto, lo que comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto (planificación, ejecución, control y cierre). La EDT puede ser ilustrada en formato de tabla, según ilustra la figura 43 que se presenta aa continuación:
1
2
3
4
PREPA RAR MATERI ALES
1.1
Comprar pintura
1.2
Comprar masilla
1.4
Comprar accesorios
2.1
Retirar ropas
2.2 2.3
Retirar cuadros y espejos Desmontar muebles
2.4
Cubrir el suelo
3.1
Lijar pared
PINTAR
3.2
Tapar grietas
DORMITO RIO
3.3
4.1
Primera mano de pintura Segunda mano de pintura Guarda pintura
4.2
Limpiar pinceles
4.3
Guardar accesorios
4.4
Retirar protección
4.5
Montar muebles
4.7
Poner cuadros y espejos
PREPARA R DORMITO RIO
LIMPIAR DORMITO
3.4
Figura 43: La EDT en formato de tabla
164
La creación de la EDT debe seguir algunas reglas importantes:
·
El primer nivel de la EDT corresponde al nombre del proyecto o fase.
·
El segundo nivel de la EDT normalmente corresponde al ciclo de vida del proyecto (en proyectos de desarrollo de software estos niveles podrían ser: Requisitos, diseño, programación, pruebas y documentación).
·
Cada nivel de la EDT debe ser más pequeño que el nivel anterior.
·
Cada tarea de la EDT debe ser realista y estimable, no puede ser subdividida, debe ser de rápida ejecución (máx. de 80 horas) y debe ser ejecutada sin interrupciones.
·
Deberá incluir todo el trabajo previsto para la ejecución del proyecto.
·
Deberá contemplar todos los entregables, incluido de terceros.
·
Deberá incluir las actividades de gestión de proyecto.
·
Cada elemento deberá tener un identificador único.
·
Cada elemento deberá corresponderse con un único entregable.
·
Es importante utilizar nombres o codificaciones familiares a toda la empresa. El Diccionario de la EDT es muy útil en este sentido.
¿Existe algún límite para descomponer una EDT? Una EDT no debe ser demasiado grande ni demasiado limitada. En cualquiera de los casos se pueden producir problemas de entendimiento del proyecto. Si una actividad que tiene una estimación de diez meses de finalización, es una actividad muy difícil de hacerse un seguimiento correcto. Lo mismo ocurre con una tarea que tiene una duración estimada de dos horas. El esfuerzo que conlleva hacer un seguimiento de una actividad de tan corta duración no es compensador. Se suele utilizar muy a menudo algunas reglas acerca de la descomposición de una EDT. Algunas organizaciones utilizan lo que se conoce por “regla 4/40” o “regla 8/80”. La regla 4/40 es utilizada cuando se establece que ningún paquete de trabajo puede tener una duración menor que 4 horas y mayor que 40 horas. Con la regla 8/80, ocurre lo mismo, pero con limites mayores. Para lograr una buena administración de un proyecto, una EDT no debe sobrepasar los cien objetos terminales. Si el proyecto es muy grande y sobrepasa este límite, es aconsejable montar varias EDT (se puede hacerlo por fases, por ejemplo). Es aconsejable también que una EDT no sobrepase 4 niveles. Normalmente, una EDT se descompone hasta llegar a una tarea desarrollada por un solo grupo funcional puro (pintores, albañiles, electricistas, entre otros). Será el responsable o encargado del grupo funcional el que realizará las estimaciones de tiempo y coste que se encuentran bajo su responsabilidad. 165
La EDT es una herramienta que debe ser desarrollada por el Project Manager en conjunto con los equipos que trabajaran en ella. Además de poder contar con la experiencia de profesionales con experiencia, el desarrollo de esta estructura en equipo ayudará a todos los involucrados a entender mejor el proyecto. De esta forma, el equipo del proyecto podrá obtener el conocimiento suficiente para poder compartir informaciones y hacer con que el proyecto se desarrolle de forma más eficaz ya que, en muchos casos, una tarea será compartida a equipos distintos. Aunque cada proyecto es único, la EDT de un proyecto similar anterior puede ser utilizada como modelo para un nuevo proyecto. Normalmente, los proyectos desarrollados por la misma empresa contienen fases y ciclo de vidas similares y muchas veces los mismos entregables
El número de horas requeridas para el desarrollo de cada actividad además de sus costes asociados, deben aparecer en cada nivel de la EDT. Las primeras estimaciones financieras podrán ser realizadas a partir de la conclusión del diseño de la EDT, como ilustra la figura 44, a continuación:
Figura 44: Estimación de costes basado en una EDT
166
5.3.1.2 Estructura de desglose del producto – EDP (Product breakdown structure – PBS) Aunque muchos proyectos son desarrollados para la puesta en marcha de una solución integrada, algunos son realizados para el desarrollo de un producto específico (un coche, un móvil, un equipo informático...). En este tipo de proyecto, es imprescindible utilizar la estructura de desglose del producto DP (Product breakdown structure - PBS, en algunos casos también es conocida como Bill of materials – BOM). Se trata de una herramienta que permite confeccionar visualmente el listado de materias primas, componentes, accesorios y cantidades necesarias para producir un determinado artículo. Muchas empresas utilizan catálogos o banco de precios electrónicos de productos (como por ejemplo, BASELEC, BASEFON o BASEFER).
Figura 45: EDP de la fabricación de una PDA
5.3.1.3 Otros tipos de estructuras de desglose ·
Estructura de desglose de la organización – EDO (Organization breakdown structure - OBS): Representa la parte del organigrama de la organización que formará parte del proyecto (descrita en la sección 9.1.1.4).
·
Estructura de desglose de costes - EDC (Cost breakdown structure - CBS): Lista organizada de costes directos en los que incurrirá el proyecto (descrita en la sección 7.1.1.10).
·
Estructura de desglose de riesgos - EDR (Risk breakdown structure - RBS): Lista organizada de riesgos del proyecto (descrita en la sección 11.2.1.5).
167
5.3.1.4 El diccionario de la EDT (WBS dictionary) La EDT es una herramienta imprescindible para organizar el alcance del proyecto. Sin embargo, tiene sus restricciones. Su uso se limita a organizar el alcance del proyecto e informar de los nombres de las actividades que forman parte del proyecto. Será necesario conocer los componentes de cada actividad y cómo ellos serán desarrollados. Para ello, se utiliza el diccionario de la EDT, que incluirá la descripción detallada de todos los elementos de la EDT. Las instrucciones sobre su confección se encuentran en el documento nº 009 en el Apéndice A.
5.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 008 – Estructura detallada del trabajo EDT (Work breakdown structure - WBS)
I
DOC nº 009 – Diccionario de la EDT (WBS dictionary)
I
Línea base del alcance. Véase sección 2.1.3 (Scope baseline)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
5.4 Verificación del alcance
(Proceso que corresponde a la fase de control del proyecto) Es el proceso que consiste en obtener la aceptación formal del alcance del proyecto por parte de los interesados correspondientes. Esta aceptación tiene como condicionante la revisión de los entregables del proyecto que deberán atender a los requisitos establecidos. Como requisito, podemos decir que es: “Una condición o capacidad que un producto o servicio tiene que poseer para cumplir con un contrato, especificación o cualquier otro documento formalmente impuesto”. Los requisitos incluyen las necesidades, los deseos y las expectativas del cliente o del patrocinador. Generalmente, clasificamos los requisitos en dos tipos:
·
Obligatorios: forman parte inexcusable del proyecto.
·
Deseables: aportarían valor añadido a la satisfacción del cliente, pero no están incluidos obligatoriamente en el proyecto.
Cuando hablamos de requisitos deseables, es muy importante no caer en la tentación de añadir requisitos que en vez de aportar beneficios al proyecto, puede perjudicar el buen funcionamiento del producto o servicio resultante. Esto suele suceder a menudo cuando se practica en gold plating (véase también capítulo 9 – Gestión de la calidad). 168
5.4.1 Técnicas y herramientas 5.4.1.1 Inspección (Inspection) La inspección funciona como si de una auditoria se tratara. Se realiza a través de mediciones y verificaciones que determinarán si los servicios o productos entregados cumplen con los requisitos establecidos en el plan de proyecto. Esta inspección puede ser realizada por el Project Manager, por algún miembro del equipo capacitado o incluso por el propio cliente (de hecho, lo suelen hacer antes de firmar la aceptación del proyecto). A veces, se contrata a un auditor externo con competencia para determinar si el producto o servicio desarrollado cumple con los requisitos establecidos previamente. Se suele hacer en formato de checklist que incluirá todos los componentes de la EDT del proyecto. Normalmente, suele tener los campos a continuación:
Nº
DESCRIPCIÓN DEL ARTÍCULO
APROBA SÍ DO NO
CRÍTICO SÍ NO
1 4 5 Figura 46: Checklist de artículos
De acuerdo con los resultados de la inspección, el cliente podrá aceptar el producto/servicio entregado o rechazarlo. La forma en que se realizará la inspección, incluyendo cuales son los puntos considerados críticos, podrá ser detallada en el plan de proyecto.
5.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Entregables aceptados (véase sección 2.4) (Accepted deliverables)
I
DOC nº 039 – Solicitudes de cam bio (Change requests)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
169
5.5 Control de cambios del alcance
(Proceso que corresponde a la fase de control del proyecto) Casi todos los proyectos que son desarrollados sufren cambios por alguno motivo. Cuanto más largo y complejo sea un proyecto, mayor es la posibilidad de que sufra algún cambio. En casi todos los casos, los cambios en un proyecto son inevitables, y por ello es importante estar preparado para afrontar el momento de realizar las eventuales acciones correctivas, cuando estos cambios ocurran. Los cambios de un proyecto pueden ser el resultado de muchos factores:
· · · · ·
La aprobación de una nueva ley. Una petición inesperada por parte del cliente. Un cambio de tecnología. Un cambio de estrategia organizacional. Un error o una omisión en la línea base del alcance.
A continuación, veremos las principales herramientas de control de cambios de alcance.
5.5.1 Técnicas y herramientas 5.5.1.1 Análisis de variación (Variance analysis) El análisis de variación es una herramienta utilizada para evaluar la magnitud de la variación respecto de la línea base original del alcance. Los aspectos importantes de control incluyen básicamente la determinación de la causa y del grado de variación entre la línea base original del alcance y la línea base actual. Se desarrolla de la siguiente manera:
·
Se comprueba la calidad y la veracidad de la información recopilada a fin de asegurarse de que esté completa y de que sea coherente con datos anteriores.
·
Se establecen las variaciones mediante la comparación de la información real con la línea base del proyecto, y la observación de todas las diferencias, tanto favorables como desfavorables.
·
Se utilizan herramientas como el valor del trabajo realizado para cuantificar las variaciones.
·
Se determina el impacto de las variaciones y sus consecuencias en el coste y en el cronograma del proyecto.
·
Se documentan las conclusiones sobre las fuentes de variación y el área de impacto.
El valor del trabajo realizado (earned value – EV) es descrito detalladamente en la sección 7.3.1.1.
170
5.5.1.2 Sistema de control de cambios del alcance (Scope change control system) Descrito en la sección 4.5.1.1
5.5.1.3 Planificación adicional (Aditional planning) Son pocos los proyectos que se desarrollan exactamente según lo planificado. Prácticamente todos los cambios aprobados y aplicados al proyecto conllevarán la modificación de la documentación original, y por ello se hará necesario la revisión de los plazos, costes y recursos anteriormente establecidos. La planificación adicional tiene como objetivo mitigar cualquier impacto negativo causado por los cambios incluidos en el proyecto. Por ello es importante revisar toda la planificación anteriormente realizada y actualizarla acorde con la nueva situación del proyecto.
5.5.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Mediciones del desempeño del trabajo. Véase sección 7.3.1.1 (Work performance measurements)
I
Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al pro ceso
I
DOC nº 039 – Solicitudes de cam bio (Change requests)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
I
Cambios del alcance (Scope changes) - Los que correspondan al proceso
I
DOC nº 046 – Plan de acciones correctivas (Corrective action plan)
I
DOC nº 054 – Lecciones aprendidas (Lessons learned)
I
Línea base ajustada. Véase sección 2.1.3 (Adjusted baseline) 171
Capítulo 6 Gestión del tiempo “Pocos son los que tienen tiempo suficiente y, sin embargo, cualquiera tiene casi todo el tiempo que hay” Paradoja del tiempo
172
Algunas cosas en las que NO puedes pensar acerca de la gestión del tiempo “El cronograma es inútil, ya sabéis que no lo vamos a cumplir” Podemos considerar que un cronograma está bien hecho cuando refleja exactamente la realidad de su entorno. Es decir, un cronograma tiene que basarse en la correcta gestión de los calendarios, en la capacidad de ejecución por parte del equipo asignado y en la complejidad de cada actividad. El problema del incumplimiento de plazos no reside en el cronograma. Las causas son las mencionadas anteriormente: no se ha tenido en cuenta el calendario del proyecto, el equipo no tenía la capacidad esperada, o la complexidad de la actividad ha sido evaluada incorrectamente. “Os puedo asegurar, que mañana lo tenemos funcionando” “No dejes para mañana lo que puedas hacer hoy”. Este refrán, muy popular, significa exactamente lo que parece, y se encaja perfectamente a la gestión del tiempo del proyecto. Si puedes hacer algo ahora, no esperes al día siguiente. Si tienes una tarea en manos y hay tiempo y condiciones para iniciarla, lo ideal es ponerla en marcha para que se pueda finalizarla dentro del plazo. Una serie de incidencias no esperadas pueden llegar a ocurrir en un proyecto, lo que podrá provocar atrasos en la finalización de algunas actividades. Si a esto sumamos atrasos debidos a postergaciones innecesarias, el cronograma del proyecto podría colapsarse. “No es necesario obedecer la secuencia de actividades propuesta” Al analizar el cronograma de un proyecto, se podrá apreciar que las actividades obedecen a una lógica, que han sido investigadas y desarrolladas por un grupo de expertos. Prácticamente, todos procesos industriales, artesanales o incluso naturales obedecen a una secuencia lógica que no debería ser modificada. No se puede pintar una pared sin antes levantar los ladrillos, y tampoco es posible tomarse una copa de vino sin antes sacarle el corcho de la botella. Por lo tanto, si el cronograma presenta una secuencia de actividades, lo mejor es cumplirla a rajatabla. “Esta medición, aunque parezca compleja, será realizada en tiempo récord” Existen tareas que necesitan un tiempo mínimo para que finalicen adecuadamente. El desarrollo de un proyecto no es una carrera contra el tiempo, es un emprendimiento que ha sido previamente estudiado y cuyas actividades deberán ser realizadas dentro de unos plazos compatibles con su naturaleza. “Podemos hacerlo con calma, porque disponemos de una buena reserva de tiempo extra” Las reservas de contingencia de tiempo existen para los casos de emergencia cuando, por razones especiales, el equipo no ha podido finalizar su labor en el plazo previsto y, por lo tanto, dispone de una reserva de tiempo extra para poder completar sus tareas. Por esta razón, no podemos ralentizar la ejecución de una tarea, pensando en una reserva de tiempo que tenemos disponible.
173
Según la ley de Parkinson (Parkinson´s law), creada por Cyril Northcote Parkinson22 en un artículo publicado en el semanario británico The Economist, en el año 1955: “El trabajo se amplía para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de seis días y se añaden dos días más como contingencia, según la ley de Parkinson, esta tarea llevará ocho días para ser completada. Por supuesto, esta teoría no pretende derrumbar la técnica de la reserva de tiempo, pero intenta demostrar que no será simplemente añadiendo un par de días más a cada tarea, que se alcanzará el cronograma perfecto; todo lo contrario, esta práctica puede tornarse un vicio que convertirá el proyecto en un emprendimiento interminable.
Introducción Para muchos, gestionar un proyecto es lo mismo que confeccionar un cronograma. Sabemos que la gestión de un proyecto conlleva a la administración integrada de una serie de elementos, como son la comunicación, los costes, el alcance y los recursos humanos. La gestión del tiempo, por lo tanto, depende del correcto sincronismo de las actividades realizadas por los diferentes profesionales implicados en el proyecto que necesitarán de una coordinación que pueda asegurar el cumplimiento de toda la planificación establecida. Aisladamente, la gestión del tiempo empieza definiendo las actividades del proyecto. Luego se organiza su secuencia para, a continuación, estimar sus duraciones. El resultado final de estas estimaciones es el cronograma, que orientará el equipo del proyecto en lo que dice respeto a las fechas de inicio/fin y la duración de las actividades correspondientes. Algunos proyectos pueden perder totalmente su objetivo si los plazos no son cumplidos. La infraestructura necesaria para realizar una carrera de Fórmula 1 en una ciudad, será de muy poca utilidad si los trabajos se concluyen después que la carrera ha terminado. Sin embargo, y naturalmente, gestionar el tiempo de un proyecto no se limita tan solamente a estimar las secuencias y las duraciones del proyecto, ni mucho menos desarrollar un cronograma. Existen algunos conceptos que el Project Manager necesita conocer, para entender mejor las implicaciones que conlleva realizar una gestión de tiempo correcta:
·
Actividad crítica (Critical activity): Es una actividad que, si no finaliza en el tiempo estimado podrá impactar negativamente en la duración de todo el proyecto. Se determina una actividad como critica cuando no se puede cambiar sus fechas de comienzo y finalización sin modificar la duración total del proyecto. Su holgura total es cero.
·
Camino crítico (Critical path): Es la secuencia de actividades del proyecto que tiene la mayor duración y que determina el menor tiempo posible para completar un proyecto sin holguras. La duración del camino critico determina la duración total del proyecto, con lo cual, cualquier retraso en el desarrollo de los elementos del camino critico repercutirá negativamente sobre la fecha de finalización del proyecto. Es decir, si se retrasa en dos días una de las actividades del camino crítico, el proyecto entero se retrasará en dos días (a no ser que haya otra tarea del camino crítico que se adelante en dos días).
·
Duración (Duration): Periodo de tiempo estimado (sin incluir días festivos u otros periodos de no trabajo) necesario para completar una determinada actividad. Normalmente es expresado en horas, días, semanas...
174
•
Esfuerzo (Effort): Número de unidades requeridas para completar una determinada actividad del proyecto. Normalmente se expresa en horas hombre, días hombre o semanas hombre. No se debe confundir con la duración.
·
Flotación (Float): Tiempo que una actividad se puede retrasar desde su fecha de inicio temprana sin retrasar la fecha de finalización del proyecto. Este tiempo de flotación puede cambiar a medida que avance el proyecto y se efectúan cambios en el proyecto.
·
Recorrido hacia Adelante (Forward Pass): Este término determina la fecha de inicio y finalización más temprana para las partes incompletas de todas las actividades de la red. El resultado obtenido permite conocer cuál es la fecha más temprana para la asignación de un determinado recurso y cuál es la fecha mínima que el proyecto necesita contar con este recurso.
·
Recorrido hacia Atrás (Backward Pass): Cálculo de fechas de finalización e inicio tardías para las partes incompletas de todas las actividades de las redes. Se determina yendo hacia atrás en la logia de las redes a partir de las fechas de conclusión del proyecto, la que puede calcularse en un recorrido hacia adelante o ser establecida por el cliente o patrocinador.
·
Hito (Milestone): Un punto del cronograma, normalmente señalizando un evento importante del proyecto, normalmente la conclusión de una determinada actividad, decisión o fase. Los hitos no son actividades, es decir que no consumen tiempo ni recursos, son tan solamente, un punto de referencia del proyecto.
·
Diagrama de Red (Network Diagram): Representación gráfica de las relaciones lógicas de las actividades de un proyecto. Siempre se traza de la izquierda a la derecha para reflejar la cronología del proyecto.
·
Holgura (Slack): Es la cantidad de tiempo que una tarea puede ser aplazada sin afectar la fecha de finalización del proyecto.
Estos términos son fundamentales para entender correctamente la gestión del tiempo del proyecto. Su correcto entendimiento además, contribuirá para el desarrollo de un cronograma realista. Un cronograma “perfecto” que debería ser confeccionado obedeciendo algunos procedimientos:
·
Identificar las actividades que formarán parte del proyecto: Utilizando la Estructura detallada del proyecto – EDT (descrita en la sección 5.3) será posible realizar las estimaciones iniciales del proyecto. La EDT es una herramienta de descomposición del trabajo realizado, orientada a los entregables del mismo, que organiza y define el alcance completo.
·
Desarrollar el diagrama de red: La confección de este diagrama deberá contemplar todas las actividades del proyecto. Estas actividades deberán secuenciarse de forma precisa para sustentar el posterior desarrollo de un cronograma realista. Si posible, es importante poder contar con la colaboración de expertos. (Para más detalles, véase también sección 6.2.1 - Técnicas y herramientas para la secuenciación de actividades).
175
•
Estimar la duración de las actividades: Normalmente, se estiman las fechas más optimistas, como si todos los recursos estuviesen disponibles en tiempo integral. Una vez hecha está estimación orientativa, se parte para una estimación más realista, basado en la disponibilidad real de los recursos en la empresa.
·
Estimar fechas: Con la secuencia y la duración de las actividades en manos, es hora de planificar las fechas concretas de comienzo y cierre del proyecto. Muchas veces, estas fechas son una restricción del proyecto ya que pueden, y muchas veces lo son, determinadas pelo cliente. Para poder lograr el cumplimiento del calendario establecido, es importante considerar festivos, horarios especiales y, sobre todo, la disponibilidad de los recursos asignados; esta última muchas veces es la razón por la cual muchos proyectos no finalizan en el plazo estimado.
·
Hacer un seguimiento: Finalizado en cronograma de las actividades es fundamental crear una línea base. Esta línea base será importante para comprobar si el proyecto avanza según el cronograma planificado y posteriormente se tornará una fuente de consulta para futuros proyectos similares.
En algunos proyectos, especialmente en los pequeños, la secuencia de las actividades, su estimación y duración, así como el desarrollo del cronograma están tan estrechamente vinculados que son vistos como un único proceso ya que pueden ser ejecutados durante un periodo relativamente corto. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión del tiempo de un proyecto incluye los procesos y actividades necesarios para administrar la finalización del proyecto a tiempo. Son estos:
· · · · · ·
Definir las actividades. Secuenciar las actividades. Estimar los recursos de las actividades. Estimar la duración de las actividades. Desarrollar el cronograma. Controlar el cronograma.
6.1 Definición de las actividades
(Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste básicamente en identificar correctamente las acciones específicas que deberán ser puestas en marcha para el desarrollo de los entregables del proyecto. Las actividades de un proyecto son la base fundamental para la estimación, la planificación, la ejecución, el seguimiento y el control del trabajo del proyecto. La definición y la planificación de las actividades del cronograma están implícitas en este proceso, de modo que se cumplan los objetivos del proyecto.
176
6.1.1 Técnicas y herramientas 6.1.1.1 Estructura detallada del trabajo – EDT (Work breakdown structure – WBS)
Descrita en la sección 5.3
6.1.1.2 Descomposición (Decomposition) La descomposición es la subdivisión de los entregables del proyecto en componentes más pequeños y manejables, hasta que el trabajo y los entregables queden definidos al nivel de paquetes de trabajo. El nivel de paquetes de trabajo es el más bajo en la EDT, y es aquel en el que el coste y la duración de las actividades del trabajo pueden estimarse y gestionarse de manera más confiable. El nivel de detalle para los paquetes de trabajo varía en función del tamaño y la complejidad del proyecto. La forma más conocida y más utilizada para hacer la descomposición del alcance de un proyecto es la técnica de la estructura detallada del proyecto – EDT (work breakdown structure – WBS), descrita en la sección 5.3.
6.1.1.3 Planificación gradual (Rolling wave project planning RWPP)
Descrito en la sección 5.2.1.3
6.1.1.4 Plantillas (Templates) Una plantilla es un documento estándar utilizado para diferentes fines y sirve, sobre todo, para facilitar el trabajo de reproducción de documentos idénticos o similares. Las plantillas no son otra cosa que un punto de partida, una idea aproximada de lo que se quiere hacer. A partir de una plantilla se puede diseñar nuevas plantillas, más refinadas y con más informaciones. Con el paso de los años, muchas empresas mantienen un “banco de plantillas” que pueden ser aprovechadas para determinado momento del proyecto.
177
Las plantillas son realmente muy útiles. Yo mantengo un banco de plantillas personal desde hace años y las utilizo a menudo. Cualquier documento puede servir de plantilla: contratos, cronogramas, líneas base, cartas, propuestas... Se trata de un recurso que te hace ahorrar el tiempo y te aporta un contenido listo para usar. Otra ventaja es que estas plantillas van mejorando con el paso del tiempo. Siempre que utilizo una plantilla, aprovecho para mejorar su contenido y formato. No obstante, a la hora de coger un documento para convertirlo en plantilla, es fundamental eliminar cualquier información que pueda identificar a personas, fechas, valores o cualquier otro dato identificativos utilizado en un documento anterior. De una plantilla se aprovecha su estructura y contenido, pero se debe conservar la confidencialidad, eliminando datos considerados “sensibles”.
6.1.1.5 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
6.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I DOC nº 010 – Lista de actividades (Activity list)
I DOC nº 011 – Atributos de la actividad (Activity attributes)
I Lista de hitos (véase session 6.5.1.9) (Milestone list)
6.2 Secuenciación de actividades
(Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste en identificar y documentar las relaciones entre las actividades del proyecto, que se establecen mediante relaciones lógicas; es decir, las actividades se conectan con sus predecesores y sucesores correspondientes, que pueden incluir adelantos o retrasos entre las actividades que proporcionen al cronograma un escenario realista, viable y, sobre todo, sostenible.
178
6.2.1 Técnicas y herramientas 6.2.1.1 Diagramas de red (Network diagram) Un diagrama de red es el término genérico de un diagrama, que representa algún tipo de red que pueda conectar varias actividades en una secuencia cronológica. Presentan una serie de variaciones, y cada una de ellas podrá ser estructurada para los más diferentes fines.
Figura 47: Diagrama básico de red
Un diagrama de red básico debería contener, por lo menos, los siguientes elementos:
·
Un evento: Que señale el inicio y el fin de la tarea o acción; no consume tiempo ni recursos. Se representa a través de un nodo o un círculo.
·
Actividades: Son el un conjunto de tareas, que deben ejecutarse, para la realización de una obra; consume tiempo, tiene inicio y fin, requiere mano de obra, materia prima y otros recursos.
·
Una actividad ficticia: Es aquella que no consume tiempo ni trabajo. Se representa por líneas entrecortadas y sirve para guardar la lógica de la red.
·
Un camino crítico: Es el camino más largo a través de la red y representa el menor tiempo posible para la ejecución del proyecto.
6.2.1.2 Método de diagramación con flechas (Arrow diagramming method - ADM) También conocido por “AOA - Activity on arrow”, es una de las primeras herramientas utilizadas para secuenciar actividades. Utilizada en proyectos muy sencillos, su concepto es limitado y no puede soportar una red de actividades muy compleja. Por esta razón, es poco utilizada actualmente.
179
La relación precedente entre actividades es representada por círculos conectados a una o más flechas. La longitud de la flecha puede representar la duración de la actividad. En algunos casos, se añade una actividad ficticia (conocida en el ámbito del Project Management como dummy task), que sirve básicamente para representar la dependencia entre actividades y no consume tiempo ni trabajo. Existen dos formas de diseñar una diagramación con flechas. En la figura 48, la actividad es representada por la fecha, en que los círculos ilustran el comienzo y el fin de la actividad. También se puede confeccionar este diagrama representando las actividades en círculos, según ilustra la figura 49. Las flechas representan la secuencia determinada para las actividades del proyecto.
Figura 48: Enlace de eventos
Figura 49: Enlace de actividades
Figura 50: Diagrama ADM
6.2.1.3 Método de diagramación por precedencia (Precedence diagramming method PDM) El PDM es una técnica de representación visual que describe las actividades de un proyecto. Es una herramienta que aporta muchos beneficios, como por ejemplo:
·
Comunicación clara: Su representación visual permite entender claramente el flujo de desarrollo del proyecto y sus implicaciones.
·
Identificación de actividades “olvidadas”: Cuando una actividad no es identificada, consecuentemente no será incluida en la red y, por supuesto, no será desarrollada. La PDM permite, a través del análisis de su estructura, la ausencia de alguna actividad en el proyecto.
180
• Identificación
de las dependencias: En la PDM, cada actividad es dependiente de alguna actividad predecesora. Cuando una dependencia no es identificada, el proyecto seguramente terminará retrasado. Por ejemplo, si un componente crítico está siendo producido por un proveedor externo, el producto final dependerá del proveedor, es decir, aunque todas las actividades internas hayan sido correctamente completadas, el proyecto no estará finalizado hasta que el proveedor suministra el componente crítico. Este un ejemplo de dependencia que debe ser identificada y por supuesto, contemplada en la PDM.
·
Identificación de las actividades críticas: Algunas actividades tienen un mayor impacto en la programación del proyecto que otras. Mediante el uso de la PDM, es posible determinar las actividades críticas a la programación del proyecto. Esto se conoce como método del camino crítico (descrito con profundidad en la sección 6.5.1.2).
·
Creación del cronograma del proyecto: El objetivo final de todo PDM es crear un cronograma de trabajo fiable.
Relaciones de precedencia:
·
Finalizar para comenzar (Finish-to-start): Muchas de las actividades de un proyecto contienen esta relación lógica. Es, sin duda, la relación más común de todas. En esta relación, la actividad predecesora (A) debe ser concluida para que la actividad sucesora (B) pueda empezar. Esto no quiere decir que la actividad sucesora (B) finalice inmediatamente tras el término de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, después de aplicar la masilla, se puede empezar la pintura en cualquier momento, pero es lógico que no se podrá pintar la pared antes que se aplique la masilla.
Figura 51: Relación finish-to-start
·
Comenzar para finalizar (Start-to-finish): Esta relación es la menos utilizada en un proyecto. La actividad predecesora (A) debe empezar antes de que finalice la actividad sucesora (B). No es necesario que la actividad sucesora (B) finalice inmediatamente después del comienzo de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, el aprendiz puede empezar a pintar (A) antes de la llegada del jefe de pintura (B), pero no podrá rematar la pintura (A) antes su llegada (B).
181
Figura 52: Relation start-to-finish
182
•
Finalizar para finalizar (Finish-to-finish): La actividad predecesora (A) debe finalizar antes de que finalice la actividad sucesora (B). No es necesario que la actividad sucesora (B) concluya inmediatamente después del término de la actividad predecesora (A), pero no podrá terminar antes. Por ejemplo, el jefe de la pintura no podrá terminar la revisión de la pintura (B) antes que el aprendiz termine de pintar (A). A B
Figura 53: Relation finish-to-finish
·
Comenzar para comenzar (Start-to-start): La actividad predecesora (A) debe empezar antes de que empiece la actividad sucesora (B). No es necesario que la actividad sucesora (B) empiece inmediatamente después de la puesta en marcha de la actividad predecesora (A), pero no podrá empezar antes. Para ilustrar un ejemplo, cogeremos una vez más el caso de la pintura de una habitación. Las dos actividades son: (A) la llegada del jefe de pintura y (B) pintar la pared. El aprendiz de pintura no puede empezar a pintar (actividad B), antes que llegue el jefe de pintura (actividad A);
Figura 54: Relación start-to-start
·
Leads y Lags: Para acabar el tema de las relaciones entre actividades es importante mencionar los leads y lags. Se trata de retrasos o adelantos que, a veces, son impuestos entre actividades de un proyecto, sin modificar su relación.
Una lag es un retraso o un “tiempo de espera” entre actividades. En el ejemplo de la pintura, cuando se aplica la masilla, es necesario esperar un tiempo para que esta pueda secar, y a continuación empezar la pintura. Si establecemos un tiempo de secado de ocho horas, este será el lag entre una actividad y la posterior. La actividad B (pintar la pared) no podrá empezar hasta ocho horas después de completada la actividad A (aplicación de la masilla). Por otro lado, una lead es aceleración entre actividades. Una forma de “provocar” una lead es realizando dos tareas en paralelo, cuando lo normal es que deberían ser realizadas en secuencia.
183
Por ejemplo, tras la aplicación de la masilla en la pared, se podría instalar la cornisa mientras se espera por el secado de la masilla y antes que empiece la pintura de la pared. Es decir, la actividad C (instalación de la cornisa) empezaría ocho horas antes de la actividad B (pintar la pared). De esta forma, el tiempo necesario para la ejecución y finalización de la actividad C sería absorbido por el tiempo de espera entre la actividad A y B.
Teniendo en cuenta los conceptos de relación de dependencias, ya es posible confeccionar un diagrama de red. Para ello, es importante saber: a) Qué actividades deben empezar antes de una actividad concreta.
b) Qué actividades no pueden empezar antes que se finalice una actividad concreta. c) Qué actividades pueden ser desarrolladas simultáneamente. A partir de la información recogida de la estructura detallada trabajo – EDT (descrita en la sección 5.3), se confecciona una tabla donde se clasifican las actividades del proyecto y se identifican sus predecesores. Todavía no se han realizado las estimaciones de duración o adjudicación de recursos. De momento, la única preocupación es establecer la relación entre las actividades. El ejemplo que se desarrolla a continuación ilustra las actividades para la puesta en marcha de un viaje de fin de semana.
ACTIVIDAD 1
3
DURACIÓ N (en 10
6
30
5
30
PRECEDES ORA
DESCRIPCIÓN Revisar documentación
3
Llamar taxi y dirigirse al aeropuerto Reservar hotel y vuelo
4
Separar ropas
3
30
5
-
10
6
Establecer las fechas del viaje Dormir y despertar a la hora programada
1,4,7
480
7
Preparar el equipaje
3
30
9
120
2
120
2
8 9
Aterrizar en el destino programado Realizar check-in y embarque en los horarios establecidos
Figura 55: Tabla de actividades de la EDT
184
Note que en la propia tabla de actividades de la EDT se pueden establecer sus duraciones. La duración de una actividad será estimada por el esfuerzo previsto, es decir el tiempo que uno o más recursos necesitarán para ejecutarla. Este esfuerzo normalmente es estimado por número de horas (o minutos, como ilustra la figura 55, por tratarse de un proyecto de tres días). La columna de las predecesoras es fundamental para poder enlazar la secuencia de las actividades y construir el diagrama correspondiente, según ilustra la figura abajo:
Figura 56: Secuencia de actividades
Según explicado anteriormente, hay casos muy frecuentes en que el Project Manager y su equipo suelen realizar estimaciones muy optimistas. Para definir correctamente la duración de una actividad, se debería contar con la experiencia de expertos, que podrán aportar estimaciones más realistas. Convirtiendo el diagrama en un cronograma: El producto resultante de la confección del diagrama de red y de la estimación de las duraciones de cada actividad resultará en el cronograma, que tendrá un aspecto semejante al que ilustra la figura a continuación. Para conocer más detalles acerca del desarrollo de un cronograma, véase también sección 6.5.
Figura 57: Cronograma del proyecto
155
6.2.1.4 Método del camino crítico (Critical path method – CPM) El método CPM o camino crítico (critical path method - CPM) fue desarrollado en 1957 por la empresa americana DuPont, y su objetivo principal es establecer la duración de un proyecto, entendiendo este como una secuencia de actividades que se relacionan entre sí, donde cada una de ellas tiene una duración determinada. Un camino o ruta es el recorrido (o recorridos) realizada por el proyecto a través de la secuencia lógica de sus actividades desde el inicio hasta el final. En este sentido, cada camino tendrá sus longitudes, siendo una de ellas considerada un camino crítico, y será siempre la más grande del proyecto. El camino crítico tiene una característica principal: no hay tiempo de holgura entre las actividades, y por ello, ninguna de ellas puede retrasarse. El camino crítico solo permite holgura si una de sus actividades es completada antes del plazo previsto. El desarrollo del CPM es realizado a través de los siguientes pasos:
1.
Se identifican las actividades del proyecto: A través de la EDT (véase también sección 5.3) se recogen todas las actividades necesarias para el desarrollo del proyecto.
2.
Se establecen las relaciones entre las actividades. Decidir cuál debe comenzar antes y cuál debe seguir después.
3.
Se confecciona el diagrama de red. Conectando las diferentes actividades en base a sus relaciones de precedencia.
4.
Se define el tiempo estimado para cada actividad.
5.
Se identifica la trayectoria más larga del proyecto. Siendo esta la que determinará la duración del proyecto (el camino critico).
Una CPM puede proporcionar una gran cantidad de informaciones, y para poder conocerlas, es importante establecer los siguientes parámetros para cada actividad: Para organizar correctamente el camino crítico es importante cumplir un requisito importante: Organizar todas las actividades secuencialmente, identificando sus sucesoras y predecesoras y estableciendo sus fechas de inicio y fin, que se desglosan en cuatro tipos:
186
Figura 58: Diagrama de red según el CPM
• Inicio más temprano - IT (early start - ES): Representa la fecha de inicio más temprana en que se pude iniciar una actividad, basada en el diagrama de red del cronograma del proyecto. Para las primeras actividades del proyecto esta fecha es la fecha de comienzo del proyecto.
·
Inicio más lejano - IL (late start - LS): Es la fecha más de inicio tarde en que se puede iniciar una actividad, basada en el diagrama de red del cronograma del proyecto.
·
Finalización más temprana - FT (early finish – EF): Representa la fecha más temprana posible de finalización de una determinada actividad, basada en el diagrama de red del cronograma del proyecto.
·
Finalización más lejana - FL (late finish - LF): Representa la fecha más tardía de finalización de una determinada actividad, sin provocar retrasos en el proyecto. Las fechas de finalización tardías son determinadas durante el cálculo del camino crítico a partir del final del proyecto hacia el principio.
Ejemplo práctico: Para desarrollar correctamente el método del camino crítico, es necesario previamente realizar las siguientes acciones:
·
Una vez identificadas las actividades del proyecto, se determinan sus sucesores y predecesores, estableciendo de esta forma las rutas lógicas que el proyecto tendrá que recorrer desde el inicio hasta su fin.
·
Es imprescindible conocer cuál es la duración estimada de cada actividad, antes de desarrollar el diagrama, puesto que la duración será siempre el punto de partida para conocer los otros valores de la red. Tal y como ilustra la figura 59, la duración de las actividades se disponen en el recuadro central superior de la actividad correspondiente.
·
Como regla general el inicio y el fin son considerados hitos, y por ello su duración será siempre igual a cero.
187
Figura 59: Diagrama de red con sus rutas lógicas y duraciones correspondientes
Tal y como podemos apreciar en la figura 59, las actividades del proyecto ya están enlazadas por varias rutas lógicas y sus actividades predecesoras debidamente identificadas. Es fundamental añadir un “INICIO” y un “FIN” al diagrama, para no dejar ninguna actividad “suelta”. De esta forma, tenemos el diagrama debidamente atado. Es importante mencionar otra vez, que el inicio y fin son hitos, y, por lo tanto, tendrán duración igual a cero. Conociendo la duración de todas las actividades, ya podemos establecer cuáles serán las fechas de inicio más temprano y finalización más temprana. En el la figura 60, las actividades “A”, “B” y “C”, empiezan simultáneamente, a partir del inicio (que tiene duración igual a cero), por lo tanto, sus fechas de inicio más temprano será igual a “cero” y las fechas de finalización más temprana serán: cero + la duración correspondiente.
Figura 60: Las fechas de inicio más temprano se sitúan el recuadro superior izquierdo y las de finalización más temprana en el recuadro superior derecho
188
Para obtener entonces las fechas de inicio y finalización de las siguientes actividades, se realizan los siguientes cálculos: Actividad D: IT (2) + duración (3) = FT (5) Actividad E: IT (4) + duración (5) = FT (9) Actividad F: IT (2) + duración (4) = FT (6)
Figura 61: Diagrama de red con sus fechas y duraciones
En el caso de la actividad “G” tenemos una situación especial. Tal y como se puede observar en la figura 62, esta actividad tiene 3 predecesoras (B, D y E). Cuando esto ocurre, siempre se elegirá el valor de la actividad predecesora que posee el mayor valor. En este caso, sería la actividad “E” que tiene un FT = 9. De esta forma: IT de la actividad “G” es igual al FT de la actividad “E” + duración de la actividad “G” = 9 + 2 = 11.
Figura 62: Diagrama de red con sus fechas y duraciones
189
Con el fin del proyecto pasa lo mismo. Como se encuentra enlazado por dos actividades predecesoras (F y G), se elegirá la que tenga la FT mayor. En este caso, sería la actividad “G” que tiene un FT = 11. De esta forma, el fin del proyecto será: = FT de la actividad “G” + duración del “FIN” = 11 + 0 = 11.
Figura 63: Diagrama de red con sus fechas y duraciones
El camino de vuelta Ahora, tenemos que hacer el camino de vuelta, para conocer las fechas de inicio y fin lejano (IL y FL). Para empezar correctamente con el camino de vuelta, tenemos que tener en cuenta lo siguiente: La FL del “FIN” será siempre igual a su “FT”, en este caso será 11. La FL de las actividades predecesoras del “FIN” será siempre igual al FL del “FIN”, con lo cual, las actividades “F” y “G” tendrán un FL = 11.
Figura 64: El camino de vuelta
190
A continuación, se aplican las FL de cada actividad predecesora y restando con la duración correspondiente, encontraremos sus IL correspondientes, lo que nos proporcionará los siguientes resultados: 1 – = IL de “G”: 1 IL de “F”: 1 – = IL de “E”: 9 – = 4 – = IL de “B”: 9 – = IL de “A”: 6 – =
Figura 65: El camino de vuelta
La actividad “A” tiene dos sucesores “D” y “F”. En el camino de vuelta, cuando una actividad se enlaza con dos sucesoras, se elige la de menor valor, es decir: IL de “A” = IL de “D” (6) – 2 = 4. Tras calcular las formulas correspondientes en el camino de ida y vuelta, ya conocemos todas las fechas posibles del proyecto. (IT, FT, IL y FL) y tenemos todo el grafico completo. Nos queda por fin, conocer el camino crítico del proyecto, y para ello necesitamos encontrar las holguras de cada actividad, representadas en el recuadro centrar inferior, que es el único recuadro que se ha quedado de momento sin ningún valor. Las holguras se obtienen restando el FL del FT de cada actividad (FL – FT), es decir: Actividad A: Actividad B: Actividad C: Actividad D: Actividad E: Actividad F: Actividad G:
6-2 9-6 4-4 9-5 9-9 11 - 6 11 – 11
191
= = = = = = =
Y de esta forma, hemos obtenido la holgura de todas las actividades. Nos queda por fin, lograr el objetivo principal de esta herramienta, que es identificar el camino crítico del proyecto.
Identificando el camino crítico Esta operación es muy sencilla. Simplemente se marcan las actividades cuya holgura es igual a cero; en este caso, serían las actividades “C”, “E” y “G”, además del inicio y del fin
Figura 66: El camino crítico
La duración de todas estas actividades será lo que indique el FL del fin, en este caso, once días, o sea, el camino crítico de este proyecto tiene once días, y por no disponer de holguras, ninguna actividad podrá retrasarse. Por todo ello, el Project Manager tendrá que asegurar que:
· · ·
La actividad “C” empiece el día 0 y termine el día 4. La actividad “E” empiece el día 4 y termine el día 9 La actividad “G” empiece el día 9 y termine el día 11.
Si estas fechas no se cumplen, todo Si esto ocurre, todo el proyecto se retrasará. Las otras actividades podrán retrasarse acorde con la holgura que cada una dispone, por ejemplo: La actividad A dispone de una holgura de cuatro días, por lo tanto, si hiciera falta, esta actividad podría empezar el día uno o dos y terminaría el día tres o cuatro.
Figura 67: Las holguras de una actividad
192
• Las actividades del camino crítico no son necesariamente las técnicamente más importantes del proyecto.
·
Para utilizar el método CPM correctamente, es imprescindible conocer todos los tiempos de duración de cada actividad del proyecto, es decir, no puede haber incertidumbre.
·
En un diagrama como el presentado, los cálculos de ida y vuelta son sencillos. No obstante, nos podemos encontrar con diagramas bastante complejos, y por ello se recomienda el uso de programas informáticos. El CPM es una de las herramientas clave del Project Management, y cualquier error podría provocar graves daños al proyecto.
·
Las actividades que forman parte del camino crítico deben ser las actividades que el Project Manager deberá dedicar más atención. Todo y cualquier retraso en el camino crítico provocará un retraso en todo el proyecto. Tampoco es recomendable abusar de las holguras de determinadas actividades. Cualquier incidencia podrá incrementar un riesgo importante en las fechas de las actividades subsecuentes.
·
En 1997, el físico israelí Eliyahu Goldratt 23 publicó su best seller Critical Chain (Cadena Crítica) que aportaba una técnica innovadora que permitiría completar los proyectos en un tiempo significativamente más corto que utilizando las técnicas tradicionales de administración de proyectos. El método de la cadena crítica es considerado por muchos autores como la evolución del método del camino crítico, y podremos conocerlo en profundidad, en la sección 6.5.1.2 de este capítulo.
6.2.1.5 Determinación de dependencias (Dependency determination) Para determinar la secuencia entre actividades, se pueden emplear tres tipos de dependencias:
·
Dependencias obligatorias: Son las dependencias consideradas contractualmente obligatorias o inherentes a la naturaleza del proyecto. El equipo del proyecto determinará qué dependencias son las obligatorias, durante el proceso de establecimiento de secuencia de las actividades. Un ejemplo de dependencia obligatoria es la construcción de un edificio, donde es imposible erigir su estructura hasta que no se realicen las labores de excavación.
193
•
Dependencias discrecionales: En este caso, el equipo del proyecto podrá establecer las dependencias de las actividades libremente, aunque es prudente hacerlo de acuerdo con la experiencia obtenida de proyectos similares de éxito u obedeciendo el estándar de las mejores prácticas del sector. Este tipo de dependencias deben estar bien documentadas, pues sus resultados podrán definir estándares internos para proyectos futuros similares de la organización, además de ser una importante fuente de consulta de “lecciones aprendidas”.
• Dependencias externas: Son dependencias que implican una relación entre las actividades del proyecto y aquellas que no pertenecen al proyecto, y por ello se encuentran parcial o totalmente fuera de control de la organización. Podrán depender de la ejecución de un profesional o empresa externo a la organización, o en algunos casos, dependerá también de la decisión y/o aprobación de la administración pública. Por ejemplo, la ampliación de un aeropuerto dependerá de la aprobación del presupuesto del Ayuntamiento o Junta correspondiente, o la puesta en marcha de una determinada maquina podrá depender de la entrega de algún componente fabricado fuera del país.
6.2.1.6 Aplicación de adelantos y retrasos (Applying leads and lags) Una lag es un retraso o un “tiempo de espera” entre actividades. En el ejemplo de la pintura, cuando se aplica la masilla, es necesario esperar un tiempo para que esta pueda secar, y a continuación empezar la pintura. Si establecemos un tiempo de secado de ocho horas, este será el lag entre una actividad y la posterior. La actividad “B” (pintar la pared), no podrá empezar hasta ocho horas después de completada la actividad “A” (aplicación de la masilla). Por otro lado, una lead es aceleración entre actividades. Una forma de “provocar” una lead es realizando dos tareas en paralelo, cuando normalmente deberían ser realizadas en secuencia. Por ejemplo, tras la aplicación de la masilla en la pared, se podría instalar la cornisa mientras se espera por el secado de la masilla y antes que empiece la pintura de la pared. Es decir, la actividad “C” (instalación de la cornisa) empezaría ocho horas antes de la actividad “B” (pintar la pared). De esta forma, el tiempo necesario para la ejecución y finalización de la actividad C seria absorbido por el tiempo de espera entre la actividad “A” y “B”.
6.2.1.7 Plantillas de red de cronograma (Schedule network templates)
Descrito en la sección 6.1.1.4
6.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto)
I
Diagramas de red del cronograma (Véase sección 6.2.1.1) (Project schedule network diagrams) 194
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
195
6.3 Estimación de los recursos de las actividades (Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste en estimar el tipo y las cantidades de recursos necesarias para ejecutar correctamente cada actividad de un proyecto. Como “recurso” podemos entender por ejemplo, materiales, personas, maquinaria, equipos informáticos y suministros en general.
6.3.1 Técnicas y herramientas 6.3.1.1 Juicio de expertos (Expert judgement)
Descrito en la sección 4.1.1.1
6.3.1.2 Datos de estimación publicados (Published estimating data) Muchas empresas publican periódicamente los costes unitarios de sus recursos para una amplia variedad de materiales y equipos en diferentes países. Es una fuente de información que aporta datos fiables para la estimación de recursos.
6.3.1.3 Estimación ascendente (Bottom-up estimating) Cuando una actividad tiene unas características que dificultan una estimación fiable, se utiliza la técnica de estimación ascendente que funciona de la siguiente forma: se descomponen los trabajos de esta actividad a un nivel mayor de detalle, y se estiman los recursos necesarios para ejecutar cada actividad individualmente. A continuación, se van totalizando los costes encontrados, cuya suma total corresponderá al coste total de la actividad. Para esta estimación es muy interesante utilizar la estructura detallada del trabajo - EDT (para más detalles, véase también la sección 5.3). La ventaja de esta técnica es que ella produce resultados bastante fiables. La desventaja es que estos resultados necesitan de un periodo de análisis considerablemente largo.
196
Se estiman los costes y las duraciones desde los niveles más bajos (paquetes de trabajo) Figura 68: Aplicación de la estimación ascendente en la EDT
6.3.1.4 Software de gestión de proyectos (Project Management Software) Para poder desarrollar una gestión de proyectos eficiente, el Project Manager debe hacer uso de sistemas y procedimientos que colaboren en la administración del proyecto junto con su equipo. Los últimos avances tecnológicos han contribuido bastante, ofreciendo en el mercado un amplio abanico de opciones de herramientas verticales, como los de gestión financiera, de plazos e incluso de recursos. El mercado dispone también de potentes aplicaciones de gestión de documentos que evitan la duplicación innecesaria de datos y la pérdida de información y que generan formatos profesionales para su publicación. Sin embargo, gestionar un proyecto no se limita solamente a utilizar aplicativos informáticos. No hay dudas de que el uso de una buena herramienta informática es fundamental para desarrollar un proyecto. No obstante, nada puede sustituir el sentido común, la experiencia y el juicio de expertos. Es importante tener claro que un software no puede:
·
Asegurar que la información es apropiada, actualizada y correcta: Durante el desarrollo del proyecto, los integrantes del equipo, registrarán datos técnicos y de gestión del proyecto en el sistema de información disponible por la organización. El Project Manager podrá revisar y formatear toda la información registrada, pero el programa no puede asegurar la fiabilidad de los datos imputados.
·
Tomar decisiones: Un programa informático puede perfectamente auxiliar el Project Manager a la hora de tomar decisiones, generando informes y una serie de resultados, pero no puede de forma alguna, decidir por él.
·
Crear y sostener relaciones interpersonales de forma dinámica: A pesar de que las personas son fascinadas por chat, e-mails, redes sociales y otros tipos de aplicaciones volcadas a las relaciones interpersonales, un programa no puede asegurar la fiabilidad de cualquier relación entre personas. Además, ningún programa tiene la habilidad de comunicar un mensaje de forma tan personal y dinámica, como las expresiones faciales y el lenguaje del cuerpo.
197
Por lo tanto, tenga en cuenta las limitaciones de una aplicación informática e intente sacar lo mejor que la tecnología puede ofrecer. Si has decidido utilizar un software de gestión integral es importante seguir las recomendaciones a continuación:
·
Programas utilizados pela organización: Verifique los programas que son utilizados por otros equipos de proyecto de la organización. Pregunte cuáles son los aspectos que ellos más valoran y qué prestaciones les gustaría tener.
·
Versión de demostración: Si ya sabes cual es el programa que pretendes adquirir, intente conseguir una versión de demostración, para poder explotarlo durante un periodo.
·
Prácticas: Una vez que tenga la versión de demostración instalada, intente crear proyectos sencillos. De esta forma será más fácil hacer un recorrido general por todas las funciones del programa.
·
Compatibilidad: Asegúrese que el producto es compatible con los sistemas existentes en la empresa. Verifique si el programa es capaz de generar los gráficos, informes o cualquier otro tipo de información que el proyecto necesite.
·
Formación: Matricúlese en algún curso de formación. Es importante establecer contacto con otras personas que conozcan el programa. Incluso, si posible, forme parte de algún foro de Internet. En los foros será posible conocer las ventajas y desventajas del programa, a través de la opinión de usuarios más experimentados.
198
Los softwares del Project Management más utilizados en el mercado son:
199
Open-Source desktop applications
· ·
KPlato (www.koffice.org)
· ·
TaskJuggler (www.taskjuggler.org)
· ·
OpenWorkbench (www.openworkbench.org)
· · · · ·
GANTT Project (http://ganttproject.biz)
Proprietary desktop applications
· ·
Artemis (http://www.svibs.com)
· · · · ·
Collanos Workplace (www.collanos.com)
·
Sophocles PM (www.mediafire.com/sophocles)
Bugzilla (www.bugzilla.org) dotProject (http://sourceforge.net/projects/dotproject) Eventum (https://launchpad.net/eventum) Mantis Bug Tracker (www.mantisbt.org) Project.net (www.project.net) ProjectPier (www.projectpier.org) Trac (http://trac.edgewall.org)
Proprietary web-based applications
Cerebral Project(TM) (www.cerebralproject.com) Microsoft Project (www.microsoft.com) Merlin (www.projectwizards.net/en/merlin) OmniPlan (www.omnigroup.com) Planisware OPX2 Pro (www.planisware.com)
Open-Source web-based applications
200
· · · · · · ·
24SevenOffice (http://24sevenoffice.com)
· · ·
Teamwork (www.twproject.com)
@task (www.attask.com) Basecamp (http://basecamphq.com) Central Desktop (www.centraldesktop.com) JIRA (www.atlassian.com/software/jira) Project Insight (www.projectinsight.net) ProjectHand (www.natara.com/projectathand2) Wrike (www.wrike.com) TOPdesk (www.topdesk.com)
6.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) §
DOC nº 012 – Requisitos de recursos de la actividad (Activity Resource Requirements)
§
DOC nº 013 – Estructura de desglose de recursos (Resource breakdown structure)
I] DOC nº 056 – Actualizaciones a los documentos del royecto (Project document updates)
201
6.4 Estimación de duración de actividades
(Proceso que corresponde a la fase de planificación del proyecto) La estimación de duración de actividades es el acto de cuantificar la cantidad de tiempo necesaria para finalizar una determinada actividad. Normalmente esta estimación se realiza sobre el esfuerzo dedicado a esta actividad en término de horas. De esta forma, si un trabajador está disponible las ocho horas diarias de su jornada laboral, sería muy sencillo realizar la estimación de sus actividades en un proyecto. Sin embargo, este tipo de circunstancia no suele ocurrir en el mundo real. Existen muchas variables que dificultan la realización de estimaciones fiables. Algunas de estas variables son:
·
Variables de conocimiento: Difícilmente un grupo de trabajadores tiene la misma capacidad de trabajo. Unos pueden tener más conocimientos o habilidades que otros.
·
Eventos inesperados: Eventos de la naturaleza como tormentas de nieve, lluvia, incluso huracanes pueden perjudicar el plazo de conclusión de una tarea. Otras incidencias pueden ocurrir, como por ejemplo, retrasos por parte de proveedores, problemas burocráticos, cortes de energía, entre otros.
·
Interrupciones: Las tareas que un trabajador desarrolla en un proyecto son frecuentemente interrumpidas por el teléfono, e-mail, reuniones, desayunos y charlas con los compañeros.
·
Equivocaciones: Es común que ocurran fallos que culminan en una tarea desarrollada de forma equivocada.
Dos trabajadores no realizan una actividad en la mitad de tiempo Otro detalle muy importante y que suele ocurrir con una cierta frecuencia es pensar que dos personas realizan una actividad en la mitad de tiempo. Consecuentemente, se podrá pensar que tres personas llevarán un tercio del tiempo, y así sucesivamente. En estas horas hay que tener en cuenta que dos madres no pueden generar un niño en cuatro meses y medio. Es una equivocación muy común pensar que se puede disminuir la ejecución de una actividad, añadiendo más recursos a ella. Es cierto que se nota una reducción, pero no en una escala lineal. Aumentar el número de trabajadores puede realmente reducir el tiempo de ejecución de una tarea, pero este tipo de medida también provoca un incremento de costes, que en algunos casos no compensa. El Project Manager deberá saber estimar el número correcto de recursos que pueden ser asignados a una tarea sin comprometer su duración y/o incrementar indebidamente los costes.
202
La curva de aprendizaje Existe un concepto llamado “curva de aprendizaje”, que es un modelo matemático que demuestra que la repetición de una determinada actividad conlleva a que su tiempo de desarrollo sea cada vez más reducido y consecuentemente sus costes también. Por ejemplo, el montaje de una misma máquina por la centésima vez será mucho más rápido y menos costoso que la primera vez. Es algo que el Project Manager deberá tener en cuenta a la hora de estimar duraciones.
203
Figura 69: Curva de aprendizaje
204
Algunos proyectos incluyen actividades muy familiares cuyas estimaciones son sencillas de realizar. No obstante, en muchos casos, hay un total desconocimiento de la duración necesaria para llevar a cabo una determinada tarea, sobre todo en proyectos innovadores. No importa cuál sea el caso, siempre será necesario realizar estimaciones considerando las variables descritas anteriormente. Algunas consideraciones importantes acerca de la estimación de duración de actividades:
·
Es importante tener como base el calendario laboral y estimar las duraciones en días laborales.
·
Verificar la existencia de festivos durante los periodos de ejecución del proyecto.
·
Las horas extra no se consideran.
·
El nivel de experiencia del personal es un factor importante a la hora de realizar estimaciones de tiempo.
·
Incluir las reuniones de revisión en los cronogramas. En muchos casos, las reuniones pueden llegar a consumir el 10% del tiempo total de un proyecto.
·
Considerar tiempos de viaje y desplazamientos;
205
•
Considerar la disponibilidad de infraestructuras (equipos informáticos, maquinaria, vehículos, entre otras).
•
Tener siempre en cuenta que los trabajadores necesitan formación, pueden estar asignados a más de un proyecto, cogen vacaciones y a veces solicitan bajas médicas por problemas de salud.
6.4.1 Técnicas y herramientas 6.4.1.1 Juicio de expertos (Expert judgement)
Descrito en la sección 4.1.1.1
6.4.1.2 Estimación analógica (Analogous estimating or top-down estimates) Cuando el equipo se reúne para determinar la duración de las actividades del proyecto, hay casos en que no se dispone de información suficiente para poder realizar las estimaciones correctas. En este caso, se utiliza la estimación analógica, que es una técnica utilizada para determinar la duración de una determinada actividad, basándose en otra actividad similar que ha sido desarrollada en un proyecto anterior. Las organizaciones que desarrollan proyectos muy parecidos cuentan con una base de datos que contiene información valiosa que puede ser aprovechada en otros proyectos y con ello reducir el tiempo de reuniones para estimación de duraciones. Esta herramienta suele ser menos costosa que otras técnicas, pero también es menos precisa. Sin embargo, puede ser considerada fiable cuando los proyectos anteriores comprenden un contenido realmente similar y los encargados por realizar las estimaciones son profesionales con experiencia.
206
El mantenimiento de un archivo de los proyectos realizados permitirá a la empresa disponer de una inagotable y valiosa fuente de información que aportará estimaciones fiables, como es el caso de la estimación analógica. No obstante, es importante tener en cuenta que los datos aportados por un proyecto de características similares no pueden ser 100% aplicables a un nuevo proyecto, puesto que, en cualquier caso, siempre habrá diferencias que deberán ser consideradas. Vamos suponer que en un proyecto anterior, la empresa ha construido un puente de cinco kilómetros en dos meses. El siguiente proyecto prevé la construcción de otro puente que presenta las mismas características del anterior, con una única diferencia que este tendrá una extensión de veinte kilómetros. Haciendo una estimación analógica, se podría estimar un plazo de ocho meses para concluir este proyecto. No podemos dejar de considerar que existen otras variables a parte del puente. Por ejemplo, el puente anterior fue construido en verano y el nuevo será construido en invierno. Las condiciones climáticas de las estaciones del año tienen un peso importante a la hora de estimar los plazos del proyecto. Además, el puente anterior se construyó sobre un terreno previamente asfaltado y en este nuevo proyecto, el terreno se encuentra en el medio de una zona boscosa, sin haber recibido todavía ningún tratamiento previo. Como se pudo apreciar, la eficacia de la estimación analógica depende severamente de las similitudes de dos proyectos, con lo que es fundamental realizar una comparación a fondo de todas las características de ambos proyectos.
6.4.1.3 Estimación paramétrica (Parametric estimating) Esta técnica utiliza una relación estadística entre datos históricos y otras variables para calcular los costes de un recurso en una determinada actividad del proyecto (ejemplo: metros cuadrados en la construcción, líneas de códigos en desarrollo de software, lauda de texto traducido...). Es una herramienta que puede producir resultados muy fiables, dependiendo de la complejidad del proyecto y de la cantidad de información conocida.
207
6.4.1.4 Técnica de evaluación y revisión de programas (Program evaluation and review technique - PERT) Inventada en 1958, la técnica de revisión y evaluación de programas (program evaluation and review technique - PERT) es un método utilizado en el análisis de las tareas que forman parte de un proyecto, sobre todo cuando existe un grado importante de incertidumbre en relación a sus duraciones. También es conocida como three-point estimating. El PERT realiza tres estimaciones para cada actividad:
· · ·
PesimistaTP: define el mayor tiempo que puede durar una actividad. OptimistaTO: define el menor tiempo que puede durar una actividad. Más probableTM: define el tiempo más probable que puede durar una actividad.
La fórmula utilizada con el PERT es la siguiente: (O + 4M + P) / 6 O = Es la estimación optimista para la duración de una determinada tarea. M = Es la estimación más probable para la duración de una determinada tarea. P = Es la estimación pesimista para la duración de una determinada tarea.
Figura 70: Gráfico PERT Estadísticamente, esta fórmula tiende a la estimación a más probable, pero permite algunos ajustes para acomodar los extremos mínimos y máximos. En la tabla que hay a continuación se ha aplicado la formula PERT en tres actividades. En el caso de la actividad “A” se ha estimado una duración optimista de siete días. En el caso en que surgiera algún tipo de incidencia, la duración podría llegar a catorce días. En condiciones normales la tarea “A” consumiría probablemente nueve días. Aplicando la formula PERT, se ha llegado a una duración ajustada de diez días, que añade tres más que la estimación más optimista, pero que no alcanza los catorce días resultantes de una estimación pesimista. 208
ACTIVIDAD
OPTIMIS TA
A
7
MÁS PROBAB LE 9
14
DURACI ÓN AJUSTA 10
B
10
20
27
19
C
13
20
32
21
PESISMISTA
Figura 71: Tabla PERT
¿Cuánto tiempo se lleva para pescar un pez? Es una pregunta muy difícil de responder. En algunos casos, puede llevar un minuto y a veces un pescador puede volver a casa con las manos vacías después de pasar todo un día a la orilla del río. Es muy difícil realizar estimaciones, y cuando se estiman las duraciones de un proyecto, normalmente se llega a resultados equivocados. Para que un PERT pueda aportar el resultado más fiable posible, es muy importante que las duraciones optimistas, pesimistas y más probables sean muy bien definidas. Para llegar a un número adecuado, se recurren a los recursos que se expresan a continuación.
6.4.1.5 Base histórica de proyectos (Historical records) Un proyecto finalizado correctamente es un proyecto bien documentado. Proyectos que cuentan con una buena documentación pueden guardar informaciones importantes, como, por ejemplo, las estimaciones de las actividades realizadas para su desarrollo. Hay casos en que se encuentran estimaciones muy sofisticadas con datos que pueden incluir, además de las duraciones, las características de las actividades y los conocimientos necesarios para realizarlas. La base histórica de proyectos puede incluir:
•
Tareas: Muchos proyectos pueden tener actividades muy similares e incluso idénticas. Consultar cómo se ha realizado el desarrollo de estas tareas en proyectos anteriores similares puede ser una forma eficaz de realizar nuevas estimaciones.
209
•
EDT: Es una herramienta de descomposición del trabajo realizado en un proyecto, orientada a los entregables del mismo, que organiza y define su alcance (para más detalles, véase también la sección 5.3).
·
Informes: Si la comunicación de un proyecto ha sido correctamente desarrollada, una serie de informes de seguimiento deberían haber sido distribuidos a todos los interesados a lo largo de su ciclo de vida. Estos informes suelen aportar información útil a proyectos futuros, ya que describen posibles problemas encontrados durante el desarrollo de sus actividades y propone las medidas preventivas o correctivas tomadas en su momento.
·
Estimaciones: En muchos casos, se podrán encontrar en proyectos anteriores actividades similares. Las estimaciones realizadas pueden aportar informaciones que pueden ser utilizadas en el proyecto actual.
·
Planes de proyecto: El plan de proyecto es un documento formal y aprobado por la dirección y es utilizado principalmente para la administración del proyecto de forma general. Se puede aprovechar mucha información de un plan de proyecto similar desarrollado anteriormente y aplicar varias de sus estimaciones en el plan de proyecto actual.
Lecciones aprendidas: (descrita en el Apéndice A, doc nº 054). ·
Riesgos: El nivel de riesgo de un proyecto dependerá sobre todo de la cantidad de información disponible. De cuanta más información disponga el equipo, menor será el riesgo, ya que el nivel de incertidumbre será reducido.
·
Recursos necesarios: Si un proyecto anterior cuenta con una buena documentación de gestión de recursos, ciertamente esta documentación incluirá los procesos, las técnicas, las herramientas y la documentación utilizada para realizar el uso efectivo de las personas involucradas.
6.4.1.6 Juicio de expertos (Expert judgement)
Descrito en la sección 4.1.1.1
6.4.1.7 Técnica delphi (Delphi technique) La técnica delphi es una metodología de investigación multidisciplinar para la realización de pronósticos y predicciones. Fue desarrolla por la Corporación Rand al inicio de la Guerra Fría para investigar el impacto de la tecnología en la guerra. El nombre del método se basa en las predicciones del Oráculo de Delfos.
210
Su objetivo es la consecución de un consenso basado en la discusión entre expertos. Esta técnica puede producir buenas estimaciones, y elimina un problema común que suelen ocurrir en las secciones de tormenta de ideas (brainstorming, véase también sección 11.2.1.8), como la timidez o la sensación de intimidación por parte de algún participante. Utilizando la técnica delphi, los participantes pueden contar con el anonimato, una vez que la recogida de opiniones puede ser realizada a través de chat o por e-mail, lo que también añade la ventaja de poder incluir personas de distintas localidades. En esta técnica, un facilitador (por ejemplo, el Project Manager), solicita a los participantes que aporten ideas acerca de los riesgos de un determinado evento. El facilitador recoge todas las ideas enviadas y la centraliza en un listado, que será reenviado a todos los participantes, para que estos puedan añadir más información sobre la lista anteriormente estructurada. Esta lista circulará hasta que no se generen ideas nuevas. La ventaja principal de esta técnica es que recoge la opinión sobre el proyecto actual basada en experiencias anteriores difíciles de evaluar por otros medios (características especiales del personal, peculiaridades del proyecto...).
6.4.1.8 Reserva de tiempo (Contingency time) Cuando se estiman duraciones de actividades, se intenta buscar el plazo más próximo a la realidad, y eso puede ser posible utilizando algunas de las técnicas mencionadas anteriormente. Sin embargo, aunque se estime correctamente la duración de una actividad, es común añadir una cantidad de tiempo extra, por si acaso surge alguna incidencia no esperada. Existe una teoría llamada ley de Parkinson (Parkinson´s law), creada por Cyril Northcote Parkinson 22 en un artículo publicado en el semanario británico The Economist en 1955 que dice: “El trabajo se amplia para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de seis días y se añaden dos más como contingencia, según la ley de Parkinson, esta tarea llevará ocho días para ser completada. Por supuesto, esta teoría no pretende derrumbar la técnica de la reserva de tiempo, pero intenta demostrar que no será simplemente añadiendo un par de días más a cada tarea, que se alcanzará el cronograma perfecto; todo lo contrario, esta práctica puede tornarse un vicio que convertirá el proyecto en un emprendimiento interminable. La reserva de tiempo o contingencia debe ser utilizada de forma correcta para realmente ser eficaz. Y eso se hace de la siguiente forma: de acuerdo con el tipo de proyecto se añade un porcentaje de tiempo extra al final del proyecto, que será utilizado en tareas que ultrapasen el plazo estimado de conclusión. Este porcentaje puede variar entre el 5% y el 10% del tiempo total estimado de finalización de todo el proyecto. Se utilizará el 5% en proyectos cuyo grado de incertidumbre es bajo y el 10% cuando se utilizan, por ejemplo, nuevas tecnologías. Una vez que se determine el plazo total del proyecto, se creará una tarea que será la “reserva de tiempo” y que tendrá como duración el porcentaje necesario de tiempo extra. Esta tarea será la última tarea del proyecto. De esta forma, las actividades del proyecto contarán con un plazo estimado real sin reservas, y el equipo del proyecto reunirá los esfuerzos necesarios para cumplir con cada plazo determinado.
211
Imaginemos un proyecto en que se estiman ciento veinte días para su conclusión. Se le añade un 10% de reserva (es decir doce días más). El proyecto tendrá un plazo final de ciento treinta y dos días. Si una determinada tarea consume dos días más que el originalmente previsto, se descontará dos días de la reserva, que pasaría a contar con diez días. Esta técnica permite que el Project Manager pueda gestionar la reserva disponible de forma más dinámica. Si un proyecto ha completado el 35% de sus actividades, pero ya ha consumido la mitad de la reserva, ya se sabe con mucha antelación que el proyecto no avanza según el plan. Estimar correctamente un tiempo adecuado de contingencia no es una labor muy sencilla. No obstante, es posible llegar a un valor muy aproximado, obedeciendo algunos principios básicos:
·
Cuanto más largo y complejo el proyecto, más tiempo de contingencias será necesario.
·
La contingencia aplicada deberá ser proporcional al riesgo del proyecto.
·
El tiempo de contingencia podrá ser reducido si el proyecto en marcha es muy similar a algún proyecto anterior.
·
Se podrá tomar como base el nivel de experiencia del equipo a la hora de decidir la cantidad de contingencia que será utilizada.
Existe una técnica llamada gestión de proyectos por cadena crítica, descrita en la sección 6.5.1.2, que aporta más informaciones sobre la gestión de las contingencias de un proyecto.
6.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Estimación de la duración de la actividad (Véase 6.4) (Activity duration estimates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
6.5 Desarrollo del cronograma del proyecto (Proceso que corresponde a la fase de planificación del proyecto) El desarrollo del cronograma es un proceso que consiste en analizar las actividades establecidas para un proyecto, su duración, los recursos necesarios y las restricciones identificadas. La incorporación de todas estas informaciones generará un cronograma con fechas planificadas que deberán ser cumplidas. El desarrollo de un cronograma es una de las tareas clave de un proyecto y podrá exigir el repaso y una revisión en profundidad de los tiempos de duración estimados de cada actividad y de los recursos necesarios para su correcta puesta en marcha. Es importante recordar que un cronograma es un documento que necesita de un seguimiento constante para mantenerse realista y sostenible. 212
6.5.1 Técnicas y herramientas 6.5.1.1 Método del camino crítico (Critical path method – CPM)
Descrito en la sección 6.2.1.4
6.5.1.2 Gestión de proyectos por cadena crítica (Critical chain Project Management- CCPM) Presentada por el físico israelí Eliyahu Goldratt 23 en 1997 en su libro Critical Chain, la gestión de proyectos por cadena crítica (Critical Chain Project Management - CCPM) está basada en algoritmos de su teoría de las restricciones* y se acredita que su técnica es capaz de reducir los costes y plazos entre un 10% y un 50% más que los métodos tradicionales. Esta técnica ha sido desarrollada para solucionar uno de los vicios más recurrentes del Project Management, que es la adición de tiempo innecesario a la ejecución de una tarea, observada en varios proyectos, incluso los de alto nivel. A la hora de realizar las estimaciones de duración de una determinada tarea, existe una tendencia natural a añadirle más plazo de lo necesario como forma de protección frente a la incertidumbre. Esta protección nos permitirá finalizar la tarea dentro del plazo estimado, incluso en los casos más desfavorables. La figura 72 ilustra cómo solemos realizar nuestras estimaciones de tiempo de ejecución de tareas:
Figura 72: Estimaciones de tiempo con colchón de seguridad
Como se puede apreciar en la figura 72, una tarea recibe un colchón de seguridad de tiempo que muchas veces puede ser del orden del doble de lo que sería la duración media de la tarea. Si aplicamos esta regla a todas las actividades de un proyecto, su tiempo total de finalización sería el doble, es decir, si una obra contiene tareas que normalmente consumen veinte días de ejecución, aplicando colchones de seguridad a todas las actividades del proyecto, la obra tendría un plazo total de cuarenta días para finalizar. El colchón de seguridad nos permite, entonces, terminar el proyecto dentro del plazo, ya que nos ha añadido el doble del tiempo necesario para su ejecución. 213
No obstante, lo que se ve es que el proyecto, por más colchones de tiempo que se añadan, terminará retrasado de la misma forma. Esto ocurre debido a una teoría conocida como la “síndrome del estudiante” (student syndrome), en el que una persona comenzará a esforzarse en la finalización de una actividad faltando muy poco para el vencimiento de su plazo. La consecuencia principal de esta actitud es la pérdida de cualquier imagen de tiempo establecido en la fase de estimación de tiempo de ejecución de actividades. La figura 73 nos ilustra cómo se administra de forma equivocada el esfuerzo dedicado a una actividad. Prácticamente, durante el 70% del tiempo asignado a esta actividad, el nivel de esfuerzo ha sido mínimo, elevándose sustancialmente en el 30% del tiempo disponible.
Figura 73: Síndrome del estudiante
Lo primero que la cadena crítica pretende defender es la idea de que añadir colchones de seguridad a todas y cada una de las tareas no tiene ningún sentido. Este tipo de actitud nos lleva a preocuparnos por terminar cada tarea a tiempo, cuando lo que realmente importa es finalizar el proyecto en el plazo previsto. La cadena crítica tiene una filosofía totalmente opuesta: trata de gestionar exactamente la imposición del plazo mínimo en que un proyecto puede ser realizado. Se puede definir entonces la cadena crítica como la secuencia de tareas más corta teniendo en cuenta los conflictos de recursos. A través de la tabla que presento a continuación podemos comparar los conceptos de la cadena crítica con las técnicas de gestión tradicionales:
214
MÉTODO DE LA CADENA CRÍTICA Protege la finalización total del proyecto con buffers.
MÉTODO TRADICIONAL Protege las tareas individualmente con buffers de seguridad.
Énfasis en la evolución del proyecto. Inicio de las actividades solamente cuando sea necesario.
Énfasis en la evolución de la tarea. Inicio de realización de tareas lo más temprano posible.
Minimización de la realización de múltiples tareas a través de la distribución de prioridades.
Realización de múltiples tareas. Reacción a las incertidumbres a través del cambio de prioridades, estableciendo nuevos horarios.
Gestiona la incertidumbre monitorizando el impacto de los hechos en el consumo de los buffers.
Figura 74: Método de la cadena crítica x método tradicional
El método de la cadena crítica es considerada como uno de los más importantes avances en el Project Management en los últimos treinta años y tiene su origen en la teoría de las restricciones (véase también “nota del autor”, al final de esta sección). De acuerdo con Goldratt 23, las previsiones de las estimaciones son normalmente aportadas por personas distintas, que, en algunos casos, no tienen acceso a toda la información del proyecto, causando una cierta incertidumbre que, naturalmente, les motivará a añadir un colchón de seguridad muchas veces innecesario. La cadena crítica, por lo tanto, sugiere que se planifiquen las actividades estimando sus duraciones de forma agresiva, reduciendo el tiempo hasta un nivel que permita la realización de su ejecución sin comprometer su calidad. ACTIVIDAD A Duración estimada
Colchón
ACTIVIDAD B Duración estimada
colchón
ACTIVIDAD C Duración estimada
colchón
Figura 75: Tabla con las actividades y sus colchones de seguridad
ACTIVIDAD A Duración estimada
ACTIVIDAD B
ACTIVIDAD C
Duración estimada
Duración estimada
COLCHÓN
Figura 76: Tabla con las actividades y sus colchones de seguridad dispuesta al final del cronograma.
Este tipo de estrategia permite eliminar una serie de colchones de seguridad añadidos innecesariamente que “inflan” el proyecto, volviéndole más manejable y con estimaciones más realistas.
215
* La esencia de la teoría de las restricciones se basa en cinco puntos:
1. 2. 3. 4. 5.
Identificar las restricciones del sistema. Decidir cOmo explotarlas. Subordinar todo a la decisiOn anterior. Superar la restricciOn del sistema (elevar su capacidad). Si en los pasos anteriores se ha roto una restricciOn, regresar al paso 1.
Para conocer en profundidad la metodología de la cadena crítica, consulte la obra de Eliyahu M. Gold ratt23 Cadena Crítica – Una novela empresarial sobre la gestión de proyectos, editorial Díaz de Santos.
6.5.1.3 Nivelación de recursos (Resource leveling) Una de las grandes dificultades en el Project Management es asegurar que el trabajo ha sido asignado al equipo de forma equilibrada. Si no se logra realizar una adecuada gestiOn de los recursos del proyecto, se darán casos donde algunos integrantes estarán sobrecargados, mientras otros tendrán demasiado tiempo ocioso. La nivelaciOn de recursos es una técnica utilizada para evaluar el uso desequilibrado de recursos y resolver sus conflictos y/o asignaciones equivocadas. Actualmente la mejor forma de de utilizar esta herramienta es a través de programas informáticos dedicados que son capaces de administrar escenarios complejos donde se ejecutan múltiples proyectos a la vez. Cruzando las informaciones de los calendarios de los proyectos y del personal, es posible determinar la cantidad Optima de mano de obra disponible en cada momento del proyecto.
6.5.1.4 Análisis “¿Qué pasa si...?” (What-if scenario analysis WISA) El análisis WISA (¿Qué pasa si...?) es una técnica que utilizamos en nuestro cotidiano, con cuestiones tan sencillas como la que presento a continuaciOn: Su novia le pide que la lleve al cine este viernes y, como trabajas hasta tarde, decides llevarla a la última sesiOn, que empieza a las once de la noche. De súbito, te haces la siguiente reflexiOn: “¿Qué pasa si llegamos al cine y no quedan entradas disponibles?”. 216
La respuesta a esta pregunta deberá ser una o más soluciones alternativas, por ejemplo: “Si no quedan más entradas, la llevo a cenar a su restaurante favorito”. Este tipo de situación se repite decenas de veces en el Project Management. La pregunta “¿Qué escenario podríamos tener sí ocurre una determinada situación?”. El mercado dispone de un gran abanico de herramientas informáticas WISA, que son capaces de crear varios escenarios para determinadas cuestiones relacionadas con costes, plazos, cambios y riesgos en general.
Las herramientas que realizan análisis WISA necesitan de una cantidad importante de información, para poder realizar un análisis eficaz. Por ello, es importante que se introduzcan los siguientes datos:
·
La creación de un escenario actual, que será el punto de partida para un análisis “¿Qué pasa si...?”.
·
Determinar los valores y variables que harán cambiar los escenarios contemplados.
·
Determinar los recursos disponibles para cada escenario sugerido.
Una herramienta muy similar al WISA, es el método de los escenarios, descrita detalladamente en la sección 11.3.1.4.
6.5.1.5 Aplicación de adelantos y retrasos (Applying leads and lags)
Descrita en la sección 6.2.1.6
217
6.5.1.6 Ejecución rápida (Fast Tracking) La técnica de la ejecución rápida significa poner en ejecución dos o más actividades en paralelo, en vez de ejecutarlas secuencialmente. Lógicamente, esta técnica no se puede aplicar en todos los casos, por ejemplo, no se puede levantar un tabique y pintarlo a la vez, pero utilizando correctamente la técnica de la ejecución rápida se podría ir pintando las partes del tabique que ya están listas para la pintura, en vez de esperar a que todo el tabique esté completamente construido. Sin embargo, este tipo de técnica tiene un riesgo involucrado que puede provocar un incremento de coste y plazo, si ocurre algún imprevisto. Por esta razón, es muy importante tener la actividad muy bien planificada, para poder aplicar esta técnica con los riesgos mitigados.
Algunos autores estiman que en algunos casos se puede aplicar la ejecución rápida de la siguiente manera: la segunda actividad puede empezar a ser ejecutada cuando la actividad anterior esté al 66% completada. Este sería el porcentaje más conservador y de menor riesgo involucrado para poder aplicar la ejecución rápida. Sin embargo, cada proyecto tiene su naturaleza y características propias que pueden exigir un porcentaje de trabajo realizado más alto.
6.5.1.7 Compresión (Crashing) En el Project Management, el término “compresión” (crashing) significa reducir las actividades del camino crítico con el objetivo de terminar el trabajo antes del tiempo previsto, o en el peor de los casos, en el tiempo originalmente previsto (cuando se aprecia la posibilidad de que el trabajo podría terminar con retraso). Una de las formas más comunes de aplicar la compresión es añadiendo trabajadores a una o más actividades del camino crítico. Si un trabajador está trabajando en una tarea que necesita de diez horas para ser completada, y existe una necesidad de completarla en menos tiempo, se añade un segundo trabajador, que posibilitaría la reducción del plazo original de diez horas estimado para la ejecución de esta actividad. Los recursos añadidos en un proyecto pueden venir de la propia plantilla de la empresa o pueden ser contratados de forma temporal. Esta técnica puede asegurar la entrega de un producto o servicio antes del plazo determinado, pero, sin embargo, implicará en costes añadidos, ya que se incrementan los recursos asignados para completarla en menos tiempo. De todas formas, muchas veces, la empresa prefiere asumir este incremento de costes, asegurando la entrega dentro del plazo. En el ejemplo que viene a continuación podemos ver una serie de actividades cuya duración estimada total es de cuarenta días.
218
Figura 77: Serie de actividades
SITUACIÓN ACTUAL DEL PROYECTO DURACIÓN (en días)
A
10
10.000
DURACI ÓN (en días) 5
B
10
5.000
C
10
D
5
E
5
TOTALES
40 horas
COSTE
APLICANDO LA “COMPRESIÓN”
ACTIVIDAD
COSTE
18.000
COSTE DIARIO DE LA COMPRESIÓN 1.600
5
7.000
400
10.000
5
15.000
1.000
15.000
2
22.000
3.500
5.000
2
40.000 euros
19 Horas
6.000 68.000 euros
500 7.000 euros
Figura 78: Aplicación de la compresión
Este tipo de técnica es muy utilizada en determinadas circunstancias en que el plazo final no puede ser, en ninguna hipótesis, postergado. En la década de los 90, muchas empresas de software tuvieron que afrontar el problema del año 2000, más conocido como el “efecto 2000” o “Y2K”. Sus aplicaciones informáticas corrían el riesgo de parar de funcionar si no se implantaban las correcciones necesarias antes de que terminara el año 1999. Bancos, empresas de telefonía y otras compañías de grande porte invirtieron millones de dólares para evitar que ocurriese una “catástrofe informática”, que felizmente no ha llegado a ocurrir. Los proyectos de desarrollo de aplicaciones informáticas que pretendían subsanar el “Y2K” tenían que tenerlo todo listo antes de que empezara el año 2000 y, para ello, el método de la compresión tuvo que ser puesto en marcha para lograr este objetivo. En la preparación de grandes eventos deportivos, como los juegos olímpicos o los mundiales de futbol, la técnica de la compresión es ampliamente utilizada.
Desventajas de la compresión:
·
Aumento de costes del proyecto: La compresión demanda más gente trabajando en una actividad, lo que conlleva a un incremento en los costes de mano de obra.
·
Aumento de los riesgos: La compresión conlleva a la gestión de una ejecución acelerada de trabajo, con más recursos añadidos en un plazo de tiempo reducido.
·
Cualificación del equipo: Cuando es necesario incluir más recursos de última hora, normalmente estos recursos disponibles no son los mejores cualificados. En algunos casos, será necesario darles algún tipo de formación.
219
•
Calidad: Tener que reducir la duración de la ejecución de una tarea, añadiéndole más trabajadores, que, además, podrán contar con la cualificación necesaria, provocará problemas de integración y comunicación entre el grupo, lo que podría comprometer la calidad de ejecución de la tarea.
6.5.1.8 Gráfico de barras de Gantt (Gantt chart) El gráfico de Gantt fue concebido por el ingeniero estadounidense Henry L. Gantt 24 durante la primera guerra mundial. En aquel entonces, Gantt buscaba resolver el problema de la programación de actividades, es decir, su distribución conforme un calendario, de manera que fuese posible visualizar de manera sencilla el periodo de duración de cada actividad, sus fechas de inicio y fin, y también el tiempo total requerido para la ejecución del trabajo. Este gráfico consiste en un sistema de coordinadas en que se indica un eje horizontal que representará una escala de tiempo definido en términos de unidad más adecuada al trabajo que se va a ejecutar: hora, día, semana o meses, y un eje vertical que constituye las actividades del proyecto. Ha sido desarrollado para presentar la información acerca del estado de un proyecto, de una forma fácil de comprensión, sobre todo a la hora de realizar comparaciones de datos estimados por datos realizados. A cada actividad se hace corresponder una línea horizontal cuya longitud es proporcional a su duración en la cual la medición efectúa con relación a la escala definida en el eje horizontal conforme se ilustra en la figura 79.
Figura 79: Gráfico de barras de Gantt
220
Características gráficas:
·
Cada actividad es representada mediante un bloque rectangular cuya longitud indica su duración. La altura carece de significado.
·
La posición de cada bloque en el diagrama indica las fechas de inicio y finalización de cada actividad de acuerdo con la escala de tiempo asignada.
La figura 80 representa una variación del gráfico de Gantt. La diferencia básica es el uso de triángulos en lugar de barras. En este tipo de Gantt, los triángulos con la punta hacia arriba representan la fecha de inicio de cada actividad y los triángulos con la punta hacia abajo, la fecha de conclusión de la tarea. Las fechas planificadas corresponden a los triángulos blancos y las fechas reales a los triángulos grises.
Figura 80: Variación del gráfico de barras de Gantt
Comparando la figura 79 con la 80 se podrá apreciar que ambos gráficos presentan la misma información. La tarea B, por ejemplo, ha empezado más tarde y su duración será mucho más larga que lo planificado. Lo mismo pasa con la tarea D. Las tareas E y F, de momento, siguen lo establecido por el plan.
Método constructivo Para construir un diagrama de Gantt se han de seguir los siguientes pasos:
·
Dibujar los ejes horizontal y vertical.
·
Escribir los nombres de las tareas sobre el eje vertical.
221
•
En primer lugar, se dibujan los bloques correspondientes a las tareas que no tienen predecesoras. Se sitúan de manera que el lado izquierdo de los bloques coincida con el instante cero del proyecto (su inicio).
• A continuación, se dibujan los bloques correspondientes a las tareas que sólo dependen de las tareas ya introducidas en el diagrama. Se repite este punto hasta haber dibujado todas las tareas. En este proceso se han de tener en cuenta las siguientes consideraciones: Las dependencias fin-inicio (finish-to-start) se representan alineando el final del bloque de la tarea predecesora con el inicio del bloque de la tarea dependiente.
Figura 81: Relación finish-to-start
Las dependencias final-final (finish-to-finish) se representan alineando los finales de los bloques de las tareas predecesora y dependiente. A B
Figura 82: Relación finish-to-finish
Las dependencias inicio-inicio (start-to-start) se representan alineando los inicios de los bloques de las tareas predecesora y dependiente. Figura 83: Relación start-to-start
La relación start-to-finish es la menos utilizada en un proyecto. La actividad predecesora debe empezar antes que finalice la actividad sucesora.
Figura 84: Relación start-to-finish
222
Cálculos El diagrama de Gantt es un diagrama representativo que permite visualizar fácilmente la distribución temporal del proyecto, pero es poco adecuado para la realización de cálculos. Por la forma en que se construye, muestra directamente los inicios y finales mínimos de cada tarea.
Ventajas y desventajas de los gráficos de Gantt Los gráficos de barras de Gantt se revelan muy eficaces en las etapas iniciales de planificación. No obstante, después de iniciada la ejecución de la actividad y cuando comienzan a efectuarse modificaciones, el gráfico tiende a volverse confuso. Cuando esto ocurre, normalmente se requiere la confección de un nuevo gráfico. Aún en términos de planificación, existe una limitación bastante grande en lo que se refiere a la representación de planes de cierta complejidad. En resumen, para la planificación de actividades relativamente simples, el gráfico de Gantt representa un instrumento de bajo coste y de extrema simplicidad en su utilización. Para proyectos complejos, sus limitaciones son bastantes serias, y fueron estas las que llevaron a ensayos que dieron como resultado el desarrollo del CPM, del PERT (véase también sección 6.4.1.4) y otras técnicas conexas. De todas formas, el gráfico de barras de Gantt es ampliamente utilizado por las organizaciones y se ha hecho muy popular por la simplicidad de su confección y su uso. Es fácil de hacer y de entender y, actualmente, está incorporado en los programas de planificación más utilizados del mercado. Su simplicidad es tan evidente, que incluso ni siquiera hace falta un ordenador o un software específico para confeccionarlo. Un papel, un lápiz y una regla son suficientes para poder sacar partido de esta herramienta.
6.5.1.9 Grafico de hitos (Milestones) Un hito es un punto del cronograma normalmente señalizando un evento importante del proyecto, como la conclusión de una determinada fase o la entrega de un módulo importante del proyecto. Los hitos no son actividades, es decir, no consumen tiempo, ni recursos, ni duraciones. Son tan solo un punto de referencia del proyecto.
223
Figura 85: Gráfico de hitos
6.5.2 Documentación generada en este proceso (Véase Apéndice A – documentos del proyecto) I DOC nº 014 – Cronograma del proyecto (Project schedule)
I Línea base del cronograma (Véase sección nº 2.1.3) (Schedule baseline)
I DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
6.6 Control del cronograma (Proceso que corresponde a la fase de control del proyecto) El control del cronograma es el proceso que realiza el seguimiento del estado actual del proyecto, el control de su avance y la gestión de los cambios realizados en su línea base. Los objetivos de este proceso son los siguientes:
· · · ·
Determinar el estado actual del cronograma del proyecto. Influir en los factores que generan cambios en el cronograma. Determinar que el cronograma del proyecto ha cambiado. Gestionar los cambios reales conforme suceden.
224
6.6.1 Técnicas y herramientas 6.6.1.1 Medición del rendimiento (Earned value management)
Descrito en la sección 7.3.1.1
6.6.1.2 Índice de desempeño del cronograma (Schedule performance index – SPI) El índice de desempeño del cronograma es la medida del avance logrado en un proyecto en comparación con el avance planificado. Básicamente, esta herramienta utiliza fórmulas matemáticas para determinar el grado de cumplimiento del cronograma establecido en la fase de planificación del proyecto. La fórmula utilizada para la obtención del SPI es la siguiente:
SPI = BCWP/BCWS Los resultados obtenidos traducen las siguientes situaciones:
· · ·
SPI=1: El proyecto está en el plazo previsto. SPI>1: El proyecto está adelantado. SPI<1: El proyecto está retrasado.
El BCWS (budgeted cost of work scheduled), es el “coste presupuestado del trabajo planificado” o valor planificado (PV). Significa el coste presupuestado de las tareas que se habían planificado terminar en esa unidad de tiempo. “¿Cuánto trabajo debería estar terminado?”. El BCWP (budgeted cost of work rerformed) es el “coste presupuestado del trabajo realizado” o valor ganado (EV). Significa el coste presupuestado de las tareas que realmente se han avanzado o terminado para cada periodo. “¿Cuánto trabajo está realmente terminado?”. Aunque el SPI puede ser utilizado de forma independiente, sus resultados aportan una información bastante más robusta cuando son agrupados a otras variables que forman parte de la EVM (earned value management), considerada como la herramienta de valoración de avance del proyecto más poderosa que existe en el ámbito del Project Management. La EVM es descrita en profundidad en la sección 7.3.1.1.
6.6.1.3 Software de gestión de proyectos (Project management software)
Descrito en la sección 6.3.1.4 225
6.6.1.4 Nivelación de recursos (Resource leveling)
Descrito en la sección 6.5.1.3
6.6.1.5 Análisis “¿Qué pasa si...?” (What-if scenario analysis)
Descrito en la sección 6.5.1.4
6.6.1.6 Aplicación de adelantos y retrasos (Applying leads and lags)
Descrito en la sección 6.2.1.6
6.6.1.7 Compresión del cronograma (Schedule compression)
Descrito en la sección 6.5.1.7
6.6.1.8 Sistema de control de cambios del cronograma (Schedule control change system)
Descrito en la sección 4.5.1.1
6.6.1.9 Planificación adicional (Aditional plan)
Descrito en la sección 5.5.1.3
226
6.6.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I Mediciones del desempeño del trabajo. Véase sección 7.3.1.1 (Work performance measurements)
I Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I DOC nº 039 – Solicitudes de cam bios (Change requests)
I DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates)
I DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
227
Capítulo 7 Gestión de costes Bienaventurado el que tiene talento y dinero, porque empleará bien este último Menandro 25, comediógrafo griego
228
Algunas cosas en las que NO puedes pensar acerca de la gestión de costes “Empezamos sin el presupuesto finalizado, luego nos adaptamos a lo que aprueben” Los proyectos se desarrollan en varios ámbitos, uno de ellos es el económico. Lamentablemente, y sobre todo en tiempos de crisis, puede volverse un área inestable donde suele predominar la incertidumbre, y por ello necesita de una dedicación especial. El presupuesto es, por lo tanto, una herramienta de planificación y control de los costes asignados al proyecto. Los cambios bruscos en el ambiente, las variantes en las disposiciones legales o los acontecimientos mercantiles inesperados pueden cam biar el proceso. “Podemos consumir más dinero en esta actividad, porque s6 que hay unas actividades donde sobra la pasta” La estimación de costes es una actividad fundamental en la gestión de costes. Se debe llevar a cabo con el mayor detalle posible, puesto que cualquier equivocación podría infraccionar el coste total del proyecto, lo que derivaría en el rechazo de su aceptación de desarrollo. De lo contrario, si falta dinero en el proyecto, su finalización no sería viable. Cuando “sobra la pasta” en alguna actividad, la estimación ha sido realizada de forma equivocada. Una actividad puede, como mucho, contar con una reserva financiera para emergencias. “El cliente es de con fianza, estoy seguro de que nos pagará en el plazo que establecimos con 6l en la cena de la semana pasada” Con los tiempos que corren, se vuelve muy arriesgado poner en marcha cualquier acción que dependa de posteriores pagos por parte de un cliente y/o proveedor sin ningún compromiso escrito. Cuando en una determinada actividad del proyecto no cabe el establecimiento de un contrato, se suele utilizar una “carta de compromiso”, que es un documento que se redacta para hacer constar un compromiso verbal, ya fuese un compromiso de pago de una deuda o cualquier otro tipo de compromiso previamente establecido informalmente.
Introducción La gestión de costes existe en cualquier organización de cualquier sector, aunque se trate de una organización sin ánimo de lucro, o incluso en nuestro propio hogar. Si no se hace una gestión adecuada de costes, cualquier entidad, profesional o familiar, se iría a la quiebra en poco tiempo. En muchos proyectos se asocia la gestión de costes a actividades aburridas que deberían estar exclusivamente asignadas al departamento financiero de la empresa. Esta gestión no se restringe solamente al seguimiento y control del presupuesto asignado al proyecto, sino que es fundamental para realizar un análisis financiero que permita tomar decisiones correctivas antes de que el proyecto empiece a generar costes superiores a los previstos. Este tipo de control forma parte de una de las responsabilidades fundamentales del Project Manager. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de costes de un proyecto incluye los procesos y actividades necesarias para estimar, presupuestar y controlar los costes de modo que se complete el proyecto dentro del presupuesto. Estos son: 229
• · ·
Estimar los costes. Determinar el presupuesto. Controlar los costes.
Factores que determinan la importancia de la gestión de costes:
·
La gestión de costes permite conocer el progreso real del trabajo realizado.
·
Mide fielmente el desempeño del equipo.
·
Permite auditar el progreso general del proyecto.
·
Permite comparar el coste realizado con el coste previsto y, por consiguiente, tomar las decisiones correctivas oportunas.
·
Proporciona referencias comparativas de precio, que después servirán para realizar compras por mejores ofertas.
·
Servirá como una importante base de consulta para presupuestar futuros proyectos similares.
Tipo de costes Estimar costes es especialmente difícil por la variedad de tipos que pueden afectar al proyecto y que no pueden ser olvidados. El coste directo es un gasto que está específicamente vinculado al proyecto. Las categorías presentadas a continuación son las más frecuentes:
·
Trabajo/mano de obra: Normalmente se calcula multiplicando el número de horas de trabajo por el coste por hora del recurso asignado. Suele ser el coste más alto del proyecto y puede incluir, además de los sueldos, los costes de admisión, costes contractuales, seguridad social, seguros, entre otros elementos.
·
Material y suministros: Incluyen los artículos comprados para ser consumidos durante la ejecución del proyecto.
·
Facilidades: Son incluidos si son utilizados solamente para el proyecto. Puede ser el alquiler de maquinaria o de una nave.
·
Formación: Es el gasto requerido para formar el equipo del proyecto. En algunas ocasiones podrá incluir la formación del cliente.
·
Viajes, dietas y costes diversos: Igual que las facilidades, son incluidas solamente si están vinculadas directamente al proyecto.
El coste indirecto es un gasto que está relacionado con el mantenimiento de las instalaciones, los 230
servicios generales y la organización como un todo. Estos costes pueden incluir:
231
• Beneficios complementarios: Son los costes asociados a los trabajadores, excluyendo el sueldo, como seguridad social, transporte, seguros u otros.
·
Facilidades: Son los costes requeridos para el entorno del proyecto. Pueden incluir alquiler, mantenimiento de la oficina, suministro de papelería, luz, agua...
·
Administrativo: Son los costes referentes a las nóminas del personal de apoyo: administrativo, contabilidad, marketing, compras, etcétera.
·
Coste de oportunidad: También conocido como “coste alternativo”, designa el coste de la inversión de los recursos disponibles en una oportunidad económica, a costa de las inversiones alternativas disponibles, o también el valor de la mejor opción no realizada. El término fue acuñado por Friedrich von Wieser26 en su obra Theorie der Gesellschaftlichen Wirtschaft (Teoría de la Economía Social).
·
Costes irrecuperables (sunk costs): Este tipo de coste incluye la cantidad de dinero que ha sido invertida antes del proyecto empezar. Este tipo de costes no son controlados por el Project Manager y no entran en ningún presupuesto del proyecto. Son costes a fondo perdido en que no se espera que sean recuperados y no afectan a los resultados financieros del proyecto.
7.1 Estimación de costes (Proceso que corresponde a la fase de planificación del proyecto) La estimación de costes implica en la realización de predicciones sobre la cantidad más probable de esfuerzo, tiempo y niveles de personal necesarios para el desarrollo de un proyecto. Estas estimaciones son importantes sobre todo para determinar la viabilidad de un determinado proyecto. Una estimación de costes bien realizada es fundamental, puesto que servirá como referencia para medir cuánto el presupuesto estimado está siendo consumido en función de los costes reales. Buenas estimaciones servirán también como base histórica para futuros proyectos similares. Si acaso, se observa que la curva de costes reales se va alejando de la curva presupuestada, el Project Manager podrá poner en marcha las acciones correctivas adecuadas, que básicamente son tres:
·
Si la variación del valor estimado real es cero o la diferencia es muy marginal, el plan podrá seguir avanzando tal cual ha sido planificado.
·
Si la variación es poco significativa, y puede recomponer cualquier perdida, el proyecto sigue, pero haciendo uso de sus reservas financieras.
·
Si la variación es muy importante, deberán hacerse nuevas estimaciones más adecuadas, o en el peor de los casos, evaluar si el proyecto sigue siendo económicamente viable.
232
7.1.1 Técnicas y herramientas 7.1.1.1 Juicio de expertos (Expert judgement)
Descrito en la sección 4.1.1.1
7.1.1.2 Estimación por analogía (Analogous estimating or top down estimates)
Descrita en la sección 6.4.1.2
7.1.1.3 Estimación ascendente (Bottom-up estimating)
Descrito en la sección 6.3.1.3
7.1.1.4 Estimación paramétrica (Parametric estimating)
Descrito en la sección 6.4.1.3
7.1.1.5 Técnica de evaluación y revisión de programas (Program evaluation and review technique PERT)
Descrito en la sección 6.4.1.4
7.1.1.6 Análisis de reserva (Reserve analisys) El análisis de reserva es una de técnica utilizada para el desarrollo de presupuestos y se aplica generalmente en proyectos que contienen un cierto grado de incertidumbre, y por ello puede contener algún riesgo. Por ejemplo, se puede incluir una reserva de contingencia por la falta de 233
conocimiento de los técnicos del proyecto acerca de una determinada tecnología. Este desconocimiento puede provocar retrasos en la entrega del producto. A medida que se dispone de información más precisa sobre el proyecto, esta reserva puede reducirse o incluso eliminarse. Las reservas de contingencia funcionan por lo tanto, como un colchón de seguridad para los casos en que la actividad consuma más recursos de lo planificado.
234
Todo proyecto debería contar con alguna reserva, independientemente del su grado de incertidumbre. Cualquier proyecto, incluso los más recurrentes, siempre estarán expuestos a alguna clase de riesgo, por lo tanto, el análisis reserva es una herramienta indispensable en el proceso de estimación de costes.
7.1.1.7 Software de estimación para la gestión de proyectos (Project management estimating software)
Descrito en la sección 6.3.1.4
7.1.1.8 Análisis de propuestas para licitaciones (Vendor bid analysis)
Descrito en la sección 12.2.1.2
7.1.1.9 Estructura detallada del trabajo EDT (Work breakdown structure - WBS)
Descrita en la sección 5.3
7.1.1.10 Estructura de desglose de costes EDC (Cost breakdown structure - CBS) En general, los costes de un proyecto se clasifican en categorías, de acuerdo con la organización establecida por la empresa. Estas categorías son los elementos que componen la estructura de desglose de costes – EDC, cuyo desarrollo veremos a continuación. Acorde con Wolter J. Fabrycky27 en su obra Análisis del Coste del Ciclo de Vida de los Sistemas, las principales categorías de costes son las siguientes (tomando como ejemplo una empresa de desarrollo de software):
·
Costes de investigación y desarrollo: Planificación inicial, análisis de mercado, investigación del producto, análisis de requisitos, diseño de ingeniería, datos y documentación de diseño, software, pruebas y evaluación de los modelos de ingeniería, y funciones de gestión asociadas.
·
Costes de producción y construcción: Ingeniería industrial y análisis de operaciones, producción (fabricación, montaje y pruebas), construcción de instalaciones, desarrollo del proceso, operaciones de producción, control de calidad y requisitos iniciales de apoyo a la logística (por ejemplo, apoyo inicial al cliente, producción de repuestos, producción de equipo de pruebas y apoyo...).
235
•
Costes de operación y apoyo: Operaciones del sistema o producto por parte del consumidor o usuario, distribución del producto (marketing y ventas, transporte y gestión de tránsito), y mantenimiento y apoyo logístico durante el ciclo de vida del sistema o producto (por ejemplo, servicio al cliente, actividades de mantenimiento, apoyo de abastecimiento, equipos de prueba y apoyo, transporte y manejo, datos técnicos, instalaciones, modificaciones del sistema, entre otras.).
·
Costes de retirada y eliminación: Eliminación de elementos no reparables a lo largo del ciclo de vida, retirada del sistema o producto, reciclaje de material y requisitos aplicables del apoyo logístico. La estructura de desglose del coste relaciona los objetivos y actividades con los requisitos de recursos de organización. Constituye una subdivisión lógica del coste por área de actividad funcional, elementos importantes del sistema, y/o una o más de las clases discretas de elementos comunes o semejantes.
Figura 86: Estructura de desglose de costes
El desarrollo de una correcta EDC ayudará el Project Manager a identificar todos los elementos de costes relevantes, además de proporcionar un medio para la asignación inicial de recursos, la vigilancia del coste y el control del coste. Sea cual sea su complejidad, una EDC debe tener las siguientes características básicas:
·
Deberán incluir todos los costes relevantes, incluidos los gastos internos.
·
Cada coste debe estar bien definido a fin de que todos los participantes tengan una clara comprensión de lo que se va a incluir en dicho coste.
·
Cada coste debe ser identificable con un importante nivel de información.
·
El desglose de costes debe ser estructurado de tal manera que permitan el análisis de áreas específicas.
·
El EDC debe ser compatible con los procedimientos contables utilizados por la empresa en su gestión financiera.
236
7.1.1.11 Tasas de recursos (Resources rates) Aplicando el concepto de tasas de recursos al proceso de estimación de costes es posible determinar el coste total de los recursos del proyecto. Vamos suponer que el proyecto necesite de cuatro programadores, dos técnicos de hardware y un Project Manager. Las tasas para cada uno de los integrantes de este pequeño equipo son:
· · ·
Programador: 80 euros/hora. Técnico de hardware: 90 euros/hora. Project Manager: 100 Euros/hora
El proyecto necesitará de cien horas de trabajo de los programadores, cincuenta horas de los técnicos de de hardware y ciento cincuenta horas de trabajo del Project Manager. Estos datos nos llevan a los siguientes costes: Programador: 80 euros/hora * 100 horas de trabajo * 4 programadores = 32.000 euros Técnico de hardware: 90 euros/hora * 50 horas de trabajo * 2 técnicos = 9.000 euros Project Manager: 100 euros/hora * 150 horas de trabajo * 1 Project Manager = 15.000 Euros Los costes de los recursos tendrán entonces un coste total de: 32.000 + 9.000 + 15.000 = 56.000 euros.
7.1.1.12 Técnica delphi (Delphi technique)
Descrita en la sección 6.4.1.7
7.1.1.13 Base histórica de proyectos (Historical Records)
Descrito en la sección 6.4.1.5
7.1.1.14 Plan de cuentas (Chart of accounts) Es un sistema numérico financiero utilizado para identificar cada elemento de la estructura detallada de trabajo – EDT y para monitorizar los costes del proyecto por categoría. El plan de cuentas es confeccionado de acuerdo con el plan de cuentas “maestro” desarrollado 237
por la organización y que contiene las principales actividades de todos los proyectos realizados por la empresa, de forma general (para más detalles, véase también doc nº 041, en el Apéndice A – Documentos del proyecto).
238
7.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Estimaciones de costes de las actividades (véase sección 7.1). (Activity cost estimates)
I
DOC nº 015 – Base de las estimaciones (Basis of estimates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
7.2 Establecimiento del presupuesto (Proceso que corresponde a la fase de planificación del proyecto) Este proceso consiste en sumar los costes estimados de todas las actividades individuales del proyecto para establecer la línea base de costes del proyecto, que incluirá todos los prepuestos revisados y aprobados, volviéndose, entonces, en el fondo financiero autorizado para el desarrollo del proyecto.
7.2.1 Técnicas y herramientas 7.2.1.1 Suma de costes (Cost aggregation) Las estimaciones de costes se suman básicamente a través de los paquetes de trabajo establecidos en la EDT del proyecto (véase también sección 5.3)
7.2.1.2 Análisis de reserva (Reserve analysis) Descrito en la sección 7.1.1.6
7.2.1.3 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
239
7.2.1.4 Relaciones históricas (Historical relationships) Las relaciones históricas son resultados obtenidos a través de estimaciones análogas (véase también la sección 6.4.1.2) y/o paramétricas (véase también la sección 6.4.1.3) de proyectos similares anteriores que podrán proporcionar modelos matemáticos que permitan preceder los costes totales de un nuevo proyecto.
7.2.1.5 Conciliación del límite del financiamiento (Funding limit reconciliation) El gasto de fondos siempre debe estar conciliado con los límites impuestos por el presupuesto o financiamiento del proyecto. Una variación entre estos límites y los gastos planificados podrán requerir una revisión del trabajo para regular dichos gastos.
7.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Línea base del desempeño de costes. Véase sección 7.3.1.1 (Cost performance baseline)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
7.3 Control de costes (Proceso que corresponde a la fase de control del proyecto) El cliente o el patrocinador que invierten una determinada cantidad de dinero en un proyecto esperan que los trabajos previstos consuman solamente el presupuesto establecido. Se pueden aceptar variaciones, puesto que es conocido que existen muchas posibilidades de que el proyecto sufra cambios en su alcance a lo largo de su ciclo de vida. Además, siempre pueden surgir eventos no esperados. El cliente puede aceptar variaciones financieras razonables, pero no aceptará variaciones financieras derivadas de una pérdida de control por parte de la empresa ejecutora del proyecto. Si la cantidad invertida sobrepasa en mucho el presupuesto original, en muchos casos el proyecto pierde su viabilidad, y finalmente podrá ser cancelado. El control de costes básicamente implica supervisar la evolución de costes para detectar cualquier variación con respecto al plan inicial y, con ello, poder efectuar acciones correctivas y/o preventivas para mantener los costes dentro de límites aceptables. La preocupación del Project Manager en esta gestión no serán propiamente las variaciones, pero sí la dimensión de estas variaciones y sus impactos que pueden llevar el proyecto a un estado muy crítico. La figura 87 ilustra la situación actual de un proyecto respecto a sus costes.
240
Figura 87: Evolución de los costes de un proyecto (planificado x realizado)
El seguimiento y control de costes de un proyecto puede ser realizado sencillamente, tal y como ilustra la figura 88, a continuación, donde se listan las actividades del proyecto. Se añaden el coste estimado (línea base), los costes realizados y los costes estimados para el futuro. El resultado es la variación de cada tarea, y la variación total, que en ejemplo, es negativo. TAREA A
COSTE ESTIMA DO 10.000
B
1.200
C E F
CONSUMIDO HASTA EL MOMENTO 5.200
COSTE PARA CONCLUSI 5.000
400
800
300
25
200
860
1.020
3.570
2.120
33.270
21.855
2.000 720 13.560
TOTAL Figura 88: Tabla de variaciones
241
ESTIMACI ÓN REVISADA 10.200 1.200 225
VARIACI ÓN -200 0 75
3.020
-2.160
2.840
730
35.415
-2.145
A pesar de poder proveer la situación financiera real de un proyecto, este dato aislado no representa mucho si no está integrado con la evaluación del cronograma del proyecto. De la misma manera, tampoco será de gran utilidad saber la cantidad de trabajo realizado sin considerar los costes adjudicados. La figura 84 indica que el proyecto consumirá 2.145 euros más de lo previsto. Quizás sea una variación aceptable. Sin embargo, estas cifras no nos dicen la cantidad de trabajo realizado ni tampoco el trabajo que queda por realizar, con lo que saber que la organización gastará 2.145 euros aparte es una información aislada que poco podrá aportar a los interesados en el proyecto. Para disponer de una estimación más realista, es necesario utilizar una herramienta que integre el coste y el cronograma. Esta herramienta se llama valor del trabajo realizado (EV – earned value) y será explicada en detalles a continuación, en la sección 7.3.1.1).
7.3.1 Técnicas y herramientas 7.3.1.1 Valor del trabajo realizado (EV: earned value) Como hemos podido comprobar, el Project Manager tiene que asumir una serie de responsabilidades para asegurar que el proyecto avance sin incidencias. Una de ellas, que posiblemente es la que mejor justifica la intervención de un Project Manager, es el seguimiento del proyecto. El seguimiento del proyecto no se resumen solamente a “echar un ojo”, pues debe incluir informes de estados, mediciones de avance, previsiones y tendencias. La información sobre el rendimiento del trabajo debería incluir además, la medida en que se está cumpliendo con los estándares de calidad, los costes incurridos o comprometidos, los plazos asumidos, entre otros asuntos. Adicionalmente, es apropiado realizar revisiones internas de una forma regular, así como organizar revisiones periódicas con todas las partes participantes en el proyecto. El análisis del valor ganado (earned value management - EVM) es actualmente el método más utilizado para la medición de desempeño de un proyecto por su facilidad en generar informes de estado de costes y plazo de forma integrada. Es, además, una forma eficaz de comunicar a los interesados del proyecto es estado del presupuesto y desempeño en el tiempo. Este análisis, por lo tanto, realiza la medición del estado del proyecto básicamente por medio de la respuesta de tres preguntas.
·
“¿Qué tanto trabajo se planificó?”. La respuesta corresponde al valor planificado (planned value - PV): Que representa el presupuesto definido y aprobado para realizar un determinado trabajo.
·
“¿Qué tanto trabajo actualmente se ha completado?”. La respuesta corresponde al valor ganado (earned value - EV): Que representa el presupuesto definido y aprobado para realizar un determinado trabajo. La suma de los costes previstos para las actividades finalizadas durante un periodo dado. 242
• “¿Qué tanto ha costado completar el trabajo actual?”. La respuesta corresponde al coste real (actual cost - AC): Que representa el valor financiero efectivamente consumido en la realización de un determinado trabajo durante un periodo específico de tiempo.
Caso práctico Un proyecto ha sido planificado para ser ejecutado en cuatro semanas por un presupuesto de 100.000 euros. A la tercera semana de ejecución, nos han informado de que se ha completado solamente el 50% del trabajo, cuando se debería haber realizado el 75%, acorde con el cronograma establecido. Nos informan además que el coste actual asciende a la cifra de 90.000 euros. ¿Cuál será el estado del proyecto en este momento?
Figura 89: Análisis del valor ganado
Por lo tanto, el valor planificado (PV) para este proyecto para el día de hoy debería ser la realización del 75% del trabajo planificado, por un coste de 75.000 Euros. El valor planificado (PV) se calcula multiplicando el porcentaje planificado por el presupuesto del proyecto, es decir: PV = Porcentaje planificado (%) * el presupuesto del proyecto = 75% x 100,000 = 75,000 Por otro lado, el valor ganado (EV) se calcula multiplicando el porcentaje actual completado por el presupuesto del proyecto, es decir: EV = Porcentaje ejecutado (%) * el presupuesto del proyecto = 50% * 100,000 = 50,000 El coste actual (actual cost) para lograr el 50% del proyecto es de 90.000 euros. El coste actual (actual cost) se calcula rastreando el coste contra el presupuesto del proyecto: AC = 90.000 euros
243
A través de estos cálculos, podemos determinar las variaciones de coste y cronograma del proyecto. La variación de coste (cost variance - CV): representa la diferencia entre el valor ganado (earned value – EV) y el coste real del proyecto (actual cost – AC). La variación de coste es encontrada utilizando la siguiente formula: CV = EV – AC. Si el resultado es mayor que cero (valor positivo), entonces tenemos una variación de coste favorable. Si el valor es menor que cero (valor negativo), podemos determinar que la variación de coste no es favorable. Una de las formas más sensatas de mantener una variación de coste favorable, es controlando disciplinalmente los costes del proyecto, además de controlar también el cronograma del proyecto, ya que cada hora trabajada tiene un coste vinculado. Variaciones de cronograma (schedule variance – SV): Es la diferencia entre lo que se ha previsto consumir en un determinado plazo y lo que efectivamente se ha consumido, que podrá definir si el proyecto está dentro o fuera del plazo. Su valor se puede obtener a partir de la siguiente formula: SV = EV – PV Aplicando las fórmulas de variaciones en nuestro ejemplo, encontramos los siguientes resultados: Variación del coste para este proyecto: CV= 50.000 – 9000 = - 40.000 euros Variación del cronograma para este proyecto: SV = 50.000 – 75.000 = -25.000 euros Al realizar estos cálculos, el Project Manager podrá determinar que el proyecto ha consumido el 90% de su presupuesto para completar solo el 50% del trabajo planificado. En otras palabras, este proyecto se encuentra retrasado en el cronograma y seguramente terminará por encima del presupuesto establecido. Será necesario ampliar el cronograma del proyecto y/o obtener fondos adicionales para completar el proyecto. Con todos estos datos, el Project Manager puede todavía determinar dos índices muy utilizados en Project Management, para la evaluación de desempeño de proyectos: Índice de desempeño del coste (cost performance index - CPI): Véase también sección 7.3.1.4. Es una medida del valor ganado de un proyecto comparada a los costes reales incurridos. Los resultados obtenidos traducen las siguientes situaciones:
· · ·
CPI=1: El proyecto está gastando lo previsto. CPI>1: El proyecto está gastando menos de lo previsto. CPI<1: El proyecto está gastando más de lo previsto.
Índice de desempeño del cronograma (schedule performance index – SPI): Véase también sección 6.6.1.2. Es una medida de progreso real del cronograma del proyecto. Los resultados obtenidos traducen las siguientes situaciones:
244
• · ·
SPI=1: El proyecto está en el plazo previsto. SPI>1: El proyecto está adelantado. SPI<1: El proyecto está retrasado.
Las fórmulas utilizadas para obtener los índices de coste y cronograma son las siguientes, respectivamente:
CPI = EV / AC SPI = EV / PV Si cogemos los números reales de nuestro ejemplo, obtendremos los siguientes índices: Índice de desempeño de coste: CPI = EV / AC 50.000 / 90.000 = 0.56 CPI = 0.56 Índice de desempeño del cronograma: 50.000 / 75.000 = 0.67 SPI = 0.67 Tal y como podemos apreciar, ambos índices son menores de uno, por lo tanto el proyecto necesita ser revisado. Si el proyecto sigue con esta tendencia, será necesario gastar 180.000 euros para completar el proyecto, cuando su presupuesto planificado era de 100.000 euros. Esta previsión de gasto de 180.000 euros se obtiene a través de otra variable llamada “estimación a la terminación” (EAC – estimate at complete), que calcula el total de los probables gastos al termino del proyecto, basado en los valores consumidos hasta el momento actual. Esta estimación es muy sencilla de ser realizada porque asume que los gastos que serán consumidos hasta la conclusión del proyecto serán los mismos consumidos hasta ahora. Claro, que las circunstancias futuras serán distintas a las ocurridas en el pasado. De todas formas, el EAC puede ser modificado de acuerdo con la evolución y los gastos del proyecto, para que su estimación sea actualizada y real. Más detalles en la sección a continuación (7.3.1.2 – Proyecciones).
245
El EAC es reflejado de forma gráfica, de la forma como ilustra la figura 90, que se muestra a continuación:
Figura 90: EAC
Para calcular la estimación a la terminación (EAC), se divide el presupuesto original por el índice de desempeño del coste (esta es la fórmula más básica, aunque hay otras formas de determinarlo). EAC = BAC/CPI = 100.000 / 0.56 EAC = 180.000 Con toda esta información disponible, ya podremos contestar a una serie de preguntas acerca del estado general del proyecto: ¿Estamos por debajo o por encima del presupuesto proyecto? CV: cost variance (desviación de coste) = EV - AC 50.000 – 9000 = - 40.000 euros Respuesta: El valor ganado ha sido menor que el coste planeado. El presupuesto real del proyecto está excedido. ¿Cómo de eficientemente estamos usando los recursos financieros del proyecto? CPI: cost performance index (índice de desempeño de coste) = EV / AC 50.000 / 90.000 = 0.56 Respuesta: El nivel de eficiencia en el uso de los recursos financieros no es bueno. Por cada euro invertido en el proyecto este genera en términos de valor solamente 0,56 euros. ¿Cuál es el coste más probable del proyecto? EAC: estimate at completion (coste estimado de terminación) = BAC / CPI 100.000 / 0.56 = 180.000 Respuesta: Indica que si la tendencia se mantiene a este ritmo de desfase, al finalizar las actividades del proyecto, este costará 180.000 euros.
246
Los valores negativos o positivos de coste y plazos indican que el proyecto no se desarrolla exactamente como determina el plan. Una vez determinadas las variaciones existentes, es hora de identificar los factores que están causando estas variaciones y poner en marcha las medidas correctivas adecuadas. Para ello, es muy indicado utilizar una herramienta de causa-efecto, como es diagrama de ishikawa (Para más detalles, véase también el punto 8.3.1.7).
7.3.1.2 Proyecciones (Forecasting) Conforme el proyecto avanza, el Project Manager irá disponiendo de informaciones que le permitirán desarrollar proyecciones muy útiles para la toma de acciones preventivas y/o correctivas. Una técnica de proyección muy utilizada es la “proyección de la estimación por la conclusión” (estimate at completion – EAC), que se define como: “El coste total esperado de una actividad o proyecto cuando todo el trabajo esté finalizado”, que, en algunos casos, pueden diferir de otro concepto de gestión de costes, conocido por “presupuesto hasta la conclusión” (budget at completion – BAC). Los datos obtenidos de la EVM pueden proporcionar varias EAC, según diferentes escenarios. A continuación, y acorde con el PMBOK®, se describirán tres de las más comunes:
·
Proyección de la EAC basada en el trabajo correspondiente a la ETC, realizado según la proporción presupuestada: Este método de EAC toma en cuenta el desempeño real del proyecto a la fecha (ya sea favorable o desfavorable), como lo representan los costes reales, y prevé que el trabajo según la ETC se llevará a cabo de acuerdo con el ratio presupuestado. Cuando el desempeño real es desfavorable, el supuesto de que el desempeño futuro mejorará debe aceptarse únicamente cuando está sustentado por un análisis de riesgo del proyecto. Ecuación: EAC = AC + BAC – EV.
·
Proyección de la EAC basada en el trabajo correspondiente a la ETC, realizado según el CPI actual: Este método supone que se espera que lo que el proyecto ha experimentado a la fecha continúe en el futuro. Se supone que el trabajo correspondiente a la ETC se realizará según el mismo índice del desempeño de coste (CPI) acumulativo en el que el proyecto ha incurrido a la fecha. Ecuación: EAC = BAC / CPI acumulativo.
·
Proyección de la EAC basada en el trabajo correspondiente a la ETC, realizado considerando ambos factores (SPI y CPI): En esta proyección, el trabajo correspondiente a la ETC se realizará según una proporción de eficiencia que toma en cuenta tanto el índice del desempeño de costes como el índice de desempeño del cronograma. Supone un desempeño de costes negativo a la 247
fecha y la necesidad de que el proyecto se comprometa firmemente a respetar el cronograma. Este método es tanto más útil cuanto el cronograma del proyecto es un factor que afecta el esfuerzo de la ETC.
248
Las variaciones de este método miden el CPI y el SPI según diferentes valores (por ejemplo, 80/20, 50/50 o alguna otra proporción), de acuerdo con el juicio del Project Manager. Ecuación: AC + [(BAC – EV) / (CPI acumulativo x SPI acumulativo)]. Cada uno de estos métodos puede ser adecuado para cualquier proyecto dado y proporcionará al equipo de dirección del proyecto una señal de “advertencia temprana” si las proyecciones para la EAC no están dentro de las tolerancias aceptables.
7.3.1.3 Índice de desempeño del trabajo por completar (To-complete perfomance index - TCPI) El TCPI es una proyección calculada del desempeño del coste que deberá lograrse para el trabajo restante, con el objetivo de cumplir con la meta establecida, tal como el BAC o la EAC. Según lo explicado en el punto anterior, cuando el BAC no se presenta viable, se proyecta entonces una EAC, que, una vez aprobada, sustituirá la BAC en vigor como meta de desempeño de costes. La ecuación para el TCPI basada en el BAC es: (BAC – EV) / (BAC – AC) Si el CPI acumulativo se presenta por debajo de la línea base del plan, todo el trabajo futuro tendrá que ser realizado inmediatamente en el rango de la TCPI para mantenerse dentro del BAC autorizado. Una vez que se reconozca que ya no es posible cumplir con el BAC, se preparará una nueva estimación a la conclusión (EAC), para el trabajo, y una vez aprobada, el proyecto utilizará el nuevo valor de la EAC. Este nivel de desempeño se muestra como la línea TCPI (EAC). La ecuación para el TCPI basada en la EAC es: (BAC – EV) / (EAC – AC).
7.3.1.4 Índice del desempeño del coste (Cost performance index - CPI) El índice del desempeño del coste (CPI) es una medida del valor del trabajo completado, en comparación con el coste o el avance real del proyecto. Es considerada la métrica más importante de la EVM (véase también sección 7.3.1.1) y mide la eficacia de la gestión del coste para el trabajo completado. La fórmula utilizada para la obtención del CPI es la siguiente:
CPI = EV / AC Los resultados obtenidos se traducen las siguientes situaciones:
· · ·
CPI=1: El proyecto está gastando lo previsto. CPI>1: El proyecto está gastando menos de lo previsto. CPI<1: El proyecto está gastando más de lo previsto.
Para poner un ejemplo sobre la aplicación de la CPI, vamos suponer que un determinado 249
trabajo tiene el valor de 750 euros (EV), pero ha costado en realidad 800 euros (AC). Esto quiere decir que cada euro consumido en este proyecto se ha pagado por un trabajo que valía 93,73 céntimos.
250
Por lo tanto, es un proyecto ha sido presupuestado en 10.000 euros, si dividimos en CPI encontrado de .9373, tendremos como resultado el valor total de 10.669 euros de coste real, o un sobrecoste de 669 euros.
Figura 91: Los índices del EVM
7.3.1.5 Software de gestión de proyectos (Project Management software)
Descrito en la sección 6.3.1.4
7.3.1.6 Planificación adicional (Aditional planning)
Descrito en la sección 5.5.1.3
7.3.1.7 Sistema de control de cambios de costes (Cost change control system)
Descrito en la sección 4.5.1.1
251
7.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Mediciones del desempeño del trabajo. Véase sección 7.3.1.1 (Work performance measurements)
I
Proyecciones del presupuesto. Véase sección 7.3.1.2 (Budget forecasts)
I
Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I
DOC nº 039 – Solicitudes de cam bio (Change requests)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
252
Capítulo 8 Gestión de la calidad “La calidad nunca es un accidente, siempre es el resultado de un esfuerzo de la inteligencia” John Ruskin28, escritor, poeta y crítico inglés
253
Algunas cosas en las que NO puedes pensar acerca de la gestión de la calidad “Si añadimos más funciones, la calidad del producto aumentará” Al principio, lo que suena como algo positivo podría provocar un gran dolor de cabeza. Añadir más elementos a un producto y/o servicio sin que el cliente los hubiera solicitado podría incrementar sustancialmente la probabilidad de riesgos en el proyecto, que, eventualmente, no finalizará dentro de los plazos y presupuestos establecidos. Y lo primero que el cliente dirá es que los problemas empezaron a partir del momento en que se ha decidido añadir elementos al producto. Al cliente se le debe entregar solamente lo solicitado. Añadir “extras” es una pérdida de tiempo y no aportará ningún beneficio al proyecto. Además, es importante recordar que el Project Manager debe respetar el enunciado del trabajo (statement of work - SOW, descrita en el doc nº 029), que especifica exactamente los entregables del proyecto. En resumen, calidad significa “cumplir con las expectativas del cliente, asegurar que este recibirá exactamente lo solicitado, en el plazo y dentro del presupuesto”. “Los requisitos del cliente están escritos en aquella servilleta de papel” Los requisitos del cliente establecen detalladamente sus necesidades y expectativas, además de proporcionar la dirección por la cual el equipo tendrá que desarrollar la planificación del proyecto. Un factor clave del éxito del proyecto es la correcta documentación de estos requisitos, que deberá estar exhaustivamente detallada. Si un proyecto está basado en requisitos escritos en una servilleta, ya podemos conocer con mucha antelación que fin tendrá este proyecto. “Todos los problemas serán priorizados como críticos”. Este tipo de “estrategia” es muy frecuente en la ejecución de proyectos, y se puede decir, sin mediar palabras, que se trata de “pegar un tiro en el propio pie”. Imaginemos la siguiente situación: una casa antigua necesita cambiar el suelo de la cocina, renovar toda la pintura y cambiar todo el cableado eléctrico, cuyo mal estado contempla un alto riesgo de cortocircuito. ¿Es razonable decir que en el proyecto de reforma de esta casa se puede clasificar todo los problemas como críticos? Todos los problemas, en cualquier seguimiento, sea empresarial o personal, no pueden tener la misma prioridad. Cada uno requiere un tratamiento distinto, tendrá seguramente un coste distinto y necesita de grados diferentes de urgencia. “Podemos entregarlo al cliente sin hacer las pruebas, estoy seguro de que todo funciona perfectamente” La verificación y validación de un producto es una actividad fundamental para asegurar su calidad antes de su puesta en funcionamiento, evitando, de esta forma, errores y costes imprevistos para corregir dichos errores. Las pruebas son generalmente consideradas como costosas y molestas, aunque sus beneficios se dejan notar en la empresa y, sobre todo, en la satisfacción del cliente. La empresa, por un lado, cumple con su compromiso de alcance, plazo, coste y calidad; por otro, el proyecto llega a su fase final entregando un producto considerado estable y seguro.
254
“No creo que el cliente necesite un manual” Igual que las pruebas, algunas empresas consideran los manuales como un elemento innecesario y, muchas veces, una pérdida de tiempo. Felizmente, se ha notado que la gran mayoría de las empresas se ha dado cuenta de la importancia de los manuales, y hoy en día incluso una silla viene acompañada de su manual de uso y montaje. Esto se debe, sobre todo, por el nivel de exigencia del mercado consumidor y de la fuerte competencia que las empresas tienen que enfrentar, especialmente las multinacionales. Un manual es considerado como una parte integral del producto y una parte legal de la entrega, estando debidamente presente como uno de los criterios de aceptación final del proyecto.
Introducción La calidad es algo muy subjetivo, puesto que cada persona posee grados distintos de valores y expectativas. Lo que puede tener mucha calidad para una persona, puede tener poca o casi ninguna para otra. Por esta razón es fundamental entender lo que necesita el cliente (sus requisitos), en la fase inicial del proyecto, para poder asegurar que el producto y/o servicio que le será entregado atiende a sus expectativas y posee el nivel de calidad esperado. La calidad es un concepto extremadamente amplio y difícil de explicar. La podemos definir de distintas formas:
·
Grado en que el conjunto de características cumple con los requisitos establecidos.
·
Conjunto de actividades que permiten satisfacer las necesidades de un individuo o de un colectivo.
·
Satisfacción del cliente y conformidad con sus requisitos.
·
Grado de satisfacción que produce al cliente.
Se pueden comprobar en la historia, que desde siempre el hombre ha buscado por la perfección y siempre ha tenido un especial interés por el trabajo bien hecho, inquietudes que, con el pasar de los siglos, han culminado en los estándares de calidad que conocemos actualmente. Entre los años 2000 y 3000 a.C, los faraones egipcios construyeron pirámides que poseían parámetros que se acercaban casi a la perfección. El mismo nivel de calidad de ingeniería se puede apreciar en las pirámides aztecas, que atestiguan los increíbles avances en la arquitectura y la ingeniería que estos pueblos mesoamericanos lograron gracias a los métodos de inspección empleados durante su construcción. Muchos siglos más tarde, en la edad media, surgió la figura del artesano, que acorde con la zona en donde habitaba, confeccionaba sus productos siguiendo las especificaciones establecidas por su gremio. Es por esta razón que, pasados 600 años, todavía es posible apreciar el sabor de un queso, de un pan o de un dulce exactamente como eran fabricados en aquella remota época. Llega la revolución industrial y con ella, comienza a desaparecer la artesanía. Surgen las primeras grandes fábricas que llevan a la población una novedad: productos industrializados, hechos en cantidades jamás imaginadas y con una característica novedosa: eran todos exactamente iguales.
255
Los dulces tenían todos el mismo sabor, las sillas las mismas dimensiones y las ropas el mismo diseño y características textiles. La producción masiva de productos ha logrado reducir sus costes de producción y atender a un público cada vez mayor, y con el paso del tiempo, más exigente. Los años pasaron y finalmente surge el control de calidad moderno en las primeras décadas del siglo XX, con la aplicación industrial del cuadro de control ideado por el doctor Walter Shewhart 31, inventor de los conocidos gráficos de control (descritos detalladamente en la sección 8.3.1.4). Finalizada la II Guerra Mundial, los japoneses comienzan a dedicar una atención casi obsesiva a la calidad. Muchas empresas empiezan a trabajar con el concepto de “sistema integral de calidad”, que afecta al diseño, la fabricación y la comercialización, produciéndose un fenómeno singular que afectó a la comercialización y economía industrial de muchos países, como consecuencia del despegue de la industria japonesa, aplicando los conceptos del aseguramiento de la calidad y la prevención. Los industriales japoneses aprendieron las enseñanzas de Deming 30 y la calidad japonesa, la productividad y su posición competitiva se mejoraron y reforzaron, para ser lo que son hoy en día. Es por ello que cada año se otorga en el Japón los muy deseados “Premios Deming” al individuo que muestre logros excelentes en teoría o en la aplicación del control de la calidad por estadísticas, o aquella persona que contribuya notablemente a la difusión de las técnicas del control de calidad por estadísticas, así como a su aplicación. Las compañías japonesas que han obtenido dichos premios incluyen Nissan, Toyota, Hitachi y Nipon Steel. En 1989, la Florida Power and Light Company fue la primera compañía extranjera en ganar el “Premio Deming”.
8.1 Planificación de la calidad
(Proceso que corresponde a la fase de planificación del proyecto) “Planificar la calidad” es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos. La planificación de la calidad debe realizarse en forma paralela a los demás procesos de planificación del proyecto. Por ejemplo, los cambios propuestos en el producto para cumplir con las normas de calidad identificadas pueden requerir ajustes en el coste o en el cronograma, así como un análisis detallado de los riesgos de impacto en los planes. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de la calidad de un proyecto incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por la cuales fue emprendido. Son ellos:
· · ·
Planificar la calidad. Realizar el aseguramiento de calidad. Realizar el control de calidad.
256
8.1.1 Técnicas y herramientas 8.1.1.1 Análisis beneficiocoste (Benefit-cost analisys – BCA) Es una herramienta utilizada para determinar si los beneficios obtenidos a través de la realización de un proyecto compensan los costes que serán generados para ponerlo en marcha. Se aplica muy frecuentemente para determinar cuál de las opciones disponibles ofrece mejor rendimiento sobre una inversión. Los beneficios pueden ser tangibles o intangibles. En el caso de los intangibles, sus beneficios son más difíciles de mesurar, por ejemplo, hacer una reforma en una oficina, modernizando a la vez el mobiliario y los equipos de trabajo, podrá incrementar de forma importante el nivel de satisfacción y motivación de los trabajadores, aumentando el nivel de producción. El análisis beneficio-coste se desarrolla de la siguiente forma:
·
Se lleva a cabo una tormenta de ideas (descrita en la sección 11.2.1.8). O se puede de forma más sencilla, reunir datos históricos, o incluso consultar a personas con experiencia (descrita en la sección 4.1.1.1).
·
Determinar los costes relacionados con cada factor. Algunos costes, como mano de obra, podrán ser exactos, mientras otros menos conocidos, deberán ser estimados.
·
Sumar los costes totales de cada decisión propuesta.
·
Determinar los beneficios en Euros de cada decisión.
·
Determinar la relación entre los beneficios y costes. Los beneficios tangibles se traducen en retorno financiero y son más sencillos de cuantificar. La fórmula clásica del análisis beneficio-coste es muy sencilla y fácil de calcular:
Comparar los resultados de esta fórmula entre las diferentes propuestas. La mejor solución, en términos financieros es aquella con el mejor resultado. Para imputar los valores y realizar los cálculos, se puede utilizar una tabla como la que ampliamos a continuación:
257
PROPUESTA
COSTE S
BENEFICIO S
258
BENEFICIO COSTE
¿DESEABLE? (SÍ / NO)
259
Figura 92: Tabla de análisis beneficio / coste
Aunque sea deseable que los beneficios sean mayores que los costes, no existe una respuesta única que pueda determinar la mejor relación. Dependerá de cada caso. Existen beneficios intangibles, como la seguridad, la motivación de los trabajadores o la tranquilidad que no pueden ser exactamente traducidos en beneficios financieros. El análisis coste/beneficio por si solo puede no ser una referencia clara para tomar una determinada decisión. Existen otros puntos que deben ser llevados en cuenta y que pueden ser identificados a través de las herramientas presentadas en el Capítulo 3 – Selección de proyectos.
8.1.1.2 Análisis de los costes de calidad (Cost of qualityanalisys) Desarrollar un sistema de calidad eficaz en un proyecto conlleva a un cierto incremento de costes. Puede que parezca más económico no establecer controles de calidad o ningún proceso de medición o monitorización del trabajo realizado. No obstante, es importante tener claro que es indiscutiblemente más cara las eventuales consecuencias provocadas por la no calidad. Básicamente, son cuatro los costes de calidad:
• Costes de prevención: El coste de corregir un defecto o problema generalmente es mayor que el coste de prevenirlo. El coste de prevención es el coste derivado de la planificación que se realiza antes de un proyecto para evitar que se comentan errores. Son acciones que buscan realizar el trabajo a la primera. Los costes de prevención generalmente involucran planes adicionales, formación del equipo inspecciones, pruebas y auditorias.
260
•
Costes de evaluación: Es el resultado de las evaluaciones que se realizan en un producto ya acabado. Normalmente se realiza este proceso cuando la organización no está segura de que las acciones preventivas desarrolladas con anterioridad no hayan sido suficientes.
·
Costes por fallos internos: Son aquellos en los que incurre la organización como consecuencia de errores cometidos durante el desarrollo, y que han sido detectados antes de que el producto o servicio sea entregado al cliente. También son conocidos como “costes de corrección” que generalmente involucran retrabajo, reparación, substitución de piezas, perdida de futuros negocios con el cliente, problemas contractuales.
·
Costes de errores externos: Son los costes incurridos debido a que el cliente detectó defectos. La organización tiene que asumir estos costes porque su sistema de evaluación no detectó los fallos. Estos costes desaparecerían si no se hubiera producido ningún defecto. Son los costes de garantías, costes de servicio técnico, manejo de quejas y pérdidas futuras del negocio.
La gestión eficaz de los costes, enfocando fundamentalmente en la prevención, generará a lo largo del desarrollo del proyecto una serie de beneficios, por ejemplo:
·
Incremento en la satisfacción del cliente: El número de defectos o problemas es inversamente proporcional a la satisfacción del cliente. Un servicio de alta calidad dará al cliente una sensación muy buena durante su desarrollo, lo que se podrá traducir más adelante en nuevas ventas.
·
Mayor productividad: Corregir errores continuamente y tener que realizar el mismo trabajo dos veces en tareas ya terminadas son factores que perjudican directamente la productividad. Si los entregables son producidos con la mejor calidad posible, la productividad del proyecto como un todo será muy efectiva.
·
Costes más bajos / duración más corta: Para alcanzar un cierto nivel de calidad es necesario invertir dinero, tiempo y recursos. Sin embargo, todos estos esfuerzos serán compensados a partir del momento que el nivel de retrabajo empieza a reducirse y los procesos fluyan naturalmente sin incidencias.
·
Mayor moral del equipo: La moral del equipo se queda dañada siempre que se producen errores. A nadie le gusta cometer errores y las cosas se pueden volverse muy frustrantes si estos errores vuelven a repetirse.
·
Menos errores y defectos: Un trabajo realizado con calidad es un trabajo que no presenta ningún defecto. En el mercado, un producto hecho con calidad presenta menos devoluciones, menos trabajo de mantenimiento y reparo y consecuentemente, menos costes a la empresa.
8.1.1.3 Diagramas de control (Control chart)
Descrita en la sección 8.3.1.4 261
8.1.1.4 Estudios comparativos (Benchmarking) El benchmarking es una técnica que empezó a emplearse a finales de los 70 en Estados Unidos. Con esta técnica se pretende descubrir y definir los aspectos que hacen que una organización sea más rentable que otra, o que tenga productos y servicios mejores. Este análisis aportará informaciones que ayudarán a la organización a mejorar sus propios servicios y productos. Hay que tener presente que es una técnica que no implica prácticas fuera de legalidad. No se trata de espionaje o de copiar lo que hacen otras empresas, sino realizar una investigación que permita a la empresa mejorar sus procesos internos de gestión realizando comparaciones de sus servicios y productos con las mejores prácticas del mercado. El término inglés benchmark proviene de las palabras “bench” (banquillo, mesa) y “mark” (marca, señal). El uso del término provendría de la Inglaterra del siglo 19, cuando los agrimensores hacían un corte o marca en una piedra o en un muro para medir la altura o nivel de una extensión de tierra. El corte servía para asegurar un soporte llamado bench, sobre el cual luego se apoyaba el instrumento de medición, en consecuencia, todas las mediciones posteriores estaban hechas con base en la posición y altura de dicha marca. El benchmarking se puede encajar perfectamente con un texto del año 500 a. C. del General Sun Tzu29 que dice “Conoce a tu enemigo y conócete a ti mismo; en cien batallas, nunca saldrás derrotado. Si eres ignorante de tu enemigo pero te conoces a ti mismo, tus oportunidades de ganar o perder son las mismas. Si eres ignorante de tu enemigo y de ti mismo, puedes estar seguro de ser derrotado en cada batalla”.
Técnicas de Benchmarking En función del objetivo y de la necesidad de la organización, se pueden desarrollar varios tipos de benchmarking:
·
Benchmarking interno: En empresas de grande porte que cuentan con varias divisiones y departamentos, muchos de los procedimientos y gestiones utilizados son similares. El benchmarking interno trata de comparar los procesos dentro de estos departamentos, para posteriormente aplicar las mejores prácticas en toda la organización. Es una de las formas más fáciles de desarrollar la práctica del benchmarking, ya que es posible acceder a una importante cantidad de información de la empresa.
·
Benchmarking primario: Es un tipo de benchmarking en que la información es recabada directamente de la competencia. Una forma muy común de realizar este tipo de benchmarking es consultando a los antiguos empleados de otras empresas. Actualmente algunas organizaciones están optando por formalizar un contrato de confidencialidad con sus empleados, en el momento de su admisión, lo que por lo menos teóricamente, les impediría de divulgar informaciones de su trabajo anterior. De todas formas, existen otras fuentes de información importantes como son los clientes y los proveedores de la competencia, a pesar de que en muchos casos, la información podrá llegar destorcida por interés del propio cliente o proveedor.
262
•
Benchmarking cooperativo: En este tipo de benchmarking las empresas competidoras realizan un intercambio de información entre sí. Es una técnica más sencilla en el ámbito internacional, ya que la competencia es más lejana y se percibe menos directa que la competencia nacional. No obstante, es una técnica prácticamente inexistente en empresas pequeñas o en PYMES que suelen ser muy resistentes al intercambio de informaciones.
·
Benchmarking secundario: Es la recopilación de información de dominio público, como puede ser por ejemplo y sin ir más lejos, la sacada de internet. De una forma rápida, sencilla y gratuita, se puede obtener a través de Internet, informaciones sobre un determinado sector, cuales son las empresas competidoras, como actúan y como ofrecen sus servicios, el perfil de los clientes, entre otras.
·
Benchmarking genérico: Es desarrollado entre empresas de sectores distintos que desarrollan el mismo proceso. Muchas organizaciones son estructuradas de formas similares y desarrollan procedimientos muy parecidos. El beneficio de esta forma de benchmarking tiene la posibilidad de acceder de forma más amplia a las mejores prácticas.
Aunque parezca una técnica sencilla, el benchmarking requiere una cierta inversión económica y, sobre todo, de tiempo. Todo estudio de benchmarking conlleva a una búsqueda y recogida de información que incluye el análisis de procesos, asistencia a congresos, visitas a empresas, entrevistas, charlas y mucha investigación, además de todo el proceso de implantación y adaptación de las prácticas aprendidas, que seguramente es una batalla a parte.
8.1.1.5 Diseño de experimentos (Design of experiments) El diseño de experimentos es un método estadístico que permite identificar los factores que pueden influir sobre una determinada variable. Es una técnica que se aplica de forma más frecuente al producto generado por el proyecto. Tiene como objetivo:
·
Seleccionar la experiencia ideal que permita obtener la información buscada con el mínimo coste.
·
Evaluar los resultados obtenidos, buscando garantizar la fiabilidad de la información obtenida.
Ejemplo:
·
Los diseñadores de un software pueden determinar qué características (cantidad de memoria, velocidad del procesador...) debe tener un equipo informático para que su aplicación sea ejecutada de forma rápida y sin errores.
·
Un cocinero puede combinar diferentes ingredientes, hasta encontrar el sabor ideal para el plato que está preparando. 263
Este método consiste básicamente en variar un factor de cada vez, a partir de una determinada condición inicial, en que todos los factores estudiados permanecen constantes, con excepción de aquel que se está analizando. Se repite el mismo procedimiento con los otros factores, uno a uno. Cada respuesta obtenida será atribuida a la variación de cada factor analizado y por lo tanto obtendremos los efectos derivados de este factor. Este método tiene el inconveniente de tener que probar un factor cada vez y en algunos casos, el número de factores a probar puede ser muy alto. Se trata de una operación que puede llegar a ser muy costosa. Es importante hacer una planificación previa, descartando algunos factores hasta alcanzar una cantidad manejable. Para asegurarse que se están descartando los factores de adecuadamente, se puede realizar el mismo experimento utilizando un modelo o prototipo más sencillo. Los resultados obtenidos determinarían los mejores factores para utilizar en el experimento completo. Los resultados obtenidos deberán ser exhaustivamente analizados, sobre todo la respuesta de sus interacciones. Todo esto contrastado con la calidad deseada, podrá asegurar que el producto final generará los resultados esperados.
8.1.1.6 Muestra estadística (Statistical sampling)
Descrita en la sección 8.3.1.8
8.1.1.7 Diagrama de flujo (Flowcharting) Un diagrama de flujo es la representación gráfica de hechos, situaciones, decisiones o relaciones de todo tipo, a través de símbolos gráficos. El diagrama de flujo representa de inmediato una visión global de un determinado proceso y ayuda a comprender mejor las relaciones y dependencias de las actividades que forman parte de un determinado proceso. Esta herramienta es útil para determinar cómo funciona un proceso completo y es, además, una herramienta muy útil para determinar si la organización está desarrollando algún proceso con tareas innecesarias, círculos de duplicación de trabajo o problemas potenciales. El diagrama de flujo indica acciones en secuencia y para ello existen docenas de símbolos, sobre todo para uso especializado. La simbología más comúnmente utilizada es la siguiente:
264
Figura 93: Elementos de un diagrama de flujo
El diagrama de flujo puede ser aplicado en cualquier situación, como por ejemplo, procesos control de documentación, procedimientos de calidad, fases de fabricación de una pieza, encuestas de marketing... Confeccionado de forma adecuada, el diagrama de flujo proporcionará a los miembros un conocimiento común exacto del funcionamiento de un proceso. Existen casos, como, por ejemplo, en una cadena de producción, en que se puede estimar el tiempo necesario de duración de cada actividad, asignando un tiempo estimado de cada actividad y el tiempo estimado total para el desarrollo de todo el flujo. El mercado dispone de varios programas que facilitan la confección de un diagrama de flujo. Sin embargo, su confección es muy sencilla. Conociendo todo el proceso, se puede hacer un borrador utilizando un lápiz y un folio y pasarlo a una herramienta ofimática común. Básicamente, se puede confeccionar un diagrama de flujo utilizando correctamente los símbolos descritos en la figura 93. Un diagrama de flujo, no debe excluir ninguna actividad, tiene que ser confeccionado tal cual es realizado en la práctica y las personas responsables en llevar a cabo el proceso deben participar directamente de la confección de estos flujos. La figura 94, que se presenta a continuación, ilustra un diagrama de flujo de un proceso de atención a un cliente usuario de un servicio de telefonía.
265
Envia técnico al domicilio del cliente NO ¿Resuelve el problema?
Analisa problema
Soluciona problema SÍ ¿Es un problema nivel 1? NO Repasa llamada al técnico nivel 2
266
Refleja solución del problema en el sistema
Recoje llamada Analisa problema
267
Refleja solución del problema en el sistema SÍ
268
Figura 94: Ejemplo de un diagrama de flujo de atención al cliente
8.1.1.8 Metodologías propietarias de gestión de la calidad (Property quality management methodologies) El mercado dispone de una importante gama de metodologías propietarias, donde podemos destacar las más utilizadas:
·
Madurez máxima en dirección de proyectos a nivel organizacional (organizational Project Management maturity model - OPM3®).
·
PRINCE2® (Projects in controlled environments).
·
Método en V (V-Model - German project management method).
·
HERMES.
·
ISO 9000.
·
ISO 10006.
·
Modelo de madurez de capacidades (Capability caturity model – CMM®).
·
Six Sigma®.
269
Véase también la información más ampliada de estas metodologías en la sección “referencias” de esta obra.
8.1.1.9 Análisis de campos de fuerza (Force field analysis) El análisis de campos de fuerza es una herramienta utilizada para realizar una evaluación a fondo de un determinado cambio. Esta herramienta ve el cambio como un evento que trae consigo dos fuerzas antagónicas que compiten entre si: las fuerzas impulsoras (driving forces), que facilitan el cambio y conspiran a su favor y las fuerzas restringentes (restraining forces), que presionan contra el cambio. Este análisis nos ayuda, por lo tanto, a identificar los factores que pueden contribuir para el éxito o fracaso del cam bio propuesto. ¿Cómo se desarrolla?
·
De define el cambio deseado
·
Se realiza una sección de tormenta de ideas para identificar las fuerzas impulsoras y restringentes.
·
Se clasifica el orden de prioridad de cada fuerza.
·
Se definen las acciones a tomar.
Figura 95: Ejemplo de aplicación del análisis de campo de fuerzas
Una vez desarrollado el gráfico de análisis de fuerzas y estudiando sus resultados, se decide si el cambio es viable en función de las fuerzas a favor y en contra. Si la decisión es llevar a cabo el cambio, se definirán acciones para intentar minimizar el impacto de los contras y aumentar la fuerza de los pros.
270
Teniendo en cuenta que cada fuerza tiene grados de intensidad e impacto diferentes sería interesante, y además muy recomendable, asignar pesos para cada fuerza identificada, utilizando, por ejemplo, una escala de 1 a 5 (1 para más débil y 5 para más fuerte). Al asignar pesos a las fuerzas, será posible conocer cuáles son las fuerzas impulsoras y restringentes más potentes, y de esta forma, poner en marcha acciones paralelas que logren aumentar la potencia de las fuerzas más favorables y reducir (o eliminar) la potencia de las fuerzas más restringentes. La puntuación se puede obtener por medio de la información disponible o simplemente por criterio de las personas involucradas en la decisión. En el segundo caso, puede ocurrir una manipulación de valores para obtener un valor favorable según determinados intereses personales. Por ello, es recomendable trasladar este criterio de valores a un juicio de expertos. En la figura 96, podemos apreciar que la suma de puntos nos conducirá a la decisión de no realizar el cambio. No obstante, si somos capaces de debilitar o eliminar alguna de las fuerzas restringentes (por ejemplo, reducir el coste de implantación y/o eliminar los problemas de compatibilidad), podíamos cambiar el resultado final del análisis, favoreciendo por lo tanto, al cambio de tecnología. También se podría por otro lado, intentar potencializar alguna fuerza impulsora (logrando obtener mejores tasas de financiación) o incluyendo una nueva fuerza impulsora todavía no identificada.
Figura 96: Análisis de campo de fuerzas incluyendo asignación de pesos
271
8.1.1.10 Listas de verificación (Checklists) Descrita en la sección 8.3.1.5.
8.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 016 – Plan de gestión de calidad (Quality management planificación)
I
DOC nº 017 – Métricas de calidad (Quality metrics)
I
DOC nº 018 – Listas de control de calidad (Quality checklists)
I
DOC nº 019 – Plan de mejoras del proceso (Process improvement plan)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
8.2 Aseguramiento de la calidad (Proceso que corresponde a la fase de ejecución del proyecto) El aseguramiento de calidad es el proceso que consiste en auditar los requisitos de calidad y los resultados obtenidos a partir de medidas de control de calidad, con el fin de garantizar que se utilicen definiciones operacionales y normas de calidad adecuadas. Esta gestión también se encarga del proceso de mejora continua, que es un medio iterativo de mejora de la calidad de todos los procesos. El proceso de mejora continua reduce las actividades inútiles y elimina aquellas que no agregan valor al proyecto. El resultado es la obtención de un proceso que opera a nivel óptimo, evitando de esta forma, el consumo desnecesario de recursos
272
8.2.1 Técnicas y herramientas 8.2.1.1 Auditorias de calidad (Quality audits) En muchos casos, es importante realizar evaluaciones puntuales acerca del desarrollo de un proyecto a través de un proceso de verificación realizado por un agente externo. Este proceso de verificación es conocido como auditoría y es empleada para comprobar y evaluar las actividades relacionadas con el desarrollo de los productos y servicios de una organización. Su realización puede ocurrir por solicitud de la administración, por exigencia de un cliente, por solicitud de una entidad certificadora, por el gobierno, o incluso por exigencia del sistema de calidad adoptado por la organización. En cualquiera de los casos, es importante que la alta dirección facilite los medios adecuados para su realización, así como la mejora de las áreas no conformes con el modelo exigido. La filosofía de la auditoria de calidad será normalmente basada en la verificación y en la prevención, más que en la detección de problemas. La persona que realiza la auditoria debe tener la cualificación apropiada para hacerlo, de preferencia debe poseer una formación específica y principalmente conocer el sector en que se realiza la auditoria. La documentación básica de un proceso de auditoría de calidad es la siguiente: Agenda de realización de la auditoria (audit agenda): Véase doc nº 047, Apéndice A. Listas de verificación (Checklists): Véase sección 8.3.1.5. Informes de deficiencias y recomendaciones (audit report): Véase doc nº 048, Apéndice A.
Las fases de una auditoria de calidad son las siguientes:
·
Notificación: El Project Manager recibe una notificación del auditor en que se solicita una reunión para tratar de la agenda de la auditoria, los departamentos y personas que serán auditadas. Una vez establecida la agenda de la auditoria, el Project Manager deberá notifi car a todo el personal afectado.
·
Preparación: El auditor necesitará de algunas informaciones preliminares del proyecto que deberán ser suministradas por el Project Manager. Es importante que, en esta fase, el auditor y el Project Manager intercambien informaciones para que la auditoria pueda ser realiza de forma más productiva posible.
·
Auditoria: El auditor realizará las comprobaciones necesarias para verificar si el proyecto cumple con los procedimientos establecidos. En esta fase, el auditor detectará las conformidades y no conformidades.
·
Análisis complementares: En algunos proyectos, una reunión suele ser suficiente. Sin embargo, en proyectos grandes y complejos, será necesaria la realización de otras reuniones en que el auditor realizará una sección de análisis y cuestionamientos complementares. Este tipo de acción podrá incluir reuniones con el cliente y análisis de la documentación técnica.
273
•
Informe inicial: Tras la conclusión de las fases de recogida de datos y análisis de información, el auditor confeccionará los resultados en un informe que será entregado al Project Manager para su apreciación. Este informe incluirá también las recomendaciones y acciones que deberán ser llevadas a cabo para sanar las eventuales no conformidades;
·
Reunión de revisión: Otra reunión entre el Project Manager y el auditor deberá ser realizada para discutir los puntos descritos en el Informe Inicial. El auditor realizará sus comentarios acerca de todo el informe, haciendo hincapié, sobre todo, en las no conformidades detectadas.
·
Informe final: El Auditor finalmente, confeccionará y enviará al Project Manager el informe final, detallando los trabajos y resultados de todas las fases anteriores. Se realizará una junta con la dirección en que se discutirán los puntos del informe final y se decidirán las acciones para corregir las no conformidades encontradas y evitar que se produzcan los mismos errores.
8.2.1.2 Informe de auditoria (Audit report) El informe de auditoria es un documento que expresa la opinión de un profesional cualificado acerca de la información y de la documentación de calidad de una organización. Constituye la etapa final del proceso de auditoría, en el mismo se recogen todos los hallazgos detectados y el soporte documental para sustentar el dictamen emitido, por lo que requiere de extremo cuidado en su confección. La capacidad y habilidad del auditor en la redacción del informe, son fundamentales para que este logre sus objetivos y cumpla con los propósitos de ofrecer los elementos que permitan al lector conocer, de forma fácil, los resultados del trabajo realizado por los auditores. Las instrucciones de redacción de este documento se encuentran detalladas en el Apéndice A – doc nº 048.
8.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I
DOC nº 039 – Solicitudes de cam bio (Change requests)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates) 274
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
275
8.3 Control de calidad
(Proceso que corresponde a la fase de control del proyecto) La calidad es un concepto muy relativo y subjetivo, ya que diferentes personas pueden tener una percepción diferente de la calidad, es decir, lo que es bueno para unos puede no serlo para otros. Un producto o servicio es considerado de calidad cuando refleja exactamente las expectativas del cliente y será el factor que determinará su grado de satisfacción con los resultados generados. Un control efectivo de la calidad es posible si los requisitos del cliente son claramente definidos y ampliamente conocidos por todas las partes involucradas. Una vez finalizado un producto o servicio, se comparan si los resultados generados son exactamente los mismos especificados anteriormente por el cliente. En muchos proyectos estos requisitos no existen o no se tienen en cuenta. De esta forma, resulta imposible realizar un servicio o producto que pueda atender las expectativas del cliente. El control de calidad además debe ser de carácter preventivo y es una gestión constante, que acompañara el ciclo de vida del proyecto en todas sus fases. Entre otros aspectos, puede resultar útil para el equipo conocer la diferencia entre los siguientes pares de términos:
·
Prevención (evitar que haya errores en el proceso) e inspección (evitar que los errores lleguen a manos del cliente).
·
Muestreo por atributos (el resultado cumple o no con los requisitos) y muestreo por variables (el resultado se clasifica según una escala continua que mide el grado de conformidad).
·
Tolerancias (rango especificado de resultados aceptables) y límites de control (umbrales que pueden indicar si el proceso está fuera de control).
8.3.1 Técnicas y herramientas 8.3.1.1 Mediciones de calidad (Quality control measurement) Medir cosas es una práctica muy común en nuestro cotidiano. Todos los días, solemos medir pesos, alturas, temperaturas, ruidos, dimensiones y un sinfín de valores. Estas mediciones se realizan a través de un valor de referencia, que nos permite evaluar si nos situamos por debajo o por encima del valor deseado para alcanzar un determinado nivel de calidad. "Si usted no puede medir algo, es imposible que pueda mejorarlo”. Esta frase de Edward Deming30 traduce la importancia que las mediciones proporcionan a la calidad de los productos y/o servicios desarrollados en un proyecto. Son muchos los argumentos que justifican el uso de mediciones de calidad. Normalmente las utilizamos para:
276
•
· · · ·
Indicar la calidad del producto. Evaluar la productividad de la gente que desarrolla el producto. Evaluar los beneficios en términos de productividad y de calidad. Establecer una línea de base para la estimación. Ayudar a justificar el uso de nuevas herramientas o de formación adicional.
Las mediciones en la fase de control de calidad de un proyecto nos pueden aportar las informaciones necesarias para tomar las decisiones adecuadas, como por ejemplo, la puesta en marcha de medidas preventivas, si se constata que el producto no está logrando alcanzar la calidad adecuada. Además nos pueden contar si se está ejecutando el proyecto correctamente, si estamos obteniendo los objetivos buscados, si el cliente está satisfecho, si nuestros procesos son efectivos o es necesario mejorar algún aspecto del mismo, identificar tendencias, evaluar la implementación de cambios, efectuar análisis y proyecciones en general. Un buen programa de control de proyectos debería identificar, seleccionar y priorizar las métricas a utilizarse para el monitoreo de la performance del proyecto y el logro de sus objetivos. Una buena medición debe cumplir los siguientes requisitos: sus resultados tienen que ser consistentes, entendibles, manejables, analizables y obtenidos de forma sencilla.
Los modelos de métricas de calidad más conocidos en los proyectos de desarrollo de software son los siguientes: Modelo de MCCALL (1977)
·
Describe la calidad como un concepto elaborado mediante relaciones jerárquicas entre factores de calidad, en base a criterios.
·
Los factores de calidad se concentran en tres aspectos importantes de un producto de software: características operativas, capacidad de cambios y adaptabilidad a nuevos entornos.
·
Identifica una serie de criterios, tales como rastreabilidad, simp licidad, capacidad de expansión...
·
Las métricas desarrolladas están relacionadas con los factores de calidad y la relación que se establece se mide en función del grado de cumplimiento de los criterios.
Modelo de FURPS (1987)
·
Modelo desarrollado por Hewlett-Packard (HP) en 1987, desarrollando un conjunto de factores de calidad de software y sus respectivos atributos. 277
·
Basado en el modelo de MCCALL.
278
• ·
Se utilizan para establecer métricas de la calidad para todas las actividades del proceso de desarrollo de un software, inclusive de un sistema de información. FURPS es una sigla que significa: Functionality, Usability, Reliability, Performance y Supportability.
Modelo de DROMEY (1996)
·
Resalta el hecho de que la calidad del producto es altamente determinada por los componentes del mismo (incluyendo documentos de requerimientos, guías de usuarios, diseños y código).
·
Sugiere el uso de cuatro categorías que implican propiedades de calidad, que son correcciones internas, contextuales y descriptivas.
8.3.1.2 El Ciclo PDCA (PDCA cycle) También conocido como “ciclo Deming”, fue creado por Edwards Deming 30, estadístico y profesor estadounidense. Se trata de una herramienta cuya función es crear una estrategia de mejora continua de la calidad en cuatro etapas, basada en un concepto creado por Walter A. Shewhart 31, considerado el padre del control estadístico de la calidad.
Figura 97: Ciclo PDCA
Las siglas PDCA son el acrónimo de Plan (planificar), Do (hacer), Check (verificar), Act (Actuar). Estas acciones consisten en:
·
Planificar (plan): Prevenir y definir las actividades a desarrollar, identificando el proceso que se quiere mejorar y recopilando la información necesaria para profundizar el conocimiento del proceso para establecer los objetivos de mejora y definir los procesos necesarios para lograr estos objetivos.
279
•
Hacer (do): Realizar las actividades definidas en el proceso anterior definidas y documentar las acciones realizadas.
·
Verificar (check): Monitorizar el estado del proyecto. El Project Manager compara el resultado obtenido con el planificado y evalúa las diferencias.
·
Actuar (act): Anticipar el problema, mitigando posibles riesgos.
·
... ¡¡y volver a empezar!!!
8.3.1.3 Inspección (Inspection)
Descrita en la sección 5.4.1.1.
8.3.1.4 Gráfico de control (Control chart) El gráfico de control es utilizado para verificar si un proceso fluye normalmente, a través de la monitorización de su avance. Es una herramienta muy utilizada en procesos repetitivos, como son los de producción, pero muy útil para monitorizar variaciones de costes y plazos. Todo proceso está expuesto a variaciones que pueden ser resultantes de una causa puntual o de pequeñas incidencias que se van acumulando y que acaban generando una variación visible que necesita de acciones correctivas para que se mantenga estable otra vez. Cuando un proceso se encuentra dentro de los límites establecidos es porque su curso avanza de forma normal. Si el proceso sale de estos límites, es necesarios realizar reajustes. La figura 98 es un ejemplo de un gráfico de control, en que un determinado proceso está bajo seguimiento del Project Manager y del equipo del proyecto. Los puntos ilustrados en el ejemplo tienen que estar dentro de la zona límite de normalidad. Si uno de estos puntos sobrepasa el límite, el proceso ha salido de control e inmediatamente el Project Manager deberá poner en marcha un plan de acción correctiva, como ocurre en el ejemplo ilustrado en la figura 98, donde se puede apreciar que algunos puntos han sobrepasado la zona de variación normal, situándose en la zona de control.
280
Figura 98: Ejemplo de gráfico de control
8.3.1.5 Listas de verificación (Checklists) Es una herramienta que se utiliza para determinar la frecuencia que ocurre un evento a lo largo de un periodo de tiempo determinado. En esta lista se recoge información de cualquier clase de ocurrencias basándose en información histórica o en eventos que están ocurriendo. Para demostrar un ejemplo de su uso, ilustraremos a continuación el caso de la empresa de informática Alfa PC, que se dedica al montaje y la comercialización de ordenadores de sobremesa. Su sistema de ventas consiste en comprar de mayoristas las piezas de los ordenadores (placas, memorias, discos duros...) y montar los equipos a medida para sus clientes que son en su mayoría, personas físicas. Una vez montado el equipo, este es entregado al cliente sin realizar ningún tipo de verificación, puesto que ellos contaban con las pruebas realizadas anteriormente por sus proveedores que certificaban que sus componentes eran probados y funcionaban perfectamente. No obstante, las quejas recibidas por parte de algunos de sus clientes no decían lo mismo. Preocupados con su imagen, decidieron realizar un análisis más a fondo. Tras verificar las notas de reparo del departamento técnico, se constató que durante los últimos doce meses, el 20% de los equipos vendidos presentó defectos. Un número bastante elevado que, además de perjudicar su imagen, conllevaba a costes que a largo plazo la empresa Alfa PC no podría soportar. Para intentar buscar una solución que pudiera reducir el número de equipos defectuosos, la gerencia de Alfa PC recogió toda la información de los equipos que presentaron problemas en estos doce meses y confeccionaron la lista a continuación:
281
COMPONEN TES Ratón
DEFECT OS 29
Altavoces
29
Disco duro
82
Teclado
20
Placa base
TOTAL
109 400
Figura 99: Ordenadores vendidos con defecto
Con esta sencilla herramienta fue posible identificar los componentes que presentaron problemas en todos los cuatrocientos equipos defectuosos que retornaron a la asistencia técnica para reparo. Decidieron que, a partir de entonces, ningún equipo saldría de las tiendas de Alfa PC sin antes pasar por una serie de pruebas internas que garantizasen su correcto funcionamiento. Es decir, cada equipo tendría que presentar cero defectos para ser vendido. Para garantizarlo, cada equipo pasaría por un chequeo, utilizando la lista de verificación anteriormente confeccionada: A partir de entonces, no se ha vendido una sola unidad que presentara el mínimo defecto. Diez meses después, se podía apreciar la siguiente tabla de defectos:
COMPONEN TES Ratón
DEFECT OS 0
Altavoces
0
Disco duro
0
Placa de red Monitor
0
Teclado
0
Placa base
0
Memoria
0
TOTAL
0
0
Figura 100: Ordenadores vendidos con defecto
282
La lista de verificación logró reducir a cero el número de equipos vendidos con defecto. Sin embargo, los defectos seguían ocurriendo en el taller de montaje de la empresa, durante las pruebas realizadas antes de la venta. Sus proveedores garantizaban que las piezas eran probadas y no presentaban defectos. La única explicación plausible era que algún problema todavía no identificado podría estar ocurriendo en el taller de montaje de Alfa PC. Para llegar a la causa del problema sería necesario realizar un análisis más detallado, utilizando las herramientas que veremos a continuación.
8.3.1.6 Diagramas de Pareto (Pareto Chart) El diagrama de Pareto, también llamado “curva 80-20” o “distribución A-B-C”, es una técnica de organización de datos de forma que estos queden en orden descendente, de izquierda a derecha y separados por barras. Permite, pues, asignar un orden de prioridades. El diagrama permite mostrar gráficamente el principio de Pareto (pocos vitales, muchos triviales), es decir, que hay muchos problemas sin importancia frente a unos pocos graves. Mediante la gráfica colocamos los "pocos vitales" a la izquierda y los "muchos triviales" a la derecha. Su origen proviene de los estudios del economista italiano Wilfredo Pareto32 que desarrolló una teoría que afirmaba que el 80% de la riqueza en Italia estaba en manos de 20% de la población. Siglos más tarde, J. Duran33 utilizó esta teoría para determinar que en tan solo el 20% de las actividades eran responsables por el 80% de los problemas. Por lo tanto, el diagrama de Pareto es una técnica que separa los “pocos vitales” de los “muchos triviales”. Este diagrama consiste en un gráfico de barras que ordena la frecuencia de las ocurrencias por orden de importancia, de la mayor a la menor en un orden decreciente, ilustrando cuales son los problemas o incidencias más significativas y/o cuales son las incidencias que requieren más atención.
¿Cómo se confecciona un diagrama de Pareto? Dando continuidad al ejemplo descrito en la sección anterior, la empresa Alfa PC cuantificó los defectos encontrados en los equipos informáticos que son vendidos en sus tiendas. Fueron identificados ocho tipos de defectos clasificados por componentes. A continuación, se realizó la distribución de la cantidad de defectos por componente y se ordenaron los datos por orden descendente. Se computó el porcentaje que cada componente representa en función del total. A continuación se computaron el porcentaje acumulado que necesariamente tiene que alcanzar el 100%.
283
A
COMPONEN TES Placa base
DEFECT OS 109
27%
% ACUMULADA 27%
B
Disco duro
82
21%
48%
C
Memoria
76
19%
67%
Teclado
20
5%
92%
Ratón
20
5%
97%
TOTAL
400
100%
G
%
Figura 101: Tabla de distribución
Una vez identificados los componentes defectuosos en una tabla de distribución, según ilustra la figura 101, se confecciona el gráfico de Pareto. Para ello, es necesario seguir los pasos que vienen a continuación:
·
Se trazan los ejes horizontales (componentes analizados) y verticales (de cero al total según se ha calculado).
·
De la izquierda a la derecha se trazan las barras para cada componente en orden descendente.
·
Se traza la línea de porcentaje acumulativo, empezando por el componente que acumuló el mayor número de defectos, se van sumando los porcentajes acumulativos. Se diseñan los puntos porcentuales que se conectarán hasta que se alcance el 100%.
Figura 102: Gráfico de Pareto
284
En el caso de la empresa Alfa PC se llegó a una curiosa y hasta entonces desconocida constatación: el 80% de los defectos de los equipos correspondía a problemas en las placas internas de los equipos, y solamente el 20% de los defectos estaba vinculado a los accesorios externos (altavoces, teclado, ratón y monitor). El uso de del diagrama de Pareto fue fundamental para llegar a esta conclusión. Ahora, la empresa Alfa PC es consciente de que el gran problema de sus equipos ocurre en los componentes internos de sus equipos. La pregunta ahora es: “¿cuál es la razón por el cual eso ocurre?”. La solución final de este problema será presentada a continuación, con el diagrama de causa-efecto.
8.3.1.7 Diagrama de causaefecto (Cause and effect diagram) El diagrama de causa-efecto es una presentación gráfica de las causas de un determinado fenómeno. Fue concebido por el ingeniero japonés Kaoru Ishikawa34 en el año 1953 y consiste en una técnica que organiza y representa las diferentes teorías propuestas sobre las causas de un problema. Se conoce también como “diagrama de Ishikawa” o “diagrama de espina de pez” y se utiliza en las fases de diagnóstico y solución de una determinada causa. El ejemplo que sigue intenta identificar las causas por las que los componentes internos de los equipos informáticos montados en el taller de la empresa Alfa PC representan el 80% de los componentes defectuosos. En una sección de brainstorming (descrita en la sección 11.2.1.9), el equipo responsable del montaje de los equipos de Alfa PC intenta identificar las causas principales y secundarias de los defectos en los componentes utilizados en el montaje de sus PC. En este caso, los agentes que influyen directamente en el montaje de los equipos son:
· · · · ·
Los equipos auxiliares de montaje (herramientas, maquinaria). El método (la forma en que se montan los equipos). El material utilizado (la materia-prima incluyendo sus proveedores). El personal (la plantilla del taller y sus encargados). Las instalaciones (luz, mobiliario, espacio físico).
Analizando cada categoría, se identifican las posibles causas que pueden producir defectos.
285
Figura 103: Diagrama de Ishikawa
El resultado es el diagrama que ilustra la figura 103. Fueron identificadas dos causas para cada categoría y muy probablemente una de ellas es la causa real del problema encontrado en los equipos montados por Alfa PC. Una vez identificadas las causas, se buscan soluciones para subsanarlas. Se verifican si las causas encontradas realmente presentan los problemas señalados por el equipo encargado durante la confección del diagrama. Si se comprueban que estos problemas realmente existen, se busca la forma más adecuada de resolverlos.
Figura 104: Solución propuesta
La figura 104 ilustra la ampliación de una de las “espinas” del diagrama. Se puede observar que las instalaciones físicas de la fábrica son poco iluminadas y a la vez producen mucho calor por tratarse de un ambiente poco ventilado. Estos dos factores influyen en el desempeño del personal que trabaja bajo condiciones poco confortables, perjudicando también el funcionamiento de algunos equipos que se sobrecalientan. Eso puede explicar el hecho de que el 80% de los problemas provienen de los componentes internos de los equipos. Quizás esté ahí la raíz del problema que la gerencia de Alfa PC estaba buscando. La solución para esta causa seria la puesta en marcha de las reformas adecuadas para resolver estos problemas. Una vez que ha sido posible identificar otras causas, la gerencia podrá aprovechar para resolverlas, poniendo en marcha las medidas correctivas convenientes.
286
Algunas recomendaciones:
·
Defina el problema que pretende investigar de forma precisa: Es decir, evite términos abstractos o ideas muy genéricas que no permitirán identificar las causas reales.
·
Identifique las causas del problema: La forma más adecuada es hacerlo en reuniones o secciones de brainstorming invitando personas involucradas en el proceso.
·
Se concentre en las causas que realmente pueden ser resueltas: Si son encontradas causas que no podrán ser resueltas por alguna limitación, el diagrama de causa efecto pierde su aplicación práctica.
8.3.1.8 Muestra estadística (Statistical sampling) Esta técnica consiste en recoger una muestra representativa, a partir de un determinado universo de interés. Al elegir esta muestra, se espera que los resultados obtenidos sean fiables al universo total. Este proceso permite la obtención de resultados muy similares a los de un estudio exhaustivo de todo el universo, pero de forma más rápida y menos costosa. En algunos casos, el muestreo puede aportar datos aún más exactos que los de una investigación completa ya que el manejo de un número menor de información reduce la probabilidad de errores en su tratamiento. El tamaño del muestreo será determinado por la organización y deberá obtener un resultado fiable que deberá ser siempre inferior que el del universo total, pero suficiente para que la estimación de los resultados alcance el nivel de confianza adecuado. Un ejemplo de uso de esta técnica son las encuestas electorales (barómetros), que buscan anticipar el ganador de una elección, o los formularios de opinión que buscan a través de un determinado número de personas, conocer la opinión general de la población acerca de un determinado tema de interés (la audiencia de un programa de televisión, la opinión acerca de algún proyecto del gobierno...). El tamaño de la muestra seleccionada puede variar de acuerdo con el tipo de estudio. Existen fórmulas complejas para determinar el porcentaje ideal de la muestra a ser analizada, pero de manera general si el universo contiene menos de cincuenta elementos, no se debe coger muestras. En este caso, se estudiará todo el universo. Cuando se rebasa esta cifra, la muestra deberá tener entre el 10% y el 15% del total de los elementos.
287
En el caso de proyectos, existen muchas situaciones en que se puede utilizar esta técnica, como, por ejemplo, en el caso de un proyecto que conlleve a la producción de una determinada pieza. Si una fábrica produce diez mil piezas de un determinado producto y necesita comprobar su durabilidad, se realizan pruebas en, por ejemplo, el 10% del total de las piezas producidas (es decir, mil piezas), cuyos resultados representarán la totalidad de la producción. Además de fiable (el margen de error suele ser marginal), teóricamente esta muestra estadística solamente habrá consumido el 10% de los recursos necesarios para realizar una prueba en la totalidad de piezas producidas.
Es más ventajoso realizar un estudio de calidad analizando una muestra en lugar de analizar toda la población por varias razones:
·
En algunos casos, la población es muy grande y, por lo tanto, imposible de analizar en su totalidad.
·
Las características o deseos de toda la población pueden variar si el estudio se prolonga demasiado tiempo.
·
Reducción de costes: al estudiar una pequeña parte de la población, los gastos de recogida y tratamiento de datos serán menores que si los obtenemos de su totalidad.
·
Rapidez: el estudio de la muestra reduce el tiempo de recogida y tratamiento de los datos, proporcionando los resultados en menos tiempo.
·
La elección de una muestra permite la realización de estudios que sería imposible hacerlo sobre el total de la población.
·
En algunos procesos es necesario destruir o consumir totalmente un componente para extraer los resultados deseados (por ejemplo: vida útil de una bombilla, carga soportada por una cuerda, precisión de un proyectil...).
8.3.1.9 Análisis de tendencias (Trend analysis)
Descrito en la sección 5.5.1.1
8.3.1.10 Diagramas de
288
flujo (Flowcharts)
Descrito en la sección 8.1.1.7
289
8.3.1.11 Diagramas de interrelación (Interrelationship diagram) El diagrama de interrelación muestra cómo diferentes factores están relacionados entre sí, basándose en causa y efecto. Es una herramienta que ayuda a identificar los aspectos del proyecto que están causando problemas y que son el resultado de otra acción. También muestra la fuerza de cada influencia. El diagrama consiste en un conjunto de círculos (o cajas), que representan cada aspecto que debemos analizar, organizada de forma radial. Las líneas se dibujan entre los círculos para indicar su relación.
Figura 105: Diagrama de interrelación
Principales usos Los diagramas de interrelación pueden ser muy útiles cuando se trata de resolver la causa y el resultado de un problema específico. A pesar de que no se identifican las razones detalladas para el problema, sí nos permiten analizar las causas y los efectos que los aspectos causan unos a otros.
Cómo se desarrolla
·
Se identifica un problema: Se decide cuál es el problema que debe ser solucionado mediante el análisis de sus diversos factores. Se posiciona este problema en el círculo superior del diagrama.
·
Se Identifican los factores: Se realiza una sección de brainstorming (véase también sección 11.2.1.8) para producir todas las cuestiones clave, las ideas, motivos, causas..., para el problema. Se organizan los resultados en los otros círculos del diagrama de forma aleatoria.
·
Se conectan los factores: Se elige cualquiera de los resultados para empezar y se van conectando uno con los otros. Para que la herramienta pueda proporcionar los resultados adecuados, es importante definir qué elemento del diagrama es la causa y qué elemento es el efecto. Con una flecha se enlazan los dos elementos en el orden “causa-efecto”.
290
•
Se define la intensidad: Si un elemento tiene una influencia particularmente fuerte en otro elemento, la flecha que los enlaza debe ser más oscura, si se trata de una relación débil, se utiliza una línea de puntos.
·
Se analiza el diagrama: Cualquier elemento con una gran cantidad de flechas salientes es una causa fundamental del problema. Cualquier elemento con muchas flechas apuntando hacia él es un resultado principal.
·
Se verifica la precisión: Es importante llevar los resultados a un juicio de expertos, para eventualmente añadir otras cuestiones que puedan jugar un papel importante en el problema y luego discutir la forma de resolverlo, centrándose en la principal causa.
8.3.1.12 Diagramas de dispersión (Scatter diagram) Un diagrama de dispersión es un tipo de diagrama matemático que utiliza las coordenadas cartesianas para mostrar los valores de dos variables para un conjunto de datos. Los datos se muestran un conjunto de puntos, cada uno con el valor de una variable que determina la posición en el eje horizontal y el valor de la otra variable determinado por la posición en el eje vertical. Un diagrama de dispersión se puede llamar también “gráfico de dispersión”. Esta herramienta se emplea cuando existe una variable que está bajo el control del experimentador. Si existe un parámetro que se incrementa o disminuye de forma sistemática por el experimentador, se le denomina “parámetro de control” o “variable independiente” y habitualmente se representa a lo largo del eje horizontal. La variable medida o dependiente usualmente se representa a lo largo del eje vertical. Si no existe una variable dependiente, cualquier variable se puede representar en cada eje y el diagrama de dispersión mostrará el grado de correlación (no causalidad) entre las dos variables. Un diagrama de dispersión puede sugerir varios tipos de correlaciones entre las variables con un intervalo de confianza determinado. La correlación puede ser positiva (aumento), negativa (descenso), o nula (las variables no están correlacionadas). Se puede dibujar una línea de ajuste (llamada también "línea de tendencia") con el fin de estudiar la correlación entre las variables. Una ecuación para la correlación entre las variables puede ser determinada por procedimientos de ajuste. Para una correlación lineal, el procedimiento de ajuste es conocido como regresión lineal y garantiza una solución correcta en un tiempo finito. Uno de los aspectos más poderosos de un gráfico de dispersión, sin embargo, es su capacidad para mostrar las relaciones no lineales entre las variables. Además, si los datos son representados por un modelo de mezcla de relaciones simples, estas relaciones son visualmente evidentes como patrones superpuestos. El diagrama de dispersión puede aportar los siguientes resultados: Correlación positiva fuerte: El valor del eje “Y” aumenta así como el valor del eje “X”:
291
Figura 106: Correlación positiva fuerte
Correlación negativa fuerte: El valor del eje “V” disminuye así como el valor del eje “X”:
Figura 107: Correlación negativa fuerte
Correlación positiva débil: El valor del eje “V” aumenta superficialmente, así como el valor del eje “X”:
Figura 108: Correlación positiva débil
292
Correlación negativa débil: El valor del eje “Y” disminuye superficialmente, así como el valor del eje “X”:
Figura 109: Correlación negativa débil
Correlación compleja: El valor de “Y” parece tener relación con el valor de “X”, pero esta relación no es fácilmente determinada:
Figura 110: Correlación compleja
Sin correlación: No hay cómo comprobar una conexión entre las variables.
Figura 111: Sin correlación
293
8.3.1.13 Diseño de experimentos (Design of experiments) Desarrollada por Ronald Fisher35, considerado como el padre del diseño experimental, esta herramienta es un método estadístico que identifica los factores que pueden influir en variables específicas de un producto o proceso en fase de desarrollo de producción. El diseño experimental es una técnica estadística que permite identificar y cuantificar las causas de un efecto dentro de un estudio experimental. En un diseño experimental se manipulan deliberadamente una o más variables, vinculadas a las causas, para medir el efecto que tienen en otra variable de interés. El diseño experimental prescribe una serie de pautas relativas a qué variables hay que manipular, de qué manera, cuántas veces hay que repetir el experimento y en qué orden para poder establecer con un grado de confianza predefinido la necesidad de una presunta relación de causa-efecto.
Ejemplo de aplicación: Se pretende evaluar la resistencia de una pieza metálica sometida a temperaturas cambiantes. La pieza puede ser elaborada con tres tipos de metales distintos. De ahí que se plantee las siguientes preguntas:
·
¿Qué efecto tienen la composición de la pieza y la temperatura en la resistencia de la pieza?
·
¿Existe algún material con el que la pieza resulte más resistente que con cualquiera de los otros dos independientemente de la temperatura?
Para darles respuesta, se realiza una serie de experimentos. Cada uno de ellos consiste en tomar una pieza de un material dado, someterla a una temperatura prefijada y aplicarle una presión hasta que la pieza se quiebre. El grado de presión necesario será la medida de resistencia de la pieza. Por fijar ideas, se seleccionan tres temperaturas, -20°C, 20°C y 60°C. Por lo tanto, se realizarán nueve pruebas, (tres temperaturas diferentes por tres tipos de metal). Para dar más credibilidad a los resultados de las pruebas, se repite cada una de las nueve pruebas cuatro veces cada una. Normalmente, se realizan las pruebas de forma aleatoria. Tras realizar los experimentos, se obtiene 36 resultados, es decir, 4x9 medidas de resistencia distintas. A partir de ese momento, se realiza un estudio cuantitativo utilizando técnicas estadísticas, que ya no forman parte propiamente de la fase del diseño experimental.
8.3.1.14 Histogramas (Histograms) La palabra “histograma” tiene origen en el vocablo griego “histos”, que significa “tela”. Por otro lado, la palabra “gramma” significa “letra” o “texto”. Se considera que la unión de estas dos palabras ha resultado en el nombre “histograma”, tal y como lo conocemos actualmente. No obstante, existe una otra versión (quizás la más verosímil), que defiende que este término ha sido creado en 1895, por Karl Pearson36, un prominente científico y matemático, que estableció la disciplina de la estadística matemática. 294
Un Histograma es un tipo especial de gráfico de barras que despliega la variabilidad dentro de un proceso. Su técnica empieza con la toma datos variables, tales como alturas, pesos, densidades, tiempo, temperaturas, entre otros, y despliega su distribución. Los patrones inusuales o sospechosos pueden indicar que un proceso necesita investigación para determinar su grado de estabilidad. Distinta del Pareto, cuya finalidad es priorizar acciones para la mejoría, el histograma permite la interpretación de grandes volúmenes de datos sobre una determinada variable que deseamos analizar. Su diseño presenta diferentes configuraciones, acorde con el resultado que genere, según la naturaleza, calidad y cantidad de datos utilizados en su confección. A continuación, veremos los resultados más comunes encontrados en los histogramas.
Los datos indican una distribución normal. Se puede concluir que el proceso es estable.
Figura 112: Simétrico, forma de campana (normal)
Los datos están hacia la izquierda de la media. La distribución no es normal y el proceso debe ser investigado.
Figura 113: Diagrama (izquierda) negativo
Los datos están hacia la derecha de la media. La distribución no es normal y debe ser investigado.
295
Figura 114: Diagrama (derecho) positivo
Los datos pueden venir de dos procesos diferentes. Por ejemplo, es posible que datos de la operación de día y de noche hayan sido combinados para formar el histograma.
Figura 115: Bimodal
8.3.1.15 Diagrama matricial (Matrix diagrams) El diagrama matricial es una herramienta utilizada para identificar las relaciones que pudieran existir entre dos o más factores, sean problemas, causas y procesos, métodos y objetivos, o cualquier otro conjunto de variables. Una aplicación frecuente de este diagrama es el establecimiento de relaciones entre requerimientos del cliente y características de calidad del producto o servicio. Tiene las siguientes finalidades:
·
Visualizar claramente los patrones de responsabilidad para que haya una distribución pareja y apropiada de las tareas.
·
Ayudar al equipo a llegar a un consenso en relación a pequeñas decisiones, mejorando la calidad de, y el apoyo a, la decisión final.
·
Mejorar la disciplina de un equipo en el proceso de observar minuciosamente un gran número de factores de decisión importantes.
296
Cómo se desarrolla un diagrama matricial La confección del diagrama matricial se realiza básicamente a través de seis pasos:
1.
Definir el objetivo de la construcción del diagrama.
2.
Establecer el tipo de diagrama que será utilizado.
3.
Identificar los factores correspondientes a cada uno de los tipos implicados en el estudio.
4.
Dibujar el diagrama.
5.
Identificar y establecer la intensidad de las relaciones entre los factores de los diferentes tipos.
6. Rotular el diagrama y añadir la información relevante. Estos pasos serán ampliamente detallados a continuación: PASO 1: Definir el objetivo de la construcción del diagrama: Para empezar el proceso de desarrollo del diagrama matricial es necesario establecer el objetivo del estudio que será realizado para poder identificar los tipos de factores que deben intervenir en el análisis. La definición “tipo” se entiende como “un conjunto de factores que tienen una característica común para su agrupación” (por ejemplo: Tipo A: características del servicio, Tipo B: necesidades del cliente). Para que la herramienta pueda ser viable, el número de tipos implicados podrá ser como máximo cuatro.
PASO 2: Establecer el tipo de diagrama que será utilizado: En función del resultado del paso anterior (número de tipos de factores implicados en el análisis), se elige el tipo de diagrama más adecuado. Son cinco los tipos más utilizados:
· · · · ·
Matriz tipo “L”. Matriz tipo “A”. Matriz tipo “T”. Matriz tipo “Y”. Matriz tipo “X”.
MATRIZ TIPO “L”: Es la más básica de las cinco, y se utiliza para representar relaciones entre dos factores distintos (“A” y “B”), mediante una disposición de columnas y filas. Ejemplo: En la columna de tipos “B” se pueden enumerar las “necesidades del cliente” y en la fila de tipos “A”, “características del servicio”.
297
Figura 116: Matriz tipo “L”
MATRIZ TIPO “A”: Es un caso particular de la matriz tipo “L”. Se utiliza básicamente para representar las relaciones entre los factores que componen un tipo determinado. Por ejemplo, el tipo “A”, “características del servicio”.
Figura 117: Matriz tipo “A”
MATRIZ TIPO “T”: Se trata de una combinación de 2 diagramas matriciales de tipo “L”. Su principal característica es la posibilidad de representar las relaciones entre 3 tipos de factores distintos (“A”, “B” y “C”, agrupándolos de la siguiente forma: Relaciones entre el tipo “A”, las “características del servicio” y el tipo “B”, “necesidades del cliente” o relaciones entre el tipo “A” “características del servicio” y un tercer tipo, el “C”, “características del servicio de la competencia”.
298
Figura 118: Matriz tipo “T”
MATRIZ TIPO “Y”: Es la combinación de tres diagramas tipo “L”. Se utiliza básicamente para representar las relaciones entre tres tipos distintos (“A”, “B” y “C”), agrupándolos de una forma diferente al tipo “T”:
·
Relaciones entre el tipo “A”, “características del servicio” y el tipo “B”, “necesidades del cliente”.
·
Relaciones entre el tipo “B”, “necesidades del cliente” y el tipo “C”, “características del servicio de la competencia”.
·
Relaciones entre el tipo “C” “características del servicio de la competencia”. y el tipo “A”, “características del servicio”.
Figura 119: Matriz tipo “V”
299
MATRIZ TIPO “X”: Es la combinación de 4 diagramas tipo “L”. Se utiliza básicamente para representar, de esta vez, las relaciones entre cuatro tipos distintos (“A”, “B”, “C” y “D”):
·
Relaciones entre el tipo “A”, “características del servicio” y el tipo “B”, “necesidades del cliente”.
·
Relaciones entre el tipo “B”, “necesidades del cliente” y el tipo “C”, “características del servicio de la competencia”.
·
Relaciones entre el tipo “C”, “características del servicio de la competencia” y el tipo “D”, “precio”.
Relaciones entre el tipo “D”, “precio” y el tipo “A”, “características del servicio”. Figura 120: Matriz tipo “X”
PASO 3: Identificar los factores correspondientes a cada uno de los tipos implicados en el estudio: La identificación de los factores integrantes de cada tipo puede ser realizada a través de una herramienta auxiliar de toma de datos, como por ejemplo:
· · · ·
Tormenta de Ideas: Descrita en la sección 11.2.1.8; Entrevistas: Descrita en la sección 5.1.1.1; Técnica Delphi: Descrita en la sección 6.4.1.7; Juicio de Expertos: Descrita en la sección 4.1.1.1.
300
PASO 4: Dibujar el diagrama El diagrama será confeccionado según el modelo elegido y acorde con la necesidad y el tipo y numero de factores que serán analizados. Tomaremos como ejemplo, la confección de un diagrama de tipo “L”, que deberá cumplir con los siguientes requisitos:
·
Establecer los tipos que serán representados en las respectivas columnas y filas;
·
Dibujar tantas filas y columnas como factores tengan los tipos correspondientes, añadiéndoles un espacio para cada tipo;
·
Rotular los factores pertenecientes a cada tipo en las filas y columnas. Un buen
entendimiento del diagrama exigirá que los rótulos elegidos sean claros y autoexplicativos
MODELO DE RADIO
Memoria
PC 1
PC 2
PC 3
PC 4
PC 5
PC 6
Disco duro Procesad or Altavoce s Teclado Figura 121: Diagrama matricial en “L” de un ordenador personal
PASO 5: Identificar y establecer la intensidad de las relaciones entre los factores de los diferentes tipos Este es un paso fundamental para extraer la información precisa del diagrama matricial. Este paso se ejecuta básicamente en cuatro acciones:
1.
Primero, se toma el primer elemento de las filas y se repasa cada uno de los elementos de las columnas, identificando todos los que están relacionados con aquél.
2.
Se determina la intensidad de la relación entre los factores. Para ello, se pueden utilizar las mismas herramientas mencionadas el paso 3.
3.
Se utilizan símbolos para representar las escalas de intensidad, que son establecidas con un mínimo de dos niveles y un máximo de 4. Las escalas más comúnmente utilizadas internacionalmente son las siguientes:
301
Figura 122: Símbolos de intensidad
4. Distribuir los símbolos de intensidad en las casillas correspondientes:
MODELO DE RADIO
Memoria
PC 1 0
Disco duro Procesad or Altavoce s Teclado
PC 2 0
PC 3 0
PC 4
PC 5
PC 6
S
0
0
S
S
S
0 S S
Figura 123: Diagrama matricial en “L” completo
PASO 6: Rotular el diagrama y añadir la información relevante Para finalizar el diagrama, se añaden informaciones complementares de identificación (título, legenda y/o cualquier otra información considerada oportuna), para facilitar su entendimiento por cualquiera de los implicados en el proyecto. MODELO DE RADIO
Memoria
PC 1 0
Disco duro Procesad or Altavoce s Teclado
PC 2 0
PC 3 0
PC 4
PC 5
PC 6
S
0
0
S
S
S
0 S S
• = Relación fuerte
0 = Relación débil 302
Las evaluaciones se basan en los datos de todas las reparaciones efectuadas en el taller de reparación en un mes. Figura 124: Diagrama matricial con elementos explicativos
Observaciones generales con respecto a algunas deficiencias que esta herramienta puede presentar: La confección de un diagrama matricial se realiza, basándose normalmente en datos subjetivos, como por ejemplo, la opinión de expertos o entrevistas con profesionales veteranos. Esto da lugar a la deficiencia más habitual en su interpretación: confundir esta disposición de las relaciones y su intensidad con los datos reales, sin una comprobación empírica previa. El diagrama matricial debe ser utilizado, por lo tanto, como un guía en el análisis del tema en estudio y es necesario comprobar la exactitud de las ideas que de su interpretación se obtengan. Las causas posibles de inexactitudes en la asignación de intensidades a las relaciones serán: .
.
.
El uso de datos obsoletos. Evaluación tendenciosa de expertos (visión subjetiva, desconocimiento parcial del tema, entre otros). Evaluaciones superficiales sin contar con expertos.
Otra de las principales causas de deficiencias en la interpretación del diagrama matricial es la falta de elementos o factores clave en el análisis del tema en estudio. En general, este hecho se produce por la deficiente utilización de las herramientas utilizadas para su identificación.
303
8.3.1.16 Matriz de priorización (Prioritization matrix) La matriz de priorización es una técnica muy utilizada cuando es necesario priorizar problemas u obtener un consenso acerca de una determinada cuestión. Sus resultados permiten ver con claridad cuáles son los problemas más importantes sobres los que se debe trabajar primero. Esta técnica se elabora de la siguiente forma:
·
Se lleva a cabo una tormenta de ideas (véase también sección 11.2.1.8) sobre los problemas detectados en el proyecto.
·
Se cumplimenta la matriz de priorización, conforme ilustra la figura 125. En la primera columna se ponen los problemas detectados en la tormenta de ideas. De la segunda a la cuarta columna se establecen los criterios, que pueden ser: frecuencia, importancia, factibilidad, probabilidad, impacto, costes... Los criterios son libres y si bien existe un número ilimitado de criterios, tres o cuatro es la cantidad recomendada para confeccionar correctamente una matriz. Los problemas deberán ser priorizados, de acuerdo con la suma de los puntos presentada en la matriz.
·
X
FRECUEN CIA 10
IMPORTAN CIA 10
FACTIBILID AD 50
PUNTO S 70
Y
15
5
35
55
Z
5
10
20
35
PROBLEMA
Figura 125: Matriz de priorización básica
8.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I Cambios validados. Véase sección 5.5 (Validated changes)
I Entregables validados. Véase sección 2.4 (Validated deliverables)
I Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I DOC nº 039 – Solicitudes de cam bio (Change requests)
I DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates) 304
Capítulo 9 Gestión de los recursos humanos “Ningún grupo puede actuar con eficacia si falta el concierto, ningún grupo puede actuar en concierto si falta la confianza, ningún grupo puede actuar con confianza si no se halla ligado por opiniones comunes, afectos comunes, intereses comunes” Edmund Burke37, escritor, orador y filósofo irlandés
305
Algunas cosas en las que NO puedes pensar acerca de la gestión de los recursos humanos “No tenemos tiempo para dar formaciones al equipo. Ya irán aprendiendo sobre la marcha” Una importante cantidad de proyectos fracasan a un ritmo impresionante, casi en la mitad de los casos, según algunas estimaciones. Curiosamente, un gran número de empresas que han pasado por la mala experiencia de asumir el fracaso de un proyecto, contaban con los procedimientos y la documentación adecuada, y además, tenían una estructura apropiada, además de estar económicamente preparadas para afrontar un gran proyecto. Uno de los factores clave del fracaso de un proyecto es la falta de formación adecuada. Desde de la antigüedad, la capacitación de todos los eslabones que forman un emprendimiento ha sido condición necesaria para que la misma pueda sacar el máximo rendimiento de sus proyectos y para que encuentre su camino hacia la excelencia. “No pierdas tiempo con un proceso selectivo que nos costará tiempo y dinero. Tengo un primo que está en el paro y seguro que sirve para el puesto” Desconozco el currículo del primo del autor de esta frase, pero si hay un factor que determina el éxito o el fracaso de un proyecto es la capacidad profesional y las habilidades de cada una de las personas involucradas. El PMDCF (Project Manager competency development framework) es una guía publicada por el PMI que establece, entre otras cosas, las tres dimensiones básicas para el desarrollo correcto de las competencias de un Project Manager, y por qué no decirlo, de cualquier profesional asignado a un proyecto. Estas dimensiones se dividen en “conocimiento” (se refiere al conocimiento que el profesional debe poseer con respecto a la aplicación de los procesos, herramientas y técnicas en las actividades del proyecto), “desempeño” (se refiere a como un profesional debe emplear su conocimiento para conseguir los requisitos u objetivos del proyecto) y “comportamiento” (se refiere a como un profesional se comporta ante un determinado contexto o ambiente de proyecto). Formar parte de un proyecto conlleva asumir unas responsabilidades que requieren la correcta selección de profesionales capacitados.
Introducción Cada proyecto tiene características propias que demandarán profesionales de diferentes áreas. Hay proyectos que necesitan un equipo muy grande y hay otros que pueden ser ejecutados con un grupo de profesionales más limitado. Conseguir el personal adecuado, decidir qué hacer con el equipo tras la conclusión del proyecto y, sobre todo, cómo distribuir correctamente el tiempo de cada profesional en diferentes proyectos simultáneos, son los grandes desafíos que implican la gestión de los recursos humanos. Definitivamente, un proyecto no se resume solamente en su alcance, los plazos y los costes asignados para ponerlo en marcha. Uno de los factores clave más importantes para el éxito de un proyecto es tener a disposición las personas adecuadas en los momentos oportunos, que es sin duda, una combinación muy difícil de obtener. Es una fórmula que el Project Manager intentará buscar constantemente.
306
En muchas empresas, algunos recursos son asignados a un proyecto sobre todo porque están disponibles y no porque son la mejor elección. Realmente, un equipo debería ser montado solamente cuando se haya conocidos los requisitos técnicos del proyecto. De esta forma, es más fácil escoger el perfil del profesional adecuado. No obstante, las empresas normalmente no pueden darse el lujo de contar con una plantilla muy amplia. Lo más común es asignar el mismo profesional a muchos proyectos a la vez. La regla general normalmente es: se asigna quien esté disponible. La asignación de profesionales para un proyecto es una de las preocupaciones más importantes de un Project Manager. El alma del proyecto son las personas que lo desarrollan. Cada trozo de un proyecto lleva la “firma” de sus ejecutores, y esta es una de las muchas razones por las cuales es muy importante poder contar con los recursos adecuados. Un proyecto según lo definido en el capítulo 1, “es realizado por personas”. Puede ser desarrollado por una única persona o por todo un departamento. Puede involucrar una pequeña oficina o pueden cruzar fronteras afectando a decenas de multinacionales. Además, un proyecto es afectado por una serie de agentes internos y externos que ejercen a todo momento, de una forma u de otra, su influencia sobre él, pudiendo incluso, impactar negativa o positivamente en sus resultados.
Figura 126: Los interesados de un proyecto
Todas las personas involucradas, directa o indirectamente en el proyecto son llamados “interesados” (en inglés, stakeholders). Un interesado se caracteriza principalmente en función de su influencia o participación en el proyecto, como por ejemplo:
· · · ·
Asumir pérdidas o ganancias acorde con el resultado final. Proveer fondos al proyecto. Invertir recursos humanos o infraestructura. Participar activamente en los procesos de planificación, control y ejecución.
307
Tal y como ilustra la figura 126, los interesados tanto pueden ser personas como pueden ser departamentos o empresas. El Project Manager, además de controlar la ejecución del proyecto y hacer con que las actividades avancen según el plan establecido, deberá tener la capacidad de gestionar las expectativas de los interesados del proyecto. Muchos de ellos se relacionan entre sí, y normalmente ocurren conflictos que pueden ser de todo tipo: filosóficos, culturales, profesionales, personales, administrativos, políticos, etcétera. Los Interesados pueden además tener diferentes prioridades, formas distintas de trabajar, o incluso formas diferentes de enfrentar un riesgo. El Project Manager necesitará, por lo tanto, buscar constantemente un punto de equilibrio que logre mantener una constante armonía en las relaciones establecidas durante el desarrollo del proyecto.
El equipo del proyecto El equipo del proyecto se define como un grupo de personas de conocimientos diversos, que se complementan en función del proyecto, y donde se les asignan responsabilidades y objetivos concretos. Para que su trabajo en equipo funcione eficazmente, sus esfuerzos individuales necesitan coordinación, como un equipo de fútbol, donde esta coordinación es realizada por el entrenador que dedica horas de entrenamientos, formaciones tácticas y jugadas ensayadas. Algunos integrantes del equipo trabajan en momentos muy puntuales del proyecto, otros estarán presentes desde el comienzo hasta el cierre de los trabajos. Generalmente, es formado por los empleados de la empresa encargada de la ejecución del proyecto, pero también podrá incluir profesionales de otras empresas y en muchos casos algún representante del cliente. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de los recursos humanos de un proyecto incluye procesos y actividades necesarios para organizar, gestionar y conducir el equipo del proyecto. Son ellos:
· · · ·
Desarrollar el plan de recursos humanos. Adquirir el equipo del proyecto. Desarrollar el equipo del proyecto. Dirigir el equipo del proyecto.
9.1 Desarrollo de los recursos humanos (Proceso que corresponde a la fase de planificación del proyecto) Acorde con el PMBOK®, el desarrollo de los recursos humanos es el proceso por el cual se identifican y documentan los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación, y se crea el plan para la dirección de personal. La planificación de los recursos humanos se utiliza para determinar e identificar aquellos recursos humanos que posean las habilidades requeridas para el éxito del proyecto. El plan de recursos humanos documenta los roles y responsabilidades dentro del proyecto, los organigramas y el plan para la dirección de personal, incluyendo el cronograma para la adquisición y posterior liberación del mano de obra. También puede incluir la identificación de necesidades de capacitación, las estrategias para fomentar el espíritu de equipo, los planes de reconocimiento y los programas de recompensas, las consideraciones en torno al cumplimiento, los asuntos relacionados con la seguridad y el impacto del plan para la dirección de personal a nivel de la organización.
308
9.1.1 Técnicas y herramientas 9.1.1.1 Organigramas (Organization charts) Es una representación gráfica de la estructura de una organización que permite de forma muy sencilla y visual distinguir las estructuras departamentales y en algunos casos, las personas que las dirigen, haciendo un esquema sobre las relaciones jerárquicas en vigor en la organización. Se compone a través de rectángulos que representan los departamentos y puestos ocupados por cada integrante de la organización. La unión de estos rectángulos es representada por líneas que determinan los canales de la jerarquía.
Figura 127: Organigrama
El organigrama no debe contener toda la información necesaria para conocer como es la estructura de una empresa, no obstante debe cumplir los siguientes requisitos:
· ·
Ser fácil de entender y sencilla de utilizar. Contener únicamente los elementos indispensables.
El diseño de un organigrama es libre, pero existen diferentes tipos que reúnen algunas características especiales:
·
Organigrama vertical: Muestra las jerarquías según una pirámide, de arriba abajo.
·
Organigrama horizontal: Muestra las jerarquías de izquierda a derecha.
·
Organigrama mixto: Es una combinación entre el horizontal y el vertical.
·
Organigrama circular: La autoridad máxima está en el centro, alrededor de él se forman círculos concéntricos donde se nombran a los jefes inmediatos.
·
Organigrama escalar: Se usan sangrías para señalar la autoridad, cuanta mayor es la sangría, menor es la autoridad de ese cargo.
309
9.1.1.2 Relaciones de Trabajo o Redes Sociales (Networking) Según el sociólogo francés Joseph Folliet38, en su obra, El hombre Social - Ensayo de Antropología Social, “por lejos que nos remontemos en el pasado histórico, lo encontramos (al hombre) siempre viviendo en sociedad”. Es decir, desde tiempos muy remotos, el hombre se dio cuenta que no lograría supervivir en un mundo hostil si no se aliara a sus semejantes. Desde entonces, y durante toda la evolución del hombre hasta los días actuales, nos hemos encontrado con la necesidad de vivir en sociedad. La “técnica” de reunir un grupo de personas para actuar en conjunto con el objetivo de lograr un objetivo común, ha recibido el nombre de networking. Entre otros factores, ha sido el networking que ha posibilitado a la humanidad de avanzar y progresar a través de los siglos. Para poner un ejemplo histórico, Cristóbal Colón 39 solo ha podido llevar adelante su plan de crear una nueva ruta hacia las indias por el océano Atlántico, porque había logrado, a través de su red de contactos, acceder a los Reyes Católicos (Fernando II de Aragón40 e Isabel I de Castilla41), que aportaron los fondos necesarios para poner en marcha su proyecto, que culminaría posteriormente con el descubrimiento de un nuevo continente. El proyecto de Colón39 no es distinto de un proyecto empresarial, puesto que contempla una serie de riesgos, de restricciones financieras, de cumplimiento de plazos y depende, sobre todo, del apoyo de un grupo de interesados. En la actualidad principalmente la calidad de la red social de una persona, que le posibilitará transformar buenas oportunidades en grandes proyectos. Las redes sociales son de lo más fuerte que hay en internet actualmente y es un fenómeno que se debe gracias al poder de comunicación que la internet puede proporcionar. En ellas podemos compartir opiniones, fotos, videos y una infinidad de información a nuestra red de contactos. Las redes sociales más populares en internet son el Facebook, el Twitter y el Hi5, además de los blogs y de los foros.
9.1.1.3 Matriz de responsabilidades (Responsibility assignment matrix - RAM) Delegar es una de las acciones primarias de un Project Manager y, para hacerlo de forma adecuada, es importante identificar los roles y responsabilidades del proyecto lo antes posible. Para ello, se utiliza la matriz de responsabilidades (responsabilitiy assignment matrix – RAM, también conocida como RACCI – sigla que significa las atribuciones: responsible, ccountable, consulted, informed), es decir:
310
ROL
DESCRIPCIÓN
R
Responsibl e
Responsabl e
A
Accountabl e
Aprobador
C
Consulted
Consultado
I
Informed
Informado
Este rol realiza el trabajo y es responsable por su realización. Lo más habitual es que exista solo un R, si existe más de uno, entonces el trabajo debería ser subdividido a un nivel más bajo, usando para ello las matrices RASCI. Es quien debe ejecutar las tareas. Este rol seencarga de aprobar el trabajo finalizado y a partir de ese momento, se vuelve responsable por él. Solo puede existir un A por cada tarea. Es quien debe asegurar que se ejecutan las tareas. Este rol posee alguna información o capacidad necesaria para terminar el trabajo. Se le informa y se le consulta información (comunicación bidireccional). Este rol debe ser informado sobre el progreso y los resultados del trabajo. A diferencia del consultado, la comunicación es unidireccional.
Figura 128: Matriz RACI
También existe la matriz RASCI, que es una variación de la RACI. La única diferencia es la adición de un nuevo rol: el de soporte. ROL S
Supportive
DESCRIPCIÓN Soporte
Este rol proporciona para realizar el trabajo.
recursos adicionales
Figura 129: Matriz RASCI
En la matriz RACI o en la RASCI, se asignan el rol que cada recurso deberá ejecutar para cada actividad del proyecto. No es necesario incluir los cuatro o cinco roles en la misma actividad, pero estas deberían contar con por lo menos el de encargado y responsable. Esta herramienta se utiliza muy frecuentemente en conjunto con la EDT (Véase también sección 5.3), donde se recogen las actividades identificadas del proyecto, y a través de la RACI se complementa con los recursos asignados.
311
Existe una infinidad de herramientas similares que agregan nuevos roles, las más comunes son:
RAC I-VS o VARISC Al igual que la RASCI, es una variación de la RACI. Los roles adicionales son: ROL V
Verify
DESCRIPCIÓN
Verificador
Este rol se encarga de comprobar si el producto es acorde a los criterios de aceptación establecidos en la descripción del producto.
Figura 130: Matriz VARISC
RACIO Esta es una versión ampliada, basada en el estándar RACI, con un tipo de participación adicional. ROL O
Omitted
DESCRIPCIÓN Omitido
Establece los individuos o grupos que no forman parte de la tarea. Especificar que un recurso no participa puede ser tan beneficioso para la
Figura 131: Matriz RACIO
312
RSI Es la variación utilizada por el PMI - Project Management Institute ROL
DESCRIPCIÓN
R
Responsibl e
Responsab le
S
Sponsor
Patrocinad or
I
Informed
Informado
Son los encargadosde ejecutar la actividad. Tiene la responsabilidad de finalizar la tarea según el alcance definido, obedeciendo los plazos y costes establecidos. También tienen poderes de Es el propietario del proyecto o de la actividad. Es el rol encargado de firmar la aceptación de la actividad una vez que esté finalizada. Son roles que no participan directamente, pero que necesitan estar informados acerca de la evolución de las actividades y/o del proyecto como un todo.
Figura 132: Matriz RSI
Otras variaciones de matriz de responsabilidades:
·
DACI: Versión más utilizada para centralizar la toma de decisiones y aclarar los roles que pueden levantar cuestiones acerca del proyecto. Incluye los siguientes roles: conductor (driver), aprobador (approver), contribuyente (contributor) e informado (informed).
·
PARIS: Incluye los roles: primario (primary) que es básicamente el responsable por la actividad, asignado (assigned), revisión necesaria (review required), entrada requerida (input required) y firma requerida (signature required).
·
OARP: Al igual que con los otros modelos, este modelo se utiliza para la designación de roles en el proceso de toma de decisiones. Incluye el propietario (owner), aprobador (approver), crítico (reviewer) y participante (participant).
9.1.1.4 Estructura de desglose de la organización – EDO (Organization breakdown structure - OBS) La estructura de desglose de la organización es una descripción jerárquica de la organización del proyecto, como si de un organigrama se tratara, y según ilustrado en la figura 127.
313
No obstante, su función es potencializada cuando sus datos son combinados con los paquetes del trabajo establecidos en la estructura detallada de trabajo – EDT (véase también sección 5.3) y con las unidades ejecutantes de la organización que se encuentran en la matriz de responsabilidades (véase también la siguiente sección). En otras palabras, se utilizada la EDO de la siguiente forma, tal y como se puede apreciar en la figura 128:
·
Para combinar la EDT, la RAM y la EDO, es fundamental que todo el alcance previsto en la EDT esté completamente establecido y aprobado por la dirección.
·
Se coge entonces la EDO de la organización, y a través de la RAM, se define quienes serán los encargados de cada actividad de la EDT y cuáles serán sus roles y responsabilidades.
·
Es importante además consultar el calendario de la organización para certificarse de que los recursos de la EDO estarán disponibles para el proyecto.
·
Definida la EDT y la RAM y conociendo cuáles serán los recursos disponibles, es posible combinar sus datos y entonces, empezar el desarrollo del diagrama de red del proyecto (véase también sección 6.2.1.1), que servirá de base para confeccionar el cronograma del proyecto.
Figura 133: Relación entre EDT, EDO y RAM
9.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 022 – Plan de gestión de los recursos humanos (Human resources management plan)
314
9.2 Adquisición de personal (Proceso que corresponde a la fase de ejecución del proyecto) El éxito de un proyecto depende mucho de la capacidad y de las habilidades del Project Manager y su equipo. Cuando nos encontramos en la fase de adquisición de personal no podemos limitarnos a realizar una selección considerando solamente el conocimiento técnico necesario para llevar a cabo las actividades del proyecto. Es importante que exista una química favorable entre el Project Manager y su equipo, y principalmente entre los propios miembros del equipo. Poder contar con gente que, además de poseer los conocimientos adecuados, estén motivados y tengan ganas de trabajar en equipo, estimularán la unión, la sinergia y la armonía. En algunos casos, el Project Manager podrá equivocarse a la hora de elegir los integrantes de su equipo, pero esto es uno de los riesgos que deberán ser considerados. Normalmente, un equipo de proyecto está estructurado por tres componentes:
· · · ·
El Project Manager. El líder técnico. El equipo de la plantilla. El equipo subcontratado.
El Project Manager Es el líder del proyecto. Es el responsable de hacer cumplir los plazos planificados, los costes asignados en el presupuesto y el alcance de acuerdo con las especificaciones establecidas. Es el Project Manager quien representa el proyecto para la organización y para el cliente.
¿Cuál es el momento adecuado de elegir el Project Manager? No hay una regla sobre el momento adecuado para elegir el Project Manager. Naturalmente, esta elección deberá ocurrir en el momento que se publica el acta de constitución del proyecto (project charter, descrito en el Apéndice A, doc nº 001). Normalmente, el Project Manager no es asignado hasta que el proyecto es aprobado por la organización. Por regla general, y según algunos autores, el momento más adecuado para la entrada de un Project Manager en un proyecto es inmediatamente después de la firma del contrato entre el cliente y la empresa adjudicataria del proyecto. Cuanto más temprano esté involucrado, mayores serán las posibilidades de ejecutar el proyecto con más seguridad. Esto también vale para otros integrantes cuya experiencia pueda ser muy útil en la fase inicial de planificación del proyecto. Todo conocimiento que se puede aportar en la fase de planificación será muy beneficioso para las fases a continuación
El equipo de la plantilla Son los que realmente ejecutarán el proyecto, tendrán que tomar decisiones importantes (sobre todo técnicas) y tendrán la difícil misión de cumplir los planes establecidos. ¿Cuando se eligen los integrantes del equipo del proyecto?
315
Dependerá del papel que cada integrante tendrá en el proyecto y también en qué fase del proyecto participarán. En el caso de la construcción de un edificio, el pintor empezará a actuar, por ejemplo, en la fase final. Por otro lado, el personal de excavaciones entrará en el comienzo. Ingenieros, y aparejadores serán asignados antes de la fase de ejecución de las obras, puesto que sus conocimientos serán muy útiles a la hora de estimar plazos y actividades. Como en el caso del Project Manager, los integrantes de un proyecto pueden estar asignados a más de un proyecto simultáneamente, fraccionando sus tiempos de trabajo. Por ejemplo: 25% en el proyecto “A”, 50% en el proyecto “B” y 25% en el proyecto “C”. Mientras este trabajador no termine sus trabajos en unos de estos tres proyectos, no podrá ser asignado a ningún otro más. Es importante establecer una sincronía entre los cronogramas en que un mismo integrante este adjudicado, para evitar que este su tiempo disponible se solape.
El equipo subcontratado Actualmente las empresas están subcontratando mucha mano de obra externa para la ejecución de sus proyectos. Es una forma efectiva de reducción de costes y también de riesgos. En muchos casos se trata de profesionales muy especializados que se incorporan al equipo en el momento en que las actividades por las cuales fueron asignados empiezan. Al finalizarlas, ellos dejan el proyecto y retornan a sus empresas.
Implicaciones en utilizar recursos subcontratados en un proyecto Como comentado anteriormente, la subcontratación de mano de obra conlleva a asumir una serie de riesgos que deberán ser considerados:
·
El cronograma no podrá sufrir muchas variaciones en los plazos, pues es posible que el recurso contratado no este disponible.
·
Su compromiso a veces no corresponde a las expectativas del Project Manager, pues en muchos casos este tipo de recurso tiene otras prioridades. Este factor puede influir directamente en la calidad de su trabajo.
·
Como en muchos casos el recurso subcontratado no suele acompañar toda la evolución del proyecto es necesario dedicar un tiempo importante para situarle en el estado actual de los trabajos realizados.
9.2.1 Técnicas y herramientas 9.2.1.1 Asignación previa (Pre-assignment) Existen proyectos que, por su naturaleza, demandan una promesa de recursos humanos previa a su aprobación, como puede pasar en los siguientes casos:
·
Licitaciones públicas cuyo concurso exige que la empresa participante ya cuente 316
con un grupo de profesionales contratado.
317
•
El proyecto tiene un objetivo tan específico, que necesita de la experiencia de determinados profesionales extremadamente especializados (por ejemplo, el estudio de una vacuna, o la modernización de toda red de telefonía de un país).
En casos como los anteriormente descritos, la organización tendrá que anticipar todo el proceso de selección, para de esta forma asegurar al contratante de que dispone de toda la plantilla necesaria para su puesta en marcha. La asignación previa es una técnica que tiene un cierto grado de riesgo, puesto que proyectos como los que demandan un alto nivel tecnológico, necesitan de presupuestos muy elevados, y por ello, pueden tardar meses en empezar, o incluso no llegar a llevarse a cabo.
9.2.1.2 Negociación (Negotiation) En muchos proyectos, las asignaciones de personal se negocian. Por ejemplo, el equipo de dirección del proyecto podría necesitar negociar con:
·
Gerentes funcionales, para asegurar que el proyecto reciba personal con las competencias apropiadas dentro del plazo necesario y que los miembros del equipo del proyecto cuenten con la capacidad, disposición y autorización necesarias para trabajar en el proyecto hasta completar sus responsabilidades.
·
Otros equipos de dirección del proyecto dentro de la organización ejecutante a fin de asignar de forma adecuada recursos humanos escasos o especializados.
·
Organizaciones externas, vendedores, proveedores, contratistas, entre otras, para obtener recursos humanos adecuados, escasos, especializados, calificados, certificados o de otro tipo específico. Deberá prestarse especial atención a las políticas, prácticas, procesos, pautas, disposiciones legales y a otros criterios de negociación externos.
La capacidad del equipo de dirección del proyecto de influir en otras personas desempeña un papel importante en la negociación de asignaciones de personal, del mismo modo que las políticas de las organizaciones implicadas. Por ejemplo, un gerente funcional evaluará los beneficios y la visibilidad de proyectos que compiten, a la hora de determinar a dónde asignar a las personas con un excelente desempeño, que son requeridas por diferentes equipos del proyecto.
9.2.1.3 Adquisición (Adquisition) Cuando la organización ejecutante no cuenta con el personal interno necesario para completar un proyecto, los servicios requeridos pueden adquirirse de fuentes externas. Esto puede implicar contratar consultores individuales o subcontratar trabajo a otra organización.
318
9.2.1.4 Equipos virtuales (Virtual teams) El uso de equipos virtuales crea nuevas posibilidades a la hora de adquirir a los miembros del equipo del proyecto. Los equipos virtuales pueden definirse como grupos de personas con un objetivo común, que cumplen con sus respectivos roles pasando poco o nada de tiempo en reuniones cara a cara. La disponibilidad de medios de comunicación electrónica como el correo electrónico, las audio conferencias, los encuentros por internet y las videoconferencias, ha hecho posible la existencia de estos equipos. El formato de equipo virtual permite:
·
Formar equipos de personas de la misma empresa que viven en áreas geográficas dispersas.
·
Aportar experiencia especial a un equipo del proyecto, incluso si el experto no se encuentra en la misma área geográfica.
·
Incorporar empleados que trabajan desde oficinas instaladas en sus domicilios.
·
Formar equipos de personas que trabajan en diferentes turnos u horarios.
·
Incluir personas con limitaciones de movilidad o discapacidades.
·
Avanzar en proyectos que habrían sido descartados debido a los gastos de desplazamiento.
La planificación de las comunicaciones adquiere una importancia cada vez mayor en el entorno de un equipo virtual. Puede ser necesario dedicar tiempo adicional para establecer expectativas claras, facilitar las comunicaciones, desarrollar protocolos para la resolución de conflictos, incluir personas en la toma de decisiones y compartir los méritos del éxito.
9.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Calendarios de recursos. Véase sección 9.4.1.7 (Resource calendars)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)
319
9.3 Desarrollo del equipo (Proceso que corresponde a la fase de ejecución del proyecto) Formar un equipo de proyecto no se limita tan solamente a asignar un grupo de personas a determinadas tareas. Un equipo de proyectos es un grupo especializado, que asume el compromiso de realizar su trabajo correctamente y son capaces de aportar valor al proyecto. Una de mayores preocupaciones de un Project Manager es la preparación de su equipo. El éxito o fracaso de un proyecto puede tener como factor principal el nivel de preparo del equipo ejecutor. El desarrollo del equipo es actualmente un gran desafío que consiste en transformar un conjunto de personas en un equipo profesional que sepa responder a las demandas del proyecto y sobre todo de sus clientes. Una vez que el equipo este formado, es importante definir los procedimientos y compromisos que nortean el proyecto. Estableciendo estos elementos, el Project Manager deberá asegurarse de que el equipo conoce:
· · · ·
Los objetivos del proyecto y de cada objetivo individual. El papel y compromiso de cada integrante. Las herramientas y recursos disponibles.
La relación que los integrantes mantendrán entre si durante el desarrollo del proyecto.
9.3.1 Técnicas y herramientas 9.3.1.1 Teoría de Tuckman (Tuckman theory) Bruce Wayne Tuckman42 es un psicólogo estadounidense que estudió en profundidad el comportamiento de los grupos. Su obra más importante, publicada en 1965, se titula Desarroio secuencial en grupos pequeños y es un modelo que llegó a ser muy influyente en la teoría de desarrollo de grupos. Este modelo se divide en cinco etapas:
· · · · ·
Formación (Forming). Enfrentamiento (Storming). Normalización (Norming). Desempeño (Performing). Disolución (Adjourning).
Esta teoría es interesante porque encaja perfectamente en lo que se refiere al desarrollo de un equipo en un proyecto. Normalmente, los integrantes de un equipo provienen de diferentes departamentos de la empresa y son reunidos única y exclusivamente para la ejecución de un determinado proyecto. Una vez que finalizado, el grupo es disuelto y sus integrantes regresan a su departamento de origen, donde siguen desarrollando sus labores diarias, hasta que sean convocados para formar parte de un nuevo proyecto. 320
•
Formación (Forming): Fase de iniciación del equipo de proyecto: Si aplicamos la teoría de Tuckman42, veremos que en la etapa de formación, los integrantes del equipo no se conocen y no tienen claro todavía los objetivos del proyecto. Cada integrante trae consigo un cierto grado de incertidumbre y es natural que se sientan todavía inseguros en relación a lo que le puede venir por delante. Es una fase en que cada uno adopta una postura neutral, evitando cualquier conflicto, asumiendo una postura pasiva. El Project Manager debe realizar una serie de entrevistas con cada integrante del equipo para identificar las expectativas que cada uno tiene con el grupo y con el proyecto con lo cual ha sido asignado. Es el momento para establecer con el grupo las “reglas del juego” (ground rules – véase también doc nº 042). Se trata de una lista de comportamientos aceptables e inaceptables adoptados por el equipo de proyecto para mejorar la relación de trabajo, efectividad y la comunicación. Estas reglas deben ser expuestas, compartidas y aceptadas por el equipo.
·
Enfrentamiento (Storming): Fase en que las ideas compiten, a veces de forma agresiva, para que se lleven en cuenta. Una vez superada la fase inicial, el equipo empezará a trabajar en un ambiente que se espera, sea armónico. No obstante, eventuales conflictos son inevitables. Cada persona es dotada de una personalidad y expectativas diferentes y consecuentemente los objetivos de cada uno se verán muchas veces enfrentados. El Project Manager tendrá que intentar conducir el equipo hacia la misma dirección, y para ello, tendrá que asumir un papel activo de negociación para que de alguna forma, todos los integrantes puedan llegar a un acuerdo que les permita seguir sin percances. Para ello, las reglas del juego establecidas en el punto anterior, serán de gran valía. El capítulo 13, Gestión de conflictos, aborda una serie de técnicas de resolución de conflictos que pueden resultar muy útiles.
·
Normalización (Norming): Una vez superadas las fases anteriores, lo más probable es que los integrantes del equipo empiecen a confiar unos en los otros y en el grupo como un todo. Dependiendo del grado de madurez del grupo, será posible incluso disfrutar de alguna autonomía en la toma de decisiones, rompiendo un poco la dependencia que a veces tienen del Project Manager.
·
Desempeño (Performing): En esta fase, el equipo del proyecto ha alcanzado la madurez necesaria para funcionar como una unidad. El grupo es plenamente capaz de hacer que el trabajo sea realizado de forma fluida y con eficacia, sin conflictos inadecuados o necesidad de supervisión externa. El grado de interferencia del Project Manager disminuye sensiblemente y los buenos resultados se hacen notar en poco tiempo. No obstante, no es común alcanzar este nivel de desempeño, el grupo depende totalmente de la capacidad de cada uno de los integrantes y sobre todo de la buena voluntad de resolver conflictos. Cuando el grupo alcanza este tipo nivel de toma de decisión, el Project Manager tiene la posibilidad de fomentar la “potenciación” del equipo.
·
Potenciación (Empowerment): Significa dar libertad a un empleado para que tome decisiones asumiendo su propio nivel de riesgo. Esto es la actitud que un Project Manager tiene cuando existe una relación de plena confianza con su equipo. Por lo tanto dar poder a los empleados es básicamente: establecer una relación de confianza, darles libertar de toma de decisiones, adquirir experiencia propia y legitimar la asunción de riesgos.
321
•
Disolución (Adjourning): Cuando el proyecto termina, el grupo se deshace. La satisfacción de haber logrado terminar el proyecto muchas veces se ve empañada por el “sentimiento de pérdida” que los integrantes sienten por tener que abandonar el equipo (o a veces, sucede lo contrario). Los integrantes del equipo vuelven a sus departamentos de origen, para cuidar de sus labores diarias. Ha llegado el momento del Project Manager realizar las evaluaciones de los integrantes, cuyos resultados, muchas veces, son encaminados a los superiores directos de cada integrante del equipo del proyecto. Si los resultados han sido satisfactorios, este mismo equipo podrá ser convocado para asumir proyectos similares.
9.3.1.2 Habilidades interpersonales (Interpersonal skills) Las habilidades interpersonales son aquellas que te permiten tener una mejor comunicación con otras personas. Los profesionales con estas habilidades colaboran a mejorar las relaciones entre el equipo y entablar relaciones duraderas, proporcionando al proyecto una fluidez en las comunicaciones y un intercambio de mensajes claros y eficientes, lo que contribuye al proyecto una reducción importante de errores y consecuentemente de riesgo. Para potenciar tus habilidades interpersonales en el trabajo debes tener en cuenta lo siguiente:
· · ·
Centrarse en la conversación. Mostrar disposición. Superar la timidez.
Las personas hábiles para relacionarse en el trabajo observan a los demás, se comunican con ellos y fomentan el establecimiento de relaciones. Entablan amistad en reuniones cortas y encuentran posibilidades donde parece no haberlas.
9.3.1.3 Formación (Training) La capacitación ha sido, desde siempre, una de las condiciones necesarias para una empresa sacar el máximo provecho del rendimiento de sus trabajadores y, así, volverse competitiva, apostando por la diferenciación de la competencia en base al valor añadido que supone tener una organización, un capital humano formado en todas sus parcelas, puede lograr tener una ventaja competitiva considerable. La formación aporta un sinnúmero de beneficios a la empresa y su adecuado desarrollo contribuye a:
·
Optimizar la utilización de los recursos humanos, ayudando a los empleados a alcanzar los objetivos de la organización, así como sus metas individuales.
·
Proporcionar oportunidades y amplía la capacidad de desarrollo de la habilidades de los trabajadores. Colabora además, con la consecución de crecimiento personal. 322
• Aumentar la productividad de los empleados que contribuye a la organización el logro de sus objetivos.
·
Inculcar el sentido del trabajo en equipo y la colaboración entre personas.
·
Desarrollar y mejorar la cultura de aprendizaje dentro de la organización.
·
Construir una percepción positiva y un sentimiento sobre la organización.
·
A la mejora de la calidad de la vida laboral.
·
Mejorar la salud y la seguridad de la organización evitando así la obsolescencia.
·
Crear una mejor imagen corporativa.
·
Desarrollar habilidades de liderazgo, motivación, lealtad, mejores actitudes, y otros aspectos que los trabajadores y gerentes de éxito suelen mostrar.
·
Demostrar el compromiso de mantener a los empleados a la vanguardia del conocimiento y la práctica.
9.3.1.4 Reglas básicas (Ground rules) El objetivo del Project Manager durante el desarrollo del equipo es intentar que, entre los integrantes del equipo ejecutor del proyecto, empiece a surgir un cierto grado de armonía, que confíen uno en el otro y que tengan la capacidad de desarrollar una relación de trabajo. Y sobre todo que las reglas del juego estén claras y aceptadas por todos. (Para más detalles, véase también Apéndice A, doc nº 042).
9.3.1.5 Reubicación (Co-location) La reubicación es una acción que implica reunir a varios integrantes del equipo del proyecto en la misma ubicación física para mejorar su capacidad de trabajo en equipo. Esta reubicación puede ocurrir en cualquier fase del proyecto, siempre y cuando el Project Manager lo estime necesario. Las estrategias de reubicación incluyen principalmente una sala de reuniones para el equipo, lugares para la publicación de cronogramas e informes de rendimiento y todas las facilidades necesarias para mejorar la comunicación y el trabajo del equipo del proyecto. En algunos proyectos la reubicación puede ser realizada a través de medios virtuales (teleconferencia, chats, foros, plataformas web y otros).
323
9.3.1.6 Reconocimiento y recompensas (Recognition and awards) Son muchos los factores que pueden motivar a los integrantes de un proyecto. Beneficios económicos, poder, logros, oportunidades de promoción.... Pero hay un factor muy importante que es el reconocimiento. Un trabajador que está satisfecho con su trabajo y sus aportes a la empresa son más propensos a estar motivados. Cuando se le reconoce por sus esfuerzos, la tendencia es dar seguimiento a su afán de superación y esforzarse en mantener su trabajo en la empresa. Existen muchas organizaciones que invierten mucho dinero en la formación y capacitación de sus empleados, pero no son capaces de mantenerles en la organización a largo plazo. Esto ocurre porque en muchos casos, los trabajadores no se sienten reconocidos o no vislumbran una posibilidad de promoción. A veces, pequeños gastos invertidos en un premio o en una promoción interna, pueden transmitir al trabajador una sensación real de reconocimiento por su trabajo bien hecho y reforzar su deseo de mantenerse en la empresa.
9.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I DOC nº 044 – Evaluaciones del desempeño del equipo (Team perfomance assessments)
I Actualizaciones a los factores ambientales de la empresa (las que correspondan) (Enterprise environmental factors updates)
9.4 Gestión del equipo (Proceso que corresponde a la fase de ejecución del proyecto) Acorde con el PMBOK®, la gestión del equipo es el proceso que consiste en dar seguimiento al desempeño de los integrantes del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto. El equipo de dirección del proyecto observa el comportamiento del equipo, gestiona los conflictos, resuelve los problemas y evalúa el desempeño de los miembros del equipo. Como consecuencia de dirigir el equipo del proyecto, se envían solicitudes de cambio, se actualiza el plan de recursos humanos, se resuelven los problemas, se suministran datos de entrada para las evaluaciones de desempeño y se añaden lecciones aprendidas a la base de datos de la organización. Gestionar el equipo del proyecto requiere una variedad de habilidades de gestión para fomentar el trabajo en equipo e integrar los esfuerzos de sus miembros, a fin de crear grupos de alto desempeño. La dirección del equipo implica una combinación de habilidades con especial énfasis en la comunicación, la gestión de conflictos, la negociación y el liderazgo. El Project Manager debe proponer a los miembros del equipo tareas estimulantes y recompensar el alto desempeño.
324
9.4.1 Técnicas y herramientas 9.4.1.1 Evaluación de rendimiento (Project performance appraisals) Las evaluaciones de rendimiento son normalmente utilizadas por el Project Manager para analizar la evolución del equipo en diferentes ámbitos del proyecto durante su desarrollo. Normalmente se utiliza una escala de números para facilitar y agilizar el cumplimento de la evaluación. Una vez cumplimentada, es fundamental calcular las valoraciones realizadas, a fin de conocer sus promedios y con esto poder poner en marcha acciones preventivas o correctivas que el Project Manager juzgue necesarias. La evaluación de rendimiento puede contener los siguientes puntos: Nº
ARTÍCULO
1
2
3
4
5
6
1
El equipo está alineado con los objetivos del proyecto
1
2
3
4
5
6
2
1
2
3
4
5
6
3
El equipo participa activamente de las actividades de control Las decisiones son realizadas con consenso
1
2
3
4
5
6
4
El equipo está motivado
1
2
3
4
5
6
5
Los conflictos son resueltos de forma armónica
1
2
3
4
5
6
Figura 134: Ejemplo de evaluación de rendimiento
Por otro lado, la evaluación de rendimiento también es muy útil para conocer el grado de satisfacción y expectativas de cada integrante del proyecto, acerca de su trabajo, del trabajo de sus compañeros, del ambiente del grupo en general o de sus relaciones con sus pares, superiores o subordinados. Estas evaluaciones pueden ser realizadas por cualquier persona involucrada en el proyecto. Es decir, el Project Manager puede realizar evaluaciones de sus subordinados, así como estos pueden realizar evaluaciones del Project Manager o de cualquier líder del proyecto. También se puede hacer entre pares, un integrante evaluando a su compañero, o un Project Manager evaluando al líder técnico. Algunos ejemplos de cuestiones que pueden aparecer en una evaluación de rendimiento: “En general, ¿está usted de acuerdo en cómo su responsable gestiona su departamento?” 1. Mucho
2. 3. 4. 5. 6.
Bastante Regular Poco Nada No lo sé 325
“¿Cómo describiría el clima de trabajo con sus compañeros?” 1. Muy bueno
2. 3. 4. 5. 6.
Bueno Regular Malo Muy Malo No lo sé
Es importante facilitar campos libres para permitir a los participantes expresar libremente sus comentarios, sugerencias o quejas. Para garantizar la confidencialidad y la calidad de los datos, estas evaluaciones suelen ser realizadas de forma anónima, y se instituye el principio del “360-degree feedback”. Este principio establece lo siguiente: Todo aquél que realice evaluaciones de sus compañeros o superiores, recibirá posteriormente, las evaluaciones realizadas por los demás, sobre su propio rendimiento, siempre de forma anónima, como dicho anteriormente. Las respuestas obtenidas ayudarán a cada integrante del proyecto a conocer las sensaciones generales de todo el grupo, pero principalmente, le permitirá conocer las sensaciones que los demás tienen de sí mismo. Se trata además una importante fuente de información acerca de las fortalezas y debilidades del proyecto, del entorno y del equipo en general. Tan importante como evaluar la performance del equipo y las impresiones personales de los integrantes del equipo, evaluar las capacidades del Project Manager también es una forma de conocer la evolución del grupo como un todo. Algunos de los puntos que se pueden evaluar acerca de la performance del Project Manager son:
Nº
ARTÍCULO
1
2
3
4
5
6
1
Capacidad de liderazgo
1
1
1
1
1
1
2
Capacidad de comunicación
2
2
2
2
2
2
3
Capacidad cumplimiento de objetivos
3
3
3
3
3
3
4
Capacidad de resolución de conflictos
4
4
4
4
4
4
5
Habilidad de cumplimiento de plazos
5
5
5
5
5
5
Figura 135: Ejemplo de evaluación de las capacidades del Project Manager
No existe un modelo específico de Evaluación de Rendimiento, una vez que cada empresa o departamento posee expectativas y necesidades diferentes acerca de su grupo y de los proyectos que está llevando a cabo.
326
9.4.1.2 Gestión de conflictos (Conflict management) La gestión de conflictos es la capacidad de administrar una situación donde las personas involucradas en un determinado proyectos poseen intereses diferentes. El capítulo 13, Gestión de conflictos, aborda una serie de técnicas de resolución de conflictos que pueden resultar muy útiles.
9.4.1.3 Registro de incidencias (Issue log) Este documento es utilizado para recoger, registrar y controlar todas las incidencias que puedan generarse durante el desarrollo del proyecto. Es uso efectivo de este documento permitirá al Project Manager gestionar correctamente las incidencias ocurridas, minimizando sus impactos y consecuentemente, garantizando de alguna forma, el buen progreso del proyecto. El modelo de este documento se encuentra, en el Apéndice A, doc nº 049.
9.4.1.4 Habilidades interpersonales (Interpersonal skills)
Descrito en la sección 9.3.1.2
9.4.1.5 Diagramas de red (Network diagrams)
Descrito en la sección 6.2.1.1
9.4.1.6 Histograma de recursos (Resoure histogram) Los histogramas son herramientas muy prácticas en la planificación de control de los recursos. Permite gestionar de forma adecuada las horas de trabajo de los integrantes de un equipo de proyecto. Entre otras cosas, permite visualizar:
·
Si un recurso tiene más horas de trabajo que las que le fueron originalmente asignadas.
·
Si un recurso tiene demasiado tiempo ocioso, mientras que otro recurso similar está sobrecargado.
Para confeccionar un histograma de recursos es necesario saber básicamente: 327
· ·
Quiénes son los integrantes del proyecto y a cuales tareas han sido asignados. Cuáles son las tareas del proyecto y sus respectivas duraciones.
328
En el ejemplo que viene a continuación, podremos visualizarlo de forma ilustrada: ACTIVIDAD
PEDRO
MARIANO
MARÍA
MONTSE
REQUISITOS
4 horas
-
2 horas
6 horas
DISEÑO
10 horas 60 horas 5 horas
12 horas
10 horas
-
40 horas
20 horas
10 horas
1 hora
6 horas
3 horas
-
2 horas
2 horas
-
79
55
40
19
CODIFICACIÓN DOCUMENTACIÓN PRUEBAS TOTAL HORAS
Figura 136: Tabla de asignación de horas y recursos humanos a las actividades
4 5 4 0 3 5 3
PED RO MARI ANO MARI
Figura 137: Grafico de asignación de horas y recursos humanos a las actividades
En este ejemplo, se puede observar claramente que Pedro y Mariano están trabajando en este proyecto mucho más horas que los demás, es decir, no hay un equilibro de horas de dedicación entre los cuatro integrantes de este proyecto. No obstante, tenemos que saber si María y Montse están asignados a otros proyectos y por esta razón tienen que repartir sus horas. Además, es fundamental tener en cuenta la cantidad de horas necesarias para completar una actividad, o sea, puede que no sea necesario tener mucha gente dedicada a la misma actividad. En cualquier caso, el Project Manager deberá equilibrar está relación, para evitar que sus recursos estén ociosos o sobrecargados.
329
9.4.1.7 Calendario de recursos (Resource calendar) El calendario de recursos es una herramienta muy utilizada por el Project Manager para organizar y consultar la disponibilidad de los integrantes del equipo del proyecto. Estos calendarios deben reflejar quienes son recursos que están solamente disponibles durante el horario laboral, quienes pueden trabajar por la noche o quienes se encuentran indisponibles por vacaciones, bajas médicas, formación o porque están asignados a otro proyecto. El calendario de recursos debe estar disponible en una red compartida, que permita que cualquier involucrado en el proyecto pueda conocer la disponibilidad de determinados recursos.
9.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I Actualizaciones a los factores ambientales de la empresa (Enterprise environmental factors updates) - Las que correspondan al proceso
I Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I DOC nº 039 – Solicitudes de cam bio (Change requests)
330
Capítulo 10 Gestión de las comunicaciones “Una buena conversación debe agotar el tema, no a sus interlocutores” Winston Churchill 20 , estadista, historiador, escritor y orador británico
331
Algunas cosas en las que NO puedes pensar acerca de la gestión de la comunicación “No controlo mucho de francés, pero creo que entiendo más o menos lo que este documento propone” ¿Cuantas veces has intentado traducir un documento utilizando los típicos programas gratuitos de traducción, que no hacen otra cosa que crear más confusión? Hay un pasaje en el viejo testamento que refleja exactamente la ejecución de un proyecto y los problemas resultantes de la mala traducción o interpretación de un idioma extranjero: la Torre de Babel. Definida como una escalera entre el cielo y la tierra, la Torre de Babel figura en el texto del Génesis, donde se relata que los hombres, reunidos en la llanura de Shinear, resolvieron levantar una torre gigantesca. Dios, al ver lo que intentaban, obstaculizó sus planes "confundiendo sus lenguas" de modo que los obreros no pudieran entenderse entre sí. Al quedar incapacitados de trabajar de común acuerdo, los constructores abandonaron el proyectio y se dispersaron en diferentes direcciones. La Torre de Babel se convierte entonces en símbolo de la confusión y las desastrosas consecuencias que invaden al hombre cuando no puede comunicarse con sus semejantes, porque cada uno emplea su propio idioma o la comunicación no fluye de forma adecuada. “No hace falta que me envíes ningún e-mail. Me acordaré perfectamente de todo lo que hemos acordado esta mañana” La comunicación escrita tiene varias ventajas, pero una de ellas es incontestable: ¡Tiene permanencia! Es decir, que la información estará siempre disponible en cualquier momento que la necesitemos. La comunicación escrita además, nos permite pensar y definir claramente lo que queremos expresar, lo que reduce drásticamente la posibilidad de interpretaciones equivocadas (que es una importante fuente de problemas en proyectos). Además, una vez finalizado el proyecto, toda la comunicación escrita generada puede ser utilizada como fuente de consulta (lessons learned), como medio de información ya que está escrita permanentemente. “No tengo las instrucciones completas, pero me dejaron algo escrito en este post-it” Una vez Peter Drucker43 dijo que “El 60% de los problemas empresariales son consecuencia de una mala comunicación”. Es imprescindible tener en cuenta que uno de los motores que mueven un proyecto es la comunicación, que tiene que ser generada, transmitida y recibida correctamente, o al contrario, podrá provocar daños importantes al proyecto. ¿Cuántas veces hemos realizado mal un trabajo porque el mensaje nos ha llegado incorrecto, incompleto o equivocado? La mala comunicación puede ser la causa del fracaso de un proyecto.
332
Introducción Imagine que acabas de planificar un viaje de coche que exigirá cruzar algunos miles de kilómetros. Antes de realizarla, has tomado todas precauciones necesarias para empezar un largo viaje: dispones de los mapas del recurrido, te has informado acerca de la previsión del tiempo y has realizado una revisión completa en el coche. No hay razón para preocupaciones. Sales con el coche, recurres los primeros kilómetros, pero durante el trayecto, te das cuenta que están haciendo obras en la carretera que te obligarán a hacer un recorrido muy distinto del planificado. No habían puesto ninguna señal de obras durante el recorrido, lo que podría haberte ayudado a realizar alguna acción correctiva (coger un desvio) antes de acercarse a la obra, para de esta forma no tener tantos trastornos. Ocurre que ahora te encuentras en el medio de un atasco de coches monumental, la gasolina no será suficiente para recorrer el tramo provisional y tú no tienes ninguna información acerca de la localización de la próxima gasolinera. Todos estos incidentes, te hicieron consumir mucho más horas de las planificadas, lo que te obligará a pasar la noche en un hotel en una ciudad que desconoces completamente. Todo el plan original del viaje tendrá que ser revisado. Quizás ni siquiera valdrá la pena seguir con el viaje. Si los responsables de la obra hubiesen realizado una sencilla labor de comunicación a los conductores a través de una señalización adecuada, con una antelación que pudiera te permitir revisar tu plan, quizás tu proyecto de viaje no habría sido tan gravemente perjudicado. Normalmente, un Project Manager suele consumir entre el 75% y el 90% de su tiempo realizando gestiones relacionadas con la comunicación del proyecto. Casi todos los documentos generados en un proyecto son remitidos al Project Manager y es él normalmente la persona encargada de trasmitirlos. Esta información normalmente viene de distintas personas y suelen llegar en los más variados formatos, que necesitarán de un tratamiento adecuado para poder ser transmitido de forma clara e inequívoca a los involucrados del proyecto. La comunicación eficaz es una de las claves de un proyecto de éxito. En resumen, es compartir los mensajes adecuados en los momentos oportunos a las personas correctas. La gestión de las comunicaciones incluye los elementos necesarios para una adecuada generación, colecta, diseminación y almacenamiento de las informaciones del proyecto. Hay estudios que comprobaron que existe una alta porcentaje de atritos, frustraciones y ineficiencias que tiene como origen una comunicación escasa.
Modelos de comunicación El modelo clásico de comunicación se encuentra ilustrado a continuación, en la figura 138. Consiste en un emisor que transfiere una información a través de un canal de comunicación a un receptor. Cuando el receptor recibe el mensaje, se la decodifica y la analiza. Normalmente, el receptor responde al emisor a través de un canal de retorno, con la respuesta del mensaje recibido. Este ciclo es conocido como “loop de comprensión”.
333
Figura 138: Canal de comunicación
Saber comunicarse es una de las habilidades más importantes de un Project Manager y será una de las herramientas más eficaces a la hora de hacer con que el proyecto se ejecute acorde con el plan. Además, durante su ejecución, todos los interesados deberán ser comunicados acerca de la evolución de los trabajos realizados. Es muy importante que el Project Manager desarrolle una estructura de comunicación. Normalmente está estructura incluirá:
·
La planificación de la comunicación: analiza las necesidades de información de cada interesado y desarrolla los canales de comunicación que serán utilizados en el proyecto.
·
La distribución de la información: es el proceso que desarrolla el sistema de recogida y distribución de la información de forma en que la información llegue al receptor de forma clara y correcta. Podrá ser formal o informal, escrita o oral, o de otra forma.
·
Informes de seguimiento: Es un documento que transmite a los interesados sobre la situación actual del proyecto, los problemas encontrados y las previsiones y estimativas de las siguientes fases.
Objetivos de la gestión de las comunicaciones
· · · ·
Facilitar la toma de decisiones. Coordinar mejor los departamentos involucrados en el proyecto. Favorecer la participación. Mejorar la eficiencia.
La forma de transmitir un mensaje, es muchas veces tan o más importante que el propio mensaje en sí.
334
Tipos de comunicación
·
Escrita u oral: Dependerá de la situación. Un mensaje escrito permitirá preparar un primer borrador, y luego realizar las debidas correcciones hasta llegar al exacto contenido del mensaje que se quiere transmitir. Además, los mensajes escritos se quedan registrados para posteriores consultas o comprobaciones. Sin embargo, en muchos casos, un mensaje escrito puede ser mal interpretado ya que la entonación o el sentimiento son muy difíciles de ser transmitidos en este tipo de mensaje. Una comunicación oral, permite un feedback rápido, que muchas veces aporta ahorro de tiempo y agilidad. Sin embargo, en situaciones más delicadas, podrá llevar a situaciones de nerviosismo que el transmisor del mensaje podrá no saber cómo actuar.
·
Formal o Informal: La comunicación formal es realizada utilizando documentos previamente establecidos por el Project Manager y su equipo, como son las actas de reunión, memorandos o plantillas de e-mail. La comunicación informal, es básicamente compuesta por las conversaciones e intercambios de ideas entre los afectados del proyecto, durante la ejecución de los trabajos previstos. En muchas ocasiones, durante una conversa informal se generan decisiones muy importantes que deberán posteriormente ser compartidas formalmente con los demás integrantes del proyecto. Las comunicaciones informales tienen dos desventajas importantes: como no hay ningún registro, mucha información valiosa se pierde. Además, algunos conflictos pueden generarse por una decisión tomada informalmente.
·
Individual o colectiva: Transmitir un mensaje a un grupo tiene una ventaja muy clara: asegura que todo el grupo ha escuchado exactamente el mismo mensaje y bajo las mismas circunstancias. No obstante, las interpretaciones por parte de algunas personas podrán ser distintas, de acuerdo con la percepción o expectativa de cada miembro del grupo.
Saber elegir la mejor forma de hacer llegar un mensaje a una persona o grupo de personas, es importante para que el proyecto avance sin incidencias. La tardanza en una respuesta, la mal interpretación de un mensaje o la omisión de una información, perjudicará el buen avance del proyecto.
Las reuniones del proyecto La reunión de proyecto es una cita obligatoria. Reunir el equipo de proyecto es fundamental, sobre todo cuando es posible reunir todos los integrantes. Es una oportunidad de revisar el progreso del proyecto, la documentación generada y las próximas actividades y principalmente compartir información. La reunión de proyecto debe ser realizada regularmente. Si posible, es aconsejable que el equipo del proyecto organice reuniones siempre en el mismo día y hora, creando así, una rutina de seguimiento. Infelizmente, la reunión de proyecto es con frecuencia, vista con antipatía, como si el tiempo invertido en estos encuentros fuese un tiempo perdido. De hecho, las reuniones de proyecto deberían ser tratadas como una actividad del proyecto, y por ello deberían ser incluir en el cronograma.
335
Algunas recomendaciones sobre la organización de reuniones: Realizar reuniones solamente cuando necesario: Las reuniones podrán perder su efecto si convocadas sin una agenda fuerte. No convoque una reunión si:
· · ·
Los temas pendientes pueden ser resueltos por e-mail. Lo que tienes que decidir, lo podrás decidir solo. No hay temas importantes por decidir.
Sé claro en relación al propósito de la reunión: Los objetivos y la agenda de la reunión deben ser claros y propuestos en el momento adecuado. Se pueden clasificar una reunión por tipo, y normalmente los tipos más importantes de reunión son:
·
Reunión de progreso: Su fin es evaluar estado actual del proyecto y tratar de determinar estrategias para la ejecución de las próximas actividades.
·
Reunión de decisión: Consiste en decidir sobre un tema pendiente, un evento inesperado o una estrategia puntual.
·
Reunión de acuerdo: Ocurre cuando hay la necesidad de llegar a una decisión conjunta sobre un determinado tema.
·
Reunión de información: Es realizada para comunicar alguna decisión importante o algún acontecimiento importante para el proyecto.
·
Reunión de opinión: Su necesidad viene por una necesidad de dialogar con el equipo con el fin de colaboración en una decisión importante.
·
Reunión de instrucción: Tiene por fin determinar la dirección de un evento o incrementar el conocimiento sobre un determinado aspecto.
·
Reunión de revisión: es realizada normalmente cuando se acerca el fin de una determinada fase. Analiza algunos aspectos como los resultados de una determinada operación.
Organice una reunión de forma sistemática: Reuniones bien estructuradas y bien organizadas suelen ser eficaces. Es importante seguir un guión como el de la continuación:
·
Preparando una reunión o Determine el objetivo o propósito. o Prepare un previo comentario. o Prepare la agenda. o Determine su duración. o Invite las personas necesarias. o Convoque la reunión con una antelación razonable.
·
Comenzando una reunión o Explique el propósito de la reunión. o Anuncie la agenda. 336
o Este seguro que todos los participantes entendieron el objetivo de la reunión.
337
•
Asegure la atención y la participación del equipo o Permita que el equipo colabore con sus opiniones. o Controle las discusiones y desentendimientos. o No permita que la reunión salga de sus objetivos. o Asegure que los temas sean concluidos.
·
Cierre la reunión o Termine la reunión en tiempo. o Desarrolle un plan de acción con las decisiones tomadas. o Intente obtener compromiso por parte del equipo.
·
Actividades tras el cierre o Confeccione un acta de reunión y envíela en veinticuatro horas como mucho.
Una reunión bien estructurada y con un guion concreto proporcionará un tono bastante formal e incentivará la participación del equipo. Si los integrantes de un equipo empiezan a ausentarse de las reuniones, la información se quedará dispersa y será necesario dedicar más tiempo para hacer con que el mensaje llegue a todo el equipo.
Centro de mando (War room) El concepto de war room se refiere, en términos militares, a un lugar donde el comandante jefe se reúne con su mando para desarollar y dar seguimiento a tácticas, planes y estrategias de combate, antes de su ejecución en el campo de batalla. Históricamente, podemos retroceder a la segunda guerra mundial, más precisamente al nº 10 de Downing Street (Londres), donde Winston Churchill 20 conducía todo el esfuerzo bélico ingles en el sótano, transformado en Centro de Mando. De las innúmeras reuniones mantenidas en aquel local, salieron muchos de los planes que culminarían posteriormente con la victoria de los aliados en 1945. En la actualidad, se sabe que en la Casa Blanca en Washington, existe un local conocido como Situation Room (Sala de Situación), utilizada por el presidente estadounidense y su mando militar en situaciones de emergencia, como en los atentados del 11-S. En el ámbito del Project Management, un local como este se hace extremadamente necesario, aunque parezca exagerado. Un proyecto, igual que un conflicto bélico (guardando las debidas proporciones), puede sufrir graves incidencias y terribles consecuencias. Por esta razón sería muy interesante que la organización pudiese disponer un lugar especial, con las facilidades necesarias para el desempeño de un grupo de trabajo. Es importante tener en cuenta que una situación de crisis normalmente ocurre en un momento inestable y por esta razón el Centro de Mando debe estar integrado por personas específicamente involucradas en el perfil de situaciones de conflicto o crisis específicas que sean capaces de tomar las rápidamente las decisiones necesarias para la corrección de un determinado problema.
338
Canales de comunicación Los canales de comunicación son un importante aspecto en la gestión de la comunicación. Es importante entender las relaciones entre personas que se comunican y percibir que la a medida que más gente se involucra en una conversación más difícil será transmitir con claridad un mensaje concreto.
·
Canal circular: El canal circular de comunicación es una estructura de comunicación en círculo, según ilustra la figura 139. En este tipo de canal, el mensaje necesita pasar por varias personas, hasta llegar al receptor del mensaje. Cuanto más grande sea el círculo, más personas estarán entre el emisor y el receptor del mensaje. Hay que tener un especial cuidado de preservar el contenido original del mensaje, durante su recorrido hasta el receptor final.
Figura 139: Canal circular
·
Canal en cadena: En este tipo de comunicación, el mensaje sale del emisor y es pasada a los integrantes de la cadena uno a uno, hasta llegar al receptor, según ilustra la figura 140. Este tipo de canal de comunicación es donde ocurre más frecuentemente problemas de comunicación, ya que el mensaje suele tener su contenido original ligeramente cambiado toda vez que llega a uno de los integrantes, pudiendo llegar bastante cambiada al receptor. Se puede comprobar esto haciendo una sencilla prueba. En un grupo de 10 personas, un integrante comenta una noticia en privado con otro integrante. Este integrante repasa la noticia en privado al siguiente, hasta que la noticia finalmente llega al décimo integrante. Al final se compara la noticia transmitida por el emisor original y el receptor final. Normalmente las dos versiones presentadas son completamente distintas.
Figura 140: Canal en cadena
339
•
La rueda: Este tipo de canal de comunicación centraliza y da poder al individuo del centro, según ilustrado en la figura 141. Todas las informaciones se dirigen al centro y solamente el centro provee información para los otros individuos de la cadena. En este tipo de canal, el centro ocupa una situación privilegiada, por ser el único detentor de toda la información que proviene de varias fuentes. De esta forma, podrá filtrar determinadas informaciones o no hacerlas llegar a su destinatario, si así le parece conveniente.
Figura 141: La rueda
•
Canal de Comunicación Abierto: La figura 142 ilustra un canal de comunicación abierto. Cada nodo del canal puede comunicarse con cualquier otro nodo. Eso significa que la información de un individuo puede ser transmitida a cualquier otro individuo en el diagrama. La comunicación en este tipo de canal es difícil de controlar porque la información fluye fuera de un orden y puede venir de cualquier nodo del diagrama. Según el número de individuos incremente, los nodos de comunicación incrementarán también.
El número de canales de comunicación posibles puede ser calculado a través de la siguiente formula: Canales = [N x (N – 1)] / 2 Por ejemplo, si existen 6 personas en el equipo del proyecto y es necesario que ellos se comuniquen entre ellos, ¿cuantos canales de comunicación son necesarios? Canales = [ 6 x ( 6 – 1 ) ] / 2 Canales = [ 6 x ( 5 ) ] / 2 Canales = 30/2 Canales = 15
340
Figura 142 – Canal de comunicación abierto
Principales barreras de comunicación Barreras Logísticas · Geográficas.
· · ·
Husos horarios. Métodos (e-mail, videoconferencias, audio conferencias...). Diferencias multiculturales.
Barreras idiomáticas · Diferentes terminologías.
· · ·
Gestos u otras comunicaciones no verbales. Problemas de traducción. Desconocimiento del idioma.
Aspectos personales · Educación.
· · ·
Valores. Actitudes. Estatus social.
341
Organ izacionales · Cultura organizacional.
· · · ·
Rumores. Conflictos de interés. Relaciones entre departamentos. Diferentes prioridades.
Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de la comunicación de un proyecto incluye procesos y actividades necesarios para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados y oportunos. Son ellos:
· · · · ·
Identificar a los interesados. Planificar las comunicaciones. Distribuir la información. Gestionar las expectativas de los interesados. Informar el desempeño.
10.1 Identificación de los interesados
(Proceso que corresponde a la fase de inicio del proyecto) Acorde con el PMBOK®, la identificación de los interesados consiste en identificar a todas las personas u organizaciones impactadas por el proyecto y en documentar información relevante relativa a sus intereses, participación e impacto en el éxito del proyecto. Los interesados en el proyecto son personas y organizaciones (por ejemplo, clientes, patrocinadores, la organización ejecutante o el público) que están activamente involucrados en el proyecto, o cuyos intereses pueden verse afectados de manera positiva o negativa por la ejecución o terminación del proyecto. Ellos también pueden influir sobre el proyecto y sus entregables. Los interesados pueden encontrarse en diferentes niveles dentro de la organización y poseer diferentes niveles de autoridad, o bien pueden ser externos a la organización ejecutante del proyecto. Para el éxito del proyecto, resulta fundamental identificar a los interesados desde el comienzo del mismo y analizar sus niveles de interés, expectativas, importancia e influencia. Se puede elaborar entonces una estrategia para abordar a cada uno de ellos y determinar el nivel y el momento de su participación, a fin de maximizar las influencias positivas y mitigar los impactos negativos potenciales. La evaluación y la estrategia correspondiente deben revisarse de forma periódica durante la ejecución del proyecto para ser ajustadas frente a eventuales cambios. La mayoría de los proyectos tendrán gran cantidad de interesados. Dado que el tiempo con el que cuenta el Project Manager es limitado y debe usarse con la mayor eficiencia posible, estos interesados deberían ser clasificados según su interés, influencia y participación en el proyecto. Esto permite que el Project Manager se concentre en las relaciones necesarias para asegurar el éxito del proyecto.
342
10.1.1 Técnicas y herramientas 10.1.1.1 Matriz poder/interés (Power/interest matrix) Descrito en la sección 1.7.3.1.1
10.1.1.2 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
10.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 002 – Registro de interesados (Stakeholder register)
I
Estrategia de gestión de los interesados. Véase sección 1.7.3 (Stakeholder management strategy)
10.2 Planificación de las comunicaciones
(Proceso que corresponde a la fase de planificación del proyecto) Acorde con el PMBOK®, planificar las comunicaciones es el proceso para determinar las necesidades de información de los interesados en el proyecto y para definir cómo abordar las comunicaciones. El desarrollo del proyecto puede ponerse en peligro por una comunicación pobre. Por ello, hay que cerciorarse de realizar un ejercicio efectivo y constructivo de comunicación y gestión documental. Todas las personas involucradas en el proyecto deben comprender cómo afectan las comunicaciones al proyecto como un todo. Mediante la definición de un proceso de planificación de las comunicaciones se podrán determinar las necesidades de información y comunicación de los interesados, así como determinar una forma adecuada de satisfacer esas necesidades, por ejemplo, quién necesita qué información, cuándo la necesitará, cómo le será suministrada y por quién. Si bien todos los proyectos comparten la necesidad de comunicar información del proyecto, las necesidades de información y los métodos de distribución varían ampliamente.
343
10.2.1 Técnicas y herramientas 10.2.1.1 Análisis de requisitos de comunicaciones (Communication requirement analysis) El PMBOK® define el análisis de requisitos de Comunicación como una herramienta que determina las necesidades de información de los interesados. Estos requisitos se definen combinando el tipo y el formato de la información necesaria con un análisis del valor de dicha información. Los recursos del proyecto se utilizan únicamente para comunicar información que contribuya al éxito o cuando una falta de comunicación puede conducir al fracaso. Asimismo, el Project Manager debe considerar la cantidad de canales o rutas de comunicación potenciales como un indicador de la complejidad de las comunicaciones de un proyecto. La cantidad total de canales de comunicación potenciales es igual a n(n-1)/2, donde n representa la cantidad de interesados. Por consiguiente, un proyecto con diez interesados tiene 10(10-1)/2 = 45 canales de comunicación potenciales. Por lo tanto, un componente clave de la planificación de las comunicaciones reales del proyecto son la determinación y delimitación de quién se comunicará con quién y de quién recibirá qué información. Entre la información normalmente utilizada para determinar los requisitos de comunicación del proyecto, se incluyen:
· · · · · · ·
Organigramas. La organización del proyecto y las relaciones de responsabilidad de los interesados. Las disciplinas, departamentos y especialidades con implicación en el proyecto. La logística de cuántas personas participarán en el proyecto y en qué ubicaciones. Las necesidades de información interna (por ejemplo, comunicaciones entre diferentes empresas). Las necesidades de información externa (por ejemplo, comunicaciones con los medios). La información sobre los interesados proveniente del registro de interesados.
10.2.1.2 Tecnología de las comunicaciones (Communication technology) La comunicación es un elemento vital y uno de los factores de éxito de cualquier proyecto. Se equivoca quienes piensan que una empresa que cuenta con un moderno sistema de comunicación tiene asegurado un eficaz flujo de información y habrá fomentado correctamente la comunicación entre los interesados del proyecto. Hay empresas que están dotadas de dichos sistemas pero la comunicación sigue siendo escasa. Los sistemas de intercambio de información son independientes de modernos sistemas informáticos. Un equipo de proyecto puede comunicarse perfectamente a desde breve conversaciones, hasta reuniones prolongadas. La cuestión es que, durante un proyecto, una cantidad importante de información tiene que ser generada y tanto el Project Manager como su equipo deben tener en cuenta una serie de factores importantes: 344
·
La urgencia de la necesidad de información: ¿El éxito del proyecto depende de contar con información actualizada frecuentemente y disponible de inmediato, o bastaría con emitir periódicamente informes escritos?
345
•
La disponibilidad de la tecnología: ¿Los sistemas con los que ya se cuenta son apropiados o las necesidades del proyecto justifican un cambio? Por ejemplo, ¿el o los interesados previstos tienen acceso a la tecnología de comunicaciones seleccionada?
·
El personal previsto para el proyecto: ¿Los sistemas de comunicación propuestos son compatibles con la experiencia y conocimientos de los participantes del proyecto o se requiere una capacitación y un aprendizaje exhaustivos?
·
La duración del proyecto: ¿Es probable que la tecnología disponible cambie antes de la finalización del proyecto?
·
El entorno del proyecto: ¿El equipo se reúne y trabaja cara a cara o en un entorno virtual?
10.2.1.3 Modelos de comunicación (Communication models) Tal y como he comentado anteriormente, la comunicación constituye una de las herramientas más importantes que los profesionales tienen a disposición para desempeñar correctamente sus funciones. Toda la investigación moderna sobre la comunicación se basa en el artículo que describe el acto de comunicar, publicado en 1948 por el científico político americano Harold Lasswell 44. Este artículo describe el acto de la comunicación como un proceso que debería seguir un recorrido unidireccional. Para demostrarlo, ha creado una formula que es conocida como el Paradigma de Lasswell: “¿Quién dice qué, a quien, por qué canal y con qué efecto?". La figura 143 muestra un modelo de comunicación básico que representa como una información se envía y se recibe entre dos partes, definidas como el “emisor” y el “receptor”. Los principales elementos de este modelo son:
·
Emisor: Persona o equipo que intenta enviar un mensaje al receptador.
·
Receptor: Persona que recibe la información.
·
Canal: Medio físico por el que se transmite el mensaje (internet, teléfono, carta, fax...).
·
Codificación: Forma que toma la información que se intercambia entre la el emisor y el receptor.
·
Mensaje: Es lo que se quiere transmitir.
·
Decodificación: La metodología utilizada para “traducir” el mensaje recibido.
·
El ruido: Toda interferencia que pueda perjudicar el entendimiento del mensaje.
346
Figura 143: Modelo de comunicación básica
A pesar de los años transcurridos y de haber sido superado por otras visiones analíticas más modernas y acordes con el panorama mediático actual, el Paradigma de Lasswell sigue conservando muchas de aquellas virtudes que permitieron el despegue de los estudios sistemáticos de la comunicación. Algunos de los modelos de comunicación que surgieron a partir de la teoría de Lasswell son:
·
Modelo de Braddock 45: Incorpora al modelo de Lasswell dos aspectos: las circunstancias en las que se envía un mensaje y el propósito con el que el comunicador comienza el proceso.
·
Modelo de Shannon46 y Weaver47: Basado en el paradigma de la teoría matemática de la comunicación, fue una obra pionera y ha influido notablemente en los estudios de comunicación.
·
Modelo de Hennings48: Centrándose más en la comunicación interpersonal entre el emisor y el receptor, establece que hay una serie de estímulos verbales físicos, vocales, y situacionales que determinan la codificación de la información por el emisor y la decodificación de la misma por parte del receptor. En este sentido las nuevas tendencias recepcionistas de la comunicación vienen a indicar que lo importante no es lo emitido sino lo recibido, lo cual le dará al estudio del receptor y a sus características fisiológicas, educativas y culturales que facilitaran o dificultaran su participación en el proceso.
·
Modelo de Comunicación de Schramm 49: Establece que la comunicación es un proceso determinado por compartir, es decir, por establecer relaciones entre personas que tengan en común tres componentes como mínimo, tales componentes son: la fuente (puede ser una persona, una cadena de televisión, un medio impreso...), el mensaje (verbal o no verbal, diferentes formas de expresión) y el destino (la persona que escucha o recibe el mensaje).
·
Modelo de Katz50 y Lazarsfeld51: Conocido también como two-step-flow, este modelo dice que la influencia de los medios de comunicación de masas no se produce de manera líneal y directa, sino que se produce a través de los líderes de opinión, y del papel que desempeñan como estructuradores y reestructuradores de la información.
·
Modelo de Comunicación de Maletzke 52: El modelo destaca su riqueza y amplitud. Es un modelo en el que se analizan cinco sub modelos: 1. El comunicador y el mensaje. 2. El comunicador y el medio. 3. El comunicador y el receptor. 4. El mensaje y el medio. 5. El receptor y el medio. 347
10.2.1.4 Métodos de comunicación (Communication methods) Acorde con el PMBOK®, existen varios métodos de comunicación que se emplean para compartir la información entre los interesados en el proyecto. De manera general, estos métodos pueden clasificarse en:
·
Comunicación interactiva: Entre dos o más partes que realizan un intercambio de información de tipo multidireccional. Resulta la manera más eficiente de asegurar entre todos los participantes una comprensión común acerca de temas específicos, e incluye reuniones, llamadas telefónicas, videoconferencias...
·
Comunicación de tipo push: Enviada a receptores específicos que necesitan conocer la información. Esto asegura la distribución de la información, pero no garantiza que efectivamente haya llegado a la audiencia prevista ni que haya sido comprendida. Este tipo de comunicación incluye las cartas, los memorandos, los informes, los correos electrónicos, los faxes, los correos de voz, los comunicados de prensa...
·
Comunicación de tipo pull: Utilizada para grandes volúmenes de información o para audiencias muy grandes, que requieren que los receptores accedan al contenido de la comunicación según su propio criterio. Entre los métodos, se incluyen los sitios intranet, el aprendizaje virtual, los servidores de contenido... En función de los requisitos de comunicación, el Project Manager decide qué métodos de comunicación deben utilizarse dentro del proyecto, cómo y cuándo hacerlo.
10.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 023 – Plan de gestión de las comunicaciones (Communication management plan)
I
Actualizaciones a los documentos del proyecto (Project document update) - Las que correspondan al proceso
10.3 Distribución de la información
(Proceso que corresponde a la fase de ejecución del proyecto) La distribución de la información es el proceso que consiste en poner a disposición de los interesados toda la información relevante del proyecto de acuerdo con el plan establecido. Es un proceso que se ejecuta a lo largo de todo el ciclo de vida del proyecto, y tiene como principal premisa la distribución de la información adecuada en el momento oportuno a las personas que correspondan.
348
10.3.1 Técnicas y herramientas 10.3.1.1 Sistemas de gestión de la información (Information management system) El concepto de sistema de gestión de la información puede ser muy amplio. El PMBOK® lo define como un sistema que gestione información; conoce, incorpora y vincula todos los tipos de datos, de todas las áreas de la organización y se relaciona con todos los procesos, desde la generación de información interna y la selección y adquisición hasta la organización de su uso. Utiliza recursos básicos (económicos, físicos, humanos, materiales) para manejar información dentro y fuera de la entidad. Cuenta con un instrumento por excelencia que es el análisis de información, cuyo objetivo es la captación, evaluación, selección y síntesis, de contenidos de documentos, lo cual adquiere una relevancia extraordinaria ante la creciente circulación de datos e información. Su realización exitosa y eficiente genera una mejor utilización de la información disponible en aras de acelerar el proceso de acceso y utilización. Exige, la aplicación de nuevas tecnologías de información y comunicación. Sin embargo, la tecnología por sí sola no es suficiente para lograr una buena gestión de información. Son diversos los procesos que conforman los sistemas de gestión de información; ellos generan las entradas y salidas del sistema o de otros procesos relacionados; también pueden identificarse, controlarse, corregirse o actualizarse en la medida en que se producen las transformaciones del entorno y evoluciona la organización, como vía incuestionable para garantizar su calidad, eficiencia y mejora continua.
10.3.1.2 Lista de distribución de la información (Information distribution tools) Uno de los factores clave de éxito de un proyecto es la distribución eficaz de la información. Es fundamental que todos los implicados estén informados del avance de los trabajos, de las decisiones tomadas, de las estimaciones previstas o de cualquier otro dato que sea relevante para el desarrollo de su labor. La distribución de la información consiste en recoger, compartir y distribuir la información a las partes interesadas en el proyecto en el momento adecuado. La tecnología de la información ha posibilitado que la distribución de la información sea realizada de forma sencilla y rápida. No obstante, todavía existe un cierto descontrol a la hora de distribuir la información, sobre todo cuando la información llega a quienes no deberían recibirla, un hecho muy grave, una vez que muchas informaciones de un proyecto son confidenciales. Una forma eficaz de distribuir la información correctamente es utilizando una lista de distribución. La lista de distribución es un conjunto de direcciones que son utilizadas para enviar la información a un grupo determinado de personas de forma organizada. Normalmente, se asigna a una persona que deberá encargase de la gestión de esta lista, que tendrá que poner en marcha las siguientes acciones:
349
•
Creación y mantenimiento de los grupos de interés. Actualización y mantenimiento de las direcciones.
· · · · ·
Creación de perfiles de acceso. Gestión de altas y bajas de usuarios. Gestión y control de las informaciones enviadas. Gestión de contraseñas de acceso.
10.3.1.3 Control de versiones (Revision control) El control de versiones está directamente vinculado a la lista de distribución. La información, además de ser enviada a las personas correctas en el momento adecuado, debe estar actualizada. Se conoce como “control de versiones”, a la gestión de los cambios que se realizan sobre los documentos de un proyecto. El sistema de control de versiones facilita la administración de las distintas versiones de un documento. Para mantener un control eficaz de versiones, es importante que a todos los documentos del proyecto se les incluya una tabla como la que presentamos a continuación: VERSION 1.0
DESCRIPCION Descripción de la actualización realizada
FECHA [fecha]
Figura 144: Control de versiones de un documento
A cada versión realizada se le asigna un número y se describe el cambio realizado en el documento, vinculando siempre una fecha a cada versión del documento. Todos los documentos deben ser guardados con un número de versión en su nombre de fichero, por ejemplo “cronograma proyecto Alfa-v3.doc”, a cada cambio realizado se guardaría el fichero, cambiándole el número de versión. De esta forma, se conservaría un registro histórico de las acciones realizadas en cada documento, posibilitando volver o recuperar un estado anterior de este documento, evitando de esta forma, conflictos de versiones, documentación duplicada o pérdida de información. También es recomendable que solamente una persona o un reducido grupo de personas esté autorizado para realizar cambios en la documentación y generar versiones. Los demás integrantes que no estén autorizados, deberán enviar sus modificaciones al personal encargado, solicitando que se genere una versión nueva del documento correspondiente.
10.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso 350
10.4 Gestión de las expectativas de los interesados (Proceso que corresponde a la fase de ejecución del proyecto) Acorde con el PMBOK®, la gestión de las expectativas de los interesados es el proceso que consiste en comunicarse y trabajar en conjunto con los interesados para satisfacer sus necesidades y abordar los problemas a medida que se presentan. Implica actividades de comunicación dirigidas a los interesados en el proyecto, para influir en sus expectativas, abordar sus inquietudes y resolver asuntos, tales como:
·
Gestionar activamente las expectativas de los interesados para aumentar la probabilidad de aceptación del proyecto, negociando y ejerciendo influencia sobre sus deseos para alcanzar y mantener los objetivos del proyecto.
·
Abordar inquietudes que aún no representan incidentes, por lo general relacionadas con la anticipación de problemas futuros. Es preciso revelar y tratar estas inquietudes, así como evaluar los riesgos.
·
Aclarar y resolver los incidentes identificados. La resolución puede generar una Solicitud de Cambios o puede abordarse fuera del proyecto, por ejemplo, puede posponerse para otro proyecto o fase, o derivarse a otra entidad de la organización.
Gestionar las expectativas de los interesados ayuda a aumentar la probabilidad de éxito del proyecto al asegurar que los interesados comprenden los beneficios y riesgos del mismo. Esto les permite apoyar el proyecto de forma activa y ayudar en la evaluación de los riesgos asociados con las elecciones del proyecto. Al anticipar la reacción de las personas frente al proyecto, pueden implementarse acciones preventivas a fin de obtener su apoyo o minimizar los impactos negativos potenciales. El Project Manager es responsable de gestionar las expectativas de los interesados. La gestión activa de estas expectativas disminuye el riesgo de que el proyecto no alcance sus objetivos y metas por causa de incidentes no resueltos a nivel de los interesados, y limita las interrupciones durante el proyecto.
10.4.1 Técnicas y herramientas 10.4.1.1 Métodos de comunicación (Communication methods)
Descrito en la sección 10.2.1.4
10.4.1.2 Habilidades interpersonales (Interpersonal skills)
Descrito en la sección 9.3.1.2 351
10.4.1.3 Habilidades de gestión (Management skills) Descrito en la sección 15.3
10.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I DOC nº 039 – Solicitudes de cam bio (Change requests)
I DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project Management plan updates)
I DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
10.5 Informes de rendimiento
(Proceso que corresponde a la fase de control del proyecto) Acorde con el PMBOK®, informar el rendimiento es el proceso de recopilación y distribución de información sobre el desempeño, incluidos informes de estado, mediciones del avance y proyecciones. El proceso de informar el rendimiento implica la recopilación y análisis periódicos de datos reales y su comparación con la línea base a fin de comprender y comunicar el avance y desempeño del proyecto, así como proyectar los resultados del mismo. Los informes de desempeño deben suministrar información en un nivel adecuado para cada audiencia. El formato puede variar desde un informe de estado simple hasta informes más elaborados. Un informe de estado simple puede revelar información sobre el desempeño, como el porcentaje completado o los indicadores de estado para cada área (el alcance, el cronograma, los costes y la calidad). Entre los informes más elaborados, se incluyen:
· · · · · ·
El análisis del desempeño pasado. El estado actual de los riesgos e incidentes. El trabajo completado durante el período. El trabajo que se completará a continuación. El resumen de los cambios aprobados en el periodo. Otra información relevante que debe ser revisada y analizada.
Un informe completo también debería incluir la conclusión proyectada del proyecto (incluidos el tiempo y el coste). Estos informes pueden elaborarse con regularidad o de manera excepcional. 352
10.5.1 Técnicas y herramientas 10.5.1.1 Análisis de variación (Variance analysis)
Descrito en la sección 5.5.1.1
10.5.1.2 Métodos de proyección (Forecasting methods) El método de la proyección consiste en predecir el desempeño futuro de un proyecto basándose en el desempeño real hasta la fecha. Son varios los métodos de proyección, que pueden ser clasificados en diferentes categorías:
·
Métodos de serie de tiempo: Se utilizan datos históricos como base para la estimación de resultados futuros. Como ejemplo se incluyen el método del valor ganado (véase también sección 7.3.1.1), el promedio móvil, la extrapolación, la predicción lineal, la estimación de tendencias y la curva de crecimiento.
·
Métodos causales/econométricos: Son métodos que se basan en la hipótesis de que es posible identificar los factores subyacentes que pueden llegar a influir en la variable que se está proyectando. Por ejemplo, las ventas de balones pueden asociarse con el mundial de futbol. Entendiendo las causas, es posible proyectar las variables que influyen y usarse en la proyección.
·
Métodos de juicio: Se incorporan juicios intuitivos, opiniones de expertos y estimaciones de probabilidad. En los ejemplos de métodos en esta categoría, se encuentran proyecciones compuestas, las encuestas (véase también sección 5.1.1.6), la técnica Delphi (véase también sección 6.4.1.7), la elaboración de escenarios (véase también sección 11.3.1.4) y la proyección por analogía.
·
Otros métodos: Incluyen la simulación, las proyecciones probabilísticas y las proyecciones ensemble (proyecciones combinadas).
10.5.1.3 Sistemas de informes (Report systems) Un sistema de informes es una herramienta muy útil que registra, almacena y distribuye a los interesados cualquier información importante acerca de los proyectos (seguimiento de costes, avance del cronograma y desempeño del proyecto en general). El uso de un sistema de informes permite al Project Manager administrar toda la comunicación generada durante el proyecto, utilizando un formato estándar de fácil entendimiento.
353
10.5.1.4 Análisis de tendencias (Trend analysis) Descrito en la sección 5.5.1.1
10.5.1.5 Análisis del valor del trabajo realizado (EVM methods) Descrito en la sección 7.3.1.1
10.5.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) - Las que correspondan al proceso
I
DOC nº 039 – Solicitudes de cam bio (Change requests)
I
Informes de desempeño. Véase secciones 6.6.1.2, 7.3.1.1, 7.3.1.3 y 7.3.1.4 (Performance Reports)
354
Cap ítulo 11 Gestión de riesgos “Si no esperas lo inesperado no lo reconocerás cuando llegue” Heráclito de Éfeso53, filosofo griego.
355
Algunas cosas en las que NO puedes pensar acerca de la gestión de riesgos “Nuestro proyecto no tiene riesgos” Creo que de todas las cosas en las que no puedes pensar en el Project Management, quizás esta afirmación sea la más absurda. Quien conoce o ha oído hablar de la ley de Murphy54, seguramente conocerá su máxima más conocida: “Si algo puede salir mal, saldrá mal”. Esta afirmación que denota una actitud extremadamente pesimista, se aplica a cualquier situación, desde las más banales de la vida cotidiana hasta otras más trascendentes. Por lo tanto, es una estupidez pensar que un prometo no tiene riesgos. “El proyecto es demasiado pequeño para contener riesgos” En las estadísticas de la DGT (Dirección General de Tráfico), los trayectos cortos se presentan como los más peligrosos. Esto ocurre por un exceso de confianza al volante por conocer la vía por la que se viaja habitualmente. Con los proyectos pequeños ocurre algo similar. Existe un exceso de confianza que tiende a depreciar eventuales riesgos. Hay que tener claro que ningún proyecto está totalmente exento de riesgos y todos necesitan de un plan de prevención y respuesta adecuadas. “Gestionaremos el riesgo cuando este ocurra” Como me encantan los refranes, no podría encontrar un apartado más apropiado para mencionar el muy conocido “más vale prevenir que curar”. Empezar a ejecutar un proyecto sin haber realizado una estrategia previa frente a eventuales riesgos que puedan llegar a ocurrir, equivale a garantizarnos tropiezo tras tropiezo, ineficiencias, retrabajos y un sinfín de incidencias que acabarán redundando en un considerable aumento de costes, desmotivación del equipo y desconfianza por parte del cliente. “Tranquilo, seguro que esto no nos va a ocurrir” Muchas veces frases como estas han sido dichas segundos antes de que ocurriera un grave accidente. Es el resultado de subestimar los riesgos, uno de los grandes errores de la humanidad. Han pasado milenios, desde el surgimiento de las primeras civilizaciones, y el hombre todavía no ha aprendido a valorar debidamente el riesgo. Muchos de los desastres que vemos a diario en la tele, como la caída de aviones de pasajeros, grandes inundaciones, incendios o derrumbes de edificios son más que nada el resultado de uno o más riesgos que han sido ignorados o subvalorados por las personas implicadas en su gestión. Cualquier proyecto conlleva al surgimiento de determinados riesgos, de menor o mayor proporción, pero que deben ser correctamente valorados y gestionados.
356
Introducción La gestión de riesgos es una de las más importantes áreas de gestión de un proyecto y deberá ser realizada durante todo el ciclo de vida de un proyecto. La identificación de probables riesgos es relativamente sencilla, sobre todo si el proyecto cuenta con el apoyo de expertos. Sin embargo, estos riesgos deberán ser revisados durante todo el avance de los trabajos, ya que algunos de ellos podrán ser descartados y otros deberán tener una atención redoblada. Además, la posibilidad de surgimiento de nuevos riesgos será una constante durante todo el desarrollo del proyecto. Uno de las labores más importantes y sin embargo, más difíciles en la gestión de riesgos es la toma de decisiones. Tanto el Project Manager como su equipo afrontarán una infinidad de situaciones que les obligará a tomar decisiones que les pueden llevar tanto al éxito como al fracaso del proyecto. En un mundo ideal, el Project Manager debería tener a su disposición todas las informaciones necesarias para poder decidir con una alta probabilidad de acierto. No obstante, en el mundo real, el nivel de incertidumbre es muy alto, lo que hace con que la toma de decisiones sea una gestión bastante difícil de llevarse a cabo. Para sanarlo es importante que se disponga de una cantidad de información importante para poder reducir el nivel de esta incertidumbre. La incertidumbre se define como la falta de información de un futuro evento. Normalmente, cuanto mayor el emprendimiento, mayor será su grado de incertidumbre y consecuentemente mayor será su riesgo. Todo eso unido a un plan detallado y teniendo en manos la información necesaria acerca de los factores que influyen en el proyecto, reducirá el nivel de incertidumbre y hará con que el equipo pueda trabajar bajo estimaciones más seguras. Para alcanzar el éxito, minimizando la ocurrencia de incidencias, es importante que el equipo identifique los riesgos involucrados. Tome, por ejemplo, un viaje de vacaciones: si llevamos en cuenta solamente el precio, será más barato coger un autobús que un avión, sin embargo si empezamos a añadir otros factores como seguridad, será necesario analizar las estadísticas de accidentes entre ambos transportes. Otros factores, como tiempo de desplazamiento, comodidad..., deberán ser evaluados. En este ejemplo, llegar tarde podrá ser un riesgo aceptable, pero no llegar con seguridad será, sin duda, un riesgo inaceptable. De acuerdo con el PMBOK®, la definición de riesgos es: “Un evento o una condición que, si ocurre, tiene un efecto positivo o negativo sobre los objetivos del mismo. Un riesgo tiene una causa, y si ocurre, una consecuencia”. Conceptualmente, podemos definir el riesgo como “un resultado no deseado” o irónicamente como una “sorpresa inesperada”. No importa cómo se nombre, el riesgo es un factor muy sensible y necesita ser tratado con la atención adecuada. Existen factores de riesgo (conocidos o no) que pueden perfectamente arruinar meses de trabajo. El nivel de riesgo depende sobre todo de la cantidad de información disponible. Cuanto menos información, mayor será el riesgo, ya que el nivel de incertidumbre es muy alto. Según el proyecto avance, el nivel de incertidumbre disminuye, puesto que el Project Manager contará con un nivel de información cada vez mayor.
357
Figura 145: Cantidad de riesgo
Por otro lado, aunque el grado de incertidumbre disminuya considerablemente, el riesgo todavía será alto, una vez que cualquier problema surgido en una fase avanzada del proyecto tendrá un impacto muy alto. El riesgo siempre tendrá una importancia muy relevante, o por falta de informaciones en el comienzo de un proyecto o por el impacto que podrá causar cualquier percance en una fase avanzada del proyecto. La figura 146 ilustra estas dos situaciones:
Figura 146: Matriz de incertidumbre x riesgo
En un proyecto se toman decisiones casi a diario y cada decisión tomada, conlleva en asumir un determinado grado de riesgo. En un mundo perfecto, las decisiones serian tomadas con una probabilidad de acierto casi segura, ya que toda la información necesaria estaría disponible, lo que conllevaría a resultados siempre positivos. Infelizmente en el mundo real, está situación es muy poco frecuente, sobre todo cuando se tratan de proyectos que, según sus características, conllevan a la puesta en marcha de algo nunca haya sido hecho anteriormente. Sin la información necesaria, la probabilidad de resultados positivos es baja. En muchos casos el grado de incertidumbre, asociado a la complejidad del proyecto.
358
359
Figura 147: Alta complejidad, baja incertidumbre
Figura 148: Baja complejidad, alta incertidumbre
Figura 149: Alta complejidad, alta incertidumbre
360
361
Figura 150: Baja complejidad, baja incertidumbre
La gestión de riesgos siempre lidiará con incertidumbres y, en muchos casos, el Project Manager no sabrá de la existencia de un determinado riesgo hasta que ocurra o esté a punto de ocurrir. La incertidumbre no puede ser totalmente eliminada, pero puedo mitigarse si se siguen algunas pautas:
362
•
Definir la probabilidad de ocurrencia.
· ·
Cuantificar sus impactos. Determinar sus causas y eventuales daños.
Además, el Project Manager deberá desarrollar estrategias que busquen reducir la posibilidad de incidencias. Una gestión de riesgos apropiada podrá convertir un riesgo en una oportunidad. ¿Y cómo un Project Manager podrá saber si puede asumir un riesgo? Todo dependerá del nivel del riesgo, su impacto (negativo o positivo) y, en muchos casos, del perfil del Project Manager. Profesionales de perfil conservador tendrán un nivel de tolerancia para los riesgos muy bajo y buscarán siempre evitarlos o por lo menos reducir su posibilidad de ocurrencia. Ya un Project Manager agresivo tenderá a afrontar los riesgos y asumir sus consecuencias, aunque sus impactos sean altos, pues normalmente querrá arriesgarse en busca de resultados muy positivos. El gráfico 151 ilustra algunos de los principales factores de riesgo de un proyecto.
Figura 151: Principales factores de riesgo de un proyecto
FACTORES DE RIESGO – INICIO DEL PROYECTO R01 R02 R03 R04
-* -* -* -*
El proyecto no dispone de un análisis de beneficio/coste. El proyecto no dispone de un estudio de viabilidad. Hay poca o ninguna información acerca del proyecto. El proyecto no cuenta con el apoyo apropiado de la dirección.
Figura 152: Principales factores de riesgo en la fase inicial de un proyecto
FACTORES DE RIESGO – FASE DE PLAN IFICACIÓN R05 R06 R07 R08 R09
-* -* -* -* -*
El plan no ha sido desarrollado por personas con experiencia en proyectos similares. El plan no es un documento escrito, formalizado y debidamente aprobado. El plan está incompleto. Algunos capítulos del plan no fueron aprobados. El equipo del proyecto no ha participado. 363
R10
-*
Los procedimientos del proyecto no están claros.
Figura 153: Principales factores de riesgo en la fase de planificación de un proyecto
FACTORES DE RIESGO – FASE DE EJECUCIÓN / CONTROL R11 R12 R13 R14 R15
-* -* -* -* -*
La necesidad del cliente ha cambiado. Los informes de seguimiento son inconsistentes. Sustitución de integrantes del equipo del proyecto. Presupuesto insuficiente. Número elevado de fallos en las pruebas realizadas.
Figura 154: Principales factores de riesgo en la fase de ejecución/control de un proyecto
FACTORES DE RIESGO – FASE DE CIERRE R17 R18
-* -*
Los resultados del proyecto no fueron aprobados por el cliente. Miembros del equipo fueron adjudicados a otros proyectos antes del cierre formal.
Figura 155: Principales factores de riesgo en la fase de cierre de un proyecto
Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de riesgos de un proyecto incluye los procesos y las actividades necesarias para llevar a cabo la planificación de la gestión, la identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitorización y control en un proyecto. Los objetivos de la gestión de los riesgos del proyecto son aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos para el proyecto.
364
controlar
Figura 156: Ciclo de gestión de riesgos
11.1 Planificación de la gestión de riesgos (Proceso que corresponde a la fase de planificación del proyecto) La planificación de la gestión de riesgos es el proceso por el cual se define cómo se gestionarán las actividades de gestión de riesgos para un proyecto. La realización de una plantación cuidadosa mejora la probabilidad de éxito de los otros procesos de gestión de riesgos. La planificación es una gestión fundamental y puede aportar los siguientes beneficios:
·
Puede asegurar que el nivel, el tipo y la visibilidad de gestión de riesgos se encuentran acordes tanto con los riesgos como con la importancia del proyecto para la organización.
·
Proporciona los recursos y el tiempo suficientes para las actividades de gestión de riesgos.
·
Establece una base acordada para la evaluación de riesgos.
El proceso de planificar la gestión de riesgos debe iniciarse tan pronto como se concibe el proyecto y debe completarse en las fases tempranas de planificación del mismo.
11.1.1 Técnicas y herramientas 365
11.1.1.1 Análisis y reuniones de planificación (Planning meetings and analysis) Las reuniones de planificación son las que definen los planes a alto nivel para la realización de una correcta gestión de riesgos, sobre todo en lo que se refiere a las metodologías de aplicación de las reservas para contingencias en materias de riesgo. Además, se establecerán los parámetros de riesgo del proyecto, como, por ejemplo, las categorías y los tipos de riesgos, sus niveles, las probabilidades de ocurrencia y eventuales impactos...
366
Un proyecto planificado adecuadamente dará al Project Manager y a su equipo la seguridad y las condiciones necesarias de poder anticiparse y afrontar los riesgos previstos. Eso resultará en mantener los plazos y los costes originales y los objetivos determinados. Por otro lado, un gran abanico de problemas pueden afectar al proyecto, comprometiendo la calidad del servicio y/o producto especificado.
11.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 020 – Plan de gestión de riesgos (Risk management plan)
11.2 Identificación de riesgos (Proceso que corresponde a la fase de planificación del proyecto) Durante todo el ciclo de vida del proyecto, el Project Manager y su equipo se encontrarán delante de determinadas situaciones que podrían ocasionar la ocurrencia de alguna incidencia o evento de riesgo que podrían comprometer el buen avance del proyecto. Los riesgos, aparte de su tipo, suelen tener unas características en común: poseen una probabilidad de ocurrencia y un impacto, pueden ser conocidos o desconocidos y pueden generar en algunos casos, una oportunidad de negocio.
Figura 157: Ciclo de gestión de riesgos: Identificación
El primer paso en la gestión de riesgos es intentar identificar los riesgos y determinar los desafíos que podrían venir por delante. ¿Cuáles serán los escollos que impedirán al Project Manager de lograr sus objetivos? Como comentado anteriormente, todo empieza con una gran incertidumbre, un total desconocimiento de cómo el proyecto evolucionará y como los factores internos y externos colaborarán para su éxito o fracaso. La identificación de riesgos es el proceso de identificación de las amenazas y oportunidades que podrán ocurrir no solamente durante el ciclo de vida del proyecto, como en todo el ciclo de vida del producto o del servicio generado.
367
Por ejemplo, el proyecto de construcción de un nuevo puente puede haber sido un éxito, pero es importante considerar que una corrosión en su estructura a lo largo de los años podría resultar en una tragedia, es decir, que los materiales utilizados para la construcción de este nuevo puente también deben ser considerados a la hora de identificar un riesgo en potencial. Por ello, es importante a la hora de planificar un proyecto tener en cuenta todos los riesgos involucrados. No existe una solución mágica para salir de la zona gris de desconocimiento. La identificación de los riesgos dependerá básicamente del juicio de expertos en proyectos similares, de la experiencia del Project Manager y de su equipo y de la cantidad de información disponible.
Tipos de Riesgo Existen varias formas de clasificar los riesgos de un proyecto. En el ámbito del Project Management, los riesgos pueden ser clasificados de la siguiente forma:
·
Estratégicos: Cambios de demanda, propiedad intelectual...
·
Organizativos: Infidelidad de empleados, falta de comunicación...
·
Personales: Huelga, absentismo...
·
Operacionales: Incendios, fallos logísticos, control de calidad...
·
Medio Ambientales: Inundación, vientos, terremotos...
·
Políticos y Legales: Cambio de legislación y de gobierno...
·
Mercado: Competencia, reducción de márgenes...
·
Económico Financieros: Tipos de interés y de cambio, impuestos...
·
Imprevisibles: Estadísticamente alrededor del 10% de los riesgos de un proyecto pueden ser considerados imprevisibles.
·
Riesgo Residual: Riesgo remanente que existe después de que se hayan tomado las medidas de seguridad.
El síndrome del iceberg John Jeston55 y Johan Nelis56 describen en su libro Business Process Management: Practical Guidelines to Successful Implementations, el síndrome del iceberg, una teoría que puede perfectamente aplicarse en el proceso de identificación de riesgos, y que dice lo siguiente: Los icebergs normalmente solo dejan expuesta un pequeño porcentaje de su masa sobre la superficie del agua. Lo que se encuentra sumergido es totalmente desconocido. Durante el proceso de identificación de riesgos, muchas personas se concentran solamente en lo que ven, y por consiguiente, desarrollan estrategias de respuesta enfocadas solamente a la parte visible del problema. 368
Figura 158: La punta del iceberg
Sin embargo, la realidad en muchos casos no es completamente visible, sobre todo en la fase inicial del proyecto, cuando el grado de incertidumbre es muy alto. Lo que se encuentra “por debajo del agua” y que todavía no conocemos es lo que representa exactamente el riesgo que el equipo probablemente tendrá que enfrentar. Es lo que llamamos de unknowns unknowns (desconocidos desconocidos), o en otras palabras, un evento imposible de prever, o totalmente desconocido. Para hacer frente a esta situación se establecen algunas reservas de tiempo, coste y de recursos que podrán reducir el impacto causado por un factor de riesgo todavía desconocido.
Figura 159: La verdad por debajo del iceberg
11.2.1 Técnicas y herramientas 11.2.1.1 Revisión de la documentación (Documentation reviews) En general, lo que inicialmente hacen los equipos de proyecto es una revisión estructurada de los planes de proyecto, incluso en los archivos de proyectos anteriores y de otras fuentes de información. Es importante disponer de una documentación completa acerca de proyectos similares, realizados anteriormente. La “lecciones aprendidas” de otros proyectos forman parte importante en las reuniones de identificación de riesgos, ya que aportan información muy útil. La documentación generada en la gestión de tiempo (los diagramas de red, cronogramas) y la gestión del alcance (por ejemplo, la EDT) serán de gran utilidad al Project Manager y su equipo.
369
11.2.1.2 Técnicas de recopilación de información (Information gathering techniques) Algunos ejemplos de técnicas de recopilación de información utilizadas en la identificación de riesgos son:
· · · · ·
Tormenta de ideas: Descrita en la sección 11.2.1.8. Técnica delphi: Descrita en la sección 6.4.1.7. Entrevistas: Descrita en la sección 5.1.1.1. Técnica de grupo nominal: Descrita en la sección 11.2.1.19. Técnica crawford slip: Descrita en la sección 11.2.1.11.
11.2.1.3 Listas de verificación (Checklists)
Descrito en la sección 8.3.1.5
11.2.1.4 Análisis de hipótesis o supuestos (Assumptions analysis) El análisis de hipótesis es una técnica que permite a los involucrados la identificación de posibles escenarios para el proyecto que, de otra forma, no sería posible. La gran ventaja de esta técnica reside en la simulación de distintas hipótesis que podrá demostrar cómo responderá el proyecto a los escenarios identificados. De esta forma, será posible desarbolar planes de mitigación de riesgo o incluso eliminar riesgos que todavía no habían sido identificados. Esta técnica obedece el siguiente proceso: se formulan posibles hipótesis que tengan por objeto reflejar e inspirar posibles estrategias de gestión de riesgos. Las hipótesis se pueden clasificar como “generales” y “específicas”. Las hipótesis generales ofrecen información sobre los posibles enfoques que se pueden utilizar para reducir el riesgo sin definir una estrategia concreta. Las hipótesis específicas se pueden interpretar como la medida de los efectos de una posible estrategia, para ver cómo cabe esperar que funcione. También puede ayudar a establecer si hay dificultades, salvedades o cuestiones que se deben tener en cuenta al evaluar el rendimiento previsto de la estrategia.
11.2.1.5 Técnicas de diagramación (Diagramming techniques) ·
Diagramas de causa-efecto: También conocido como diagrama Ishikawa o “espina de pez”. Es una de las diversas herramientas surgidas a lo largo del siglo XX en el ámbito de la industria y, posteriormente, en el de los servicios, para facilitar el análisis de problemas y sus soluciones en esferas como es la calidad de los procesos, los productos y servicios (para más detalles, véase también sección 8.3.1.7).
·
Diagrama de flujo: Consiste en representar gráficamente hechos, situaciones, 370
movimientos o relaciones de todo tipo, por medio de símbolos (para más detalles, véase el punto 8.1.1.7).
371
•
Diagrama de influencia: Se trata de una representación gráfica de un problema mostrando las influencias causales, el orden en el tiempo de los sucesos y otras relaciones entre las variables y los resultados. Al analizar decisiones, se busca obtener claridad ante situaciones complejas y confusas. La modelización de las decisiones a través de herramientas específicas nos brinda mayor comprensión ya que nos permite visualizar gráficamente sus elementos clave. El diagrama de influencia es una herramienta que nos ayuda a identificar a las variables "no controlables" (eventos inciertos con distintos grados de probabilidad) con sus interrelaciones. El diagrama nos permitirá considerar todas las variables clave antes de tomar la decisión y entender cómo se impactan unas a otras y al resultado final esperado.
Todas estas técnicas utilizadas por separado, o en conjunto, podrán ayudar a identificar los riesgos más importantes para el proyecto. Toda esta información disminuirá el grado de incertidumbre y, por consiguiente, la probabilidad de ocurrencia de algún evento de riesgo.
11.2.1.6 Análisis DAFO (SWOT analysis) El análisis DAFO es una herramienta que analiza el ambiente externo e interno de una organización. En el eje externo del análisis organizacional se encuentran las oportunidades y las amenazas, mientras que en el ambiente interno están las fortalezas y debilidades. Es una herramienta que produce la confrontación de las variables externas e internas, facilitando la generación de alternativas en el caso puntual de identificar algún riesgo potencial.
oportunidades fortalezas
EXTERNAS INTERNAS SWOT debilidades amenazas
Figura 160: Análisis DAFO
·
Las fortalezas corresponden a los recursos y capacidades de la empresa que, combinados, pueden generar importantes ventajas competitivas en relación a la competencia.
·
Las debilidades son los factores más vulnerables de una organización en relación con la 372
competencia.
373
• ·
Las oportunidades corresponden a las posibilites de crecimiento, fortalecimiento de la empresa, generación de nuevos negocios, entre otros. Las amenazas son los cambios en el ambiente que pueden comprometer seriamente la supervivencia de la empresa.
Los resultados obtenidos a través de la combinación de los cuatro factores del Análisis DAFO podrán aportar lo siguiente:
· · ·
Indicar el camino más apropiado para que la empresa pueda desarrollar su estrategia competitiva. Establecer los cambios necesarios para que la empresa pueda sacar mejor partido de su plantilla, recursos y posibilidades. Ayudar a elegir a trazar estrategias de participación en el mercado, alternativas de inversión, fusiones, entre otras.
11.2.1.7 Juicio de expertos (Expert judgment)
Descrito en la sección 4.1.1.1
11.2.1.8 Tormenta de ideas (Brainstorming) Muy utilizada en las empresas, esta técnica consiste en obtener una lista exhaustiva de soluciones y alternativas para un determinado problema. Bajo el liderazgo de un facilitador (que puede ser el Project Manager), se incentiva al equipo para generar toda y cualquier idea que les ocurra sin debatirlas. Cada integrante del grupo tendrá a su disposición un bloque de notas, donde podrá plasmar cualquier idea que pudiera generar algún beneficio para el proyecto. Al cabo de pocos minutos, se obtendrá un listado bastante amplio de soluciones y alternativas que serán analizadas y clasificadas posteriormente. Este análisis descartará las sugerencias que no pueden ser implementadas y combinará las alternativas válidas en probables soluciones para el problema. A pesar de ser una técnica bastante sencilla y muy fácil de ponerse en marcha, es importante respectar algunas reglas básicas:
·
Todas las ideas, a principio, son buenas.
·
Asegúrese de que sus ideas tienen sentido, no utilice una palabra clave cuyo significado podría olvidarse posteriormente.
·
Asegúrese de todas las ideas están escritas en un papel adecuado que posibilite un manipulado y clasificado adecuado. 374
•
Ideas duplicadas deben ser aceptadas. A veces, dos sugerencias parecen idénticas, pero luego cada una puede tener un significado distinto.
·
Déjese llevar por la imaginación, cualquier idea puede ser válida.
·
Plasme su idea inmediatamente, sin discutirlas con nadie.
Una sección de tormenta de ideas realizada adecuadamente y enfocada en la identificación de riesgos podrá aportar mucha información útil. Los resultados obtenidos podrían identificarnos lo siguiente:
·
Riesgos en el alcance: Añadidos en el alcance por parte del cliente, trabajos que no pueden ser definidos, alcance sobreestimado, cambios en el objetivos del proyecto...
·
Riesgos en los plazos: Duración de las actividades sobreestimadas, retrasos en las fechas de finalización de actividades, cronogramas irreales, aprobaciones tardías...
·
Riesgos en los materiales: Materia prima escasa, retraso en la entrega por parte de los proveedores, baja calidad, precio elevado, defectos...
·
Riesgos en los equipos, suministros y maquinaria: Disponibilidad escasa, baja calidad, incompatibilidades diversas, limitaciones, poca adaptabilidad...
·
Riesgos en los RRHH: Cambios en el equipo, costes inesperados, poca disponibilidad, conflictos de interés...
·
Riesgos organizacionales: Liderazgo insuficiente, limitaciones políticas, comunicación insuficiente, limitación de presupuesto, conflictos entre departamentos, apoyo limitado de la dirección, otras prioridades...
·
Riesgos de personal: Vacaciones, enfermedades, despidos, temas familiares, conflictos de interés, cuestiones éticas, morales, religiosas...
·
Riesgos profesionales: Baja productividad, conflictos de interés, poca motivación, baja calificación...
·
Riesgos de influencias externas: Clima, desastres naturales, regulaciones del gobierno, propiedad intelectual, problemas económicos, políticos, sociales y legales.
Ventajas y desventajas
·
Ventajas o Estimula la interacción del grupo. o Es rápida. o Tiene un bajo coste.
375
• Desventajas
o Puede ser dominada por el integrante más influyente. o Solo puede ser utilizada en determinadas áreas. o Requiere un mediador muy capacitado. o Puede ser tendenciosa.
11.2.1.9 Técnica de grupo nominal (Nominal group technique) Desarrollada por Delbecq57 y Van de Ven58, es una técnica que consiste en conducir grupos incorporando un análisis de las ideas presentadas, mientras que el brainstorming, presentado en el punto anterior, es una técnica que se limita a la generación de dichas ideas. Es una técnica que valora, sobre todo, el proceso de decisión asegurando la participación igualitaria de todo el grupo. Está técnica se desarrolla de la siguiente forma:
·
Preparación: Es la primera fase de la actividad. Se confecciona la cuestión objeto de la reunión, cuya redacción debe contener una amplia gama de detalles.
·
Generación de Ideas: Una vez presentada la cuestión, los participantes tendrán un periodo limitado de tiempo (normalmente diez minutos), para desarbolar por escrito, en silencio y sin discusión cualquier idea que pueda generar la solución para la cuestión presentada.
·
Ronda de Ideas: En este momento se exponen las ideas desarrolladas. Cada uno expone su idea, obedeciendo el orden físico de la mesa, dando la “vuelta al grupo”. Se registra solamente una Idea por persona y no se hacen críticas o alabanzas a las ideas presentadas. Discusión de ideáis: Ha llegado el momento de discutir todas las ideáis presentadas. Se analiza una idea a la vez, valorando sus pros y sus contras. Es fundamental limitar el tiempo de discusión de cada idea, para evitar que la reunión se prolongue demasiado.
·
·
Votación preliminar: Cada participante elegirá las ideas que considere mejores, asignándoles una puntuación predeterminada (por ejemplo, utilizando una escala de 1 a 5).
·
Nueva ronda de discusiones (si necesario): En esta fase, las ideas presentadas estarán clasificadas según la puntuación dada por cada participante. Se analizan los resultados obtenidos y se deciden las acciones correspondientes.
Ventajas y desventajas
·
Ventajas o Reduce el efecto dominante de un integrante influyente. o Genera una clasificación interesante de ideas. o Estimula la interacción del grupo.
376
• Desventajas
o Consume mucho tiempo. o Demanda mucho trabajo por parte del mediador.
11.2.1.10 Técnica Delphi (Delphi Technique)
Descrita en la sección 6.4.1.7
11.2.1.11 Técnica crawford slip (Crawford´s slip writing method) Muy parecida a la tormenta de ideas, este método puede ser una buena manera de estimular a las personas en las que las secciones de tormenta de ideas les puede producen una cierta inhibición. La técnica Crawford Slip fue desarrollada por C.C. Crawford 59 en la década de 20 en los Estados Unidos y es utilizada para obtener rápidamente una gran cantidad de ideas a partir de grupos numerosos. Se reúne el equipo del proyecto y se da a cada miembro diez trozos de papel (o post-its). El Project Manager, entonces hace la pregunta: “¿Cuáles pueden ser los eventuales riesgos que podemos identificar para este proyecto?” Cada participante pone sus respuestas en cada trozo de papel recibido. Si el participante consigue enumerar seis posibles riesgos, utilizará seis trozos de papel, y así sucesivamente. Esto deberá ser hecho en silencio, individualmente y sin discusiones. Una vez respondida la cuestión, el Project Manager recogerá los papeles y verá las respuestas. Si un determinado grupo es formado por 10 personas, el Project Manager tendrá en su mano cerca de cien respuestas que seguramente podrán formar el listado de los diez riesgos más probables de ocurrencia en el proyecto.
Ventajas y desventajas
·
Ventajas o Es rápida. o De fácil implementación. o Genera una cantidad importante de ideas. o Su formato permite la participación de grandes grupos. o No permite el dominio del más influyente.
·
Desventajas o La interacción entre los participantes es muy limitada.
11.2.1.12 Entrevistas (Interviews)
Descrito en la sección 5.1.1.1
377
11.2.1.13 Mapa conceptual (Concept map) El mapa conceptual ha sido desarrollado en los años 70 por el investigador estadounidense Joseph Novak6 , que lo define como “una técnica de organización y representación del conocimiento”. Son estructurados a partir de conceptos fundamentales y sus relaciones. 0
Se trata sobre todo de una representación gráfica de un conjunto de conceptos construidos de tal forma que las relaciones entre ellos sean evidentes. Se desarrolla de la siguiente manera:
1. Se identifican los conceptos clave del contenido que se quiere ordenar en el mapa en una lista. 2. Se pone el concepto principal en la parte superior del mapa para ir enlazándolo con otros conceptos según su nivel de generalización. Estos conceptos deben escribirse con letras mayúsculas.
3. Se conectan los conceptos con una palabra enlace, la cual debe ir con letras minúsculas en medio de dos líneas que indiquen la dirección de la proposición. 4. Se permiten incluir ejemplos en la parte inferior del mapa, debajo de los conceptos correspondientes; Aunque su origen está ligado a la enseñanza, su aplicación en la visualización de información lo convierte como una herramienta útil para transmitir de forma clara mensajes complejos o difíciles de entender y, por ello, contribuye notablemente a la identificación de riesgos.
Figura 161: Mapa conceptual de un accidente aéreo
378
Si miramos la figura 161 de abajo hacia arriba, se podrá identificar, de entrada, cuáles son los riesgos que conllevan, en la peor de las hipótesis, a un accidente aéreo. Los mapas conceptuales son, por lo tanto, una forma muy sencilla y grafica de identificación de riesgos. Consideraciones importantes a la hora de confeccionar un mapa conceptual:
·
Deben ser sencillos y mostrar claramente las relaciones entre sus conceptos.
·
Van siempre de lo general al específico. Las ideas más generales ocupan la parte superior de la estructura, mientras las más específicas la parte inferior.
·
Deben ser vistosos. Cuanto más visual se confeccione el mapa, más cantidad de información será posible de entender y de procesar.
·
Los conceptos, que nunca se repiten, van dentro de recuadros y las palabra enlace se ubican en flechas o líneas de relación.
·
Las palabras enlace deben utilizar verbos, proposiciones o conjunciones.
·
Si la idea principal tiene que ser dividida en dos o más conceptos iguales, estos deberán ir en la misma línea o altura.
11.2.1.14 Diagrama de afinidades (Affinity diagram) El diagrama de afinidad o método KJ ha sido desarrollado por Jiro Kawakita 61 en los años 60 y es una técnica utilizada para ayudar a reunir una gran cantidad de información y organizarla en función de sus afinidades o relaciones naturales, a través de un proceso creativo que produce consenso por medio de la clasificación que hace un equipo. Es muy útil cuando:
· · · ·
El problema es complejo o difícil de entender. El problema parece estar desorganizado. El problema requiere de la participación y soporte de todo el equipo/grupo. Se quiere determinar los temas claves de un gran número de ideas y problemas.
Su desarrollo se realiza da la siguiente forma: PASO 1: Se reúne un grupo de seis a diez personas para que expresen su opinión acerca de una determinada situación y establezcan acuerdos en torno de las causas del problema y sus posibles soluciones. Se utilizará un mediador para organizar la reunión y definir la dinámica de trabajo y las reglas. Se distribuyen tarjetas en blanco entre todos los asistentes. El mediador solicita a los participantes que anoten en las tarjetas las posibles causas del problema analizado. Normalmente, las tarjetas deberán cumplir los siguientes criterios:
·
Los problemas o hechos anotados deben ser concretos. 379
·
No deben anotarse causas, consecuencias, ni juicios.
380
• Los problemas o hechos deben ser precisos y de fácil comprensión. • Registrar el nombre de quien escribe la tarjeta.
Figura 162: Paso 1 del Diagrama de afinidades
PASO 2: Todas las tarjetas utilizadas son recogidas por el mediador. El grupo conocerá los resultados y realizará una primera organización acorde con la similiridad de la información de cada tarjeta
Figura 163: Paso 2 del Diagrama de afinidades
PASO 3: Las tarjetas deberán leerse y revisarse con el fin de comprobar si la agrupación realizada es la correcta y definitiva. Se asignan entonces un nombre a cada grupo de tarjetas por medio de una discusión en grupo. El nombre del grupo deberá transmitir el significado de las tarjetas agrupadas en pocas palabras. Si alguna tarjeta individual no se encaja en ningún grupo, se podrá crear un grupo aparte con un nombre genérico, por ejemplo: “Otros”.
Figura 164: Paso 3 del Diagrama de afinidades
381
PASO 4: El Diagrama de afinidades está completo y deberá tener un aspecto similar al representado en la figura a continuación. El grupo deberá discutir la relación de los grupos y sus elementos correspondientes con el problema.
Figura 165: Paso 4 del Diagrama de afinidades
11.2.1.15 Estructura de desglose de riesgos EDR (Risk breakdown structure - RBS) Es una representación jerárquica de los eventos inciertos, los cuales son identificados y ordenados por categoría de riesgo y subcategoría, reconociendo las distintas áreas y causas de probables riesgos. La estructura de desglose del riesgo se adaptará a cada proyecto específico y proporcionará una estructura que garantiza un proceso completo de identificación sistemática de los riesgos con un nivel de detalle uniforme y ayuda a la calidad y efectividad de la identificación de riesgos.
Figura 166: Ejemplo de EDR
382
11.2.1.16 Lecciones aprendidas (Lessons learned) Descrita en el Apéndice A, doc nº 054
11.2.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 021 – Registro de riesgos (Risk register)
11.3 Análisis cualitativo de riesgos (Proceso que corresponde a la fase de planificación del proyecto) Mediante este proceso, se pretende buscar la priorización de los posibles riesgos que se pueden producir y que ya han sido anteriormente identificados como probables. Se les debe asignar una probabilidad de ocurrencia y el impacto que podrían tener sobre el proyecto. Los riesgos son entonces clasificados en tres niveles: “alto”, “moderado” y “bajo”, a través del auxilio de técnicas sofisticadas y la opinión de expertos.
Figura 167: Ciclo de gestión de riesgos: análisis
383
11.3.1 Técnicas y herramientas 11.3.1.1 Probabilidad de riesgos y valoración de impactos (Risk probability and impact assessment) La probabilidad y las consecuencias de los riesgos en un proyecto en el ámbito del Project Management pueden ser descritas en términos cualitativos como: “alto”, “moderado” y “bajo”. Algunos autores incluyen además los términos “muy alto” y “muy bajo”. Acorde con el PMBOK®, un riesgo tiene una “probabilidad”, que se puede definir como “la posibilidad en “%” de que un riesgo pueda ocurrir”. Además, la eventual ocurrencia de un riesgo, conllevará a una “consecuencia” o “impacto”, que es el efecto causado en proyecto. Es importante resaltar, que estas dos dimensiones se aplican a sucesos específicos de riesgo, no al proyecto en conjunto. Realizando un correcto análisis de riesgos conociendo las probabilidades y sus consecuencias, permitirá clasificar los riesgos de una forma que se pueda dedicar una atención proporcional. La probabilidad y el impacto son, por lo tanto, dos conceptos que no pueden ser ignorados. La probabilidad de que una incidencia puntual ocurra puede ser minima o casi nula, pero si ocurre, sus consecuencias podrían ser catastróficas. Un vuelo comercial es un buen ejemplo. La posibilidad de que se caiga un avión es muy pequeña, pero cuando ocurre, las consecuencias normalmente son trágicas, puesto que las posibilidades de haber supervivientes son prácticamente nulas.
Matriz de evaluación de probabilidad e impacto del riesgo Se construye una matriz donde se clasifican los riesgos, según ilustra la figura 168. El nivel de cada riesgo será clasificado en “alto”, “moderado” o “bajo”. Se puede ampliar la matriz añadiéndole dos clasificaciones más: “muy bajo” y “muy alto”. Un evento que conlleve la ocurrencia de de un riesgo con alta probabilidad y alto impacto, naturalmente será un calificado como de nivel alto (o muy alto, dependiendo de la escala que se utilice). Cada evento deberá ser evaluado individualmente. Si surge un determinado evento que tiene una probabilidad muy baja de ocurrir, pero que si acaso ocurriese, su impacto sería catastrófico (por ejemplo, los atentados en las torres gemelas en Nueva York), se podría considerar como un evento de alto riesgo y debería ser incluido en el plan de gestión de riesgos. (Véase también Apénd ice A, doc nº 020).
384
IMPACTO
A
PROBABILID AD Alta
Alto
NIVEL DE RIESGO Alto
B
Media
Alto
Alto
C
Baja
Alto
Medio
Media
Medio
Medio
Alta
Bajo
Bajo
EVENTO
G
Figura 168: Tabla de probabilidad x impacto
Con está herramienta, es posible determinar de forma sencilla, la acción más adecuada en una determinada relación “probabilidad x impacto”. Existen matrices, como la que ilustra la figura 169, que utiliza nueve combinación de acciones.
PROBABILIDAD IMPACTO
BAJO
MEDIO
ALTO
BAJO
Ignorar
Ignorar
¡Cuidado!
MEDIO
Ignorar
¡Cuidado!
Responder
Figura 169: Tabla de acciones de respuesta
Es posible, además, añadir más detalle a la evaluación cualitativa de riesgos, incrementando información a la probabilidad de ocurrencia de un determinado evento, como ilustra la figura 170 que se presenta a continuación. IMPACTO BAJO
MEDIO
ALTO
1
PROBABILIDA D Muy improbable
Riesgo bajo
Riesgo bajo
Riesgo bajo
2
Improbable
Riesgo bajo
Riesgo bajo
Riesgo medio
Riesgo bajo
Riesgo medio Riesgo medio / alto Riesgo medio / alto
Riesgo medio / alto Riesgo alto
3
Puede o no ocurrir
4
Probable
Riesgo bajo
5
Muy probable
Riesgo bajo
Figura 170: Tabla de probabilidad x impacto
385
Riesgo alto
En vez de utilizar una escala estándar, como la presentada en el ejemplo, se puede elaborar escalas à medida, que serán aplicada para cada evento, separadamente. Con esta escala se pueden determinar acciones concretas, como por ejemplo, establecer que eventos de escala uno o dos pueden ser ignorados, mientras los eventos de escala 4 o 5 deberán ser gestiónados con más detenimiento. El nivel tres representa un riesgo que deberá pasar por una evaluación especial, acorde con cada caso. Se puede también, estimar la probabilidad de ocurrencia de un suceso, a través del uso de fórmulas. En el ejemplo a continuación, fue solicitada la opinión de diez expertos sobre la posibilidad de ocurrencia de un determinado suceso. Para cada posibilidad se le ha asignado un valor: alto (3), medio (2) y bajo (1). Seis expertos afirmaron que este evento es de alta probabilidad de ocurrencia, dos expertos concluyeron que el evento es de media probabilidad de ocurrencia y los otros dos que era de baja ocurrencia. Con estos resultados, se ha desarrollado la siguiente formula: (6x3) + (2x2) + (2 x 1) = (18 + 4 + 2) / 10 = 2.4 Esta fórmula sugiere que el evento una probabilidad media/alta de ocurrencia.
Cualquiera que sea la técnica utilizada para valorar los riesgos de un proyecto, es muy importante seguir las siguientes recomendaciones:
·
Para asegurar una clasificación adecuada sobre la posibilidad de ocurrencia de un suceso, se asume que la probabilidad baja corresponde de 0% a 33%; media, de 33% a 66%, y alta de 66% a 100%.
·
Es importante tener en cuenta la opinión del mayor número de personas posibles. Sin olvidarnos de la vieja regla que dice que “cantidad es menos importante que calidad”. Cuanto más evaluaciones mejor, pero que procedan de personas con experiencia en proyectos similares.
·
Los resultados de cada estimación deben ser recogidos de forma separada. No permita que los expertos consultados tengan la oportunidad de discutir sus evaluaciones en un primer momento. Esto puede influenciar en el resultado final. Una vez recogidas todas las estimaciones y conocidos sus resultados, se podrá promover una reunión conjunta para discutir y llegar a una clasificación única de riesgo.
386
11.3.1.2 Evaluación de la calidad de los datos sobre riesgos (Risk data quality assessment) El análisis cualitativo de riesgos requiere información precisa y no tendenciosa para que sea útil a la gestión del proyecto. La clasificación de la precisión de la información es una técnica para evaluar el grado con el cual la información acerca de los riesgos es útil para la gestión de los mismos. Ello implica examinar:
· · · ·
El grado de conocimiento del riesgo. La información disponible acerca del riesgo. La calidad de la información. Confiabilidad e integridad de la información.
11.3.1.3 Categorización de riesgos (Risk categorization)
Descrito en la sección 11.2.1.15
11.3.1.4 Método de los escenarios (Scenary methods) El concepto “escenario” fue introducido por primera vez en los estudios del futuro por Herman Kahn62, cuyos análisis de las probables consecuencias de una guerra, contribuirían al desarrollo de la estrategia nuclear de los Estados Unidos. Un escenario es la descripción de una situación en el futuro, determinado por una trayectoria de sucesos. Un escenario se construye estableciendo posibles circunstancias previas que pueden llegar a ocurrir y eventualmente provocar dicho escenario efectivamente se constituya. Es importante tener en cuenta que el futuro es una circunstancia incierta que dependerá sobre todo de la toma de una determinada decisión. Existen varios futuros posibles, pero el camino que conduce a uno u otro es forzosamente único. El método de los escenarios tiende a construir una representación de un posible futuro, así como los caminos y/o circunstancias que conducirán a su consecución. Para poder establecer un escenario, hay que cumplir algunas pautas:
·
Es importante determinar exhaustivamente todos los elementos que forman parte del escenario para que el resultado final sea fiable.
·
Las circunstancias que conducirán a un determinado escenario deben tener una determinada probabilidad de ocurrencia.
·
Básicamente se distinguen dos grandes tipos de escenarios: 387
• Exploratorios: parten de tendencias pasadas y presentes y conducen a futuros verosímiles.
·
De anticipación o normativos: construidos a partir de imágenes alternativas del futuro, pueden ser deseables o rechazables. Se conciben de un modo retrospectivo.
El desarrollo de esta herramienta se realiza en dos fases: Fase 1: Construcción de la base. Esta fase consiste básicamente en establecer un conjunto de representaciones del estado actual del sistema constituido por la organización y su entorno. La base es la expresión de un sistema de elementos dinámicos ligados unos a los otros, sistema a su vez, ligado a su entorno exterior. A partir de dicha representación, se llevará a cabo un estudio prospectivo, que contará de cuatro puntos:
·
Elección del horizonte temporal y espacial: El horizonte espacial hace referencia normalmente a la zona donde competimos. El horizonte temporal para la construcción de una base no debe ser un periodo de tiempo ni muy largo ni muy corto. Normalmente se establece un periodo correspondiente al ciclo de vida del proyecto.
·
Elección de las variables esenciales: Se realiza la confección de un listado de las variables clave que son las que van a influir en el escenario futuro. Para poder desarrollar un escenario completo, es imprescindible que se incluyan variables que abarquen el entorno económico, político, tecnológico, legal...
·
Asignación de probabilidades: en este punto se realiza la asignación de dos tipos de probabilidades: la de ocurrencia (que consiste en señalar la posibilidad que variable que consideramos llegue a materializarse en el escenario futuro) y la de importancia.
·
Análisis de inconsistencias y eliminación de variables: Las variables y sus probabilidades deben estar relacionadas entre sí, pero antes hay que asegurarse que no hay inconsistencias entre ellas. Además, también se eliminan algunas variables, que aunque son consistentes, su escasa probabilidad de ocurrencia así lo aconseja.
Figura 171: Construcción de la base
329
Fase 2: Confección de los escenarios. En esta fase se confeccionarán los escenarios utilizando la base de las variables relevantes con sus probabilidades correspondientes, definidas en la fase anterior. Este proceso se realiza en 4 partes:
·
Relación de variables: Hay que relacionar cada variable con las demás. Existen varias técnicas diferentes para hacerlo, la más utilizada es el método de los impactos cruzados (véase siguiente sección).
·
Construcción de escenarios: Una vez que se haya realizado correctamente las relaciones entre las variables, se genera un resumen de éstas y se opta por tres escenarios posibles. Para obtener el escenario más probable (que será en nuestro diagrama el escenario nº 2 o “E2”); se resumen las ideas más importantes de las relaciones de las variables y se plasman en un escenario posible. Los otros dos escenarios (“E1” y “E3”) se construyen a partir del escenario “E2” intensificando las variables más importantes hacia arriba o hacia abajo. Es decir; “E1” = “E2”, intensificando las relaciones hacia arriba y “E3” = “E2”, intensificando las relaciones hacia abajo.
·
Implicaciones: Se describe las eventuales consecuencias resultantes de la ocurrencia de un determinado escenario, normalmente el más probable (“E2”), pero también se describen las implicaciones que se darían en los escenarios “E1” y/o “E3”.
·
Recomendaciones: Se describen las acciones que deben tomarse en el proyecto, en el caso que se dieran uno de los escenarios analizados.
Figura 172: Diagrama completo de escenarios
Es importante tener en cuenta de que los escenarios están sujetos a proporcionar resultados poco realistas. Todo dependerá de la elección de las variables y del correcto establecimiento de sus probabilidades. Los escenarios siempre se basan en hipótesis, más o menos establecidas, que pueden ser cuestionadas a lo largo de todo el proceso de elaboración del escenario. Cuando este ya ha sido elaborado, debe ser contrastado con la realidad y con las posibilidades «reales» de ocurrencia. Si tal escenario no puede tener lugar, entonces es preciso proceder al cambio de las hipótesis de partida, lo que se suele hacerse en base a criterios personales, lo cual puede desembocar en el diseño de un escenario más deseado y quizás la objetividad del proceso sea entonces cuestionable.
389
11.3.1.5 Método de los impactos cruzados (Cross-impact analysis) En el método de los escenarios es frecuente encontrarnos con una importante variedad de hechos cuya probabilidad de que se produzcan esté condicionada por la ocurrencia previa de otros eventos. El método de los impactos cruzados ayuda a determinar la naturaleza y el alcance de las repercusiones entre los distintos acontecimientos que pueden sucederse en el entorno. Sencillamente, se basa en la probabilidad de que ocurra algo si ha ocurrido otra cosa. Lo aclaramos mejor a continuación. El método de los impactos cruzados (cross-impact analysis) ha sido desarrollado por Theodore Gordon63 y Olaf Helmer64 en 1966, y se originó en una pregunta simple: “¿Los pronósticos pueden basarse en las percepciones acerca del modo en que interactuarán los eventos futuros?”. Un cambio en la tecnología, la aprobación de una nueva ley, diferencias culturales o eventos naturales pueden afectar al entorno alrededor de tres maneras distintas:
· · ·
Pueden cambiar la probabilidad de ocurrencia de acontecimientos interconectados. Pueden cambiar el momento en que ocurrirán los acontecimientos interconectados. Pueden afectar al modo de impacto de los acontecimientos interconectados.
Pongamos un ejemplo* Supongamos que se estuviera realizando un estudio del futuro de la industria química. En el transcurso del estudio se genera una lista de eventos futuros importantes. Una parte de esa lista podría incluir los siguientes eventos:
·
El uso de plásticos en los vehículos de transporte y en la construcción aumenta seis veces desde 1992.
·
La mayor intervención gubernamental en el proceso de innovación se origina en las demandas de protección al consumidor y control de la contaminación.
·
La teoría química progresa hasta el punto de que la mayor parte de la investigación química se realiza mediante cálculos por computadora más que mediante la experimentación real.
·
La industria química se expande a la producción textil y a la fabricación de ropa mediante el desarrollo de una tela sintética no tejida.
·
Las empresas químicas obtienen un menor retorno o realizan mayores inversiones en la investigación convencional.
La primera etapa en la utilización de estos eventos en un análisis de impacto cruzado es estimar las probabilidades iniciales de los eventos. Los especialistas, reconociendo que todos estos eventos son posibles e interactúan, pueden ofrecer las siguientes probabilidades:
390
PROBABILIDA D DE QUE OCURRA 2000
EVENTO 1
5
El uso de plásticos aumenta seis veces
0,15
La industria química se expande a los textiles
0,10
Menor retorno respecto de la investigación convencional
0,20
Figura 173: Probabilidad de eventos
El próximo paso es estimar las probabilidades condicionales. En este paso, se diseña una matriz similar al Cuadro 4. Cada celda de la matriz representa la respuesta a la pregunta: "Si ocurre el evento x, ¿cuál es la nueva probabilidad del evento y?" Por ejemplo, la primera celda completa de la primera fila de la matriz contiene la nueva probabilidad del evento 2 dada la ocurrencia del evento 1. Así, la pregunta respondida aquí es, "Si el uso de plásticos en el transporte y la construcción aumenta seis veces (evento 1), ¿cuál es la posibilidad de una mayor intervención gubernamental en el proceso de innovación originado en la demanda de protección al consumidor y control de la contaminación (evento 2)?". Dado que el aumento en el uso de los plásticos probablemente aumente la demanda de protección al consumidor y de control de la contaminación, la ocurrencia del evento 2 será más probable que en el cálculo inicial (0,20) si ocurre el evento 1. De este modo, podemos considerar que la nueva probabilidad del evento 2 será de 0,30, si ocurre el evento 1.
SI ESTE EVENTO OCURRE
1. El uso de plásticos aumenta seis veces 2. Más intervención gubernamental en la innovación 3. Investigación química por computadora 4. La industria química se expande a los textiles 5. Menor retorno respecto de la investigación convencional
PROBABILID AD INICIAL PARA
1
2 0, 30
0,15 0, 1 0
0,20
0, 1 5 0, 1 5 0, 1 5
0,25 0,10 0,20
3
4
5
0,2 5
0,10
0,15
0,3 5
0,07
0,40
0,15
0,05
0, 20 0, 25
0,2 5
0, 15
0,5 0
0,15 0,20
Figura 174: Ejemplo de matriz de probabilidad condicional
391
Dado que las influencias mutuas de los eventos estaban incluidas en los cálculos de la probabilidad inicial, ahora esta opinión debe analizarse para probar su coherencia con las probabilidades iniciales. Utilizando la ecuación 5 y las probabilidades de los eventos 1 y 2, podemos observar que los límites a la probabilidad condicional del evento 2, dado el evento 1, son 0,0 y 1,00. De este modo, no existen problemas respecto de la opinión de 0,30 para la probabilidad del evento 2, dado el evento 1. De manera similar, se completa toda la matriz. La próxima tarea será especificar la política o las evaluaciones de sensibilidad a fin de correrlas con la matriz. En este caso, podríamos desear conocer el efecto sobre los demás eventos si ocurre el evento 3 (uso de computadoras para la mayor parte de las investigaciones químicas). De este modo, se realizaría una evaluación asignando la probabilidad de 1,0 al evento 3 y corriendo nuevamente la matriz. Se realizaría una nueva evaluación para analizar la sensibilidad de los eventos respecto del evento 2 (mayor intervención gubernamental en el proceso de innovación). Estas evaluaciones se indican a continuación:
PRUEBA DE LA PROBABILID 0,15
PROBABILI DAD FINAL 0,14
CAMBI O
1
PROBABILID AD INCIAL 0,15
2
2
0,20
0,20
0,00
3
0,25
1,00
1,00
0,00
4
0,10
0,10
0,12
0,02
EVENTO
-0,01
Figura 175: Evaluación de ocurrencia del evento 3
PRUEBA DE LA PROBABILID 0,15
PROBABILI DAD FINAL 0,13
CAMBI O
1
PROBABILID AD INCIAL 0,15
2
0,20
1
1
0,00
3
0,25
0,25
0,30
0,05
0,20
0,20
0,29
0,09
EVENTO
-0,02
5 Figura 176: Evaluación de sensibilidad del evento 2
De este modo, si el evento 2 ocurriera, la consecuencia más importante sería un aumento de la probabilidad del evento 6, del 20% al 29%. En efecto, en este ejemplo observamos un pequeño escenario.
392
* Ejemplo extraído de la sección Nº 10 de la publicación Futures Research Methodology, Version 1.0, de Jerome C. Glenn, Editor, publicada por el Millennium Project del American Council for the United Nations University, Washington, USA, 1999. Traducción al español: Cuerpo de Traductores de la Biblioteca del Congreso de la Nación – Argentina.
11.3.1.6 Evaluación de la urgencia de los riesgos (Risk urgent assessment) No todos los riesgos exigen el mismo tratamiento, algunos tendrán prioridades sobre otros, con lo cual es importante conocer cuáles son los riesgos que exigen respuestas a corto plazo y una dedicación urgente. Cuando nos encontramos con una lista importante de riesgos es imprescindible disponer de indicadores de prioridad que indicarán el tiempo de respuesta adecuado a los riesgos. La evaluación de la urgencia de respuesta a un riesgo puede estar asociada con la calificación del riesgo, la cual se determina a partir de la matriz de probabilidad e impacto (véase también sección 11.3.1.1) para obtener una calificación final de la severidad y el tiempo de respuesta.
11.3.1.7 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
11.3.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 021 – Actualizaciones al registro de riesgos (Risk register updates)
11.4 Análisis cuantitativo de riesgos (Proceso que corresponde a la fase de planificación del proyecto) El objetivo de la cuantificación de los riesgos es establecer una forma de organizar los riesgos en orden de prioridad. Esto es importante porque, en muchos proyectos, no habrá tiempo o recursos financieros disponibles para afrontar todos los riesgos identificados. Los valores cuantitativos pueden ser aplicados a los riesgos utilizando un análisis entre probabilidad e impacto. Normalmente, se utilizan los siguientes valores para determinar las probabilidades:
· · ·
Riesgo cero: No existe la posibilidad de que este riesgo pueda ocurrir. Riesgo bajo: La probabilidad de ocurrencia puede ser entre el 1 y el 40%. Riesgo medio: La probabilidad de ocurrencia puede ser entre en 41 y el 70%.
393
·
Riesgo alto: La probabilidad de ocurrencia puede ser entre el 71 y el 99%.
394
Este análisis cuantitativo se realiza a continuación del análisis cualitativo de riesgos y utilizando las escalas obtenidas en la visión cualitativa. Básicamente, dentro de las funciones o aportaciones que realiza el análisis cuantitativo está el análisis de las consecuencias que tienen esos riesgos y la asignación de un valor numérico para que ayude a la toma de decisiones de una forma más correcta y efectiva, aminorando de alguna forma la incertidumbre e intentando dar una visión más realista de la evolución del proyecto. Se usan, por lo tanto, para:
· · · ·
Dar un valor numérico a los resultados del proyecto y sus probabilidades. Establecer las mejores decisiones cuando aparezca alguna contingencia. Valorar que probabilidades existen de lograr ciertos objetivos del proyecto. Establecer qué riesgos son los que necesitan una mayor atención.
Figura 177: Ciclo de gestión de riesgos: análisis
El estudio de impacto x probabilidad se realiza a través de la matriz que presentamos a continuación. El cruce de sus variables determinará las acciones preventivas adecuadas.
IMPACTO ALTO
MEDIO
BAJO
ALTA
Alto
Alto
Bajo
MEDIA
Alto
Medio
Bajo
PROBABILIDAD Figura 178: Tabla de probabilidad x impacto
395
11.4.1 Técnicas y herramientas 11.4.1.1 Técnicas de recopilación y representación de datos (Data gathering and representation techniques) ·
Entrevistas: Véase también sección 5.1.1.1.
·
Distribuciones de probabilidad: Acorde con el PMBOK®, las distribuciones continuas de probabilidad, utilizadas ampliamente en el modelado y la simulación (véase también sección 11.4.1.2), representan la incertidumbre de valores tales como las duraciones de las actividades del cronograma y los costes de los componentes del proyecto. Las distribuciones diferenciadas pueden emplearse para representar eventos inciertos, como el resultado de una prueba o un posible escenario en un árbol de decisiones.
11.4.1.2 Análisis cuantitativo de riesgos y de modelado (Quantitative risk Analysis and modeling) Puede ser realizado a través de las siguientes técnicas:
·
Análisis del valor monetario esperado: Acorde con el PMBOK®, el análisis del valor monetario esperado (expected monetary value) es un concepto estadístico que calcula el resultado promedio cuando el futuro incluye escenarios que pueden ocurrir o no (es decir, análisis bajo incertidumbre). El valor monetario esperado de las oportunidades se expresará, por lo general, con valores positivos, mientras que el de los riesgos será negativo. El valor monetario esperado requiere una suposición de neutralidad del riesgo, que no se trate de una aversión al riesgo ni de una atracción por éste. El valor monetario esperado para un proyecto se calcula multiplicando el valor de cada posible resultado por su probabilidad de ocurrencia, y sumando luego los resultados.
·
Modelado y simulación: Acorde con el PMBOK®, una simulación de proyecto utiliza un modelo que traduce las incertidumbres detalladas especificadas del proyecto en su impacto potencial sobre los objetivos del mismo. Las simulaciones iterativas se realizan habitualmente utilizando la técnica Monte Carlo. En una simulación, el modelo del proyecto se calcula muchas veces (mediante iteración) utilizando valores de entrada (por ejemplo, estimaciones de costes o duraciones de las actividades) seleccionados al azar para cada iteración a partir de las distribuciones de probabilidad para estas variables. A partir de las iteraciones, se calcula una distribución de probabilidad (por ejemplo, el coste total o la fecha de conclusión). Para un análisis de riesgos de costes, una simulación emplea estimaciones de costes. Para un análisis de los riesgos relativos al cronograma, se emplean el diagrama de red del cronograma y las estimaciones de la duración.
11.4.1.3 Juicio de expertos (Expert judgement) 396
Descrito en la sección 4.1.1.1
11.4.1.4 Entrevistas (Interviews)
Descrito en la sección 5.1.1.1
11.4.1.5 Análisis del árbol de decisiones (Decision tree analysis) Esta herramienta permite que se desglose una condición en varias acciones, determinando las probabilidades de que ocurra y sus resultados, ayudando al Project Manager a elegir la decisión más adecuada para avanzar en alguna fase determinada de un proyecto. El árbol de decisiones se dibuja sobre un plano horizontal, con la raíz del árbol al lado izquierdo del papel y las ramas hacia la derecha. Esto permite describir las condiciones de acciones sobre las ramas. Un árbol de decisiones empieza con la decisión que tienes tomar. Esta decisión es representada por un cuadrado (nodo de decisión). Conforme avance el árbol, otros nodos podrán aparecer.
1 Figura 179: Nodo de decisión
Desde este nodo salen las ramas que representan las opciones que tenemos para elegir. Si una de las opciones es un evento incierto, se dibujará un círculo. Si el la opción resulta en otra decisión, entonces se dibujará otro cuadrado. Si acaso se ha encontrado la solución, se dejará la rama en blanco.
Figura 180: Primeras ramas del árbol de decisiones
De los círculos salen las ramas que representan los posibles resultados provenientes de eventos inciertos sobre los que no se tiene control. En cada línea se describen los resultados que se pueden
397
obtener.
398
Figura 181: Primeras ramas del árbol de decisiones
Los círculos de eventos inciertos, los cuadrados de decisiones y las ramas correspondientes seguirán desarrollándose hasta que se llegue a la decisión más adecuada.
399
Figura 182: Escenarios
400
La secuencia temporal de un árbol de decisiones se desarrolla de izquierda a derecha. Las ramas que llegan a un nodo desde la izquierda ya ocurrieron. Las ramas que salen hacia la derecha todavía no. Siempre que se dibuje un árbol de decisiones es importante distinguir entre las condiciones y las acciones. Para este propósito, según he explicado anteriormente, el uso de un nodo cuadrado indica una decisión y un nodo redondo representa una condición, tal y como se representa en la figura 183. Una forma sencilla de interpretar un árbol de decisiones es tener en cuenta el círculo significa “si”, mientras que el cuadrado significa “entonces”. Dado que quien toma las decisiones controla las ramas que salen de cada nodo de decisión, se elige la rama que resulte en el mayor valor esperado. Se van tachando todas las ramas que no sean seleccionadas y se prosigue el análisis hacia la derecha del árbol, hasta seleccionar la primera decisión.
Evaluando el árbol de decisiones Terminada la confección del árbol, llega el momento de evaluar financieramente su decisión. Para ello, se asigna un valor orientativo para cada resultado posible. De esta forma, será posible llegar al coste de una determinada decisión. Esta evaluación empieza estimando una probabilidad para cada resultado proveniente de un evento posible (los círculos). Una vez que se estime todos los valores posibles, el árbol tendrá este aspecto:
401
Figura 183: Evolución del árbol de decisiones
Realizando los cálculos Una vez designadas las probabilidades y los valores financieros de cada resultado, llega el momento de empezar a calcular el valor definitivo que facilitará la toma de una decisión. Para llegar al resultado financiero de una decisión, se multiplica el valor de un evento incierto (los círculos) por su probabilidad:
Opción A 0,5 (probabilidad del escenario A) x 20.000 0,3 (probabilidad del escenario B) x 18.000 0,2 (probabilidad del escenario C) x 12.000 Total: 17.800
= 10.000 = 5.400 = 2.400
402
Opción B 0,2 (probabilidad del escenario D) x 20.000 0,8 (probabilidad del escenario E) x 8.600 (valor) Total: 10.680
= =
4.000 6.880
= = =
8 0 3.600 4.500
= = =
1.200 3.000 1.200
Opción C 0,1 (probabilidad del escenario F) x 8.000 (valor) 0,3 (probabilidad del escenario G) x 12.000 0,6 (probabilidad del escenario H) x 7.500 (valor) Total: 8.900
Opción D 0,4 (probabilidad del escenario I) x 3.000 (valor) 0,3 (probabilidad del escenario J) x 10.000 0,3 (probabilidad del escenario K) x 4.000 (valor) Total: 5.400
403
Figura 184: Resultados del árbol de decisiones
404
Cuando se está evaluando una decisión se escribe el coste estimado en la línea de decisión. Se resta el coste estimado de los valores de cada resultado encontrado anteriormente. Esta operación resultará en la ganancia obtenida en cada decisión. Los costes estimados serán siempre los costes futuros, no se consideran los costes pasados. Después de calcular la ganancia de cada decisión, se elegirá la opción que tiene mejor ganancia.
Figura 185: Resultados del árbol de decisiones
En la figura 185 la ganancia calculada para vender un software propio a través de desarrollo con personal propio es de 17.800 euros. Se ha estimado un coste orientativo de 9.000 euros lo que resultaría en una ganancia liquida (descontando los costes) de 8.800 euros. Analizando las otras opciones, se concluye que en el caso ilustrado en este ejemplo, la mejor decisión en términos financieros es vender un software propio, desarrollado con el personal en plantilla. Por otro lado, si elegimos revender un software de mercado y decidimos hacerlo con un software importado, tendríamos casi la mitad del coste, pero la ganancia sería bastante menor.
405
El árbol de decisiones es un método eficaz de decisión porque:
· · ·
Nos permite analizar íntegramente las posibles opciones obtenidas de cada decisión. Nos posibilita estimar probabilidades y valores retornos financieros. Nos ayuda a tomar decisiones basadas en números con gran margen de acierto.
11.4.1.6 Simulación de Montecarlo (Montecarlo method) La simulación de Montecarlo es un método no determinístico o estadístico numérico usado para aproximar expresiones matemáticas complejas y costosas de evaluar con exactitud. Tiene este nombre en referencia al Casino de Montecarlo, por ser la “capital europea del juego de azar” al ser la ruleta un sencillo generador de números aleatorios. Ha sido desarrollado por Stanislaw Ulam 65 y John Von Neumann66. Mientras se recuperaba de una enfermedad, Ulam65 jugaba al solitario y se le ocurrió que resultaba mucho más sencillo tener una idea del resultado general del solitario haciendo pruebas múltiples con las cartas y contando las proporciones de los resultados que computar todas las posibilidades de combinación formalmente. La idea consistía en probar con experimentos mentales las miles de posibilidades, y en cada etapa, determinar por casualidad, por un número aleatorio distribuido según las probabilidades, qué sucedería y totalizar todas las posibilidades y tener una idea de la conducta del proceso físico. Tras una etapa inicial de investigación, John von Neumann66 y Stanislaw Ulam65 refinaron esta ruleta rusa y los métodos "de división" de tareas. Sin embargo, el desarrollo sistemático de estas ideas tuvo que esperar al trabajo Herman Kahn62 en 1948. En el ámbito del Project Management, esta técnica es aplicada en cualquier proceso que presente alguno grado de incertidumbre o donde hayan sido identificados determinados riesgos. Por ejemplo, para ejecutar un determinado proyecto, es necesario identificar las actividades necesarias para su puesta en marcha, su secuencia lógica y su duración. Con estas informaciones se desarrolla un cronograma con todas las fechas de inicio y fin estimadas. Estas estimaciones normalmente no alcanzan el 100% de exactitud, debido a un cierto grado de incertidumbre, muy común en los proyectos. La técnica de Montecarlo crea una simulación que describe cómo un determinado proceso generará determinados resultados. Esta simulación no devuelve una respuesta única, sino una gama de respuestas posibles y la probabilidad de cómo cada una de estas respuestas se producirá.
406
11.4.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 021 – Actualizaciones al registro de riesgos (Risk Register Updates)
11.5 Plan de respuesta al riesgo (Proceso que corresponde a la fase de planificación del proyecto) Una vez identificados y priorizados los riesgos, la planificación de respuesta al riesgo desarrolla opciones y determina acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. La planificación respuesta al riesgo es el proceso por el que podemos desplegar alternativas y seleccionar acciones para disminuir la incertidumbre y el riesgo. Tienen que ser adecuadas a la importancia del riesgo, aplicadas en el momento adecuado, ser realistas, acordadas por todas las partes implicadas y con un coste efectivo en relación al riesgo.
Figura 186: Ciclo de gestión de riesgos: planificación
Todos los eventos de riesgo identificados afectarán al proyecto de alguna manera si llegan a concretizarse. En las secciones anteriores, hemos conocido las herramientas para identificar los riesgos, se han evaluado dichos riesgos y determinado su probabilidad de ocurrencia e impacto. Además, se han priorizado los riesgos según su importancia. Ahora es el momento de decidir cómo afrontarlos, de preparar un plan de respuesta a estos riesgos. Las organizaciones y las personas tienen distintos comportamientos a la hora de afrontar un determinado riesgo. Existen por ejemplo, algunos patrocinadores que no se arriesgan en soluciones nuevas que fueron poco probadas, estos son conocidos como “conservadores”. Sin embargo, hay patrocinadores que apuestan en nuevas ideas, por creer que al afrontar un determinado riesgo, y superarlo, estarán sacando partido de una oportunidad antes que otros. Son los considerados “agresivos”, aquellos que afrontan el riesgo a todo coste.
407
De la misma forma, hay Project Managers que toleran el riesgo más que otros. Mientras algunos son muy conservadores e intentan reducir el riesgo del proyecto aplazando fechas o ampliando su personal técnico (a veces, generando más costes), otros son más agresivos, aceptan mejor los riesgos y, muchas veces, logran resultados espectaculares (asumiendo eventuales consecuencias). Eso dependerá del carácter de cada individuo. En el caso de asumir un riesgo en un proyecto, generalmente existen tres tipos de actitudes:
Figura 187: Tolerancia al riesgo
Todo dependerá del tipo de riesgo que se afronta, la probabilidad que pueda ocurrir y, principalmente, su impacto (negativo o positivo) en el proyecto. La gestión de riesgos cuantifica la probabilidad y el impacto de cada riesgo, ayudando el Project Manager a direccionar mejor sus estrategias.
11.5.1 Técnicas y herramientas 11.5.1.1 Estrategias para riesgos negativos o amenazas (Strategies for negative risks or threats) Una vez que se realice un correcto análisis de los riesgos identificados, el siguiente paso es establecer la estrategia para cada uno de ellos. Dependiendo del entorno y de la sensibilidad al riesgo, algunas organizaciones elegirán entre una u otra estrategia. Todo dependerá del tipo de riesgo, de la sensibilidad que la organización, de su capacidad financiera, alcance geográfico, recursos, entre otros factores. A continuación, y en las siguientes secciones, conoceremos las principales estrategias de respuesta a riesgos practicadas en el ámbito del Project Management.
408
Evitar Evitar un riesgo, en pocas palabras, significa “no aceptarlo”. Al evitar un riesgo, se elimina el motivo que provoca el problema. Eso puede conllevar a cambiar completamente las acciones determinadas en el plan original. Un claro ejemplo de evitar un riesgo es el caso de los autobuses espaciales. Cuando las condiciones meteorológicas no lo permiten, normalmente su lanzamiento es abortado. Eso conlleva en retrasos en las misiones espaciales programadas, pero en cambio, podrá preservar la vida de los astronautas.
Transferir Otra forma de reducir la exposición a un riesgo, es transferir el riesgo a terceros. Un caso clásico de transferencia de riesgos es la subcontratación de empresas para realizar un determinado trabajo. Esta estrategia no elimina el riesgo, pero transfiere la responsabilidad a otros. En estos casos, normalmente se establece un contrato con compensaciones financieras a la empresa que está asumiendo el riesgo por nosotros. La contratación de un seguro, es un ejemplo de transferencia de riesgo.
Prevenir La prevención supone realizar una acción previa con el objetivo de reducir la probabilidad de ocurrencia de una determinada incidencia. Para ello, es importante intentar identificar la causa de esta incidencia potencial y realizar las acciones correspondientes. Un ejemplo claro es la prevención de riesgos laborales, donde los trabajadores de obra utilizan elementos de seguridad con el fin de prevenir que ocurran accidentes.
Mitigar Es una de las estrategias de respuesta a riesgos más utilizadas y que tiene como objetivo reducir los efectos negativos de una incidencia. Una planificación bien estructurada, la contratación de más personal, la ampliación de la oferta de proveedores, la dedicación de más tiempo de pruebas, son formas de disminuir la probabilidad de ocurrencia de eventos de riesgo. La mitigación de riesgo conlleva a reducir su posibilidad de ocurrencia a niveles aceptables y de fácil administración. Mitigar un riesgo puede ser por ejemplo, poseer un amplio abanico de inversiones financieras. Personas que invierten sus ahorros en inmuebles, diferentes fondos de plazo fijo, acciones..., corren menos riesgo de sufrir con cualquier impacto negativo en la economía del país.
Aceptar Aceptar un riesgo es simplemente, no hacer nada. Seguir los planes originales, asumir las consecuencias o tratar con ellas cuando ocurran. Es sin duda una estrategia agresiva. Sin embargo, el riesgo, muchas veces es una oportunidad. De la misma manera que aceptar un riesgo puede generar problemas, aceptarlos también podrá traer resultados importantes. De todas formas, normalmente se acepta un riesgo cuando su impacto es bajo. Si no es así no tiene sentido aceptarlo, como por ejemplo, si existe la posibilidad de poner en riesgo vidas humanas para llevar a cabo una determinada actividad.
409
Aceptar un riesgo no significa que no se actuará cuando un suceso ocurra. Pero se actuará solamente cuando dicho ocurra. En esta estrategia se encajan normalmente eventos de bajo impacto cuyos costes de corrección son más bajos que los costes de prevención. Existen dos formas de aceptación del riesgo: aceptación activa y pasiva: En la aceptación pasiva, el equipo del proyecto no realiza ninguna acción para afrontar el riesgo. Simplemente espera que este ocurra y a continuación desarrolla acciones para corregir sus efectos. Es una forma de gestionar pequeños e insignificantes eventos de riesgo cuyo coste de investigación son mayores que sus correcciones a posteriori. Por ejemplo, una empresa de refrescos decide realizar un concierto promocional en una región de playa en el verano, cuando las temperaturas son muy agradables y el riesgo de lluvia es mínimo. Aunque exista una posibilidad de lluvia, la empresa decide realizar el evento, sabiendo que para promocionar su producto, no hay otra estación más adecuada que el verano. Cuando el Project Manager adopta una postura de aceptación activa, se desarrolla un plan de acción que es llevado a cabo cuando ocurra un suceso. Es una estrategia muy importante ya que podrá traer resultados más eficaces, una vez que es mejor buscar una solución planificada para ponerla en práctica cuando sea necesario, que buscar una solución correctora en el calor del momento, que muchas veces podrá ser la solución equivocada. Utilizando el ejemplo anterior, si en el día del concierto programado por la empresa de refrescos, cae una tormenta sobre la ciudad, la empresa tendrá reservada una inmensa carpa para poder acoger al público. El desarrollo del plan de acción resultará en un plan de contingencia (descrito en la sección 11.5.1.3)
Acuerdos contractuales relacionados con los riesgos Los acuerdos para transferencia de riesgos, tales como acuerdos para seguros, servicios y otros temas según corresponda, se establecen en el marco de las estrategias descritas anteriormente. Esto puede suceder como resultado de mitigar o transferir parte o toda la amenaza, o de mejorar o compartir parte o toda la oportunidad. El tipo de contrato elegido proporciona también un mecanismo para compartir los riesgos.
11.5.1.2 Estrategias para riesgos positivos u oportunidades (Strategies for positive risks or opportunities) De las cuatro estrategias presentadas a continuación, tres son utilizadas sobre todo para el tratamiento de riesgos con impactos potencialmente positivos sobre el proyecto. La cuarta y última estrategia (aceptar), se puede utilizar tanto para los riesgos negativos o positivos (tal y como explicado la sección anterior).
Explotar Esta estrategia busca la eliminación de la incertidumbre asociada con un riesgo positivo, asegurando que la potencial oportunidad realmente llegue a concretizarse. Un ejemplo de explotación incluye la asignación de un equipo técnico muy experimentado que pueda ser capaz de reducir el tiempo de ejecución de una determinada tarea, ofreciendo un coste inferior a lo inicialmente planificado.
410
Compartir Compartir implica asignar todo o parte de la propiedad de la oportunidad a un tercero que reúna las capacidades necesarias para capturar esta oportunidad en beneficio del proyecto, como por ejemplo las uniones temporales de empresas que pueden establecerse con el objetivo de tomar ventaja de una determinada oportunidad, de modo que todos los involucrados se beneficien a partir de su implicación.
Mejorar Esta estrategia es aplicada con el impactos y/o beneficios de una adecuadas puede incrementar su mejorar el tiempo de ejecución de necesarios.
objetivo de aumentar y/o potencializar los eventuales oportunidad. La aplicación de fuerzas impulsoras probabilidad de ocurrencia. Por ejemplo, se puede una determinada actividad, añadiéndole los recursos
Aceptar Aceptar una oportunidad consiste en tener la voluntad de tomar ventaja de ella si se presenta, pero sin buscarla de manera activa.
11.5.1.3 Plan de contingencia (Contingency plan) Un plan de contingencia determina acciones específicas para atacar directamente factores de riesgo llamados “conocidos desconocidos” (knowns unknows). Son factores que sabemos que existen, pero no estamos seguros si ocurrirán. Por ejemplo, sabemos que los datos informáticos producidos durante el proyecto pueden ser afectados por un virus o un problema en el servidor. Es un riesgo que conocemos, pero no sabemos si realmente podrá ocurrir. El plan de contingencia determinará la puesta en marcha de copias de seguridad, para evitar cualquier pérdida de datos producida por una incidencia informática. El plan de contingencia es un documento que debe estar listo en la fase de planificación del proyecto, mucho antes del proyecto entrar en la fase de ejecución. Este plan ayudará a planificar y coordinar las acciones adecuada de respuesta en tiempo. (Para más detalles acerca de este documento, consulte el doc nº 025, en el Apéndice A).
11.5.1.4 Gestión de reservas (Reserve management) Las reservas son como un “colchón” de recursos, que el proyecto dispone para hacer frente a un evento imposible de prever, o totalmente desconocido (unknowns unknowns). Las reservas podrán ser financieras, de tiempo, de recursos humanos o de maquinaria.
411
11.5.1.5 Gestión del riesgo residual (Residual risk Mmanagement) Todas las estrategias definidas en las secciones anteriores son imprescindibles para una planificación adecuada de respuesta a los riesgos. No obstante, ningún control puede ofrecer una seguridad absoluta, y por lo tanto, siempre quedará un algún grado de riesgo que en Project Management se conoce como “riesgo residual”. El concepto de riesgo residual es definido por el estándar para la seguridad de la información ISO/IEC 27001, en el apartado 3, término 3.9, como “el riesgo remanente que existe después de que se hayan tomado las medidas de seguridad”. En otras palabras, cualquier riesgo que permanezca, que no consiga ser eliminado, tras haber implantado un plan de respuesta de un riesgo se llama “residual”, y debería ser identificado y analizado como cualquier otro riesgo. Un ejemplo de riesgo residual: En la edad media, las ciudades eran cercadas por murallas altas para evitar el asalto del ejército enemigo. Sin embargo, los administradores de estas ciudades deberían asumir el riesgo residual de que el enemigo pudiera contar con potentes armas de asedio, como las lanza piedras (o fundíbulos) que eran capaces no solo de destruir gruesas murallas como lanzar proyectiles sobre muros muy altos. Es importante que la organización tenga en cuenta la probable existencia de un riesgo residual, por lo tanto, la primera acción de la organización es aceptar la posibilidad de existencia de un riesgo residual que necesitará de una respuesta adecuada si llega a producirse.
Figura 188: Gestión de Riesgo residual
La gestión de un riesgo residual es relativamente sencilla. Se deberá reconocer el riesgo residual como un nuevo riesgo a ser tratado y aplicarle las estrategias de respuestas que mejor le pueda hacer frente, eliminando sus consecuencias o mitigándolas lo máximo posible.
412
11.5.1.6 El plan B (Fallback plan) Aunque se trata de una situación extremadamente rara, siempre cabe la posibilidad de que ocurra algún evento improbable cuyas acciones preventivas y correctivas, los planes de reserva y contingencia no sean suficientes para detener sus consecuencias. En casos como este, se suele realizar una acción llamada fallback plan, que simplemente significa “retroceder”. Es una acción similar a la estrategia de “evitación” (véase también 11.5.1.1). Sin embargo, la estrategia de evitación implica en librarse de una determinada acción o circunstancia. El fallback plan, por otro lado prevé detener todo el plan. Esto suele ocurrir por dos motivos: 1. El proyecto no ha contado con una buena planificación. 2. Ha ocurrido algún suceso que no ha sido previamente identificado o considerado. En la mayoría de los casos en que se utiliza el recurso del fallback plan, el proyecto no vuelve a reanudarse y es abandonado. Durante la Segunda Guerra Mundial, el mando militar alemán desarrolló un plan para invadir la Gran Bretaña. Este plan fue bautizado de “Operación León Marino” (Unternehmen Seelöwe en alemán). La invasión no llegó a ejecutarse, si bien sus preparativos fueron muy intensos y la amenaza de invasión se mantuvo durante bastante tiempo Los planes de invasión de Rusia y el inicio de la misma hacen que Alemania decida abandonar definitivamente la operación.
11.5.1.7 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
11.5.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 021 – Actualizaciones al registro de riesgos (Risk register updates)
I
Acuerdos contractuales relacionados con los riesgos. Véase sección 11.5.1 (Risk-related rontract decisions)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
413
11.6 Supervisión y control de riesgos (Proceso que corresponde a la fase de control del proyecto) La supervisión y control de riesgos es una importante labor de gestión que debe ser realizada continuamente para detectar probables riesgos nuevos (sobre todo residuales – véase también sección 11.5.1.5) y/o la modificación de los riesgos previamente detectados. Durante la ejecución de este proceso se podrá apreciar que algunos riesgos perderán importancia, mientras otros se volverán más importantes. Por otro lado, algunos riesgos dejarán de existir y otros nuevos aparecerán. Acorde con el PMBOK®, una supervisión y control eficaz de los riesgos, conlleva en poner en marcha las siguientes gestiones:
· · · ·
Implementar estrategias de respuesta a los riesgos identificados;. Rastrear dichos riesgos. Identificar y monitorizar los riesgos residuales. Evaluar la efectividad del proceso contra los riesgos a través del proyecto.
Otras finalidades del proceso monitorizar y controlar los riesgos es determinar si:
· · · ·
Los supuestos del proyecto siguen siendo válidos. Los análisis muestran que un riesgo evaluado ha cambiado o puede descartarse. Se respetan las políticas y los procedimientos de gestión de riesgos. Las reservas para contingencias deben modificarse para alínearlas con la evaluación actual de los riesgos.
Figura 189: Ciclo de gestión de riesgos: supervisión y control
El proceso de supervisión y control de riesgos puede, además, implicar en la selección de estrategias alternativas, la puesta en marcha de un plan de contingencia (véase también sección 11.5.1.3), la implantación de acciones correctivas o en un escenario más drástico, una importante modificación en el plan de proyecto. Los responsables por las estrategias de respuesta al riesgo deberán mantener el Project Manager constantemente informado acerca de su evolución y eficacia, sobre cualquier efecto anticipado o sobre cualquier corrección necesaria para gestionar adecuadamente el riesgo.
414
11.6.1 Técnicas y herramientas 11.6.1.1 Reevaluación de los riesgos (Risk reassessment) Un continuo proceso de monitorización, control y seguimiento de los riesgos nos puede proporcionar una identificación de nuevos riesgos, sobre todo los residuales (véase también sección 11.5.1.5), una reevaluación de los riesgos existentes y el cierre de los riesgos obsoletos y/o eliminados. Estas monitorizaciones deben ser programadas por el equipo de proyecto y pueden coincidir con las auditorias de riesgo (véase también la siguiente sección).
11.6.1.2 Auditorías de riesgos (Risk audits) Las auditorias de riesgos son realizadas con el objetivo de examinar y documentar eficiencia de las estrategias de respuesta adoptadas (véase también sección 11.5.1) y si estas están teniendo el efecto deseado. El Project Manager es el responsable de asegurar que las auditorías de riesgos se realicen con una frecuencia apropiada, según está definido en el plan de gestión de riesgos (véase también doc nº 020, Apéndice A). Las auditorías de riesgos pueden incluirse durante reuniones de rutina de revisión del proyecto, o bien, pueden celebrarse reuniones de auditoría específicas para este fin.
11.6.1.3 Análisis de variación (Variance and trend analysis)
Descrito en la sección 5.5.1.1
11.6.1.4 Medición del desempeño técnico (Technical performance measurement) La medición del desempeño técnico compara el grado de cumplimiento de los objetivos técnicos durante la ejecución del proyecto. Requiere la definición de determinadas medidas cuantificables que puedan ser utilizadas para comprar los resultados reales con los previstos. Las mediciones de desempeño técnico pueden incluir:
· · ·
Pesos. Tiempos de transacción. Numero de piezas entregadas.
415
· · ·
Capacidad de almacenamiento Velocidad de procesamiento Otros.
416
Una desviación, como ofrecer una mayor o menor funcionalidad con respecto a la planificada, puede ayudar a predecir el grado de éxito que se logrará en cumplir con el alcance del proyecto y también puede mostrar el grado de riesgo técnico que enfrenta el proyecto.
11.6.1.5 Análisis de reserva (Reserve analysis) Descrito en la sección 7.1.1.6
11.6.1.6 Reuniones sobre el estado del proyecto (Status meeting) Descrito en la sección 4.3.1.4
11.6.1.7 Análisis de hipótesis o supuestos (Assumptions analysis) Descrito en la sección 11.2.1.4
11.6.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 021 – Actualizaciones al registro de riesgos (Risk register updates)
I
Actualizaciones a los activos de los procesos de la organización (Organizational process assets updates) – Las que correspondan
I
DOC nº 039 – Solicitudes de cam bio (Change requests)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
417
Capítulo 12 Gestión de compras y contratos “Nada es barato ni caro, todo es igual en la vida. Las cosas valen tan solo lo que cuesta conseguirlas” Francisco Villaespesa67, escritor español
419
Algunas cosas en las que NO puedes pensar acerca de la gestión de compras y contratos “Tenemos una relación profesional con este proveedor desde hace muchos años. Hacer un contrato puede generar un ambiente de desconfianza" Todos los proyectos, casi sin excepción, traen alguna clase de riesgo que debe ser asumida por todos los implicados en su puesta en marcha. El grado de confianza entre empresas o profesionales no puede ser un escollo para delimitar responsabilidades y formalizarlas en un documento. El contrato, por lo tanto, se convierte en el pilar básico de la relación entre una empresa y sus proveedores, de modo que las partes no han de escatimar esfuerzos para elaborar un documento que va a ser la única “ley” entre ellas. Es cierto que además del contrato, vienen por detrás toda una serie de normas de diverso rango y contenido, como pueden ser por ejemplo: Derecho de sociedades, LOPD, Propiedad Intelectual, Defensa de la Competencia, Consumidores y Usuarios, normas tributarias...); pero siempre será el contrato la fuente esencial de derechos y obligaciones entre las partes y el marco regulador del día a día de su relación comercial. “No podemos ser flexibles. Hay que con feccionar un contrato que no proporcione ninguna margen de maniobra al proveedor. Somos nosotros el cliente, con lo cual, las cláusulas las ponemos nosotros, sin discusión previa” Bajo este comentario, nos encontramos en una situación donde el contratante incluye en el contrato algunas cláusulas que colocan al proveedor en una situación de inferioridad no justificada. Si bien es cierto que es el contratante que establece las “reglas del juego”, esta condición natural de “parte fuerte” no debería servir de argumento para imponer al proveedor obligaciones abusivas. El proveedor es una empresa como cualquier otra que, al formar parte de un proyecto, también asume riesgos, de manera que la imposición de restricciones excesivas podría provocar una serie de problemas, que sin duda, perjudicarían el buen avance de un proyecto. Un proveedor, es más que nada, un colaborador. “¿No te parece exagerado hacerles un contrato de con fidencialidad?” La información generada por un proyecto (información relativa a los productos, servicios, clientes, proveedores, personal, método de trabajo, organización, estrategias empresariales, información económica y financiera...) se considera como uno de los principales activos de negocio de cualquier empresa, y como tal, debe ser protegida adecuadamente con medios técnicos y legales, de forma que se evite, en la medida de lo posible, que cualquier persona física o jurídica pueda acceder, obtener, tratar, y/o difundir la información ilícitamente, causando perjuicios a cualquier empresa o profesional implicados en el proyecto.
Introducción 420
La Gestión de compras y contratos trata de la obtención de recursos a partir de fuentes externas a la organización. Estos recursos pueden incluir entre otras cosas: mano de obra, equipos, maquinaria, softwares, servicios o una combinación de estos. La adquisición de un producto o servicio a partir de una empresa externa conlleva a la confección, gestión y mantenimiento de contratos, que deberán asegurar la entrega de los productos o servicios dentro del plazo, coste y especificaciones contratadas.
421
Hoy día, las organizaciones, en búsqueda de principalmente lograr una reducción de costes, adoptan la estrategia de contratar servicios externos que puedan cumplir con sus necesidades, en lugar de desarrollarlos internamente. El proveedor contratado, tiene la responsabilidad de garantizar que el producto y/o servicio entregado cumplirá con todas las exigencias establecidas por el cliente, o por un contrato de servicios, cuando corresponda. Este capítulo no tratará de profundizar los aspectos legales acerca de los contratos de un proyecto, partiendo del principio que el Project Manager no posee el perfil de un abogado. Sin embargo, lograr un buen contrato exige mucha negociación, y negociar es una de las habilidades de un Project Manager. Además, es muy importante que se conozcan los conceptos básicos y los detalles que son objeto de un tratamiento jurídico especifico del Project Management. Bajo el enfoque de la cuarta edición del PMBOK®, la gestión de la integración de un proyecto incluye procesos y actividades necesarias para los procesos de compra o adquisición de los productos, servicios o resultados que es necesario obtener fuera del equipo del proyecto. Son ellos:
· · · ·
Plan de compras y contratos. Conducción de compras. Administración del contrato. Cierre del contrato.
12.1 Plan de compras y contratos (Proceso que corresponde a la fase de planificación del proyecto) En todo proyecto se hace necesario determinar cuáles serán los componentes suministrados por un proveedor externo y cuáles serán los desarrollados por los recursos internos de la organización. Planificar las adquisiciones es el proceso que consiste en documentar las decisiones de compra para el proyecto, especificando su gestión e identificando potenciales proveedores. Este proceso también incluye la identificación de necesidades y cómo ellas podrán satisfacer adecuadamente los requisitos del proyecto, mediante la adquisición de productos y servicios fuera de la organización del proyecto. Además, este proceso también implicará la decisión de obtener apoyo externo, o si fuera el caso, qué adquirir de qué manera, en qué cantidad y cuando hacerlo. Todas las decisiones acerca de contratar servicio externo o comprar material de proveedores, traen una serie de riesgos que deberán ser identificados, evaluados y tratados según la probabilidad e impacto de cada uno en el proyecto.
12.1.1 Técnicas y herramientas 12.1.1.1 Base histórica de proyectos (Historical records)
Descrito en la sección 6.4.1.5
422
12.1.1.2 Análisis "comprar o hacer" (Make or buy analysis) Cuando una organización decide comprar un producto o contratar un servicio de una empresa externa, está tomando la decisión de no producir dichos productos o servicios a través de sus propios medios. En algunos casos, resulta una decisión difícil, sobre todo porque son muchas las variables que pueden determinar la mejor decisión. Normalmente, el principal criterio utilizado en la decisión de comprar o hacer es el financiero. No obstante, el análisis financiero no es suficiente para determinar qué es lo más viable, ya que, en algunos casos la empresa que ofrece el mejor coste, muchas veces no ofrece el mejor servicio. La organización, tiene que analizar otras variables importantes, como por ejemplo:
·
Coste: Es solamente uno de los factores a considerar. La organización debe tener en cuenta los costes directos (el precio de la oferta entregada por el proveedor) y los indirectos (las horas de los que coordinarán y controlarán el trabajo desarrollado por el proveedor dentro de la organización y las horas dedicadas a la administración del contrato).
·
Capacidad de recursos y materiales: ¿Cómo está la capacidad de producción de los recursos internos? Si no están al 100%, ¿Compensa agregarles otro trabajo? ¿La prioridad de este trabajo en la organización permite ocupar el 100% del tiempo de los recursos internos?
·
Incremento de la plantilla: Si la decisión de la empresa implica la contratación de más recursos, ¿está la empresa preparada para hacerlo? ¿Los costes derivados de la contratación de personal compensan los beneficios obtenidos por el proyecto?
·
Propiedad intelectual: La contratación de un proveedor puede significar en muchos casos darle acceso a informaciones internas de la organización, muchas veces confidenciales que pueden constituir en una ventaja competitiva frente a otras empresas. En muchas organizaciones, no revelar su conocimiento a terceros externos es un factor mucho más relevante que asumir los costes y los plazos de desarrollar un producto internamente.
La cuestión “hacer versus comprar” es una de las decisiones más difíciles y, a la vez, más importantes en el proyecto, la figura 164 nos presenta las razones que nos pueden llevar a tomar una u otra decisión:
423
Figura 190: Hacer versus comprar
Una de las razones que más relevantes que llevan a las empresas a tomar la decisión de comprar es su falta de experiencia en producir el producto y/o el servicio deseado. Intentar desarrollarlo internamente podrá provocar una perdida importante de tiempo y un incremento desnecesario de costes. Además, es muy probable que la empresa no logre alcanzar el mismo nivel de calidad de los productos ofertados por empresas externas con más experiencia. La organización debe por lo tanto, enfocarse en lo que mejor hace y dejar lo demás a empresas externas especializadas. Por otro lado, el hacer implica poseer la propiedad intelectual y los derechos de propiedad del producto, lo que, indudablemente, constituye una importante ventaja competitiva frente a la competencia.
12.1.1.3 Análisis del árbol de decisiones (Decision tree analysis) Descrito en la sección 11.4.1.5
12.1.1.4 Juicio de expertos (Expert judgement) Descrito en la sección 4.1.1.1
12.1.2 Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) 424
I DOC nº 024 – Plan de gestión de las adquisiciones (Procurement management)
425
I
DOC nº 029 – Enunciado del trabajo (Procurement statements of work)
I
Decisiones de hacer o comprar. Véase sección 12.1.1.2. (Make or buy decisions)
I
DOCs nº 030 al 037 – Documentos de la adquisición (Procurement documents)
I
DOC nº 038 – Criterios de selección de proveedores (Source selection criteria) DOC nº 039 – Solicitudes de cam bio (Change requests)
12.2 Conducción de compras (Proceso que corresponde a la fase de ejecución del proyecto) Este proceso consiste en desarrollar todo el ciclo de compras: Preparar las solicitudes, obtener respuestas de los vendedores, seleccionar un vendedor y adjudicar un contrato. Se deberá aplicar unos criterios de selección definidos previamente a fin de seleccionar los proveedores adecuados para el objeto que se va a desarrollar.
12.2.1 Ciclo de compras 12.2.1.1 Preparación y solicitud de propuestas Es el proceso que consiste en preparar la documentación necesaria para el proceso de solicitud de propuestas. La contratación de los proveedores de los proyectos se realiza normalmente a través del departamento de compras de la empresa, a pedido del Project Manager. En algunos casos, la contratación es hecha directamente por el propio Project Manager, sin intermediarios. El proceso de selección de los proveedores consiste básicamente en solicitar propuestas a los potenciales proveedores y analizarlas. Hay casos en que la empresa contratante prefiere trabajar con un determinado proveedor, sobre todo por los buenos servicios prestados en proyectos anteriores. De hecho, muchas empresas tienen una cartera de proveedores fijos que son convocados siempre que hay la necesidad de contratar sus servicios. No obstante, no es común, ni siquiera recomendable, solicitar un presupuesto a una única empresa. Normalmente, se solicitan por lo menos tres presupuestos de diferentes proveedores para de esta forma, poder realizar una valoración más amplia y acceder a la mejor oferta. El ciclo completo de solicitud de propuestas está ampliamente detallado en el Apéndice A, que contempla el siguiente proceso:
426
I
DOC nº 030 – Solicitud de información (Request for information – RFI) I DOC nº 031 – Solicitud de cotización (Request for quotation – RFQ)
I
DOC nº 032 – Solicitud de propuesta (Request for proposal – RFP)
I
DOC nº 033 – Invitación a negociar (Invitation for negotiation IFN)
Figura 191: Ciclo del proceso de compras
12.2.1.2 Preselección de los proveedores La preselección de proveedores es una fase muy importante en el proceso de contratación, teniendo en cuenta, de que la empresa ganadora, saldrá de este listado, y por ello, es importante realizar una preselección utilizando unos criterios que nos puedan asegurar una elección correcta. La forma más correcta de hacerlo, es manteniendo un registro de las empresas con las que ha trabajado en proyectos anteriores y que son preferidas a las demás, por criterios objetivos, como por ejemplo:
· · · · ·
Capacidad financiera. Estructura. Disponibilidad de recursos. Evidencias de calidad. Comportamiento y experiencia en proyectos anteriores.
Se pueden incluso añadir otros criterios para refinar mejor los resultados. Estos criterios son libres y
427
deberán ser utilizados solo los más apropiados en cada organización o en cada proyecto, dependiendo de su naturaleza.
428
12.2.1.3 Tipos de respuesta Se puede responder a una petición, utilizando un documento especifico de respuesta. Los proveedores interesados en ofrecer sus servicios a un determinado proyecto podrán responder utilizando el documento apropiado, que pueden ser:
·
CIR - Contractor initial response: Es la respuesta inicial del contratista que dará lugar a las negociaciones posteriores.
·
Propuesta económica: Es la respuesta a la solicitud de cotización (véase también doc nº 031).
·
Propuesta económica y de ejecución: Es la respuesta a la solicitud de propuesta (véase tam bién doc nº 032).
·
Respuesta punto por punto: Es la respuesta detallada a todos los puntos recogidos en las especificaciones del cliente.
12.2.1.4 Licitaciones o convocatorias Existen organizaciones que hacen una especie de licitación, en que el proveedor será elegido en función de puntuaciones establecidas por la empresa contratante, como el ejemplo a continuación: La empresa Alfa PC necesita implantar en sus oficinas un sistema de telefonía más moderno. Como no disponían de referencias de ningún proveedor especifico, decidieron hacer una convocatoria que será estructurada bajo el siguiente reglamento:
·
Solicitud y Recepción de Propuestas: La empresa Alfa PC solicitará a los proveedores interesados una propuesta de implantación de un nuevo sistema de telefonía. Recibidas las propuestas, la empresa Alfa PC, asignará un equipo que se encargará de comprobar el cumplimiento de los requisitos exigidos y procederá a remitir a la Junta de Valoración únicamente las propuestas que cumplan exactamente con los requisitos establecidos. (Esta Junta de valoración puede ser compuesta por el Project Manager, un representante del departamento de compras y departamento financiero, el líder técnico o cualquier integrante del equipo que la empresa considere importante).
·
Valoración de Propuestas: En esta fase, la junta de valoración realizará un detallado análisis de las propuestas recibidas y decidirá cual es la propuesta que mejor atiende a la solicitud del servicio, a través de una puntuación numérica (que normalmente es de 1 a 5 puntos). La valoración de las propuestas se realiza teniendo solo en cuenta la propuesta técnico-económica aportada y la documentación técnica solicitada. Para que la valoración sea la más neutral posible y no favorezca una determinada empresa, las propuestas no contendrán identificación ni referencia alguna a la empresa, a los efectos de realizar una valoración ciega.
·
Elección de la empresa adjudicada: La empresa que obtenga la mayor puntuación será la elegida para que manifieste por escrito su aceptación de la propuesta provisional
429
de adjudicación y para que presente la documentación acreditativa.
430
Una vez comprobada por la Junta de Valoración la conformidad de la documentación presentada, se procederá a la formalización de la relación contractual mediante la firma de un contrato entre Alpha PC y la empresa adjudicataria. A los restantes participantes se les comunicará su no adjudicación formalmente por escrito.
12.2.1.5 Criterios de valoración Según lo explicado anteriormente, cuando se solicita una propuesta para la adjudicación y contratación de una empresa para la ejecución de un determinado servicio, se establece una puntuación que definirá el eventual ganador de la licitación. Los criterios de valoración normalmente son los siguientes:
·
Cumplimiento con los requisitos establecidos: Las propuestas enviadas deberán explicar de forma detallada, como se ejecutará el servicio solicitado, especificando, cuando necesario, el tipo de componentes, equipos o procedimientos que serán utilizados.
·
Experiencia acreditada en el servicio contratado: Las empresas participantes han de acreditar esta experiencia facilitando un listado de empresas a las que le han realizado este servicio. Se valorará el número de empresas aportadas con un máximo de puntos.
·
Certificaciones de calidad general de la empresa: Se valorará que las empresas presentadas posean certificados generales de calidad (ISO 9000, ISO27001, ISO14000, etc.). La acreditación de estar en posección y vigencia de alguna de las certificaciones garantiza la obtención de la máxima puntuación. El no poseer alguno de estos certificados implicará la no obtención de puntuación en este criterio.
·
Propuesta económica ajustada al cumplimiento de los pliegos de prescripciones técnicas: Se otorgará la máxima puntuación a las ofertas que ofrezcan las mejores condiciones económicas.
La tabla que viene a continuación ilustra un ejemplo de de valoración y puntuación de las empresas participantes: PROVEED PROVEED PROVEEDO REQUISITOS P* OR 1 OR 2 R3 Capacidad financiera 10 4 3 3 Infraestructura
5
3
2
2
Disponibilidad de recursos
10
3
2
5
10
3
3
2
195
150
210
Experiencia RESULTADO
P* = ponderación (Escala de valores de 1 a 5) Figura 192: Tabla de criterios de valoración
431
Normalmente, el proceso de decisión de adjudicación de un contrato puede ser complementado con otras evaluaciones, como por ejemplo, auditorias de procesos de calidad y/o comprobación de los medios físicos y humanos para cumplir con los requisitos del proyecto.
12.2.1.6 Adjudicación del contrato Una vez tomada la decisión de adjudicación del contrato (punto anterior), se comunica formalmente a la empresa adjudicataria y se convoca una reunión para la confección del contrato de prestación de servicios.
12.2.1.7 Confección del contrato Un contrato (doc nº 034) es un acuerdo legal que declara las partes implicadas, su objeto y las cláusulas que especificarán los derechos y deberes de cada involucrado. Un Project Manager suele prestar más atención en el alcance del proyecto descrito en el contrato, sus plazos y costes asociados. No obstante, es importante que se observe también los aspectos legales, sobre todo en lo que se refiere a la propiedad de los servicios y productos desarrollados. Un contrato debe contener como mínimo cinco elementos:
·
Oferta: El contrato debe contemplar una oferta en que la empresa contratante conoce el precio y las características del servicio ofertado.
·
Consideración: El contratante y el contratado consideran justo el intercambio. La contratante recibe los servicios y la otra el importe acordado.
·
Capacidad: Las partes involucradas debe ser capaces de contratar. La empresa contratada es capaz de proveer el servicio contratado y la empresa contratante tiene la capacidad de pagar por el servicio realizado.
·
Aceptación: La empresa contratante debe aceptar el precio y las condiciones ofrecidas en el contrato.
·
Legalidad: Ambas partes involucradas deben recoger y pagar los tributos correspondientes.
Los contratos pueden asumir muchas formas distintas, sin embargo en el ámbito del Project Management los contratos más comunes son los siguientes:
·
Contrato de precio fijo (Fixed-price): Descrito en el doc nº 035, Apéndice A. Este contrato puede tener las siguientes variaciones:
·
Precio fijo o suma global (Fixed-price or lump-sum- FP): Descrito en el doc nº 035.
432
·
Precio fijo más honorarios con incentivos (Fixed price with incentives - FPI): Descrito en el doc nº 035.
433
• Precio fijo con ajuste económico (Fixed price with economic price adjustment FPEA): Descrito en el doc nº 035.
·
Precio fijo redeterminable (Fixed price redeterminable - FPR): Descrito en el doc nº 035.
·
Contrato de precio variable (Cost-reimbursable): Descrito en el doc nº 036, Apéndice A. Este contrato puede tener las siguientes variaciones:
·
Coste más cuota fija (Cost plus fixed fee - CPFF): Descrito en el doc nº 036.
·
Coste más incentivo (Cost plus incentive fee - CPIF): Descrito en el doc nº 036.
·
Coste más cuota premio (Cost plus award fee - CPAF): Descrito en el doc nº 036.
·
Coste más porcentaje del coste (Cost plus percentage of cost - CPPC): Descrito en el doc nº 036.
·
Contrato a tiempo y material (Time & material contract): Es un tipo de contrato que no tiene un final claramente definido, porque el valor total del contrato no se define en el momento de su adjudicación. Véase también doc nº 037.
·
Garantías: Aunque la organización cuente con un proceso rígido de selección de proveedores y con un departamento jurídico capaz de confeccionar contratos muy completos, aún existe el riesgo de que el proveedor no entregue el servicio contratado según lo especificado, sea por algún problema ajeno, por incapacidad o por mala fe. Para mitigar este riesgo, todo contrato debe contener una cláusula de garantía.
12.2.2. Documentación generada en este proceso I
DOC nº 030 – Solicitud de información (Request for information – RFI)
I
DOC nº 031 – Solicitud de cotización (Request for quotation – RFQ)
I
DOC nº 032 – Solicitud de propuesta (Request for proposal – RFP)
I
DOC nº 033 – Invitación a negociar (Invitation for negotiation IFN)
I
Calendario de recursos. Véase sección 9.4.1.7 (Resource calendars)
434
I
DOC nº 039 – Solicitud de cam bios (Change requests)
435
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates)
I
DOC nº 056 – Actualizaciones a los documentos del proyecto (Project document updates)
12.3 Ad ministración del contrato
(Proceso que corresponde a la fase de control del proyecto) El proceso de administración del contrato comprende el periodo establecido desde la firma del este hasta su extinción. En este proceso, el Project Manager buscará asegurar que las partes cumplan lo estipulado en el contrato. Este proceso podrá incluir:
· · · · · · · · ·
Supervisar la correcta y adecuada ejecución del plan de proyecto. Asegurar el cumplimiento de los cronogramas. Evaluar el desempeño de la empresa contratada. Aceptar y pagar de facturas. Asegurar y controlar de la calidad. Poner en marcha acciones preventivas y correctoras. Supervisar las condiciones financieras del contrato. Aplicar las penalizaciones acordadas. Controlar los cambios del proyecto.
Durante prácticamente todo el tiempo de administración del contrato, el Project Manager tendrá un enfoque más concentrado en la gestión de cambios del proyecto, puesto que, en cualquier contrato, los cambios son inevitables. Conforme el proyecto avance, podrán ocurrir incidencias o surgir presiones que forzarán alguna de las partes involucradas a cambiar algún aspecto que figure en el contrato, que puede ser de orden técnica, administrativa y/o jurídica. Independientemente del motivo, un cambio en una condición o cláusula contractual normalmente provocará también un cambio en el coste o plazo del proyecto, o incluso en el alcance del proyecto. Son circunstancias muy difíciles de prever y prevenir. No obstante, es posible administrar los cambios de forma en que se minimicen los impactos producidos por ellos, ejecutando las siguientes acciones:
·
Verificar detenidamente las cláusulas contractuales que sufrirán cambios.
·
Analizar detalladamente que aspectos del proyecto serán directamente afectados.
·
Determinar las consecuencias de los cambios en los resultados del proyecto, sobre todo en sus plazos, costes, disponibilidad de recursos.
436
12.3.1 Técnicas y herramientas 12.3.1.1 Sistema de control de cambios del contrato (Contract change control system)
Descrito en la sección 4.5.1.1
12.3.1.2 Revisiones e informes de desempeño (Procurement performance reviews and reports) Los informes de desempeño proporcionan a la dirección información sobre la efectividad del vendedor en el logro de los objetivos contractuales. Para monitorizar el desarrollo, tanto a nivel interno como externo, de los requisitos e indicadores del proyecto una buena metodología es el uso de indicadores claves de rendimiento (key performance indicators – KPI). Los KPI proporcionan un cálculo muy certero del estado del proyecto. Los indicadores claves de rendimiento son una métrica de alto nivel de la efectividad y/o eficiencia que se usan como guía y control progresivo del rendimiento.
12.3.1.3 Inspecciones y auditorías (Inspection and audits) Cuando una organización elige contratar una empresa externa para desarrollar un producto y/o servicio, tendrá que tener en cuenta que no todo el proceso estará totalmente bajo su control. Para compensar esta debilidad, se realizan inspecciones y auditorías durante la ejecución del proyecto para comprobar, así, si el proveedor cumple con los requisitos establecidos. Para evitar conflictos entre la empresa contratante y la contratada, es fundamental que las inspecciones y auditorías estén contempladas en el contrato, previendo posibles consecuencias en la detección de eventuales incumplimientos o, incluso, fraudes. Esta supervisión se realiza a lo largo de todo el proyecto y proporciona al equipo de dirección del proyecto una idea sobre el estado del proyecto e identifica cualquier área que necesite más atención. El proceso completo de auditoría se encuentra ampliamente detallado en la sección 8.2.
12.3.1.4 Sistemas de pago (Payment systems) Un sistema de pago contempla la puesta en marcha de un procedimiento controlado, que, entre otras cosas, deberá incluir la adopción de determinados criterios de aceptación para autorizar el pago al proveedor. Es decir, los pagos son procesados después de que una persona autorizada
437
certifique que el trabajo es satisfactorio. Todos los pagos deben ser efectuados y documentados en estricto cumplimiento de los términos del contrato.
438
La administración del contrato también tiene un componente de gestión financiera que involucra el seguimiento de los pagos. Esto asegura que los plazos de pago definidos dentro del contrato se cumplan y que la compensación del proveedor se corresponda con sus avances, según lo establecido en el contrato. Los pagos son algo muy relacionado con la aceptación del proyecto o alguna de sus fases. Es un factor crítico para ambas partes, es por ello que debe hacerse un buen seguimiento de las facturas, el proceso de pago y los resultados. Nadie debe eludir sus responsabilidades en este aspecto.
12.3.1.5 Administración de reclamaciones (Claims administration) Aparte de las solicitudes de cambio aprobadas, también existen los cambios impugnados y los constructivos. Los cambios impugnados (reclamaciones, conflictos, apelaciones) son aquellos cambios solicitados respecto de los cuales el adquiridor y el proveedor no consiguen acordar la compensación correspondiente debido a los mismos. Las reclamaciones se documentan, se procesan, se supervisan y se gestiónan a lo largo del ciclo de vida del contrato, en general, de acuerdo con los términos del contrato Si las partes no resuelven por sí mismas una reclamación, puede ser necesario gestionarla de acuerdo con los procedimientos de resolución alternativa de conflictos establecidos en el contrato. El acuerdo de todas las reclamaciones y conflictos mediante la negociación es el método más adecuado.
12.3.1.6 Sistema de gestión de registros (Record management system RMS) El RMS es un sistema de gestión de registros que es utilizado por el Project Manager para la gestión y correcta documentación y registro de los contratos del proyecto. Incluye un conjunto específico de procesos, funciones de control relacionadas y herramientas de automatización que deberán consolidarse y combinarse en un todo, como parte del sistema de información del proyecto.
439
12.3.2. Documentación generada en este proceso I
Actualizaciones a los activos de los procesos de la organización (las que correspondan) (Organizational process assets updates)
I
DOC nº 039 – Solicitud de cam bios (Change requests)
I
DOC nº 055 – Actualizaciones al plan de gestión del proyecto (Project management plan updates)
I
DOCs nº 030 al 038 – Documentos de la adquisición (Procurement documents)
12.4 Cierre del contrato
(Proceso que corresponde a la fase de cierre del proyecto) El cierre del contrato es una gestión administrativa que contempla verificar si todo el trabajo realizado y todos los productos entregados han sido aceptados formalmente. Incluye, además, la actualización de todos los registros para reflejar los resultados consolidados y el archivo con toda la documentación para su uso en el futuro. El proceso de cierre contiene tareas tales como las presentadas a continuación:
·
Cierre administrativo: Describe detalladamente todas las actividades, interacciones, roles y responsabilidades relacionadas con el equipo del proyecto y todos los interesados en la ejecución de esta gestión.
·
Verificación del alcance: Esta gestión pretende obtener la aceptación formal por parte de los interesados del alcance realizado y los entregables correspondientes. Esta gestión incluye, además, la revisión de los entregables para asegurarse de que cada uno de ellos ha sido completado correctamente.
·
Obligaciones posteriores: Antes de finalizar el contrato, es aconsejable revisarlo, para señalar aquellas áreas en las que alguna de las partes debe mantener unas responsabilidades posteriores, como, por ejemplo: o Licencias. o Propiedad intelectual. o Mantenimiento. o Garantía. o Actualizaciones. o Nuevas versiones.
440
Una vez completados los trabajos previstos, empiezan las gestiones formales de cierre del contrato. En esta fase, se realiza la verificación final del producto o servicio desarrollado. Para asegurar que el contrato ha sido correctamente cumplido, es necesario realizar un chequeo general que contemplará lo siguiente:
·
Documentación: Esta documentación incluye informes, actas, manuales o cualquier otro registro que las partes involucradas consideren importante.
·
Estado financiero: Es fundamental comprobar si el contrato tiene alguna deuda o pagos pendientes de realizar o cobrar.
·
Verificaciones: El cliente realizará una especie de auditoria, y en caso necesario, en conjunto con un auditor independiente capacitado para certificar que el producto o servicio atiende a los requisitos establecidos contractualmente.
·
Archivo: Toda la documentación generada en el proyecto deberá ser reunida, organizada y archivada para eventuales consultas.
·
Aceptación formal: La empresa proveedora debe desarrollar un documento de aceptación formal para que el cliente lo firme y, con ello, formalice la aceptación de todos los servicios o productos entregados. Los requisitos de aceptación del cliente, normalmente son establecidos en el contrato. Las instrucciones de cómo confeccionar un documento de aceptación formal se encuentran en el doc nº 050
En algunos tipos de servicios la documentación es, normalmente, la última entrega realizada por el proveedor (suele ocurrir frecuentemente cuando se trata de desarrollo de software). La aceptación final formalizada y los pagos correspondientes estarán normalmente vinculados a esta entrega.
12.4.1 Técnicas y herramientas 12.4.1.1 Auditorías de la adquisición (Procurement audits) Una auditoría de la adquisición es una revisión que realiza al proceso de adquisición, incluyendo su planificación y administración. Su objetivo es identificar éxitos o fracasos que merecen ser reconocidos para la preparación y gestión de contratos futuros.
12.4.1.2 Acuerdos negociados (Negotiated settlements) En toda relación de adquisición, el acuerdo definitivo y equitativo de todos los asuntos, reclamaciones y controversias pendientes a través de la negociación es un objetivo fundamental. En los casos en que no es factible llegar a un acuerdo mediante la negociación directa, puede
441
examinarse el empleo de algún método alternativo para la resolución de conflictos, incluyendo la mediación o el arbitraje. Cuando todo recurso falla, iniciar un litigio en los tribunales es la opción menos deseable.
442
12.4.1.3 Sistema de gestión de registros (Records management system) Descrito en la sección 12.3.1.6
12.4.2. Documentación generada en este proceso (Véase Apéndice A – Documentos del proyecto) I
DOC nº 052 – Acta de cierre del proyecto (Closed procurements)
I
Actualizaciones a los activos de los procesos de la organización (las que correspondan) (Organizational process assets updates)
443
Capítulo 13 Gestión de con flictos "Al menos, una vez en la vida conviene poner todo en discusión" René Descartes68, filósofo, científico y matemático francés
445
Algunas cosas en las que NO puedes pensar acerca de la gestión de conflictos “Son adultos, que se entiendan ellos solos” Las personas en las que predomina el estilo de evitar un conflicto, esquivar, posponer o, inclusive, ignorarlo, por lo general, son personas que temen las consecuencias de enfrentarse a una situación complicada, o no se sienten preparadas para abordarla, y por ello, consideran que una situación de conflicto debe ser resuelta por otras personas con más capacidades. El único escenario recomendable para evitar un conflicto es cuando sus consecuencias no son significativas, el coste de la confrontación puede ser superior a lo que se podría obtener al enfrentarlo o cuando no tenemos toda la información sobre el problema. “Si no haces nada, el problema se arreglará solo” No hacer nada es simplemente ser negligente, lo que es, sin lugar a dudas, una de las peores posturas que se pueden esperar de un Project Manager. Cuando un profesional es negligente significa que ha fracasado en el momento de ejecutar sus habilidades a la hora de tratar un problema, infravalorando sus consecuencias. En este capítulo se demostrará que cualquier conflicto necesita una resolución, que puede ser más o menos complicada de superar, pero que exigirá siempre una resolución. No hacer nada, simplemente, empeorará las cosas. “No hay negociación, soy el jefe y la última palabra es la mía, por supuesto” Este tipo de pensamiento se resume simplemente en hacer uso de su autoridad para resolver los problemas a su manera, muchas veces sin consultar las partes involucradas. Es una postura que puede resolver un problema a corto plazo, pero su solución no suele sostenenerse a largo plazo.
Introducción Uno de los objetivos que un Project Manager debe proponerse es lograr evitar disputas o las posibles incidencias que generen conflictos. De acuerdo con la Wikipedia (www.wikipedia.org), un conflicto “hace referencia a una situación difícil, que conlleva un enfrentamiento de intereses y valores considerados importantes”. Un proyecto es un emprendimiento que suele involucrar un número importante de personas con diferentes personalidades, opiniones y expectativas. Es fácil, por lo tanto, deducir que un proyecto puede ser una fuente propicia para el surgimiento de varios conflictos, sean de índole técnica, organizacional o financiera. A pesar de contener una cierta connotación negativa, la palabra “conflicto” también puede ser una oportunidad importante para estudiar nuevas alternativas, desarrollar mejores soluciones y, sobre todo, mejorar la formación del equipo. Los conflictos son situaciones que ocurren de forma muy frecuente en un proyecto y normalmente provienen de la relación que las personas de un mismo grupo mantienen por un determinado periodo de tiempo. Es importante que el Project Manager sepa reconocer rápidamente una situación de conflicto y que utilice la forma más eficaz de resolver su origen. Todos los conflictos, aunque sean pequeños, pueden tener un potencial para hacer un gran daño al proyecto, sobre todo en lo que se refiere a la motivación y la unión del grupo, factores muy sensibles y que suelen ser bastante inestables.
446
El Project Manager, durante el desarrollo del proyecto, tiene que lidiar con diferentes grupos de personas: directores, clientes, ingenieros, administrativos, patrocinadores, entre otros. Estos grupos, normalmente, tienen intereses distintos que, por lo general, podrán convertirse en conflictos. Es importante que exista una figura neutral que pueda lidiar con todos estos grupos, y esta figura es el Project Manager y la forma en que él se relacionará con estos grupos tendrá relación directa con el éxito del proyecto. Para poder ejercer un cierto liderazgo y tener influencia sobre grupos tan heterogéneos, el Project Manager necesita gozar de algún tipo de poder y/o autoridad para lograr la cooperación necesaria entre todos los involucrados. Este poder puede venir formalmente a través del acta de constitución del proyecto (Project charter, véase también doc nº 001), o a través de promociones en la organización que le acredita la autoridad necesaria. Sin embargo, estos factores, que son muy formales, no necesariamente pueden ayudarle a obtener el poder de influencia adecuado. Existen otras formas más eficaces de lograr respecto e influencia, como, por ejemplo, sus amplios conocimientos sobre el proyecto que será desarrollado o a través de su carisma hacia las personas con quienes interaccionará.
13.1 Las siete fuentes de conflicto en proyectos De acuerdo con el PMI, son siete las fuentes de conflicto más comunes en los proyectos:
·
Prioridades del proyecto: Cada integrante del proyecto suele tener sus prioridades, que le afectan directamente y son causas constantes de conflictos con otros integrantes e incluso con el Project Manager.
·
Procedimientos administrativos: La forma en que un proyecto es gestionado, la burocracia o la necesidad de seguir procedimientos para cumplir con una normativa que obliga a los integrantes del equipo a dedicar más tiempo en una determinada tarea.
·
Cuestiones técnicas: Pueden ocurrir desacuerdos sobre la tecnología elegida para el desarrollo de un producto o acerca de las especificaciones técnicas determinadas.
·
Recursos: En algunas organizaciones, sobre todo las funcionales, el Project Manager puede afrontar dificultad en disponer del personal adecuado en el momento necesario.
·
Costes y plazos: Estimaciones equivocadas pueden generar problemas en el momento de poner en marcha una actividad del proyecto.
·
Conflictos de personalidad: Es muy frecuente que ocurran enfrentamientos entre personas de distintas personalidades.
13.2 Técnicas de resolución de conflictos Los conflictos deben ser resueltos por aquellos que están directamente involucrados en ellos. El Project Manager suele ser la figura central de la resolución de un conflicto, puesto que dispone de autoridad para ello. En casos muy extremos, la gerencia se solicita para intervenir. Existen muchas técnicas para la resolución de conflictos, aunque la técnica utilizada dependerá mucho más del
447
carácter del Project Manager que del conflicto en sí mismo.
Existen, incluso, algunos conflictos que deben ser considerados como parte del proceso de gestión de compras y contratos. Las organizaciones involucradas en el proyecto deben establecer unas pautas de resolución de eventuales disputas e incluirlas como cláusulas contractuales. Es importante tener en cuenta que un conflicto no resuelto puede ser una importante fuente de retrasos en el proyecto e incremento de costes.
13.2.1 Alternativa de resolución de disputas (Alternative dispute resolution – ADR) Cuando el Project Manager se encuentra ante un conflicto o disputa entre partes diferentes, normalmente involucrando a la empresa, el cliente y el proveedor, a raíz de retrasos en entregas, pagos y/o incumplimiento de algún acuerdo contractual, se podrá hacer uso de la “alternativa de resolución de disputas - ADR”. Este método básicamente involucra a un mediador que intentará resolver el conflicto sin tener que llevárselo a un proceso judicial. Usado adecuadamente, la ADR reduce el número de disputas que pueden terminar en costosas y largas batallas legales. La ADR es una metodología de resolución de conflictos tan importante que en algunos países los tribunales de justicia suelen recomendar a las partes envueltas en determinados casos que busquen una mediación antes de presentarse a un juez.
Ventajas de la ADR: · · · · · ·
Los conflictos son resueltos con más rapidez. La mediación intentará buscar una situación donde todos ganan. Es un procedimiento informal y sencillo. Es confidencial. Es menos costoso. Se evitan largas y costosas batallas legales.
Su desarrollo empieza con la recopilación, por parte del mediador, de toda la información útil sobre la disputa para que se pueda elaborar la estrategia adecuada de mediación. A continuación, se desarrolla el proceso de mediación, donde cada parte explica su versión de los hechos, su punto de vista y lo que cree necesario para resolver el conflicto. Tras la recopilación de toda la información acerca de la disputa, y después de haber hablado con las partes involucradas y conocido sus puntos de vista, el mediador finalmente elegirá una de las siguientes estrategias de resolución:
·
Evitación (withdrawing): La postura pasiva del mediador generalmente tiene como objetivo intentar ganar tiempo o enfriar la situación, para que se pueda pensar en una solución que sea por lo menos temporal y que pueda minimizar conflictos. Es una estrategia que normalmente no resuelve el problema.
·
Agresividad (confronting, problema solving): Un mediador agresivo tenderá a
448
buscar una forma rápida y eficaz en acabar con cualquier fuente de conflicto. Normalmente, se convoca a las partes involucradas para objetivamente resolver cualquier punto de discordia.
449
•
Conciliación (conciliation): El mediador puede convocar las partes y facilitar el reinicio del dialogo, pudiendo, incluso, hacer sugerencias de eventuales alternativas de solución. Estas sugerencias podrán ser aceptadas o rechazadas por las partes que están en conflicto.
·
Negociación (compromising): Es una de las posturas más adecuadas, independientemente del grado de conflicto. Las partes involucradas se reúnen buscando encontrar un punto de equilibro que busque satisfacer a ambos lados. Esta forma de actuar normalmente resulta en resultados satisfactorios y definitivos.
Cuando la mediación es concluida de manera satisfactoria para ambas partes, el acuerdo debe ser formalizado por escrito. Las partes pueden utilizar el documento como un contrato vinculante si ellos necesitan tomar una acción más formal. El mediador puede ser cualquier persona que tenga alguna relación directa o indirecta en el proyecto. La persona adecuada dependerá básicamente del tipo de conflicto y de las partes interesadas en su resolución. Su asignación puede ser determinada por el Project Manager, por el líder técnico o por cualquier persona cuyas partes consideren adecuada para la mediación de su problema.
13.3 Diez principios para la resolución de conflictos La Guía práctica de gestión de contratos, emitida por el Instituto Nacional de Tecnología de la Comunicación (INTECO), trae una interesante lista de principios para la resolución de conflictos, cuyo contenido se facilita a continuación:
·
Los conflictos son una combinación de relaciones personales, procesos e ideas: A la hora de analizar la situación, no debe olvidarse el componente humano y el proceso de colaboración entre organizaciones como potencial fuente de disputas.
·
Para poder encontrar una solución, en primer lugar, hay que entender el problema: Conviene hablar con todas las partes involucradas en el conflicto, así como al personal cualificado en el proceso, aunque no directamente implicado en la disputa, con el objetivo de entenderla claramente como primer paso hacia su resolución.
·
Se debe diseñar y seguir cuidadosamente una estrategia: A veces, la presión es mucha y se exige encontrar una solución rápida al problema. Incluso en estos casos conviene definir una secuencia de pasos que se deben seguir para resolver la situación.
·
Es necesario desarrollar buenas relaciones entre las empresas participantes en el proyecto: Toda la documentación relacionada con el conflicto y su resolución debe ser correctamente gestionada de forma que exista una cooperación entre ambas empresas para el intercambio de información y acuerdos.
·
Las negociaciones en la resolución de los conflictos comienzan definiendo el problema: Los participantes en la resolución deben determinar el problema.
450
•
Los participantes en el procedimiento de gestión de conflictos deben colaborar tanto en el diseño del procedimiento como en la definición de la solución: Todos los participantes en el proyecto deben estar involucrados de forma continua en la búsqueda de soluciones y acuerdos.
·
Las soluciones encontradas deben estar basadas en nuestros intereses, no en las circunstancias: Para poder llegar a un acuerdo, conviene intentar comprender el posicionamiento tomado por la otra parte.
·
El procedimiento de gestión de conflictos debe de ser flexible: El plan inicial puede servirnos como guía siendo posible adaptarlo según sea requerido por las circunstancias y los participantes.
·
Conviene anticiparse a los problemas que puedan aparecer en la negociación.
·
El objetivo es trabajar para solucionar los desacuerdos, no crear otros nuevos.
451
Capítulo 14 Las organizaciones "Donde hay una empresa de éxito, alguien tomó alguna vez una decisión valiente” Peter Drucker43, escritor y consultor de empresas austriaco
452
Introducción El diccionario de la Real Academia Española define “organización” como “acción y efecto de organizar u organizarse”. El acto de organizar una entidad consiste en atribuir a ella una estructura y establecer funciones a sus departamentos para que puedan cumplir sus misiones y objetivos. Ya el verbo “organizar” consiste en “establecer o reformar algo para lograr un fin, coordinando las personas y los medios adecuados”. Por otro lado, “administrar” comprende las tareas de planificar, decidir e implantar las acciones necesarias para lograr sus objetivos. Desde el comienzo de la administración moderna, a principios del siglo XIX, el concepto de “organización” era muy sencillo. Las empresas eran estructuradas a partir del modelo funcional. La diferencia se basaba en su administración: funcional centralizada o funcional descentralizada. A partir de la década de los 50, las organizaciones empezaron a estructurase de una forma menos conservadora y, en poco tiempo, empezaron a surgir las empresas proyectizadas y matriciales. Desde los años 80, y sobre todo desde el surgimiento de internet, las empresas fueron volviéndose menos rígidas, adaptándose al su sector de actuación y sobre todo sobre su forma de trabajo. Actualmente, se pueden encontrar organizaciones que encajarán de alguna forma de uno de estos tipos o podrán, incluso, ser una combinación de las tres. No importa cuál es el tipo de organización, todas tendrán sus ventajas y sus desventajas. Lo más importante es invertir en la comunicación e interacción interna entre personal y departamentos. De esta forma, se disminuyen los conflictos internos y se incrementa la optimización de los recursos.
14.1 Tipos de organizaciones Existen básicamente, tres tipos de organizaciones:
· · ·
Funcional. Proyectizada. Matricial.
14.1.1 La organización funcional La organización funcional es la más antigua de las tres. Es un tipo de organización tradicional que básicamente divide el trabajo por categorías, especializaciones o funciones, donde la autoridad es distribuida en niveles jerárquicos. Esta división de trabajo puede ser horizontal cuando se asignan partes específicas de los trabajos de la organización a los departamentos en que los recursos humanos y materiales de la organización son agrupados en funciones bien definidas. Estos departamentos pueden ser organizados de varias formas:
·
Por productos: como pueden ser los diferentes productos de un fabricante de hardware: división de impresoras, portátiles, ordenadores de sobremesa, PDA...
·
Por especialización: profesional: compras, contabilidad, recursos humanos, administración, calidad, jurídico...
453
Por tipo de cliente: pymes, grandes empresas, personas físicas... Por proceso: planificación, diseño, producción, ventas, soporte...
No es común que una organización funcional se involucre en proyectos. Sus actividades diarias son repetitivas y muy limitadas a cada departamento, que, normalmente, trabaja de forma independiente y, muchas veces, líneal, estando subordinadas a un gerente funcional. De esta forma, el departamento de compras se encarga de suministrar material al almacén, que atiene los pedidos de producción y que a su vez los entrega al departamento de ventas, que se lo comercializa al cliente final. Por otro lado, el departamento de contabilidad y el administrativo se encargan de las gestiones de todo este proceso. Una organización funcional es estructurada según ilustra la figura 192 que refleja la división de trabajo en que es basada.
Figura 193: Organización matricial
La estructura funcional no es el ambiente apropiado para el desarrollo de proyectos que necesiten la interacción entre departamentos. Esto ocurre porque cada trabajador se comunica directamente con su jefe directo, que pasará las informaciones al jefe del otro departamento, es decir, no hay una comunicación directa entre los equipos de distintos departamentos. Los departamentos de una estructura funcional son muy “cerrados” y su personal está muy acostumbrado a hacer solamente su trabajo. Esta falta de comunicación directa conllevará a eventuales retrasos en la toma de decisiones, generación de conflictos y podrá comprometer la integridad de las informaciones. En un último análisis, una estructura funcional no sería capaz de adaptarse a un ambiente interdepartamental, ya que no estaría preparada para ejecutar trabajos que no corresponden a su naturaleza funcional. Si eso llega a ocurrir, todas las decisiones estarían centralizadas al jefe general de los departamentos involucrados, que podrá ser, en muchos casos, la persona mejor preparada para tomar algunas decisiones importantes. Además, como se ha comentado anteriormente, el flujo de comunicación no tendría la fluidez adecuada, lo que conllevaría a retrasos de decisiones importantes. Una estructura funcional es demasiado rígida para ser aplicada a empresas que trabajan con proyectos, ya que sus recursos no pueden ser asignados íntegramente a un proyecto.
454
Normalmente, los proyectos tendrán la responsabilidad compartida entre los gerentes funcionales afectados, donde cada uno actuará y coordinará las actividades referentes a su departamento.
14.1.2 La oorganización proyectizada La organización proyectizada es experta en ejecutar proyectos. Es un tipo de estructura que consiste en organizar un equipo temporal y liderado por un Project Manager que estará exclusivamente dedicado al proyecto y tendrá amplia autoridad sobre su equipo, cuyos integrantes son desplazados de sus departamentos de origen temporalmente para poder trabajar en el proyecto. Una vez finalizado el proyecto, el equipo es disuelto y retorna a sus departamentos. Es un tipo de organización en el que los proyectos desarrollados están mejor integrados y la comunicación fluye de forma más natural. Por otro lado, a veces, un recurso puede quedarse ocioso, ya que tendrá que esperar a que las actividades antecedentes a la suya estén finalizadas para que él pueda actuar.
Figura 194: Organización proyectizada
14.1.3 La organización matricial Como la organización funcional y proyectizada demostraron tener limitaciones de cara al Project Management, es natural que un tipo de organización debiera surgir para atender plenamente esta necesidad. La organización matricial, que obtuvo mucho éxito en los años 70, puede ofrecer, de forma combinada, lo mejor de la organización funcional y proyectizada. Este tipo de organización mantiene las líneas verticales de la estructura funcional y, a la vez, establece una línea horizontal que será el eje del proyecto. Su diseño permite que los departamentos involucrados sean coordinados por sus gerentes funcionales que gestionarán sus recursos de modo que no se encuentren ociosos o sobrecargados. Sin embargo, no es una estructura perfecta. La organización matricial presenta fallos importantes, sobre todo en lo que se refiere a liderazgo y comunicación. Los integrantes de un equipo normalmente estarán subordinados a dos jefes: el gerente funcional y el Project Manager. Como cada uno tiene prioridades distintas, se podrán generar conflictos y ambigüedades.
455
De todas formas, es la estructura que mejor puede atender al Project Manager. Los gerentes funcionales son responsables en mantener su personal técnicamente cualificado para cumplir adecuadamente con las demandas del proyecto y proveerá toda la estructura necesaria para que su trabajo sea desarrollado sin percances. Al mismo tiempo, proveerá los estándares de Project Management, las mejores prácticas y fomentará el uso adecuado de documentación. Además, supervisará la evolución de las fases del proyecto, proporcionando informes en que se medirán los resultados obtenidos en cada fase.
Figura 195: Organización matricial
456
Capítulo 15 El Project Manager "No hay mayor peso para un ser humano que un gran potencial" Charles M. Schultz69, Historicista estadounidense, creador de Snoopy
458
Introducción Una de las contribuciones más importantes que el Project Management pudo aportar fue la institucionalización de la figura del Project Manager. A partir del momento en que las organizaciones empezaron a encargar la gestión de sus proyectos a una figura central que fuera capaz de administrar todas sus variables, los proyectos empezaron a contar con más posibilidades de éxito. Jack Guido70 y James P. Clements71, en su libro Administración Exitosa de Proyectos, afirman (muy acertadamente): “Son las personas – no los procedimientos ni las técnicas – las que son criticas para lograr el objetivo del proyecto. Los procedimientos y las técnicas son simplemente herramientas para ayudas a las personas a realizar sus trabajos”. Un proyecto debe tener una figura central que sea el responsable por su éxito y por su fracaso. Es una práctica bastante distinta de las llevadas a cabo por algunas organizaciones que ponen en marcha proyectos “sin dueño”, o “sin padre”, o con muchos dueños, cuyas responsabilidades no son claras y, a la hora de un posible éxito, todos quieren llevarse los méritos. Sin embargo, en el caso de un muy probable fracaso, será difícil que alguien se responsabilice. La responsabilidad final del Project Manager es asegurar la ejecución del proyecto dentro del plazo y de los costes estimados, garantizando la calidad de los servicios y productos entregados. Esto exige una administración eficaz de todas las disciplinas que hemos analizado en este libro: la comunicación, los recursos humanos, los contratos, el alcance, los riesgos, los costes, entre otros. Esta responsabilidad podrá variar en función de la complejidad del proyecto, del tipo de la organización que lo ejecuta, del interés del cliente, entre otros factores. Además de las responsabilidades inherentes del cargo, el Project Manager también deberá ser poseedor de grandes capacidades. El Project Manager, más que nada, actúa como un integrador. Su papel, entre otras cosas es el de resolver conflictos y prestar atención a lo que dicen los patrocinadores del proyecto. En el proyecto, será el responsable en la planificación, supervisión y control de los trabajos ejecutados.
15.1 El Project Manager, ¿nace o se hace? Como podremos ver a continuación, la profesión de Project Manager exige una cierta “vocación”, dada a la cantidad de talentos que el profesional debe poseer, como por ejemplo: liderazgo, capacidad de resolución de conflictos, capacidad de organización, planificación y en muchos de los casos, capacidad de actuar como un psicólogo. Por todo ello, la pregunta que proponemos, si un Project Manager nace o se hace, casi podemos decir que un poco de los dos. Un profesional que a lo largo de los años, acumule experiencia en proyectos y reciba una formación adecuada y completa, puede llegar a ser un excelente Project Manager. Sin embargo, existen algunas capacidades que la experiencia y la formación no pueden proporcionar. Si no se nace con ellas, la dificultad de asumir ciertas responsabilidades será, sin duda, mayor.
459
15.2 Las responsabilidades de un Project Manager El Project Manager es un puesto de indudable importancia en el ámbito del Project Management. No lo nombraría como el principal agente de un proyecto, ya que el grado de dependencia del Project Manager en relación al cliente, a su equipo y a los patrocinadores es muy alto. No obstante, no hay duda de que un proyecto necesita de una figura central que conduzca toda la evolución de un proyecto. Su responsabilidad en la organización recae en tres aspectos:
·
El proyecto: Es la responsabilidad más obvia de un Project Manager. Cuando asume un proyecto, se espera que el Project Manager reúna las condiciones necesarias para gestionar correctamente los costes, plazos, alcances y el equipo adjudicado.
·
La organización: El proyecto que será administrado por el Project Manager pretende proveer beneficios a la organización. Algunos proyectos tienen poca visibilidad y muchas veces, tienen un alcance tan sencillo, que en pocas semanas puede ser finalizado. Sin embargo, hay casos frecuentes de proyectos que generan una expectación muy grande, por su complejidad, por su importancia, pero sobre todo por las ganancias y oportunidades en el mercado que la empresa obtendrá con su desarrollo. Se espera que el Project Manager ejerza su actividad respectando la política de la empresa, los códigos profesionales de conducta y la ética (informando de forma honesta todos los resultados del proyecto, sean buenos o no).
·
El equipo: El Project Manager deberá suministrar toda la información necesaria para que el equipo puede desarrollar correctamente sus actividades. Es importante que se establezca desde el principio un canal de comunicación eficaz, con dialogo abierto y oportunidades para los miembros se sientan confortables en hacer sus sugerencias y demandas. Además, es de responsabilidad del Project Manager mantener el equipo unido, motivado y con ganas de llevar a cabo el proyecto, y eso no es tarea fácil. Cada ser humano tiene expectativas, motivaciones, valores e ilusiones distintas.
15.3 Las habilidades del Project Manager Un Project Manager de éxito debe reunir una serie de habilidades y capacidades que le permitirá conducir correctamente su equipo de trabajo y el proyecto por lo cual ha sido asignado. Las principales habilidades son las siguientes:
·
Planificador: La clave de una exitosa ejecución de un proyecto es una buena planificación. Como planificador, el Project Manager deberá asegurar que antes de la ejecución de los trabajos, se reserve una cantidad de tiempo razonable para que se pueda preparar un plan que garantice la participación de los recursos necesarios, el desarrollo de un cronograma viable y sobre todo el consenso de todos los interesados involucrados en el proyecto.
·
Integrador: Quizás sea su principal papel. El Project Manager no puede ver solamente un árbol. Tiene que conocer toda la floresta, es decir que su enfoque tiene que ser más amplio que los demás, un proyecto es estructurado a partir de diversas variables que se interrelacionan entre si, y que muchas veces son conflictivas.
460
• Comunicador: Si no se desarrolla una comunicación adecuada con los interesados, será muy difícil llevar a cabo el proyecto sobre todo dentro de los plazos estimados. Además de mantener un nivel de comunicación adecuado con su equipo, el Project Manager deberá mantener este mismo nivel de comunicación con su gerente, con el cliente y con todos los interesados que ejercen una influencia directa en el proyecto.
·
Líder: Para poder gestionar el proyecto de manera eficaz, es fundamental que el Project Manager sepa desarrollar su liderazgo. Conocer bien el producto o servicio que se desarrolla, conocer la política de la organización, saber negociar, mantener buenas relaciones con todos los interesados y proveer información a todos son maneras de crear confianza y demostrar liderazgo en el proceso de conducción del proyecto. El liderazgo quizás sea el atributo más difícil para un Project Manager, ya que para ello es necesario casi un talento nato, un carisma que sea capaz de motivar todo el equipo de forma que todos trabajen unidos hacia un objetivo común. Existe una tendencia en el mercado de seleccionar a un Project Manager solamente por sus habilidades técnicas o por su formación académica. Si bien la experiencia y el conocimiento sean fundamentales para el desarrollo de su actividad, nunca podrán reemplazar a la función de un líder.
·
Administrador del tiempo: Se suele decir que el tiempo es un bien escaso, que una vez perdido, no se recupera jamás. Para el Project Manager, el tiempo es una restricción importante y por esta razón, tendrá que saber gestionarla correctamente.
·
Administrador de Personal: Administrar personas no es lo mismo que administrar materiales, costes o plazos. El Project Manager deberá establecer un ambiente adecuado donde las personas puedan desarrollar sus tareas, y tendrá que estar capacitado para lidiar con los conflictos, expectativas y frustraciones que surgirán a lo largo del proyecto.
·
Negociador: Negociar significa discutir con otras personas con el objetivo de alcanzar un acuerdo. Estos acuerdos pueden ser negociados directamente o a través de un intermediario. La necesidad de una negociación, normalmente proviene del surgimiento de un conflicto, y dependiendo de la naturaleza del conflicto de las personas involucradas en ello, es necesario establecer una determinada estrategia.
Gary R. Heerkens72, en su libro Project Management, hace mención a lo que el define como “habilidades extraoficiales”:
·
Canguro: Aunque personalmente no me guste el término, esta denominación se refiere a la necesidad del Project Manager de dar instrucciones y supervisar al grupo, y a veces, a algunos individuos de forma especial, sobre todo cuando estos no demuestran tener la autonomía suficiente para poder desarrollar su labor.
·
Comercial: En muchos proyectos de índole técnica, la presencia de un Project Manager puede significar para los técnicos un supuesto incremento de documentación y burocracia en el proyecto. El Project Manager tiene que tener la capacidad de saber “vender” su forma de trabajo y sobre todo ser capaz de ganar la confianza de los implicados en sus apuestas.
·
Profesor: Project Managers veteranos pueden aportar una cantidad importantísima de
461
“lecciones aprendidas” y desarrollar labores de formación que proporcionarán al grupo conocimientos, seguridad y confianza.
462
• Amigo: Mantener una relación profesional y de amistad dentro del entorno de trabajo es difícil. No obstante, si el Project Manager es capaz de lograrlo, podrá formar un grupo implicado entre si y volcado a los intereses principales del proyecto. Una comunicación abierta, informal y sincera aportará al Project Manager una cantidad importante de información que un sistema formal, cerrado y burocrático quizás no sería capaz de hacerlo.
15.4 La certificación PMP® El Project Management Institute (www.pmi.org) es la organización líder, a nivel mundial, para la profesión de Project Manager. Maneja un riguroso programa de certificación, reconocido globalmente y para el que mantiene la certificación ISO – 9001 en sistemas de administración de calidad. El obtener una certificación profesional a través del PMI significa que un individuo:
· · · ·
Ha demostrado poseer la formación apropiada y/o la experiencia profesional. Ha acreditado un examen riguroso. Ha aceptado regirse por un código de conducta profesional. Se ha comprometido a mantener activa su credencial a través de cumplir con los requisitos establecidos.
Las certificaciones profesionales, disponibles para miembros y no miembros del PMI son ampliamente reconocidas y aceptadas en todo el mundo, como evidencia de un nivel de educación, conocimiento y experiencia en la disciplina de Dirección de Proyectos. Existen profesionales certificados actuando en diversos proyectos en todos los rincones del mundo, desde Dubai a Río de Janeiro, o desde Tokio a Dublín. Para ser elegible para obtener la certificación PMP®, primero se debe cumplir con los requisitos de educación y experiencia en Project Management y estar de acuerdo en apegarse a un código de ética y conducta profesional. El paso final para convertirse en PMP® es pasar el riguroso examen de opción múltiple, diseñada para evaluar y medir objetivamente tus habilidades para aplicar conocimientos en los siguientes dominios: inicio, planificación, ejecución, monitorización, control, cierre y responsabilidad social y profesional. Este examen, realizado on line, desde un centro oficial habilitado, es administrado globalmente con ayuda traducida en diez lenguajes, incluido el español.
Categoría 1 Para profesionales con título universitario de carreras de cuatro años o más de duración. Deben cumplir con:
·
4.500 horas de experiencia en Project Management, durante, por lo menos, tres años, en los últimos seis años (se documenta en el Project Management Experience Verification Form).
463
•
35 horas de capacitación en Project Management. Capacitación específica dirigida a los objetivos específicos de Project Management. No tiene requisitos especiales de cuándo se debe haber tomado esa capacitación. Debe incluir temas de las áreas de conocimientos. Pueden ser: carreras, parte de carreras o cursos universitarios, cursos o programas ofrecidos por empresas de educación, cursos ofrecidos por capítulos del PMI, cursos ofrecidos por Registered Education Providers, por el empleador o a distancia.
Documentación requerida para esta categoría:
·
·
Un currículo vitae actualizado, detallando la experiencia de trabajo y el complemento educativo (se debe suministrar el nombre y dirección completa de todos los empleadores y universidades atendidas). Copia del diploma o traslado a una carrera intermedia o grado universitario equivalente. Formulario(s) de verificación de experiencia, cumpliendo con todos los criterios listados anteriormente.
Categoría 2 Para profesionales sin título de carreras de cuatro años o más de duración. Deben cumplir con:
·
7.500 horas de experiencia en Project Management, durante por lo menos cinco años, en los últimos ocho años (se documenta en el Project Management Experience Verification Form).
·
35 horas de capacitación en Project Management. Capacitación específica dirigida a los objetivos específicos de Project Management. No tiene requisitos especiales de cuándo se debe haber tomado esa capacitación. Debe incluir temas de las áreas de conocimientos. Pueden ser: carreras, parte de carreras o cursos universitarios, cursos o programas ofrecidos por empresas de educación, cursos ofrecidos por capítulos del PMI, cursos ofrecidos por Registered Education Providers, por el empleador o a distancia
Documentación requerida para esta categoría:
·
Un currículo vitae actualizado, detallando la experiencia de trabajo y el complemento educativo (se debe suministrar el nombre y dirección completa de todos los empleadores y escuelas atendidas).
·
Formulario(s) de verificación de experiencia, cumpliendo con todos los criterios listados anteriormente.
Fuente: Project Management Institute (www.pmi.org) Como son muchos los candidatos que se presentan a este examen en todo el mundo, el PMI no tiene cómo comprobar la veracidad de los datos presentados por todos los candidatos. Sin embargo, el PMI realiza auditorias permanentes a un porcentaje de los candidatos, exigiéndoles que comprueben que la documentación presentada es verdadera. Por esta razón, es sensato y prudente que el candidato realmente cumpla con los requisitos establecidos por el PMI para
464
presentarse al examen.
465
Para poder realizar el examen, es necesario que el candidato tenga entre sus manos una carta de elegibilidad enviada por el PMI al término del registro de información y validación correspondiente. El candidato deberá reservar la fecha de su examen en el centro homologado más cercano de su residencia.
El examen El examen consta de doscientas preguntas de opción múltiple cubriendo cinco categorías: procesos de inicio, procesos de planificación, procesos de ejecución, procesos de control y monitorización, procesos de cierre y conocimiento del código de conducta para profesionales de la dirección de proyectos. Estas categorías consideran todas las áreas de conocimiento contenidas en el PMBOK® Guide. El examen tiene una duración de cuatro horas.
Visión general del examen El examen asegura el dominio de los aspirantes en la disciplina de dirección de proyectos; toma en cuenta los cinco grupos de procesos y las nueve áreas de conocimiento que el PMI ha identificado como prácticas que funcionan para obtener éxito la mayor parte de las veces en la mayoría de los proyectos que son realizados.
Realizado en el ordenador.
Idioma: Inglés con ayuda en diez lenguajes, incluido el español.
·
200 preguntas de opción múltiple con cuatro opciones, cubriendo las nueve áreas de conocimiento dentro de los cinco grupos de procesos de la dirección de proyectos, más temas de responsabilidad profesional.
·
25 preguntas no son contabilizadas para el resultado final (son usadas para efectos de benchmarking), están distribuidas aleatoriamente a lo largo del examen.
·
Duración: 240 minutos. El examen será calificado una vez que se haya concluido o bien al terminar el tiempo asignado para contestarlo.
·
El examen se acredita con un mínimo de 61% (106 respuestas correctas de un total de 175 preguntas).
Soporte en idioma español Al momento de proporcionar la información en el formato correspondiente, se debe especificar que se desea tener soporte en español, esto se hace indicando en la sección correspondiente el idioma; junto a este punto está el que dice "segundo idioma", ahí se deberá seleccionar español. El examen será presentado totalmente en idioma inglés pero al llenar la opción de segundo idioma se tendrá opción de traducir una a una cada pregunta presionando el botón correspondiente. Al momento de estar aplicando el examen podrá traducir las preguntas que no comprenda en el idioma español. Para una pequeña práctica, al inicio de su examen tendrá la opción de un tutorial que le guiará sobre el manejo del programa en que es aplicado el examen; además, le permitirá practicar con algunas preguntas de muestra.
466
Figura 196: Proceso de certificación PMP
La evaluación del examen es inmediata, así que, una vez terminado el tiempo o cuando al finalizar el examen, se conocerá el resultado.
Calif icación aprobatoria Si el resultado es aprobatorio, aproximadamente en quince días hábiles el PMI emitirá una carta de felicitación, un tríptico explicando los beneficios, un cuadernillo que describe los requisitos de continuidad de la certificación y un PIN distintivo.
Calificación reprobatoria Primero que nada, no hay que desanimarse, el 60% de las personas que se presentan a este examen por primera vez lo reprueba, señal de que aún existen áreas de oportunidad para poder aprobar el examen. Hay que tener en cuenta que se tienen tres oportunidades al año, por lo que es necesario identificar cuáles fueron las áreas de oportunidad y buscar elementos de estudio complementarios. En internet hay una gran cantidad de sitios con herramientas de autodiagnóstico y autoestudio. Se recibirá vía correo electrónico la autorización para volver a presentar el examen. Será necesario pagar los costes de reexaminación en el PMI.
Continuidad de la certificación El certificado PMP® tiene un ciclo de tres años, en el cual se espera que el profesional alcance los requisitos de continuidad de certificación (cuyo acrónimo en inglés es CCR) establecidos por el PMI. Para mantener su certificación, el PMP® deberá acumular PDU´s (Profesional Development Units) a lo largo de estos tres años posteriores a la certificación. Los PDU’s se obtienen a través de actividades relacionadas con el Project Management, sea a través de asistencias a cursos, experiencia profesional o participación de seminarios o congresos como asistente o como ponente.
467
Son cinco las categorías de actividades que acreditan PDU’s:
· · · · ·
Categoría 1: Educación académica formal. Categoría 2: Actividades profesionales. Categoría 3: Programas ofrecidos por REP. Categoría 4: Educación provista por otras organizaciones. Categoría 5: Servicio a la profesión u organizaciones comunitarias.
Los PDU pueden ser reportados por internet a través de un formulario electrónico disponible en la página Web del PMI, conforme se vayan obteniendo. El sistema usado por el PMI contiene las fechas del ciclo de la credencial del PMP y un formulario de reporte de actividades. Adicionalmente a la acreditación de los PDU, es necesario completar una solicitud para la renovación de la credencial, remitir el pago de la renovación y confirmar la adhesión al “Código de ética y conducta profesional” del PMI. La recomendación obvia en estos casos es la de no esperar hasta el último o para obtener y registrar los PDU. Fuente Project Management Institute: www.pmi.org
15.5 El Código de ética y conducta profesional de PMI El PMI posee un Código de ética y conducta profesional en donde se establece el comportamiento que debe seguir el profesional que se dedica a la práctica del Project Management. Este código habla de los principios, la visión y la aplicabilidad, sobre la responsabilidad, el respeto, la justicia y la honestidad. El Código de ética y conducta del profesional de PMI se encuentra en la siguiente dirección de internet (en inglés): http://www.pmi.org/About-Us/Ethics/Code-of-Ethics.aspx
468
Capítulo 16 20 reglas de oro del Project Management “Se dan consejos, pero no el juicio para sacar provecho de ellos” François de la Rochefoucauld73, escritor francés
470
Introducción Este capítulo traduce exactamente esta frase célebre de François de la Rochefoucauld 73. Se pueden dar consejos, pero toca a cada uno de nosotros actuar de la forma más correcta según nuestros principios. El Project Manager es, ante todo, un ser humano, dotado de capacidades, expectativas y posturas diferentes. Los hay muy agresivos, que buscan el resultado a corto plazo y están constantemente pendientes de todo lo que se hace en el proyecto. De las misma forma que los hay más conformistas, que actúan de forma pasiva, dejando las riendas del proyecto al equipo ejecutor. Este capítulo no tiene ninguna intención de dar consejos a nadie. Hay un refrán brasileño que dice “si los consejos fueran buenos, no se daban..., se vendían”. De todas formas, existen unas pautas que sí deberían tenerse en cuenta, y que tratamos de ampliarlas aquí. Mas que pautas, la información que facilitamos a continuación son buenas practicas que quizás no puedan evitar grandes desastres, pero pueden ayudarnos a alejarnos de ellos.
1. Enfoque su dedicación a pocos proyectos a la vez y termine todos : No es recomendable coordinar demasiados proyectos. Frecuentemente, el enfoque se pierde, y con ello mucha información. Además, la comunicación pierde eficacia y el cliente se siente mal atendido. 2. Cuide de su equipo: Generalmente, pensamos que el cliente está siempre de primero. No podemos cuidar a nuestro cliente si no cuidamos a nuestro equipo. Debemos hacer cosas para el equipo en forma colectiva, y a la vez atender los problemas de cada individuo. 3. Ocúpese de las tareas del día: Un proyecto es un emprendimiento dinámico que requiere atención continua. No se preocupe con tareas que empezarán en fases más avanzadas. Toda la atención debe ser dedicada a las tareas en marcha y en sus sucesoras. 4. No posponga las decisiones: La incertidumbre será una constante en todo el desarrollo del proyecto. Su incapacidad de decidir resultará en la incapacidad de su equipo de trabajar. 5. Espere lo inesperado: El Project Management aunque no parezca, no es una ciencia exacta. Es más, un proyecto puede serlo todo, menos algo previsible. Por esta razón, es importante preparar el proyecto con mucha planificación, formar un equipo preparado y estar atento a cualquier señal de que algo raro pueda ocurrir. 6. Esté atento al “ambiente” del proyecto: Hay ocasiones, muchas veces frecuentes, en las que algo raro está pasando en el proyecto, pero nadie se atreve a decirlo. Fíjese en cualquier actitud extraña principalmente por parte del cliente o del equipo del proyecto. Una de las principales habilidades del Project Manager es la de negociador, cuya búsqueda está volcada siempre a alcanzar acuerdos que posibiliten el avance del proyecto. 7. Establezca una estrategia para el proyecto que determine alcanzar todos los objetivos establecidos.
8. Verifique periódicamente las líneas base para asegurar que el proyecto está 471
avanzando de acuerdo con los planes del proyecto.
472
9. Motive la implicación del equipo: Cuanto mayor la motivación del equipo, mayor será su interés y disposición para participar en el proceso decisorio. El Project Manager deberá invitar la participación del equipo desde el inicio, buscando utilizar métodos participativos siempre que posible. 9. Establezca un entregable para cada milestone del proyecto: De esta forma, la evolución de los trabajos pueden ser fácilmente medida.
10. No realice estimaciones en actividades con duración mayor de seis semanas: Dichas estimaciones podrán muy posiblemente resultar erróneas. Mejor dividir esta tarea en tres o cuatro partes para facilitar su seguimiento.
11. Intente disponer de una reserva extra de tiempo: Siempre podrá surgir una incidencia que podrá perjudicar la evolución de una actividad.
12. No deje, de todas formas, que los integrantes del equipo esperen hasta el plazo límite de comienzo de una actividad para empezar a trabajar : Este tiempo de espera puede ser necesario en el caso de que ocurran problemas.
13. Evite el gold plating: Es decir, entregar más cosas de las que el cliente ha solicitado. Añadiendo más elementos, se incrementa el riesgo de no realizar el producto dentro de los plazos y presupuestos aceptados. Al cliente se le debe entregar solo lo solicitado, ni más, ni menos. 14. Documente todo lo que sea posible : Un proyecto de éxito termina con una robusta documentación que le respalda. Estimaciones, actas de reunión, líneas base, contratos, planes... Todo esto puede ser muy valioso a la hora de determinar estimaciones a un futuro proyecto de características similares. 15. Escuche a los veteranos: El juicio de expertos siempre será útil para poner en marcha este proceso. Esta colaboración puede venir tanto de un especialista como de un grupo de personas con mucha experiencia o que ha asistido a alguna formación especializada y que pueden aportar muchas informaciones. 16. Planifique, planifique, planifique: Proyectos de éxito son proyectos bien planificados. La probabilidad de éxito de un proyecto se incrementa si el Project Manager elabora estimaciones y metas realísticas de costes, plazos y recursos, y desarrolla estrategias para anticipar problemas potenciales. 17. ¡Comunique SIEMPRE!: Para muchos, el Project Management significa gestionar el alcance, el tiempo, los costes y las personas de manera organizada y planificada. No deja de ser cierto, pero hay que pensar que todos estos elementos no pueden ser correctamente coordinados si no existe una comunicación eficiente entre todos los implicados. La comunicación constante y adecuada, aportará una coordinación en el equipo del proyecto, podrá anticipar eventuales problemas o riesgos, además de generar los medios para que todo el personal involucrado reciba la 473
información adecuada en el tiempo oportuno. La mala gestión de la comunicación puede arruinar cualquier planificación por mejor que ésta haya sido desarrollada.
474
19. Tenga una vision de sistema: La gestión de un proyecto es un sistema, un conjunto complejo de innúmeras partes que interrelacionan entre sí. No se trata de prestar atención a un solo árbol, el equipo de proyecto ya existe para que sus integrantes puedan dedicarse a su parte correspondiente del proyecto. El Project Manager debe dedicarse a “vigilar” toda la floresta. 20. Más vale prevenir que remediar: Prácticamente, todas las herramientas que hemos dispuesto en esta obra tienen una naturaleza preventiva. Es cierto que, normalmente, la implantación de medidas preventivas conlleva a un coste añadido, pero es importante tener en cuenta que la implantación de una medida correctora saldrá a la final, mucho más cara, sin contar que normalmente se traducirá en insatisfacción por parte del cliente.
475
Cap ítulo 17 Documentos del pro yecto “Estableced el orden: el hábito se encargará de mantenerlo” Francis de Gaston
476
74
, Mariscal Francés
Introducción La documentación es un elemento que tiene como propósito principal ofrecer a cualquier interesado toda la información acerca del desarrollo de un proyecto, sus registros, actas, estimaciones, informes, contratos, entre otras funciones. Un proyecto es respaldado por su documentación, y su efectividad se traduce en su buena gestión: evitar excesos y producir solamente documentos que realmente añadan algún valor. Además, para asegurar una completa documentación, se hace necesario que se realicen registros desde el principio del proyecto. Cuanto más complejo es un proyecto, normalmente mayor será su demanda por documentación y más compleja será su estructura. La documentación de un proyecto constituye una herramienta poderosa, que dará respaldo a todas las acciones realizadas por el Project Manager y su equipo, y servirá como una valiosa base histórica para consulta para proyectos La documentación del proyecto también sirve para:
·
Referencia para futuros cambios: Aunque el proyecto esté completo y entregado al cliente, en el futuro, el cliente podrá solicitar actualizaciones, añadiendo al producto nuevas funciones o mejoras que en su momento no existían. Son casos que suelen ocurrir por ejemplo, en proyectos tecnológicos. La documentación original del proyecto servirá de base para la planificación de los eventuales añadidos.
·
Datos históricos para estimaciones de plazos y costes: Proyectos completados con éxito son una excelente fuente de información para proyectos futuros si su documentación ha sido desarrollada correctamente. Estimar costes y plazos no es una tarea fácil y poder contar con los datos de un proyecto similar, podrá ayudar mucho a la hora de planificar. No hay que olvidar que incluso los proyectos que no han finalizado dentro de lo planificado, también aportan muchas lecciones sobre “cómo no hacer ciertas cosas”.
·
Apoyo a los Project Managers novatos: La carrera de Project Manager es fundamentada a base de mucho estudio. Un Project Manager es un profesional que se dedica al desarrollo de muchas áreas de conocimiento y la documentación de un proyecto siempre será una excelente fuente de estudio. ¿Cómo se hizo una EDT para un determinado proyecto?, ¿cómo se llegó a una determinada decisión?, ¿por qué fue necesario realizar un cambio tan significativo en una fase tan avanzada? Estas, entre otras, son cuestiones que están registradas en la documentación y que serán muy útiles a las nuevas generaciones de Project Manager.
·
Apoyo al equipo del proyecto: Como referencia, los documentos del proyecto pueden ayudar al equipo a lidiar con situaciones inesperadas. Un problema similar puede haber ocurrido en algún proyecto anterior y su documentación podrá aportar aclaraciones importantes.
·
Referencia para evaluaciones: En muchas organizaciones, se utiliza la documentación de un proyecto para evaluar la performance del Project Manager y de su equipo en proyectos similares.
La ISO9000
477
La ISO9000 establece unos procedimientos específicos para el desarrollo de la documentación que soportará el sistema de calidad de una organización. Algunas de sus orientaciones pueden ser perfectamente aplicables a la documentación de un proyecto.
478
Algunos de los procedimientos utilizados por la ISO9000 que son muy útiles en la documentación de un proyecto incluyen, entre otras cosas:
· · · · · · ·
Obtener la aprobación de la gerencia antes de su publicación. Realizar revisiones y actualizaciones siempre y cuando necesario. Asegurar que se han identificados los cambios y su estado de revisión. Garantizar que las revisiones pertinentes se encuentran disponibles. Asegurar que los documentos permanecen legibles y son fácilmente identificados. Controlar su distribución, de forma que lleguen a las personas autorizadas. Evitar el uso de documentos obsoletos, aplicándoles una identificación adecuada.
El ciclo de vida de la documentación Un documento es desarrollado según el momento que le corresponda, de lo contrario, este documento no tendrá sentido. Por ejemplo, un acta de apertura de un proyecto debe ser emitida antes de empezar el proyecto, y no cuatro meses después. Es importante que un Project Manager sepa el momento adecuado en que un determinado documento debe ser aplicado en un proyecto. Por ejemplo, en lo que se refiere a las actas de reunión, hay un entendimiento común de que su generación y envío a las personas involucradas no debería sobrepasar las 24 horas, tras el cierre de la reunión correspondiente. Hacer un uso adecuado del ciclo de vida de los documentos, ayuda a soportar el desarrollo de cada fase de un proyecto. Una documentación incompleta, desfasada, o mal administrada puede causar la toma de decisiones equivocadas, por no contar con la información adecuada. Además, se desperdicia tiempo buscando la información correcta. Un documento suele tener un ciclo de vida que pasa por las siguientes etapas:
·
Creación de un borrador inicial: Normalmente, el Project Manager se reúne con el personal involucrado en el proceso que está vinculado con el documento en cuestión (personal de compras, jurídico, recursos humanos...) y juntos definirán la estructura que el documento debe tener. En esta etapa, el Project Manager tendrá a su disposición, un borrador inicial.
·
Solicitud de revisión: Si el Project Manager considera necesario, podrá solicitar la revisión del documento a otros involucrados en el proyecto. Está solicitud podrá generar sugerencias e importantes añadidos por parte del personal consultado. Realizados los cambios, el documento es enviado a una revisión final a la gerencia.
·
Aprobación: Algunos documentos necesitan la aprobación formal de la gerencia para que puedan ser emitidos y distribuidos al personal correspondiente.
·
Archivo: Cuando un proyecto termina, la documentación es archivada. Muchas empresas mantienen un repositorio central de documentación para consulta, lo que muchos llaman como “lecciones aprendidas”.
479
Apéndice A Documentos del pro yecto A continuación, facilito un amplio listado de documentos que componen la documentación básica que un proyecto debe tener, organizada por las fases del ciclo de vida de un proyecto. Cada documento incluye una breve descripción de su uso y objetivos, y, además, sugiere los campos mínimos que deberían formar parte de su composición. Es importante resaltar que cada empresa es libre para confeccionar su documentación, que normalmente refleja su política, sus procedimientos internos e incluso su cultura organizacional. Por lo tanto, los modelos presentados son una sencilla sugerencia del autor. No obstante, este Apéndice podrá servir como una guía básica de documentación de proyecto, aportando sugerencias y orientaciones acerca de cómo dejar un proyecto documentado de forma completa y consistente.
Puntos imprescindibles: Independientemente del contenido que un documento pueda tener, es imprescindible que se incluyan los siguientes puntos:
·
Nombre del proyecto: El nombre del proyecto ayuda, sobre todo, a establecer una identidad al trabajo que será realizado dentro de la organización y, además, tiene connotaciones comerciales, puesto que puede crear una expectativa en el mercado. Existen algunas empresas que llegan incluso a crear un logotipo para el proyecto. A la hora de darle un nombre, es importante tener en cuenta algunas recomendaciones, como, por ejemplo: 1. Que sea un nombre corto y fácil de usar, 2. Que se asigne un nombre único y memorable, 3. Que sea multicultural y 4. Que sea fácil de pronunciar. 5. En algunos casos el nombre del proyecto será el nombre del producto y/o servicio que será ofertado al mercado tras su finalización. En estos casos es fundamental comprobar si el nombre elegido no se encuentra registrado por otra empresa. El uso de un nombre registrado puede dar lugar a denuncias legales por parte de su propietario.
·
Código del proyecto: Para los códigos de proyecto normalmente se les asignan un acrónimo (mezclando letras con números o fechas) que será asignada a un proyecto específico. Se debe tener en cuenta algunas recomendaciones al momento de asignar un nombre, como por ejemplo, que sea un acrónimo corto y de fácil asociación. El acrónimo PWEB003-10 significa que es un proyecto de desarrollo de una página Web y el “003-10” significa que es el tercer proyecto de esta naturaleza que se desarrolla en el año 2010. Muchas empresas asignan el código de proyecto acorde con el nº de su presupuesto correspondiente.
·
Nombre del cliente: Un proyecto normalmente es desarrollado para un cliente externo y/o interno. Es importante mencionarlo.
·
Departamento de la empresa: Algunos documentos podrán ser desarrollados por departamentos que no están vinculados directamente al proyecto (por ejemplo:
481
RRHH, jurídico, entre otros), y por ello es importante la correcta identificación del departamento responsable por su emisión.
482
• Preparado por: Además de señalar el departamento responsable, es importante indicar la persona que ha preparado el documento, por si surgen dudas en algún punto específico.
·
Revisado y aprobado por: Antes de realizar la distribución de los documentos al personal involucrado yo a los interesados del proyecto (patrocinadores, proveedores, el cliente...), es fundamental que se revise y se aprueben los documentos generados y sus correspondientes actualizaciones.
·
Fechas: Todos los documentos deben poseer fecha de emisión para que se pueda realizar un control de su emisión, revisión y aprobación, además de sus correspondientes vigencias y/o caducidades.
Es importante también mantener un control adecuado de la distribución y generación de versiones de este documento, por lo tanto, es importante no olvidar:
·
Lista de distribución: En el ámbito del Project Management existe una regla no escrita de sentido común que determina que la eficiencia de un documento está directamente relacionada con la distribución su contenido a la gente adecuada en el momento oportuno. Para asegurar de que la información está llegando a las personas que corresponden, se genera y se mantiene actualizada una lista de distribución que contiene los nombres, departamentos y correos electrónicos de los involucrados e interesados de un proyecto.
·
Control de versiones: Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los documentos. Un sistema de control de versiones facilita la administración de las distintas versiones de cada documento desarrollado, así como las posibles modificaciones realizadas.
Los documentos que vienen a continuación son presentados con un contenido y en un orden orientativo. Su adecuado uso y organización dependerá, sobre todo, de las caracteristicas de cada proyecto y de las necesidades organizacionales de cada empresa.
483
DOC Nº 001 Acta de constitución del proyecto
(Project Charter) El acta del proyecto es el primer documento desarrollado para un proyecto. Este documento formaliza el inicio de un proyecto e identifica a sus interesados, el equipo que llevará a cabo su desarrollo, pero, sobre todo, concede la autoridad al Project Manager. Los componentes básicos del acta de constitución del proyecto son simples. Primero se autoriza formalmente el inicio del proyecto y se asigna el Project Manager, que, normalmente, será el encargado de generar el documento, que será, no obstante, distribuido bajo la firma de la gerencia la empresa. Mientras no se genere o no se firme este documento, no se habrá producido la creación formal del proyecto y tampoco se ha reconocido formalmente el Project Manager. Este documento debe contener las siguientes informaciones a continuación:
·
Descripción del proyecto: De preferencia, que la descripción del proyecto sea breve, utilizando términos clave de entendimiento general y si posible utilizando algún tipo de grafico o diagrama, si aplicable.
·
Requisitos del producto y/o servicio: De forma general, se define requisitos como “los intereses documentados del cliente”.
·
Asignación del Project Manager: Una de las razones fundamentales de la confección de una acta de constitución del proyecto es formalizar la asignación del Project Manager, que responderá por el proyecto y tendrá la autoridad necesaria para conducir su equipo y las actividades correspondientes.
·
Objetivo del proyecto: El objetivo del proyecto consiste en los beneficios que la organización pretende alcanzar como resultado de la inversión realizada para su desarrollo. Los objetivos del proyecto pueden ser desglosados en tres categorías: 1: Objetivo principal: la razón por la cual el proyecto es puesto en marcha; 2: Objetivos añadidos: son los objetivos logrados a través de los efectos provocados por el objetivo principal, y 3: Objetivos no esperados: son aquellos objetivos logrados que no estaban previstos por la organización.
·
Hitos: Tarea de duración cero que simboliza haber conseguido un logro importante en el proyecto o la finalización de una fase. Este concepto es ampliamente desarrollado en la sección 6.5.1.9.
·
Supuestos: Factores que son considerados verdaderos para realizar una planificación o estimación, sin que sea necesario demostrar su fiabilidad. Este concepto es ampliamente explicado en la sección 2.2.1.
·
Restricciones: Factor que impone un límite en el desarrollo de una determinada actividad. Este concepto es ampliamente descrito en la sección 2.2.1.
·
Interesados: Individuos y/u organizaciones que están involucrados en el proyecto, tienen intereses en su desarrollo y poseen diferentes necesidades y expectativas. Este concepto
484
es ampliamente expuesto en la sección 1.7.
485
•
Organigrama: Representación gráfica de la estructura de la organización y/o del proyecto. Representa las estructuras departamentales y, en algunos casos, las personas que las dirigen, hacen un esquema sobre las relaciones jerárquicas y competenciales de vigor en la organización. . Este concepto es ampliamente explicado en la sección 9.1.1.1.
•
Responsables, funciones y obligaciones: Todos y cada persona involucrada en el proyecto tiene unas funciones y obligaciones específicas y correspondientes con su papel en el proyecto, que deberán estar claramente identificadas.
Además no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
486
DOC Nº 002 Registro de interesados
(Stakeholder register) Un interesado es cualquier persona o entidad que pueda influenciar (positiva o negativamente) en los resultados y/u objetivos de un proyecto. El registro de interesados es un documento que contiene una lista de los interesados externos e internos de un proyecto. Su correcto desarrollo depende de la respuesta de las siguientes cuestiones:
· · · · · ·
¿Cuál es el nombre del interesado, sus datos de contacto, puesto y empresa? ¿Cuáles son sus expectativas, intereses, influencias y requisitos? ¿Es un interesado crítico en todo el proyecto o en fases específicas? ¿Qué rol podrá desarrollar y cuál es su grado de poder? ¿Cuál es la frecuencia que necesita para recibir informes del proyecto? ¿Cuál es la vía de comunicación preferente?
El registro de los interesados es, por lo tanto, un documento útil de identificación de los interesados del proyecto, pero sobre todo, de su grado de poder y sobre todo de influencia en los resultados de un proyecto. Para cubrir correctamente este registro es interesante confeccionar una “matriz de los interesados” (véase también sección 1.7.3.1.3), que puede determinar la relación entre los interesados y sus funciones en cada fase del proyecto.
NOMB RE
PUES TO
DPTO.
ROL
TIP O
Juan Pérez
Gere nte
Gerencia
Silvio Martí nez
Ingenie ro
Cliente
Exte rno
Líder técnico
Inter no
Sofí a Sán
Contab le
Colabora dor
Inter no
Semanal, email
ABC Comp uter
Provee dor
-
Proveedo r
Exte rno
Sem anal, teléf ono
Car los Bla
Financi ero
Compras
Colabora dor
Inter no
Semanal, email
Ingen iería Técni ca Contabili dad
COMUNICA CIÓN
EXPECTATI VAS
Semanal, reunión de seguimi Diaria, email y/o teléfono
Entrega del producto acorde con requisitos Entrega del producto acorde con requisitos Facturas pagadas y cobradas Entrega de compone ntes acorde Facturas pagadas y cobradas
GRADO DE IN FLU Alto
Alto BajoMedio
Alto
Medio
Figura 197: Registro de interesados
Este documento debe estar disponible para todos los involucrados en el proyecto y debe contener estrictamente las informaciones relevantes para la correcta identificación de los interesados. Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
487
DOC Nº 003 Plan de proyecto
(Project Management plan) El plan de proyecto es un documento formal y aprobado por la dirección, y es utilizado para la administración general del proyecto. Funciona básicamente como guion que dará las pautas para el desarrollo de las actividades establecidas. El plan empieza con una planificación básica que va siendo incrementada durante todo el proceso de implantación y se espera que se mantenga durante la fase de ejecución, seguimiento y control. Es un documento formal, aprobado por la gerencia y por el cliente, y deberá pasar por constantes actualizaciones. De acuerdo con el PMBOK®, el plan de proyectos es utilizado para:
· · · · ·
Guiar la ejecución del proyecto. Documentar las hipótesis y las decisiones de la planificación del proyecto. Facilitar la comunicación entre los interesados. Definir las revisiones clave de la gestión. Proporcionar un plan de referencia para la medición y control del proyecto.
El plan de proyecto es considerado como uno de los documentos más importantes del proyecto (sino el más importante) y, debido a su importante extensión y nivel de detalle, debería ser organizado en secciones, como las que presentamos a continuación:
Datos generales del proyecto
·
Objetivo del proyecto: El objetivo del proyecto consiste en los beneficios que la organización pretende alcanzar como resultado de la inversión realizada para su desarrollo. Los objetivos del proyecto pueden ser desglosados en tres categorías: 1: Objetivo principal: la razón por la cual el proyecto es puesto en marcha; 2: Objetivos añadidos: son los objetivos logrados a través de los efectos provocados por el objetivo principal, y 3: Objetivos no esperados: son aquellos objetivos logrados que no estaban previstos por la organización.
·
Supuestos: Factores que son considerados verdaderos para realizar una planificación o estimación, sin que sea necesario demostrar su fiabilidad. Este concepto es ampliamente desarrollado en la sección 2.2.1.
·
Restricciones: Factor que impone un límite en el desarrollo de una determinada actividad. Este concepto es ampliamente explicado en la sección 2.2.1.
·
Interesados: Individuos y/u organizaciones que están involucrados en el proyecto, tienen intereses en su desarrollo y poseen diferentes necesidades y expectativas. Este concepto es ampliamente descrito en la sección 1.7.
488
Alcance
·
EDT - Estructura detallada del trabajo: Comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto. Véase también sección 5.3.
·
Entregables: Producto o servicio resultante del trabajo realizado durante una determina fase, como por ejemplo, la colocación del piso en una obra es el resultado de una de las fases de construcción de un edificio. Véase también sección 2.4.
·
Hitos: Tarea de duración cero que simboliza el haber conseguido un logro importante en el proyecto o la finalización de una fase. Este concepto es ampliamente explicado en la sección 6.5.1.9.
·
Criterios de aceptación: Determinados condicionantes que implican en la revisión de los entregables del proyecto que deberán atender a los requisitos establecidos.
Tiempo y recursos
·
Equipo asignado.
·
Responsables, funciones y obligaciones: Todas y cada una de las personas involucradas en el proyecto tienen unas funciones y obligaciones específicas y correspondientes con su papel en el proyecto, que deberán estar claramente identificadas.
·
Líneas base del proyecto: Véase también sección 2.1.3.
·
Diagramas de red: Un diagrama de red es el término genérico de un diagrama, que representa algún tipo de red que pueda conectar varias actividades en una secuencia cronológica. Presentan una serie de variaciones, y cada una de ellas podrá ser estructurada para los más diferentes fines. Véase también sección 6.2.1.1.
·
Cronograma del proyecto: Consiste en una lista de todos los elementos terminales de un proyecto con sus fechas previstas de comienzo y final, y permite la creación de listas de tareas, la asignación de recursos, precedencias y diagramas. Uno de los tipos más utilizados en el Grafico de Barras de Gantt. Véase también sección 6.5.1.8.
Costes
·
Estimación de costes: Implica en la realización de predicciones sobre la cantidad más probable de esfuerzo, tiempo y niveles de personal necesarios para el desarrollo de un proyecto. Estas estimaciones son importantes sobre todo para determinar la viabilidad de un determinado proyecto. Este concepto es ampliamente explicado en la sección 7.1.
·
Estructura detallada de costes: Lista organizada de costes directos en los que incurrirá el proyecto. Descrita en la sección 7.1.1.10.
489
·
Presupuesto del proyecto: Descrito en el Doc nº 040.
490
Documentación del soporte
·
Acta de constitución del proyecto: Es el primer documento desarrollado para un proyecto. Formaliza el inicio de un proyecto e identifica a los interesados del proyecto, el equipo que llevará a cabo su desarrollo, pero, sobre todo, concede la autoridad al Project Manager. Véase tam bién doc nº 001.
·
Políticas de la organización: Se define como la orientación de la acción administrativa en un determinado sentido, en juego de determinados objetivos generales y particulares que se desean alcanzar.
·
Enunciación de alcance del proyecto: Descrito en el Doc nº nº 007.
·
Planes de contingencia: Descrito en el Doc nº nº 025.
PLANES DE PROYECTO SUBSIDIARIOS
· · · · · · · ·
Plan de gestión del alcance: Descrito en el Doc nº 026. Plan de gestión de costes: Descrito en el Doc nº 027. Plan de gestión de riesgos: Descrito en el Doc nº 020. Plan de gestión del cronograma: Descrito en el Doc nº 028. Plan de gestión de las comunicaciones: Descrito en el Doc nº 023. Plan de gestión de la calidad: Descrito en el Doc nº 016. Plan de gestión de los recursos humanos: Descrito en el Doc nº 022. Plan de gestión de las adquisiciones: Descrito en el Doc nº 024.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice. Es importante consultar la información histórica disponible de proyectos anteriores. Esta puede ser útil para ayudar a verificar hipótesis y evaluar alternativas. El borrador inicial del plan de proyecto puede incluir requerimientos de recursos genéricos y una sucesión de actividades sin fecha. Las versiones siguientes deberán ser refinadas, hasta llegar a la versión definitiva.
491
De acuerdo con Gary R. Heerkens72, en su libro Project Management, un plan de proyecto suele tener, por lo menos, cinco versiones.
·
La primera versión es confeccionada antes del proyecto ser definido. En esta versión las estimaciones de coste y plazo todavía son muy inciertas pues están basadas en la poca información disponible. Generalmente este documento sirve para recoger los fondos necesarios para llevar el proyecto a cabo.
·
La segunda versión del plan de proyecto viene justo en el momento que la organización se está preparando para iniciar el proyecto. Un mínimo de planificación debe ser hecha para que se sea posible decidir formalmente si el proyecto es viable para que la organización invierta en él.
·
Si la propuesta el proyecto es aceptada, la siguiente versión es preparada. Un plan bastante más detallado será confeccionado para orientar el equipo responsable de su implementación. Además, servirá para evaluar y controlar el progreso del proyecto.
·
La cuarta versión del plan de proyecto normalmente es la que más sufre cambios. En este momento, el proyecto ya está en pleno desarrollo, y normalmente, los resultados pueden ser diferentes de los esperados desde cuándo se ha confeccionado la primera versión. Todos estos cambios deben estar reflejados en el plan de proyecto que debe estar constantemente actualizado.
·
La última versión ocurre cuando se acerca el final del proyecto. Esta versión incluirá las últimas acciones del proyecto y formalizará de hecho el cierre del proyecto.
492
DOC Nº 004 Documentación de requisitos
(Requirements documentation) La documentación de requisitos describe el modo en que los requisitos del cliente cumplen con las necesidades del proyecto. Los requisitos pueden comenzar a un alto nivel e ir convirtiéndose gradualmente en requisitos más detallados, conforme se va conociendo más acerca de las necesidades del cliente y de los objetivos del proyecto. Por ello, los requisitos deben ser claros (es decir, medibles y comprobables), rastreables, completos, coherentes y aceptables para los interesados clave. Cuando se alcance este nivel de detalle, los requisitos podrán, entonces, ser añadidos a la línea base del proyecto. El formato de un documento de requisitos puede variar desde un documento sencillo en el que se enumeran todos los requisitos, clasificados por interesado y por prioridad, hasta formatos más elaborados que contienen un resumen de la junta directiva, descripciones detalladas y anexos. Entre los componentes de la documentación de requisitos pueden incluirse, entre otros:
·
La necesidad comercial u oportunidad, que describa las limitaciones de la situación actual y las razones que llevaron a emprender el proyecto.
·
Objetivos de la empresa y del proyecto a ser rastreados.
·
Requisitos funcionales que describan los procesos de la empresa, la información y la interacción con el producto, según sea el caso, que puedan ser documentados por escrito en una lista de requisitos, en modelos o en ambos.
·
Requisitos no funcionales, tales como nivel de servicio, desempeño, seguridad, cumplimiento, capacidad de soporte, retención/depuración...
·
Requisitos de calidad.
·
Criterios de aceptación.
·
Reglas de la empresa que establecen los principios directivos de la organización.
·
Impactos sobre otras áreas de la organización, tales como el centro de llamadas, la fuerza de ventas, los grupos tecnológicos.
·
Impactos sobre otras entidades dentro o fuera de la organización ejecutante.
·
Requisitos de apoyo y capacitación.
·
Supuestos y restricciones alrededor de los requisitos.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
493
DOC Nº 005 Plan de gestión de requisitos
(Requirements management plan) El plan de gestión de requisitos documenta la manera en que se analizarán, documentarán y gestionarán los requisitos a lo largo del proyecto. El Project Manager debe seleccionar la relación más efectiva para el proyecto y debe documentar este enfoque dentro del plan de gestión de requisitos. Muchos de los componentes del este plan se basan en esta relación. Entre los componentes del plan de gestión de requisitos, pueden incluirse, entre otros:
·
El modo en que las actividades de los requisitos serán planificadas, rastradas e informadas.
·
Las actividades de gestión de la configuración: Tales como el modo en que se iniciarán los cambios a los requisitos del producto, servicio o resultado; el método de análisis, seguimiento, registro y comunicación de los impactos, y el nivel de autorización requerido para aprobar dichos cambios.
·
El proceso para otorgar prioridad a los requisitos.
·
Las métricas del producto que se utilizarán y el fundamento de su uso.
·
La estructura de rastreabilidad: Es decir, qué atributos de los requisitos se plasmarán en la matriz de rastreabilidad y qué otros documentos del proyecto serán rastreados.
·
Lista de requisitos excluidos: Los artículos eliminados durante las secciones de verificación, no serán olvidados. Es recomendable documentar los artículos eliminados durante las secciones de verificación en una “lista de requisitos excluidos”, que también formará parte de este documento Si no se documentan los artículos descartados en una lista de exclusión, estos volverán una y otra vez, siempre que se realice el proceso de definición del alcance.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
494
DOC Nº 006 Matriz de rastreabilidad de requisitos
(Requirements traceabilty matrix) La matriz de rastreabilidad de requisitos es una tabla que vincula los requisitos con su origen y los monitorea a lo largo del ciclo de vida del proyecto. Tiene las siguientes funciones:
·
Ayuda a asegurar que cada requisito agrega valor a la empresa, vinculándolo con los objetivos de la empresa y del proyecto.
·
Proporciona un medio para monitorear los requisitos a lo largo del ciclo de vida del proyecto, lo cual ayuda a asegurar que al final del proyecto se entreguen los requisitos aprobados en la documentación de requisitos.
Proporciona una estructura para gestionar los cambios al alcance del producto.
Este proceso incluye rastrear, entre otros elementos:
· · · · · · ·
Los requisitos con respecto a las necesidades, metas y objetivos de la empresa. Los requisitos con respecto a los objetivos del proyecto. Los requisitos con respecto al alcance del proyecto/a los entregables de la EDT. Los requisitos con respecto al diseño del producto. Los requisitos con respecto al desarrollo del producto. Los requisitos con respecto a la estrategia y los escenarios de prueba. Los requisitos de alto nivel con respecto a los requisitos más detallados.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice En la matriz de rastreabilidad de requisitos pueden registrarse los atributos asociados con cada requisito. Estos atributos ayudan a definir la información clave acerca de cada requisito. Los atributos que se utilizan habitualmente en la matriz de rastreabilidad de requisitos, pueden incluir: un identificador único, una descripción textual del requisito, el fundamento de su incorporación, el responsable, la fuente, la prioridad, la versión, el estado actual (tales como vigente, cancelado, diferido, agregado, aprobado) y la fecha de término. Además, para cerciorarse de que el requisito ha satisfecho a los interesados, pueden incluirse otros atributos, tales como estabilidad, complejidad y criterios de aceptación.
495
DOC Nº 007 Enunciación del alcance del proyecto
(Project scope statement) La enunciación del alcance es el documento que define el proyecto y será la base para la toma de decisiones del proyecto. Es un documento dinámico, creado en el principio de la fase de planificación del proyecto y que evolucionará junto con el proyecto durante su ejecución. Más que nada, es un documento que busca determinar los límites de alcance del proyecto. Uno de los factores de fracaso son los añadidos no planificados en un proyecto. Estos añadidos, poco a poco van rompiendo con los presupuestos y los plazos estimados, llevando al proyecto a una gestión incontrolable ya que todos los costes, plazos y recursos son asumidos en función del alcance establecido. Este documento debe contener las siguientes informaciones a continuación:
·
Acta de constitución del proyecto: Descrito en el doc nº 001.
·
Interesados: Individuos y/u organizaciones que están involucrados en el proyecto, tienen intereses en su desarrollo y poseen diferentes necesidades y expectativas.
·
Objetivo del proyecto: El objetivo del proyecto consiste en los beneficios que la organización pretende alcanzar como resultado de la inversión realizada para su desarrollo. Los objetivos del proyecto pueden ser desglosados en tres categorías: 1: Objetivo principal: la razón por la cual el proyecto es puesto en marcha; 2: Objetivos añadidos: son los objetivos logrados a través de los efectos provocados por el objetivo principal, y 3: Objetivos no esperados: son aquellos objetivos logrados que no estaban previstos por la organización.
·
Requisitos del producto y/o servicio: De forma general, se define requisitos como “los intereses documentados del cliente”. Este concepto es ampliamente detallado en la sección 5.1.
·
Entregables: Producto o servicio resultante del trabajo realizado durante una determina fase, como por ejemplo, la colocación del piso en una obra es el resultado de una de las fases de construcción de un edificio. Véase también sección 2.4.
·
Hitos: Tarea de duración cero que simboliza el haber conseguido un logro importante en el proyecto o la finalización de una fase.
·
Costes estimados: Ampliamente detallado en la sección 7.1. Además, no podrán faltar
los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
496
La enunciación del alcance del proyecto es un documento que forma de parte del contrato establecido entre la organización contratante y el proveedor. Es un documento que formaliza los términos y condiciones en que un producto o servicio que será generado y debe ser suficiente detallado para que sea posible posteriormente, confeccionar una EDT de forma en que se pueden identificar y cualificar las entradas, recursos, actividades, informaciones y los resultados generados, bajo condiciones contractuales y criterios de aceptación, según ilustra la figura a continuación.
Figura 198: Detalle de una actividad en la EDT
497
DOC Nº 008 Estructura detallada del trabajo - EDT
(Work breakdown structure – WBS) Es una de los documentos más utilizados en Project Management. Es sencilla y fácil de utilizar. Comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto. Cerca del 95% de las actividades de un proyecto puede ser identificado a través de esta herramienta. Además, sirve tanto para proyectos grandes como para pequeños. En pocas palabras, una EDT es un desglose gráfico y estructurado de las actividades que forman parte de un proyecto y debe tener un aspecto similar a la figura abajo:
Figura 199: EDT de una pintura de un dormitorio
498
Una EDT desarrollada correctamente necesita incluir, por lo menos, los siguientes elementos:
·
Código de cuentas: Sistema numérico utilizado para identificar los elementos de la EDT.
·
Plan de cuentas: Es un sistema numérico financiero utilizado para identificar cada elemento de la Estructura Detallada de Trabajo y para monitorizar los costes del proyecto por categoría (por ejemplo, mano de obra, materiales, maquinaria...). El plan de cuentas es confeccionado de acuerdo con el plan de cuentas “maestro” desarrollado por la organización y que contiene las principales actividades de todos los proyectos desarrollados por la empresa.
·
Paquetes de trabajo: Es el entregable que se encuentra en el último nivel del árbol jerárquico de la EDT.
·
Diccionario de la EDT: Contiene la descripción detallada de los componentes que forman parte de cada actividad y cómo ellos serán desarrollados. Véase también doc nº 009.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice. La sección 5.3 dedica una cantidad importante de información al respecto del desarrollo de la EDT.
499
DOC Nº 009 Diccionario de la EDT
(WBS dictionary) Una vez definido el alcance de la EDT, es necesario conocer los plazos, costes y los recursos necesarios para llevar a cabo las actividades establecidas. Para ello, se consulta el diccionario de la EDT, que contendrá la descripción detallada cada uno de estas actividades. Su finalidad principal es la de documentar las características de cada elemento de la EDT y proporcional un entendimiento uniforme para todos los interesados del proyecto. El diccionario de la EDT debe ser constantemente actualizado puesto que algunas actividades pueden sufrir cambios en su coste, duraciones y/o cantidad de recursos necesarios. La descripción detallada de cada elemento de la EDT debe contener, por lo menos:
·
Código identificativo del paquete del trabajo: Puede ser preferentemente una palabra y/o, acrónimo que será asignada a un proyecto específico. Se debe tener en cuenta algunas recomendaciones al momento de asignar un nombre, como, por ejemplo: 1. Que sea un nombre corto y fácil de usar, 2. Asignar un nombre único y memorable, 3. Que sea multicultural, y 4. Que sea fácil de pronunciar.
·
Nombre del paquete.
·
Descripción del paquete.
·
Recursos necesarios o asignados.
·
Costes y plazos de ejecución: Cada paquete de trabajo contiene un coste específico y un plazo de ejecución. Estos datos son fundamentales para establecer una fiable previsión de costes y un cronograma realístico para todo el proyecto.
·
Hitos: Tarea de duración cero que simboliza el haber conseguido un logro importante en el proyecto o la finalización de una fase.
·
Relación de paquetes de trabajo o actividades sucesoras y predecesoras: Algunos paquetes de trabajo pueden depender de actividades sucesoras y/o predecesoras que deberán estar contempladas.
·
Entregables: Producto o servicio resultante del trabajo realizado durante una determina fase, como por ejemplo, la colocación del piso en una obra es el resultado de una de las fases de construcción de un edificio.
·
Criterios de aceptación: Determinados condicionantes que implican en la la revisión de los entregables del proyecto que deberán atender a los requisitos establecidos.
·
Fecha de comienzo: Normalmente se asigna la fecha de inicio más temprano, que representa la fecha de inicio más temprana en que se pude iniciar una actividad, basada en el diagrama de red del cronograma del proyecto.
500
•
Fecha de fin: Normalmente, se asigna la fecha de finalización más lejana (FL) que representa la fecha más tardía de finalización de una determinada actividad, sin provocar retrasos en el proyecto.
• Supuestos y restricciones: Los supuestos son factores que son considerados verdaderos
para realizar una planificación o estimación, sin que sea necesario demostrar su fiabilidad. Las restricciones son factores que pueden imponer un límite en el desarrollo de una determinada actividad. Estos dos conceptos son ampliamente detallados en la sección 2.2.1.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice. Un paquete de trabajo podría tener el siguiente aspecto: CODIGO EDT: 1000.2010.564 NOMBRE DEL PAQUETE: Equipo informático ALCANCE: Montar un equipo informático (PC) para el departamento administrativo con todos los componentes, periféricos y placas necesarios para el desarrollo de las actividades propias del departamento supracitado. RESPONSABLE: Juan Ricardo Costa, Departamento Técnico DESCRIPCIÓN DE ACTIVIDADES
1. 2. 3. 4. 1.
Instalación de Placa base
5. 6.
Cableado
Instalación de Memoria Instalación de Placas auxiliares (sonido, vídeo y comunicaciones) Instalación de Software (sistema operativo y herramientas ofimáticas) Instalación de Periféricos (teclado, ratón, altavoces e impresora)
Pruebas de funcionamiento
RECURSOS NECESARIOS: 1 técnico informático, hardware y software según lo descrito en las actividades del paquete. COSTE ESTIMADO: 2.000 euros Figura 200: Diccionario de la EDT
501
DOC Nº 010 Lista de actividades
(Activity list) La lista de actividades es una lista exhaustiva que abarca todas las actividades del cronograma necesarias para el proyecto. La lista de actividades incluye el identificador de la actividad y una descripción del alcance del trabajo para cada actividad, con el nivel de detalle suficiente para que los miembros del equipo del proyecto comprendan el trabajo que deben realizar.
DOC Nº 011 Atributos de la actividad
(Activity attributes) Los atributos de la actividad amplían la descripción de la actividad, identificando los múltiples componentes relacionados con cada una de ellas. Los componentes de cada actividad evolucionan con el tiempo. Durante las etapas iniciales del proyecto, estos atributos incluyen:
· · ·
El identificador de la actividad. El identificador de la EDT. El nombre de la actividad.
Una vez term inado, pueden incluir:
· · · · · · · · ·
Los códigos de la actividad. La descripción de la actividad. Las actividades predecesoras. Las actividades sucesoras. Las relaciones lógicas. Los adelantos y los retrasos. Los requisitos de recursos. Las fechas impuestas. Las restricciones y los supuestos.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice Los atributos de la actividad pueden usarse para identificar a la persona responsable de ejecutar el trabajo, la zona geográfica o el lugar donde debe realizarse el trabajo y el tipo de actividad, tal como nivel de esfuerzo, esfuerzo discreto y esfuerzo prorrateado. Los atributos de la actividad se utilizan para el desarrollo del cronograma y para seleccionar, ordenar y clasificar las actividades del cronograma planificadas de diferentes maneras dentro delos informes. La cantidad de atributos varía según el área de aplicación.
502
DOC Nº 012 Requisitos de recursos de la actividad
(Activity resource requirements) Este documento identifica los tipos y la cantidad de recursos necesarios para cada actividad de un paquete de trabajo. Estos El nivel de detalle y especificidad de las descripciones de los requisitos de recursos puede variar según el área de aplicación. La documentación de los requisitos de recursos para cada actividad puede incluir la base de la estimación de cada recurso, así como los supuestos considerados al determinar los tipos de recursos que se aplican, su disponibilidad y en qué cantidad se utilizan. Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
DOC Nº 013 Estructura de desglose de recursos
(Resource breakdown structure) La estructura de desglose de recursos es una estructura jerárquica de los recursos, identificados por categoría y tipo de recurso. Algunos ejemplos de categorías de recursos son:
· · · ·
La mano de obra. El material. Los equipos. Los suministros.
Los tipos de recursos pueden incluir:
· · ·
El nivel de habilidad. El nivel de formación. Cualquier otra información apropiada para el proyecto.
La estructura de desglose de recursos es útil para organizar y comunicar los datos del cronograma del proyecto, incluyendo la información sobre la utilización de recursos.
503
DOC Nº 014 Cronograma del proyecto
(Project schedule) En gestión de proyectos, un cronograma consiste en una lista de los elementos de un proyecto con sus fechas previstas de comienzo y final. Una de las metodologías más utilizadas en la confección de un cronograma es el uso de los diagramas de Gantt (véase también sesión 6.5.1.8), que ofrecen la creación de listas de tareas, la asignación de recursos y precedencias. Los datos para el cronograma del proyecto abarcan, por lo menos:
· · · · · · · · ·
Calendario de recursos. Lista de actividades. Duración de las actividades. Los atributos de las actividades. Diagrama de red. Recursos asignados. Porcentaje de trabajo realizado. Los hitos del cronograma. La documentación de todos los supuestos y restricciones identificados.
La cantidad de datos adicionales varía según el área de aplicación. La información suministrada frecuentemente como detalles de soporte incluye, entre otras:
·
Los requisitos de recursos por periodo de tiempo, a menudo presentados en el formato de un histograma de recursos.
·
Los cronogramas alternativos, tales como el mejor o el peor escenario, sin nivelación de recursos, con nivelación de recursos, con o sin fechas impuestas.
·
La planificación de las reservas para contingencias.
·
Los datos del cronograma también podrían abarcar elementos tales como histogramas de recursos, proyecciones del flujo de caja y cronogramas de pedidos y entregas.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
504
Figura 201: Cronograma
DOC Nº 015 Base de las estimaciones
(Base of estimates) La cantidad y el tipo de detalles adicionales que respaldan la estimación de costes varían según el área de aplicación. Independientemente del nivel de detalle, la documentación de respaldo debe proporcionar una comprensión clara y completa de la forma en que se obtuvo la estimación de costes. Los detalles de respaldo para las estimaciones de costes de las actividades pueden incluir:
·
Documentación de los fundamentos de las estimaciones (es decir, cómo fueron desarrolladas).
·
Documentación de todos los supuestos utilizados.
·
Documentación de todas las restricciones conocidas.
·
Indicación del rango de estimados posibles (por ejemplo, $10.000 (±10%) para indicar que se espera que el coste del elemento se encuentre dentro de este rango de valores).
·
Indicación del nivel de confiabilidad del estimado final. Además, no podrán faltar los
“puntos imprescindibles” descritos en el comienzo de este Apéndice.
505
DOC Nº 016 Plan de gestión de calidad
(Quality management plan) La calidad es un concepto muy subjetivo, puesto que cada persona posee grados distintos de valores y expectativas. Lo que puede tener mucha calidad para una persona, puede tener poca o casi ninguna para otra. Por esta razón, es fundamental entender lo que necesita el cliente (sus requisitos), en la fase inicial del proyecto, para poder asegurar que el producto y/o servicio que le será entregado, tras finalizar un proyecto, atenderá a sus expectativas, y consecuentemente, poseerá el nivel de calidad esperado. El plan de gestión de la calidad puede ser definido como un documento que contiene una serie de actividades planificadas desde en el inicio del proyecto que intentarán asegurar que el proyecto logre el nivel de calidad deseado. El plan de gestión de la calidad, por lo tanto, identificará cuales son los estándares relevantes de calidad para el proyecto y determinará como ellos podrán ser satisfechos. Incluye sobre todo la implantación de determinadas gestiones (revisiones, checklists, etc.), utilizando una serie de técnicas (descritas en el capítulo 8). Este documento debe contener, por lo menos, la siguiente información:
·
Responsabilidad de gestión: Describe las responsabilidades referentes a calidad por parte de los interesados.
·
Sistema de gestión de la calidad: Se refiere al uso de los procedimientos de calidad existentes en la organización.
·
Sistema de control de cambios: Se refiere a los procedimientos de gestión de cambios del proyecto.
·
Control de documentos: Se refiere al proceso de control de la documentación generada a lo largo del ciclo de vida del proyecto.
·
Compras: Define los requisitos de calidad necesarios para la subcontratación de terceros.
·
Inspecciones: A través de mediciones y verificaciones, se determinarán si los servicios o productos entregados cumplen con los requisitos establecidos en el plan de proyecto.
·
No conformidades: Hecho que define como “el incumplimiento de un requisito asociado a un uso previsto o especificado”.
·
Acciones correctivas: Medida o un conjunto de medidas que se ponen en macha para eliminar o subsanar algo que no ha salido según lo previsto.
·
Métricas de calidad: Describe los procedimientos necesarios para mantener las métricas de calidad de los proyecto (variaciones, checklists, verificaciones...) Véase también doc nº 017.
·
Auditorias de calidad: Que permitan evaluar el grado de cumplimiento de los requisitos definidos en el manual de la calidad, en el manual de procedimientos y en la norma adoptada, para detectar aquellas áreas o actividades que no cumplen los criterios
506
establecidos.
507
DOC Nº 017 Métricas de calidad
(Quality metrics) Una métrica de calidad es una definición operativa que describe, en términos muy específicos, un atributo del producto o del proyecto, y la manera en que el proceso de control de calidad lo medirá. Una medición es un valor real. La tolerancia define la variación permisible de las métricas. Por ejemplo, una métrica relacionada con el objetivo de calidad de mantenerse dentro del límite de ± diez por ciento del presupuesto aprobado puede consistir en medir el coste de cada entregable y determinar el porcentaje de desviación con respecto al presupuesto aprobado para ese entregable. Las métricas de calidad se emplean en los procesos de aseguramiento de la calidad y de control de calidad. Algunos ejemplos de métricas de calidad incluyen el índice de puntualidad, el control del presupuesto, la frecuencia de defectos, el índice de fallos, la disponibilidad, la fiabilidad y la cobertura de las pruebas.
DOC Nº 018 Listas de control de calidad
(Quality checklists) Una lista de control es una herramienta estructurada, por lo general específica de cada componente, que se utiliza para verificar que se haya realizado una serie de pasos necesarios. En función de los requisitos y prácticas del proyecto, las listas de control pueden ser simples o complejas. Muchas organizaciones tienen disponibles listas de control normalizadas para asegurar la uniformidad en tareas que se realizan frecuentemente. En algunas áreas de aplicación, también existen listas de control disponibles provenientes de asociaciones profesionales o de proveedores de servicios comerciales. Las listas de control de calidad se emplean en el proceso de control de calidad.
DOC Nº 019 Plan de mejoras del proceso
(Process improvement plan) El plan de mejoras del proceso detalla los pasos para analizar los procesos que facilitarán la identificación de actividades que incrementan su valor. Las áreas por considerar incluyen:
·
Límites del proceso: Describen la finalidad de los procesos, su inicio y finalización, sus entradas y salidas, los datos requeridos, el propietario y los interesados.
·
Configuración del proceso: Una descripción gráfica de los procesos, con las interfaces identificadas, que se utiliza para facilitar el análisis.
·
Métricas del proceso: Junto con los límites de control, permiten analizar la eficacia del proceso.
·
Objetivos de desempeño mejorado: Guían las actividades de mejora del proceso.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
508
DOC Nº 020 Plan de gestión de riesgos
(Risk management plan) Puesto que todos los proyectos tienen algún grado de riesgo, el plan de gestión de riesgos es fundamental para definir los procedimientos que serán puestos en marcha para gestionar los riesgos durante el desarrollo del proyecto. El objetivo del plan de gestión de riesgos es definir cuales son los riesgos o potenciales resultados no deseados del proyecto y determinar estrategias y acciones que posibiliten la respuesta adecuada y eficaz para evitarlos, o por lo menos, minimizar su impacto. Este documento debe contener, por lo menos, las siguientes informaciones a continuación:
·
Metodología: Define los métodos se van a utilizar y que fuentes de información de datos se emplearan para la gestión. Como metodología se sugiere seguir los procesos del PMBOK®, definidos en el capítulo 11 – Gestión de riesgos.
·
Roles y responsabilidades: Define el líder, el apoyo y los miembros del equipo de gestión de riesgos para cada tipo de actividad del plan de gestión de riesgos, asigna personas a estos roles y explica sus responsabilidades.
·
Preparación del presupuesto: Asigna recursos y estima los costes necesarios para la gestión de riesgos a fin de incluirlos en la línea base de coste del proyecto.
·
Periodicidad: Define cuándo y con qué frecuencia se realizará el proceso de gestión de riesgos durante el ciclo de vida del proyecto, y establece las actividades de gestión de riesgos que se incluirán en el cronograma del proyecto.
·
Categorías de riesgo: Para poder identificar los riesgos en una forma estructurada se puede crear una Estructura de Desglose de riesgos (EDR). Véase también sección 11.2.1. 15.
·
Matriz de la probabilidad y el impacto: Los riesgos se priorizan según sus posibles implicaciones para lograr los objetivos del proyecto. Véase también sección 11.3.1.1.
·
Tolerancias revisadas de los interesados: Las tolerancias de los interesados pueden revisarse en el proceso planificación de la gestión de riesgos, ya que se aplican al proyecto específico.
·
Formatos de informe: Describe el contenido y el formato del registro de riesgos, así como de cualquier otro informe de riesgos que se requiera. Define cómo se documentarán, analizarán y comunicarán los resultados de los procesos de gestión de riesgos.
·
Seguimiento: Documenta cómo todas las facetas de las actividades de riesgo serán registradas para beneficio del proyecto actual, para futuras necesidades y para las lecciones aprendidas. Documenta si serán auditados los procesos de gestión de riesgos y cómo se realizaría dicha auditoría.
509
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
510
DOC Nº 021 Registro de riesgos
(Risk register) El listado de riesgos es un documento utilizado para identificar todas las condiciones o eventos que puedan poner en peligro en buen desarrollo de un proyecto. Cada una de las condiciones encontradas será clasificada en función de su grado de severidad, probabilidad de ocurrencia o posibles impactos. Además, se podrá incluir el tipo de acciones preventivas para cada caso. Hay muchas maneras de organizar y presentar este documento, de todas formas, este documento debería contener por lo menos las siguientes informaciones:
• · · · · · ·
Riesgo. Tipos de riesgo. Impactos y probabilidades. Acción requerida. Responsable. Fecha última revisión. Estado actual.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
DOC Nº 022 Plan de gestión de los recursos humanos
(Human resources management plan) El plan de gestión de los recursos humanos constituye un factor de extrema importancia, pues determina las principales necesidades de del proyecto en lo que se refiere a la capacitación del equipo del proyecto y/o eventuales colaboradores de empresas externas. Dicha capacitación permitirá que los involucrados brinden el mejor de sus aportes en sus funciones y obligaciones, buscando lograr con eficiencia y rentabilidad los objetivos del proyecto. Además, el plan de proyecto definirá horarios, medidas de seguridad y sistemas de reconocimiento y recompensas.
· · · · · · · · ·
Organigrama del proyecto. Roles y responsabilidades. Cómo se llevará a cabo la adquisición de personal. Horario laboral, festivos nacionales y locales y vacaciones. Criterios de liberación. Necesidades de formación. Reconocimientos y recompensas. Cumplimiento. Seguridad y prevención de riesgos.
511
·
Cómo y cuando se llevarán las actividades de desarrollo del equipo de proyecto.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
512
DOC Nº 023 Plan de gestión de las comunicaciones
(Communication management plan) Comunicarse al principio parece ser muy sencillo. No obstante, es una de las principales causas de fracaso en un proyecto. Un proyecto debe contar siempre con un plan de gestión de comunicaciones, que normalmente nunca es cumplido, y si lo fuera, evitaría muchos de los conflictos que tanto atormentan el Project Manager. El plan de gestión de las comunicaciones trata de estandarizar la información y hacer que con que esta información llegue a las personas ciertas en el momento oportuno. De acuerdo con Eric Verzuh2, los involucrados del proyecto que necesitan recibir información son:
· · · · · ·
El patrocinador. El gerente funcional. El cliente. El equipo del proyecto. El Project Manager. El líder técnico.
Es conocido que un Project Manager dedica el 90% de su tiempo desarrollando labores de comunicación. Por esta razón, se hace necesario desarrollar un plan de gestión de las comunicaciones que establezca principalmente:
La metodología de recogida, tratamiento y almacenamiento de la información (cómo).
·
La distribución a las personas correspondientes en el momento oportuno, como por ejemplo: Informes durante las fechas programadas de entregas parciales del servicio y/o producto del proyecto, actas de las reuniones de seguimiento... (cuándo).
·
El contenido que será comunicado (qué).
·
Quién distribuye y quién envia la información (quién).
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
513
DOC Nº 024 Plan de gestión de las adquisiciones
(Procurement management plan) Este document deberá describer cómo permanecerá la gestión del proceso de adquisiciones desde la fase inicial hata el cierre del contrato. Este plan debería incluir, por lo menos, la siguiente documentación:
·
Los tipos de contratos que serán usados.
·
Quién preparará las estimaciones independientes y si son necesarias como criterios de evaluación.
·
Las acciones que el equipo de dirección del proyecto puede llevar a cabo por sí mismo, si la organización ejecutante tiene un departamento de adquisiciones, contratación o compras.
·
Documentos de adquisición estandarizados, si fueran necesarios.
·
Gestión de múltiples proveedores.
·
Coordinación de las adquisiciones con otros aspectos del proyecto, como establecer el cronograma e informar el rendimiento.
·
Restricciones asunciones que podrían afectar a las compras y adquisiciones planificadas.
·
Manejo de los períodos de adelanto requeridos para comprar o adquirir artículos a los vendedores, y coordinación de los mismos con el desarrollo del cronograma del proyecto.
·
Manejo de las decisiones de fabricación propia o compra y vinculación de las mismas en los procesos de Estimación de Recursos de las Actividades y Desarrollo del Cronograma;
·
Determinación de las fechas planificadas en cada contrato para los productos entregables del contrato y coordinación con los procesos de desarrollo y control del cronograma.
·
Identificación de garantías de cumplimiento o de contratos de seguros para mitigar algunas formas de riesgos del proyecto.
·
Determinación de las instrucciones que se proporcionarán a los vendedores para desarrollar y mantener una estructura de desglose de trabajo del contrato.
·
Determinación de la forma y el formato que se usarán en el enunciado del trabajo del contrato.
·
Identificación de vendedores seleccionados precalificados, si los hubieran, que se utilizarán.
514
·
Métricas de adquisiciones que se usarán para gestionar contratos y evaluar vendedores.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice
515
DOC Nº 025 Plan de contingencia
(Contingency plan) El plan de contingencia es un documento que debe estar listo en la fase de planificación del proyecto, mucho antes del proyecto entrar en la fase de ejecución. Este plan ayudará a planificar y coordinar las acciones adecuada de respuesta en tiempo. En algunos casos, el plan de contingencia podrá incluir más recursos (humanos, financieros, equipos...). El plan de contingencia es el resultado de una estrategia de aceptación activa. Hay muchas maneras de organizar y presentar este documento, de todas formas, este documento debería contener por lo menos las siguientes informaciones:
· · · · · ·
Factores de riesgo. Riesgos asociados. Probabilidad de ocurrencia. Consecuencias de cada riesgo. Estrategia elegida para cada riesgo. Plan de comunicación.
La estrategia utilizada para tratar el riesgo podrá cambiar de acuerdo con en el momento. En una fase determinada del proyecto podrá ser conveniente evitar ciertos riesgos. Sin embargo, en alguna otra fase será más conveniente adoptar una estrategia correcta de aceptación. Independientemente de la estrategia a ser tomada, el plan de contingencia es fundamental. Es importante saber exactamente cual es el momento exacto de poner en marcha el plan de contingencia para evitar el uso indebido de los recursos previstos en el plan. Los riesgos de un proyecto no son solamente los identificados. Quedan todavía los riesgos no identificados, o no conocidos, ya que siempre existirá algún grado de incertidumbre durante todo el desarrollo del proyecto. La gestión de riesgo, por tanto es inevitable en cualquier caso.
516
DOC Nº 026 Plan de gestión del alcance
(Scope management plan) El plan de gestión del alcance establecerá como el alcance del proyecto será definido, comprobado y controlado. Definirá, además, las pautas de desarrollo y aprobación de la enunciación del trabajo (doc nº 029) y de la EDT. Este documento establecerá también el proceso de gestión las eventuales solicitudes de cambios en el alcance, así como sus correspondientes aprobaciones y actualizaciones en el proyecto original. Este documento debe contener, por lo menos, las siguientes informaciones a continuación: · Objetivos del proyecto.
· · · · · · · · · · ·
Alcance del proyecto. EDT (estructura de descomposición del trabajo): véase también sección 5.3. El diccionario de la EDT: Descrito en el doc nº 009. Requisitos del producto y/o servicio. Limitaciones. Entregables; véase sección 2.4. Criterios de aceptación. Restricciones véase sección 2.2.1. Supuestos véase sección 2.2.1. Equipo asignado. Documentación de gestión de control de cambios. Véase sección 4.5.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
517
DOC Nº 027 Plan de gestión de costes
(Cost management plan) El plan de gestión de costes define claramente como los costes de un proyecto serán administrados a través del ciclo de vida del proyecto. El plan establece el formato y las normas por los cuales los costes serán estimados, comunicados y controlados. Su objetivo es:
·
Identicar quién es el responsable de la gestión de costes.
·
Identificar quién tiene la autoridad para aprobar los cambios del proyecto y/o de su presupuesto.
·
Como la performance del cost es medida y comunicada.
·
Informa formatos, frecuencia y para quién serán presentados.
Este documento debe contener, por lo minimo, los siguintes campos:
·
Enfoque en la gestión de costes: Se explica el enfoque de la gestión de costes en el proyecto.
·
Medición de costes del proyecto: Se define como los costes del proyecto serán medidos el PMBOK se centra en el valor del trabajo realizado (véase también sección 7.3.1.1), para medir y controlar los costes de un proyecto.
·
Informe de situación del proyecto: Incluirá una sección denonimada gestión de costes. Esta sección contendrá las métricas de valor del trabajo realizado identificados en la sección anterior. Todas las variaciones de costes fuera de los limites señalados en este plan de gestión de costes se informará sobre la inclusión de las medidas correctoras que se han previsto.
·
Proceso de respuesta a las variaciones de coste: Define los límites de costes y qué acciones correctivas se tomarán si los costes del proyecto salen de los limites establecidos.
·
Control integrado de cambios: Véase sección 4.5.
·
Presupuesto del proyecto. (Véase también doc nº 040) podrá ser desglosado en las siguientes categorias: Costes fijos, costes variables, costes de materiales, costes de proveedores, reserva de gestión...
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice
518
DOC Nº 028 Plan de gestión del cronograma
(Schedule management plan) El cronograma del proyecto es un documento que servirá al Project Manager y a su equipo com una “hoja de ruta” sobre cómo el proyecto será ejecutado. El cronograma es un documento fundamental en el proyecto puesto que proporciona a todos los interesados una imagen del estado real del proyecto en un momento dado. El objetivo del plan de gestión del cronograma es definir el enfoque que el equipo del proyecto utilizará en la creación de la programación del proyeto. Este plan también incluye cómo el equipo va a supervisar y gestionar los cambios después de que la línea de base del cronograma haya sido aprobada. La gestión de cambios (veáse también sección 4.5), incluye: identificar, analizar, documentar, priorizar, aprobar o rechazar (además de comunicar), todos los cambios relacionados con el cronograma. Este documento debe incluir, además los siguientes campos:
·
Enfoque en la gestión del cronograma: Establece un marco general para la planificación que será llevado a cabo para crear el cronograma del proyecto. Incluye las herramientas de estimación de timepos, hitos del cronograma y plan de desarrollo de roles y responsabilidades.
·
Control del cronograma: Se define el modo en que el cronograma del proyecto será controlado. Incluye, además, la frecuencia de las actualizaciones y revisiones del calendario, así como su comunicación y seguimiento de su progreso y correspondientes controles.
·
Cambio del alcance: De vez en cuando, algunos cambios aprobados en el alcance del proyecto pueden provocar una revisión en la linea base. Estos cambios pueden incluir nuevos entregables o requisitos que no estaban anteriormente previstos. En esta situación el Project Manager y su equipo deben observar el cronograma en vigor y como los cambios podrán afectar en los plazos previamente establecidos.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
519
DOC Nº 029 Enunciado del trabajo
(Statement of work - SOW) Un enunciado de trabajo (Statement of Work - SOW) es un documento preparado por el Project Manager para describir a un proveedor qué trabajo se le está encargando. Es el documento utilizado para clarificar detalladamente cuales son los esfuerzos necesarios para los productos o servicios que serán suministrados por el proyecto, estableciendo los criterios de medición de los resultados obtenidos. Cuando el cliente y el equipo del proyecto pertenecen a la misma empresa, el SOW será el único acuerdo formal entre ambas partes. Cuando el cliente y el equipo del proyecto pertenecen dos empresas diferentes, deberá existir un contrato entre las partes, donde el SOW podrá ser un anexo de dicho contrato. Este documento debe contener, además de la información presentada en el punto 0.0, las siguientes informaciones a continuación:
·
Objetivos generales: Describe, de forma breve, los objetivos que el proyecto pretende alcanzar.
·
Alcance del trabajo: Describe detalladamente las actividades que serán realizadas, acorde con la EDT establecida.
·
Trabajo: Describe los locales donde serán realizadas las actividades, sus duraciones e recursos necesarios.
·
Plazos: Normalmente, se estiman las fechas más optimistas, como si todos los recursos estuviesen disponibles en tiempo integral. Una vez hecha está estimación orientativa, se parte para una estimación más realista, basado en la disponibilidad real de los recursos en la empresa.
·
Fecha de entrega(s): Para poder lograr el cumplimiento del calendario establecido, es importante considerar festivos, horarios especiales, y sobre todo la disponibilidad de los recursos asignados, esta última muchas veces es la razón por la cual muchos proyectos no finalizan en el plazo estimado.
·
Estándares utilizados: Describe los estándares específicos que serán utilizados para el desarrollo de determinadas actividades.
·
Criterios de aceptación: Determinados condicionantes que implican en la revisión de los entregables del proyecto que deberán atender a los requisitos establecidos.
·
Requisitos especiales: Describe cualquier tipo especial de componente, material, manode-obra o procedimiento necesario para cubrir correctamente los requisitos establecidos por la empresa contratante.
·
Tipo de contrato / fechas de pago(s): Describe el tipo de contracto establecido y la programación de fechas para la realización de los pagos correspondientes.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
520
Ambas partes deberán estar de acuerdo con los las condiciones establecidas en este documento antes del proyecto ser puesto en marcha. No obstante, en proyectos muy largos, algunos compromisos asumidos podrán ser negociados, de acuerdo con la evolución del proyecto. Si acaso existir la necesidad de cambiar o actualizar cualquiera que los acuerdos establecidos en este documento, será necesario evaluar los efectos de estos cambios en el SOW original y a continuación se propondrá los cambios necesarios para el proyecto. Las nuevas condiciones tendrán que ser aceptadas por el cliente y contempladas en un nuevo SOW.
DOC Nº 030 Solicitud de información
(Request for information – RFI) Este documento es utilizado para recoger información preliminar acerca de potenciales proveedores que pueden ofrecen sus servicios o productos necesarios para el proyecto, y sus capacidades. En este documento, las empresas interesadas en formar parte del proyecto deben proporcionar informaciones acerca de sus áreas de actuación, sus productos y servicios, si tienen certificados de calidad, y en algunos casos se les exige referencias de sus clientes. Con las informaciones obtenidas, la empresa contratante podrá realizar las comparaciones y valoraciones necesarias para decidir por la empresa más adecuada. Estas informaciones serán posteriormente almacenadas en la base de datos de la empresa contratante para futuras consultas. Este documento debe contener, por lo menos, las siguientes informaciones a continuación:
· · · · · · · · · ·
Datos de la empresa. Fecha de creación de la empresa. Tamaño y plantilla. Clientes atendidos. Experiencia en el sector. Razones por el interés en la participación en este proyecto. Breve descripción acerca de la experiencia en proyectos similares anteriores. Catálogo de productos y servicios. Plazo estimado de entrega. Certificados de calidad.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice. Una vez recogida toda la información enviada por los potenciales proveedores del proyecto, se comparan los datos recibidos, y se seleccionan los proveedores que mejor corresponden a las expectativas del proyecto. A los proveedores seleccionados, se les enviará una “solicitud de cotización”, que es el siguiente proceso que veremos a continuación.
521
DOC Nº 031 Solicitud de cotización
(Request for quotation – RFQ) La solicitud de cotización es muy similar a la “solicitud de información”, la diferencia fundamental es que en la solicitud de cotización se solicita a los eventuales proveedores los precios y tarifas que serán cobradas para desarrollar la parte que le corresponda en el proyecto, además de las formas y condiciones de pago. Para recibir las cotizaciones de forma correcta, se incluye la información específica de los artículos o servicios contratados para asegurarse que los proveedores ofrecerán exactamente el artículo o servicio demandado para el proyecto. Cuanto mejor detallado estén los requisitos de esta solicitud, más exactas serán las cotizaciones. Otra razón que exige la correcta redacción de una RFQ bien detallada, es que en muchos casos este documento podrá servir como un instrumento legal, por si en el futuro se pueda producir algún tipo de desacuerdo o disputa. Los proveedores deberán responder a esta solicitud dentro de los plazos asignados y lógicamente, las condiciones ofrecidas, podrán ser negociadas más adelante en un documento llamado “invitación para negociar” (doc nº 033).
DOC Nº 032 Solicitud de propuesta
(Request for proposal – RFP) La solicitud de propuesta es el siguiente paso realizado, tras completar la fase de solicitud de cotización, en el proceso de contratación de terceros para un proyecto. La solicitud de propuesta demanda una cantidad de información bastante más amplia que permitirá a la empresa contratante evaluar las ventajas y desventajas resultantes de la contratación de un determinado proveedor. Este documento también podrá exponer sus debilidades y fortalezas. Las RFP es documento vital para la administración del proyecto, ya que definirá claramente los entregables asociados con el proyecto y el marco de acción para la ejecución del mismo. Asimismo, una RFP deberá estipular los requisitos de la empresa que está comprando y las condiciones bajo las cuales contrataría, por lo que un RFP debe contener:
· · · · · · ·
Especificación del producto o servicio requerido, con el mayor detalle posible. Información general como las personas que liderarán el proyecto. Un cronograma orientativo. Criterios para selección o descalificación de proponentes. Fechas relevantes, incluyendo las de apertura y cierre del proceso. Cualquier requerimiento de confidencialidad. Elementos legales de la posible contratación;
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
522
DOC Nº 033 Invitación a negociar
(Invitation for negotiation - IFN) Una vez que el proveedor es finalmente seleccionado, tras superar los requisitos anteriormente descritos, cabrá a la empresa contratante negociar unas pautas preliminares a través de un documento conocido como “carta de intenciones”, que supone simples conversaciones personales, redacción de minutas, ofertas y contraofertas en las que las partes implicadas no demuestran su intención de obligarse recíprocamente, sino que de lo único que dejan constancia es de hacer ver la posibilidad de llegar a contratar en el futuro. Acorde con el artículo publicado por el Foro Legal - Abogados Asesores de Barcelona, llamado Carta de intenciones: su diferencia con el precontrato y el contrato definitivo, una Carta de intenciones o cualquier trato preliminar similar, supone el inicio del iter contractual, o de la formación progresiva del contrato, durante el cual las partes no quedan obligadas ni vinculadas jurídicamente en forma alguna, a menos que se aprecie una evidente mala fe. Es cierto que en ocasiones puede llegar a ser difícil establecer la línea divisoria entre lo que son meros tratos preliminares o acuerdos de intenciones, con lo que en una segunda fase la doctrina denomina precontrato. En aquellos son solo esbozos, insinuaciones y manifestaciones de voluntad hacia un fin común, mientras que el precontrato viene caracterizado por la concreción de unos elementos suficientemente determinantes para la constitución de un contrato definitivo, a la espera exclusivamente de la aceptación de la otra parte, sin necesidad de que se requieran nuevas negociaciones para la última eficacia de lo pre-acordado. Se pueden así distinguir perfectamente sucesivas facetas en las que a veces una de las partes (ofertante) avanza en una dirección y posteriormente retrocede en otra, para desde ese estadio ser impulsada de nuevo en otra dirección por la otra parte (que había sido primitiva acreedora de aquella oferta y que ahora se convierte en nuevo ofertante), cuya propuesta es a su vez revisada y vuelta a plantear en forma distinta, y así sucesivamente, tratando de buscar de este modo el equilibrio de las prestaciones que determinará la configuración definitiva del contrato deseado.
DOC Nº 034 Contrato
(Contract) El contrato es un acto jurídico bilateral o multilateral en que pueden intervenir dos o más partes, sean físicas o jurídicas. Este documento tiene por finalidad identificar dichas partes, estableciéndoles sus derechos y obligaciones. El PMBOK®, trata única y exclusivamente de los contratos que se refieren a la gestión de compras, y por ello, su definición de contrato se limita exclusivamente a una relación cliente-proveedor. De esta forma, según el PMBOK® un contrato es “un acuerdo mutuo que obliga al vendedor a proveer un producto especifico y obliga el comprador al pagar por él”. El Código Civil español, tiene una descripción generalista de contratos como un “convenio o acuerdo mutuo de consentimiento concorde y recíproco que tienen como consecuencia la creación de un vínculo obligatorio con fuerza de ley entre las partes contratantes”. Además, se puede encontrar otras definiciones para los contratos, en el Código Civil:
523
•
En el artículo 1.091 “las obligaciones que nacen de contratos tienen fuerza de ley entre las partes contratantes”.
·
El artículo 1.254 del Código Civil establece perfiles fundamentales de los contratos afirmando que existe un contrato desde que una o varias personas consienten en obligarse respecto de uno u otras.
·
El artículo 1.255 del Código civil faculta a los arrogantes para formar libremente el contenido del contrato. “Los contratantes pueden establecer los pactos, cláusulas y condiciones que tengan por conveniente, siempre que no sean contrarios a las leyes, a la moral ni al orden público”.
No cabe al Project Manager la confección del contrato y sus correspondientes cláusulas ya que normalmente, no está capacitado para ello. Cabe a un abogado o al departamento jurídico de la organización la elaboración de este tipo documento. Sin embargo, el Project Manager desarrollará la función de administrador del contrato, una vez que, durante el desarrollo del proyecto se establecerán contratos con proveedores, clientes y subcontratas, por lo tanto, el Project Manager deberá conocer todas las cláusulas incluidas para poder realizar los seguimientos correspondientes y actuar de forma adecuada.
Tipos de contratos Aunque muchas cláusulas son comunes internacionalmente, cada país adopta su propia legislación, con lo cual, se hace necesario adaptar los contratos según lo que marque la ley local. El Código Civil español establece en su artículo 1.261 que “no hay contrato sino cuando concurren los requisitos siguientes: 1°. Consentimiento de los contratantes. 2°. Objeto cierto que sea materia del contrato. 3°. Causa de la obligación que se establezca”. Un contrato debe contener todos los elementos y requisitos de un acto jurídico:
·
Sujetos: Quien concluye un contrato debe ser capaz. Todo sujeto, como parte de su personalidad, tiene la capacidad jurídica. Sin embargo, la capacidad de actuar es el poder que tiene un sujeto de derecho para crear, con una manifestación de voluntad, efectos de derechos. Así, la persona que constituya un contrato debe tener la capacidad de actuar para obligarse según las condiciones estipuladas en el contrato.
Objeto: El objeto puede consistir en una obligación de dar, hacer o de no hacer.
·
Capacidad: La capacidad se subdivide en capacidad de goce (la aptitud jurídica para ser titular de derechos subjetivos, comúnmente denominada también como capacidad jurídica) y capacidad de ejercicio (aptitud jurídica para ejercer derechos y contraer obligaciones sin representación de terceros, denominada también como capacidad de actuar).
·
Consentimiento o voluntad: La voluntad es el querer interno que, manifestado bajo el consentimiento, produce efectos de derecho. Todo contrato exige el libre consentimiento entre las partes que lo forman. El consentimiento se manifiesta por la concurrencia de la oferta y de la aceptación sobre la cosa y la causa que han de constituir el contrato. Será nulo el consentimiento prestado por error, violencia, intimidación o dolo.
524
•
El error: Cuando versa el error, existe una equivocación sobre el objeto del contrato, o sobre alguno de sus aspectos esenciales. El error es motivo de nulidad del contrato cuando recae sobre: o La naturaleza del contrato. o La identidad del objeto. o Las cualidades específicas de la cosa.
El error no debe de ser de mala fe, porque de lo contrario, se convierte en dolo.
·
La fuerza: En la violencia se ejerce una fuerza irresistible que causa un grave temor a una de las partes del contrato, o que una de las partes haya abusado de la debilidad de la otra. La amenaza de acudir ante una autoridad judicial para reclamar un derecho no es coacción, a no ser que se amenace abusivamente de este derecho.
·
El dolo: Todo medio artificioso, contrario a la buena fe, empleado con el propósito de engañar para hacer a una persona consentir un contrato es considerado dolo. La víctima del dolo puede mantener el contrato y reclamar daños y perjuicios.
·
El objeto: Pueden ser objeto de contratos todas las cosas que no están fuera del comercio humano, aun las futuras. Pueden ser igualmente objeto de contrato todos los servicios que no sean contrarios a las leyes o a las buenas costumbres.
·
Causa: Normalmente, la normativa civil de los ordenamientos jurídicos exige que haya una causa justa para el nacimiento de los actos jurídicos. La causa es el motivo determinante que llevó a las partes a celebrar el contrato. Un contrato no tiene causa cuando las manifestaciones de voluntad no se corresponden con la función social que debe cumplir, tampoco cuando se simula o se finge una causa. El contrato debe tener causa y esta ha de ser existente, verdadera y lícita.
·
Forma: La forma es el conjunto de signos mediante los cuales se manifiesta el consentimiento de las partes en la celebración de un contrato. En algunos contratos es posible que se exija una forma específica de celebración. Por ejemplo, puede ser necesaria la forma escrita, la firma ante notario o ante testigos, entre otras.
·
Elementos accidentales: Son aquellos que las partes establecen por cláusulas especiales, que no sean contrarias a la ley, la moral, las buenas costumbres o el orden público. Por ejemplo: el plazo, la condición, el modo, la solidaridad, la indivisibilidad, la representación...
En consonancia con la autonomía de la voluntad, los contratantes pueden establecer los pactos, cláusulas y condiciones que tengan por convenientes, siempre que no sean contrarios a la ley, la moral, las buenas costumbres o el orden público.
525
Estructura de un contrato escrito La libertad formal suele caracterizar casi todos los tipos de contratos aunque la mayoría siguen modelos bastante parecidos con las siguientes partes:
·
Título: Indica el tipo de contrato.
·
Cuerpo sustantivo: Que identifica en las partes. Estas pueden ser, según el tipo de contrato, tanto personas físicas como jurídicas. Consta de las siguientes partes: Lugar y fecha de contrato.
· · · · · ·
Identificación de quienes van a suscribirlo. Representaciones de los intervinientes indicando si suscriben el contrato en su propio nombre o en representación de un tercero o sociedad. Identificación, si son aplicables, de los objetos y servicios objeto del contrato. Identificación, si son aplicables, de otros elementos como ámbito geográfico. Exposición: Relacionan los hechos y antecedentes que pueden ser relevantes pero que carecen de valor normativo.
También pueden incluir cláusulas que establezcan el significado de determinados conceptos para el contrato en cuestión:
· · ·
Cuerpo normativo: Pactos o acuerdos objeto del contrato. Son las cláusulas normativas. Cierre: Fórmula de cierre donde se indica la forma de realizar el acuerdo. Anexos: Desarrollan algunos aspectos complejos del contrato para simplificar su lectura.
De acuerdo con el PMBOK®, se utilizan básicamente tres tipos de contratos, muy comunes en el mundo laboral internacional y que son convenientes acorde con el tipo de proyecto o de mano de obra que será contratada. Las características y aplicación de estos contratos podrán ser analizadas a continuación:
526
DOC Nº 035 Contrato de precio fijo
(Fixed-price contract) En este contrato se paga al contratado un valor fijo total para la realización de un servicio o fabricación de un producto claramente definido. La exacta definición del producto o servicio es importante para ambas partes, una vez que el comprador tiene el riesgo de no recibir el producto o servicio exactamente como lo esperaba recibir, o el vendedor puede incurrir en costes añadidos para poder realizar el producto o servicio ofertado. Para mitigar este tipo de problemas, los pagos en este contrato pueden darse por ejemplo, mensualmente, o de acuerdo con la entrega de cada ítem contratado. Este tipo de contrato puede establecer incentivos para alcanzar los objetivos antes de las fechas previstas, o al contrario, pueden establecer multas por eventuales atrasos. Pueden presentar las siguientes variaciones:
·
Precio fijo o suma global (Fixed-price or lump-sum - FP): Definición del PMBOK® “Tipo de contrato que implica un precio total fijo para un producto claramente definido”. La forma más simple de un contrato de precio fijo es una orden de compra”.
·
Precio fijo más honorarios con incentivos (Fixed-price with incentives - FPI): Definición del PMBOK® “Tipo de contrato en el cual el comprador paga al vendedor un monto establecido (conforme lo defina el contrato), y el vendedor puede ganar un monto adicional si cumple con los criterios de rendimiento establecidos”.
·
Precio fijo con ajuste económico (Fixed price with economic price adjustment FPEA): Es un tipo de contrato que prevé una revisión de las cuotas de pago hacia arriba o hacia abajo en las tarifas originalmente establecidas en función de eventuales escenarios que pueden producirse durante el desarrollo del servicio contratado, como por ejemplo, la caída o la subida del precio de un determinado material utilizado en el proyecto. Por su característica singular, es un contrato utilizado, normalmente, en proyectos que consumen una cantidad importante de comoddities (cobre, petróleo, caucho...).
·
Precio fijo determinable (Fixed price redeterminable - FPR): Es un tipo de contrato que contiene una acción “prospectiva” o “retroactiva”. Podrá tener un carácter prospectivo cuando se establece un precio de contratación para un determinado periodo de corta duración, cuyas tarifas de los periodos subsiguientes serán revisadas una vez que finalice el primer periodo previamente establecido. Por otro lado, este contrato tendrá un carácter retroactivo cuando no sea posible negociar o establecer un precio favorable para las partes involucradas y por esta razón, se preestablece un precio máximo acordado que será ajustado una vez que finalice la duración del contrato.
·
Precio fijo con ajuste ecónomico (Fixed price with economic price adjustment – FPEA)
527
DOC Nº 036 Contrato de precio variable
(Variable price contract) Es tipo de contrato se paga al contratado un valor variable en función del trabajo realizado o del escenario económico actual. Este tipo de contrato incluye algunas ventajas importantes para la parte contratante, como, por ejemplo, poder contratar el proveedor más cualificado, en vez del más barato o la posibilidad de pode ofrecer incentivos para completar el trabajo rápido y con el menor coste. El contrato de precio variable puede presentar las siguientes variaciones:
·
Coste más cuota fija - (Cost plus fixed fee - CPFF): Definición del PMBOK® “Tipo de contrato de costes reembolsables en el que el comprador reembolsa al vendedor los costes permitidos correspondientes al vendedor (según se define costes permitidos en el contrato) más una cantidad fija de ganancias (pago fijo). También conocido como: contrato de coste más honorarios fijos”.
·
Coste más incentivos - (Cost plus incentive fee - CPIF): Definición del PMBOK ® “Tipo de contrato de costes reembolsables en el que el comprador reembolsa al vendedor los costes permitidos correspondientes al vendedor (según se define costes permitidos en el contrato) y el vendedor obtiene sus ganancias si cumple los criterios de rendimiento definidos”.
·
Coste más Cuota Premio (Cost Plus Award Fee - CPAF): Es un tipo de contrato que contempla el pago de un premio financiero en función de la excedente calidad del servicio o producto ofertado. También se puede premiar la eficiencia del proveedor en la gestión de los costes, plazos y recursos del proyecto.
·
Coste más porcentaje del Coste - (Cost Plus Percentage of Cost - CPPC): Definición del PMBOK® “Tipo de contrato que al vendedor se le reembolsan los costes permitidos por realizar el trabajo del contrato y recibe un honorario calculado como un porcentaje de los costes previamente acordado”.
528
DOC Nº 037 Contrato a tiempo y material
(Time & material contract) Es un tipo de contrato no tiene un final claramente definido, porque el valor total del contrato no se define en el momento de su adjudicación. Por esta razón, los contratos te tipo “tiempo y material” pueden crecer en valor contractual como si fueran acuerdos del tipo de costes reembolsables. Por otro lado, esta modalidad contractual también se asemeja a los contratos de precio fijo. El comprador y el vendedor establecen por anticipado las tarifas unitarias por trabajo realizado (por ejemplo: 20 euros por hora de servicios profesionales o 50 euros por tonelada cúbica de tierra removida). El valor final del contrato es la suma total de las cantidades necesarias para completar el trabajo.
DOC Nº 038 Criterios de selección de proveedores
(Source selection criteria) Los criterios de selección se incluyen a menudo como parte de los documentos de solicitud de adquisiciones. Dichos criterios se desarrollan y utilizan para calificar o evaluar las propuestas de los vendedores y pueden ser objetivos o subjetivos. Los criterios de selección pueden limitarse al precio de compra si el artículo que se va a adquirir está fácilmente disponible a través de un número aceptable de vendedores. En este contexto, el precio de compra incluye tanto el coste del artículo como cualquier gasto adicional, como, por ejemplo, los gastos de entrega. Otros criterios de selección pueden identificarse y documentarse para respaldar la evaluación en el caso de productos, servicios o resultados más complejos. A continuación, se muestran algunos ejemplos:
·
Comprensión de la necesidad: ¿En qué medida la propuesta del vendedor responde al enunciado del trabajo relativo a la adquisición?
·
Coste total o del ciclo de vida: ¿El vendedor seleccionado producirá el coste total más bajo (coste de compra + coste de operación)?
·
Capacidad técnica: ¿El vendedor cuenta con las habilidades y conocimientos técnicos necesarios o se puede esperar razonablemente a que los adquiera?
·
Riesgo: ¿Qué nivel de riesgo conlleva el enunciado del trabajo, qué proporción de ese riesgo será asignado al vendedor seleccionado y de qué modo el vendedor mitigará el riesgo?
·
Enfoque de gestión: ¿El vendedor cuenta con los procesos y procedimientos de gestión necesarios para asegurar el éxito del proyecto o puede esperarse razonablemente que los desarrolle?
529
•
Enfoque técnico: ¿Las metodologías, técnicas, soluciones y servicios técnicos propuestos por el vendedor cumplen con los requisitos de la documentación de adquisición o es probable que proporcionen más o menos que los resultados esperados?
·
Garantía: ¿Qué propone el vendedor para garantizar el producto final y durante qué período de tiempo?
·
Capacidad financiera: ¿El vendedor cuenta con los recursos financieros necesarios o puede esperarse razonablemente que los obtenga?
·
Capacidad de producción e interés: ¿El vendedor tiene la capacidad y el interés para cumplir con los posibles requisitos futuros?
·
Tamaño y tipo de negocio: ¿La empresa del vendedor se encuadra dentro de una categoría específica de negocio, por ejemplo, una pequeña empresa, una empresa dirigida por mujeres o una pequeña empresa desfavorecida, según la definición del comprador o de acuerdo con lo establecido por una agencia gubernamental y determinado como una condición para la adjudicación del contrato?
·
Desempeño pasado de los vendedores: ¿Cuál ha sido en el pasado la experiencia con los vendedores seleccionados?
·
Referencias: ¿El vendedor puede proporcionar referencias de clientes anteriores que verifiquen la experiencia laboral y el cumplimiento de los requisitos contractuales por parte del vendedor?
·
Derechos de propiedad intelectual: ¿El vendedor reivindica los derechos de propiedad intelectual en los procesos de trabajo o servicios que utilizará o en los productos que generará para el proyecto?
·
Derechos de propiedad exclusiva: ¿El vendedor reivindica los derechos de propiedad exclusiva en los procesos de trabajo o servicios que utilizará o en los productos que generará para el proyecto?
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
530
DOC Nº 039 Solicitud de cambios
(Change requests) Es el proceso que permite a cualquier interesado solicitar una petición de cambio en el proyecto. A priori, se identifican las necesidades de realizar un determinado cambio en el proyecto y, a continuación, se genera un documento formal que será remitido al Project Manager. El documento de solicitud de cambios debe contener, al menos, los siguientes puntos:
·
Nombre del solicitante y sus datos de contacto.
·
Título de la solicitud.
·
Fecha de la solicitud.
·
Categoría de la solicitud: Normalmente, se dividen en dos tipos: Mayor: Puede provocar impactos en los plazos y costes del proyecto y/o eventualmente podrá incrementar riesgos. Menor: Sin efectos identificados.
·
Descripción del cambio: En este campo se describe, con el mayor detalle posible, los argumentos que respaldan la solicitud del cambio propuesto, sobre todo las eventuales mejoras que dicho cambio podrá producir. Se recomienda establecer un nivel para identificar la necesidad y urgencia del cambio propuesto: Nivel alto: El cambio es necesario para lograr los objetivos del proyecto. Nivel medio: El cambio podrá incrementar los beneficios del proyecto y/o reducir costes y plazos. Nivel bajo: El cambio podría eventualmente aportar valor al proyecto.
·
Impactos: Posibles impactos en los costes, plazos, recursos y calidad del proyecto.
·
Aprobaciones necesarias: Algunos cambios podrán necesitar de más aprobaciones que otros, es importante reflejar los niveles de aprobación necesarios para realizar el cambio requerido.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
531
DOC Nº 040 Presupuesto del proyecto
(Project budget) El presupuesto es una valoración, en términos monetarios, de los recursos que serán utilizados, sobre todo en lo que se refiere a materiales y mano de obra. Para asegurarnos de que estamos confeccionando un presupuesto completo, hay que tener en cuenta que debe ser un reflejo económico fiel del proyecto que vamos a realizar. Por ello, es importante, por ejemplo, no omitir ningún tipo de gastos. La forma más fiable de confeccionar un presupuesto de proyecto es utilizar la EDT del proyecto (véase también sección 5,3). La EDT comprende la subdivisión de los principales entregables del proyecto en otros componentes más pequeños y manejables, de forma tal que los entregables sean definidos con suficiente detalle para responder a las futuras actividades del proyecto. Utilizando la EDT como referencia, se podrá asignar el coste unitario de cada componente que será desarrollado. Sumándose el coste de cada componente, se podría obtener el coste total del proyecto.
Figura 202: EDT con costes adjudicados
Este documento debe contener, además:
· · · · · · · · ·
La descripción de los servicios prestados. Sus duraciones previstas. La mano de obra necesaria. La descripción de los materiales utilizados. El coste de cada servicio. El coste total del presupuesto. El IVA correspond iente. Las fechas y formas de pago. Categorias de costes: fijos, variables, de materiales, de proveedores y otros.
532
DOC Nº 041 Plan de cuentas
(Chart of accounts) El plan de cuentas es un listado que la empresa utiliza para organizar y clasificar el listado de cuentas utilizado para el desarrollo de sus procesos contables relacionados con las actividades económicas que realice. La cantidad y los nombres de cada cuenta estarán en función de la naturaleza o tipo de empresa, por ejemplo, una empresa farmacéutica tendrá un plan de cuentas diferente de una empresa de desarrollo de software. Para confeccionar un plan de cuentas correctamente es importante tener en cuenta que el listado sea ordenado y completo, es decir, que contemple todas las cuentas necesarias para reflejar los movimientos realizados por la empresa. Un plan de cuentas debe ser codificado para facilitar la memorización, ordenamiento y gestión de las cuentas de la empresa. La codificación utilizada puede ser numérica, alfabética o alfanumérica y deben obedecer algunos criterios:
·
Sencillez: Deben permitir su fácil memorización y deben ser recordadas fácilmente.
·
Precision: Debe existir un criterio de codificación único, que evite ambigüedades. La terminología utilizada para cada cuenta debe ser comprensible por todo el personal de la empresa.
·
Flexible: Que posibilite la inclusión, modificación o cancelación de cuentas, de acuerdo con la necesidad de la empresa. De hecho, es importante la realización de revisiones periódicas que permita mantenerlo actualizado.
Si analizamos el plan general contable del año 2008, veremos cuáles son los grupos contables existentes y cómo podemos realizar nuestras propias codificaciones. Este plan contable contiene un cuadro de cuentas que constituye la cuarta parte del plan y no tiene carácter obligatorio para las empresas. Contiene los grupos, subgrupos y cuentas necesarios, codificados en forma decimal y con un título expresivo de su contenido. El plan general contable divide las cuentas en nueve grupos. Los cinco primeros son de cuentas patrimoniales, y los cuatro últimos, de cuentas de gestión: Grupo 1: Financiación básica. Grupo 2: Inmovilizado. Grupo 3: Existencias. Grupo 4: Acreedores y deudores por operaciones de tráfico. Grupo 5: Cuentas financieras. Grupo 6: Compras y gastos. Grupo 7: Ventas e ingresos. Grupo 8: Gastos imputados al patrimonio neto. Grupo 9: Ingresos imputados al patrimonio neto.
533
Si desglosamos por ejemplo la cuenta 4 (Acreedores y deudores por operaciones comerciales, del grupo 4), encontraremos un segundo grado de cuentas, en el siguiente orden: 4.0 Proveedores. 4.1 Acreedores varios. 4.3 Clientes. 4.4 Deudores varios. 4.6 Personal. 4.7 Administraciones públicas. 4.8 Ajustes por periodificación. 4.9 Deterioro de valor de créditos comerciales y provisiones a corto plazo. Todavía podemos desglosar este nivel. Si elegimos, por ejemplo, la cuenta 4.3 Clientes, nos encontraremos con el siguiente orden de cuentas: 4.3.0 Clientes. 4.3.1 Clientes efectos comerciales a cobrar. 4.3.2 Clientes, empresas del grupo. 4.3.3 Clientes, empresas asociadas. 4.3.5 Clientes de dudoso cobro. 4.3.6 Envases y embalajes a devolver por clientes. 4.3.7 Anticipos a clientes. Dentro de la cuenta 4.3.1 Clientes efectos comerciales a cobrar, encontramos cuatro subgrupos: 4.3.1.0 Efectos comerciales en cartera. 4.3.1.1 Efectos comerciales descontados. 4.3.1.2 Efectos comerciales en gestión de cobro. 4.3.1.5 Efectos comerciales impagados. A partir de este nivel, podemos empezar a realizar nuestras codificaciones. Podemos, por ejemplo, crear un nuevo nivel debajo de la cuenta 4.3.1.2 Efectos comerciales en gestión de cobro, es decir, las facturas recibidas por los proyectos que desarrollamos, donde podemos establecer cuentas codificadas de forma personalizada de acuerdo con nuestros clientes, por ejemplo: 4.3.1.2.0.1 Cliente proyecto A. 4.3.1.2.0.2 Cliente proyecto B. 4.3.1.2.0.3. Cliente proyecto C. Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
534
DOC Nº 042 Reglas del juego
(Ground rules) Un proyecto puede llegar a ser un emprendimiento caótico, repleto de cambios, quejas, confusión y mucha insatisfacción. Es un hecho real que muy pocos proyectos son desarrollados bajo un ambiente armónico, y para lograr este nivel, una de las gestiones más importantes que un Project Manager debe poner en marcha es el establecimiento de reglas generales, que deben ser cumplidas a rajatabla, por el bien del proyecto, del ambiente y de las personas. De acuerdo con Tuckman42, en su teoría para el desarrollo de equipos, en la etapa de formación los integrantes del equipo no se conocen y apenas tienen información sobre los objetivos del proyecto. Cada integrante trae consigo un cierto grado de incertidumbre y es natural que se sienta todavía inseguro en relación a lo que le puede venir por delante. Es una fase en que cada uno adopta una postura neutral, evitando cualquier conflicto, asumiendo una postura pasiva. Es el momento para establecer con el grupo las “reglas del juego”, o “ground rules”. Se trata de una lista de comportamientos aceptables e inaceptables adoptados por el equipo de proyecto para mejorar la relación de trabajo, efectividad y la comunicación. Estas reglas deben ser expuestas, compartidas y aceptadas por el equipo. Las reglas del juego pueden variar de acuerdo con el sector de actuación, pero dependerán sobre todo de la cultura organizada de la empresa y de los eventuales pactos acordados entre el Project Manager y su equipo. Algunas de las reglas que pueden ser establecidas son las siguientes:
·
Los interesados tienen el derecho de poseer el plan de proyecto.
·
El cronograma del proyecto debe ser razonable.
·
El plan de proyecto debe ser constantemente actualizado.
·
El Project Manager es el máximo responsable por el proyecto.
·
Cada integrante del equipo es responsable por gestionar y organizar sus horas de trabajo.
·
El Project Manager y su equipo están de acuerdo en cumplir con los procesos definidopara la gestión del proyecto.
·
El equipo solamente desarrollará las actividades para las cuales están capacitados.
·
El equipo reportará datos realistas acerca de los plazos, costes y recursos consumidos.
·
El equipo se compromete a anticipar eventuales problemas para el desarrollo de acciones correctivas.
535
·
El cliente será siempre informado acerca del avance del proyecto.
·
Los interesados guardarán secreto acerca de las informaciones que maneja.
·
Los interesados acudirán a todas las reuniones por las cuales sean convocados.
·
Cualquier conflicto será resuelto de forma amistosa.
536
DOC Nº 043 Documento de autorización del trabajo
(Work authorization document - WAD) Es WAD es un permiso, generalmente por escrito, para comenzar a trabajar en una actividad del cronograma, paquete de trabajo o cuenta de control específica. Es un método para autorizar trabajos del proyecto y garantizar que la organización identificada realice el trabajo en el tiempo asignado y con la secuencia correcta. Este documento debe contener, por lo menos, los campos que se señalan a continuación:
·
Su número correspondiente de la EDT y el alcance del trabajo.
·
El tiempo de ejecución.
·
Las firmas de las partes responsables por el seguimiento del trabajo (el Project Manager, el cliente...).
·
Un cronograma o un documento que establezca la fecha de inicio y incio del trabajo, duración, hitos y entregables.
·
Un presupuesto correctamente desglosado que incluya la mano de obra y los materiales necesarios y sus costes correspondientes.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
537
DOC Nº 044 Evaluación del desempeño del equipo
(Team perfomance assessments) De acuerdo con el PMBOK®, la evaluación del desempeño del equipo se utiliza para medir el desempeño de un equipo, sobre todo en los siguientes aspectos:
· · ·
Éxito técnico conforme los objetivos acordados del proyecto. Desempeño según el cronograma del proyecto establecido. Desempeño según el presupuesto definido.
Es importante medir, además, las cualidades específicas relacionadas con el trabajo y las personas, que representan medidas indirectas del desempeño del proyecto. La evaluación de la eficacia de un equipo puede incluir indicadores tales como:
·
Mejoras en determinadas habilidades que permitan al equipo del proyecto realizar sus asignaciones de manera más eficaz.
·
Mejoras a nivel de las competencias que ayudan al equipo a funcionar mejor como un grupo.
·
Reducción del índice de rotación del personal.
·
Mayor cohesión del equipo cuando los miembros comparten abiertamente información y experiencias, y se ayudan mutuamente para mejorar el desempeño general del proyecto.
538
DOC Nº 045 Actas de reunión del proyecto
(Project meeting minutes) El acta de reunión es un documento que tiene como objetivo principal, registrar y formalizar el desarrollo de las reuniones de un proyecto, pero sobre todo las decisiones tomadas, aceptadas y rechazadas. El acta de proyecto también permite:
· · ·
Comprobar las asistencias y abstenciones. Determinar planes de acción en función de las decisiones tomadas. Organizar y convocar oficialmente la próxima reunión.
Es importante apuntar las decisiones tomadas en la reunión directamente en el acta. Hacer los apuntes de una reunión en una libreta para posteriormente pasarlas al acta es una perdida inútil de tiempo. El modelo que sugerimos a continuación, contiene los campos necesarios para este tipo de apuntes. Trabajando de esta forma, será posible enviar el acta inmediatamente a los asistentes, proporcionándoles agilidad para poner en marcha las decisiones tomadas. El envío de un acta de proyecto no debería sobrepasar lasveinticuatro horas posteriores a la reunión. Es importante, además, mantener un registro de actas en algun repositorio de la empresa (intranet, carpeta de red...). Hay muchas maneras de organizar y presentar este documento, de todas formas, este documento debería contener, al menos, las siguientes informaciones:
· · · · · · ·
Asunto principal. Ubicación. Duración prevista. Fecha/hora de comienzo. Fecha/hora de finalización. Lista de asistentes. Agenda, que podría tener un recuadro similar al que presentamos a continuación: ÍTEM
1. [Descripción del Ítem] 2. [Descripción del Ítem] · · · · · ·
DECISION / ACCION [descripción de la decisión / acción]/ [descripción de la decisión acción]
FECHA LÍMITE [00/00/00] [00/00/00]
Agenda prevista para la próxima reunión. Duración prevista para la próxima reunión. Fecha/hora de comienzo previstas para la próxima reunión. Fecha/hora de finalización previstas para la próxima reunión. Lista de convocados. Firmas.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
539
DOC Nº 046 Plan de acciones correctivas
(Corrective actions plan) Siempre que se comparan los resultados obtenidos con los resultados previstos, se obtendrán informaciones que darán al Project Manager la oportunidad de poder, en tiempo, realizar acciones correctivas que eviten que el proyecto pierda su rumbo. Una acción correctiva es una medida o un conjunto de medidas que se ponen en macha para eliminar o subsanar algo que no ha salido según lo previsto. Se ponen en marcha, normalmente, cuando ocurren las siguientes situaciones:
· · · · ·
Cuando se observa alguna inconsistencia durante la ejecución del proyecto. Cuando se incumplen los requisitos determinados por el cliente. Cuando se incumplen las estimaciones previstas en el plan de proyecto. Cuando ocurre un suceso no previsto. Cuando se solicita un cambio.
Una vez identificado el factor que genere la necesidad de poner en marcha una acción correctiva, es importante desarrollar un plan de acciones correctivas; este documento debe tener, al menos, los campos que se presentan a continuación: Datos identificativos: · Naturaleza: Descripción del requisito que se incumple.
· ·
Hecho: Descripción de lo que se incumple. Evidencia: Elemento que demuestra el incumplimiento.
Acciones correctivas · Describir las medidas que se pondrán en marcha.
· · ·
Establecer unas fechas de inicio y término de ejecución de dichas medidas. Asignar los recursos correspondientes. Asignar los encargados del plan y sus responsabilidades.
Conclusiones
·
Valorar la eficacia de las acciones tomadas.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
540
DOC Nº 047 Agenda de realización de la auditoría
(Audit agenda) Una auditoría de cualquier naturaleza es, por definición, una reunión. Y, como tal, debería ser previamente notificada a las partes involucradas y correctamente planificada. Uno de los elementos más importantes en la preparación de cualquier reunión es la redacción de una agenda, que debería contar, como mínimo, con los siguientes campos:
· · · · · · ·
Proyecto auditado. Objetivo de la auditoría. Alcance. Localización. Duración. Auditor jefe. Equipo auditor.
La auditoria deberá, además, cumplir con la siguiente agenda:
· · · · · ·
Reunión inicial. Auditoria interna y no conformidades. Revision documental. Revision de los procedimientos. Redacción del informe de auditoría. Presentación de conclusiones auditoría.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
541
DOC Nº 048 Informes de deficiencias y recomendaciones
(Audit report) El Informe de Deficiencias y Recomendaciones presenta los hallazgos, no conformidades y recomendaciones para que la organización ponga en marcha acciones correctivas y de mejora en sus procedimientos. Este documento debe tener, por lo menos, las siguientes informaciones:
· · · · · · · · · ·
Número de auditoría. Proyecto auditado.
·
No conformidades o Código. o Calificación. o Punto norma. o Descripción de la no conformidad y evidencias.
·
Clasificar no conformidad según: o Desviación menor: afecta poco al resultado de los procesos. o Desviación moderada: En ciertas condiciones puede afectar a los procesos. o Desviación importante: Puede provocar defectos o errores que afecten a la satisfacción del cliente.
Norma de referencia. Alcance de la auditoría. Equipo auditor. Fechas de realización. Fecha del informe. Departamento, área o proceso auditado. Aspectos a verificar. Comentarios del auditor.
542
DOC Nº 049 Registros de incidencias
(Issue log) Hay muchas maneras de organizar y presentar este documento, sobre todo por la infinidad de incidencias que pueden llegar a producirse en un proyecto. El ejemplo que viene a continuación ilustra un registro de incidencias relacionado con servicios de gestión de datos informáticos:
· · · ·
Número de la incidencia.
·
Tipo de incidencia o Acceso indebido. o Pérdida de datos. o Copia no autorizada. o Corrupción de datos. o Virus o amenazas externas. o Otros.
·
Prioridad: 1, 2 o 3: Prioridad 1: Incidencia grave. El proyecto podrá ser seriamente comprometido. Prioridad 2: Incidencia importante. El proyecto podrá sufrir cambios en su alcance, plazos, costes o asignación de recursos. Prioridad 3: Incidencia leve. No afecta el proyecto, pero necesita ser documentada
·
Descripción general de la incidencia o Implicaciones en el proyecto. o Acciones propuestas. o Fecha límite.
·
Resolución de la incidencia: o Recursos afectados. o Efectos derivados de la incidencia. o Medidas adoptadas y controles implantados o reforzados. o Procedimientos realizados de recuperación de datos. o Datos restaurados.
· · ·
Persona que ejecuta el proceso.
Autor de la incidencia. Fecha de apertura. Estado: abierta, pendiente, cerrada.
Fecha de cierre de la incidencia. Persona que ha cerrado la incidencia.
Anexar a este registro, si existe, alguna evidencia física de la incidencia, como, por ejemplo, documentos, registros de ordenador, manuales técnicos, comunicaciones del personal de seguridad... En definitiva, cualquier información que pueda resultar valida. Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
543
DOC Nº 050 Aceptación formal
(Formal aceptance) Los entregables y su aceptación son un punto crítico en el desarrollo del proyecto debiéndose llevar también un registro de todos los entregables que van apareciendo en el ciclo de vida del proyecto. La aceptación es uno de los aspectos más problemáticos, ya que las partes deben estar de acuerdo en qué se requería exactamente y si el producto cumple esos requisitos. La aceptación se llevará a cabo bajo el plan de gestión del alcance del proyecto definido inicialmente, debiendo estar los criterios de aceptación, así como dónde y bajo qué circunstancias operativas se desarrollará la aceptación, claramente definidos en el contrato. El documento de aceptación formal debería contar con, al menos, los siguientes campos:
·
Entregables: Producto o servicio resultante del trabajo realizado durante una determinada fase, como, por ejemplo, la colocación del piso en una obra es el resultado de una de las fases de construcción de un edificio.
·
Fecha y firma del cliente bajo el siguiente texto: “El cliente certifica que la totalidad de los entregables reseñados en la presente acta de recepción han sido entregados/terminados y están de acuerdo con las especificaciones formales y demás requisitos contractualmente convenidos y establecidos entre las partes”.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice. En algunos casos, existe una cierta dificultad en conseguir la firma de este documento, puesto que, una vez que esté finalizado, el equipo de proyecto se disuelve y cada integrante retorna a su departamento de origen. Para evitar que el proyecto no cuente con una aceptación formal del cliente, se puede añadir en el pie de página la siguiente coletilla: “Pasado el plazo de X días desde la fecha de emisión de este documento, de no recibir respuesta en contra, se considerará el proyecto totalmente aceptado a falta de otra respuesta por parte del cliente”.
544
DOC Nº 051 Encuesta de calidad
(Surveys) La encuesta de calidad es un documento utilizado para evaluar el nivel de satisfacción del cliente, tras el cierre definitivo del proyecto y la entrega de los servicios y/o productos generados. Su cumplimiento podrá aportar a la empresa informaciones importantes, que podrán mejorar la toma de decisiones y la planificación de proyectos futuros. Se realiza mediante el envío y la recepción de la encuesta a las personas y/o empresas que han formado parte del grupo de interesados del proyecto y han contribuido directa o indirectamente a la evolución del proyecto. La elección de los interesados que cumplimentarán dicha encuesta corresponderá al Project Manager. Un cuestionario de calidad es un documento extremadamente personal, por lo cual las preguntas propuestas deberán contener los atributos de satisfacción que habitualmente se evalúan en la finalización de un proyecto dentro de una determinada organización. De todas formas, es muy recomendable dividir la encuesta de calidad en dos sesiones diferentes: la primera, con preguntas sencillas y objetivas cuya respuesta se cumplimenta a través de casillas con con valores numéricos asignados desde 1 (muy a malo) a 5 (muy bueno). Este tipo de respuesta, conocida como “selección múltiple”, que permitirá a la empresa ejecutante del proyecto calcular el promedio de diferentes indicadores y realizar estadísticas fiables. Las valoraciones presentes en esta sesión podrían ser las siguientes: VALORACIÓN DE LOS SERVICIOS
1
2
3
4
5
Puntualidad de servicios (Adecuación del cronograma, hitos, plazos...) Capacidad de reacción (Ante incidencias, cambios, urgencias...) Disponibilidad del servicios (Recursos, horarios, accebilidad de profesionales...) Profesionalidad del personal (Project Manager, consultores...) Satisfacción general de la gestión del proyecto Satisfacción general del servicio y/o producto generado Recomendaría los servicios recibidos a otras organizaciones ¿Volvería a contratar nuestros servicios? La otra sesión de la encuesta debería proporcionar un espacio donde al interesado le fuera posible expresar libremente su opinión, aportar sugerencias o críticas.
545
DOC Nº 052 Acta de cierre del proyecto
(Close documents) El cierre de un proyecto es la culminación del proceso proyectual, y el momento de hacer balance del mismo. Durante el cierre se advierte cómo de bien o de mal se ha terminado y, en especial, si se han alcanzado los objetivos previstos. Además, es el momento de realizar facturación y las reuniones de evaluación, donde se examinará cuál ha sido el transcurso del proyecto y cuál es el margen obtenido de beneficios, y se extraerán conclusiones sobre ello. El acta de cierre del proyecto tiene, por lo tanto, el objetivo de evaluar el resultado de los trabajos y resumir todo lo sucedido en el proyecto que pueda ser de importancia para proyectos futuros de la empresa. Contiene la información de si el proyecto obtuvo o no los resultados previstos y, en caso negativo, también incluye un análisis de las razones de ello. Este documento debe incluir, por los menos, las siguientes informaciones:
·
Balance de ingresos y gastos: Incluyendo todos los gastos, aún cuando no hayan sido contablemente imputados, como las facturas libradas al cliente, pero no cobradas y/o los gastos pendientes no facturados o cobrados.
·
Informes de situación final: Descripción general, en lenguaje no técnico, del ciclo de vida del proyecto, desde la adjudicación hasta el cierre contable.
·
Lista de documentación generada: Documentación interna del proyecto (minutas, informes...), documentación generada dentro del ámbito del proyecto y la obtenida de terceros (clientes, proveedores). Descripción detallada de los productos generados (diseños, planos, cambios, manuales, entre otros).
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
546
DOC Nº 053 Libro de notas del proyecto
(Project notebook) El libro de notas del proyecto es una especie de “carpeta” donde se almacena toda la información acumulada desde el comienzo del proyecto. En él se encontrará un valioso historial de consulta que puede incluir, entre otras cosas:
· · · ·
Las actas de reunión donde se han tomado las decisiones más importantes. Estimaciones de costes, plazos y recursos. Plantillas, diagramas de flujo, gráficos Gantt. Cualquier información que pueda servir como base histórica de consulta.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice. Es muy conveniente que el libro de notas del proyecto esté en formato electrónico, puesto que de esta forma se puede buscar y compartir la información de una forma más dinámica y fácil. Además, si la organización mantiene un procedimiento de copia de seguridad, esta información no se perderá. Todo proyecto debe tener un libro de notas. El momento apropiado de crearlo es al principio del proyecto, cuando todavía no se ha producido mucha documentación. Según el proyecto vaya avanzando, el libro de notas irá recogiendo la información que considere más relevante.
547
DOC Nº 054 Lecciones aprendidas
(Lessons learned) Las organizaciones que están constantemente involucradas en proyectos producen una cantidad importante de información que puede servir como base de consulta en proyectos futuros similares. Estas informaciones, conocidas en Project Management como “lecciones aprendidas”, son una compilación de los aciertos y las equivocaciones del proyecto, como son las estimaciones realizadas, las técnicas utilizadas y la opinión de los participantes directos del proyecto. Estas lecciones aprendidas son enseñanzas que, tras la conclusión de un proyecto, deberán ser cuidadosamente catalogadas, analizadas, almacenadas y distribuidas a los participantes del proyecto cuando sea necesario. De estas informaciones se aprovecharán las estimaciones e informaciones aportadas y se intentará no caer en los mismos errores. Las lecciones aprendidas pueden, de forma muy relevante, contribuir en la mejora continua de las prácticas de la organización. Muchas organizaciones cuentan con profesionales exclusivamente dedicados a la organización y el almacenamiento de este tipo de información para consulta del Project Manager o de algún integrante del equipo. El documento de lecciones aprendidas puede tener distintas variaciones y su contenido será siempre acorde con las necesidades de cada organización. No obstante, es importante tener en cuenta que este documento servirá para aportar informaciones de gran valía a futuros equipos de proyecto, y por ello debe reflejar las inquietudes, conclusiones y recomendaciones de mejora para futuros proyectos. Dicho esto, un documento de lecciones aprendidas debe contener, al menos, los siguientes campos, tal y como ilustra el ejemplo que se desarrolla a continuación:
·
Nombre propuesto para la lección aprendida: Estimación de plazos del proyecto “SYC INTERNACIONAL”.
·
Práctica especifica, método o herramienta utilizada: Gráfico de Gantt, estimación paramétrica y técnica Delphi.
·
Tarea asignada: Estimación de plazos para el diseño del prototipo de circuito electrónico “XY230”.
·
Resultado generado: Ha sido estimado un plazo de cuarenta días para la realización total del diseño.
·
Cuál pudo haber sido el resultado preferido: El cliente nos habría solicitado realizar el diseño en treinta días.
·
Qué pudo haber creado el resultado preferido: La contratación de por lo menos un profesional cualificado extra para desarrolar la actividad.
·
Cuál es la lección aprendida específicamente: Si nuestra organización pretende asumir otros proyectos de complejidad similar al proyecto “SYC INTERNACIONAL”, será necesario contar con más profesionales técnicos de diseño de componentes electrónicos.
·
Cómo se puede identificar una situación similar en el futuro: Cuando surjan proyectos
548
con el mismo grado de complejidad.
549
•
Cuál es el comportamiento recomendado para el futuro: Tener un equipo mayor de profesionales que cumplan con los requisitos exigidos para desarrollar las actividades de dicha complejidad.
·
Dónde y cómo puede ser este conocimiento utilizado más tarde durante el presente proyecto: En este proyecto no se realizarán otras estimaciones similares.
·
Dónde y cómo puede ser este conocimiento utilizado en un proyecto futuro: En la fase de estimaciones de plazos para el diseño del prototipo de circuito electrónico XY230 y/o similar.
·
Quién debe ser informado sobre esta lección aprendida: El Project Manager y el líder técnico.
·
Cómo debe ser esta lección aprendida publicada: En nuestra intranet.
·
Se ha adicionado material(es) de referencia, ejemplo(s) y / otro material adicional: Véase el fichero “cronograma_proyecto_SYC.pdf” en nuestra intranet, en el apartado “Proyectos Cerrados 2010”.
Además, no podrán faltar los “puntos imprescindibles” descritos en el comienzo de este Apéndice.
550
DOC Nº 055 Actualizaciones al plan de gestión del proyecto
(Project management plan updates) Acorde con el PMBOK®, entre los elementos del plan de gestión del proyecto que pueden actualizarse se encuentran: Referentes al proceso 4.3 - Gestión y ejecución del plan de proyecto (Proceso de ejecución del proyecto)
· · · · · · · · ·
El plan de gestión de requisitos (doc nº 004). El plan de gestión del cronograma (doc nº 028). El plan de gestión de costes (doc nº 027). El plan de gestión de calidad (doc nº 016). El plan de gestión de los recursos humanos (doc nº 022). El plan de gestión de las comunicaciones (doc nº 023). El plan de gestión de riesgos (doc nº 020). El plan de gestión de las adquisiciones (doc nº 024). Las líneas base del proyecto (véase sección 2.1.3).
Referentes al proceso 4.4 - Monitorización y control del trabajo del proyecto (Proceso de seguimiento y control del proyecto)
· · · · · ·
El plan de gestión del cronograma (doc nº 028). El plan de gestión de costes (doc nº 027). El plan de gestión de calidad (doc nº 016). La línea base del alcance (véase sección 2.1.3). La línea base del cronograma (véase sección 2.1.3). La línea base del desempeño de costes (véase sección 2.1.3).
Referentes al proceso 4.5 - Control integrado de cambios (Proceso de seguimiento y control del proyecto)
· ·
Todos los planes de gestión subsidiarios. Las líneas base que están sujetas al proceso formal de control de cambios.
Los cambios a las líneas base únicamente deben mostrar los cambios ocurridos desde la fecha actual en adelante. El desempeño pasado no debe modificarse. Cualquier modificación en el desempeño pasado perjudicará la integridad de las líneas base originales y de los datos históricos.
551
Referentes al proceso 5.5 - Control de cambios del alcance (Proceso de seguimiento y control del proyecto)
·
Actualizaciones a la línea base del alcance (véase sección 2.1.3): Si las solicitudes de cambio afectan al alcance del proyecto, entonces será necesario revisar y volver a la declaración del alcance, la EDT y el diccionario de la EDT para reflejar lo aprobados.
·
Actualizaciones a otras líneas base (véase sección 2.1.3): Si las solicitudes de cambio aprobadas alcanzan al proyecto, entonces será necesario revisar y volver a emitir las correspondientes al coste y al cronograma para reflejar los cambios aprobados.
Referentes al proceso 6.2 - Secuenciación de actividades (Proceso de planificación del proyecto)
·
Línea base del cronograma (véase sección 2.1.3): Los cambios a la línea base del cronograma se incorporan en respuesta a las solicitudes de cambio aprobadas relacionadas con cambios en el alcance del proyecto, en los recursos de las actividades o en los estimados de la duración de las actividades.
El plan de gestión del cronograma (doc nº 028). ·
Línea base de coste (véase sección 2.1.3): La línea base de coste puede actualizarse para reflejar los cambios originados por las técnicas de compresión del cronograma.
Referentes al proceso 7.3 - Control de costes (Proceso de seguimiento y control del proyecto)
·
Línea base del desempeño de costes (véase sección 2.1.3): Los cambios a la línea base del desempeño de costes se incorporan en respuesta a los cambios aprobados del alcance, de los recursos de las actividades o de las estimaciones de costes. En algunos casos, las variaciones del coste pueden ser tan importantes que se hace necesario revisar la línea base de coste para proporcionar una base realista para la medición del desempeño.
El plan de gestión de costes (doc nº 027). Referentes al proceso 8.2 - Aseguramiento de la calidad (Proceso de ejecución del proyecto)
· · ·
El plan de gestión de calidad (doc nº 016). El plan de gestión del cronograma (doc nº 028). El plan de gestión de costes (doc nº 027).
Referentes al proceso 8.3 – Control de calidad (Proceso de seguimiento y control del proyecto)
·
El plan de gestión de calidad (doc nº 016).
552
Referentes al proceso 9.2 - Adquisición de personal (Proceso de ejecución del proyecto)
·
El plan de gestión de los recursos humanos (doc nº 022): Cuando se asignan personas específicas a roles y responsabilidades del proyecto es posible que tales personas no concuerden exactamente con los requisitos de personal indicados en el plan de recursos humanos.
Referentes al proceso 10.4 - Gestión de las expectativas de los interesados (Proceso de ejecución del proyecto)
·
El plan de gestión de las comunicaciones (doc nº 023): La actualización se realiza cuando se identifican requisitos de comunicación nuevos o modificados. Por ejemplo, determinadas comunicaciones pueden dejar de ser necesarias, un método de comunicación ineficaz puede ser reemplazado por otro o puede identificarse un nuevo requisito de comunicación.
Referentes al proceso 11.5 - Planificación de la respuesta a riesgos (Proceso de planificación del proyecto)
·
El plan de gestión del cronograma (doc nº 028): Se actualiza para reflejar los cambios en el proceso y en la práctica motivados por las respuestas a los riesgos. Esto puede incluir cambios que atañen a la tolerancia o al comportamiento en relación con la carga y nivelación de recursos, así como actualizaciones al cronograma mismo.
·
El plan de gestión de costes (doc nº 027): Se actualiza para reflejar los cambios en el proceso y en la práctica motivados por las respuestas a los riesgos. Esto puede incluir cambios que atañen a la tolerancia o al comportamiento en relación con la contabilidad de los costes, el seguimiento y los informes, así como actualizaciones al presupuesto y a la utilización de las reservas para contingencias.
·
El plan de gestión de calidad (doc nº 016): Se actualiza para reflejar los cambios en el proceso y en la práctica motivados por las respuestas a los riesgos. Esto puede incluir cambios que atañen a la tolerancia o al comportamiento en relación con los requisitos, el aseguramiento o el control de calidad, así como actualizaciones a la documentación de requisitos.
·
El plan de gestión de las adquisiciones (doc nº 024): Puede actualizarse para reflejar cambios a nivel de la estrategia, tales como modificaciones en cuanto a la decisión de hacer o comprar, o en el o los tipos de contrato, motivados por las respuestas a los riesgos.
·
El plan de gestión de los recursos humanos (doc nº 022): Se actualiza para reflejar los cambios en la estructura organizacional del proyecto y en las aplicaciones de recursos motivados por las respuestas a los riesgos. Esto puede incluir cambios que atañen a la tolerancia o al comportamiento en relación con la asignación del personal, así como actualizaciones a la carga de recursos.
·
Estructura detallada del trabajo (véase sección 5.3): Como consecuencia del nuevo
553
trabajo (o del trabajo omitido) generado por las respuestas a los riesgos, la EDT puede actualizarse (Sección 5.3.3.1) para reflejar estos cambios.
554
•
Línea base del cronograma (véase sección 2.1.3): Como consecuencia del nuevo trabajo (o del trabajo omitido) generado por las respuestas a los riesgos, la línea base del cronograma puede actualizarse para reflejar estos cambios.
·
El plan de gestión de costes (doc nº 027): Como consecuencia del nuevo trabajo (o del trabajo omitido) generado por las respuestas a los riesgos, la línea base del desempeño de costes puede actualizarse para reflejar estos cambios.
Referentes al proceso 11.6 - Supervisión y control de riesgos (Proceso de seguimiento y control del proyecto) Los documentos del proyecto que pueden actualizarse son los mismos que los del proceso anterior. Referentes al proceso 12.2 – Conducción de compras (Proceso de ejecución del proyecto)
· · · ·
La línea base del alcance (véase sección 2.1.3). La línea base del cronograma (véase sección 2.1.3). La línea base del desempeño de costes (véase sección 2.1.3). El plan de gestión de las adquisiciones (doc nº 024).
Referentes al proceso 12.3 – Administración del contrato (Proceso de seguimiento y control del proyecto)
·
El plan de gestión de las adquisiciones (doc nº 024): Se actualiza para reflejar las solicitudes de cambio aprobadas que afectan a la gestión de las adquisiciones, incluyendo los impactos en los costes o los cronogramas.
·
La línea base del cronograma (véase sección 2.1.3): En el caso de que se produzcan retrasos que afecten al desempeño general del proyecto, puede ser preciso actualizar la línea base del cronograma para reflejar las expectativas actuales.
555
DOC Nº 056 Actualizaciones a los documentos del proyecto
(Project document update) Acorde con el PMBOK®, entre los elementos del plan de gestión del proyecto que pueden actualizarse se encuentran: Referentes al proceso 4.3 – Gestión y ejecución del plan de proyecto (Proceso de ejecución del proyecto)
· · · ·
Los documentos de requisitos (docs nº 004, 005 y 006). Los registros del proyecto (asuntos, supuestos...). El registro de riesgos (doc nº 021). El registro de interesados (doc nº 002).
Referentes al proceso 4.4 – Monitorización y control del trabajo del proyecto (Proceso de seguimiento y control del proyecto)
· · ·
Las proyecciones (véase sección 7.3.1.2). Los informes de desempeño (véase sección 7.3.1.1). El registro de incidencias (doc nº 049).
Referentes al proceso 4.5 – Control integrado de cambios (Proceso de seguimiento y control del proyecto) Los documentos del proyecto que pueden actualizarse como resultado del proceso realizar el control integrado de cambios incluyen el registro de solicitudes de cambio y cualquier documento que esté sujeto al proceso formal de control de cambios. Referentes al proceso 5.2 – La definición del alcance (Proceso de planificación del proyecto)
· · ·
El registro de interesados (doc nº 002). Los documentos de requisitos (docs nº 004 y 005). La matriz de rastreabilidad de requisitos (doc nº 006).
Referentes al proceso 5.3 - Creación de la EDT (Proceso de planificación del proyecto)
·
Los documentos de requisitos (docs nº 004 y 005). En caso de que se generen solicitudes de cambio aprobadas a raíz del proceso crear la EDT, es posible que sea necesario actualizar la documentación de requisitos para incorporar tales cambios.
Referentes al proceso 5.4 - Verificación del alcance: (Proceso de seguimiento y control del
556
proyecto)
557
Los documentos del proyecto que pueden actualizarse como resultado de este proceso incluyen todos aquellos documentos que definen el producto o que informan sobre su estado de terminación. Referentes al proceso 5.5 - Control de cambios del alcance (Proceso de seguimiento y control del proyecto)
· ·
Los documentos de requisitos (docs nº 004 y 005). La matriz de rastreabilidad de requisitos (doc nº 006).
Referentes al proceso 6.2 - Secuenciación de actividades (Proceso de planificación del proyecto)
· · ·
Las listas de actividades (doc nº 010). Los atributos de la actividad (doc nº 011). El registro de riesgos (doc nº 021).
Referentes al proceso 6.3 - Estimación de los recursos de las actividades (Proceso de planificación del proyecto)
· · ·
Las listas de actividades (doc nº 010). Los atributos de la actividad (doc nº 011). Los calendarios de recursos (véase sección 9.4.1.7).
Referentes al proceso 6.4 - Estimación de duración de actividades (Proceso de planificación del proyecto)
·
Los atributos de la actividad (doc nº 011).
·
Los supuestos: Hechos durante el desarrollo del estimado de la duración de las actividades, como los niveles de habilidad y disponibilidad (véase sección 2.2.1).
Referentes al proceso 6.5 - Desarrollo del cronograma del proyecto (Proceso de ejecución del proyecto)
·
Requisitos de recursos de la actividad (doc nº 012): La nivelación de recursos puede tener un efecto significativo en los estimados preliminares de los tipos y cantidades de recursos necesarios. Si el análisis de nivelación de recursos modifica los requisitos de recursos del proyecto, estos últimos son actualizados.
·
Los atributos de la actividad (doc nº 011): Se actualizan para incluir todos los requisitos de recursos revisados y cualquier otra revisión generada por este proceso.
·
Los calendarios de recursos (véase sección 9.4.1.7).
558
·
Registro de riesgos (doc nº 021): Puede necesitar actualizarse para reflejar las oportunidades o las amenazas identificadas al establecer los supuestos de la planificación.
Referentes al proceso 6.6 - Control del cronograma (Proceso de seguimiento y control del proyecto)
·
Datos del cronograma (doc nº 014): Pueden desarrollarse nuevos diagramas de red del cronograma del proyecto para reflejar las duraciones restantes aprobadas y las modificaciones al plan de trabajo. En algunos casos, los retrasos en el cronograma del proyecto pueden ser tan graves que se deberá desarrollar un nuevo cronograma objetivo, con fechas de inicio y finalización proyectadas, para proporcionar datos realistas con el fin de dirigir el trabajo y medir el desempeño y el avance.
·
Cronograma del proyecto (doc nº 014): Se generará un cronograma actualizado del proyecto a partir de los datos actualizados del cronograma para reflejar los cambios al mismo y gestionar el proyecto.
Referentes al proceso 7.1 - Estimación de costes (Proceso de planificación del proyecto)
·
Registro de riesgos (doc nº 021).
Referentes al proceso 7.2 - Establecimiento del presupuesto (Proceso de planificación del proyecto)
· · ·
Registro de riesgos (doc nº 021). Los estimados de costes (véase sección 7.1). Cronograma del proyecto (doc nº 014).
Referentes al proceso 7.3 - Control de costes (Proceso de seguimiento y control del proyecto)
· ·
Los estimados de costes (véase sección 7.1). Base de las estimaciones (doc nº 015).
Referentes al proceso 8.1 - Planificación de la calidad (Proceso de planificación del proyecto)
· ·
El registro de interesados (doc nº 002). La matriz de asignación de responsabilidades (Sección 9.1.2.1)
Referentes al proceso 8.2 - Aseguramiento de la
559
calidad (Proceso de ejecución del proyecto)
· ·
Los informes de auditorías de calidad (doc nº 048).
La documentación del proceso. Referentes al proceso 8.3 - Control de calidad (Proceso de seguimiento y control del proyecto) Los documentos del proyecto que pueden ser actualizados incluyen, entre otros, los estándares de calidad. Referentes al proceso 10.2 - Planificación de las comunicaciones (Proceso de planificación del proyecto)
· · ·
Cronograma del proyecto (doc nº 014). El registro de interesados (doc nº 002). La estrategia de gestión de los interesados (véase sección 1.7.3.1).
Referentes al proceso 10.4 - Gestión de las expectativas de los interesados (Proceso de ejecución del proyecto)
·
La estrategia de gestión de los interesados (véase sección 1.7.3.1): Se actualiza como resultado de la atención de preocupaciones y la resolución de incidentes. Por ejemplo, puede establecerse que un interesado tiene necesidades de información adicionales.
·
El registro de interesados (doc nº 002): Se actualiza cuando la información sobre los interesados cambia, cuando se identifican nuevos o en el caso de que los originalmente registrados ya no participen en el proyecto o no reciban su impacto, o cuando se requieren otras actualizaciones según casos específicos.
·
Registro de incidentes (doc nº 42): Se actualiza a medida que se identifican nuevos y se resuelven los actuales.
Referentes al proceso 11.5 - Planificación de la respuesta a riesgos (Proceso de planificación del proyecto)
·
Actualizaciones al registro de supuestos. Conforme se dispone de nueva información por medio de la aplicación de las respuestas a los riesgos, los supuestos cambiarán en consecuencia. El registro de supuestos debe revisarse para adaptarlo en función de esta nueva información. Los supuestos pueden incorporarse en el enunciado del alcance o en un registro de supuestos separado.
·
Actualizaciones a la documentación técnica. Conforme se dispone de nueva información por medio de la aplicación de las respuestas a los riesgos, los métodos técnicos y los entregables físicos pueden cambiar. La documentación de apoyo debe revisarse para adaptarla en función de esta nueva información.
560
Referentes al proceso 11.6 - Supervisión y control de riesgos (Proceso de seguimiento y control del proyecto) Los documentos del proyecto que pueden actualizarse como resultado del proceso son los mismos que los del proceso anterior. Referentes al proceso 12.2 - Conducción de compras (Proceso de ejecución del proyecto)
· · ·
La documentación de req uisitos (doc nº 11). La documentación relativa a la rastreabilidad de requisitos (doc nº 13). El registro de riesgos (doc nº 47).
561
Apéndice B Siete pro yectos que se con vertieron en siete mara villas
Proyectos son emprendimientos que, como muchas cosas en la vida, los hay más y menos difíciles de llevarse a cabo. Por definición, un proyecto bien planificado, ejecutado y finalizado correctamente es un logro complicado de obtener. Estudios demuestran que un reducido número de proyectos son finalizados dentro de los plazos y costes estimados y, de este reducido grupo, unos cuantos logran satisfacer plenamente al cliente. Si ya se puede apreciar una elevada dificultad en la ejecución de un proyecto de razonable complejidad, ¿qué podríamos decir del desarrollo de un proyecto que pretendiera construir una obra arquitectónica que debería ser recordada por muchos pueblos durante milenios? Un proyecto es, como se ha definido al principio de esta obra, un intento de lograr un objetivo específico mediante la ejecución de trabajos previamente planificados, bajo un estricto seguimiento y control de fases interdependientes. Para que un emprendimiento pueda ser considerado un proyecto debe poseer, por lo menos, las siguientes características:
· · · · · ·
Ser un emprendimiento temporario. Tener limitaciones. Ser realizado por personas. Ser realizado para crear un producto o servicio único. Ser elaborado de forma progresiva. Tener un objetivo definido.
563
En este Apéndice, analizaremos las siete maravillas del mundo antiguo bajo en enfoque del Project Management. Todas estas construcciones, sin sombra de dudas, han pasado por algún tipo de planificación, se encontraron bajo innúmeros riesgos y de alguna forma contaba con alguna figura similar al Project Manager, para la dirigir todo el proyecto. Es escasa la información que disponemos de dichos proyectos, puesto que algunos registros remontan a milenios anteriores al nacimiento de Cristo. De todas formas, intentaremos ilustrar a continuación una especie de “Ficha de proyecto” de cada una de estas construcciones trascendentales.
Antecedentes La lista clásica de las siete maravillas del mundo antiguo se basa en un poema del poeta griego Antipatro de Sidón75, que, como muchos escritores de la época, hicieron una relación de las construcciones del mundo clásico que eran considerados ejemplos de belleza. Esta relación posteriormente se hizo conocida como las “siete maravillas del mundo antiguo”. El número siete era considerado mágico entre los griegos. Todas las construcciones han sido finalizadas y efectivamente existieron (con excepción de los jardines colgantes de Babilonia, que todavía no ha sido totalmente comprobada, aunque existan algunas evidencias arqueológicas). La lista de las siete maravillas no incluye ninguna maravilla natural ni ninguna ruina. Formaban parte de un conjunto de obras arquitectónicas que los griegos consideraban dignas de ser visitadas (de las siete maravillas, cinco pertenecían al mundo helenístico). De todas ellas, solo una, la gran pirámide de Giza, en Egipto, permanece en pie. Los siete proyectos que se tornaran “Las siete maravillas del mundo”, ordenadas según la época de su construcción, son las siguientes:
1. La Gran Pirámide de Guiza. Ubicada en Giza, Egipto; entre los años 2584-2561 a.C. 2. Los jardines colgantes de Babilonia. Construidos en 605 a.C – 562 a.C. 3. Templo de Artemisa en Éfeso. Construido hacia 550 a.C – 325 a.C. 4. La estatua de Zeus en Olimpia. Esculpida hacia 430 a.C. 5. El sepulcro de Mausolo (Mausoleo) en Halicarnaso. Construido hacia 353 a.C. 6. El Coloso de Rodas. Construido entre 294 adC y 282 a.C. 7. El Faro de Alejandría. Construido entre 294 adC y 283 a.C.
564
1. La Gran Pirámide de Guiza
Wikimedia Commons
Ubicación geográfica: Egipto, sobre la meseta de Guiza, a doce kilómetros de la cuidad de El Cairo. Período de construcción: Acorde con los manuscritos del historiador griego Heródoto de Haricarnaso, la pirámide en sí, tardó veinte años en construirse. Registros históricos indican que ha sido construida entre los años 2584-2561 a.C. Patrocinador: El Faraón Keops76 Encargado y principales involucrados: El arquitecto Hemiunu77 (primo del faraón). Objetivo del proyecto: Fue construida como tumba real para el Faraón Keops76. Mano de obra: La gran pirámide no ha sido construida con mano de obra esclava, como se había pensado durante mucho tiempo, sino con trabajadores altamente cualificados, comandados por capataces de considerables conocimientos en geometría, estereotomía (arte de cortar la piedra), astronomía... Se calcula que la fuerza laboral total que intervino en la pirámide fue de aproximadamente cuatro mil hombres entre obreros de canteras, acarreadores y constructores.
565
Coste del proyecto: Hay registros que indican que la mano de obra empleada en el proyecto fue pagada con cerveza. En la pirámide escribieron con caracteres egipcios cuánto se gastó en rábanos, cebollas y ajos para los trabajadores. En términos financieros, no quedan registros fiables, pero acorde con algunos registros históricos, el Faraón tuvo que desembolsar miles de talentos de plata solo en materia prima. El “talento de plata” era una medida monetaria utilizada en la antigüedad. Un talento equivalía cerca de 35 kilos de plata, pero esta unidad ha variado a lo largo de los siglos. Características técnicas: Construida sobre una planta cuadrada de 230,5 metros de lado y cuya altura es de aproximadamente 146,5 metros. Es la mayor de todas las ochenta pirámides de Egipto. Se mantuvo como la estructura más alta hecha por el hombre hasta la construcción de la Torre Eiffel, en 1889, 4.500 años después. La obra está compuesta de más de 2,3 millones de enormes bloques de piedra caliza (se estima que cada bloque pesa cerca de tres toneladas). Estos bloques fueron producidos a partir de caliza dolomítica, fácilmente compuesto en el lugar usando sustancias muy comunes en la época, como cal, salitre y arena. Todos los bloques de piedra fueron deliberadamente inclinados y entallados con exactitud a la curvatura de la Tierra. El radio de esa inclinación es igual al radio de la Tierra. Las pirámides fueron construidas para que se adaptaran a los movimientos de expansión y contracción bajo la acción del calor, del frío o incluso de terremotos y otros fenómenos de la naturaleza. El egiptólogo británico Sir William Matthew Flinders Petrie 78 hizo el estudio más detallado realizado hasta el momento acerca del monumento, siendo sus dimensiones las siguientes:
· ·
Altura original: 146,61 metros. Altura actual: 136,86 metros. Pendiente: 51º 50' 35".
La longitud de los lados de la base, según Flinders Petrie78, es:
· ·
Lado Norte: 230,364 metros. Lado Este: 230,319 metros. Lado Sur: 230,365 metros. Lado Oeste: 230,342 metros.
Requisitos del proyecto: Debería ser construida en el margen oeste del río Nilo, en la dirección del sol poniente. Los egipcios creían que, enterrando a su rey en una pirámide, se elevaría y se uniría al sol, tomando su lugar de derecho con los dioses. Curiosidades acerca del proyecto: La mayor parte de los trabajos de construcción de la pirámide eran realizados durante los cuatro meses del año en los que el río Nilo estaba inundado y no había trabajo que hacer en el campo. Según algunos historiadores griegos, Keops 76 mandó construir la Gran Pirámide de Guiza, llegando incluso a prostituir a su propia hija, para así obtener fondos con los que construir su pirámide. Periodo de vida: La Gran Pirámide de Giza tiene más de 4.500 años, y es la única de las siete maravillas del mundo antiguo que aún perdura, aunque parte de su estructura ha sido damnificada, sobre todo por los efectos de las erosiones, y las riquezas que habían en su interior hayan sido saqueadas a lo largo de los siglos.
566
2. Los Jardines Colgantes de Babilonia
Wikimedia Commons
Ubicación geográfica: Ciudad de Babilonia, actual Iraq. Periodo de construcción: 43 años (entre 605 a.C a 562 a.C). Patrocinador: Rey Nabucodonosor II79. Objetivo del proyecto: el Rey Nabucodonosor79 encargó esta construcción para que su esposa, Amytis80, procedente del norte de Media (Oriente Medio), que añoraba su tierra montañosa y florida, pudiera contemplar un paisaje similar a su ciudad natal. Mano de obra: Esclava. Características técnicas: Los Jardines Colgantes de Babilonia estaban conformados por numerosas terrazas escalonadas conteniendo tierra fértil, construidas con piedra y ladrillos en diferentes niveles. Estas terrazas eran sostenidas por inmensas bóvedas con columnas y arcos, y podían llegar a los cien metros de altura. En ellas se plantaron palmeras de dátiles, exóticas flores de oriente, plátanos, verdes y perfumadas plantas que caían desde las alturas. Un sistema hidráulico llevaba el agua desde el río Éufrates hasta una terraza superior, desde la cual se distribuía por todas las bóvedas.
567
Requisitos del proyecto: Babilona es una ciudad donde todo es demasiado llano, rectilíneo. Esto entristece a la esposa de Nabucodonosor 79, que se crió en montes y colinas exuberantes de vegetación. Así el Rey encarga un proyecto de construcción de incluye una serie de terrazas escalonadas en las cuales se depositarán tierra y se plantara una inmensa cantidad de árboles, flores, arbustos... El proyecto requiere, además, la construcción de una máquina semejante a una noria para transportar el agua desde un pozo hasta los jardines para regarlos. Toda esta estructura deberá crear un aparente monte cubierto de verdeante vegetación. Curiosidades acerca del proyecto: Poco se sabe sobre la real existencia de esta construcción. Es tan poco lo que se conoce sobre ella, que hay dos versiones distintas sobre su construcción, con distintos protagonistas y distintas épocas, e incluso no existe la certeza de que realmente hayan existido. Período de vida: Los Jardines Colgantes de Babilonia perduraron aproximadamente por 436 años. Con la decadencia de Babilonia y el fin del Imperio neobabilónico, los jardines fueron abandonados progresivamente. En el siglo IV a.C., los jardines ya estaban parcialmente en ruinas y totalmente abandonados.
568
3. El Templo de Artemisa en Éfeso
Wikimedia Commons
Ubicación geográfica: Antigua ciudad de Éfeso, a cincuenta kilómetros al sur de la moderna ciudad portuaria de EsmirnaIzmir, en Turquía, en el valle a los pies de Ayasoluk. Período de construcción: Entre 120 y 150 años. Construido alrededor del año 550 a.C. Patrocinador: Creso81, el poderoso rey de Lidia, que financió una gran parte del proyecto con su legendaria riqueza (se conservan fragmentos de tres de sus inscripciones de donación). Sin embargo, hay versiones que indican que se construyó con la contribución de los habitantes de Éfeso. Encargado y principales involucrados: Diseñado por el arquitecto griego Quersifrón 82. Fue terminado por Metágenes83, con ayuda de Teodoro84, el arquitecto del Hereo de Samos. Dicen antiguos escritos que, durante la ejecución del proyecto, Quersifrón 82 tuvo que enfrentarse a algunas dificultades técnicas que le hicieron pensar incluso en suicidarse. Cuentan que, agotado con estos pensamientos, vio en sueños durante la noche a la diosa a la que estaba dedicando el templo y que le ordenó que viviera, que ella ya había realizado los ajustes en la obra. Y así apareció la mañana siguiente.
569
Objetivo del proyecto: Levantar un santuario a la diosa Artemisa. Anteriormente, las poblaciones locales ya practicaban el culto a la diosa madre o a Cibeles, culto al que después se asimiló el de Artemisa. Características técnicas: Aunque hay discrepancias sobre su tamaño, se calcula que el templo contaba con 115 metros de largo por 55 de ancho. Realizado principalmente en mármol, fue el más grande de todo el mundo griego. Constaba de 127 columnas, hechas cada una por encargo de distintos reyes, contando cada una con 18 metros de alto. Requisitos del proyecto: Debería levantarse sobre terreno pantanoso para que no padeciera los terremotos ni tuviera que temer por las fallas. Y, a su vez, para no situar los cimientos de tan gran mole en terreno resbaladizo e inestable se debería cubrir con carbones apisonados y luego con vellones de lana. Curiosidades acerca del proyecto: El templo de Artemisa se encontraba en una próspera región, que cruzaban viajeros y mercaderes de toda Asia Menor. Fue influenciado por varias creencias, y era un símbolo de fe para mucha gente. Los efesios adoraban a Cibeles, e incorporaron gran parte de sus creencias al culto de Artemisa. El dúo ArtemisaCibeles distaba mucho de su equivalente romano Diana. El culto de Artemisa atrajo miles de adoradores de todas partes del mundo conocido. Periodo de vida: El templo de Éfeso perduró aproximadamente por 200 años. Fue destruido por un incendio provocado por Eróstrato 85 en el año 356 a.C. Su intención era verse famoso por toda la tierra, por haber incendiado un templo tan majestuoso. Por causa de este hecho, hoy en día, el habito de cometer delitos guiado por la ansia de reconocimiento se conoce como “Erotratismo”.
570
4. La Estatua de Zeus en Olimpia
Wikimedia Commons
Ubicación geográfica: Santuario de Olimpia, Grecia. Período de construcción: Diez años. Elaborada alrededor del año 430 a.C Patrocinador: Algunas obras atenienses, incluida la estatua de Zeus, fueron aparentemente encargo de Pericles86. Encargado y principales involucrados: La estatua de Zeus fue una creación del escultor clásico Fidias87. Objetivo del proyecto: Construir un templo dedicado al culto y adoración a Zeus, el “padre de los dioses y los hombres”, que gobernaba a los dioses del monte Olimpo. Mano de obra: Básicamente el trabajo ha sido en su totalidad realizado por el propio Fidias87.
571
Características técnicas: La estatua, de carácter criselefantino, ocupaba la totalidad del ancho del pasillo del templo construido para albergarla. De acuerdo con una fuente contemporánea medía aproximadamente doce metros de alto. Zeus aparecía sentado en un trono con el torso desnudo y el manto en torno a las piernas, llevaba la cabeza coronada de olivo y la mirada, dirigida hacia abajo le confería aspecto paternal. En la mano izquierda sostenía una Niké y en la derecha el cetro rematado por un águila; el manto estaba adornado de lirios y las sandalias eran de oro. El trono, hecho a base de marfil, ébano, oro y piedras preciosas; el respaldo, los brazos, las patas y los travesaños entre ellas iban labrados y decorados con relieves posteriormente copiados y reproducidos por separado. Curiosidades acerca del proyecto: Cuenta la leyenda que cuando Fidias87 terminó de construir la estatua, le pidió a Zeus una señal de aprobación de su obra. El dios respondió enviando un rayo a los pies del escultor dejando una grieta en el suelo que, durante años, sería protegida con una urna. Período de vida: A diferencia de algunas de las Maravillas del Mundo Antiguo, esta perduraría durante unos mil años. No se sabe bien cuál fue el final de esta estatua. Hay quienes afirman que fue destruida durante los terremotos del siglo VI d.C., otros aseguran que fue destruido durante el incendio provocado por los fanáticos cristianos en el siglo 5 d.C.
572
5. El Mausoleo de Halicarnaso
Wikimedia Commons
Ubicación geográfica: Halicarnaso, actual Bodrum, en Turquía. Antigua ciudad griega, situada en la costa sudoccidental de Caria (Asia Menor) en el mar Egeo, en una posición privilegiada entre el golfo Cerámico y el golfo de Cos. Período de construcción: Terminada alrededor de 353 a.C. Patrocinador: Artemisia II de Caria88, esposa y, a la vez, hermana de Mausolo89. Encargado y principales involucrados: Según algunos registros escritos por el arquitecto romano Vitrubio, “Mausolo89 permitió que los arquitectos a quienes hizo su encargo hicieran una especie de concurso cerrado entre los artistas más importantes de la epoca. Por lo tanto, los artistas Escopas90, Leocares91, Bryaxis92 y Timotheo93, asumieron un lado para, en competición con los demás, adornarlo y hacer una exhibición de arte”. Objetivo del proyecto: Construir un mausoleo en honor a Mausolo89, Sátrapa de Caria.
573
Mano de Obra: Los arquitectos mencionados anteriormente. Escopas90 cinceló el lado oriental, el septentrional Bryaxis92, Timotheo93 el lado sur y el oste Leocares91. Características técnicas: Se trata de una estructura rectangular de treinta por cuarenta metros, sobre ella 117 columnas jónicas en dos hileras sosteniendo el techo en forma de pirámide escalonada, y sobre este último la estatua de una cuadriga con las efigies del rey y la reina, alcanzando en conjunto unos 50 metros de altura. Para completar esta obra, se tallaron figuras y relieves en su estructura. El número total de estatuas ascendió a 444, aproximadamente. Curiosidades acerca del proyecto: El término “mausoleo” que nosotros utilizamos par indicar una tumba suntuosa, procede directamente de la de Mausolo. Periodo de vida: Perduró por aproximadamente 1750 años, soportando las invasiones y la destrucción de la ciudad por parte de los bárbaros y los árabes, pero, finalmente, fue destruido por un terremoto en el año 1404. La estatua superior y algún friso se salvaron, hoy se puede admirar en el Museo Británico en Londres.
574
6. El Coloso de Rodas
Wikimedia Commons
Ubicación geográfica: Isla de Rodas, Grecia. Período de construcción: Doce años. Entre 294 a.C. y 282 a.C. Patrocinador: La ciudad de Rodas. Para poder pagar esta obra se vendió el material de asedio del enemigo, que en su rápida huida había dejado abandonado. Acorde con registros de la época, se cuenta que la obra ha costado cerca de trescientos talentos. Encargado y principales involucrados: El escultor Cares de Lindos94. Objetivo del proyecto: Celebrar las victorias militares de la ciudad de Rodas sobre el ejército macedonio, erigiendo una estatua gigantesca al dios Helios, protector de la ciudad.
575
Características técnicas: La estatua estaba hecha de bronce y medía más de 30 metros de altura, superando más del doble a la estatua de Zeus en Olimpia. Colocada sobre una base de mármol, tenía una antorcha en la mano y rayos solares como atributo del dios Helios. La obra se llevó a cabo in situ, empleando molduras de terracota para después fundir el metal. Cares94 y sus colaboradores emplearon quince toneladas de bronce y nueve toneladas de hierro. Requisitos: del proyecto: Construir una colosal escultura que representara a Helios, dios venerado en Rodas, en acción de gracias por haber ayudado a conseguir la victoria. Debería estar situada en el puerto en un lugar estratégico y visible para todos los barcos que se acercaban a la isla. Curiosidades acerca del proyecto: Durante muchos años se creyó que la estatua había sido erigida con una pierna apoyada en cada parte del muelle de Rodas como aparece en algunas imágenes. Sin embargo, no parece que haya sido realmente así por dos razones: Si hubiera sido erigida allí, se habría hundido por su propio peso. La otra razón es que para su construcción tendrían que haber cerrado un muelle de gran importancia militar durante varios años, siendo vulnerables a ataques por mar. Período de vida: 66 años después de su construcción, en el año 216 a.C, un terremoto derribó la colosal obra. Los habitantes de Rodas decidieron dejar sus restos en el mismo lugar donde cayeron por seguir el designio de un oráculo. Y así quedaron los restos de la estatua por novecientos años aproximadamente, hasta que en el año 654 los musulmanes se apoderaron del bronce como botín en una de sus incursiones.
576
7. El Faro de Alejandría
Wikimedia Commons
Ubicación geográfica: Isla de Pharos. Alejandría, Egipto. Período de construcción: 38 años. Entre 294 a.C. y 283 a.C. Patrocinador: El faraón de la dinastía ptolemaica, Ptolomeo II Filadelfio95. Encargado y principales involucrados: El arquitecto Alva-eratus96. Objetivo del proyecto: Servir como punto de referencia del puerto y como faro. Características técnicas: Su altura alcanzaba los 134 metros y en su construcción se utilizaron grandes bloques de vidrio que fueron situados en los cimientos para evitar la erosión y aumentar la resistencia contra la fuerza del mar. El edificio, erigido sobre una plataforma de base cuadrada, era de forma octogonal y estaba construido con bloques de mármol ensamblados con plomo fundido. En la parte más alta un gran espejo metálico reflejaba la luz del sol durante el día, y por la noche proyectaba la luminosidad de una gran hoguera a una distancia de hasta cincuenta kilómetros.
577
Requisitos: del proyecto: Levantar una gigantesca torre sobre la que una hoguera nocturna marcaba la posición de la ciudad a los navegantes, dado que la costa en la zona del delta del Nilo es muy llana y se carecía, por tanto, de cualquier referencia para la navegación marítima. Curiosidades acerca del proyecto: Período de vida: El Faro perduró alrededor de 1.500 años, hasta que los terremotos de 1303 y 1323 lo redujeron a escombros; en el año 1480, sus restos fueron reutilizados en la construcción de una fortaleza cercana. De las siete maravillas solo tres fueron destruidas por causas naturales: el Faro de Alejandría, el Coloso y el Mausoleo, que fueron víctimas de terremotos. El Artemision de Éfeso fue destruido por vandalismo humano, y debemos suponer que otras dos también, los jardines colgantes de Babilonia, reducidos a ruinas junto con la ciudad, y la estatua de Zeus en Olimpia destruida para evitar el culto pagano después de que el imperio romano se convirtiera al cristianismo. Incluso la Gran Pirámide ha sufrido a lo largo de los siglos la sustracción de su revestimiento de blanca piedra caliza de Tura (Egipto). Fuentes: Discovery Channel, National Geographic y Wikipedia.
578
Apéndice C Personas men cionadas Las personas que aparecen en la lista que se expone a continuación han sido mencionadas a lo largo de toda esta obra. Todos ellos han contribuido, de alguna forma, en el enriquecimiento y comprensión de la que ponemos llamar “filosofía” del Project Management. Algunos de manera totalmente inconsciente como es el caso de Lucas el evangelista3, que curiosamente describe en la Biblia los problemas resultantes de la falta de planificación financiera para la construcción de una torre; o el faraón egipcio Necherjet5, que fue el patrocinador de la construcción de la primera grande pirámide escalonada de la historia. Por supuesto están los grandes autores del Project Management como Bernard Schrivier6, Eric Verzuh 2, o Davidson Frame7. Y por último, pero no menos importantes, no podrían dejar de estar presentes en este grupo de notables inventores de técnicas y teorías revolucionarias, como John Venn11, Wilfredo Pareto32, Joseph Novak60 o Peter Drucker43. No quise limitarme solamente en citarlos, y por ello, facilito una mini biografía de cada uno a continuación. (Fuente: www.wikipedia.org) LAO TSÉ (Nacimiento y muerte desconocidos). También llamado Lao Tzu o Lao Tsi, una figura cuya existencia histórica se debate, es uno de los filósofos más relevantes de la civilización china. La tradición china establece que vivió en el siglo VI aC, pero muchos eruditos modernos argumentan que puede haber vivido aproximadamente en el siglo IV aC, durante el período de las Cien Escuelas del Pensamiento y los Reinos Combatientes. Se le atribuye haber escrito el “Dao De Jing” o “Tao Te Ching”, obra esencial del taoísmo. De acuerdo con este libro, “Dao” o “Tao” (el Camino) puede verse cómo el cambio permanente y éste es la verdad universal. Dentro de las dudas sobre su existencia y la etapa histórica en la que vivió, se cree que pudo ser contemporáneo de Confucio. Mencionado en el capítulo 1 por su pensamiento “Un viaje de mil millas comienza con el primer paso”, que puede ser aplicado en muchos ámbitos de nuestras vidas y sobre todo en comienzo del ciclo de vida de un proyecto. 1
*
ERIC VERZUH ( Seatle, Estados Unidos). Presidente de la empresa Versatile Company, que provee formación y consultoría en Project Management, y cuyos principales clientes son: Lockheed Martin, Microsoft, Nordstrom, Adobe Systems y el Servicio Postal Americano. Es además el autor de muchas obras, entre ellas el libro “The Fast Forward MBA in Project Management”. Mencionado en los capítulos 1 y 3 por sus aportaciones al Project Management presentes en muchas de sus obras académicas. 2
*
?
LUCAS, EL EVANGELISTA ( Antioquia, siglo primero de nuestra era – Beocia 84 d.C). De padres paganos probablemente de ascendencia griega, poseía una gran cultura, era médico de profesión y gran conocedor de las costumbres judías. Conoció a Cristo a través del apóstol San Pablo y se convirtió en uno de sus discípulos más queridos. San Lucas aparece por primera vez en el relato bíblico en el Libro de los Hechos de los Apóstoles en Tróada (16, 10), donde se encontró con San Pablo, Silas y Timoteo, y juntos emprendieron viaje hacia Macedonia, comenzando así su trabajo misionero. Mencionado en el capítulo 1 por el curioso pasaje bíblico descrito en su evangelio, que describe los problemas resultantes de la falta de planificación financiera para la construcción de una torre. 3
579
*
?
IMHOTEP ( 2690 2610 a.C aproximadamente). Arquitecto y médico egipcio del rey Djeser o Zoser, de la III dinastía egipcia. De origen plebeyo, hijo del también arquitecto Kanefer y de Kherduankh, según una inscripción hallada en el “Uadi Hammamat”, llegó a alcanzar, gracias a su valía personal, un significativo puesto en la Corte real, y llegó a actuar como consejero personal del rey a plena satisfacción de aquél. Durante siglos, los egipcios consideraron a Imhotep como el dios de la medicina y la sabiduría y se le representa sentado, como a los escribas, con un papiro desplegado sobre sus rodillas, tocado con un casquete. En el Imperio Nuevo fue venerado como patrón de los escribas y deificado en el periodo tardío de Egipto, para lo cual fue identificado con Nefertum, hijo de Ptah y Nut (o Sejmet). Posteriormente se le vinculó al dios Thot – una práctica común en el Antiguo Egipto. Mencionado en el capítulo 1 por tratarse de uno de los primeros encargados de un monumental proyecto de construcción, que fue la pirámide escalonada de Saqqara. 4
NECHERJET (Nacimiento y muerte desconocidos). Segundo faraón de la tercera dinastía, y del Imperio Antiguo de Egipto. Gobernó de 2665-2645 a.C. Célebre por haber encargado a su “chatir”, Imhotep, la construcción del complejo de la pirámide escalonada de Saqqara, considerado el primer gran complejo monumental en piedra de Egipto y del mundo. Algunos eruditos creen que fue el primer faraón de esta dinastía, y señalan que el orden en que algunos predecesores de Jufu (Keops) se mencionan en el Papiro Westcar sugiere que Sanajt (Nebka) debió reinar entre Dyeser y Huny. Aunque Manetón cita a Nekerofes, denominado Nebka en el Canon de Turín, como el primer gobernante de la dinastía III de Egipto. Mencionado en el capítulo 1 por encargar y patrocinar uno de los primeros grandes proyectos de construcción de la humanidad, el complejo de la pirámide escalonada de Saqqara. 5
*
?
BERNARD SCHRIEVER ( Bremen, Alemania en 1910 Washington, Estados Unidos en 2005). Fue General de la Fuerza Aérea Estadounidense y un iingeniero aeronáutico de profesión. Destacó como administrador, supervisor y gerente cuya intensa colaboración ha ayudado a la Fuerza Aérea a reestructurar y racionalizar el enfoque de investigación, desarrollo y producción de su armamento de alta tecnología en la década de 1950 y 60. Ha liderado uno de los proyectos más importantes de esta época, que fue el desarrollo del primer misil balístico intercontinental, que era capaz de llevar una ojiva nuclear y podía alcanzar miles de kilómetros. Mencionado en el capítulo 1, por su contribución al Project Management actual, desarrollando durante la guerra fría el concepto de “concurrencia”, integrando todos los elementos del plan de desarrollo en un solo programa y presupuesto, ejecutándolos y controlándolos en paralelo y no secuencialmente. 6
DAVIDSON FRAME. Es Decano Académico de la Universidad de Administración y Tecnología (UMT) y Vicepresidente del Grupo Yankee Clipper. Antes de unirse a la UMT, Frame fue profesor de Gestión de la Ciencia y Presidente del Departamento de Gestión de la Ciencia en la Escuela de la Universidad George Washington de Ciencias Empresariales y Gestión Pública. Mencionado en el capítulo 1 por sus aportaciones al Project Management presentes en muchos de sus libros. 7
JASON CHARVART. Consultor de Project Management y Gerente Senior de RCG Information Technology, Inc., empresa líder en servicios profesionales de TI, desarrollo de aplicaciones, gestión e integración de soluciones informáticas. Posee una amplia experiencia internacional en proyectos gubernamentales, de industrias farmacéuticas y telecomunicaciones. Desde hace más de diez años, Charvat ha liderado equipos de desarrollo para ofrecer soluciones de TI con éxito. Miembro activo del Project Management Institute, es además el autor de innúmeras obras relacionadas con Project Management. Mencionado en el capítulo 1 por sus aportaciones al Project Management presentes en muchas de sus libros. 8
580
GERRY JOHNSON. Considerado como uno de los profesores más respetados de Europa en Dirección Estratégica. Ha ocupado cargos académicos en las escuelas de negocios más importantes del Reino Unido, incluyendo la Manchester Business School, la Cranfield School of Management, la Strathclyde Business School y la Lancaster University Management School. Es también uno de los autores de uno de los libros de management más vendidos en Europa, “Exploring Corporate Strategy” (Prentice Hall, 8th Edition, 2008), ampliamente utilizado en la mayoría de las escuelas de negocio británicas y con presencia constante en la lista de los Top 10 en ventas de libros de negocios en el Reino Unido. Mencionado en el capítulo 1 por su contribución al desarrollar la matriz poder/interés, que clasifica los distintos interesados en función de su poder y grado de interés que pueden mostrar en un determinado proyecto. 9
KEVAN SCHOLES. Socio principal de la empresa Scholes Asociados, especializada en desarrollo de gestión estratégica. También es profesor de gestión estratégica en la Sheffield Hallam University y ex director de la Escuela de Negocios de Sheffield. Tiene una amplia experiencia en consultoría de gestión estratégica en los sectores público y privado, tanto en el Reino Unido como en el extranjero. Es el autor del libro más vendido en Europa: “Exploring Corporate Strategy” (Prentice Hall, 8th Edition, 2008), con más de 650.000 ventas en todo el mundo. Ha sido traducido al español, francés, checo y chino. Portugués, ruso y alemán. Mencionado en el capítulo 1 por su contribución al desarrollar la matriz poder/interés, que clasifica los distintos interesados en función de su poder y grado de interés que pueden mostrar en un determinado proyecto. 10
*
?
JOHN VENN ( Drypool, Reino Unido en 1834 Cambridge, Reino Unido en 1923). Fue un matemático y lógico británico. Destacó por sus investigaciones en lógica inductiva. Es especialmente conocido por su método de representación gráfica de proposiciones (según su cualidad y cantidad) y silogismos. Entre sus obras se destacan: “Symbolic Logic” (1881), “The Logic of Chance” (1866) y “The Principles of Empirical Logic” (1889). Mencionado en el capítulo 1 por una de sus creaciones más conocidas, el “Diagrama de Venn”, que permite una comprobación de la verdad o falsedad de un silogismo. Posteriormente el Diagrama de Venn fue utilizado para mostrar visualmente las operaciones más elementales de la teoría de conjuntos. 11
*
MICHAEL LEVINE ( New York, Estados Unidos en 1954). Es un publicista estadounidense, autor de libros de éxito, y conferenciante. También es fundador y presidente de Levine Communication Office (LCO), una empresa de relaciones públicas con sede central en Los Ángeles. Mencionado en el capítulo 2 por su citación “A menudo, quienes vacilan en hacer planes es porque dudan también en su capacidad de cumplir”, que hace referencia a la capacidad que un profesional debe tener en cumplir los planes que establece. 12
*
TOM DEMARCO ( Pennsylvania, Estados Unidos en 1940). Ingeniero de software americano, autor, profesor y ponente en congresos referentes a la ingeniería de software. Es conocido como uno de los desarrolladores de análisis estructurado en la década de los 80. Mencionado en el capítulo 2 por su citación “Una estimación es una predicción que tiene la misma probabilidad de estar por encima o por debajo del valor actual”, que define claramente el concepto de estimación. 13
*
?
FRANCIS BACON ( Londres, Inglaterra en 1561 Ibídem en 1626). Filósofo y político inglés. Conocido como el más influyente y versátil escritor inglés del siglo XVII, sus obras abarcaban un gran número de materias, incluidas la ética, filosofía, ciencia, derecho, historia y política. Bacon fue un hombre decisivo para el alcance del pensamiento científico moderno, al desarrollar un proceso de razonamiento llamado inducción, este proceso consiste en obtener conclusiones 14
581
generales a partir de situaciones particulares. Mencionado en el capítulo 3 por su citación “El requisito del éxito es la prontitud en las decisiones”, que enfatiza la importancia de tomar las decisiones correctas.
582
ERIC BONABEAU. Es internacionalmente conocido como uno de los principales expertos en sistemas complejos y soluciones de problemas adaptativos. Es conocido además por su capacidad de aplicar los conceptos complexos de la ciencia en los problemas del mundo real. Su trabajo se centra en los límites de la toma de decisiones en un mundo complejo, descentralizado e impredecible. Mencionado en el capítulo 3 por su definición acerca de la intuición, que aunque es importante, no sustituye la experiencia y los conocimientos acumulados de un profesional. 15
WILLIAM E. SOUDER. Profesor de ingeniería industrial y Director del grupo de estudios de gestión de tecnología de la Universidad de Pittsburgh. Mencionado en el capítulo 3, por mencionar algunos de los requisitos más importantes para elegir correctamente un criterio de selección de proyectos. 16
JACK R. MEREDITH. Profesor universitario de Management, PHD en Business Administration por la University of California. MBA en Operations Management por la Universidad of California entre otros títulos académicos. Es además coautor de las obras: Project Management in Practice, Project Management: A Managerial Approach. Mencionado en el capítulo 3 por sus aportaciones al Project Management presentes en muchos de sus libros. 17
*
THOMAS LORIE SAATY ( Mosul, Irak en 1926). Matemático, es actualmente profesor de la Universidad de Pittsburgh y en la Katz Graduate School of Business. Ha sido también consultor de agencias gubernamentales americanas como el Pentágono y también de empresas privadas. El Profesor Saaty es miembro de la National Society of Engineering desde 2005 y de la Real Academia de Ciencias Exactas, Físicas y Naturales desde 1971. En 1973 ha sido galardonado con el premio Lester Ford de la Mathematical Association of America y en 2008 ha recibido la medalla de oro de la International Society on Multi-Criteria Decision Making. Mencionado en el capítulo 3 por ser el inventor del Proceso Analítico Jerárquico, desarrollado para facilitar el proceso de toma de decisiones con múltiplos criterios. 18
VIRGINIA BURDEN TOWER. Escritora estadounidense, autora del libro “The Process of Intuition”. Mencionada en el capítulo 4 por su citación “La cooperación es la convicción plena de que nadie puede llegar a la meta si no llegan todos”, que refleja la importancia del sentido común y de la integración, como uno de los factores de éxito de un proyecto. 19
*
WINSTON CHURCHILL ( Palacio de Blenheim, Inglaterra en 30 de noviembre de 1874 Londres, Inglaterra en 24 de enero de 1965). Sin lugar a dudas, una de las figuras clave del siglo 20. Su larga trayectoria política abarca desde su primera elección como diputado en 1904 hasta su último periodo como primer ministro en 1951. Gran figura del partido conservador británico, aunque también pasó por las filas del partido liberal. Su trascendencia histórica se debe indudablemente a su papel en la Segunda Guerra Mundial, cuando dirigió al Reino Unido en su lucha contra Hitler. Mencionado en los capítulos 5 por su citación “No tiene sentido decir que lo hacemos lo mejor que podamos. Tenemos que lograr hacer lo que es necesario”, que define claramente que la asignación de un Project a un proyecto, le otorga asumir un compromiso de hacer las cosas bien y dar al cliente un producto o servicio que cumpla exactamente con sus expectativas. En el capítulo 10, Churchill es mencionado por su citación “Una buena conversación debe agotar el tema, no a sus interlocutores”, que resume la importancia de las buenas relaciones entre las personas y la importancia de una comunicación sana. Y finalmente, en el capítulo 11, se cita Winston Churchill en la definición de “War Room”, lugar donde por ejemplo un General se reúne con su mando para desarrollar y dar seguimiento a tácticas, planes y estrategias de combate, antes de su ejecución en el campo de batalla. Hoy en día, el “War Room” es la sala de reuniones donde se establecen la estrategia de planificación, ejecución y seguimiento de un proyecto. 20
583
DIANE E. PAPALIA. PhD en psicología del desarrollo durante el transcurso de la vida en la Universidad de West Virginia, ha escrito numerosos artículos para publicaciones profesionales como Human Development, International Journal of Aging and Human Development, Sex Papeles, Journal of Experimental Child Psychology y Journal of Gerontology. La mayoría de estos artículos han estado relacionados con su principal área de investigación, el desarrollo cognitivo desde la infancia hasta la vejez. Es miembro del Gerontological Society of America. Mencionada en el capítulo 5 por sus definiciones acerca de la creatividad, muy utilizada y extremadamente necesaria en el proceso de recopilación de requisitos. 21
*
?
CYRIL NORTHCOTE PARKINSON ( County Durham, Inglaterra en 30 de julio de 1909 Kenty, Inglaterra en 9 de marzo de 1993). Fue un historiador británico y autor de unos sesenta libros. Estos incluyeron ficción histórica, muchas veces basada en el período napoleónico, e historias marinas. Es aún más famoso por su sátira de las instituciones burocráticas, notablemente su “Parkinson's Law and other studies”. (La Ley de Parkinson y otros estudios). Se trata de una colección de estudios cortos explicando la inevitabilidad de la expansión burocrática, e incluye una nota sobre por qué es natural conducir por el lado izquierdo de la calle. En los años 30 Parkinson predijo, con éxito, que la Marina Real llegaría a tener más almirantes que barcos. Mencionado en el capítulo 6 por su artículo publicado en el semanario británico “The Economist” en 1955 que dice que “El trabajo se amplia para cubrir todo el tiempo disponible para su conclusión”. O sea, si una determinada tarea tiene un plazo estimado de 6 días y se añaden 2 días más como contingencia, según la Ley de Parkinson, está tarea llevará 8 días para ser completada. 22
*
DR. ELIYAHU GOLDRATT ( Israel en 31 de marzo de 1948). Físico, científico, educador y líder de negocios. Es mundialmente conocido por sus obras “La Meta”, “No es cuestión de suerte”, “Cadena Critica”, “Necesario pero no suficiente”, “El Síndrome de Pajar”, entre otros. Gold ratt es uno de los pioneros en la creación de softwares de programación de producción como el Optimized Production Technology – OPT. Su filosofía es la de estimular las personas a pensar a través de soluciones sencillas y de sentido común. La revista “Fortune” ha descrito a Eliyahu M. Goldratt como un "gurú de la industria" y la revista “Business Week” como un genio. Mencionado en el capítulo 6 por ser el creador de “Cadena Critica”, una técnica innovadora que permitiría completar los proyectos en un tiempo significativamente más corto que utilizando las técnicas tradicionales de administración de proyectos. 23
*
?
HENRY LAURENCE GANTT ( Maryland, Estados Unidos en 1861 Nueva York, Estados Unidos en 23 de noviembre de 1919). Fue un ingeniero industrial mecánico estadounidense. Fue discípulo de Frederick Winslow Taylor, siendo colaborador de éste en el estudio de una mejor organización del trabajo industrial. Sus investigaciones más importantes se centraron en el control y planificación de las operaciones productivas mediante el uso de técnicas gráficas, entre ellas el llamado diagrama de Gantt, popular en toda actividad que indique planificación en el tiempo. Su obra principal, publicada en 1913, se titula "Work, Wages and Profits" (Trabajo, Salarios y Beneficios). Fue uno de los más inmediatos seguidores de Taylor, con quien trabajó durante 14 años. Sin embargo, en el momento en que las teorías de Taylor comenzaron a ser duramente criticadas de deshumanizadas, Gantt mostró un especial interés – no sólo teórico sino práctico – por el aspecto humano. También enfatizó la importancia de la capacitación y el entrenamiento para el mejor desarrollo de los trabajadores. Mencionado en el capítulo 6 por ser el creador del Grafico de Barras de Gantt, herramienta permite visualizar de manera sencilla el periodo de duración de cada actividad, sus fechas de inicio y fin y también el tiempo total requerido para la ejecución del trabajo. 24
584
*
?
MENANDRO ( Atenas, Grecia en 342 a.C Ibídem, en 292 a.C). Máximo representante de la comedia nueva ateniense junto con Filemón de Siracusa (o de Soli), Dífilo, Apolonio de Caristos, Posidonio de Casandra y escribió ciento cinco piezas, de las cuales una ha llegado a nuestros tiempos completa, Arisco (Dyskolos), y seis casi enteras, Arbitraje, Detestado, Escudo, Rapada, Samia y Sicionio (títulos originales, Epitrépontes, Misoúmenos, Aspís, Perikeiroméne, Samia, Sicyonios), así como escenas sueltas de 18. Mencionado en el capítulo 7, por su citación “Bienaventurado el que tiene talento y dinero, porque empleará bien este último”. Esta frase traduce una situación muy común que ocurre en proyectos que cuentan con mucho presupuesto, y por esta razón, mal administran los gastos. 25
*
?
FRIEDRICH VON WIESER ( Viena, Austria en 1851 Salzburgo, Austria en 22 de julio de 1926). Economista y sociólogo austriaco, fue uno de los más destacados de su tiempo. Considerado, junto con Carl Menger y Eugen von Böhm-Bawerk, uno de los fundadores de la Escuela austríaca por lo que teóricamente se lo asocia al liberalismo económico, mientras que por otro lado sería la cabeza visible del denominado nuevo liberalismo (término peyorativo usado por parte de algunos liberales para descalificar a lo que ellos consideran socialistas "liberales") desde el criterio de Mises. Era partidario del socialismo fabiano y apoyaba el individualismo económico como camino hacia la Economía Social, a medio camino entre el liberalismo clásico y las corrientes económicas socialistas. Mencionado en el capítulo 7, por su definición de “coste alternativo”, que designa el coste de la inversión de los recursos disponibles, en una oportunidad económica, a costa de las inversiones alternativas disponibles, o también el valor de la mejor opción no realizada. 26
WOLTER J. FABRYCKY. Profesor Emérito de Ingeniería Industrial y de Sistemas por la Universidad Virginia Tech y Presidente de la Academic Applications International. Es coautor de algunas obras de la editora americana Prentice Hall y coeditor, desde 1972, de Prentice Hall International Series, editorial líder mundial en publicaciones educativas. Mencionado en el capítulo 7 por definir en su obra “Análisis del Coste del Ciclo de Vida de los Sistemas”, las principales categorías de costes. 27
*
?
JOHN RUSKIN ( Londres, Reino Unido en 8 de febrero de 1819 Brantwood, Reino Unido en 20 de enero de 1900). Fue escritor, crítico de arte y crítico social británico. También fue un poeta y artista. Algunos ensayos de Ruskin sobre el arte y la arquitectura fueron muy influyentes en la época victoriana. El pensamiento de Ruskin está ligado a la época romántica, movimiento literario e ideológico (finales del siglo 18 hasta mediados del siglo 19), y hace hincapié en la sensibilidad emocional y subjetiva, en contra de la razón. Estéticamente, Ruskin se presenta como una reacción al clasicismo y la admiración de medievalismo. En su definición de la restauración de la histórica, considerada la destrucción real de lo que no puede ser salvado, no la parte menos, una destrucción acompañada de una descripción falsa. A partir de 1851, fue uno de los primeros y patrona de la Hermandad pre-Rafaelita, inspirando la creación del movimiento Arts & Crafts . Mencionado en el capítulo 8, por su citación “La calidad nunca es un accidente, siempre es el resultado de un esfuerzo de la inteligencia”. La calidad es un logro muy difícil de alcanzar y depende del estricto cumplimiento de una serie de factores, sobre todo, entender claramente las necesidades del cliente. 28
585
SUN TZU (Nacimiento y muerte desconocidos). Es el autor de El arte de la guerra, un influyente libro chino sobre estrategia militar principalmente, abarcando también la táctica. Es también uno de los primeros realistas en ciencias políticas. Existe sólo una fuente antigua sobre la vida de Sun Tzu; la biografía escrita en el siglo II a.C, por el historiador Sima Qian, en los capítulos Shìji ā de sus Memorias históricas. De ella se deduce que Sun Tzu nació hacia el 544 a.C. en el estado de Qi, uno de los Reinos Combatientes de la historiografía tradicional china. Después de haber combatido en diversas regiones, el gobernante del estado de Wu; el rey Helu solicitó sus servicios como general en el año 512 a. C. Como resultado de su experiencia militar al servicio del monarca, Sun Tzu redactó "El arte de la Guerra", un libro sobre tácticas y estrategias militares. Mencionado en el capítulo 8, por su citación “Conoce a tu enemigo y conócete a ti mismo; en cien batallas, nunca saldrás derrotado. Si eres ignorante de tu enemigo pero te conoces a ti mismo, tus oportunidades de ganar o perder son las mismas. Si eres ignorante de tu enemigo y de ti mismo, puedes estar seguro de ser derrotado en cada batalla”, que define ligeramente el concepto de la técnica del Benchmarking, que pretende descubrir y definir los aspectos que hacen que una organización sea más rentable que otra, o que tenga productos y servicios mejores, a través del estudio de empresas del mismo sector. 29
30
WILLIAM EDWARD DEMING (
* Sioux City Iowa, Estados Unidos en 14 de octubre de 1900 -
? Washington DC, Estados Unidos en 20 de diciembre de 1993). Estadístico estadounidense, profesor universitario, autor de textos, consultor y difusor del concepto de calidad total. Su nombre
está asociado al desarrollo y crecimiento de Japón después de la Segunda Guerra Mundial. La mayor contribución de Deming a los procesos de calidad es el control estadístico de proceso, que es un lenguaje matemático con el cual los administradores y operadores pueden entender "lo que las máquinas dicen". Las variaciones del proceso afectan el cumplimiento de la calidad prometida. Mencionado en el capítulo 8 por sus contribuciones a las técnicas de control de calidad, pero sobre todo por ser el creador del “Ciclo Deming”, cuya función es crear una estrategia de mejora continua de la calidad en cuatro etapas
*
?
WALTER ANDREW SHEWHART ( Illinois, Estados Unidos en 18 de marzo de 1891 New Jersey, Estados Unidos en 11 de marzo de 1967). Fue un físico, ingeniero y estadístico estadunidense. Es considerado por muchos como el verdadero padre de la calidad, aunque algunos le nombran más bien "el abuelito", ya que fue maestro de los otros dos "padres": Deming y Juran. Shewhart es el creador de los famosos gráficos de control estadístico de procesos (CEP), paso inicial hacia lo que el denominó la formulación de una base científica para asegurar el control económico, plasmada en su obra "Economic Control of Quality of Manufactured Products" (Control Económico de la Calidad de Productos Manufacturados), publicado en 1931. Durante los años 90 la genialidad de Shewhart fue "redescubierta" por una tercera generación de administradores, llamándola la metodología Six Sigma. Mencionado en el capítulo 8 por ser considerado el padre del control estadístico de la calidad, además de ser el inventor de los conocidos gráficos de control. 31
*
?
WILFREDO PARETO ( Paris, Francia en 15 de julio de 1848 Ginebra, Suiza en 19 de agosto de 1923). Realizó importantes contribuciones al estudio de la economía y de la sociología, especialmente en el campo de la distribución de la riqueza y el análisis de las elecciones individuales. Fue el creador del concepto de eficiencia de Pareto, y contribuyó al desarrollo de la microeconomía, con ideas como la de la curva de indiferencia. Es famoso por su observación de que, en Italia el 20% de la población poseía el 80% de la propiedad, que posteriormente J. Juran y otros la harían popular como el principio de Pareto y generalizarían bajo el concepto de distribución de Pareto. Mencionado en el capítulo 8 por ser el inventor del “Diagrama de Pareto”, una técnica de organización de datos, que permite mostrar gráficamente el principio de Pareto (pocos vitales, muchos triviales), es decir, que hay muchos problemas sin importancia frente a unos pocos graves. 32
586
Mediante la gráfica colocamos los "pocos vitales" a la izquierda y los "muchos triviales" a la derecha.
587
*
?
JOSEPH MOSES JURAN ( Brăila, Rumania en 24 de diciembre de 1904 Nueva York, Estados Unidos en 28 de febrero de 2008). Conocido por muchos como “El Padre” de la Calidad. La mayor contribución de Juran a nuestro mundo actual se ha dado en el campo de la administración, particularmente la administración por Calidad. Observador astuto, atento escucha, sintetizador brillante y un pronosticador sensible, se le ha llamado "padre de la calidad", "gurú de calidad". Tal vez lo más importante es que se le reconoce como la persona que añadió la dimensión humana a la calidad, ampliándola de sus orígenes estadísticos a lo que ahora llamamos Administración de la Calidad Total. Aunque el nombre de Juran ha tenido menos exposición que el de otros, su impacto en los gerentes, negocios, naciones y productos y servicios que compramos y utilizamos cada día, ha sido profunda. Mencionado en el capítulo 8 por sus innúmeras contribuciones al control de calidad. 33
*
?
KAORU ISHIKAWA ( Tokyo, Japón en 13 de julio de 1915 Ibídem, en 16 de abril de 1989). Teórico japonés de la administración de empresas, experto en el control de calidad. Se le considera el padre del análisis científico de las causas de problemas en procesos industriales, dando nombre al Diagrama Ishikawa, cuyos gráficos agrupan por categorías todas las causas de los problemas. Fue el primer autor que intentó destacar las diferencias entre los estilos de administración japoneses y occidentales. Su hipótesis principal fue que diferentes características culturales en ambas sociedades fueron claves en el éxito japonés en calidad. Mencionado en el capítulo 8 por ser el creador del “Diagrama de Causa-Efecto”. Consiste en una técnica que organiza y representa las diferentes teorías propuestas sobre las causas de un problema y se utiliza en las fases de diagnóstico y solución de una determinada causa. 34
*
?
*
?
RONALD FISHER ( Londres, Inglaterra en 17 de febrero de 1890 Adelaide, Australia en 29 de julio de 1962). Científico, matemático, estadístico, biólogo evolutivo y genetista inglés. Fisher realizó muchos avances en la estadística, siendo una de sus más importantes contribuciones, la inferencia estadística creada por él en 1920. Mencionado en el capítulo 8, por ser el creador de la técnica “Diseño de Experimentos”, método estadístico que identifica los factores que pueden influir en variables específicas de un producto o proceso en fase de desarrollo de producción. 35
KARL PEARSON ( Londres, Inglaterra en 27 de marzo de 1857 Ibídem, en 27 de abril de 1936). Fue un prominente científico, matemático y pensador británico, que estableció la disciplina de la estadística matemática. Desarrolló una intensa investigación sobre la aplicación de los métodos estadísticos en la biología y fue el fundador de la bioestadística. En 1911 fundó el primer departamento de estadística en la Universidad de Londres, donde fue profesor y donde dirigió el Laboratory of National Eugenics creado por Sir Francis Galton. Fundó en 1902 la revista Biometrika, desde entonces una de las más importantes en el campo de la estadística. Es mencionado en el capítulo 8, por ser la persona que ha creado el término “histograma”, para una herramienta de control de calidad que analiza un gran volumen de datos referentes a una característica que se desea controlar. 36
*
?
EDMUND BURKE ( Dublín, Irlanda en 12 de enero de 1729 Beaconsfield, Inglaterra en 9 de julio de 1797). Es considerado el padre del pensamiento conservador moderno, especialmente en el mundo anglosajón. Es mencionado en el capítulo 9 por su citación “Ningún grupo puede actuar con eficacia si falta el concierto, ningún grupo puede actuar en concierto si falta la confianza, ningún grupo puede actuar con confianza si no se halla ligado por opiniones comunes, afectos comunes, intereses comunes”. Este pensamiento nos conduce a la reflexión de que lo que demanda un proyecto no es al individuo como una unidad, sino a una multiplicidad de individuos coordinados y complementados, de forma que conformen, en sí y por sí mismos, una unidad enfocada hacia un objetivo común y responsable del resultado del mismo. 37
588
*
?
JOSEPH FOLLIET ( Lyon, Francia en 27 de noviembre de 1903 Ibídem, en 12 de noviembre de 1972). También conocido por el seudónimo de Frère Genièvre, fue un católico militante, sociólogo y escritor y co-fundador de la “Compagnons de Saint Fran çois” y fundador de “La Vie Catholique Ilustrée”. Es mencionado en el capítulo 9 por su citación “Por lejos que nos remontemos en el pasado histórico, lo encontramos (al hombre) siempre viviendo en sociedad”. Es decir, desde tiempos muy remotos, el hombre se dio cuenta que no lograría supervivir en un mundo hostil si no se aliara a sus semejantes. Una teoría que pasados siglos de vida en sociedad, ha culminado en lo que conocemos como “networking” o Redes Sociales, muy en boga actualmente en la Internet. 38
*
?
CRISTOBAL COLÓN ( Lugar discutido, entre 1436 y 1456 Valladolid, España, 20 de mayo de 1506). Fue navegante, cartógrafo, almirante, virrey y gobernador general de las Indias al servicio de la Corona de Castilla, famoso por haber realizado el denominado descubrimiento de América, en 1492. Su primera expedición partió el 3 de agosto de 1492 desde el puerto de Palos de la Frontera (Huelva), llegando a Guanahani (hoy en las Islas Bahamas) el 12 de octubre de dicho año. Este hecho impulsó decisivamente la expansión mundial de Europa y la colonización por varias potencias europeas de gran parte del continente americano y de sus pobladores. Es mencionado en el capítulo 9 por ter logrado obtener de los Reyes Católicos los fondos y las condiciones necesarias para llevar a cabo uno de los más trascendentales proyectos de los últimos 600 anos, el descubrimiento de América. 39
*
FERNANDO II DE ARAGÓN, EL CATOLICO ( Sos del Rey Católico, España en 10 de mayo de 1452 Madrigalejo, España en 23 de enero de 1516). Rey de Aragón y de Castilla. Hijo de Juan II el Grande y de su segunda esposa Juana Enríquez. Fue rey de Aragón entre los años 1479 y 1516. Rey de Castilla entre 1474 y 1504 y también regente de la corona castellana entre 1507 y 1516 debido a la inhabilitación de su hija Juana, tras la muerte de Felipe el Hermoso. Rey de Sicilia (1468-1516) y de Nápoles (1504-1516). Es mencionado en el capítulo 9 por ser patrocinador, junto con su esposa, la Reina Isabel I, de los viajes de Cristóbal Colón, que acabaron culminando en el descubrimiento de un nuevo continente. 40
?
*
ISABEL I DE CASTILLA, LA CATOLICA ( Madrigal de las Altas Torres, España en 22 de abril de 1451 Medina del Campo, España en 26 de noviembre de 1504) fue reina de Castilla1desde 1474 hasta 1504, también reina consorte de Sicilia desde 1469 y de Aragón desde 1479. Es mencionada en el capítulo 9 por ser patrocinadora, junto con su esposo, el Rey Fernando II de Aragón, de los viajes de Cristóbal Colón, que acabaron culminando en el descubrimiento de un nuevo continente. 41
?
*
BRUCE WAYNE TUCKMAN ( Estados Unidos, en 1938). Psicólogo estadounidense. Es mencionado en el capítulo 9 por su publicación en 1965 de un breve artículo titulado “Desarrollo secuencial en grupos pequeños”, que se trata de un modelo que llegó a ser muy influyente en la teoría de desarrollo de grupos y que actualmente la conocemos como “Teoría de Tuckman” 42
*
?
PETER FERDINAND DRUCKER ( Viena, Austria en 19 de noviembre de 1919 Claremont, Estados Unidos en 11 de noviembre de 2005). Drucker dejó huella en sus obras de su gran inteligencia y su incansable actividad. Hoy es considerado ampliamente como el padre del management como disciplina y sigue siendo objeto de estudio en las más prestigiosas escuelas de negocios. Es mencionado en el capítulo 10 por su citación “El 60% de los problemas empresariales son consecuencia de una mala comunicación”, que destaca la importancia que se debe dar a la comunicación, como factor de éxito de un proyecto. Es mencionado además en el capítulo 14 por otra citación “Donde hay una empresa de éxito, alguien tomó alguna vez una decisión valiente”, que define como un factor de éxito imprescindible de una empresa, la correcta y (a veces necesaria), valiente toma de decisiones 43
589
*
HAROLD DWIGHT LASSWELL ( Illinois, Estados Unidos en 13 de febrero de 1902 Nueva York, Estados Unidos en 18 de diciembre de 1978). Fue pionero de la Ciencia política y de las teorías de la comunicación y está considerado como uno de los fundadores de la psicología política. . Es mencionado en el capítulo 10 por su artículo publicado en 1948, que describe el acto de comunicar, que posteriormente ha culminado en una fórmula que es conocida como “El Paradigma de Lasswell”. 44
RICHARD BRADDOCK. Es mencionado en el capítulo 10 por su publicación en 1958: “Extensión al Paradigma de Lasswell” (An extension of the Lasswell Formula) en la que trata de hallar una interacción entre las partes y actores de la acción comunicativa. 45
*
WARREN WEAVER (*
CLAUDE ELWOOD SHANNON ( Michigan, Estados Unidos en 30 de abril de 1916 Massachusets, Estados Unidos en 24 de febrero de 2001). Ingeniero electrónico y matemático 46
estadounidense, recordado como el padre de la teoría de la información.
?
47
Wisconsin, Estados Unidos en 17 de julio de 1894 Connecticut, Estados Unidos en 24 de noviembre de 1978). Matemático estadounidense. Durante la segunda guerra mundial encabezó el Applied Mathematics Panel, que reunió a destacados científicos en el estudio de soluciones que tendrían una gran influencia en los desarrollos de la posguerra. Es considerado como uno de los pioneros de la teoría de la información. Mencionados en el capítulo 10 por haber sido los creadores del “Modelo de Shannon y Weaver”, basado en el paradigma de la teoría matemática de la comunicación, fue una obra pionera y ha influido notablemente en los estudios de comunicación. HENNINGS. Mencionado en el capítulo 10 por ser el creador del Modelo de Hennings, que establece que hay una serie de estímulos verbales físicos, vocales, y situacionales que determinan la codificación de la información por el emisor y la decodificación por parte del receptor. 48
*
?
WILBUR LANG SCHRAMM ( Ohio, Estados Unidos en 5 de agosto de 1907 En 27 de diciembre de 1987). Es uno de los teóricos norteamericanos que estudiaron el problema de la comunicación al servicio del desarrollo, ejerciendo una influencia significativa en los foros de la UNESCO y en el discurso de las doctrinas de la comunicación pare el desarrollo surgidas en América Latina. Mencionado en el capítulo 10 por ser el creador del Modelo de Comunicación de Schramm, que establece que la comunicación es un proceso determinado por establecer relaciones entre personas que tengan en común tres (la fuente, el mensaje y el destino. 49
*
ELIHU KATZ ( Nueva York, Estados Unidos en 1926). Sociólogo estadounidense. Se doctoró en la Universidad de Columbia. En 1955, publicó junto a Paul Lazarsfeld 51 el libro La Influencia Personal. Vinculado a la Mass Communication Research, se dedicó al estudio de medios de 50
comunicación y su impacto en la sociedad.
?
51
PAUL LAZARSFELD (
* Viena, Austria en 13 de abril
de 1903 Nueva York, Estados Unidos en 30 de junio de 1976). Sociólogo estadounidense. Ha realizado importantes aportaciones a la metodología de las ciencias sociales y sus investigaciones matemáticas, que influyeron de manera decisiva en la evolución de la sociología. Es autor de El lenguaje de la investigación social (1955), Filosofía de las ciencias sociales (1970), Las principales tendencias en sociología (1973). Mencionados en el capítulo 10 por ser el coautor del Modelo “Twostep-flow” dice que la influencia de los medios de comunicación de masas no se produce de manera líneal y directa, sino que se produce a través de los líderes de opinión, y del papel que desempeñan como estructuradores y reestructuradores de la información.
590
*
?
GERHALD MALETZKE ( Szczecinek, Polonia en 6 de enero de 1922 Pomerania, Polonia en 6 de diciembre de 2010). Cientista de las comunicaciones y psicólogo. Mencionado en el capítulo 10 por ser el creador del Modelo de Comunicación de Maletzke, que destaca su riqueza y amplitud. Es un modelo en el que se analizan cinco submodelos: 1. El comunicador y el mensaje; 2. El comunicador y el medio; 3. El comunicador y el receptor; 4. El mensaje y el medio; y 5. El receptor y el medio. 52
*
?
HERÁCLITO DE ÉFESO ( Éfeso, Jonia (actual Turquía) en 535 a.C 484 a.C). Fue un filósofo griego. Como los demás filósofos anteriores a Platón, no quedan más que fragmentos de sus obras, y en gran parte se conocen sus aportes gracias a testimonios posteriores. Es mencionado en el capítulo 11 por su citación “Si no esperas lo inesperado no lo reconocerás cuando llegue”. Esta afirmación tiene relación directa con la gestión de los “desconocidos desconocidos” (unknown unknowns), que son eventos imposibles de prever, o totalmente desconocidos. Para hacer frente a esta situación se establecen algunas reservas de tiempo, coste y de recursos que podrán reducir el impacto causado por un factor de riesgo todavía desconocido. 53
54
EDWARD ALOYSIUS MURPHY (
?
* Zona del Canal de Panamá, Estados Unidos en 11 de enero
de 1918 17 de julio de 1990). Fue un ingeniero aeroespacial estadounidense. Trabajó en sistemas de seguridad críticos y es conocido por la homónima Ley de Murphy, que declara que "Si algo puede salir mal, saldrá mal”. Esta citación aparece en el capítulo 11 y refleja la equivocada afirmación de que un proyecto puede estar 100% libre de riesgos. Según relatos de su hijo, consideraba a muchas versiones jocosas de la ley como "ridículas, triviales y erróneas". Sus tentativas fracasadas de hacer que la ley fuera tomada más en serio sólo lograron convertirlo en una víctima de su propia ley. JOHN JESTON. Director de una empresa de consultoría internacional con amplia experiencia en el sector de TI y más de 30 años de trabajo en Project Management y Gestión de Procesos Empresariales. Es el coautor del libro “Business Process Management: Practical Guidelines to Successful Implementations”. 56 JOHAN NELIS. Con más de 15 años de experiencia internacional en Gestión de Procesos Empresariales, es autor de algunos bestsellers de gestión. Son mencionados en el capítulo 11 por su teoría, la “Síndrome del Iceberg” que refleja perfectamente el entorno de riesgos del proyecto donde muchas veces los profesionales enfocan su atención la parte visible del riesgo, ignorando la posibilidad de existencia de un probable riesgo aun mayor, pero todavía desconocido. 55
ANDRE L. DELBECQ. Ph.D. Profesor de Gestión de la Universidad de Santa. 58 ANDREW H. VAN DE VEN. Profesor de Innovación Organizacional de la Carlson School of Management de la Universidad de Minnesota. Son mencionados en el capítulo 11 por haber sido los creadores de la Técnica de Grupo Nominal, que consiste en conducir grupos incorporando un análisis de las ideas presentadas, que valora sobre todo, el proceso de decisión asegurando la participación igualitaria de todo el grupo. 57
DR. C.C. CRAWFORD. Profesor de Educación de la Universidad de Carolina del Sur. Es mencionado en el capítulo 11 por ser el inventor del método Crawford Slip, utilizado para obtener rápidamente una gran cantidad de ideas a partir de grupos numerosos. 59
JOSEPH DONALD NOVAK. Educador americano, profesor en la Universidad de Cornell e investigador Senior en el IHMC. Es mencionado en el capítulo 11 por ser el creador de la teoría del Mapa Conceptual, una técnica de organización y representación del conocimiento. 60
591
JIRO KAWAKITA. Etnologista japonés, mencionado en el capítulo 11 por ser el creador de la técnica “Diagrama de Afinidades”, un método de categorización en el que los usuarios clasifican varios conceptos en diversas categorías. 61
*
?
HERMAN KAHN ( New Jersey, Estados Unidos en 15 de febrero de 1922 New York, Estados Unidos en 7 de julio de 1983). Fue un militar estratega. Conocido por sus análisis de las probables consecuencias de la guerra nuclear. Sus teorías contribuyeron al desarrollo de la estrategia nuclear de los Estados Unidos. Ha sido mencionado en el capítulo 11 por ser el creador del concepto de “escenarios”, al desarrollar estrategias durante la guerra fría para “pensar lo impensable”, es decir, la guerra nuclear. 62
63
THEODORE JAY GORDON. Futurólogo y consultor de gestión. Experto en el campo de
*
tecnología, ingeniero, especialista en planificación y análisis. 64 OLAF HELMER ( Berlín, Alemania en 1910). Lógico alemán y futurólogo. Fue investigador de Rand Corporation desde 1946 hasta 1968 y fue cofundador del Instituto para el Futuro. Mencionados en el capítulo 11 por ser los criadores del Método de los Impactos cruzados, una técnica que ayuda a determinar la naturaleza y el alcance de las repercusiones entre los distintos acontecimientos que pueden sucederse en el entorno.
*
?
STANISLAW MARCIN ULAM ( Lemberg, Ucrania en 13 de abril de 1909 Nuevo México, Estados Unidos en 13 de mayo de 1984). Matemático que participó en el proyecto Manhattan y propuso el diseño Teller–Ulam de las armas termonucleares. También propuso la idea de la propulsión nuclear de pulso y desarrolló un número de herramientas matemáticas en la teoría de 65
números, teoría de conjuntos, teoría ergódica y topología algebraica.
?
66
JOHN VON NEUMANN (
*
Budapest, Hungría en 28 de diciembre de 1903 Washington D.C, Estados Unidos en 8 de febrero de 1957). Fue uno de los más grandes matemáticos del siglo 20. Realizó contribuciones importantes en física cuántica, análisis funcional, teoría de conjuntos, ciencias de la computación, economía, análisis numérico, cibernética, hidrodinámica (de explosiones), estadística y muchos otros campos de la matemática. Son mencionados en el capítulo 11 por ser los coautores del Método de Montecarlo.
*
?
FRANCISCO VILLAESPESA ( Almería, España en 15 de octubre de 1877 Madrid, España en 9 de abril de 1936). Poeta, periodista, dramaturgo y novelista. Estudió en la universidad de Granada y a los 20 años trasladó su residencia a Madrid para dedicarse al periodismo. Allí colaboró en muchas revistas y diarios de España. Recorrió varias veces la América española como empresario teatral y recitador de sus poemas. Ferviente admirador del poeta nicaragüense Rubén Darío, fue su mejor discípulo y el más genuino continuador del estilo modernista iniciado por éste. Es mencionado en el capítulo 12 por su citación “Nada es barato ni caro, todo es igual en la vida. Las cosas valen tan sólo lo que cuesta conseguirlas”. Esta afirmación nos remite a la importancia de realizar un análisis acerca de cualquier compra o contratación que necesitamos realizar: La necesidad de tenerla, su beneficios/coste, pero sobre todo qué valor nos podrá añadir. 67
*
?
RENÉ DESCARTES ( Torraine, Francia en 31 de marzo de 1596 Estocolmo, Suecia en 11 de febrero de 1650). Filósofo, matemático y físico, considerado como el padre de la filosofía moderna, así como uno de los nombres más destacados de la revolución científica. Formuló el célebre “cogito ergo sum” (pienso, por lo tanto existo), elemento esencial del racionalismo occidental. Es mencionado en el capítulo 13 por su citación “Al menos una vez en la vida conviene poner todo en discusión”. Esta afirmación nos hace reflejar que en muchas situaciones de conflicto, solemos dejar la opción del dialogo por último, cuando esta debería ser la primera estrategia. 68
592
69
CHARLES MONROE SCHULTZ (
* Minnesota, Estados Unidos en 16 de noviembre de 1916 -
? California, Estados Unidos en 12 de febrero de 2000). Historietista estadounidense, autor de la conocida tira cómica Peanuts, protagonizada por Charlie Brown y su pandilla. A lo largo de su vida
dibujó 17.000 tiras cómicas y gracias también al merchandising derivado, se convirtió en el dibujante de cómics de más éxito en la segunda mitad del siglo pasado. Es mencionado en el capítulo 15 por su citación “No hay mayor peso para un ser humano que un gran potencial", que refleja la importancia que una figura fuerte y habilidosa, como la de un Project Manager capacitado, se hace necesaria para administrar un emprendimiento tan complicado como puede ser un proyecto. JACK GUIDO. 71 JAMES P.CLEMENTS. Autores del libro Administración exitosa de proyectos, una obra que volcada para toda persona que trabaja con proyectos, ya que provee los fundamentos necesarios para ser líder o miembro de un equipo de proyectos efectivo. Son mencionados en el capítulo, por una de sus pasajes de su obra que dice lo siguiente: “Son las personas – no los procedimientos ni las técnicas – las que son críticas para lograr el objetivo del proyecto. Los procedimientos y las técnicas son simplemente herramientas para ayudas a las personas a realizar sus trabajos”. Un proyecto debe tener una figura central que sea el responsable por su éxito, y claro, también por su fracaso. 70
GARY R. HEERKENS. Autor de diversas obras relacionadas con el Project Management. Es citado en el capítulo 15, por describir algunas de las habilidades “extraoficiales” que un buen Project Manager debería tener para desarrollar correctamente sus funciones. 72
*
FRANÇOIS DE LA ROCHEFOUCAULD ( Paris, Francia en 15 de septiembre de 1613 Ibídem en 17 de marzo de 1680). Escritor francés, conocido, sobre todo, por sus "máximas". Autor de epigramas y moralista francés, nacido en París. Desempeñó un papel activo en la vida de la Corte, la política y durante las guerras que mantuvieron Luis XIII y Luis XIV. Fue autor de un destacado volumen de Memorias. Su fama literaria reside principalmente en sus Reflexiones o sentencias y máximas morales, un libro que contiene unas 700 máximas, en las que analiza las motivaciones y la psicología del ser humano. Su claridad y profundo significado, así como el ingenio y el talento epigramático de La Rochefoucauld, no han sido superados en la literatura francesa. Es mencionado en el capítulo 16 por su citación “Se dan consejos, pero no el juicio para sacar provecho de ellos”. Es decir, que se pueden dar consejos, pero cabe a cada uno de nosotros actuar de la forma más correcta según nuestros principios. 73
*
?
FRANCIS DE GASTON ( Limoux, Francia en 20 de agosto de 1719 Arras en 20 de noviembre de 1787). Mariscal francés. Tuvo un importante papel en la Guerra de Sucesión Austríaca y bajo el mando de Louis-Joseph de Montcalm en la Guerra Franco-india. Es mencionado en el capítulo 17 por su citación “Estableced el orden: el hábito se encargará de mantenerlo”. La documentación es un factor clave en un proyecto que además de estar debidamente organizada, debe de ser completa, actualizada y con contenido relevante. El sano hábito de documentar adecuadamente un proyecto y distribuir la información a los involucrados en el momento oportuno incrementa la calidad del proyecto, disminuye la ocurrencia de algunos riesgos y asegura la correcta comunicación entre los interesados. 74
ANTÍPATRO DE SIDÓN (Siglo II a.C). Poeta griego autor de varios epigramas de la antología griega. Es mencionado en el Apéndice “B” Fue uno de los muchos escritores que hicieron una relación de los monumentos y construcciones del mundo clásico que se consideraban síntesis de la belleza, es decir, las Siete Maravillas del Mundo Antiguo. Se limitó a siete, un número mágico entre los griegos. 75
593
KEOPS Fue el segundo faraón de la cuarta dinastía, perteneciente al Imperio Antiguo de Egipto. Reinó de 2579 a 2556 a.C. 77 HEMIUNU. Miembro de la familia real egipcia y además el arquitecto responsable por la construcción de la Gran Pirámide de Guiza. Los arqueólogos han encontrado menciones de Hemiunu con el título de Supervisor de los trabajos, Portador del sello real, Jefe del 76
Ejército y Guía de las Expediciones.
78
SIR WILLIAM MATTHEW FLINDERS PETRIE (
?
* Londres,
Inglaterra en 3 de junio de 1853 – Jerusalén, Palestina en 28 de julio de 1942). Fue un importante egiptólogo, pionero en la utilización de un método sistemático en el estudio arqueológico. Ocupó la primera cátedra de Egiptología en el Reino Unido, y realizó excavaciones en muchos de los puntos arqueológicos más importantes de Egipto, como Naucratis, Tanis, Abidosy Amarna. Han sido mencionados en el Apéndice “B” por su relación con la Gran Piramide Giza,
*
?
NABUCODONOSOR II ( 630 a.C – 562 a.C). Es probablemente el gobernante más conocido de la dinastía caldea de Babilonia. Es famoso por la conquista de Judá y Jerusalén, y por su monumental actividad constructora en la Babilonia. Es tradicionalmente llamado "Nabucodonosor el Grande", pero la destrucción de templos en Jerusalén y la conquista de Judá le causaron una imagen malévola en las tradiciones judías y en la Biblia, al contrario de lo que sucede en el Irak contemporáneo, donde es glorificado como un líder histórico. 80 AMYTIS. Esposa de Nabucodonosor II. Según los registros históricos, los Jardines Colgantes de Babilonia fueron construidos para ella, que tenía añoranza en la llanura de Babilonia por las montañas de su país. Han sido mencionados en el Apéndice “B” por su relación con la construcción de los Jardines Colgantes de Babilonia. 79
CRESO. Último rey de Lidia (entre el 560 y el 546 a.C.), de la dinastía Mermnada. Conquistó Panfilia, Misia y Frigia; en definitiva, sometió a todas las ciudades griegas de Anatolia hasta el río Halys, a las que hizo importantes donaciones para sus templos. Debido a la gran riqueza y prosperidad de su país, de él se decía que era el hombre más rico en su tiempo. 81
82
QUERSIFRÓN.
83
METÁGENES. 84 TEODORO. Diseñadores y arquitetos griegos (carecen de fuentes).
ERÓSTRATO. Fue un pastor de Éfeso, convertido en incendiario, fue responsable de la destrucción del templo de Artemisa de Éfeso. Según registra la historia, su único fin fue lograr fama a cualquier precio. En el ambiente académico de la psicología se denomina “Complejo de Eróstrato” al trastorno según el cual el individuo busca sobresalir, distinguirse, ser el centro de atención. Han sido mencionados en el Apéndice B por su relación con la construcción (y destrucción) del Templo de Artemisa de Éfeso. 85
*
?
PERICLES ( 495 a.C – 429 a.C). Importante e influyente político y orador ateniense en los momentos de la edad de oro de la ciudad. Gran dirigente, era conocido como “El Olímpico”, por su imponente voz y por sus excepcionales dotes de orador. 86
*
?
FIDIAS ( Atenas, Grecia en 490 a.C – Olimpia, Grecia en 431 a.C). Fue el más famoso de los escultores de la Antigua Grecia, pintor y arquitecto, perteneciente al primer clasicismo griego. Han sido mencionados en el Apéndice “B” por su relación con la estatua de Zeus en Olimpia. 87
594
ARTEMISA II DE CARIA. Hija de Hecatomno, fundador de la Dinastía Hecatómnida, la cual había gobernado la satrapía de Caria desde principios del siglo IV a. C. Se casó con su hermano Mausolo, sátrapa desde la muerte del padre de ambos. 88
MAUSOLO. Sátrapa de Caria. Hijo de Hecatomno, aristócrata que había obtenido en 392 a. C. la satrapía de Caria de manos de Artajerjes II. 89
90
*
ESCOPAS ( 380 a.C –
? 330 a.C). Célebre escultor y arquitecto clásico griego del siglo IV a. C.
LEOCARES. Escultor ateniense en actividad desde los años 360 a los años 320 a. C. 92 BRYAXIS. Escultor griego. 91
TIMOTHEOS. Escultor griego durante el siglo IV a.C. Han sido mencionados en el Apéndice “B” por su relación con la construcción del Mausoleo de Halicarnaso. 93
CARES DE LINDOS. Escultor griego discípulo de Lisipo. Ha sido mencionados en el Apéndice “B” por considerase el autor del Coloso de Rodas, estatua del Dios Helios erigida para celebrar la victoria rodia sobre Demetrio Poliorcetes en 304 a. C. 94
*
PTOLOMEO II FILADELFO ( Isla de Cos, en el Egeo en 308 a.C). Fue el segundo faraón de la dinastía ptolemaica; gobernó en Egipto de 285 a 246 a. C. 95
ALVA-ERATUS. Arquitecto egipcio. . Han sido mencionados en el Apéndice “B” por su relación con la construcción del Faro de Alejandría. 96
*
?
LEONARDO DA VINCI ( Florencia, Italia en 15 de abril de 1452 Torraine, Francia en 2 de mayo de 1519). Pintor florentino y polímata (a la vez artista, científico, ingeniero, inventor, anatomista, escultor, arquitecto, urbanista, botánico, músico, poeta, filósofo y escritor) Sus primeros trabajos de importancia fueron creados en Milán al servicio del duque Ludovico Sforza. Trabajó a continuación en Roma, Boloña y Venecia, y pasó los últimos años de su vida en Francia, por invitación del rey Francisco I. Es mencionado en el capítulo 2 por haber sido uno de los inventores más importantes de nuestra historia, cuyas creacciones tuvieron que esperar siglos ser puestos en marcha, simplemente porque no existía la tecnología necesaria para llevarlos a cabo. 97
595
Apéndice D Sigla s
597
AC Actual Cost ACWP Actual Cost of Work Performed AD Activity Description ADM Arrow Diagramming Method AE Apportioned Effort AF Actual Finish date AOA Activity – On – Arrow AON Activity – On – Node AS Actual Start date BAC Budget At Completion BCWP Budgeted Cost of Work Performed BCWS Budgeted Cost of Work Scheduled BOM Bill Of Materials CA Control Account CAP Control Account Plan CCB Change Control Board COQ Cost Of Quality CPF Cost-Plus-Fee CPFF Cost-Plus-Fixed-Fee CPI Cost Performance Index CPIF Cost-Plus-Incentive-Fee CPM Critical Path Method CPPC Cost-Plus-Percentage of Cost CV Cost Variance CWBS Contract Work Breakdown Structure DD Data Date DU Duration EAC Estimate at Completion EF Early Finish Date EMV Expected Monetary Value ES Early Start Date ETC Estimate to Complete EV Earned Value EVM Earned Valued Management EVT Earned Valued Technique FF Finish-to-Finish FF Free Float FFP Firm-Fixed-Price FMEA Failure Mode and Effect Analysis FPIF Fixed-Price-Incentive-Fee FS Finish-to-Start IFB Invitation for Bid LF Late Finish date
LOE Level of Effort LS Late Start date OBS Organizational Breakdown Structure OD Original Duration PC Percent Complete PCT Percent Complete PDM Precedence Diagramming Method PF Planned Finish date PM Project Management PM Project Manager PMBOK Project Management Body Of Knowledge PMIS Project Management Information System PMO Program Management Office PMO Project Management Office PMP Project Management Professional PS Planned Start Date PV Planned Value QA Quality Assurance QC Quality Control RAM Responsibility Assignment Matrix RBS Resource Breakdown Structure RBS Risk Breakdown Structure RD Remaining Duration RFP Request for Proposal RFQ Request for Quotation SF Scheduled Finish date SF Start-to-Finish SOW Statement of Work SPI Scheduled Performance Index SS Scheduled Start date SS Start-to-Start SV Schedule Variance SWAG Sophisticated Wild Ass Guess SWOT Strenths, Weaknees, Oppurtunities, and Threads TC Target Completion date TF Target Finish date TF Total Float T&M Time and Material TQM Total Quality Management TS Target Start date VE Value Engineering WBS Work Breakdown Structure
598
Apéndice E Listado de técnicas Capítulo 1 – Introducción 1.7.3 La gestión de los stakeholders Matriz poder/interés Diagrama de Venn Matriz de los interesados
Capítulo 3 – Selección de proyectos 3.1.1 Criterios financieros para la selección de proyectos Análisis beneficio-coste Punto de equilibrio Valor presente neto - VPN Tasa interna de retorno - TIR Periodo de reembolso Retorno sobre inversión - RSI
3.1.2 - Criterios no financieros para la selección de proyectos Tributos ponderados Toma de decisiones Análisis del árbol de decisiones Procesos de análisis jerárquico
Capítulo 4 – Gestión de la integración 4.1 Desarrollo del acta de constitución del proyecto Juicio de expertos
4.2 Desarrollo del plan de proyecto Metodología de planificación del proyecto Conocimientos y habilidades de los interesados Sistema de información de gestión de proyectos Valor del trabajo realizado Juicio de expertos
599
4.3 Gestión y ejecución del plan de proyecto Habilidades de gestión en general Conocimiento acerca del producto/servicio Sistema de autorización de trabajo Evaluación de progresión o reuniones de seguimiento Sistema de información de gestión de proyectos Procedimientos de la organización Juicio de expertos
4.4. Monitorización y control del trabajo del proyecto Juicio de expertos
4.5 Control integrado de cambios Sistema de control cambios Estudio de viabilidad Gestión de la configuración Informes de progreso Sistema de información de gestión de proyectos Juicio de expertos Reunión de control de cambios
4.6 Cierre del proyecto o fase Juicio de expertos
Capítulo 5 - Gestión del alcance 5.1 Recopilar requisitos Entrevistas Grupos de opinión Talleres facilitados Técnicas de creatividad en grupo Técnicas de toma de decisión en grupo Cuestionarios y encuestas Observaciones Prototipos
5.2 La definición del alcance Requisitos del proyecto La enunciación del alcance del proyecto Planificación gradual Descomposición Juicio de expertos Análisis del producto
600
5.3 Creación de la EDT Estructura detallada del trabajo - EDT Estructura detallada del producto - EDP Otros tipos de estructuras de desglose Diccionario de la EDT
5.4 Verificación del alcance Inspección
5.5 Control de cambios del alcance Análisis de variación Sistema de control de cambios del alcance Planificación adicional
Capítulo 6 – Gestión del tiempo 6.1 Definición de las actividades Estructura detallada del trabajo - EDT Descomposición Planificación gradual Plantillas Juicio de expertos
6.2 Secuenciación de actividades Diagrama de red Método de diagramación con flechas Método de diagramación por precedencia Método del camino crítico Determinación de dependencias Aplicación de adelantos y retrasos Plantillas de red de cronograma
6.3 Estimación de los recursos de las actividades Juicio de expertos Datos de estimación publicados Estimación ascendente Software de gestión de proyectos
6.4 Estimación de duración de actividades Juicio de expertos Estimación analógica Estimación paramétrica Técnica de evaluación y revisión de programas Base histórica de proyectos
601
Juicio de expertos Técnica Delphi Reserva de tiempo
6.5 Desarrollo del cronograma del proyecto Método del camino crítico Gestión de proyectos por cadena crítica Nivelación de recursos Análisis “¿Qué pasa sí...?” Aplicación de adelantos y retrasos Ejecución rápida Compresión Gráfico de barras de Gantt Gráfico de hitos
6.6 Control del cronograma Medición del rendimiento Índice de desempeño del cronograma Software de gestión de proyectos Nivelación de recursos Análisis “¿Qué pasa sí...?” Aplicación de adelantos y retrasos Compresión del cronograma Sistema de control de cambios de cronograma Planificación adicional
Capítulo 7 – Gestión de costes 7.1 Estimación de costes Juicio de expertos Estimación por analogía Estimación ascendente Estimación paramétrica Técnica de evaluación y revisión de programas Análisis de reserva Software de estimación para la gestión de proyectos Análisis de propuestas para licitaciones Estructura detallada del trabajo - EDT Estructura de desglose de costes - EDC Tasas de recursos Técnica Delphi Base histórica de proyectos Plan de cuentas
602
7.2 Establecimiento del presupuesto Suma de costes Análisis de reserva Juicio de expertos Relaciones históricas Conciliación del límite del financiamiento
7.3 Control de costes Valor del trabajo realizado Proyecciones Índice de desempeño del trabajo por completar Índice del desempeño del coste Software de gestión de proyectos Planificación adicional Sistema de control de cambios de costes
Capítulo 8 – Gestión de la calidad 8.1 Planificación de la calidad Análisis beneficio-coste Análisis de los costes de calidad Diagramas de control Estudios comparativos Diseño de experimentos Muestra estadística Diagramas de flujo Metodologías propietarias de gestión de la calidad Análisis de campos de fuerza Listas de verificación
8.2 Aseguramiento de la calidad Auditorias de calidad Informe de auditoría
8.3 Control de calidad Mediciones de calidad El ciclo PDCA Inspección Gráfico de control Listas de verificación Diagramas de pareto Diagramas de causa-efecto Muestra estadística Análisis de tendencias Diagrama de flujo
603
Diagramas de interrelación Diagramas de dispersión Diseño de experimentos Histogramas Diagrama matricial Matriz de priorización
Capítulo 9 – Gestión de los RRHH 9.1 Desarrollo de los recursos humanos Organigramas Relaciones de trabajo o redes sociales Matriz de responsabilidades Estructura de desglose de la organización – EDO
9.2 Adquisición de personal Asignación previa Negociación Adquisición Equipos virtuales
9.3 Desarrollo del equipo Teoría de Tuckman Habilidades interpersonales Formación Reglas básicas Reubicación Reconocimiento y recompensas
9.4 Gestión del equipo Evaluación de rendimiento Gestión de conflictos Registro de incidencias Habilidades interpersonales Diagramas de red Histograma de recursos Calendario de recursos
Capítulo 10 – Gestión de las comunicaciones 10.1 Identificación de los interesados Matriz poder/interés
604
Juicio de expertos
605
10.2 Planificación de las comunicaciones Análisis de requisitos de comunicaciones Tecnología de las comunicaciones Modelos de comunicación Métodos de comunicación
10.3 Distribución de la información Sistemas de gestión de la información Lista de distribución de la información Control de versiones
10.4 Gestión de las expectativas de los interesados Métodos de comunicación Habilidades interpersonales Habilidades de gestión
10.5 Informes de rendimiento Análisis de variación Métodos de proyección Sistemas de informes Análisis de tendencias Análisis del valor del trabajo realizado
Capítulo 11 – Gestión de riesgos 11.1 Planificación de la gestión de riesgos Análisis y reuniones de planificación
11.2 Ide ntificación de riesgos Revisión de la documentación Técnicas de recopilación de información Listas de verificación Análisis de hipótesis o supuestos Técnicas de diagramación Análisis DAFO Juicio de expertos Tormenta de ideas Técnica del grupo nominal Técnica Delphi Técnica Crawford Slip Entrevistas Mapa conceptual Diagramas de afinidad Estructura de desglose de riesgos - EDR Lecciones aprendidas
606
11.3 Análisis cualitativo de riesgos Probabilidad de riesgos y valorización de los impactos Evaluación de la calidad de los datos sobre riesgos Categorización de riesgos Método de los escenarios Método de los impactos cruzados Evaluación de la urgencia de los riesgos Juicio de expertos
11.4 Análisis cuantitativo de riesgos Técnicas de recopilación y representación de datos Análisis cuantitativo de riesgos y de modelado Juicio de expertos Entrevistas Análisis del árbol de decisiones Simulación de Montecarlo
11.5 Plan de respuesta al riesgo Estrategias para riesgos negativos o amenazas Estrategias para riesgos positivos u oportunidades Plan de contingencia Gestión de reservas Gestión del riesgo residual El plan B Juicio de expertos
11.6 Supervisión y control de riesgos Reevaluación de los riesgos Auditorías de riesgos Análisis de variación Medición del desempeño técnico Análisis de reserva Reuniones sobre el estado del proyecto Análisis de hipótesis o supuestos
Capítulo 12 – Gestión de compras y contratos 12.1 Plan de compras y contratos Base histórica de proyectos Análisis "comprar o hacer" Análisis del árbol de decisiones Juicio de expertos
607
12.3 Administración del contrato Sistema de control de cambios del contrato Revisiones e informes de desempeño Inspecciones y auditorías Sistemas de pago Administración de reclamaciones Sistema de gestión de registros
12.4 Cierre del contrato Auditorías de la adquisición Acuerdos negociados Sistema de gestión de registros
Capítulo 13 - Gestión de conflictos 13.2 Técnicas de resolucion de conflictos Alternativa resolución de disputas
608
Bibliogra fía Esta obra ha sido basada en la cuarta versión del PMBOK®. A Guide to the Project Management Body of Knowledge – PMBOK Guide) – Fourth Edition. Published by: Project Management Institute (www.pmi.org)
“PMI”, el logotipo de PMI, “PMP”, el logotipo de “PMP”, “PMBOK”, “PgMP”. “Project Management Journal”, “PM Network”, y el logotipo de PMI Today son marcas registradas de Project Management Institute Inc. Agradecimiento especial a la version traducida por Mónica Talledo Jiménez. A continuación, se enumeran las principales fuentes bibliográficas utilizadas en la elaboración de este libro. Esta bibliografia incluye libros, algunos artículos en revistas y boletines especializados, e Internet. ALCUBILLA, Enrique Arnaldo. Enciclopedia Jurídica La Ley. Editorial La Ley. Grupo Wolters Kluwer, 2009. ANBARI, F. Earned Value Project Management. Project Management Journal. 2003. ARBOLEDA, G. Proyectos: formulación, evaluación y control. 5º edición, AC editores, Cali, Colombia. 2003. AUSUBEL, D. P. The Psychology of Meaningful Verbal Learning. New York: Grune and Stratton, 1963. AUSUBEL, D. P., NOVAK, J. D. and HANESIAN, H. Educational Psychology: A Cognitive View, 2nd ed. New York: Holt, Rinehart and Winston, 1978. BALES, R. F. The equilibrium problem in small groups'. Knopf,ntro 1965. BHUSAN, Navneet; KANWAL Rai. Strategic Decision Making: Applying the Analytic Hierarchy Process.Springer-Verlag, 2004. BONABEAU, Eric. Don´t Trust your Gut, Harvard Business Review Vol. 81, nº 5, pags. 116-123. Harvard Business Publishing, 2003. BONNER, H. Psychology of personality, Ronal, 1961. BRIGHAM, Eugene F. Fundamentals of Financials Management. The Dryden Press, 1980. BRIGHAM, Eugene F; GAPENSKI, Louis C. Financial Management. Editorial The Dryden Press, 1994.
609
BRODERSEN, Kai. Las Siete Maravillas del mundo antiguo. Alianza Editorial, 2010. BRONSON, R.; NAADIMUTHU, G. Operations Research. McGraw Hill Companies - Schaum’s Outline Series. 2nd edition, New York, USA. 1997. BUDGE, E. A. Wallis. El libro egipcio de los muertos. Málaga, Editorial Sirio, 2007. CHARVAT, Jason. Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Project. John Wiley & Sons, 2003. CHARVAT, Jason. Project Management Nation: Tools, Techniques and Goals for the New and Practicing IT Project Manager. John Wiley & Sons, 2002. COOPER, Robert G. Portfolio Management for New Products. Perseus Books, 1998. CROWSTON, W. and THOMPSON, G. Decision CPM: A Method for Simultaneous Planning, Scheduling, and Control of Projects. 1965. DEUTSH, M. The resolution of conflict. New Haven Connesticut Yale University Press, 1973. DINSMORE, Paul C. AMA The Handbook of Project Management. Amacon Books, 1993. ERIKSSON, L; JOHANSSON, E; KETTANEH-WORD, N; WILKTRÖM, C y WOLD, S. Design of Experiments. Principles and Applications. Umetrics AB-Sweden, 2000. FABRYCKY, Wolter J and BLANCHARD, Benjamin S. Systems Engineering and Analysis. Prentice Hall; 4 edition, 2005. FABRYCKY, Wolter J. Analisis del Coste del Ciclo de Vida de los Sitemas. Isdefe, 1997. FLEMING, Q.; KOPPELMAN, J. Earned Value Project Management. 2nd edition, Newtown. 2000. FOLLIET, Joseph. El hombre social. Ensayo de Antropología social. FONTENLA, E; Sallin-Kornberg E. Scenario Building with the ExplorMultitrade Model, in Commerce International et ModèlesMultinationaux. Economica, Paris, 1981. FRAME, J. Davidson. Managing projects in organizations: how to make the best use of time, techniques, and people. Jossey-Bass Inc, 1995. GERARDIN, Luciene. Previsión de la toma de decisiones por medio del análisis de los sistemas: análisis sistemático para prever futuros alternativos. ThompsonCSF. Francia, 1974. GIDO Jack; CLEMENTS, James P. Administración Exitosa de Proyectos. Internacional Thomson Editores, 1999. GISELA, M.A. The Sculpture and Sculptors of the Greeks. New Haven, Yale University Press.
610
1950. GODET, M. Manuel de prospective stratégique. Dunod, Paris, 1984. GOLDRATT. Eliyahut M. Critical Chain. North River Press; Illustrated edition ,1997. GOLENKO, D. On the Distribution of Activity Time in PERT. The Journal of the Operational Research Society, 1988. GORDON, Theodore STOVER, John. Análisis del impacto cruzado. Manual de investigación de futuros. Jib Fowles, Greenwood Press. 1978. GORDON T.H. Initial experiments with the Cross-Impact Matrix Method of Forecasting. Futures, 1968. GORDON T.H. Integration of Forecasting Methods and the Fronteers of FuturesResearch. UN Millenium project, NY. 1994. GREER, Michael. The Project Manager´s Partner. A Step-by-Step Guide to Project Management, 2nd Edition. AMACOM Books, 2001. HALL, Earl; JOHNSON, Juliane. Integrated Project Management. Prentice Hall, 2003. HASTINGS, W. K. Montecarlo Sampling Methods Using Markov Chains and Their Applications, Biometrika, 1970). HEERKENS, Gary R. Project Management. McGraw-Hill, 2002. HERBET Simon. The New Science of Management Decision. Harper and Row, New York, 1960. HIGUCHI, Toshio; TSUTOMU, Kato. Improvement activities in the work place. Quality Control, 1984. HROMKOVIC, J. Algorithms for hard problems: introduction to combinatorial optimization, randomization, approximation, and heuristics. Springer-Verlag, London - Berlin - Heidelberg - New York, 2001. HURTADO, Toskano; BRUNO Gérard. El Proceso de Analisis Jerarquico (AHP) como herramienta para la toma de decisiones en la selección de proveedores : aplicación en la selección del pro veedor para la Empresa. Gráfica Comercial MyE S.R.L, 2005. JALOTE, Pankaj. Software Project Management in Practice. Addison Wesley, 2002. JESTON John; NELIS Johan. Business Process Management: Practical Guidelines to Successful Implementations – 3rd Edition. Butterworth-Heinemann, 2006. JOHNSON, G.; SCHOLES, K. Dirección Estratégica - 7ª edición. Pearson, Prentice Hall. Madrid, 2006.
611
JOHNSON, Robert y KUBY, Patricia. Estadística elemental, lo esencial. Tercera Edición, Thomson. 2005
KERZNER, Harold. Project Management: A Systems Approach to Planning, Scheduling and Controlling, Sixth Edition. John Wiley, 1997. KERZNER, Harold. Strategic Planning for Project Management Using a Project Management Maturity Model. John Wiley & Sons, 2001. KOTLER, Philip. Administração de marketing: analise, planejamento, implementação e controle. Ed. Sao Paulo: Atlas, 1994. LEVINE, Harvey A. Practical Project Management. Tips, Tactics and Tools. John Wiley & Sons, 2002. LEWIS, James P. Fundamentals of Project Management. AMACON Books, 1995. MARTIN Paula; TATE Karen. Getting Started in Project Management. John Wiley & Sons, 2001. MAXIMIANO, Antonio Cesar Amaru. Adminitração de Projetos. Como transformar idéias em resultados. 1 ª Edição, Editora Atlas, 1997. MCCARTHY, Jim. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995. MCCONNELL, Steve, After the Gold Rush: Creating a True Profession of Software Engineering. Microsoft Press, 1999. MEREDITH Jack R.; MANTEL JR, Samuel J. Project Management, a Managerial Approach - 3rd Edition. Wiley, 1995. METROPOLIS, A. ROSENBLUTH, M, TELLER, E. Equation of State Calculations by Fast Computing Machines, Journal of Chemical Physics, 1953. MICHAELSON, G. Sun Tzu. The Art of War for Managers. Adams Media, 2001. MIRANDA, Juan José Miranda. El Desafío de la Gerencia de Proyectos. Lemoine Editores, 2006. MULCAHY, Rita. PMP Exam Prep: Accelerated Learnirng To Pass PMI´s PMP Exam – On Your First Try ! 3rd Edition. Rmc Pubns Inc, 2005. NAYATANI, Yoshinobu. A Lecture on the New Seven Tools of QC. Japanese Standards Association, 1987. NEWELL, Michael W. Preparing for the Project Management Professional (PMP) Certification Exam - 2nd Edition. AMACON Books, 2002.
612
NEWELL, Michael W; GRASHINA, Marina N. The Project Management Question and Answer Book. AMACON Books, 2004.
613
NOVAK, J.D. y GOWIN, D.B. Aprendiendo a Aprender. Ediciones Martinez Roca, S.A., Barcelona, 1988. ODA, Noriyuki. Case Studies of Improvement Activities which Apply the Seven New Tools of QC to Defective Processes. Quality Control, 1985. OULD, Martyn. Managing Software Quality and Business Risk. New York: Wiley, 1999. PAPALIA, Diane E, OLDS, Sally Wendkos y FELDMAN, Ruth Duskin. Psicologia del desarrollo. McGraw-Hill, 2001 PHILLIPS, Joseph. PMP Project Management Professional Study Guide. McGraw-Hill, 2004. PHILLIPS, Dwayne. The Software Project Manager’s Handbook, IEE Computer Society, 2000. PRITCHARD, Carl L. Risk Management. ESI International, 1997. Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures, Project Management Institute; 2001. Project Management Institute. PMI. Practice Standard for Earned Value Management. 2005. PURBA, Sanjiv. How to Manage a Successful Software Project: Methodologies, Techniques, Tools. New York: John Wiley, 1995. QUENTIN, W; KOPPELMAN, J. What's Your Project's Real Price Tag?. Harvard Business Review. 2003SCHOBEL, Heinz. The Ancient Olympic Games. Princeton, D. Van Nostrand Company, 1965. RAKOS, John J. Software Project Management for Small to Medium Sized Projects. Englewood Cliffs, NJ: Prentice Hall, 1990. RICHMAN, Larry. Project Management Step-by-Step. Amacon Books, 2002. RODRIGUEZ, Indiana. Guía sobre metodología y técnica de la investigación. Colon La Paix. 1992. ROSS, Stephen A. Princípios de administração finaceira. Editoras Atlas - São Paulo, 2000. ROYCE, Walker, Software Project Management: A Unified Framework. Addison-Wesley, 1998.
SAATY, Thomas L. Fundamentals of Decision Making and Priority Theory. Pittsburgh, Pennsylvania: RWS Publications, 2001. SABINO, Carlos. El proceso de la investigación científica. El Cid Editor. 1978 SCHWEITZER, Marcell; TROSSMANN, Ernst; LAWSON, Gerald . Break Even Point analysises: Basic Model, Variant, Extensions. John Wiley & Sons Inc, 1991.
614
SIERRA, Bravo. Técnicas de investigación social. 8ª Edición. Editorial Paraninfo. 1996. SNACK, Nigel; CHAMBERS, Stuart; HARLAND, Christine. Operation Management. Pitman Publishing London, 1995. SOBRINHO, José Dutra Vieira. Matemática Financeira - 7ª Edição. Editora Atlas, 2000. SOUDER, Williem E. Project Selection and Economic Appraisal. Van Nostrand Reinhold, 1984. STELLMAN, Andrew; GREENE Jennifer. Head First PMP®. O´Reilly Media INC, 2009. THAYER, Richard. Software Engineering Project Management. IEEE Computer Society, 2000. THOMAS, A.J. Project Manager Desk Reference – Guide to the Project Management Body of Knowledge - Eight Edition. The Hampton Group INC, 1999. THOMSETT, Michael C. The Little Black Book of Project Management. AMACOM Books, 1990 THOR, Carl G. Using Nominal Group Technique to Establish a White Collar Productivity Measurement System. American Productivity Center, 1986. TILICH, P. The courage to be, Yale, University, 1952 TRICK, Michael A. Analytic Hierarchy Process. Class Notes. Carnegie Mellon University Tepper School of Business, 1996 TUCKMAN, Bruce W. Developmental sequence in small groups. Psychological Bulletin, 63, 384399, 1965. TUCKMAN, Bruce W. Conducting Educational Research, Wadsworth. Fifth edition 1999. TUCKMAN, Bruce W. Evaluating Instructional Programs. Allyn & Bacon, 1979. TUCKMAN, Bruce W. Forming, storming, norming and performing in groups, the encyclopaedia of informal education. 2005 VALERIANO, Dalton L. Gerenciamiento Estratégico y Administracao por Projetos - 1ª Edicao. Markron Books, 2001. VARGAS, Ricardo. Microsoft Project 2002 Profesional Server. Braspost Livros e Multimedia. 2002 VEN, A. Van de; POOLE, M.S. Handbook of Organizational Change and Innovation, Oxford University Press, 2004. VEN, A. Van de; POLLEY, D; GARUD, R and VEKATARAMAN, S. The Innovation Journey. Oxford University Press, 1999.
615
VEN, A. Vande; POOLE, M.S; DOOLEY K and HOLMES M. Organizational Change and Innovation Processes: Theory and Methods for Research Oxford University Press, 2000. VEN, A. Vande and FERRY, D. Measuring and Assessing Organizations, Wiley Interscience, 1980. VEN, A. Van de; DELBECQ, A and GUSTAFSON, D. Group Techniques for Program Planning: A Guide to Nominal Group and Delphi Processes. Scott Forsman, 1975 VERZUH, Eric. The Fast Forward MBA in Project Management, Second Edition. John Wiley & Sons, 2005. VERZUH, Eric. The Portable MBA in Project Management. John Wiley & Sons, 2005. WARD, J. LeRoy. Project Managemen Terms. A Working Glosssary. ESI International, 1997. WEISS, Joseph J; WYSOCKI, Robert K. 5-Phase Project Management. Addison Wesley, 1992. WESTERFIELD, Randolph W.; JORDAN, Bradford D. Essential of Corporate Finance. McGraw Hill Companies Inc,; 1999. WIESER, Friedrich von. Theorie der gesellschaftlichen Wirtschaft. JCB Mohr, 1924. WILKS, Samuel S. Mathematical Statistics, John Wiley, 1962 WOOD, Jane. Joint Application Development. New York, NY: John Wiley & Sons, Inc, 1995. WYSOCKI, Robert K.; MCGARY, Rudd. Effective Project Management, Third Edition. John Wiley & Sons, 2003 YOURDON, Edward. , Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible Projects. Prentice Hall, 1997.
616
Referencias en Internet 12Manage: www.12manage.com AACE International: www.aacei.org AYE Conference: http://www.ayeconference.com Biblioteca Virtual de Salud Ambiental: www.bvsde.paho.org Bright Hub: http://www.brighthub.com Catalyst Management Consulting: www.catalystpm.com Centro Latinoamericano para el Desarrollo Rural: www.rimisp.cl Discovery Channel: www.tudiscovery.com Docstoc – Documents for Small Business & Professionals : www.docstoc.com ERM – Enterprise Risk Management: www.ermholding.com Excellence in Financial Management: www.exinfm.com Foro Legal Abogados: www.forolegal-abogados.com Gestiopolis: www.gestiopolis.com Helbig Consulting: www.helbig.com.au HERMES: www.hermes.admin.ch IAAP Global: www.iaapglobal.com Ibermatica: www.ibermatica.com Infed: www.infed.org Intellisys Technology: www.intellisystechnology.com International Association for Contract & Commercial Mangmnt: www.iaccm.com International Organizational for Standardization: www.iso.org Instituto Nacional de Tecnologías de la Comunicación: www.inteco.es Iowa State University: www.extension.iastate.edu ITToolkit: www.ittoolkit.com Max´s Project Management Wisdom: www.maxwideman.com mailXmail: www.mailxmail.com Method 123: www.method123.com Microsoft Office Online: http://office.microsoft.com Mundo PM: www.mundopm.com.br National Geographic: www.nationalgeographic.com.es Navactiva – El Portal de Empresas de Navarra: www.navactiva.com Navegapolis: www. navegapol is. net PM Essentials: www.pm-essentials.com
617
PMI - Project Management Institute: www.pmi.org PMI - Capítulo Rio de Janeiro: www.pmirio.org.br PMI - Capítulo Sao Paulo: www.pmisp.org.br PMI - Capítulo Venezuela: www.pmi-v.org.ve Portal Calidad: http://www.portalcalidad.com PPC Total: www.ppctotal.com PRINCE2: www.prince2.com
618
Project Management Directory: www.project-managementknowledge.com Project Management Road Trip: www.pmroadtrip.com PymesFuturo: www.pymesfuturo.com Qualiblog: qualiblog.wordpress.com Real Academia Española: www.rae.es Real Centro Universitario Escorial: www.rcumariacristina.com Rothman Consulting Group INC: www.jrothman.com Sheffield Hallam University: www.shu.ac.uk Software Engineering Institute: www.sei.cmu.edu Tenrox: www.tenrox.com The Article Directory: http://e-articles.info The Washington Post: www.washingtonpost.com Thomas Jefferson National Accelerator Facility: www.jlab.org Tutorials Point: www.tutorialspoint.com Universidad de Almería: www.ual.es Univesitat de Valencia: www.uve.es Universidad Nacional Mayor de San Marcos: http://sisbib.unmsm.edu.pe University of Cambridge – Department of Engineering: wwwmaterials.eng.cam.ac.uk University of Western Sidney: www.uws.edu.au V-Model: www.v-modell.iabg.de Wikipedia: www.wikipedia.org Yankee Clipper Group: www.ycgweb.com
619
