UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

PROPUESTA METODOLGICA PARA LA EJECUCIN, SEGUIMIENTO, CONTROL Y CIERRE DE PROYECTOS CONSTRUCTIVOS EN ZONA FRANCA COYOL

JOSE ELISEO ARAYA ZIGA

PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACIN DE PROYECTOS

San Jos, Costa Rica

Noviembre, 2010

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

Este Proyecto Final de Graduacin fue aprobado por la Universidad como requisito parcial para optar al grado de Mster en Administracin de Proyectos.

__________________________ lvaro Mata Leitn PROFESOR TUTOR

_________________________ Ramiro Fonseca Macrini LECTOR No.1

__________________________ Eddy Ramrez LECTOR No.2

________________________ Jose Eliseo Araya Ziga SUSTENTANTE

ii

DEDICATORIA
A mis padres, que han estado a mi lado durante toda mi vida siendo una fuente inagotable de enseanzas y de sacrificio. Mi gran ejemplo!

A Silvia, quien con su amor incondicional me ha dado la gua y la fortaleza necesaria a lo largo de todo este proyecto. Te Amo!

iii

RECONOCIMIENTOS
Primero que nada a Dios, quien me ha dado todas las facultades y bendiciones que tiene mi vida como para poder alcanzar una meta ms.

Al Ing. lvaro Mata, por su oportuna y acertada gua profesional en los momentos adecuados las cuales fueron indispensables para la realizacin de este trabajo.

A los lectores, al Ing. Ramiro Fonseca Macrini y al Ing. Eddy Ramrez quienes supieron darme las recomendaciones y observaciones necesarias para terminar del moldear el xito de este proyecto.

A todos los profesores que tuve a lo largo de la maestra, quienes supieron dar lo mejor de s, para buscar en m crecer profesionalmente.

Al Departamento de Ingeniera de Zona Franca Coyol quienes me abrieron las puertas y me facilitaron el tiempo necesario para la realizacin de la propuesta.

iv

NDICE DE CONTENIDO
DEDICATORIA....................................................................................................................................III RECONOCIMIENTOS..........................................................................................................................IV NDICEDECONTENIDO.......................................................................................................................V NDICEDEILUSTRACIONES.................................................................................................................X NDICEDECUADROS.........................................................................................................................XI NDICEDEABREVIATURAS...............................................................................................................XII RESUMENEJECUTIVO......................................................................................................................XIII 1. INTRODUCCIN.........................................................................................................................1 1.1. 1.2. 1.3. 1.4. ANTECEDENTES.......................................................................................................................... 1 PROBLEMTICA.......................................................................................................................... 2 JUSTIFICACIN............................................................................................................................ 3 OBJETIVOS .................................................................................................................................5

1.4.1. ObjetivoGeneral............................................................................................................... 5 1.4.2. ObjetivosEspecficos......................................................................................................... 5 2. MARCOTERICO.......................................................................................................................8 2.1. MARCOINSTITUCIONAL............................................................................................................... 8

2.1.1. Misin:...............................................................................................................................8 2.1.2. Visin:................................................................................................................................8 2.1.3. Valores:............................................................................................................................. 8 2.2. MARCOTERICO...................................................................................................................... 11

2.2.1. HistoriadelaAdministracindeProyectos .....................................................................11 2.2.2. Institucionesdeadministracindeproyectos.................................................................14

2.2.2.1. PMI..........................................................................................................................................14 2.2.2.2. PRINCE2...................................................................................................................................16

2.2.3. AdministracindeProyectos........................................................................................... 18 2.2.4. Ciclodevidadelproyecto ................................................................................................ 23 2.2.5. GruposdeProcesos......................................................................................................... 25

2.2.5.1. GrupodeProcesosdeIniciacin............................................................................................. 27 2.2.5.2. GrupodeProcesosdePlanificacin........................................................................................ 29 2.2.5.3. GrupodeProcesosdeEjecucin............................................................................................. 31

2.2.5.4. GrupodeProcesosdeSeguimientoyControl......................................................................... 32 2.2.5.5. GrupodeProcesosdeCierre................................................................................................... 34

3.

MARCOMETODOLGICO........................................................................................................37 3.1. FUENTESDEINFORMACIN......................................................................................................... 37

3.1.1. Fuentesdeinformacinprimarias.................................................................................. 37 3.1.2. Fuentesdeinformacinsecundarias...............................................................................38 3.1.3. Mtodosdeinvestigacin............................................................................................... 39

3.1.3.1. Objetivoespecfico#1............................................................................................................ 39 3.1.3.2. Objetivosespecficos#2y3................................................................................................... 40 3.1.3.3. Objetivoespecfico#4............................................................................................................ 41

4.

DESARROLLO...........................................................................................................................42 4.1. 4.2. 4.3. PROYECTOSENZONAFRANCACOYOL........................................................................................... 43 METODOLOGADEPROYECTOSACTUAL......................................................................................... 45 GRUPOSDEPROCESOSDEEJECUCIN........................................................................................... 51

4.3.1.1. Factoresambientalesdelaempresa....................................................................................... 52 4.3.1.2. Activosdelosprocesosdelaorganizacin............................................................................. 53 4.3.1.3. Actadeconstitucindelproyecto(ProjectChrter)...............................................................54 4.3.1.4. Solicitudesdecambioaprobadas............................................................................................ 55 4.3.1.5. Mtricasdecalidad................................................................................................................. 55 4.3.1.6. Medicionesdecontroldecalidad........................................................................................... 55 4.3.1.7. Asignacionesdelpersonalalproyecto.................................................................................... 56 4.3.1.8. Informesdedesempeo......................................................................................................... 56 4.3.1.9. Registrodeinteresados........................................................................................................... 56 4.3.1.10. Estrategiadegestindelosinteresados............................................................................... 57 4.3.1.11. Registrodeincidentes........................................................................................................... 58 4.3.1.12. Registrodecambios.............................................................................................................. 58 4.3.1.13. Documentosdelaadquisicin.............................................................................................. 58 4.3.1.14. Criteriosdeseleccindeproveedores.................................................................................. 59 4.3.1.15. Listadevendedorescalificados............................................................................................. 59 4.3.1.16. Propuestasdevendedores.................................................................................................... 60

4.3.1. EntradasIniciales............................................................................................................ 51

4.3.2. PropuestaMetodolgica................................................................................................. 64
4.3.2.1. Evaluacininicialdelequipodeproyecto(EJ01)................................................................... 64 4.3.2.2. Motivacininicial(EJ02)........................................................................................................ 65 4.3.2.3. PresentacindelActaConstitutivadelProyectoalequipo(EJ03).........................................65 4.3.2.4. Definircanalesdecomunicacin(EJ04)................................................................................. 66

vi

4.3.2.5. Manejodereunionesdeproyecto(EJ05).............................................................................. 67 4.3.2.6. Definirypriorizarriesgos(EJ06) ............................................................................................. 68 4.3.2.7. AseguramientodeCalidad(EJ07) ........................................................................................... 70 4.3.2.8. Desempeosubcontratodecalidad(EJ08)............................................................................ 70 4.3.2.9. Registrodeincidentes(EJ09)................................................................................................. 70 4.3.2.10. Desarrollodelequipointerno(EJ10) .................................................................................... 71 4.3.2.11. Prevenirproblemasentremiembrosdeequipo(EJ11) ........................................................71 4.3.2.12. Evaluarrendimientodelequipo(EJ12)................................................................................ 72 4.3.2.13. Herramientaparadistribuirinformacin(EJ13).................................................................. 72 4.3.2.14. Seleccindeoferentesparalicitacin(EJ14)....................................................................... 74 4.3.2.15. Reunindeaperturadelicitacin(EJ15)............................................................................. 75 4.3.2.16. Visitaalsitio(EJ16) ............................................................................................................... 75 4.3.2.17. Revisindeofertas(EJ17).................................................................................................... 76

4.3.3. ResumendeMetodologadeEjecucin..........................................................................77 4.4. GRUPOSDEPROCESOSDESEGUIMIENTOYCONTROL.......................................................................81

4.4.1. EntradasIniciales............................................................................................................ 81 4.4.2. PropuestaMetodolgica................................................................................................. 81

4.4.2.1. Registrodeleccionesaprendidas(SyC01).............................................................................. 82 4.4.2.2. Mecanismoparaaprobacindecambios(SyC02).................................................................82 4.4.2.3. Verificaralcance(SyC03)........................................................................................................ 83 4.4.2.4. Estudiodelcronograma(SyC04)............................................................................................ 84 4.4.2.5. Seguimientodelcronograma(SyC05).................................................................................... 85 4.4.2.6. Controldecostos(SyC06)...................................................................................................... 89 4.4.2.7. Informarsobreloscostos(SyC07) .......................................................................................... 90 4.4.2.8. Gestionarelcontroldecalidad(SyC08)................................................................................. 90 4.4.2.9. Controldecalidad(SyC09)..................................................................................................... 91 4.4.2.10. Informesderendimientodeproyecto(SyC10).................................................................... 91 4.4.2.11. Seguimientoderiesgos(SyC11)........................................................................................... 93 4.4.2.12. Controlderiesgos(SyC12)................................................................................................... 94 4.4.2.13. Seguimientoaproveedores(SyC13).................................................................................... 94 4.4.2.14. Administracindelcontrato(SyC14)................................................................................... 95 4.4.2.15. Actualizacindedocumentosdeproyecto(SyC15).............................................................95

4.4.3. ResumendeMetodologadeSeguimientoyControl......................................................97 4.5. GRUPOSDEPROCESOSDECIERRE.............................................................................................. 101

4.5.1. EntradasIniciales.......................................................................................................... 103 4.5.2. PropuestaMetodolgica............................................................................................... 103

4.5.2.1. Cierredeproyecto(C01)...................................................................................................... 103 4.5.2.2. Cierrededocumentacin(C02)........................................................................................... 104

vii

4.5.2.3. Reunindecierre(C03)....................................................................................................... 104 4.5.2.4. Informefinal(C04)............................................................................................................... 105 4.5.2.5. Cierredeadquisiciones(C05) ............................................................................................... 105 4.5.2.6. Evaluacinfinaldeproveedor(C06).................................................................................... 106

4.5.3. ResumendeMetodologadeCierre.............................................................................. 106 4.6. 5. 6. 7. 8. VALIDACINDEPROPUESTAMETODOLGICA.............................................................................. 109

CONCLUSIONES.....................................................................................................................114 RECOMENDACIONES..............................................................................................................118 BIBLIOGRAFA........................................................................................................................121 ANEXOS.................................................................................................................................123 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10. 8.11. 8.12. 8.13. 8.14. 8.15. 8.16. 8.17. 8.18. 8.19. 8.20. 8.21. 8.22. 8.23. 8.24. CHRTERDELPROYECTO ........................................................................................................... 123 ESTRUCTURADETALLADADETRABAJODELPFG............................................................................ 125 CRONOGRAMADELPROYECTO................................................................................................... 128 CUESTIONARIOGRUPODEPROCESOSDEEJECUCIN..................................................................... 130 CUESTIONARIOGRUPODEPROCESOSDESEGUIMIENTOYCONTROL.................................................132 CUESTIONARIOGRUPODEPROCESOSDECIERRE........................................................................... 134 RESUMENDEFOCUSGROUPREALIZADOENZFC ............................................................................ 135 PLANTILLA:REGISTRODEINTERESADOSDEPROYECTO .................................................................... 138 PLANTILLA:REGISTRODEINCIDENTESDEPROYECTO...................................................................... 139 PLANTILLA:REGISTRODECAMBIOSDEPROYECTO......................................................................... 140 GUAPARAELABORACINDELACTACONSTITUTIVADELPROYECTO..................................................141 GUAPARAELABORACINLAAGENDADEREUNIN....................................................................... 142 GUAPARAELABORACINLAMINUTADEREUNIN....................................................................... 143 PLANTILLA:REGISTRODERIESGOSDEPROYECTO.......................................................................... 144 PLANTILLA:EVALUACINDEMIEMBROSDELEQUIPO ...................................................................... 145 PLANTILLA:EVALUACINDEOFERENTESPARALICITACIN...............................................................146 PLANTILLA:REGISTRODELECCIONESAPRENDIDASDEPROYECTO.....................................................147 DIAGRAMADEFLUJOPARASOLICITUDYAPROBACINDECAMBIOS...................................................148 PLANTILLA:SOLICITUDDEAPROBACINDECAMBIOS..................................................................... 150 EJEMPLODEPUNCHLIST........................................................................................................... 151 PLANTILLA:REVISINDECRONOGRAMADEPROYECTO..................................................................152 GUAPARAELABORACINDEINFORMESSEMANALESPARAINTERESADOS...........................................153 PLANTILLA:REGISTRODEINFORMESDECALIDAD........................................................................... 154 GUAPARAELABORACINDEINFORMESMENSUALESPARACONTROLINTERNO....................................155 viii

8.25. 8.26. 8.27. 8.28. 8.29.

PLANTILLA:SEGUIMIENTOYCONTROLDERIESGOS........................................................................ 157 PLANTILLA:REGISTRODESEGUIMIENTOAPROVEEDORESDEPROYECTO............................................158 PLANTILLA:EVALUACINFINALDECONTRATISTA ........................................................................... 159 RESUMENDEMETODOLOGAPROPUESTA.................................................................................... 160 EJEMPLODEAPLICACINDEVALORGANADOENCONTROLDECRONOGRAMA.....................................161

ix

NDICE DE ILUSTRACIONES
FIGURA2.1:ESTRUCTURAORGANIZACIONALZFC.............................................................................10 FIGURA2.2:RESTRICCIONESCLAVESENPROYECTOS........................................................................22 FIGURA2.3:RESTRICCIONESCLAVESDEPROYECTOSACTUALES. .......................................................22 FIGURA2.4:CICLODEVIDADELPROYECTO......................................................................................24 FIGURA2.5:INTERRELACINDEGRUPOSDEPROCESOSDURANTEELPROYECTO.............................26

NDICE DE CUADROS
CUADRO4.1.PRINCIPALESTCNICASYHERRAMIENTASDELOSGRUPOSDEPROCESOENESTUDIO. 46 CUADRO4.2.RESUMENDEMETODOLOGADEEJECUCIN. ..............................................................77 CUADRO4.3.RESUMENDEMETODOLOGADESEGUIMIENTOYCONTROL.......................................97 CUADRO4.4.RESUMENDEMETODOLOGADECIERRE...................................................................106 CUADRO4.5.RESULTADOSDEVALIDACINDEMETODOLOGA......................................................110

xi

NDICE DE ABREVIATURAS
AP: CMC: PFG: PMBOK: PMI: PRINCE: ZFC: Administracin de Proyectos Cadence Management Corporation Proyecto Final de Graduacin Project Management Body of Knowledge Project Management Institute Projects in Controlled Environment Zona Franca Coyol

xii

RESUMEN EJECUTIVO
Costa Rica es un pas que cada vez ms le est abriendo sus puertas a la inversin privada extranjera. Los mltiples convenios comerciales que ha generado as como las nuevas tendencias globales que dicta la economa mundial, propician que se d el establecimiento de empresas extranjeras en este pas. Las zonas francas han sido unos de los grandes impulsores y buscadores de esas empresas que han venido a traer sus operaciones, esto gracias en gran medida a los privilegios fiscales con que cuentan. Sin embargo con la reciente aprobacin de la nueva Ley de Zonas Francas, va ser posible que empresas nacionales busquen instalarse en estas zonas francas y gozar de los mismos privilegios, por lo que la gama de posibles y potenciales clientes se incrementa. Zona Franca Coyol es una empresa de capital nacional que ha buscado posicionarse en este mercado atrayendo empresas multinacionales de un perfil alto y con lneas de produccin y de servicio complejas, ofreciendo a sus clientes instalaciones con altos estndares de diseo tanto de los edificios como de la infraestructura. Cuando un cliente nuevo decide instalarse dentro del parque, empieza un proceso a lo interno de la organizacin para disearle y construirle un edificio o nave industrial que se ajuste a sus necesidades y que mantenga la lnea arquitectnica que ha establecido la organizacin, por lo que la zona franca empieza a administrar estos proyectos desde su diseo hasta su construccin. El contar con clientes de primer nivel, hace necesario que esta zona franca sepa responder de forma adecuada a las expectativas de ellos, vindose en la obligacin de lograr proyectos constructivos exitosos, que cumplan el alcance, los costos, el tiempo y la satisfaccin esperados. A pesar de que el departamento de ingeniera del parque cuenta con experiencia previa en este tipo de proyectos, no existe una metodologa establecida para administrar estos proyectos como tal, generando como consecuencia que, aunque ya proyectos hayan finalizado exitosamente, no todos se hayan logrado de la misma manera, desaprovechndose en ocasiones las experiencias previas adquiridas. Por la magnitud de los proyectos que se manejan y por el rpido crecimiento que est teniendo el parque, es que resulta importante que los procesos y labores dentro de la organizacin adquieran cierto grado de estandarizacin, permitiendo de esta forma que se norme la forma en que se administran los proyectos, siendo indiferente el director de proyectos que haya sido asignado. Es por lo anterior que el presente Proyecto Final de Graduacin tuvo como objetivo principal el desarrollar una metodologa que ayudara a los procesos de
xiii

ejecucin, control, seguimiento y cierre de los proyectos constructivos de Zona Franca Coyol, basando esta metodologa en las buenas prcticas recomendadas por el Project Management Institute. Para el desarrollo de esta propuesta metodolgica se utilizaron tanto fuentes de informacin primarias como secundarias. Asimismo para el reconocimiento de la metodologa utilizada actualmente en la zona franca se utiliz la entrevista, as como la documentacin de proyectos anteriores. Una vez que se determin cmo es que se administraban los proyectos, se analiz la informacin y se generaron recomendaciones basadas en las prcticas que seala el PMI como adecuadas, todas estas son las que sustentaron la propuesta metodolgica. La herramienta propuesta consiste en una serie de procesos recomendados para cada uno de los grupos de procesos sealados. Estos procesos estn compuestos por un listado de procedimientos los cuales a su vez estn ligados a herramientas y plantillas propuestas. En las tablas de resumen de la metodologa estn cada uno de estos aspectos para facilitar su aplicacin en el da a da del departamento de ingeniera. Se busc validar la propuesta en un proyecto de Zona Franca Coyol para poder evaluar la verdadera aplicabilidad de la herramienta. Sin embargo por motivos de limitaciones de tiempo por los plazos tan extensos de los proyectos, se logr realizar una validacin parcial en un proyecto de menor tamao. De esta forma fue posible evaluar los procesos recomendados para el cierre de los proyectos constructivos. De acuerdo a las valoraciones del profesional encargado de la validacin, la herramienta es una iniciativa importante con el fin de poder empezar un proceso de ordenamiento y estandarizacin dentro de la zona franca. Algunos de los procesos parten de iniciativas importantes y pueden ser un gran aporte dentro de la institucin, pero deben instaurarse poco a poco para ir generando una cultura organizacional. Es importante que el departamento de ingeniera revise de manera prctica los procedimientos citados para los grupos de procesos de ejecucin, seguimiento y control. Junto con esto tambin debe estar evaluando y actualizando la herramienta completa, para que poco a poco se pueda ir ajustando mejor a la realidad de los proyectos. La herramienta pos s sola no va a lograr que todos los proyectos se vuelvan exitosos y cumplan con todas sus expectativas completamente. Pero es una gua que va permitir orientar de mejor manera a los profesionales de la zona franca para as estandarizar procesos y actividades de forma tal que se pueda potenciar los resultados positivos.

xiv

1. INTRODUCCIN

1.1. Antecedentes Las condiciones sociales y la estabilidad poltica de la que goza este pas, si se comparan con las que se desarrollan en la regin y sumado con las nuevas tendencias de globalizacin que se aplican en el mundo, hacen de Costa Rica un destino atractivo para la inversin extranjera. Este hecho hace que cada vez se vuelva ms concreta la posibilidad de que empresas multinacionales se instalen en el pas, trayendo y estableciendo lneas de produccin especficas y especializadas o instalando aqu un centro de todas sus operaciones. Como respuesta a esta situacin, en Costa Rica es cada vez ms comn la aparicin de parques empresariales y zonas francas las cuales se convierten en oportunidades valiosas para la atraccin de inversin privada en el pas. Zona Franca Coyol es un parque empresarial que fue creado con la intencin de buscar y atender las necesidades de este nicho empresarial extranjero, que busca una expansin fuera de sus pases de origen. Esto ha permitido que desde su creacin hayan podido gestionar que empresas se establezcan dentro de sus instalaciones. Actualmente se encuentran instaladas dentro del parque un total de seis empresas distintas, dedicadas desde la manufactura de componentes mdicos y de uso aeroespacial, hasta la manufactura de colores, sabores y fragancias. Como puede apreciarse, en esta zona franca se instalan empresas de capital extranjero con niveles de produccin elevados. Desde la concepcin de este parque industrial, se ha procurado contar con altos estndares de diseos tanto de edificios como de infraestructura. De esta

forma la zona franca brinda una serie de facilidades importantes para el cliente. A esto debe sumrsele el hecho de estar ubicada en una zona de amplio crecimiento, cerca de la capital y prximo al principal aeropuerto del pas. Todas estas caractersticas descritas, se convierten en un gancho importante a la hora de una empresa decida instalarse dentro de este parque. ZFC siempre ha procurado el mantener un perfil de cliente alto y con lneas de produccin especializadas. El 12 de Enero de 2010 fue firmada la nueva Ley de Zonas Francas de Costa Rica. Esta ley lo que promueve es que el beneficio fiscal no va ser disfrutado nicamente por las empresas exportadoras, sino que tambin se podr favorecer a aquellas empresas que se dediquen al mercado interno. De esta manera la zona franca se encuentra ante una opcin bastante atractiva ya que la posibilidad de clientes aumenta, y ya no tendr necesariamente que buscarlos fuera de las fronteras del pas. De ah la importancia que el parque se mantenga en un proceso constante de desarrollo y mejora.

1.2. Problemtica Cada nuevo cliente que llega a ZFC, significa un nuevo proyecto que debe ser diseado, construido y entregado. La estructura organizativa de esta empresa, cuenta con un departamento de ingeniera que se encarga de administrar el diseo y la construccin de cada uno de los proyectos que surgen, as como de la infraestructura del parque. Sin embargo, si bien es cierto se cuenta con amplia experiencia en el desarrollo de este tipo de proyectos y parques industriales, no existen metodologas establecidas que sirvan de gua durante la ejecucin, seguimiento, control y cierre de los proyectos.

Todos los proyectos que se han realizado en la zona franca, se han hecho gracias a la aplicacin de prcticas de administracin de proyecto conocidas y con base a toda la experiencia que se ha acumulado a lo largo de los aos. A pesar de ello, los procedimientos y las prcticas que se aplican no siempre son las mismas, variando ya sea por la dimensin o magnitud del proyecto o por aspectos ms subjetivos como la forma de trabajar de cada director de proyectos. Esta situacin ha generado que no sea posible finalizar los proyectos con resultados semejantes. Si bien es cierto los proyectos iniciados ha podido ser finalizados, los parmetros de costo, tiempo y calidad que establece el PMBOK (Project Management Institute, 2008), no fueron administrados de la misma forma durante la realizacin de cada proyecto, afectando de esta forma cada producto final. Asimismo, no siempre se logra aprovechar al 100% la experiencia que se ha adquirido en otros proyectos semejantes realizados en el pasado. Esta empresa tiene a su haber la experticia de haber desarrollado otra zona franca como lo es Global Park y el aprendizaje adquirido no siempre es bien aprovechado ni aplicado, precisamente debido a la ausencia de una estrategia completamente desarrollada que permita recopilar lecciones aprendidas. Es evidente que ante compromisos tan grandes con clientes de alto nivel, es de suma importancia que este tipo de procesos sean normados dentro de la institucin, de forma tal que sea posible regular de una mejor manera el desarrollo de los proyectos, disminuyendo las posibilidades de fracaso y mejorando sustancialmente los resultados en cada uno de ellos. 1.3. Justificacin Zona Franca Coyol es un parque empresarial que se encuentra en expansin, actualmente se encuentran radicadas seis empresas, pero se espera que cuando el parque est a capacidad plena se tengan aproximadamente 40 empresas dentro de sus instalaciones. Es por este motivo que es de suma importancia que

los grupos de proceso de la administracin de proyectos constructivos estn debidamente normalizados de cara a todos los proyectos que se efectuarn a futuro. De acuerdo con lo que se ha trabajado hasta el momento, los proyectos que se llevan a cabo dentro de la zona franca son de dimensiones bastante considerables, esto por cuanto actualmente cuenta con proyectos que implican la construccin de 5.000 a 20.000 m2 en una sola etapa, hasta 60.000 m2 previstos a desarrollar en tres etapas. Por ello es que el adecuado manejo del proyecto es de suma importancia para aquellos con este tipo de magnitudes. Precisamente este orden de tamao fsico de los proyectos est ligado a empresas de niveles altos, con estndares de calidad elevados y que de igual manera exigen resultados de clase mundial a los cuales ZFC debe estar preparada para responder y para alcanzar oportunamente. Es por esto que es de suma importancia que se puedan tener un mejor manejo de los proyectos, mediante una correcta ejecucin de ellos, llevando un adecuado control y seguimiento que permita llevarle un pulso continuo al proyecto y por ltimo generando su cierre de forma tal que el proyecto quede recibido a satisfaccin y las lecciones aprendidas queden registradas dentro de la organizacin para su uso posterior. Entre mejor se puedan desarrollar estos procesos en un proyecto, de igual forma la posibilidades de alcanzar un proyecto exitoso se incrementan. El establecer una metodologa de este tipo dentro de esta organizacin, lo que busca es ordenar y reforzar los conocimientos que ya han sido adquiridos productos de la experiencia.

1.4. Objetivos

1.4.1.

Objetivo General

Desarrollar una metodologa que ayude a mejorar los actuales procesos de ejecucin, seguimiento, control y cierre de proyectos constructivos en Zona Franca Coyol de acuerdo a las buenas prcticas recomendadas por el Project Management Institute (PMI).

1.4.2.

Objetivos Especficos

I.

Identificar la metodologa que se aplica actualmente durante la ejecucin, seguimiento, control, y cierre de los proyectos.

Es importante partir de una identificacin de la metodologa actual para conocer de qu forma es que se trabajan los proyectos dentro de la zona franca. Esta investigacin inicial, va a permitir determinar hacia donde debe orientarse en adelante la generacin de la propuesta metodolgica, de forma tal que pueda corregirse aquello que lo amerite, eliminar lo que no aporte valor y propiciar aquellas actividades que no sean realizadas y que se puedan considerar importantes de realizar.

II.

Analizar la metodologa que se aplica actualmente comparndola contra las buenas prcticas recomendadas por el PMBOK.

Las buenas prcticas recomendadas por el PMBOK son la gua sobre la cual se fundamentar la propuesta que se genere para ZFC. Es por ello que la metodologa actual que sea determinada dentro de la empresa, se debe

comparar contra esta herramienta para poder identificarse qu cosas deben eliminarse o cambiarse y en que otros aspectos puede haber una carencia que deba subsanarse con la recomendacin de un nuevo proceso.

III.

Determinar con base en el PMBOK qu nuevas prcticas deben ser realizadas dentro de la organizacin que promuevan una mejor administracin de los proyectos.

Mediante este objetivo se alcanzar el producto final de este PGF. A partir de las nuevas prcticas que se determinen en conjunto con algunas de las que ya se realizan, se plantear una metodologa para la administracin de proyectos en ZFC, que tenga en cuenta todas las consideraciones que se hayan concluido de los dos objetivos especficos anteriores. Todas las actividades o procedimientos que se planteen en esta propuesta, deben estar orientados a mejorar la eficiencia en la

administracin de los proyectos, generando cierto grado de estandarizacin dentro de la organizacin al momento de enfrentar un proyecto.

IV.

Realizar una validacin completa o parcial de la metodologa propuesta mediante alguno de los proyectos que se encuentren en desarrollo.

Todas las empresas son distintas y la gua que provee el PMBOK es una herramienta que debe ser usada aplicando un criterio sumamente profesional para identificar cuales prcticas deben o no utilizarse en cada proyecto. De igual forma, la propuesta metodolgica est fundamentada tericamente en el PMBOK, pero la validacin de la herramienta dentro de la empresa va brindar un criterio real de la aplicabilidad de este instrumento a futuro. Esta validacin va permitir corregir o mejorar caractersticas de la

metodologa de manera tal que se adapte mejor a la realidad de la organizacin.

2. MARCO TERICO

2.1. Marco Institucional Zona Franca Coyol es una empresa de capital nacional que se ha fundado con el objetivo de atraer empresas multinacionales que se establezcan dentro de sus instalaciones. Este es un parque en pleno desarrollo que se encuentra en un rea de 107 hectreas, y que est planificado y diseado para que se convierta en la zona franca ms moderna de todo Centroamrica (Zona Franca Coyol, 2009). Para ello desde su creacin en el ao 2007, se establecieron una misin, visin y valores adecuados y alineados con el propsito de crear un parque con estndares de calidad y responsabilidad altos. De ah se tiene que: 2.1.1. Misin:

Proveer soluciones de alto nivel para los clientes e incrementar el valor para los socios y colaboradores. (Zona Franca Coyol, 2009). 2.1.2. Visin:

Convertirse en los lderes del desarrollo de los bienes races sostenibles de la regin mientras se incrementa los estndares de eficiencia y se promover en los clientes la produccin de productos de alto nivel. (Zona Franca Coyol, 2009). 2.1.3. Valores: (Zona Franca Coyol, 2009)
I.

Compromiso: la empresa est comprometida con el desarrollo de prcticas sostenibles y socialmente responsables y nuestro equipo de trabajo se esfuerza diariamente para satisfacer las necesidades del cliente y la comunidad.

II.

Excelencia: todo nuestro equipo de trabajo se esfuerza en la excelencia y por la respuesta a tiempo con soluciones para cada una de las necesidades del cliente.

III.

Integridad: nuestros trabajadores operan bajo los estndares ms altos de tica.

IV.

Responsabilidad: nosotros cumplimos responsablemente con nuestros compromisos con los clientes y los colaboradores y contribuimos con el desarrollo de la comunidad.

V.

Sostenibilidad: nuestra empresa se esfuerza en mantener relaciones sostenibles de largo plazo con el medio ambiente y la comunidad.

VI.

Eficiencia: nos esforzamos por la excelencia a travs de la eficiencia.

VII.

Innovacin:

nuestra

experiencia

nos

permite

innovar

constantemente y diferenciarnos de competidores.

VIII.

Adaptabilidad: la constante precaucin sobre los cambios en las tendencias del mercado nos permite anticipar las necesidades del cliente y proponer soluciones innovadoras.

En trminos generales, ZFC desarrolla tres actividades principales las cuales estn orientadas al servicio al cliente. Cada una de ellas se va desarrollando de forma secuencial desde que la relacin con el cliente da comienzo. Inicialmente este parque se dedica a la construccin de edificios y naves industriales ya sea para la venta o el alquiler de los mismos, dependiendo de cul sea la necesidad del cliente. Existe la posibilidad de que se le pueda construir al cliente una nave dimensionada de acuerdo a sus caractersticas propias, o puede darse el caso de que clientes un poco ms pequeos puedan alquilar espacios disponibles. Es as como una de sus actividades principales es la administracin de proyectos de construccin. Como se puede ver en la figura 2.1, dentro del marco administrativo de esta organizacin se encuentra un departamento de ingeniera que se encarga de esta labor.

10

Figura 2.1: Estructura Organizacional ZFC

La tarea de administracin se efecta desde el propio diseo del proyecto. Es as como se le da seguimiento a los contratos tanto de consultora del proyecto, as como a aquellos dedicados a la construccin del proyecto. Esta tarea implica el manejo de un amplio e interdisciplinario grupo de profesionales que estn involucrados en cada proyecto que se realiza. Esta primera etapa de las labores de ZFC finaliza con la entrega al cliente de un nuevo edificio con todas las facilidades construidas de acuerdo a los requerimientos y necesidades que se plantearon en la etapa de diseo. Una vez que el proyecto constructivo es finalizado, la empresa puede iniciar con sus labores de produccin y la zona franca cambia su labor para con el cliente, entrando en juego ahora el departamento de operaciones. Este departamento debe estar en constante comunicacin con los clientes que ya estn operando dentro del parque. Lo que buscan es velar simplemente

11

porque el cliente no tenga ningn problema que sea atribuible directamente a la zona franca y si lo tuviese resolverlo con la mayor prontitud. Mediante esta tarea, ZFC se encarga de darle un seguimiento constante a las actividades de los clientes, buscando garantizar que todos los servicios y condiciones que se ofrecieron en un inicio, se mantengan intactas durante la vida del parque y manteniendo siempre niveles de calidad altos. Igualmente, este departamento se encarga de todas las labores de mantenimiento propias del parque. Tareas como la jardinera, limpieza de calles y reparaciones en infraestructura, son labores propias del personal de este departamento. Es de esta forma como ZFC asume sus responsabilidades desde que un contrato es cerrado con un cliente, hasta que este toma posesin de su nuevo edificio e inicio sus operaciones. Cada etapa es de suma importancia ya que cada una alimenta y sirve de base para el desarrollo de la otra. La propuesta metodolgica que se plantear producto de este Proyecto Final de Graduacin (PFG), centra su desarrollo completamente en la etapa de la administracin de los proyectos de construccin. Es as como sta ser de aplicabilidad al departamento de ingeniera de esta empresa, procurando mejorar la eficiencia en la administracin de los proyectos.

2.2. Marco Terico 2.2.1. Historia de la Administracin de Proyectos

Los proyectos han existido desde siempre. A lo largo de toda su historia, la humanidad ha podido ser testigo de la ejecucin de incontables proyectos en todo el mundo. Desde las antiguas pirmides, hasta las plataformas tecnolgicas que se desarrollan hoy en da, son ejemplos claros de cmo la humanidad ha progresado gracias al nacimiento de nuevos proyectos. (Nieva Lpez, 2009)

12

Precisamente, los proyectos son la respuesta que el hombre ha buscado aplicar para poder satisfacer las necesidades emergentes, ya sea en una escala social y grande, o a nivel personal y pequeo. En cada uno de estos proyectos, el ser humano ha aplicado, consciente o inconscientemente, tcnicas y

procedimientos propios de la administracin de proyectos actual, que han permitido alcanzar los objetivos planteados. La direccin de proyectos es un medio o herramienta para lograr que un proyecto sea exitoso. Como tal, sta no es una ciencia exacta, por lo que esto promueve a que est en constante evolucin y actualizacin para as irse amoldando a las cambiantes realidades del mundo. Desde principios del siglo XX, se empezaron a realizar estudios para demostrar de qu forma poda mejorarse la eficiencia en el trabajo. Frederick Taylor (1856-1915), conocido como El padre de la administracin cientfica, demostr que las labores poda mejorarse si se centraban en sus partes fundamentales, dndole prioridad a la eficiencia, en lugar de al esfuerzo y al tiempo. (Microsoft, 2010) Junto a l estuvo como socio Henry Gantt (1861-1919), quien estudi el orden de las operaciones en el trabajo. El fue el creador de los Diagramas de Gantt, los cuales debido a su utilidad todava son ampliamente utilizados (Microsoft, 2010). Estos dos personajes fueron quizs unos de los mayores promotores de lo que sera la administracin de proyectos actual. A partir de sus investigaciones es que se ha basado la evolucin que ha tenido esta materia, es as como ya a partir de los aos 60s, las empresas empiezan a observar las ventajas de organizar el trabajo en forma de proyectos. Desde este momento la administracin de proyectos comienza a

profesionalizarse, ya que antes se haba manejado de una manera ms informal. El general Bernard Schriever, considerado El padre de la gestin de proyectos moderna fue quien para ese entonces desarroll el concepto de concurrencia, el

13

cual innov los programas de trabajo, ejecutndose a partir de ahora tareas en paralelo, reduciendo de esta forma los tiempos de ejecucin de los proyectos (Nieva Lpez, 2009). En estos inicios de la administracin de proyectos actual, haba una mayor tendencia a darle un enfoque ms tcnico a los procesos y se relegaba la parte administrativa del proyecto. Esto traa la consecuencia de que no se generara la suficiente planeacin y se gastaba dinero en re-planear muchas actividades. Sobresala una direccin reactiva. En la dcada de los 60s, nacen las primeras organizaciones destinadas a desarrollar los conceptos, procesos y herramientas de las gestin de proyectos. Es as como en ese periodo se crea el Project Management Institute (PMI) as como el International Project Management Association (IPMA). (Nieva Lpez, 2009) Este tipo de instituciones promovieron la investigacin, mejoramiento y por ende la profesionalizacin de la administracin de proyectos. De esta forma para la dcada de los 80s la tendencia que se traa evolucion, dndose ahora la misma importancia a los procesos administrativos como a los tcnicos. Por ltimo a partir de la dcada de los 90s, el concepto de administracin de proyectos sigue evolucionando y se le da a los proyectos un enfoque de negocio y de recursos humanos. Las consideraciones tcnicas van a pasar a ser el 25% de todos los procesos y la parte administrativa ocupara el 75%. (Fernndez, 2009) Este sera el inicio de lo que se conoce como la direccin de proyectos moderna. sta busca dar un nfasis importante a la planeacin de los proyectos y no escatima ningn esfuerzo en que los proyectos sean bien conceptualizados y analizados, previos a que se inicie su ejecucin, logrando de esta manera un mejor control del mismo y una disminucin de los riesgos. La direccin que se ejerce es proactiva.

14

Otro aspecto a resaltar es la humanizacin que adquiere tanto la administracin de proyecto como el mismo director de proyectos. En l se mantiene el perfil tcnico, organizativo y de liderazgo. Sin embargo se piensa tambin en las personas del equipo de proyecto y se rescata el valor que cada individuo tiene para el xito de los proyectos. Toda esta evolucin que se ha dado, ha sido como una respuesta a los cambios que el mismo mundo ha vivido y como parte de las mejoras que se tienen que ir dando en los procesos. Esta adaptabilidad se ha dado en gran medida gracias a las instituciones que se han dedicado a desarrollar la administracin de proyectos.

2.2.2.

Instituciones de administracin de proyectos

Como se mencion previamente, a partir de la segunda mitad del siglo XX, empezaron a surgir instituciones autnomas dedicadas a la investigacin y desarrollo de la AP en toda su amplitud. Ests se crean debido a la evidente necesidad que se estaba teniendo para ese momento de normalizar y estandarizar los procesos llevados a cabo, sobretodo en un momento de la historia en que el concepto de proyecto estaba adquiriendo mayor notoriedad dentro de la industria humana. 2.2.2.1. PMI

En el ao de 1969 en Estados Unidos (USA, por sus siglas en ingls) es creado el PMI. Esta es una institucin fundada por y para profesionales del rea de la gestin de proyectos. Desde su inicio, esta organizacin ha ido creciendo y actualizndose, convirtindose actualmente en la principal organizacin

profesional del rea de la direccin de proyectos. El primer seminario que organiz este instituto tuvo una asistencia de 80 personas. Ya para la dcada de los 70s contaba con ms de 2000 miembros inscritos y con captulos afuera de USA, permitindolo realizar seminarios fuera de

15

ese pas. En la actualidad, la organizacin cuenta con ms de 500.000 miembros registrados y con presencia en 185 pases, incluido Costa Rica. (Project Management Institute, 2010) Quizs el principal producto que genera y actualiza el PMI, es el Project Management Body of Knowledge (PMBOK). Esta es una gua creada por este instituto que contiene una descripcin general de los fundamentos de la AP. Se entiende que este documento, si bien es cierto enmarca un serie de prcticas, procesos y herramientas debidamente documentadas e investigadas, no representa ms que una recomendacin de buenas prcticas para los proyectos. Mediante el PMBOK el PMI no busca imponer metodologas o herramientas definitivas, ya que hay conciencia de lo dismiles que son todos los proyectos. Es por eso que siempre la responsabilidad de cada decisin y procedimiento que se lleve a cabo en el proyecto es del director de proyectos. Este documento no busca ms que asesorarle en la toma de sus decisiones. Desde esta perspectiva, el PMI ha creado una serie de certificaciones profesionales que son cada vez ms reconocidas en el mundo y demandadas por los profesionales de la direccin de proyectos. A continuacin se detallan las cinco credenciales que se otorgan (Project Management Institute, 2010): Asociado en Gestin de Proyectos Certificado (CAPM): es cuando se ha demostrado una base comn de conocimientos de la gestin de proyectos Profesional en Gestin de Proyectos (PMP): se pasa por una educacin especfica y hay requerimientos de experiencia y adems se aprueba un examen para medir de forma objetiva sus conocimientos. Profesional en Gestin de Programas (PgMP): esta acreditacin es similar a la anterior, sin embargo se debe a educacin y una vasta

16

experiencia tanto en lo relacionado con la direccin de proyectos y programas. Profesional PMI en Programacin (PMI-SP): esta certificacin se brinda a aquellos profesionales que han demostrado contar con experiencia y conocimiento tcnico en el rea de la planeacin del desarrollo y seguimiento de los cronogramas del proyecto. Profesional PMI en Gestin de Riesgos (PMI-RMP): este ltimo certificado se concede a aquellos profesionales que cuentan con experticia en la identificacin de riesgos del proyecto, as como en la realizacin de los planes para mitigarlos y convertirlos en oportunidades. Es mediante este tipo de certificados que el PMI (2008) busca mejorar la calidad de los profesionales que tiene inscritos. Sin duda alguna la acreditacin ms famosa con que cuenta esta institucin es la de PMP. Toda la teora de la AP que se debe conocer para lograr esta acreditacin proviene del PMBOK. Este libro es el que le provee al PMP muchas de las herramientas necesarias para el adecuado manejo y desarrollo de los proyectos que tenga asignados. Sin duda alguna, el PMI (2008) es una organizacin que ofrece una gran oportunidad de crecimiento para todos los profesionales que laborar en la AP. Sin embargo, no es el nico instituto que se ha dedicado al desarrollo de esta materia.

2.2.2.2.

PRINCE2

PRINCE2 (Projects in Controlled Environments) es un estndar desarrollado y utilizado extensamente por el gobierno del Reino Unido y es igualmente reconocido por el sector privado tanto local como internacionalmente. (Scribd, 2010)

17

Este mtodo es una propuesta evolucionada de su antecesora denominada Prince. Esta fue originalmente desarrollado en 1989 como mtodo de gestin por la Central Computer and Telecomunications Agency (CCTA) del gobierno britnico. (Scribd, 2010) As como el PMI, en 1990 PRINCE publica sus primeros manuales para la gestin de los proyectos orientados al sector de las telecomunicaciones. Posteriormente para 1996 se lanza al mercado PRINCE2. (Prince2, 2010) Esta nueva versin se hizo que fuera compatible con todo tipo de proyectos. Las principales caractersticas del PRINCE2 son las siguientes (Scribd, 2010, pg. 9): Su enfoque en una justificacin de negocio. Una estructura de organizacin definida para el equipo de gestin del proyecto. Una planificacin basada en productos. Su nfasis en dividir el proyecto en fases manejables y controlables. Su flexibilidad para ser aplicado al nivel apropiado del proyecto.

Mediante esta organizacin tambin puede lograrse la acreditacin como PRINCE2 Practitioner. Esta certifica que el profesional acreditado tiene conocimientos y experiencia en la utilizacin del mtodo PRINCE2. (Prince2, 2010)

Ambas instituciones buscan un objetivo comn como es el desarrollo de la AP, por lo cual no es posible verlas como enemigas entre s. Por el contrario dependiendo de las condiciones de cada proyecto, las metodologas pueden ser complementarias. El PRINCE2 se puede ver ms como un mtodo para la gestin de los proyectos, mientras que el PMBOK es un conjunto de conocimientos y buenas

18

prcticas recomendadas. En este sentido, el PMI da una mayor libertad a la hora de dirigir un proyecto. As como estos dos, existen otras opciones y propuestas para la gestin de proyectos que pueden utilizarse, todo depende de cada proyecto y de cada director. Cada una de ellas buscan el mismo objetivo, alcanzar el xito en los proyectos. Ser tarea de cada equipo de proyecto, determinar si se utiliza un mtodo especfico o se toma lo mejor de cada uno, de cara al proyecto que se va a desarrollar.

2.2.3.

Administracin de Proyectos

De acuerdo al PMBOK 4ta edicin, la administracin de proyectos es la aplicacin de conocimiento, habilidades, herramientas y tcnicas a las actividades del proyecto para satisfacer los requisitos del proyecto (Project Management Institute, 2008, pg. 6). Cada da, todas las personas participan en uno o varios proyectos de diversa ndole y complejidad. Desde aquellos que son asignados dentro de sus funciones diarias a nivel laboral, hasta aquellos proyectos personales en que una persona puede involucrarse. Algo tan simple como ir al supermercado, se puede ver como un proyecto y ejecutarlo como tal. De acuerdo a Chamoun (2002), un proyecto es un conjunto de esfuerzos temporales, dirigidos a generar un producto, o servicio nico (pg. 27). Esta definicin que plantea este autor, est basada en la que se hace en el PMBOK. El producto o servicio que se genera al final del ciclo de vida de los proyectos se crea con base a una necesidad especfica que necesita ser satisfecha. Es por esto que los proyectos no son ms que una respuesta para atender a eso. Se puede encontrar varios tipos de necesidades, ellas son (Heldman, 2002):

19

I.

De mercado: el mercado puede ser responsable de la aparicin de nuevos proyectos. Por ejemplo cuando un banco tenga una iniciativa de ofrecer a sus clientes prstamos por internet debido a la cada en las tasas de inters y un aumento en la demanda de prstamos para financiamiento de casas.

II.

De negocio: este tipo de proyectos se generan cuando se quiere ofrecer un nuevo producto en el mercado o se quiere mejorar un ya existente.

III.

Tecnolgica: constantemente se estn actualizando y evolucionando las plataformas tecnolgicas en el mundo, muchas veces estos cambios suponen el ajuste de muchos otros productos. Esta situacin promueve que en muchas empresas se generen proyectos.

IV.

De cliente: la mayora de las compaas tienen clientes y sus solicitudes pueden desembocar en nuevos proyectos. Los clientes pueden ser tanto internos como externos.

V.

Legal: este tipo de proyectos se da en muchas ocasiones debido a nuevas leyes o reglamentaciones aprobadas que pueden hacer que se modifiquen productos o servicios. Por lo tanto esas actualizaciones implican nuevos proyectos.

VI.

Social: este tipo de necesidad est ligada a proyectos gubernamentales. Por ejemplo cuando se necesite atacar problemas de inseguridad o salud, requerir el planteamiento de proyectos en las instituciones responsables. Es a partir de cualquier de la seis reas anteriores, que va surgir una

necesidad que eventualmente va propiciar la creacin de un proyecto. Aunque el origen de los proyectos est supeditado a estas reas anteriores, la razn misma o la necesidad pueden ser distintas, es por ello que se parte de hecho de que todos los proyectos son distintos.

20

Es imposible encontrar proyectos iguales, pueden tener un mismo objetivo y buscar el mismo producto, pero por la forma en que se desarrollan, como se realizan o el medio en que se desenvuelven, hacen que las caractersticas del proyecto varen entre ellos. En el caso de ZFC que se dedica a la construccin de naves industriales, puede darse el caso que de que necesiten construir dos edificios con un diseo exactamente igual. Sin embargo al tener que realizarse en partes distintas del parque y con personal distinto, esto hace que las condiciones para cada proyecto varen, teniendo entonces que el producto es el mismo, pero el proyecto es distinto. A pesar de que todos los proyectos son distintos, todos cuentan con ciertas caractersticas en comn que se deben presentar para poder decir que se trata de un proyecto. Tanto el PMBOK como PRINCE2 concuerdan en estas

caractersticas. Por su lado el PMI establece que todos los proyectos deben ser: (Project Management Institute, 2008) Un esfuerzo temporal: tiene un inicio y fin determinados, no se prolongan indefinidamente. nico: no hay dos proyectos iguales. Por su lado, PRINCE2 de la misma manera indica que todos los proyectos deben contar al menos con las siguientes caractersticas (Scribd, 2010, pg. 11): Una vida finita y definida. Productos de negocios definidos y mensurables. Un conjunto de actividades para obtener los productos de negocio. Una cantidad definida de recursos. Una estructura organizativa, con responsabilidades definidas, para gestionar el proyecto.

21

Como puede observarse, ambas propuestas tericas parten del hecho de considerar que los proyectos se tratan de esfuerzos finitos con recursos agotables y una estructura definida para tal. Si lo que se est emprendiendo es algo que se prolongar indefinidamente en el tiempo, no puede ser considerado como proyecto, ya que esa indefinicin no permitira planear el proyecto como lo recomiendan estos estndares. En todo proyecto es importante que los involucrados en l, ya sea como beneficiarios primarios o secundarios, tengan claro cul es el objetivo que se busca y cules son sus requerimientos. Esto permitir que el norte a seguir sea ms claro con tal de alcanzar el xito en el proyecto. La concepcin de proyecto exitoso puede volverse bastante subjetiva, porque puede depender de las expectativas de cada persona. Si dos personas mandan a construir dos cuartos iguales y se los entregan sin pintar, puede ser que uno de ellos quede satisfecho con el resultado, pero si la otra persona se lo imagin pintado de un color diferente, no va poder concebir este proyecto como exitoso. En este sentido, Cadence Management Corporation (2009) establece que el concepto de xito est regulado por tres restricciones claves aplicables a todos los proyectos, las cuales se pueden apreciar en la figura 2.2. Como puede apreciarse, CMC lo que plantea que el proyecto exitoso es aquel que se cumple dentro de los plazos de tiempo que fueron establecidos desde su planificacin, de forma tal que no se hubiesen presentado atrasos con la entrega del proyecto. Asimismo, el proyecto debe completarse con el presupuesto que se estim y se aprob desde su comienzo. Por ltimo lo que establece es que se cumpla con el desempeo esperado del mismo. Por desempeo, esta organizacin define que involucra finalizar el proyecto con el alcance con el que fue pensado, adems de lograr finalizarlo con los niveles de calidad solicitados y esperados.

22

Costo

Tiempo

Desempeo

Figura 2.2: Restricciones claves en proyectos (Cadence Management Corporation, 2009)

Estas tres restricciones cumplen su funcin desde un punto de vista tcnico. Sin embargo, como se vio en secciones anteriores, desde la dcada de los 90s, la administracin de proyectos evolucion hacia una cultura de administracin ms humana y en la que los aspectos administrativos tienen ms importancia que los tcnicos. Costo

Satisfaccin delcliente
Desempeo

Tiempo

Figura 2.3: Restricciones claves de proyectos actuales.

23

Es por ello que en la actualidad se concuerda con el concepto que la figura 2.2 muestra. Sin embargo se le agrega una nueva dimensin, la cual a la postre se puede convertir en una ms determinante a la hora de calificar a un proyecto como exitoso o no. Hoy en da el xito se mide en funcin del tiempo, costo y desempeo, pero tambin considerando la satisfaccin del cliente, tal y como se muestra en la figura 2.3. Esta ltima variable adquiere una gran importancia debido a que toma en cuenta la subjetividad del cliente para saber si el producto es o no adecuado. Si los primeros tres parmetros se cumplen pero no se tiene un cliente satisfecho, no es posible considerar que el proyecto haya sido exitoso. De ah que es de suma importancia llevar un mejor control y registros de los requerimientos y cambios del proyecto a lo largo de todo su ciclo de vida, unido con una fluida comunicacin con el cliente para aumentar las posibilidades de que el producto que se obtenga sea de agrado para el cliente.

2.2.4.

Ciclo de vida del proyecto

Como se indic recientemente, una de las caractersticas principales de los proyectos es que son un esfuerzo temporal, es decir tiene una duracin cuantificable. Con base a esto es que es posible establecer un ciclo de vida a los proyectos. Bsicamente, el PMI (2008) establece un ciclo de vida basado en cuatro etapas: inicio, organizacin y preparacin, ejecucin del trabajo y cierre. En estas cuatro fases se basa el desarrollo de un proyecto desde el surgimiento de su necesidad hasta su finalizacin. En la figura 2.4, Gido & Clements (2007) presentan la relacin del esfuerzo versus tiempo en el ciclo de vida del proyecto. Las primeras dos etapas son dedicadas primero que nada al establecimiento de la necesidad por la cual el

24

proyecto naci y por otro lado a la planificacin. Es visible como la etapa de ejecucin es en la que se consume el mayor esfuerzo a lo largo de todo su ciclo de vida.

Esfuerzo

Identificar una necesidad

Desarrollar una solucin propuesta

Realizarel proyecto

Concluir elproyecto

Tiempo

Figura 2.4: Ciclo de vida del proyecto (Gido & Clements, 2007)

A lo largo de este ciclo de vida, pueden intervenir distintos profesionales y grupos de trabajo, por lo que probablemente la nica persona que est involucrada desde la concepcin del proyecto hasta que este es entregado es el patrocinador o algn stakeholder primario. Esta situacin se ve reflejada en la operacin de ZFC. Es as como una vez que se cierre un contrato con un cliente, se empiezan a recolectar sus necesidades y a ajustar su diseo. Hasta que ste est aprobado es que interviene de manera activa el departamento de ingeniera del parque. Este departamento se involucra al 100% hasta que se llega a la fase de Realizacin del proyecto. Es por esto que este PFG basar su desarrollo en esta seccin. El ciclo de vida del proyecto separa su desarrollo en etapas claras de su crecimiento. Sin embargo, en el PMBOK (Project Management Institute, 2008) se

25

establecen tambin procesos todava ms especficos que deben desarrollarse en su totalidad dentro de cada una de las etapas del ciclo. Estos son los grupos de procesos.

2.2.5.

Grupos de Procesos

Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener un producto, resultado o servicio predefinido (Project Management Institute, 2008). Estos grupos de procesos lo que vienen es a ordenar el procedimiento en que el proyecto se va a desarrollar, con el fin de poder facilitar la coordinacin. De acuerdo a lo que establece el PMI (2008) hay cinco grupos de procesos dentro de la Direccin de proyecto, a saber:
I. II. III. IV. V.

Grupo del Proceso de Iniciacin. Grupo del Proceso de Planificacin. Grupo del Proceso de Ejecucin. Grupo del Proceso de Control y Seguimiento. Grupo del Proceso de Cierre. Estos grupos de procesos se pueden presentar de forma terica como

elementos separados y con caractersticas bien definidas que los diferencian entre s, sin embargo cada uno de ellos cuenta con dependencias establecidas que hacen que en la realidad de los proyectos, estos grupos se superpongan.

26

El elemento que liga a cada grupo de proceso son los resultados que producen. Es as como lo que se obtenga al final de uno de estos grupos signifique la pieza necesaria para poder arrancar el siguiente. La ilustracin 2.5, muestra la situacin ms comn que se suele dar con estos grupos de procesos.

Grupode Procesosde Inicio

Grupode Procesosde Planificacin

Grupode Procesosde Ejecucin

GrupodeProcesos deControly Seguimiento

Grupode Procesosde Cierre

Nivel

de

interaccin entre proyectos

Inicio

Finalizacin

Tiempo Figura 2.5: Interrelacin de grupos de procesos durante el proyecto. (Project Management Institute, 2008)

Es posible ver que as como hay grupos tales como el de iniciacin y cierre que tienen participacin en momentos especficos del proyecto, hay otros como el de planificacin o control y seguimiento, que estn presentes durante casi toda la vida del proyecto. La interrelacin que se da entre ellos es absoluta. No es posible ver, entender o evaluar algn grupo de proceso de un determinado proyecto de forma separada y sin contemplar cuales fueron las entradas que iniciaron este grupo y cules sern sus salidas.

27

Cada uno de estos grupos est compuesto por los procesos constitutivos de la AP, los cuales segn lo indica el PMI (2008), llegan a ser 42 procesos distintos. Son precisamente estos procesos los que proveen y generan las entradas y salidas necesarias para ligar los grupos de procesos y desarrollar el proyecto. Es importante aclarar que los grupos de procesos no constituyen ni fases ni etapas del proyecto del proyecto en s, por el contrario estos grupos son los que conforman cada una de las etapas del proyecto. Si un determinado proyecto es dividido en tres fases distintas, pues entonces en cada una de estas fases se repetirn los grupos de procesos vistos. El presente PFG centrar su desarrollo en el estudio y mejora de los grupos de procesos de Ejecucin, Control y Seguimiento y Cierre de los proyectos constructivos de ZFC. Para su mejor referencia y entendimiento, a continuacin se brindar una descripcin de cada uno de los 5 grupos de procesos. 2.2.5.1. Grupo de Procesos de Iniciacin

Este grupo de proceso inicia con el reconocimiento formal por parte de todos los involucrados de que el proyecto debe empezar y que se deben asignar y comprometer los recursos a l. Para este momento la necesidad que genera el proyecto ya tiene que estar determinada. El Grupo del Proceso de Iniciacin est compuesto por aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtencin de la autorizacin para comenzar dicho proyecto o fase (Project Management Institute, 2008). En este grupo de proceso es que se van a definir las principales caractersticas con las que contar el producto final y sobre las cuales se basar toda la programacin y estimaciones que se hagan con respecto al proyecto. Es importante que en esta etapa estn involucrados los stakeholders y el patrocinador de forma activa ya que ellos son los que determinarn al final la satisfaccin del cliente.

28

Inicialmente se deben definir las metas u objetivos que se buscarn con el proyecto. Las metas y objetivos son los propsitos para realizar el proyecto, y ellos describan el resultado final del proyecto (Heldman, 2002). Todos estos objetivos deben estar establecidos en trminos tangibles. Asimismo, es necesario que empiecen a determinarse los requerimientos del proyecto. Esto no es lo mismo que los objetivos, sino por el contrario se tratan de especificaciones con que deben contar los entregables que se hayan establecido. Los requerimientos van a ayudar a responder la pregunta: Cmo se sabr si el proyecto es exitoso? (Heldman, 2002). El ltimo aspecto que tiene que fijarse son los entregables del proyecto. Estos se tratan de resultados o productos o servicios especficos que se tienen que dar para poder decir que el proyecto ha sido completado. Es muy importante que todos estos aspectos vistos queden establecidos en esta etapa y que de igual forma queden registrados. El registro es fundamental para que posteriormente no ocurran divergencia de criterios entre los miembros del equipo de proyecto y los stakeholders con respecto al producto. Es por ello que el PMBOK establece dos resultados muy tangibles luego de pasar por este grupo de proceso. Inicialmente solicita que se desarrolle el Chrter del proyecto o el Acta de Constitucin del proyecto. Este es un documento que recoge toda la informacin que se indic en prrafos anteriores de forma tal que quede documentado y firmado por el patrocinador y por el gerente de Proyecto. Asimismo, el PMI (2008) incluye el proceso de Identificacin de los stakeholders. Esto lo hace para que desde el comienzo del proyecto se tenga claramente identificados cuales son los interesados del proyecto y cules son sus intereses. Esto de igual forma promueve que haya una comunicacin fluida con ellos a lo largo del proyecto si ya se tiene claro quines son.

29

2.2.5.2.

Grupo de Procesos de Planificacin

Este es quizs uno de los procesos que mayor trabajo lleva ya que en l se hace una planificacin extensiva de lo que ser el proyecto y se dejan sentadas las bases para lo que ser su ejecucin y control. El Grupo del Proceso de Planificacin est compuesto por aquellos procesos realizados para establecer el alcance total del esfuerzo, definir y refinar los objetivos, y desarrollar la lnea de accin requerida para alcanzar dichos objetivos (Project Management Institute, 2008). Este grupo de proceso es de suma importancia porque las salidas que genera son las que van a permitir que el proyecto se empiece a ejecutar. En aos recientes se la ha dado ms importancia a este grupo de proceso que a la misma ejecucin ya que se ha podido determinar que entre mejor planificado est el proyecto, las posibilidades de xito aumentan considerablemente. El plan que se genere de este proceso de planificacin va a abarcar casi todas las reas del conocimiento que ha establecido el PMI. A saber: alcance, tiempo, costo, calidad, riesgos, adquisiciones, recursos humanos y

comunicaciones e integracin. Es as como para la fijacin del alcance se debe establecer definitivamente los requisitos del proyecto, enunciar el alcance y realizar la estructura detallada de trabajos (EDT) en la cual se deber reflejar los entregables que tendr el proyecto. Con respecto al tiempo, el proceso de planificacin deber dejar definidas las actividades que tienen que realizarse, secuenciarlas, y estimar los recursos que requerirn, tanto humanos como econmicos. Una vez que estos aspectos estn definidos ser posible desarrollar el cronograma del proyecto. De igual forma, se debe estimar un presupuesto. Este presupuesto se realiza con base en toda la informacin que se ha generado hasta el momento y asignando un costo. El presupuesto va a convertirse en una herramienta

30

importante porque es uno de los rubros que vigilan con ms recelo los stakeholders y an ms el patrocinador. Continuando con la lista de tareas que se deben ejecutar en este grupo de procesos, es necesario establecer el plan de calidad. En este se tienen que identificar cules sern los requisitos y normas de calidad que deben seguirse. De igual forma, el plan tiene que indicar de qu forma se va medir la calidad en cada uno de los rubros que considere. Los recursos humanos tambin son tomados en cuenta, mediante el establecimiento de un plan en el cual se deben identificar los roles, responsabilidades y habilidades que son requeridas en el equipo de proyecto. Es necesario tambin que se planifiquen adecuadamente las comunicaciones en el proyecto. Este plan tendr que aclarar cules sern las vas y los flujos de informacin que deben gestarse durante todo el proyecto. Este es uno de los principales aspectos que debe cuidarse porque muchas veces se generan problemas por una mala comunicacin y en otros casos se pueden evitar problemas si la comunicacin es ptima. Es tambin importante desde este momento del proyecto, realizar una profunda identificacin de los riesgos latentes que pudieran afectar el proyecto. El plan de riesgos debe iniciar por una tarea meticulosa e interdisciplinaria en la cual se puedan identificar todos los riesgos posibles. Se tiene que generar posteriormente un anlisis cualitativo y un anlisis cuantitativo de riesgos, para de esta manera poder planificar la respuesta a estos riesgos. La correcta planificacin de riesgos puede ser un aspecto determinante para el xito en un proyecto si se le da el seguimiento adecuado por parte del equipo. La planificacin debe cuidar las adquisiciones del proyecto, donde tiene que quedar registro de las decisiones de compra en el proyecto as como de posibles

31

proveedores que deban de ser tomados en cuenta cuando se vaya a concretar la compra. 2.2.5.3. Grupo de Procesos de Ejecucin

La ejecucin del proyecto es cuando ya se va a poner en prctica todos los planes que se generaron de la planificacin del proyecto. En este grupo de proceso es cuando el producto ya se empieza a gestar de una forma tangible y fsica. En simples palabras aqu es donde materializa el plan de proyecto. Las entradas que tendr este grupo de proceso sern todos los planes y entregables que se generaron en la planificacin. Para poder iniciar con la ejecucin ya todas las actividades deben estar claras y contarse con la autorizacin oficial para iniciar. Asimismo deben tenerse los recursos econmicos y humanos asignados. Este es probablemente el grupo de procesos en el que ms cuidado se debe tener y en el que se generan la mayor cantidad de problemas. A partir de su comienzo se empieza a lidiar con una serie de factores que vuelve a la ejecucin en un proceso delicado y de cuidado. Todos estos factores deben ser controlados por los planes que fueron creados durante la planificacin, pero no siempre es as de fcil. Un aspecto determinante para que la ejecucin se lleve a cabo de buena manera, es el equipo de proyecto. Una vez que se inicie con este proceso se tiene que adquirir el equipo, por lo que se deben buscar los recursos humanos disponibles y necesarios con base al plan que se haba realizado. Asimismo es determinante el poder desarrollar el equipo y dirigir el equipo. Tal vez uno de los aspectos que vuelven ms complicada la ejecucin de los proyectos es la intervencin tan directa del recurso humano en los resultados. Este es quizs el recurso ms difcil de controlar, por lo que se convierte en el que ms hay que darle seguimiento. De ah que el desarrollo del equipo se vuelva un aspecto relevante en el proyecto.

32

Durante la ejecucin tambin es fundamental realizar el aseguramiento de la calidad. Este es un proceso que consiste en auditar los requisitos de calidad y los resultados obtenidos a partir de medidas de control de calidad, a fin de garantizar que se utilicen definiciones operacionales y normas de calidad adecuadas (Project Management Institute, 2008). En un proceso como este, en el cual se empieza a gestar lo que ser el producto final, la comunicacin tambin adquiere un papel de trascendencia para que el producto final sea satisfactorio para el cliente. Es por ello que se debe velar porque el plan de comunicaciones que se estableci sea cumplido a cabalidad por los miembros del equipo del proyecto. Se debe tener una fluidez de informacin de tal manera que se puedan tomar decisiones correctas y a tiempo para que no se impacte el proyecto. Por esto es que la comunicacin con los interesados tiene que ser lo ms constante que se requiera Por ltimo se tiene que velar por realizar las adquisiciones. Durante la planificacin se determinaron que equipos y materiales deban de ser comprados. Ahora lo que toca es realizar las compras de acuerdo al plan. 2.2.5.4. Grupo de Procesos de Seguimiento y Control

Como puede verse en la ilustracin 2.5, este es el nico grupo de proceso que est presente a lo largo de todo el proyecto. Desde que se da el inicio hasta que se finaliza su cierre, deben estar presentes tareas de seguimiento para poder verificar que se est desarrollando un proyecto de forma adecuada y apegada a las restricciones y requerimientos establecidos. En este grupo de procesos se van a llevar a cabo todas las actividades necesarias para poder supervisar y regular el progreso que tenga el proyecto mientras este se est ejecutando. De este constante seguimiento es que se identificarn los cambios que sean necesarios y eventualmente se aplicarn.

33

Es importante ver que los cambios no necesariamente van a implicar efectos negativos sobre el proyecto, ya que puede haber algunos que al contrario produzcan resultados positivos. Lo importante es saber manejar este proceso adecuadamente, porque es necesario un solo cambio para que se impacte el tiempo, el costo, el alcance o la calidad. El PMBOK (Project Management Institute, 2008) asimismo, indica que este grupo tambin incluye: Controlar cambios y recomendar acciones preventivas para anticipar posibles problemas. Dar seguimiento a las actividades del proyecto, comparndolas con el plan para la direccin del proyecto y la lnea base desempeo de ejecucin del proyecto. Influir en los factores que podran eludir el control integrado de cambios, de modo que nicamente se implementen cambios aprobados. (Project Management Institute, 2008, pg. 59)

Este ltimo punto es quizs uno de los que se deben manejar con mayor precaucin, ya que se tiene que evaluar el cambio, revisar, aprobar y gestionar su ejecucin. Este proceso es importante que se haga de la mejor manera y con el menor tiempo de respuesta posible para evitar la posibilidad de impactar el proyecto. De la misma forma se tiene que verificar el alcance del proyecto, de tal manera que se haga una revisin de los entregables que se van dando y que estn acordes con los requerimientos establecidos. Igualmente se debe controlar el alcance, revisando y actualizando los cambios aprobados. Adems del alcance se debe tener un control sobre el cronograma, los costos y la calidad del proyecto. Estas otras variables constituyen las otras restricciones que se pueden apreciar en la ilustracin 2.3. De ah que de igual manera es importante que sean controladas correctamente.

34

Por ltimo se tiene que seguir y controlar tantos los riesgos identificados como las adquisiciones que fueron solicitadas y compradas. Esto implica por un lado implementar los planes de respuesta a los riesgos cuando fuese necesario, as como actualizar el listado de riesgos. Y por otro lado se deben revisar los contratos generados producto de las adquisiciones realizadas. Este grupo de procesos es el que le va permitir al director de proyectos tener mayor seguridad y certeza de que el proyecto va por buen camino o de que se requiere un cambio. De ah que tambin es importante circular adecuadamente informes de desempeo del estatus del proyecto. Entre mayor y ms fluida sea la informacin entre el equipo del proyecto y para con los interesados, mejor va resultar la respuesta a los problemas que se generan. Este grupo de procesos no busca problemas, pero si los identifica y cuando se realiza con buena anticipacin, entonces est cumpliendo su misin. 2.2.5.5. Grupo de Procesos de Cierre

Es probable que una vez que se haya completado el proceso de ejecucin y se haya llevado un buen control y seguimiento, se genere un sentimiento de que el proyecto ya ha finalizado. Esto puede ser comn en muchos proyectos y hasta esperable, teniendo en cuenta que ya se han pasado por los picos de esfuerzo y de costos del proyecto. Sin embargo todava resta cerrar el proyecto adecuadamente. Este es un grupo de procesos que en muchas ocasiones queda marginado y al cual no se le presta el mayor cuidado. Esto trae consigo que los proyectos no sean cerrados de la mejor manera. El problema es que no importa si el proyecto fue un xito y el producto cumple con todos los requisitos, si el proyecto no ha sido cerrado entonces este no va haber finalizado su ciclo de vida completo, dejando de lado actividades importantes por fuera. El Grupo del Proceso del Cierre est compuesto por aquellos procesos realizados para finalizar todas las actividades a travs de todos los grupos de

35

procesos de la direccin de proyectos, a fin de completar formalmente el proyecto, una fase del mismo u otras obligaciones contractuales. Este grupo de procesos, una vez completado, verifica que los procesos definidos se hayan completado dentro de todos los grupos de procesos a fin de cerrar el proyecto o una fase del mismo, segn corresponda, y establece formalmente que el proyecto o fase del mismo ha finalizado (Project Management Institute, 2008). De acuerdo con Heldman (202), existen cuatro posibles razones para que un proyecto finalice:
I.

Adicin: esto sucede cuando las actividades de un proyecto se empiezan a transformarse en una operacin. Es decir cuando el proyecto se convierte en una unidad del negocio y empieza a generar un trabajo por un periodo de tiempo indeterminado.

II.

Inanicin: esto se da cuando le son arrebatados los recursos al proyecto antes de que pudiera ser terminado. Esta situacin se puede presentar por diversas razones, como que otro proyecto haya adquirido mayor importancia, por una reduccin en el presupuesto o por cambios en el entorno e intereses del proyecto.

III.

Integracin: ocurre cuando los recursos del proyecto tanto humanos como materiales son distribuidos en otras reas o en otros proyectos que se estn desarrollando. Esto muchas veces puede suceder por restructuraciones organizacionales que se den mientras el proyecto est desarrollndose. La diferencia con el anterior es que en la inanicin los recursos son eliminados, en este caso ms bien son reasignados.

IV.

Extincin: esta es la forma en la que todos los proyectos deberan finalizar. La extincin se da cuando el proyecto es completado, entregado y aceptado por los stakeholders. Esto implica que el proyecto desaparece y por ende queda cerrado.

36

Evidentemente el ideal de todo director de proyecto es que se pueda realizar un cierre por extincin, donde el proyecto cumpla con todos los requerimientos por los cuales fue concebido. Sin embargo sin importar de qu forma se d, el cierre administrativo del proyecto debe realizarse. Este cierre se compone de juntar y generar informacin para formalizar su cierre y que todos los involucrados estn conscientes de que el proyecto ya se cerr. El PMBOK (Project Management Institute, 2008) seala una serie de actividades que pueden darse durante el cierre de un proyecto: Obtener la aceptacin del cliente o del patrocinador. Realizar una revisin tras el cierre del proyecto o la finalizacin de una fase. Registrar los impactos de la adaptacin a un proceso. Documentar las lecciones aprendidas. Aplicar actualizaciones apropiadas a los activos de los procesos de la organizacin. Archivar todos los documentos relevantes del proyecto en el sistema de informacin para la direccin de proyectos para ser utilizados como datos histricos. Cerrar las adquisiciones (Project Management Institute, 2008, pg. 64)

37

3. MARCO METODOLGICO
En este captulo se establecen las pautas marcadas de cmo se desarroll el proyecto. Se describe la forma en que se recolect la informacin y cmo fue procesada.

3.1. Fuentes de informacin La fuente de informacin es el lugar u objeto en donde se llegan a encontrar los datos necesarios acorde con el objetivo de la investigacin. En este proyecto especfico fue posible contar con dos tipos de fuentes de informacin.

3.1.1.

Fuentes de informacin primarias

Las fuentes de informacin primarias son todas aquellas que se lograron obtener de primera mano y de forma directa. Es decir, que no existi un intermediario, ya sea una persona o un documento. En este PFG la fuente de informacin primaria ms importante fue el departamento de ingeniera de ZFC. Mediante la aplicacin de focus group con los profesionales del departamento, fue posible conocer y recopilar la informacin sobre la forma en que los proyectos se manejan actualmente. Estas sesiones se realizaron con los ingenieros senior con que cuenta la organizacin, tal y como se puede ver en la figura 2.1. Esta fue una herramienta que permiti obtener informacin de primera mano sobre la opinin de ellos a cerca de aspectos especficos de los proyectos en la zona franca. Estos focus group fueron dirigidos mediante la resolucin de cuestionarios los cuales fueron creados para lograr conocer la forma en que se trabaja actualmente. Otra fuente primaria fueron los proyectos en s que se estaban llevando a cabo en el momento de la ejecucin del PFG. Para extraer esta fuente se

38

realizaron periodos de observacin de forma tal que se pudo conocer mejor como son los procedimientos empleados actualmente.

3.1.2.

Fuentes de informacin secundarias

Las fuentes secundarias fueron todas aquellas en las que, al contrario de las anteriores, hubo un intermediario de por medio, de forma tal que la informacin que se obtuvo pas por alguien y pudo haber sido objeto de anlisis previo. La fuente de informacin secundaria principal que se utiliz fue el PMBOK (Project Management Institute, 2008). Este libro recoge todas las buenas prcticas recomendadas por el PMI que sern la base de la propuesta metodolgica que se realice. Asimismo, se cont con el apoyo de material bibliogrfico de autores que tienen reconocimiento y trayectoria en el mbito de la AP, toda esta bibliografa fue un complemento al aporte que realiz el PMBOK. De igual manera, otras fuentes secundarias fue toda la documentacin que tena ZFC de proyectos anteriores y ya concluidos. La informacin obtenida de estos archivos fue de gran importancia para establecer de una mejor manera la realidad del desarrollo de proyectos en la empresa. La investigacin que se desarroll fue de carcter mixto. Esto por cuanto hay una seccin bastante amplia del producto final que se bas en el apoyo de fuentes documentales que permitieron respaldar de una forma terica todas las propuestas y mejoras que se plantearon al procedimiento que se tiene actualmente. Sin embargo, de la misma forma se tuvo que recopilar informacin de campo para el anlisis de proyectos realizados y para conocer las tcnicas y herramientas que los profesionales de la organizacin utilizan en este momento.

39

El mtodo, las herramientas y la forma en que se desarroll este trabajo, vari en funcin del objetivo especfico que se quiso alcanzar. Es por ello que la metodologa de investigacin pudo variar. A continuacin se detalla las metodologas que se utilizaron. 3.1.3. Mtodos de investigacin Objetivo especfico # 1

3.1.3.1.

Este objetivo lo que busc fue determinar en trminos generales cual es la metodologa que se utiliza actualmente durante la ejecucin, control, seguimiento y cierre de proyectos; o al menos determinar cules son las prcticas que se llevan a cabo. Por esta razn es que se utiliz el mtodo analtico-sinttico. Este mtodo lo que hace es descomponer una cierta unidad en sus elementos ms simples, revisarlos y analizarlos por separado y posteriormente volver a realizar un anlisis pero viendo todos los elementos en conjunto. De esta forma lo que se busc fue determinar qu procedimientos son llevados a cabo actualmente, ya sean estos establecidos por la organizacin o realizados personalmente por el equipo. A partir de cada uno de los que se identificaron fue posible generar cul es la metodologa que consciente o inconscientemente se lleva a cabo en estos momentos. En este caso particular, la investigacin fue ampliamente de campo. Porque, mediante focus group realizados con los ingenieros senior de la empresa, se recopilaron los procedimientos que se llevan a cabo y cules son las herramientas que se utilizan. La informacin recolectada se revis y se compil de forma tal que gener una radiografa de la realidad actual de los proyectos en ZFC. Es as como a partir de esto, se pudo tener mayor certeza sobre cmo se manejan los proyectos actualmente.

40

3.1.3.2.

Objetivos especficos # 2 y 3

Estos objetivos especficos se estn poniendo de forma conjunta, porque su desarrollo est ligado entre s. Por un lado mediante el objetivo especfico # 2 lo que se busc fue el anlisis de la metodologa que actualmente se est implementando y el criterio de anlisis ser con base a lo que recomienda el PMBOK (Project Management Institute, 2008). Y por otro lado el objetivo especfico # 3 lo que plantea es la determinacin de cules nuevas prcticas deben ser realizadas dentro de la organizacin para que procuren mejorar la eficiencia de los proyectos. Este tercer objetivo depende complementariamente del segundo y pudieron ser desarrollados de forma casi paralela en cada grupo de procesos especfico. En este caso, de igual forma el mtodo de investigacin que se aplic es el analtico-sinttico. Esto ya que se debi realizar un trabajo de investigacin y anlisis de forma detallada, revisando cada grupo de procesos as como los procesos que lo conforman. Hasta que cada uno de estos elementos fue revisado, es que se pudo decir que la propuesta para un determinado grupo de procesos se encontraba finalizada. Para el cumplimiento de estos dos objetivos, tuvo que efectuarse una investigacin mixta. Esta por un lado incluy la investigacin documental de registros que estaban disponibles de proyectos anteriores, as como la documentacin de campo para conocer qu realizan presentemente los ingenieros de la empresa. De igual forma se debi recurrir a la investigacin documental para conocer cules son las prcticas y herramientas que el PMI (Project Management Institute, 2008) propone en cada uno de los grupos de procesos. Con toda esta informacin recopilada, se pudo proceder a realizar un anlisis de que tan efectiva es la metodologa que se aplica en estos momentos. Se tabul la informacin para poder determinar si todos los procesos se estn aplicando y

41

que tan bien estn siendo aplicados. Si hubo alguno que no se est utilizando, se evalu el porqu de esta omisin y si es justificada de acuerdo a los tipos de proyectos que se ejecutan. A partir de los resultados que se obtuvieron, es que se empez a plantear la propuesta metodolgica. Esta busc enfatizar en aquellas reas en las que se haya encontrado alguna deficiencia y bas su propuesta en las recomendaciones establecidas por el PMBOK (Project Management Institute, 2008), as como cualquier otra que el autor consider importante provenientes de su juicio experto o cualquier otra fuente documental. 3.1.3.3. Objetivo especfico # 4

Mediante este objetivo se busc validar de forma parcial la propuesta metodolgica que se est proponiendo en este PFG. Es as como se implementaron las recomendaciones planteadas en algn proyecto, teniendo la limitante de que deba existir algn proyecto en ejecucin. Por las caractersticas del objetivo, se debi llevar a cabo un mtodo de investigacin experimental. Esto debido a que lo que se busc fue aplicar en un proyecto los procedimientos que se determinaron como mejores y se observaron que resultados se obtuvo de ellos. Durante esta etapa de validacin, se obtuvieron resultados e inmediatamente cada uno se evalu. De esta forma fue posible conocer si lo que se planteado era aplicable para la realidad de los proyectos en ZFC, o si por el contrario poda ser mejorado, deba ser cambiado o inclusive deba eliminarse. Para este objetivo especfico no se cont con fuentes documentales, al ser de aplicacin completa en un proyecto, fue una investigacin plenamente de campo.

42

4. DESARROLLO
Este PFG busca el planteamiento de una propuesta metodolgica que sirva como gua para la Ejecucin, Seguimiento, Control y Cierre de los proyectos constructivos que sean desarrollados en Zona Franca Coyol. La propuesta que se plantea est fundamentada en los conceptos y procedimientos tericos que el PMBOK (Project Management Institute, 2008)

establece. Sin embargo, ser un planteamiento que se ajuste a la realidad que se vive en ZFC. De esta forma lo que se busca es generar una propuesta que sirva como gua u orientacin a los ingenieros de la empresa, una vez que inicie un nuevo proyecto. Es importante aclarar que la formulacin de esta propuesta toma en cuenta la vasta experiencia con la que cuenta el personal de ZFC en la administracin de los proyectos constructivos, por lo que no busca convertirse en un documento que sustituya por completo las prcticas que se dan en estos momentos. Por el contrario, este instrumento debe verse como un complemento y gua para los profesionales del departamento de ingeniera de la zona franca. Asimismo, debe tenerse en cuenta que las condiciones internas y externas de la organizacin pueden variar en el tiempo, por lo que de la misma forma esta propuesta puede evolucionar para bien. El planteamiento hecho en este PFG, corresponden a la realidad actual de la empresa. Antes de poder proponer una metodologa, es importante primero hacer una descripcin de la forma en que son desarrollados los proyectos en ZFC, esto con el fin de poder circunscribir la propuesta a las condiciones que se amplan a continuacin.

43

4.1. Proyectos en Zona Franca Coyol Como se describi previamente en captulo 2.1, ZFC se dedica a la administracin de proyectos de construccin a travs de su departamento de ingeniera. Es precisamente a las labores de este departamento a las que va orientada esta propuesta. Para el desarrollo de los proyectos, ZFC nicamente cuenta con el recurso humano que se muestra en la figura 2.1, es decir la organizacin como tal no cuenta con recursos dedicados propiamente al diseo y a la construccin de los proyectos de sus clientes, estas labores se realizan mediante subcontratos a empresas consultoras y constructoras respectivamente. Bsicamente, se pueden encontrar dos tipos posibles de proyectos los cuales en muchas ocasiones pueden traslaparse, pero es importante tener sus lmites claros porque los interesados varan entre uno y otro. Por un lado se desarrollan los proyectos para la construccin de la nave industrial vaca, nicamente la estructura principal, techo, cerramientos, losa de piso y obras exteriores, esto es lo que se le llama Shell. Por otro lado, cuando ya se cuenta con un cliente concreto, se procede con la construccin de todo el espacio interno adecuado a las necesidades propias de la empresa que se va instalar, a este tipo de proyecto se le conoce como Mejoras. Inicialmente para el diseo de las naves industriales se contrata a una firma consultora que se encarga de todo el proceso de anteproyectos, planos constructivos y permisos de construccin. Posteriormente se contrata a una empresa consultora para que ejerza la inspeccin (usualmente es la misma empresa encargada del diseo) y a la empresa constructora que se encargar del proceso constructivo. El shell se le suele alquilar a un cliente el cual va tomar posesin del rea para proceder con las mejoras. Las caractersticas de la nave deben corresponder con lo que se estipula en un documento llamado: memoria descriptiva. ste se

44

convierte en la herramienta que usa ZFC para exponer al futuro cliente las caractersticas de la nave en las que se instalar. Con respecto a los proyectos de mejoras la mecnica es similar. Sin embargo para que un proyecto de mejoras se d, primero se debe tener firmado un contrato con un cliente, mediante el cual confirme que se va instalar dentro del parque e inicie sus actividades de pre-operacin durante la construccin interna del edificio. Para este segundo tipo de proyectos, hay una variacin en cuanto al proceso de diseo ya que puede darse la situacin de que el cliente enve diseos preliminares realizados por alguna empresa consultora de su propio pas, as mismo han presentado un scope manual en cual hacen una descripcin de los equipos y servicios con los que necesitan contar para poder establecer sus operaciones, as como requerimientos bsicos de la operacin. En estos casos igualmente se contrata aqu a otra empresa consultora para que tropicalice los planos y ajuste los diseos a las condiciones del pas. Es tambin usualmente esta compaa quien se encarga de la inspeccin de las obras. Cuando el proyecto est listo en cuanto al diseo, se deben contratar las diferentes empresas que se encargarn de la construccin. Comnmente se contratan a empresas especializadas en las obras civiles, elctricas, mecnicas, aire acondicionado, telecomunicaciones y BMS (building management system). Todas estas empresas van a estar bajo la coordinacin general de la compaa encargada de la obra civil. Tambin se contrata por aparte una firma que se encargue del control de calidad, pero este contrato puede salirse del paquete de coordinacin anterior. Ya con todos los contratos anteriores definidos, se conforma el equipo de proyecto. ste estar liderado por las profesionales que asigne ZFC, un ingeniero senior que se constituir en el director de proyecto y un ingeniero de proyectos. Adicionalmente el equipo lo completarn los lderes tcnicos (arquitectnico, elctrico, mecnico, estructural, BMS, etc.) que aporte la empresa encargada de la inspeccin, el profesional encargado del control de calidad y el profesional

45

asignado por la empresa constructora, quien representa tambin a las otras empresas constructoras especializadas. Como puede verse ZFC tiene una labor bastante definida, sin embargo el recurso propio que utiliza es bastante poco y la mayora de las actividades son realizadas mediante subcontratos directos. En general en los proyectos, sus principales tareas son las de coordinacin entre todos los subcontratos y como puente de comunicacin con el cliente. A estos debe sumrsele todos los respectivos controles para asegurarle al cliente, que el producto va terminar con el alcance, la calidad y el costo deseado.

4.2. Metodologa de proyectos actual Para poder identificar cual es la metodologa que se emplea actualmente en ZFC, se realiz un focus group con los ingenieros senior del departamento de ingeniera para conocer de qu forma se afrontan los proyectos cuando estos inician. En los anexos 8.3, 8.5 y 8.6 se pueden ver los 3 cuestionarios que se plantearon que sirvieron como gua para la sesin de trabajo realizada. De acuerdo a la reunin que se tuvo con los ingenieros (en el anexo 8.7 se puede ver un resumen del focus group), se puede extraer que ZFC s realiza procesos propios de la administracin de sus proyectos y aplica buenas prcticas en cada uno de ellos. Sin embargo, estas tareas no se hacen siguiendo un protocolo establecido por la organizacin, por el contrario se trabaja basados en la experiencia de cada ingeniero a cargo y en la experiencia que la empresa ha adquirido tras la gestin de proyectos en el pasado. En el cuadro 4.1, puede verse cuales son las principales tcnicas y herramientas que propone el PMBOK (Project Management Institute, 2008) para que sean utilizadas durante los grupos de procesos que estn siendo analizados.

46

En el cuadro se seala cuales son aplicadas dentro de las organizacin y cules no.
Cuadro 4.1. Principales tcnicas y herramientas de los grupos de proceso en estudio.
Tcnica o Herramienta Descripcin EJECUCIN Herramienta basada en la experiencia y el juicio que puedan aportar el tanto el director de proyectos como el equipo para la toma de decisiones o la resolucin de conflictos. Herramienta automtica (software) que permita realizar tareas propias de la AP tal como la recopilacin y distribucin de informacin. Es una revisin independiente para determinar si las actividades del proyecto cumplen con las polticas, procesos y procedimientos del proyecto. Son actividades diseadas para mejorar la competencia de los miembros del equipo. Es la programacin de actividades que busquen ayudar a los miembros a trabajar en conjunto de manera eficaz. Puede ser algo de 5 minutos o toda una jornada. Es la documentacin de quin es responsable de la resolucin de asuntos especficos antes de una fecha lmite. Consiste en cualquier mtodo ya sea escrito o verbal as como presencial o de conexin remota que permita distribuir informacin. Son las herramientas destinadas a distribuir la informacin. Por ejemplo: correo electrnico, documentos impresos, fax, videoconferencias, interfaces web, etc. Es la definicin de un proceso formal de revisin de la oferta de acuerdo con las polticas de adquisicin del comprador Son estimaciones hechas a lo interno de la organizacin o contratadas a fin de que sirvan como norma de comparacin de las ofertas que se presenten. SEGUIMIENTO Y CONTROL Esto comprende actividades como medir, examinar y verificar para determinar si el trabajo y los entregables cumplen con los requisitos y criterios de aceptacin del producto. de de Permiten medir, comparar y analizar del desempeo del cronograma en aspectos como fechas reales de inicio y Utilizada en la organizacin?

Juicio Experto

Sistema de informacin para la AP.

No

Auditoras de calidad

No

Capacitacin

Actividades de desarrollo del espritu del equipo

No

Registro de asuntos

Mtodos de comunicacin Herramientas de distribucin de informacin Tcnicas de evaluacin de ofertas Estimaciones independientes

No

Inspeccin

Revisiones desempeo

47

cronograma

finalizacin, as como porcentajes de trabajo completado y duracin restante. Consiste en un anlisis de la pregunta: Qu pasa si se produce la situacin representada por el escenario X? La respuesta a esta pregunta permite realizar el anlisis de las distintas variables del proyecto bajo distintos supuestos y tomar mejores decisiones. Es un mtodo que se utiliza para la medicin del desempeo del proyecto e integra mediciones del alcance del proyecto, el costo y el cronograma. Implica una evaluacin del estatus de los principales parmetros del proyecto como lo son el costo, el tiempo y el alcance contra lo que fue originalmente planeado. Son diagramas que muestran la forma en que distintos factores pueden estar vinculados con un problema o efecto potencial stos son utilizados para determinar si un proceso es estable o no, o si tiene un desempeo predecible. Se establecen lmites superiores e inferiores que son los mximos y mnimos permisibles. Consiste en la seleccin de una parte de la poblacin de inters para su inspeccin. Es necesario determinar la frecuencia y el tamao de la muestra. Esta herramienta es usada en tareas de control de calidad. Esta tcnica consiste en la prediccin del desempeo futuro del proyecto basndose en el desempeo real a la fecha. sta es una herramienta estndar para que el director del proyecto registre, almacene y distribuya a los interesados informacin relativa a los costos, al avance del cronograma y el desempeo del proyecto. Consiste en el monitoreo y control de los riesgos generando de esta forma la identificacin de nuevos riesgos, la reevaluacin de riesgos actuales y la eliminacin de otros. Estas auditoras examinan y documentan la efectividad de la respuesta a los riesgos identificados y sus causas, as como la efectividad del proceso de gestin de riesgos. Son reuniones peridicas que son establecidas a lo largo del proyecto para evaluar el estado del proyecto y las tareas que estn por venir. Esto consiste en la definicin del proceso por el cual una adquisicin puede ser modificada. Es una revisin estructurada del avance del vendedor para cumplir con el alcance y la calidad del proyecto, dentro del costo y el plazo acordado.

Anlisis si?

Qu

pasa

No

Valor ganado

No

Anlisis de variacin

Diagramas causa-efecto

No

Diagramas de control

No

Muestreo estadstico

No

Mtodos de proyeccin

No

Sistemas de informes

Reevaluacin de riesgos

No

Auditoras de riesgos

No

Reuniones de proyecto

Sistema de control de cambios en contrato Revisin de desempeo de adquisiciones

No

No

48

CIERRE Auditoras adquisicin de la Consiste en una revisin estructurada del proceso de adquisicin, desde el proceso de planificar la adquisicin hasta el proceso de administrarla. Es un sistema compuesto por un conjunto especfico de procesos para gestionar la documentacin y los registros de los contratos y de las adquisiciones.

No

Sistema de gestin de registros

No

Segn indicaron los ingenieros, una vez que les es notificado que deben asumir un nuevo proyecto los primeros documentos que revisan son: la memoria descriptiva, el scope manual, el cronograma aprobado y el presupuesto aprobado. Estos son los documentos que utilizan para definir los principales parmetros del proyecto que deben cuidar. Usualmente cuando van a iniciar un proyecto de mejoras, ya estn bastante familiarizados con muchas de estas restricciones de alcance, plazo y costo, porque han formado parte de un proceso de pre-construccin. En esta etapa se tienen sesiones de trabajo con el cliente, diseadores y empresas que presupuestan el trabajo, por lo que al iniciar el proyecto, ya esta informacin se conoce de antemano. Con respecto a los riesgos, no hay ninguna tarea especfica para determinarlos ni darles seguimiento a los mismos. Los riesgos que tiene el proyecto son vistos e inclusive atacados pero de manera informal, sin ningn criterio tcnico establecido. Este tema se da ms por un aspecto de experiencia de parte de los ingenieros. Cuando el proyecto arranca, usualmente se tiene claro cules van a ser los subcontratos que se van a tener que administrar a los largo del proyecto. Dependiendo de si se trata de un proyecto de shell o de mejoras, la cantidad y la complejidad de los subcontratos vara, siendo el ltimo un tipo de proyecto mucho ms complejo.

49

A pesar de que se llegan a generar una cantidad de subcontratos nada despreciable, no se cuenta con una lista aprobada oficial de proveedores a utilizar en cada caso. Debido a la cantidad de proyectos que la organizacin ya ha realizado, s se cuenta con un conocimiento amplo de los oferentes que se utilizan y en la mayora de los casos se invita a las mismas empresas a las licitaciones, sin embargo no existe un ranking formal de las empresas y un criterio definido para invitarlas. La preseleccin de empresas para licitacin se ha dado en casos especficos en los que el cliente directamente hace la solicitud. Sin embargo se vuelve al punto anterior en que es ZFC quien elige las empresas preseleccionadas de acuerdo a su experiencia y tras una serie de presentaciones y ofertas el cliente elige finalmente la adjudicataria. Cuando se conforma el equipo de proyecto, los directores de proyectos no tienen una influencia directa en la seleccin de los lderes tcnicos. Cada uno de ellos es establecido por las empresas contratadas para la inspeccin, la construccin y el control de calidad. Esta situacin genera, segn comentan los ingenieros consultados, que no se pueda dar una gestin del equipo, a nivel del recurso humano. Esto debido a que todos los miembros corresponden a empresas distintas, que si bien es cierto forman parte de un mismo proyecto, cada uno tiene un superior distinto lo que puede complicar el manejo del recurso. A pesar de lo anterior, ellos como directores de proyectos, desde la primera reunin tratan de integrar a todas las personas al equipo y de que se conozcan bien los roles de cada uno. Asimismo, intervienen en caso de que se produzcan conflictos entre distintas personas para salvaguardar el desarrollo del proyecto. Los interesados del proyecto siempre estn bien definidos as como los canales de comunicacin. En la mayora de los casos se tiene claro cules son sus expectativas, especialmente por los mismos documentos que ellos presentan

50

durante la fase de pre-construccin. De la misma forma siempre buscan identificar cules son los interesados clave. Para llevar un control del proyecto, ya la organizacin cuenta con herramientas especficas para revisar que el presupuesto y el plazo sean cumplidos de acuerdo a lo esperado. Tablas de control de presupuestos y controles de pagos ayudan a generar proyecciones del presupuesto y a llevar un control de los pagos que se le hacen a cada contratista. Estas tablas son actualizadas cada vez que un cambio es solicitado y tambin cuando son aprobados. De la misma manera cuando los pagos son realizados los controles son actualizados. Este tipo de herramientas son indicadores del estado del proyecto y sirven tambin para prevenir que el proyecto sobrepase los montos aprobados. Las lecciones aprendidas no son registradas a lo largo del proyecto. Recientemente se ha puesto en prctica este registro pero se ha hecho hasta el final del proyecto y no se ha hecho a lo largo del mismo. Cuando se han tenido que realizar compras directas de equipos para el proyecto, tampoco se tiene un listado de proveedores aprobados, pero para estos casos se basan en las recomendaciones que el mismo cliente plantea. Precisamente es con l, con quien se definen cuales con las variables ms importantes que se tienen que tomar en cuenta a la hora de analizar las ofertas de los equipos ms complicados y de mayor inters para el cliente. Sin embargo esto se hace en compras especficas y no en todos los casos. Como puede verse, ZFC aplica principios importantes de la administracin de proyectos, pero no se hace siguiendo un procedimiento especfico, por lo que en muchas ocasiones puede variar la forma en que se administra entre proyecto y proyecto.

51

La propuesta que se plantear a continuacin, buscar resaltar todos esos principios que actualmente son aplicados y normalizar su uso mediante una metodologa clara. Con esta herramienta se buscar que todas las buenas prcticas que ya son utilizadas ms otras que van a ser propuestas, se puedan aplicar de forma consciente y ordenada en todos los proyectos venideros.

4.3. Grupos de Procesos de Ejecucin Este grupo de procesos est compuesto por aquellos procesos realizados para completar el trabajo que ya fue previamente definido, con el fin de poder cumplir con las especificaciones y requerimientos definidos. (Project Management Institute, 2008)

4.3.1.

Entradas Iniciales

Para poder empezar con la ejecucin de cualquier proyecto, el PMI establece una serie de entradas o inputs necesarios para poder desarrollar la metodologa que se describe en el PMBOK. Estas entradas corresponden a algunas de las salidas que se producen en los procesos de planificacin. La generacin de todas estas entradas necesarias est fuera del alcance de este PFG, tal y como se seala en el chrter de este proyecto en el anexo 8.1. Es por esto que se parte del hecho de que todas las entradas necesarias ya han sido creadas dentro de la organizacin y estn a disposicin de las personas que estn involucradas en cada proyecto en especfico. Sin embargo, debido a la realidad en la que se desarrollan los proyectos en ZFC, no todas las entradas que indica el PMBOK son creadas y algunas existen de manera informal. A continuacin se har una descripcin de aquellos inputs

52

que s son necesarios desarrollar para la correcta aplicacin de la metodologa que se plantear. 4.3.1.1. Factores ambientales de la empresa

Estos factores son todos aquellos aspectos tanto internos como externos del proyecto que de una u otra manera pueden influenciar el desempeo de un proyecto. En muchos casos todos estos factores son conocidos o establecidos informalmente dentro de una organizacin y puede afectar negativa o positivamente el proyecto. En este caso ZFC no lleva un registro de estos factores. Esta es una de las entradas ms importantes que establece el PMBOK, debido a que sin importar el proyecto o la organizacin, estos factores van a estar presentes. Es necesario que cuando se empiece a desarrollar el proyecto, estos factores sean conocidos por todos los miembros que estn ligados al proyecto. Entre los factores que se pueden citar, estn los siguientes (Project Management Institute, 2008): Cultura organizacional, estructura y procesos. Estndares estatales o de industria. Infraestructura. Recursos humanos existentes. Sistema de autorizacin de trabajos de la empresa. Tolerancia al riesgo de los interesados. Canales de comunicacin establecidos en la organizacin. Es importante que el departamento de ingeniera de la zona franca, tenga claro cules pueden ser algunos de los factores ambientales de esta empresa que pueden incidir en los proyectos. Dentro de ellos se pueden citar los siguientes: 1. Misin y visin de la organizacin (ver captulos 2.1.1 y 2.1.2). 2. Valores de la organizacin (ver captulo 2.1.3). 3. Estructura organizacional del departamento de ingeniera.

53

4. Ubicacin fsica de los departamentos de la empresa (no todos los departamentos se encuentran en Coyol de Alajuela). 5. Tiempos de traslado al proyecto. 6. Injerencia de la junta directiva en la toma de decisiones. 7. Disponibilidad de las jefaturas para la toma de decisiones. 8. Inters del parque hacia el desarrollo sostenible. 9. Softaware de contabilidad de proyectos. 10. Rgimen de zona franca. 4.3.1.2. Activos de los procesos de la organizacin

Esta entrada es tambin un aspecto muy importante a tomar en cuanta cuando se inicie un proyecto. Esto debido a que hace referencia a todos los activos, tangibles o intangibles, con que cuentan las empresas relacionadas con el proyecto y que pueden ser determinantes en el xito del proyecto. Estos activos estn compuestos por todos los planes, polticas,

procedimientos y lineamientos que han sido establecidos dentro de la organizacin. Asimismo contempla toda la informacin que ha podido ser compilada de proyectos anteriores, como lecciones aprendidas, informacin de riesgos y de valor ganado entre otros. Si bien es cierto que algunos de estos activos ya estn establecidos dentro de una empresa como Zona Franca Coyol, no existe una compilacin de ellos que pueda estar a disposicin de los equipos de proyecto de forma accesible, por lo que no es una entrada que est disponible. Los activos de la organizacin pueden categorizarse en dos grupos: (Project Management Institute, 2008) 1. Procesos y procedimientos: que incluyen todos aquellos aspectos que ya han sido establecidos para realizar el trabajo. Entre ellos estn: estndares y polticas organizacionales, lineamientos, plantillas y criterios para adaptar los procesos estndar de la organizacin a la realidad especfica de cada

54

proyecto, procedimientos de control financiero, procedimientos de control de cambios, entre otros.

2. Base corporativa de conocimiento: esto incluye todos los procesos para almacenar y recuperar informacin. Entre lo que se puede citar se encuentran: base de datos para la medicin de procesos, documentos de proyecto, informacin histrica, base de datos de la gestin de problemas y defectos, base de datos financieras, etc. Algunos de los activos de la organizacin que pueden encontrarse dentro de ZFC, se citan a continuacin. 1. Manual de compras exoneradas. 2. Manual de seguridad ocupacional en construcciones. 3. Procedimiento de pago de facturas. 4. Base de datos con informacin de contacto de proveedores. 5. Procedimiento para el trmite de rdenes de cambio. 6. Servidor de la empresa.

4.3.1.3.

Acta de constitucin del proyecto (Project Chrter)

Este es el documento en el cual se dejan establecidos y por escrito todas las necesidades del proyecto y las expectativas que existan de parte de los interesados. Este documento una vez firmado, autoriza formalmente el inicio del proyecto. Esta acta es una herramienta muy til durante la administracin de los proyectos porque demarca los lmites del proyecto y las caractersticas del producto final esperado. De ah la importancia de que desde el inicio del proyecto, este documento sea del conocimiento de todos. A pesar de que la confeccin del chrter del proyecto no ha sido una prctica comn a lo largo de los proyectos que han sido realizados, ltimamente si

55

se ha procurado generar este documento para arrancar oficialmente el proyecto. El anexo 8.11 se presenta una gua para la elaboracin de este documento con base en los que ya se han confeccionado previamente dentro de la institucin. 4.3.1.4. Solicitudes de cambio aprobadas

Estas consisten en todos aquellos cambios que han sido solicitados y debidamente aprobados por la persona designada que reducen o amplan el alcance, costo y el cronograma base del proyecto. Estos cambios aprobados tambin pueden modificar planes, procedimientos polticas. Igualmente pueden ser responsables de la creacin o eliminacin de riesgos. Es importante aclarar que estos cambios se pueden dar a lo largo de todo el proyecto. Estas solicitudes son una entrada que s es realizada durante la administracin de los proyectos. 4.3.1.5. Mtricas de calidad

Las mtricas de calidad consisten en la definicin de los atributos del proyecto que van a ser medidos y la forma en que se medirn mediante el proceso de control de calidad. Consisten de un valor real el cual va a ser evaluado y comparado. Estas mtricas deben definir tambin la tolerancia que se manejar a la hora de evaluar el resultado, esa tolerancia deber ser establecida para cada actividad o entregable en especfico que se le aplique control de calidad. Los proyectos de construccin suelen tener ests mtricas bien definidas ya que la calidad se evala contra parmetros contables, por ejemplo en muchos casos se solicita que el concreto tenga una resistencia de 210 kg/cm2 y contra eso se compara. Sin embargo todos esos parmetros no estn descritos en un documento como tal, por lo que sta entrada si bien se genera, no existe dentro de la organizacin. 4.3.1.6. Mediciones de control de calidad

Esta entrada hace referencia a los resultados que se obtienen de la aplicacin del control de calidad. Estos resultados son empleados para evaluar los procesos de calidad de las actividades ejecutadas.

56

Dentro de la dinmica de proyectos de ZFC, estos documentos son presentados al equipo de proyecto mediante la o las empresas contratadas para realizar el control de calidad por lo que es informacin que est disponible. 4.3.1.7. Asignaciones del personal al proyecto

Esto se da cuando ya ha sido conformado el equipo del proyecto. La documentacin que se genere producto de esta asignacin vara dependiendo de la organizacin. Puede ser desde un contrato formal hasta una simple notificacin. Para el caso de los proyectos de ZFC, puede consistir en la generacin de un directorio con la informacin de contacto de los involucrados, est practica s se da dentro de la organizacin pero no es una constante. 4.3.1.8. Informes de desempeo

Los informes de desempeo consisten en documentacin con informacin sobre el estado y el avance del proyecto. Estos reportes deben estar disponibles antes de las reuniones del proyecto. La informacin descrita tiene que exponer las variaciones que haya sufrido el proyecto, los impactos generados, las variaciones en tiempo, costo y alcance, as como la informacin relativa a proyecciones. Estos informes permiten un mejor seguimiento del proyecto y una forma ms fcil de comunicacin con los interesados. Estos documentos s son generadores durante la ejecucin y cierre de los proyectos de la zona franca y la frecuencia es definida con el cliente si se trata de un proyecto de Mejoras, o tienen una periodicidad de un mes si es para un proyecto de Shell. 4.3.1.9. Registro de interesados

Tal como su nombre lo dice, este registro lo que hace es generar un documento en el cual queden claramente establecidos cuales son los interesados del proyecto. El listado debe distinguir entre interesados primarios y secundarios y

57

de acuerdo a lo que indica el PMBOK (Project Management Institute, 2008) debe contar con: 1. Informacin de identificacin: nombre, puesto en la organizacin, ubicacin, rol en el proyecto, informacin de contacto. 2. La informacin de evaluacin: principales requisitos, principales

expectativas, influencia potencial en el proyecto, fase en el ciclo de vida donde el inters es mayor. En el anexo 8.8 se adjunta una plantilla propuesta para que sea utilizada por los miembros del departamento de ingeniera de ZFC, para generar el registro de los interesados ya que actualmente este documento no es realizado. 4.3.1.10. Estrategia de gestin de los interesados Esta estrategia lo que define es la forma en que se van a manejar la relacin con los interesados de tal manera que se pueda aumentar el apoyo de parte de ellos y disminuir cualquier impacto negativo que pueda generarse. La estrategia debe incluir: 1. Cules son los interesados clave. 2. El nivel de participacin deseado de cada interesado en el proyecto. 3. Los grupos de interesados y su gestin. Estos tres rubros son los que sugiere el PMBOK (Project Management Institute, 2008), sin embargo como en todos los casos se debe revisar para cada empresa y para cada proyecto. Lo importante de esta entrada es tener claro las caractersticas de cada interesado y cul es su rol y expectativas del proyecto. En la actualidad s se tiene un conocimiento sobre las principales caractersticas de los interesados del proyecto, pero no se documenta. Esta es una entrada que debe generarse de una manera ms formal dentro de la empresa.

58

4.3.1.11. Registro de incidentes Esta entrada consiste en la documentacin y monitoreo de la resolucin de incidentes. Mediante la generacin de este registro, se puede hacer ms fcil el seguimiento a las acciones que se toman para la resolucin de los problemas, adems de que se facilita la comunicacin y compresin de los incidentes de parte de los interesados. En el anexo 8.9 se provee una plantilla propuesta para realizar el registro de incidentes en los proyectos de ZFC de forma tal que pueda empezarse a generar este documento. 4.3.1.12. Registro de cambios Al igual que el registro de intereses, este documento lo que busca es llevar un registro de todos los cambios que se dan en el proyecto, con su respectivo impacto en el costo, cronograma y alcance. De esta forma tambin se facilita la comunicacin a los interesados. Este registro no es llevado a cabo dentro de la organizacin en todos los proyectos, su realizacin es de manera informal. En el anexo 8.10 puede verse la plantilla propuesta para esta documentacin. 4.3.1.13. Documentos de la adquisicin Esta entrada hace referencia al conjunto de documentos necesarios que deben generarse para poder solicitar propuestas a los distintos proveedores. Mediante estos documentos se especificarn las caractersticas del producto solicitado, las condiciones de compra, consideraciones tcnicas, entre otras. Estos documentos son muy propios de cada empresa y del producto que se desee adquirir. Esto debido a que se deben estructurar de forma tal que el posible proveedor pueda generar una respuesta precisa a las necesidades que tiene el proyecto. Las especificaciones tcnicas, el cartel de licitacin, los criterios de diseo y la tabla de pagos son algunos de los documentos que genera ZFC y que pueden formar parte del proceso de adquisicin.

59

4.3.1.14. Criterios de seleccin de proveedores Consiste en la definicin de los parmetros que se van a establecer para poder medir y evaluar las propuestas que sean presentadas por los posibles proveedores. Se puede generar un documento que contenga un listado de criterios generales y aplicables a cualquier proceso de adquisicin, sin embargo ser en cada una de las licitaciones que se hagan que el director de proyectos deber definir cules son los criterios que realmente aplican a cada caso es especfico. Entre los criterios que pueden mediar a la hora de tomar una decisin, estn los siguientes: costo, tiempo de entrega, garanta, capacidad tcnica del proveedor, riesgo asociado, forma de pago, capacidad financiera del proveedor, entre otros. En muchos casos los parmetros descritos en el prrafo anterior s son considerados por el director de proyecto de ZFC, sin embargo no existe una metodologa establecida para poder realizar una ponderacin de ellos. Si bien es cierto los criterios de seleccin si son utilizados, no estn formalmente establecidos y pueden variar dependiendo del producto o servicio licitado y del profesional responsable encargado. 4.3.1.15. Lista de vendedores calificados Esta es una lista generada con base a experiencias pasadas y a referencias de otros compradores. Mediante esta lista lo que se busca es realizar una discriminacin objetiva de proveedores, de forma tal que los documentos de la adquisicin se enven nicamente a oferentes que estn en condiciones de poder ejecutar el contrato resultante. Dentro de ZFC esta lista no existe. A pesar de ello s existe un buen criterio de seleccin de empresas para invitarlas a una licitacin dependiendo de la magnitud y caractersticas del proyecto o del producto.

60

4.3.1.16. Propuestas de vendedores Las propuestas de los vendedores consisten propiamente en las ofertas que presentan cada uno de los proveedores como respuesta a la solicitud planteada. Estos son los documentos que sern evaluados para con el fin de seleccionar uno o ms oferentes.

Las entradas descritas anteriormente, son aquellas que deben ser generadas como mnimo dentro de la planificacin del proyecto con el fin de hacer una correcta aplicacin de la metodologa que se proponga en este documento. Adicional a las mencionadas previamente, existen otra serie de entradas que indica el PMBOK como necesarias al momento de iniciar con la ejecucin de un proyecto. Por las caractersticas de la organizacin y por el nfasis que se le est dando a la propuesta metodolgica, estas entradas se consideran de valor agregado. A continuacin se describirn brevemente para que en caso de que la organizacin los requiera, puedan ser desarrollados. Plan de Gestin del Proyecto: este es el documento que llega a integrar todos los documentos de gestin que han sido creados para gestionar adecuadamente las principales variables del proyecto. Este es el plan que compila todos los procesos que van a ser aplicados a lo largo del proyecto y se convierte en una herramienta de gua para el director y su equipo, para poder gestionar el proyecto de manera adecuada y siguiendo procesos claros que fueron definidos previamente durante la planificacin del proyecto. No existe un formato definido para este documento, puede variar entre las organizaciones, puede presentarse de forma resumida o detallada y se puede componer de distintos planes, en funcin de las caractersticas propias de cada proyecto y de las consideraciones del director.

61

Algunos de los planes subsidiarios que pueden conformar el plan de gestin son los siguientes: (Project Management Institute, 2008) Plan de gestin del alcance. Plan de gestin del cronograma. Plan de gestin de costos. Plan de gestin de calidad. Plan de gestin de recursos humanos. Plan de gestin de riesgos. Plan de gestin de las comunicaciones

Plan de Gestin de la Calidad: este plan consiste en la descripcin de la forma en la que el equipo de proyecto va a implementar la poltica de calidad tanto para asegurar la calidad como para controlarla. El formato de este plan y su contenido va a variar en funcin de cada proyecto. Sin embargo se debe tener presente que el fin ltimo de este plan es definir de qu manera se va a ejecutar el control de calidad en las actividades del proyecto y posteriormente con qu herramientas se van a dar el aseguramiento de la calidad. Es importante tambin que se deje claro los mtodos de mejora continua del proyecto. Estos mtodos deben basarse en los resultados que se obtengan del control de calidad, por lo que este plan debe definir la forma en que tienen que ser analizados los resultados y cmo se deben proponer y aplicar las mejoras. Plan de Recursos Humanos: la gestin de los recursos humanos queda definida en este documento, en el cual se deben documentar los roles y responsabilidades dentro del proyecto, organigramas del proyecto y un plan para la direccin de personal. Deben quedar definidos los recursos humanos, as como la forma en que van a ser adquiridos, dirigidos, supervisados y liberados. (Project Management Institute, 2008)

62

De la misma forma, se debe incluir todas aquellas acciones necesarias para evaluar al personal, identificar cules son sus necesidades profesionales, programacin de capacitacin y distintas estrategias que se pueden adoptar para fomentar la unin de grupo. Por las caractersticas de la organizacin y de la estructura de los proyectos en ZFC, este plan debe enfocarse al equipo de proyecto asignado por ZFC y no involucrar a todo el equipo interdisciplinario. Por estas mismas razones, el plan puede ser un documento bastante genrico orientado a los recursos humanos propios del departamento de ingeniera y no va variar mucho entre los proyectos. Plan de Gestin de la Comunicaciones: este es el plan en cual se detallan cuales son las necesidades de informacin de los interesados del proyecto y se define de qu forma se van a abordar las comunicaciones con ellos. Se establece quin necesita la informacin, cuando la necesita, cmo le va ser proporcionada y por quin. (Project Management Institute, 2008). La planificacin de las comunicaciones va permitir evitar que se den demoras en el flujo de la informacin, y este detalle es esencialmente importante cuando se trata de informacin sensible que puede afectar significativamente los intereses de los stakeholders y/o las condiciones del proyecto. En este documento se debe proporcionar entre otras cosas: los requisitos de la comunicacin, el formato de la documentacin, el idioma oficial, la frecuencia de las comunicaciones, los responsables de la distribucin, los canales de comunicacin, los destinatarios finales y los diagramas de flujo de informacin. Este plan debe adecuarse a la situacin propia del proyecto y posterior a un adecuado conocimiento de los interesados. Asimismo debe buscar que se d un flujo gil de la informacin antes de burocratizar el proceso, sin embargo es importante que quede definida la forma en que se realizar este procedimiento.

63

Plan de Gestin de las Adquisiciones: el plan para las adquisiciones es el documento que se establecer en el proyecto en el cual queda definido el procedimiento para identificar vendedores, especificar la forma de hacer la compra, documentar las decisiones de compra y darle seguimiento a los proveedores seleccionados. La informacin del plan tiene que contemplar la forma en que se va a gestionar el proceso de compra desde el propio momento en que se genera la necesidad. Ya que debe incluir la forma en que se definirn los documentos de adquisicin que deben elaborarse en funcin de la compra seleccionada. Asimismo se definen las variables ms importantes que se deben tener presente a la hora de realizar una adquisicin como tipos de contratos, cronogramas de entregas, formas de pago, documentos a solicitar a proveedores, garantas, identificacin de vendedores, entre otros. Es de gran importancia que este documento incluya tambin el seguimiento y la evaluacin final a los proveedores. Los resultados que se obtienen de estas acciones, son de relevancia ya que brindan retroalimentacin valiosa que sirven de entrada para proyectos futuros. Todos los planes descritos anteriormente, son planes subsidiarios del Plan de Gestin del Proyecto. ste est compuesto ya sea por todos los planes anteriores o solo por algunos. Eso depender de cada proyecto. Es muy importante aclarar que cada uno de estos documentos, no tiene una plantilla definida ni establecida por el PMI para su confeccin. Cada documento puede variar entre cada organizacin y la informacin tambin se modificar dependiendo cada proyecto. Debe quedar a criterio del director de proyectos asignado por ZFC, si solicita la confeccin de cada uno de los planes anteriores y qu informacin deben contener.

64

4.3.2.

Propuesta Metodolgica

A continuacin se describir la propuesta metodolgica que se est planteando para ser aplicada en ZFC. Se describirn y enumerarn las actividades que se recomiendan deben darse para mejorar la administracin del proyecto durante la ejecucin del mismo. 4.3.2.1. Evaluacin inicial del equipo de proyecto (EJ-01)

Es de suma importancia que el director de proyecto, en este caso un ingeniero senior de la empresa, se sienta cmodo con el equipo que se ha conformado para sumir el proyecto. Debido a la forma en que se trabaja en ZFC, el equipo se genera producto de la subcontratacin de una firma consultora para que ejerza la inspeccin y de una o varias firmas constructoras encargadas de construir el proyecto. Cada una de las partes pone los lderes tcnicos correspondientes a su especialidad. Debido a la situacin descrita en el prrafo anterior, es que no se da la situacin tan clara de que el director de proyectos tenga la potestad de elegir uno a uno cada profesional que formar parte del equipo. Esta responsabilidad recae directamente sobre la empresa que fue subcontratada. El profesional asignado por ZFC como director, debe solicitar a cada una de las empresas involucradas antes de que empiece el proyecto, una notificacin oficial de cules sern los profesionales que sern asignados al proyecto. En caso de que no haya referencia previa de ellos, se deber solicitar un currculum de los mismos. Es necesario que el director de proyectos evale de forma inicial cada uno de los miembros que fueron designados para el proyecto y determine si son los ideales para desarrollar las funciones que les fueron asignadas. Puede fundamentar su razonamiento en experiencias previas o su juicio experto, pero debe dejar claro desde antes de que el proyecto arranque formalmente si est de acuerdo o no con la designacin que cada empresa subcontratada hizo.

65

4.3.2.2.

Motivacin inicial (EJ-02)

La motivacin es un aspecto fundamental que debe ser explotado y aplicado en cualquier proyecto. En el caso de ZFC, la motivacin debe ser aplicada de dos formas distintas. Inicialmente el Jefe de Ingeniera debe generar una reunin de arranque de proyecto con los profesionales que fueron asignados de parte de la organizacin (ingeniero senior e ingeniero de proyectos, ver figura 2.1). Es importante que el encargado del departamento de ingeniera sepa motivar a su equipo de cara al proyecto que inicia. Se debe resaltar las virtudes que como equipo se poseen, las expectativas que se tienen del rendimiento de ellos y la confianza que se le tiene y que propici su designacin para el proyecto. Tal como lo seala el PMBOK (Project Management Institute, 2008), se debe tratar de hacer sentir a los colaboradores valorados por la organizacin, de esa forma se puede motivar a las personas y mejorar su desempeo. Por otro lado, la otra tarea de motivacin inicial le toca al director de proyectos asignado. l debe encargarse de ejercer la labor de motivacin inicial dentro del equipo de proyecto. Esta motivacin debe darse desde la reunin de arranque y antes de cualquier tema formal de la reunin. Es importante igualmente que a lo largo del proyecto, se den los reconocimientos necesarios cuando las cosas se hacen adecuadamente y generan buenos resultados. Se debe buscar propiciar estos reconocimientos no solo al final del proyecto, sino a lo largo de toda su ejecucin. 4.3.2.3. Presentacin del Acta Constitutiva del Proyecto al equipo (EJ-03)

Como se puede ver en la seccin 4.3.1.3, el chrter debe ser una de las entradas con las que debe contar la empresa cuando se vaya a iniciar un proyecto. En el anexo 8.11, se puede consultar una gua para la elaboracin de

66

esta acta. Esta gua est basada en el Project Charter que ya se han hecho en proyectos previos dentro de la organizacin. Este documento debe ser presentado a todos los integrantes del equipo y al cliente o a su representante desde la reunin de arranque, el cual debe ser revisado por ellos y finalmente aprobado, dejando una constancia por escrito de que se acepta y se entiende todo lo que se indica. Mediante esto, se busca que todos los miembros del equipo tengan un criterio unificado sobre cul es el alcance del proyecto, los principales hitos y el plazo de ejecucin del mismo. Asimismo deben quedar claras todas las distintas fases que pudiera haber y los entregables principales. De esta forma se logra que los profesionales que estn involucrados tengan plena conciencia sobre las expectativas que hay sobre el proyecto y sobre la labor de ellos mismos, aumentando el grado de compromiso para con el producto final. Asimismo tanto el director de proyectos, como los inspectores y el cliente deben tener la ltima versin del scope manual, en el cual se describen los requerimientos que fueron establecidos por el cliente actualizado con la informacin adicionada por los consultores del proyecto. 4.3.2.4. Definir canales de comunicacin (EJ-04)

Desde el inicio del proyecto, el director debe dejar claro cules son los roles de cada uno de los miembros del equipo y cules sern los canales de comunicacin que se tienen que seguir y respetar a la hora que tenga que fluir la informacin. El director de proyecto debe analizar cules son los medios ms efectivos que hay a disposicin para poder comunicar toda la informacin del proyecto. Es importante que se evale la fluidez que tiene la herramienta para transportar la informacin.

67

Debe asegurarse que todos los miembros del equipo, as como los principales interesados tengan acceso al mecanismo de comunicacin que se vaya a escoger. Existe la posibilidad de que se determinen una o ms herramientas de comunicacin, si as lo considera viable el director de proyectos. Con base a las herramientas seleccionadas, se debe crear un flujo de informacin que muestre de qu forma debe viajar la informacin y a quin debe llegarle dependiendo del documento que se est presentando. Es importante que estos flujos de informacin queden claros para todos, sobre todo para cuando sea necesaria la presentacin de solicitudes de cambio, submittals de materiales y equipos, solicitudes de informacin o reportes de avance de proyecto. De igual manera, debe ser de entendimiento de todos de qu forma puede escalar la informacin. En algunas ocasiones, es necesario que los problemas que se presentan escalen para que sean vistos y estudiados en distintos niveles de la organizacin. Este escalamiento debe estar claro y con personas debidamente asignadas. Por ltimo, se debe llegar a un consenso entre todo el equipo acerca de cules documentos puede manejarse de forma virtual y cules deben tener una copia fsica de respaldo. Idealmente debe buscarse que todos los documentos sean de forma virtual, sin embargo si por polticas del cliente no puede ser as, se debe buscar que nicamente los documentos de mayor importancia tengan su respaldo fsico. 4.3.2.5. Manejo de reuniones de proyecto (EJ-05)

Las reuniones son una de las principales herramientas que se utilizan en la administracin de proyectos durante la ejecucin del mismo. En este tipo de sesiones se busca realizar toma de decisiones entre los miembros del equipo, que ayuden al desarrollo del proyecto mantenindose dentro de las restricciones estipuladas.

68

Debido a lo anterior, es importante que las reuniones puedan ser manejadas de forma adecuada y efectiva, de forma tal que se tomen las decisiones que sean de provecho para el proyecto y se respete el tiempo que fue dedicado por todos los profesionales hacia la reunin. Al menos un da antes de la reunin, el director de proyecto debe circular una agenda (ver anexo 8.12) con los temas que van a ser discutidos en la reunin. Estos temas deben estar acorde con los puntos que quedaron pendientes de resolucin en la reunin anterior y que estn reflejados en la minuta de la reunin. Asimismo, se debe incluir cualquier tema que sea considera por el director como importante de discutir con todo el equipo. La agenda se debe respetar durante el desarrollo de la reunin y evitar desviarse de los puntos enumerados. En caso de que cualquier otra persona tenga un tema adicional, lo tienen que indicar antes de que sea iniciada la reunin para que sea insertado en la agenda. Si el tema lo cita durante la reunin, se debe revisar una vez que los puntos de la agenda hayan sido vistos. Es importante que se trate de fijar una duracin tentativa de la reunin, con una hora de inicio y una hora de finalizacin, la cual debe indicarse en la agenda. Se debe buscar respetar esta duracin ya que con base a ella todos los profesionales involucrados pueden agendar sus trabajos. Se debe llevar una minuta (ver anexo 8.13) de todos los puntos que fueron discutidos durante la reunin. Esta minuta debe ser distribuida entre todos los participantes y aquellos interesados que sean determinados por el director. 4.3.2.6. Definir y priorizar riesgos (EJ-06)

Antes de que se arranque con el proyecto, debe hacerse un listado con todos los riesgos identificados del proyecto. De acuerdo al focus group realizado con los ingenieros senior del proyecto, cuyos resultados se pueden ver en el anexo 8.7, el listado de riesgos no es una prctica que se realice dentro de la

69

organizacin, sin embargo s se tiene cierta nocin de los riesgos que podran presentarse en el proyecto. Antes de que se genere la primera reunin con el equipo de proyecto asignado, debe generarse una sesin de definicin de riesgos dentro de la organizacin e idealmente debe ser con la participacin de todos los miembros del departamento de ingeniera, esto con el fin de poder obtener retroalimentacin y aportes de la experiencia que han tenido cada uno. La sesin, adems de realizar una identificacin de los riesgos, debe priorizarlos. Esta priorizacin tiene que realizarse mediante el juicio experto de todos los participantes, identificando cuales son aquellos que tiene mayor probabilidad de ocurrencia y con un impacto potencial mayor. Es importante que tambin sean destacados los riesgos positivos del proyecto, ya que estos deben ser explotados. En el anexo 8.14 se propone una plantilla para el registro de riesgos en los proyectos de ZFC. A partir de este momento se recomienda la aplicacin del principio de Pareto, el cual, aplicado en la administracin de proyecto, indica en trminos generales que el 80% de su presupuesto se va gastar en arreglar el 20% de sus problemas, por lo que es til concentrarse en este 20% ms importante (Fernndez, 2009). Aplicando ese principio, para el primer 20% de los riesgos priorizados se le debe planear un respectivo plan de respuesta en caso de que suceda, adems de distintas tcnicas ya sea para mitigar/mejorar, transferir/compartir o

eliminar/explotar el riesgo dependiendo si se trata de un riesgo negativo/positivo. Por ltimo para todos los riesgos, se les debe identificar cules son sus disparadores o triggers. El tener este aspecto claro en cada riesgo va permitir que a la hora de administrar el proyecto, el director sepa qu acciones pueden desembocar en la activacin de los riesgos determinados.

70

4.3.2.7.

Aseguramiento de Calidad (EJ-07)

En conjunto con el equipo del proyecto, el director debe definir qu actividades van a estar sujetas a efecturseles control de calidad. Para cada una de las actividades seleccionadas, se le debe subcontratar las respectivas pruebas de calidad. Este subcontrato se debe manejar tal y como se sealar ms adelante con respecto a las adquisiciones del proyecto. El director del proyecto debe revisar junto con el equipo las mtricas de calidad que ya fueron establecidas previamente (ver captulo 4.3.1.5) y corroborar cuales son los valores ideales en cada rubro de calidad y cules sern las tolerancias aceptables que se manejarn. 4.3.2.8. Desempeo subcontrato de calidad (EJ-08)

El director de proyecto o su asistente deben darle un constante seguimiento al proveedor seleccionado para ejercer el control de calidad. Se debe definir desde el inicio del proyecto, cada cuanto se generarn resultados e informes de los controles de calidad ejercidos y se tiene que velar porque se cumplan los plazos establecidos. Una vez esta periodicidad est establecida, el asistente de ingeniera debe encargarse de darle seguimiento a la presentacin de estos informes y qu sean entregados a los profesionales correspondientes que deban revisarlos. Es importante que la empresa designada para el control de calidad sea integrada activamente en el desarrollo del proyecto de forma tal que se pueda tener una posicin o una recomendacin de parte de ella ante cualquier problema que se suscite y en el que pueda tener alguna competencia. 4.3.2.9. Registro de incidentes (EJ-09)

El asistente del director del proyecto debe llevar un registro de cada uno de los problemas que se den durante todo el proyecto. No debe importar si el

71

problema que se dio era de gran impacto o no, tampoco si su solucin fue complicada o sencilla. Todo problema que se d, debe quedar registrado. Adems de indicar el problema, el registro debe contemplar cul fue la causa que lo gener, as como cual fue la solucin aplicada. Este documento va permitir nutrir de igual forma el registro de lecciones aprendidas. Igualmente va facilitar la comunicacin de los problemas a los interesados y un anlisis objetivo del proyecto, evaluando los problemas que se presentaron, en qu momentos se dieron y qu razones los causaron. En el anexo 8.9 se puede encontrar la plantilla propuesta para este registro. 4.3.2.10. Desarrollo del equipo interno (EJ-10) El director de proyectos debe desarrollar adecuadamente el trabajo en equipo que realiza con el ingeniero de proyectos. Este es el equipo conformado por ZFC para afrontar el proyecto y debe buscar cumplir sus objetivos todava de mejor manera que el resto del equipo. Se debe programar una reunin al inicio de cada semana entre los miembros designados por ZFC al proyecto. En ella se tienen que revisar los trabajos pendientes de la semana, los resultados obtenidos la semana anterior y las expectativas que se tiene para la semana que inicia. Asimismo este puede convertirse en un buen momento para que primeramente se hagan los reconocimientos necesarios por las labores que fueron realizadas correctamente. De igual forma se deben sealar los errores cometidos, analizarlos y marcar las pautas necesarias para que no vuelvan a ser realizados. 4.3.2.11. Prevenir problemas entre miembros de equipo (EJ-11) Como director de proyectos, el profesional asignado por ZFC es el principal responsable de que el equipo de proyecto funcione de la mejor manera y existan buenas relaciones entre cada uno de los miembros.

72

Es necesario que siempre est muy al tanto del entorno que rodea al equipo y de cualquier posible situacin de proyecto o de fuera de proyecto, que pudiera afectar el rendimiento de alguno o varios profesionales asignados al equipo. Los conflictos entre personas, deben ser de competencia completa del director. En estos casos debe haber una intervencin lo ms prematura posible con el fin de poder evitar que el problema se haga ms grande o en ltima instancia solucionarlo. Situaciones personales de cada individuo, si bien es cierto no siempre competen al director, s deben ser de su conocimiento para la adecuada gestin del recurso humano. 4.3.2.12. Evaluar rendimiento del equipo (EJ-12) Se debe evaluar constantemente el rendimiento de los lderes tcnicos que fueron subcontratados para conformar el equipo y desarrollar el proyecto. Inicialmente es necesario que el director del proyecto haga un listado de los profesionales a los cuales debe darles seguimiento. Es necesario que mantenga estricta vigilancia sobre el trabajo que realiza el equipo. Como subcontrato que es, se le debe dar un seguimiento constante y revisar que se cumplan las expectativas sobre las cuales fueron elegidos. Mediante esta evaluacin no se busca medir el conocimiento tcnico de cada uno de los lderes, sino lo que se debe evaluar es la forma en que realizan el trabajo, los tiempos de respuesta que tienen, la solucin de problemas relativos a su rea de conocimiento y el grado de compromiso que han adquirido para con el proyecto. En el anexo 8.15Error! No se encuentra el origen de la referencia. se puede encontrar la plantilla recomendada para esta evaluacin. 4.3.2.13. Herramienta para distribuir informacin (EJ-13) Se debe establecer dentro de la organizacin un mtodo para poder generar un flujo adecuado y ptimo de la informacin de proyecto. Los documentos de proyecto y de la organizacin deben estar siempre a la mano y actualizados.

73

En este sentido, lo que se plantea es que se establezca una plataforma virtual de manejo de la informacin. Esto es un espacio dentro del servidor de la empresa, en el cual se pueda estar colocando todos los documentos del proyecto y tener acceso a ellos desde cualquier punto de conexin. Tambin es posible aplicar herramientas de este tipo que existen en el mercado, tanto gratuitas como por medio de licencias. Estos sistemas generan espacios, dentro de servidores privados o pblicos, exclusivos para cada proyecto en especfico. De esta forma se va poder subir informes, cronogramas actualizados, controles de costos y presupuestos, fotografas, los registros de incidentes, etc. El acceso a todos estos archivos debe restringirse segn sea el caso. Este tipo de sitios virtuales, tambin son muy tiles ya que facilitan los procesos internos de la organizacin. As es como se puede dejar habilitados distintos machotes de documentos, disponibles para cuando se requieran. De igual forma se pueden manejar las agendas de los miembros del departamento de ingeniera y gestionar reuniones de forma ms gil y sencilla. En este sentido, es posible citar dos herramientas distintas que pueden ser utilizadas para los propsitos descritos anteriormente. Una de las opciones es la instalacin de la plataforma de SharePoint de Microsoft. Esta constituye una opcin que permite incrementar la productividad y administrar los contenidos a travs de la conocida interfaz de Office. (Microsoft Corporation, 2010) Para poder iniciar con el uso de esta herramienta, se debe comprar la licencia del producto e instalarlo en el servidor de la empresa. A partir de ese momento se debe coordinar con el departamento de soporte tcnico de la empresa para que paso a paso se vaya implementando el producto y ajustndolo a las necesidades propias del departamento de ingeniera. Una vez que se haya terminado ese proceso iterativo, se puede proceder a publicarlo e iniciar su uso.

74

Otra opcin que se encuentra disponible en el mercado es Google Apps. Esta es un instrumento virtual que busca el ordenamiento de las actividades de la empresa por medio de herramientas tecnolgicas. Las aplicaciones que tiene disponibles son: correo electrnico, Google Calendar, Google Docs, Grupos de Google, Google Sites, Google Videos. (Google, 2010) Cada una de las aplicaciones mencionadas buscan facilitar las operaciones dentro de la empresa generando espacios virtuales donde se puedan compartir calendarios, manejar documentos como hojas de clculo, presentaciones, etc. y con acceso remoto desde cualquier parte. De igual forma permite la creacin de sitios seguros para proyectos especficos en los cuales se pueda organizar la informacin y gestionar los permisos de ingreso al sitio. Es importante tener presente que la opcin de Google Apps implica almacenar informacin en un servidor que no va ser manejado directamente por la empresa, sino que la administracin recae en Google. Si bien es cierto se garantiza la seguridad, se debe tener presente que en este caso, la empresa que lo utilice se limitar a hacer uso del espacio y subir la informacin que considere pertinente. Con base en las descripciones anteriores es que la recomendacin que se plantea es el uso de una herramienta como Microsoft Sharepoint. De esta forma se puede contar con una mayor seguridad para los documentos que son subidos, ya que todo quedar dentro del mismo servidor de la empresa. De igual manera, permite flexibilidad para que se puedan ir ajustando las aplicaciones a las necesidades reales del departamento de ingeniera. 4.3.2.14. Seleccin de oferentes para licitacin (EJ-14) Se debe revisar la lista de oferentes aprobados previamente establecida antes de poder iniciar el proceso de licitacin para un determinado servicio, equipo o material que deba comprarse para el proyecto.

75

Este listado debe respetarse y en caso de que se quiera agregar algn nuevo oferente, se deber presentar la ficha tcnica y currculum de la empresa. Esta informacin deber ser revisada por el Jefe de Ingeniera quien aprobar o no la inclusin del nuevo proveedor. Del listado aprobado, se tienen que aplicar el juicio experto para discriminar cuales van a ser las empresas que se van a invitar a participar de la licitacin. Se debe evaluar: experiencias previas con el oferente, resultados anteriores y tiempos de respuesta, entre otros. 4.3.2.15. Reunin de apertura de licitacin (EJ-15) Una vez que los oferentes hayan sido seleccionados, se les debe enviar una invitacin formal a participar en la licitacin que se vaya a abrir. Se debe programar una reunin con todas las empresas participantes en la cual se explique el alcance de la adquisicin, as como las expectativas que se tienen con respecto a la compra que se va a realizar. De igual forma se debe indicar cualquier detalle que se considere importante de cara a la formulacin de la oferta. Al finalizar la reunin se debe generar una minuta, en la cual se describa los puntos discutidos y aclarados. Esta minuta se debe circular entre todos los oferentes y pasa a formar parte de los documentos de la adquisicin. (Ver captulo 4.3.1.13) 4.3.2.16. Visita al sitio (EJ-16) En algunos casos (dependiendo de las caractersticas de la adquisicin que se vaya a realizar), se tienen que programar una visita al sitio de parte de todas los oferentes seleccionados. En esta visita se deben ver las condiciones en las que el servicio va ser provedo o en las que el material o equipo va ser instalado. Se deben resaltar cualquier caracterstica o condicin especial que el oferente deba tener en cuenta cuando genere la propuesta. De esta visita igualmente se debe generar una

76

minuta de todo los discutido y aclarado y pasa a formar parte de los documentos de la adquisicin. (Ver captulo 4.3.1.13) 4.3.2.17. Revisin de ofertas (EJ-17) Previo a la recepcin de las ofertas, se debe definir cules sern los parmetros principales que sern tomados en cuenta cuando se evalen las ofertas. En caso de que sea una contratacin directa de ZFC, los parmetros deben ser definidos por el director de proyectos asignado. Si es una contratacin para un proyecto con uno de sus clientes, los parmetros tienen que ser definidos en conjunto con el representante del cliente. A cada parmetro se les debe asignar un peso especfico de acuerdo con las necesidades especficas del proyecto. Este parmetro debe ser evaluado y calificado en cada una de las ofertas, de tal forma que se pueda totalizar la sumatoria de la calificacin que obtuvo en cada oferente. Al final de este proceso el proveedor con el mayor puntaje se convertir en la primera recomendacin. En el anexo 8.16 se propone una plantilla para que sea usada en la evaluacin de las ofertas. Si bien es cierto, la determinacin del peso y la calificacin es algo totalmente subjetivo, el mtodo permite proveer objetividad a la recomendacin que se obtenga al final del anlisis. El resultado que se obtenga no es ms que una recomendacin, al final quien debe tomar la decisin es el director de proyecto, el jefe de ingeniera y el cliente si fuese necesario. Sin embargo la recomendacin debe contar con un respaldo objetivo o con la debida justificacin si se trat de una decisin subjetiva. Es necesario que se genere y quede un documento contractual debidamente firmado por las partes involucradas en el proceso de adquisicin. Este contrato debe contener todas las clusulas suficientes para regular el transcurso de la compra. Aspectos como alcance contratado, multas debido a entregas tardas, lugares de entrega y formas de pago deben incluirse.

77

Otro aspecto que se debe revisar es que en este caso en especfico al tratarse de una zona franca, se cuenta con condiciones especiales y distintas a las de cualquier empresa, por lo que es un aspecto importante a tener presente dentro de los activos de los procesos de la organizacin.

4.3.3.

Resumen de Metodologa de Ejecucin

Seguidamente se presentar un resumen de la metodologa que fue planteada para el grupo de procesos de Ejecucin.
Cuadro 4.2. Resumen de metodologa de ejecucin.
Cdigo Proceso 1. Procedimiento Solicitar nombres de los profesionales asignados al proyecto. Solicitar currculum de ellos si no son conocidos previamente. Si ya se ha trabajado con ellos revisar evaluaciones que ya se haya hecho de ellos en proyectos previos. Evaluar cada profesional asignado. Aceptar o no el equipo asignado. En ZFC Jefe de ingeniera debe convocar a reunin de arranque de proyecto. Resaltar virtudes del equipo. Exponer expectativas para con el equipo. Valorar el trabajo que han realizado previamente. Juicio experto 1. 2. 3. En equipo de proyecto Motivar al equipo en la reunin de arranque. Admitir la confianza en el equipo asignado. Hacer los reconocimientos necesarios durante las reuniones cuando se hayan logrado buenos resultados. Obtener o generar acta constitutiva del proyecto. Asegurarse que el acta tiene el G.001 8.11 Tcnicas y Herramientas Plantilla utilizada Anexo

2. EJ-01 Evaluacin inicial del equipo de proyecto 3.

Juicio experto

4. 5.

1.

2. 3. 4. EJ-02 Motivacin inicial

EJ-03

Presentacin del Acta Constitutiva

1. 2.

78

del Proyecto al equipo 3.

4.

5.

6.

visto bueno del cliente o el gerente del ZFC. Presentar este documento al equipo del proyecto en la primera reunin. Hacerles llegar a todos los miembros del equipo en forma fsica o digital este documento. En la siguiente reunin todos deben firmar el documento haciendo constar que aceptan lo que en l se indica. Archivar el acta debidamente aprobada por todos. Definir los roles de cada uno de los miembros del equipo. Analizar los posibles medios de comunicacin a utilizar. Seleccionar una o varias herramientas de comunicacin y asegurarse que el equipo de proyecto y los principales interesados tengan acceso a ella o ellas. Establecer un flujo de comunicacin que muestre de qu forma debe viajar la informacin y los responsables. Presentar el flujo de comunicacin en la reunin de arranque del proyecto. Debe asegurarse que el procedimiento quede claro para todos. Con base en el flujo propuesto, se debe explicar de qu forma puede escalar la informacin y velar porque se respete. Definir qu documentos puede trabajarse de forma virtual y qu otros requieren un respaldo fsico. Generar agenda de la reunin con base a los temas abiertos de reuniones previas y asuntos nuevos. Estimar duracin de la reunin e indicarlo en la agenda. Circular agenda de la reunin al menos un da antes de la misma. Respetar agenda durante la reunin. Temas nuevos discutirlos una vez se haya completado la agenda. Velar por que se cumpla el tiempo estimado Generar minuta de la reunin. Circular minuta de la reunin entre el equipo de proyecto.

1. 2. 3.

4. Definir canales de comunicacin

EJ-04

Juicio experto

5.

6.

7.

1.

2. 3. EJ-05 Manejo de reuniones de proyecto. 4. 5.

Agenda de reunin Medicin de tiempo

G.002

8.12

G.003

8.13

6. 7. 8.

79

1.

2. Definir y priorizar riesgos

EJ-06

3. 4.

5. 1.

Generar una sesin dentro de ZFC de definicin de riesgos positivos y negativos. Definir cules son los riesgos con mayor probabilidad de ocurrencia e impacto potencial mayor. Priorizar los riesgos mediante juicio experto. Definir un plan de respuesta para el primer 20% de los riesgos priorizados. Identificar los disparadores de todos los riesgos. Definir qu actividades necesitan un subcontrato de control de calidad. Realizar la subcontratacin de las empresas de control de calidad. Revisar las mtricas de calidad establecidas. Establecer los valores mnimos para cada variable evaluada. Definir las tolerancias que se aceptarn. Definir periodicidad de presentacin de informes de control de calidad. Velar por la presentacin de los informes de acuerdo a lo acordado. Integrar al equipo de control de calidad en el desarrollo del proyecto. Registrar semanalmente los problemas sucedidos en el proyecto. Determinar la causa de los problemas identificados. Indicar cul fue la solucin aplicada. Programar una reunin a inicio de semana con el equipo de ZFC del proyecto para coordinacin de trabajos. Revisar los trabajos que estn pendientes de realizarse durante la semana y las expectativas que hay. Evaluar los resultados obtenidos durante la semana anterior. Dar los reconocimientos necesarios por las tareas cumplidas. Identificar y analizar los errores producidos.

Sesin de definicin de riesgos Juicio experto Principio de Pareto

ZFC.004

8.14

2. EJ-07 Aseguramiento de Calidad

3. 4. 5. 1.

Juicio experto

EJ-08

Desempeo subcontrato de calidad

2.

Juicio experto

3.

1. EJ-09 Registro de incidentes

2. 3. 1.

Inspeccin

ZFC.002

8.9

2. EJ-10 Desarrollo del equipo interno

Reuniones de seguimiento Juicio experto -

3. 4.

5.

80

1. Prevenir problemas entre miembros de equipo 2.

EJ-11

3. 4. 1.

Hay que estar atento al entorno que rodea al equipo de proyecto. Identificar cualquier situacin que pudiera afectar potencialmente el rendimiento del equipo. Intervenir si se da un problema entre miembros del equipo. Buscar una solucin entre las partes involucradas. Hacer un listado de todos los profesionales que deben ser evaluados. Mantener una constante vigilancia sobre el trabajo realizado por los lderes tcnicos. Utilizar la herramienta establecida para el flujo interno de informacin. Actualizar semanalmente los documentos que hayan sufrido variaciones y aplicar la herramienta. Revisar el listado de oferentes previamente aprobados. Si se desea agregar un oferente nuevo solicitar el currculum de la empresa y someter la empresa al criterio del Jefe de Ingeniera. Discriminar del listado de oferentes las empresas que sern incitadas a la licitacin. Preparar toda la documentacin que se entregar para la licitacin. Invitar formalmente a las empresas seleccionadas para que participen en la licitacin. Programar una reunin de apertura de licitacin en la que se explique el alcance y expectativas de la adquisicin. Generar una minuta de la reunin y circularla entre los participantes. Programar una visita al sitio de todos los oferentes. (si aplica) Sealar y mostrar las condiciones en las que el servicio va ser provedo o en las que el material fue instalado. Generar una minuta de lo discutido, aclarado y acordado durante la minuta.

Juicio experto

EJ-12

Evaluar rendimiento de equipo

2.

Juicio experto

ZFC.005

8.15

1. EJ-13 Herramienta para distribuir informacin

2.

Plataforma virtual de informacin

1. 2. EJ-14 Seleccin de oferentes para licitacin 3.

Juicio experto

1.

2. EJ-15 Reunin de apertura de licitacin

3.

Reunin

G.003

8.13

4.

1. 2. EJ-16 Visita al sitio 3.

Inspeccin

G.003

8.13

81

1. 2. Revisin de ofertas 3.

EJ-17

4.

5.

Definir parmetros que sern evaluados en las ofertas. Asignar un peso especfico a cada variable a evaluar. Realizar la evaluacin de las ofertas de acuerdo con la plantilla establecida. Revisar que la oferta cumple con todas las condiciones de alcance, costo y plazo establecidas en la licitacin. Generar una recomendacin.

Anlisis multicriterio

ZFC.006

8.16

4.4. Grupos de Procesos de Seguimiento y Control El seguimiento y control consiste en la realizacin de todos los procesos que sean requeridos para darle seguimiento, revisar y regular el progreso que tenga el proyecto. Asimismo se debe identificar en las reas en las que sea necesaria la aplicacin de cambios y ejecutar el cambio. (Project Management Institute, 2008)

4.4.1.

Entradas Iniciales

Para la aplicacin de la metodologa que se plantear para este grupo de procesos, se debe partir de una serie de entradas necesarias. Algunas de stas coinciden con las que se plantearon en el captulo 4.3.1. Las dems entradas planteadas se generan producto de la aplicacin de la metodologa de ejecucin.

4.4.2.

Propuesta Metodolgica

A continuacin se presentar la propuesta metodolgica para el seguimiento y control de los proyectos en ZFC. El planteamiento est basado en las buenas prcticas que propone el PMI y adecuado a la realidad del parque.

82

4.4.2.1.

Registro de lecciones aprendidas (SyC-01)

Una vez que el proyecto haya dado inicio, el director de proyectos debe abrir un documento para llevar el registro actualizado de las lecciones aprendidas que se den producto del desarrollo del proyecto. Este documento debe abrirse ingresando todas las lecciones aprendidas que se dieron en los procesos de iniciacin y planificacin del proyecto. Este documento debe mantenerse en constante actualizacin cada vez que el director de proyectos lo considere necesario. La informacin para llevar este log, puede generarse por el juicio experto del director o de cualquier otro miembro del equipo. Si lo considera necesario, el director puede convocar al equipo del proyecto a reuniones al menos una vez al mes para identificar y discutir las lecciones aprendidas que se generen. Igualmente el director podra incluir este tema dentro de la agenda de la reunin. Es importante que el registro de lecciones se incluya dentro de los informes mensuales del proyecto que se deben presentar. En el anexo 8.17 se puede encontrar una plantilla para la documentacin de las lecciones aprendidas. 4.4.2.2. Mecanismo para aprobacin de cambios (SyC-02)

Se debe establecer un mecanismo para que se d la revisin y aprobacin de los cambios que sean solicitados a lo largo del proyecto. Este procedimiento debe ajustarse a las condiciones propias del proyecto y se deben tener en cuenta los factores ambientales de la empresa. En el anexo 8.18 puede verse la propuesta de un diagrama de flujo para aprobacin de cambios. En la primera reunin de coordinacin, se debe presentar la propuesta para la aprobacin de cambios, tomando en cuenta los criterios de la inspeccin, el cliente y de la zona franca. El proceso debe quedar claro para todas las partes y deben estar de acuerdo con l.

83

Asimismo, se deben establecer cul es la informacin mnima que debe presentarse cuando un cambio sea solicitado. Entre ellos se puede citar: solicitante del cambio, justificacin del cambio, responsable de ejecutar el cambio, descripcin e impacto en el alcance, impacto econmico, impacto en cronograma y riesgos asociados al cambio solicitado. El director de proyecto debe asegurarse que se realice una revisin correcta de las caractersticas del cambio que es solicitado, as como revisar las implicaciones que se den en el presupuesto y cronograma del proyecto previamente aprobados. Por ltimo en el anexo 0 se indica el formulario que se debe llenar y presentar para tramitar la aprobacin de un cambio. Este formulario ya es aplicado dentro de la organizacin y es el que tiene que ser firmado en el paso 14 del diagrama de flujo de solicitud y aprobacin de cambios (anexo 8.18) para que el cambio se pueda tomar como finalmente aprobado. 4.4.2.3. Verificar alcance (SyC-03)

Para una adecuada verificacin del alcance se debe mantener una constante comunicacin con el cliente y usuario final del producto a lo largo de todo el proyecto. En todo momento del proyecto las expectativas del cliente tienen que estar claras y cualquier cambio en ellas debe ser reflejado en una actualizacin del scope manual. Este documento junto con el chrter del proyecto deben ser los documentos bases sobre los cuales se debe revisar el producto final. Cuando a solicitud del cliente o debido a una necesidad especfica del proyecto se deba de ampliar o reducir el alcance del proyecto, el director de proyectos debe gestionar y asegurar que el cambio solicitado sea aplicado siguiendo el respectivo proceso de aprobacin de cambios previamente establecido. En el caso de los proyectos desarrollados por ZFC, la empresa encargada de de verificar que se est cumpliendo con el alcance requerido es aquella

84

subcontratada para la inspeccin del proyecto. El director de proyectos debe apoyarse en este grupo de profesionales para corroborar que el proyecto ha cumplido a satisfaccin con los requerimientos y especificaciones establecidos al inicio del proyecto. La inspeccin en combinacin con el juicio experto son las tcnicas que deben ser aplicadas para verificar el alcance del proyecto. Asimismo el listado de puntos pendientes (punch list) es la herramienta comnmente usada para controlar que cualquier detalle incorrecto sea corregido. Hasta que el punch list no est cerrado, no se puede dar por aceptado el proyecto. El punch list es un documento que va ser generado por la firma encargada de realizar la inspeccin del proyecto, por lo que el formato de este documento va depender ms de esta empresa subcontratada que de la propia zona franca. Sin embargo en el anexo 8.20 se indica un ejemplo bsico de cmo es un registro de este tipo y qu informacin contiene. 4.4.2.4. Estudio del cronograma (SyC-04)

Es responsabilidad del director de proyectos y el ingeniero de proyectos de realizar un estudio detallado de la ltima versin del cronograma al momento de que se inicie el proyecto. Este cronograma aprobado se constituir en la lnea base sobre la cual se medir el avance. Se debe generar un documento adicional en el cual se detalle: Fecha de inicio oficial. Fecha de cierre oficial. Hitos ms importantes. Actividades ms destacadas o de mayor cuidado, con su respectiva fecha de inicio planeada. Actividades de la ruta crtica, con su respectiva fecha de inicio planeada.

85

Este documento ser una herramienta ms accesible para poder llevarle un mejor control al avance del proyecto y debe estar a mano durante todo el proyecto. En el anexo 8.21 se encuentra una plantilla propuesta para el estudio del cronograma propuesto. De igual manera, una vez que se haya hecho un anlisis del cronograma, se debe revisar si es necesario adicionar o eliminar algn riesgo en el documento de registro de riesgos. Las actividades que son parte de la ruta crtica, pueden constituirse en riesgos potenciales a los cuales hay que darle seguimiento. 4.4.2.5. Seguimiento del cronograma (SyC-05)

El cronograma debe revisarse semanalmente previo a la realizacin de las reuniones de coordinacin. Cualquier variacin que se haya encontrado con respecto al planeamiento original y reflejado en la lnea base, debe ser notificado al equipo y a los responsables, con el fin de evaluar los posibles impactos y soluciones a la variacin presentada. Para la revisin de posibles soluciones a las variaciones en el avance del proyecto, se puede realizar el anlisis de los escenarios Que pasa si... Esta tcnica se basa en el planteamiento de diferentes escenarios, atrasando, extendiendo o comprimiendo actividades y aplicando estos cambios y factores externos al software utilizado para el desarrollo del cronograma. A partir de los resultados que se obtengan, se puede analizar la posibilidad real de que se aplique o no alguna de las soluciones que se plantearon y ver cules seran las consecuencias potenciales que se obtendran en caso de ser empleadas. Cualquier variacin que sea aplicada al cronograma del proyecto, debe ser notificada al cliente por medio de las herramientas de comunicacin previamente establecidas. Asimismo se debe informar sobre los impactos que esta variacin cause.

86

Otra herramienta que puede utilizarse para darle seguimiento al avance que ha tenido el proyecto con respecto al avance programado, es el valor ganado. Este es un instrumento muy til y que puede ser aplicado cada vez que tenga que revisarse el avance del proyecto para poder gestionar el pago al subcontratista correspondiente. Esta tcnica bsicamente consiste en la comparacin entre lo que se ha hecho realmente hasta la fecha de corte del anlisis y lo que se haba planeado que deba de estar ejecutado para esa misma fecha. Para ello, es necesario que antes que el proyecto comience, se establezca un flujo de caja del proyecto en el cual se indique de qu forma es que se van a realizar los desembolsos durante el proyecto para el pago del subcontrato. Este flujo de caja, el cual debe estar basado y coincidir con el avance que se indica en el cronograma aprobado, se constituir en la lnea base y ser el Costo Presupuestario Programado PV (planed value). El avance real a la fecha, en el caso de los proyectos de ZFC, ser el que apruebe la inspeccin para que sea tramitado y se genere el pago respectivo. Este avance de proyecto aprobado, es el que debe compararse contra lo que se tena planeado tener de avance para esa fecha, y eso se constituir en el Costo Presupuestado del Trabajo Realizado EV (Earn Value). Teniendo estos dos valores es posible obtener dos datos distintos que van a servir para analizar el avance del proyecto. Uno de ellos es la Variacin en el Cronograma SV (Schedule Variance). Esta variable lo que provee es una comparacin entre el avance obtenido en el trabajo del proyecto en un periodo de tiempo dado y el avance en el trabajo que se haba planeado para ser ejecutado. Lo que muestra es si el cronograma est atrasado o adelantado con respecto a la lnea base. (Salas, 2010) A continuacin se enuncian la frmula correspondiente a esta variable.

87

SV =

EV PV

SV=0 Proyecto de a cuerdo con el cronograma est al da. SV<0 Proyecto atrasado de a cuerdo con el cronograma est al da. SV>0 Proyecto adelantado de a cuerdo con el cronograma est al da.

La otra variable que se puede obtener es el ndice de Rendimiento del Cronograma SPI (schedule perfomance index). Este valor representa cuantas unidades de dinero de trabajo se ganaron en promedio de cada unidad de dinero de trabajo que estaba planeada hasta le fecha de anlisis. Seguidamente se cita la formula correspondiente. (Salas, 2010)

SPI =

EV / PV

SPI=1 Proyecto con rendimiento del cronograma igual al planeado. SPI<1 Proyecto con rendimiento del cronograma menor al planeado. SPI>1 Proyecto con rendimiento del cronograma mayor al planeado.

Con base a los indicadores descritos anteriormente, es posible realizar un anlisis del avance que ha tenido el proyecto. Esta tarea debera realizarse cada vez que se le apruebe un avance al subcontratista para que facture, de esta forma se puede llevar un control quincenal de cmo es el avance que tiene el proyecto con respecto a lo que se plane. Es importante que si se utiliza esta tcnica del valor ganado se complemente con lo indicado al inicio de esta seccin como es la revisin del cronograma. Esto debido a que el earn value va proveer un anlisis del avance del proyecto con

88

respecto a los costos planeados y los costos realmente pagados, pero es elemental que la informacin que se obtenga se analice junto con una revisin del avance del cronograma para tener un resultado ms detallado del estado del proyecto. Podra darse la situacin de que los resultados de SV y SPI indiquen que el avance del proyecto es correcto, sin embargo podra suceder que una actividad se haya adelantado y otra se haya atrasado propiciando que se genere un resultado que haga suponer que el avance a la fecha es de acuerdo a lo planeado o mejor. El problema puede darse si la actividad que se atras es parte de la ruta crtica y si la actividad que se adelant no lo es. Si este escenario se diera, se estara generando dentro del proyecto una sensacin de satisfaccin porque se va cumpliendo el avance de acuerdo a lo que se esperaba, pero habra un riesgo latente muy alto como es el que una actividad de la ruta crtica est atrasada. Es por ello que es necesario que una herramienta como la del valor ganado se vea complementada por un anlisis adecuado del proyecto y del cronograma real. De esta forma se puede llegar a un mejor anlisis del estado real del proyecto en una determinada fecha de corte. Evitando as que se pueda generar expectativas que no coincidan con la realidad y que posteriormente puedan acarrear mayores problemas para el proyecto. Adicionalmente es posible obtener dos proyecciones que pueden permitir analizar el proyecto con respecto a su finalizacin. La primera de ellas es la Estimacin del Tiempo para Terminar o STC (schedule to completion). La frmula es la que se describe a continuacin:
STC = Tiempo que falta de acuerdo a lo planeado / SPI

Por otro lado tambin se puede estimar la duracin total que tendr el proyecto de acuerdo con los datos reales que se tienen a le fecha. Para ello se

89

obtiene la Estimacin de la duracin total del proyecto o SAC (schedule at completion). La formula se presenta a continuacin:
SAC = Tiempo transcurrido hasta el momento + STC

En el anexo 8.29 puede encontrarse un ejemplo prctico para la aplicacin de la herramienta del valor ganado en un proyecto de construccin. 4.4.2.6. Control de costos (SyC-06)

Los costos del proyecto es quizs el aspecto al que ms atencin le dan los interesados del proyecto. Por ello es importante que el director y el ingeniero de proyectos le lleven un control ms estricto a cualquier variacin que se pueda presentar en l. Debido a que en ZFC no se realizan los trabajos de una forma directa sino por medio de un subcontrato, desde el inicio del proyecto se conoce cul va ser el monto que se consumir debido al servicio o producto contratado. Es por ello que al iniciar el proyecto se debe generar un flujo de caja estimado bisemanal, el cual refleje todos los pagos que tienen que hacerse para los subcontratos que se han adquirido. Este flujo de caja debe ajustarse a los plazos y las formas de pago que se hayan convenido con las empresas que fueron subcontratadas. Si bien es cierto el monto que se deber cancelar es nico y negociado previamente (hasta que se apruebe un cambio), el seguimiento al flujo de caja va permitir llevar un control del avance que tiene el proyecto. Esto debido al hecho de que los pagos que se realicen se harn contra avance real y de esta forma podr compararse si el avance que hay a la fecha de corte, es igual, superior o inferior al que se plane y con el cual se gener el flujo de caja. El director de proyecto debe estar atento a los impactos econmicos que se den producto de los cambios solicitados y de cualquier otro imprevisto que se pueda generar y en caso de que se apruebe el cambio, el flujo de caja debe ser actualizado. Este costo se debe revisar con respecto al monto presupuestado

90

autorizado y se tiene que velar porque la sumatoria total de todos los subcontratos adjudicados, no supere el monto aprobado. Actualmente dentro de la organizacin se cuenta con plantillas para control del presupuesto las cuales son bien detalladas y reflejan los gastos realizados, los impactos econmicos de los cambios y la proyeccin presupuestaria de los cambios solicitados. Ests plantillas deben aplicarse y actualizarse al menos bisemanalmente o cuando un cambio ha sido solicitado. 4.4.2.7. Informar sobre los costos (SyC-07)

Como se mencion anteriormente, el presupuesto es de los aspectos ms delicados para los interesados del proyecto. Se debe mantener informados a los interesados claves sobre del desempeo econmico que ha tenido el proyecto. Para ello, en los informes mensuales se debe indicar los gastos a la fecha y las proyecciones presupuestarias con base a los cambios que se hayan solicitado y que se hayan aprobado. En el anexo 8.22 se presenta una gua para la elaboracin de este tipo de informes. Este informe se debe presentar por medio de los canales ya establecidos y se debe colocar en el sitio virtual designado para que aquellas personas de la organizacin que estn autorizados, tengan acceso a l. 4.4.2.8. Gestionar el control de calidad (SyC-08)

Previamente ya han sido establecidas cuales son las actividades y tareas a las que se le realizar un control de calidad a lo largo de toda su duracin. Adicionalmente ya han sido adjudicados los subcontratos de calidad que se encargarn de ejecutar el control de calidad. A partir de eso, el director de proyecto debe velar porque esas tareas relacionadas con el control de calidad sean efectuadas. Es necesario que se lleve un registro de los informes que deben recibirse y de la periodicidad con que deben ser presentados. Para ello, se ha propuesto una

91

plantilla (anexo 8.23) para poder darle seguimiento a la presentacin de estos reportes de parte del subcontratista de calidad. De igual manera, se debe corroborar que estos documentos sean revisados y analizados por el equipo de inspeccin del proyecto con el fin de que se detecte cualquier incumplimiento con los parmetros de calidad establecidos en las mtricas de calidad. Se debe solicitar a los encargados de inspeccin, las notificaciones respectivas en caso de que se est presentado un problema con alguno de los parmetros calidad determinados. El incumplimiento de la tolerancia mxima permitida debe promover la revisin de las actividades realizadas y el mtodo que se est empleando para efectuarlas. 4.4.2.9. Control de calidad (SyC-09)

Cuando algn incumplimiento sea detectado producto de los controles aplicados, debe ser responsabilidad del director de proyecto apoyado junto con todo el equipo, de la bsqueda de la solucin ms efectiva y pronta posible, de forma tal que se solucione el problema de calidad existente y se afecte lo menos posible el alcance, el costo y el plazo del proyecto. La solucin planteada puede significar la aplicacin de alguna garanta o la ejecucin de una medida correctiva, por lo que la resolucin se traslada a una empresa o persona fsica responsable por el trabajo realizado. Asimismo, el mecanismo para solucionarlo puede significar la generacin de una solicitud de cambio la cual debe justificarse y aplicrsele el mecanismo de aprobacin de cambios establecido. 4.4.2.10. Informes de rendimiento de proyecto (SyC-10) Inicialmente, se debe revisar el documento con el registro de los interesados y se tiene que evaluar cuales son los stakeholders del proyecto a los cuales se les debe mantener con informacin actualizada sobre el avance y el rendimiento del proyecto.

92

El equipo del proyecto de ZFC, est en la responsabilidad de generar dos tipos de informes. El primero de ellos debe estar dirigido hacia los interesados del proyecto identificados (anexo 8.22). Este informe debe contener toda la informacin necesaria para que ellos puedan tener un panorama bastante claro de cul es el estado actual del proyecto y cul es su rendimiento con respecto a lo que se ha planeado. Es importante tener claro cul es rol que juega cada uno de los interesados a los cuales les est llegando la informacin, esto con el fin de saber si el informe contiene el tipo de informacin que a esa persona le interesa. Esta comunicacin debe ser idealmente de forma semanal, dejando un mximo de dos semanas entre los informes. Cada uno de estos reportes debe contener al menos: descripcin escrita y visual del avance del proyecto, rendimiento del cronograma, registro de cambios solicitados y aprobados, registro de riesgos e incidencias sobre el control de calidad, entre otros. Esta es la informacin que se debe incluir como mnimo, sin embargo puede aumentar dependiendo de la solicitud de algn stakeholder especfico. El segundo informe que se debe generar es para el seguimiento y control a lo interno de la organizacin. Este documento le va permitir al jefe de ingeniera y a los jefes de los dems departamentos de ZFC que tienen alguna relacin con el proyecto, conocer el rendimiento general del mismo. Este reporte puede tener una periodicidad mensual y tienen que contener al menos lo siguiente: Avance escrito y visual del proyecto. Rendimiento del cronograma. Rendimiento del presupuesto. Proyecciones presupuestarias. Registro de cambios solicitados y aprobados. Registro de riesgos.

93

Incidencias sobre control de calidad. Actividades venideras. Soluciones propuestas a cualquier problema con los rendimientos del proyecto y registro de lecciones aprendidas. Este documento es igualmente importante porque le va permitir a la

organizacin llevarle un mejor pulso al proyecto. Igualmente da la oportunidad de que se puedan prevenir problemas con base a experiencias previas. En el anexo 8.24 se presenta una gua para su elaboracin. 4.4.2.11. Seguimiento de riesgos (SyC-11) El registro de riesgos es un documento al cual se le debe estar dando un seguimiento y actualizacin contina. Esto con el fin de poder identificar nuevos riesgos de forma temprana y con tiempo suficiente para reaccionar, as como eliminar riesgos que ya han desaparecido y poder liberar recursos y esfuerzos que estuvieren enfocados en ese riesgo. Este documento debe ser revisado de forma semanal, inicialmente por el equipo de proyecto de ZFC y posteriormente debe ser discutido y evaluado en las reuniones de coordinacin por el equipo completo del proyecto. Se tiene que poner un especial cuidado al 20% de los riesgos que fueron identificados como los que tienen mayor probabilidad e impacto previstos. Sin embargo tambin se debe revisar el listado completo de riesgos que fueron identificados inicialmente. Es importante que tambin se le d seguimiento a los disparadores que fueron determinados en el registro de riesgos. La aparicin de alguno de ellos significa la potencial ocurrencia del riesgo, por lo que si se les sigue adecuadamente va permitir preparar mejor al proyecto y al equipo ante la eventualidad del riesgo. Los planes de respuesta que se haban establecido tambin tienen que ser revisados peridicamente por el director de proyectos y el ingeniero de proyectos. Estos planes deben estar ajustados siempre a la realidad propia en la que se est

94

desarrollando el proyecto, por lo que tambin estn sujetos a una actualizacin si as es considerado por el director. 4.4.2.12. Control de riesgos (SyC-12) El control de los riesgos se debe evaluar mediante la aplicacin de los planes de respuesta que fueron establecidos en el registro de riesgos. Una vez que estos planes hayan sido empleados, se les debe dar el seguimiento adecuado para evaluar la efectividad de la medida adoptada. En el anexo 8.25 se puede encontrar una plantilla propuesta para el seguimiento y control de los riesgos. En caso de que el plan de respuesta no d los resultados esperados, se debe buscar una medida alternativa entre todo el equipo de proyecto y buscar su aplicacin inmediata si el proyecto as lo requiere. En estos casos se debe buscar la colaboracin de todas las partes para evitar impactar el proyecto de alguna forma. Se debe tener presente que es importante mantener a los interesados al tanto de cualquier posible eventualidad que se presente, especialmente si la nueva alternativa para hacerle frente al riesgo implica algn impacto en el costo, el tiempo o el alcance, los interesados deben estar completamente informados de la medida y deben estar de acuerdo con la misma. 4.4.2.13. Seguimiento a proveedores (SyC-13) Desde el momento en que una adquisicin ha sido adjudicada, el equipo de proyecto de ZFC debe darle un constante seguimiento al proveedor al que le fue hecha la compra. Asimismo, no se debe evaluar nicamente que se cumpla con los requisitos legales establecidos en el contrato, sino tambin caractersticas ms organizativas de la empresa. Aspectos como los tiempos de respuesta, la calidad de los profesionales con que cuenta, su estructura organizativa, la calidad del servicio y el inters mostrado hacia ZFC como cliente, son variables que deben ser

95

evaluadas y registradas cada vez que se aplique un seguimiento al contrato efectuado. 4.4.2.14. Administracin del contrato (SyC-14) Se debe velar porque todas las condiciones que fueron establecidos en el contrato sean cumplidas a cabalidad tanto por el proveedor que fue adjudicado, como por ZFC. Es importante generar un documento de control de proveedor en cual de forma peridica se revise el estado de la adquisicin realizada. Se debe tener presente los plazos de entrega, las formas de pago y los procedimientos de entrega que fueron establecidos y revisar el cumplimiento que el oferente est realizando de estas variables. Sin importar si se trata de un material, un servicio o un equipo, el director de proyectos tiene el derecho a solicitar informes peridicamente a cerca del progreso que lleva el objeto que fue adjudicado. Estos informes sirven para conocer si todo va de acuerdo al cronograma establecido o si por el contrario se pudiera llegar a presentar algn atraso con la fecha de entrega del producto. En el anexo 8.26 se presenta una plantilla para el registro de los informes solicitados. En el caso de eventualidades negativas hacia el proyecto, se debe actualizar el registro de riesgos e informar a los interesados que considere necesarios sobre la situacin que pudiera presentarse y las medidas que se tomarn en caso de que suceda. Asimismo se deben evaluar todas las posibles opciones que pueden aplicarse con el fin de solventar el atraso y volver al cronograma de compras inicial. 4.4.2.15. Actualizacin de documentos de proyecto (SyC-15) A lo largo de todo el seguimiento y control de un proyecto, se realizan una serie de tareas que brindan informacin muy importante sobre el estado del proyecto. Esta informacin se compara contra lo que fue planeado y de esta forma se sabe que tan bien o no va el proyecto.

96

Cualquier variacin que se encuentre, implica cambios con respecto a lo que originalmente se planeo o se dispuso. Todos los documentos de proyecto que se vean afectados por esa diferencia deben ser actualizados, de forma tal que la ltima versin del documento refleje la realidad del proyecto en ese instante. El PMBOK (Project Management Institute, 2008) recomienda el

establecimiento dentro de un proyecto del Sistema de Gestin de la configuracin. Este sistema lo que va permitir es que se puedan gestionar los cambios y las lneas base del proyecto de una manera normalizada, efectiva y eficiente. (Project Management Institute, 2008) Lo que se debe buscar a la hora de establecer este sistema es que la mayora de los entregables como los procesos que hayan sido establecidos en el proyecto puedan especificarse. De esta manera va ser ms sencilla la identificacin, documentacin y control de los cambios que se den, logrando de esta manera una actualizacin constante en los documentos del proyecto. (Project Management Institute, 2008) La aplicacin del Sistema de Gestin de la Configuracin logra tres objetivos principales: (Project Management Institute, 2008, pg. 94) 1. Establecer un mtodo progresivo para identificar sistemticamente y solicitar cambios a las lneas base establecidas, y para determinar el valor y eficacia de estos cambios. 2. Proporcionar oportunidades de validar y mejorar el proyecto de manera continua, tomando en cuenta el impacto de cada cambio. 3. Proporcionar el mecanismo que permita al equipo de direccin del proyecto comunicar a los interesados, de manera sistemtica, todos los cambios aprobados y rechazados. Una vez que las actualizaciones hayan sido realizadas es importante que no se eliminen las versiones anteriores de estos documentos, por lo que se debe generar una nueva versin con la actualizacin realizada. De esta manera, cuando

97

se revisen todos estos documentos al final del proyecto, se va poder generar una radiografa de la evolucin que hubo y de los cambios especficos que se dieron. Esto es un detalle importante a la hora de sacar conclusiones finales del proyecto y terminar de completar las lecciones aprendidas.

4.4.3.

Resumen de Metodologa de Seguimiento y Control

A continuacin se presentar el respectivo resumen de la metodologa y los procedimientos correspondientes para el grupo de procesos de seguimiento y control.
Cuadro 4.3. Resumen de metodologa de seguimiento y control.
Cdigo Proceso 1. Procedimiento Iniciar el documento de lecciones aprendidas ingresando todas aquellas generadas en los procesos de iniciacin y planificacin. Actualizar al menos una vez al mes el registro de las lecciones aprendidas del proyecto. Si lo considera necesario, el director de proyecto puede convocar a una reunin con el equipo de proyecto para identificar y discutir lecciones aprendidas. Se debe generar un mecanismo para la solicitud, revisin y aprobacin de cambios. Esta propuesta debe presentarse y aceptarse en la reunin de arranque del proyecto. Se debe generar un mecanismo que sea aceptado por todas las partes. Se debe establecer la informacin mnima que debe presentarse para poder revisar el cambio solicitado. El cambio solicitado debe indicar los impactos en tiempo, costo y alcance que produzca. Mantener constante comunicacin con el cliente y usuario final para mantener las Tcnicas y Herramientas Plantilla utilizada Anexo

SyC-01

Registro de lecciones aprendidas

2.

Juicio experto

ZFC.007

8.17

3.

1.

2.

ZFC.008 Revisin de documentos ZFC.009

SyC-02

Mecanismo para aprobacin de cambios

3.

8.18Error! No se encuentra el origen de la referencia.

4.

5.

SyC-03

Verificar alcance

1.

Inspeccin

Punch list

8.20

98

2.

3. 4. 5.

expectativas claras. Llevar un registro de todas las rdenes de cambio que hayan sido aprobadas y que afecten el alcance. Apoyar en las labores de inspeccin del proyecto. Solicitar al equipo de inspeccin el punch list del proyecto. Dar seguimiento al cierre de los puntos indicados en el punch list. Hacer un estudio detallado del cronograma establecido al inicio del proyecto. Crear un documento con la informacin ms relevante del proyecto. Revisar si es necesaria la adicin o eliminacin de algn nuevo riesgo. Previo a las reuniones de coordinacin del proyecto revisar el cronograma del proyecto. Aplicar el valor ganado para detectar cualquier atraso que pueda darse en el cronograma. Notificar al equipo de proyecto cualquier variacin del proyecto con respecto a la lnea base. Aportar soluciones a las variaciones que hayan en el cronograma. Analizar posibles escenarios de cara los atrasos que hayan con respecto al cronograma. Valorar la posibilidad de aplicar algunas de las soluciones planteadas y los impactos que esto pueda significar. Revisar todos los montos y plazos que han sido adjudicados y revisar en cada caso la forma de pago negociada. Generar un flujo de caja estimado del proyecto con los desembolsos que debern hacerse bisemanalmente. En cada avance aprobado, revisar si lo que se va pagar realmente es mayor, menor o igual a lo estimado. Con cada cambio aprobado, actualizar el flujo de si este cambio afecta el presupuesto del proyecto. Actualizar las plantillas de control de presupuesto

Juicio experto Punch list

1.

Anlisis del cronograma Microsoft Project. ZFC.010 8.21

SyC-04

Estudio del cronograma

2.

3.

1.

2.

Anlisis que pasa si Microsoft Project. Juicio experto Valor ganado -

3. SyC-05 Seguimiento del cronograma

4.

5.

6.

1.

2.

Flujo de caja -

SyC-06

Control de costos

3.

4.

5.

Comparacin de flujo de caja contra pagos reales.

99

1.

2. SyC-07 Informar sobre los costos 3.

El desempeo econmico del proyecto debe ser reflejado en los informes mensuales. Indicar los gastos a la fecha, las proyecciones presupuestarias y los impactos econmicos producto de los cambios aprobados. El informe se debe presentar por medio de los canales previamente establecidos en el proyecto. Identificar los contratos adjudicados relacionados al control de calidad. Velar por la aplicacin de las pruebas de calidad a las actividades designadas. Generar un registro de los informes que deben recibirse y la periodicidad que deben tener. Verificar que el equipo de inspeccin reciba y evale los informes presentados. Solicitar al equipo de inspeccin notificaciones en caso de que no se est cumpliendo con alguna de las mtricas establecidas. Identificar sin se ha producido algn incumplimiento con los parmetros de calidad establecidos. Determinar en conjunto con el equipo de proyecto la solucin ms efectiva y pronto para el incumplimiento que se est presentando. La solucin que se proponga debe afectar lo menos posible el alcance, costo y plazo del proyecto. Determinar de qu forma se va asumir la solucin propuesta y si se tiene que trasladar alguna responsabilidad. Si se debe generar una orden de cambio utilizar el mecanismo aprobado. Identificar los stakeholders a los cuales se les debe informar. Generar un informe para los interesados identificados con al menos la siguiente informacin: Descripcin escrita y visual del avance del proyecto.

Informes de rendimiento.

G.004 G.005

8.22

1.

2.

SyC-08

Gestionar el control de calidad

3.

Inspeccin.

ZFC.011

4.

Error! No se encuentra el origen de la referencia.

5.

1.

2.

SyC-09

Control de calidad

3.

Juicio experto.

ZFC.009

4.

5.

1. Informes de rendimiento de proyecto 2.

SyC-10

Informes de rendimiento semanales o mensuales

G.004 G.005 Error! No se encuentra el origen de la

100

3.

4.

5.

Rendimiento del cronograma. Registro de cambios solicitados y aprobados. Registro de riesgos. Incidencias sobre control de calidad. Generar los informes a los interesados de forma semanal a bisemanal. Crear un informe para control del departamento de ingeniera con una periodicidad mensual. El informe de ingeniera debe contener al menos lo siguiente: Descripcin escrita y visual del avance del proyecto. Rendimiento del cronograma. Rendimiento del presupuesto. Proyecciones presupuestarias. Registro de cambios solicitados y aprobados. Registro de riesgos. Incidencias sobre control de calidad. Registro de lecciones aprendidas. Actividades venideras del proyecto. Revisar semanalmente el registro de riesgos levantado al inicio del proyecto. Si se considera necesario este registro debe ser revisado y evaluado por el equipo de proyecto completo. Evaluar el estatus de los disparadores que fueron indicados y revisar si alguno tiene posibilidades de ocurrencia. Revisar los planes de respuesta establecidos. Se deben actualizar o desechar dependiendo de la evolucin que haya tenido el proyecto. Evaluar la efectividad de los planes de respuesta que hayan sido ejecutados. Buscar alternativas en caso de que el plan de respuesta aplicado no genere los resultados esperados. Si se debe generar una orden

referencia.

8.24

1.

2.

SyC-11

Seguimiento de riesgos

3.

Juicio experto.

ZFC.004

8.14

4.

1. Control de Riesgos

Juicio experto. ZFC.012 Negociacin con contratistas 8.25

SyC-12

2.

3.

101

4.

de cambio utilizar el mecanismo aprobado. Mantener informados a los interesados cualquier eventualidad que se presente. Mantener contacto peridico con el proveedor para estar atento a su forma de trabajar y sus resultados. Evaluar aspectos adicionales a los legalmente establecidos como su estructura organizativa, su tiempo de respuesta, calidad de servicio e inters mostrado a ZFC como cliente. Identificar las principales condiciones de contrato que deben ser seguidas. Generar un control peridico de la adquisicin realizada. Solicitar informes al proveedor del estatus de equipo o servicio contratado. En caso de eventualidades negativas, se debe actualizar el registro de riesgos del proyecto. Tener disponibles todos los documentos y plantillas del proyecto. Fijar un momento en la semana para actualizar todos los documentos que sean necesarios para reflejar los cambios y la evolucin que tuvo el proyecto.

1.

SyC-13

Seguimiento a proveedores

2.

Juicio experto.

1.

Revisiones peridicas Solicitud de informes. Juicio experto. ZFC.013 8.27

2. SyC-14 Administracin del contrato 3.

ZFC.004

8.14

4.

1. Actualizacin de documentos del proyecto

SyC-15

2.

Sistema de gestin de la configuracin

4.5. Grupos de Procesos de Cierre El cierre de los proyectos est basado en la finalizacin de todas las actividades del proyecto para formalmente completarlo (Project Management Institute, 2008). En este grupo de procesos se verifica que efectivamente todas las tareas hayan sido completadas apropiadamente y el producto haya sido entregado.

102

Existen dos tipos de cierre que pueden darse en un proyecto, estos pueden suceder tanto simultneamente como independientemente, dependiendo de las caractersticas propias de cada proyecto. El primero de ellos es el Cierre de proyecto, este es el que est descrito previamente. Dentro de las actividades que estn ligadas a este tipo de cierre se encuentran las siguientes: (Project Management Institute, 2008) Realizar las acciones necesarias para satisfacer los criterios de terminacin o de salida del proyecto. Realizar las actividades necesarias para transferir los productos, servicios o resultados del proyecto a la siguiente fase o proyecto. Realizar las acciones para recopilar los registros del proyecto o fase, auditar el xito o fracaso del proyecto, reunir las lecciones aprendidas y archivar la informacin del proyecto para su uso futuro por parte de la organizacin. Por otro lado tambin se puede presentar el cierre de las adquisiciones del proyecto. Bsicamente este proceso lo que busca es cerrar todos los contratos que el proyecto gener durante toda su vida, verificando que la totalidad del proyecto y los entregables cumplan con todos los criterios de aceptacin. Este tipo de cierre puede incluir actividades como la conciliacin de reclamaciones, la actualizacin de registros y el archivo de informacin de la adquisicin, dando de esta forma por concluida cualquier relacin comercial con el proveedor que fue adjudicado. Es importante que ambos cierres sean ejecutados adecuada y oportunamente para que el producto pueda continuar sin problemas en su siguiente fase. A continuacin se presentar la propuesta metodolgica para buscar que ambos tipos de cierre puedan ser llevados a cabo de forma adecuada.

103

4.5.1.

Entradas Iniciales

Al igual que el grupo de procesos anterior, para el cierre de los proyectos se requiere de algunas entradas que ya han sido descritas y ampliadas en el captulo 4.3.1. Las dems entradas necesarias, corresponden a salidas que se han generado de los grupos de procesos de Ejecucin, Seguimiento y Control.

4.5.2.

Propuesta Metodolgica

A continuacin se describir la metodologa propuesta para el cierre de los proyectos constructivos en ZFC. 4.5.2.1. Cierre de proyecto (C-01)

El director de proyectos debe cerciorarse de que todas las actividades han sido completadas y que se han cumplido con las especificaciones requeridas por el cliente o por el usuario final del producto. Se debe recibir de parte del equipo de inspeccin, todas las actas necesarias de que los entregables han sido aceptados y de que se ha verificado que el alcance corresponde con el esperado. Asimismo, se debe revisar que todos los resultados obtenidos producto del control de calidad ejercido, cumplen con los estndares que fueron establecidos desde el inicio. De igual manera el director de proyectos debe revisar tanto la memoria descriptiva del proyecto como el scope manual para verificar que se est cumpliendo con todo lo ofrecido al cliente y lo solicitado por l. Una vez que se tenga seguridad de que el proyecto ha sido completado, se deben hacer las respectivas actas de aceptacin formal del producto en las que quede registro de que el cliente o el interesado determinado reciben a satisfaccin el producto final que se ha generado. Es tambin necesario que se recopile toda la informacin del proyecto que debe ser traspasada para la etapa operativa del proyecto. Esta documentacin corresponde a todas las caractersticas o especificaciones de materiales, equipos

104

o acabados, de forma tal que se pueda realizar un mejor y ms fcil mantenimiento del producto final. Entre la documentacin que se debe adjuntar se encuentra: planos as built, especificaciones tcnicas de equipos y materiales instalados, garantas de equipos y materiales instalados, cdigos de materiales utilizados, modelos de equipos instalados e informacin de contacto de proveedores utilizados. La informacin citada anteriormente, debe entregarse con su respectiva acta de entrega, a las personas o el departamento correspondiente. En el caso de los documentos correspondientes al edificio, se deben entregar al departamento de operaciones de ZFC. Si se tratase de la remodelacin interna de la nave, la informacin debe entregarse al representante del cliente. 4.5.2.2. Cierre de documentacin (C-02)

Todos los documentos que se han ido actualizando a lo largo del proyecto, deben ser actualizados por ltima vez y dejar constancia de la forma en que el proyecto finaliz. Los registros de costos, de alcance, de calidad, de riesgos y de lecciones aprendidas, entre otros, deben ser completados y cerrados. Esta documentacin debe colocarse en el espacio virtual destinado para tal fin. 4.5.2.3. Reunin de cierre (C-03)

El jefe de ingeniera de ZFC, debe convocar a una reunin para evaluar los resultados obtenidos tras finalizar el proyecto. Esta se trata de una reunin corta y concisa en la que l, junto con el equipo de proyecto que fue asignado de parte de ZFC, pueda evaluar lo que se hizo, cmo se hizo y qu se obtuvo. Para esta reunin es necesario que ya estn completos todos los documentos del proyecto, de forma tal que se pueda revisar las variaciones que hubo en el alcance, cualquier sobrecosto o ahorro generado, los riesgos encontrados y que sucedieron y as como todas las lecciones aprendidas. Queda a discrecin del jefe

105

de ingeniera si a esta reunin convoca solo a los involucrados en el proyecto, o si por el contrario invita a todo el departamento de manera tal que sirva como retroalimentacin para los dems proyectos. 4.5.2.4. Informe final (C-04)

Se tiene que generar el informe final del proyecto, tanto el que es hecho para el cliente, como el que se realiza para ZFC. En este informe se debe incluir la misma informacin que en los dems, pero con los documentos actualizados al cierre del mismo. Igualmente, se debe incluir cualquier incidencia que se haya dado durante el proceso de cierre y que sea necesario que sea del conocimiento de los destinatarios finales de los informes. 4.5.2.5. Cierre de adquisiciones (C-05)

Una vez que el producto, material o servicio haya sido recibido y que la inspeccin indique que se encuentra a satisfaccin con respecto a lo solicitado, se puede proceder a realizar el cierre del proceso de compra. Se debe llevar un proceso similar al que se describi en los puntos anteriores ya que de la misma forma, se deben generar las respectivas actas de recepcin y aceptacin del producto que est siendo entregado. En este caso ZFC como comprador debe recibir el producto y a su vez debe generar el acta correspondiente para entregrselo al cliente. Aunque la inspeccin pueda estar satisfecha con el alcance obtenido, el director de proyectos debe evaluar las circunstancias finales en las que el producto fue entregado y si se ajustan a las condiciones que fueron establecidas inicialmente. Esto por cuanto si se dieron atrasos en la entrega o se gener algn procedimiento incorrecto, se puede evaluar la posibilidad de que se apliquen multas al oferente que fue seleccionado. Esta decisin recaer en el director de proyecto y bajo la aprobacin del jefe de ingeniera y de los interesados que l considere necesarios.

106

4.5.2.6.

Evaluacin final de proveedor (C-06)

Se debe realizar una evaluacin final del proveedor con el fin de evaluar de forma objetiva, si cumpli con todas las expectativas con las cuales fue contratado al inicio. Como se vio en el punto 4.4.2.13, no se debe ver si el proveedor al final entreg el producto que se solicitaba, sino tambin evaluar cmo fue su comportamiento a lo largo del proceso de compra, si tuvo buenos tiempos de respuesta y si se trata de una empresa con buen respaldo. En el anexo 8.27 puede encontrarse una plantilla propuesta para la evaluacin final de los contratistas adjudicados. Toda esta informacin es importante de cara a procesos de compra futuros, ya que del anlisis que se realice, el jefe de ingeniera puede eliminar alguna empresa de la lista de vendedores calificados (4.3.1.15), de manera tal que no vaya a ser tomada en cuenta para licitaciones futuras.

4.5.3.

Resumen de Metodologa de Cierre

En el cuadro 4.4, se presenta un resumen de la metodologa propuesta para el grupo de procesos de Cierre. En este cuadro se detallan los procedimientos, herramientas y las plantillas asociadas a cada proceso.
Cuadro 4.4. Resumen de metodologa de cierre
Cdigo Proceso 1. Procedimiento Revisar que todas las caractersticas descritas en la memoria descriptiva, el scope manual y al Project Charter hayan sido cumplidas. Asegurarse que todas las actividades asociadas al proyecto hayan sido completadas y estn a satisfaccin de los interesados. Solicitar al equipo de inspeccin todas las actas de recepcin necesarias de cada uno de los Tcnicas y Herramientas Plantilla utilizada Anexo

C-01

Cierre de proyecto

2.

Inspeccin

3.

107

4.

5.

6.

7.

8.

entregables del proyecto. Solicitar al equipo de inspeccin una notificacin de que el proyecto cumple con el alcance establecido. Asegurarse que todos los resultados obtenidos del proceso de control de calidad estn dentro de las mtricas establecidas. Generar las actas de aceptacin formal del producto una vez se haya asegurado que el proyecto ha sido completado. Recopilar la informacin del proyecto que debe ser traspasada para la etapa operativa del proyecto. Identificar a quien se le debe hacer entrega de estos documentos. Si se trata de un proyecto tipo Shell, la informacin se debe entregar al departamento de operaciones de ZFC. Si corresponde a un proyecto de Mejoras, se debe entregar al representante del cliente. Actualizar por ltima vez los documentos de proyecto. esta ltima versin debe reflejar el estado real en que finaliz el proyecto. Colocar los documentos en el espacio virtual dedicado para tal fin. Convocar a una reunin con el equipo de ZFC asignado al proyecto, para evaluar los resultados obtenidos. Todos los documentos de proyecto deben estar actualizados y cerrados de tal manera que sean un input para el desarrollo de la reunin. Revisar las principales variaciones que tuvo el proyecto con respecto a la lnea base. Es criterio del Jefe de Ingeniera, si convoca a todo el departamento o si solo se rene con el equipo asignado al proyecto. Generar un informe final para los interesados del proyecto, presentando la informacin de cierre y notificando la finalizacin formal del proyecto. Generar el informe final para el control interno de ZFC. De la misma forma se debe presentar

1. Cierre de documentacin 2.

C-02

Plataforma virtual de informacin

1.

2.

C-03

Reunin de cierre 3.

Reunin

4.

1.

G.004 Informes de rendimiento G.005 8.22

C-04

Informe final 2.

108

3.

toda la informacin actualizada al cierre del proyecto. Cualquier aspecto adicional que sea considerado importante con relacin al proyecto debe ser indicado. Asegurarse que el producto o servicio contratado est a completa satisfaccin de la inspeccin y del cliente final. Solicitar al equipo de inspeccin el acta de recepcin del equipo o servicio entregado por el proveedor. Solicitar al equipo de inspeccin una notificacin de que el producto o servicio cumple con el alcance establecido Generar las actas de aceptacin formal del producto o servicio una vez se haya asegurado que se cumple el alcance licitado. Recopilar la informacin del producto o servicio que debe ser traspasada para la etapa operativa del proyecto. Identificar a quien se le debe hacer entrega de estos documentos. Si se trata de un proyecto tipo Shell, la informacin se debe entregar al departamento de operaciones de ZFC. Si corresponde a un proyecto de Mejoras, se debe entregar al representante del cliente. Evaluar las circunstancias finales en las que el producto fue entregado ms all si se cumpli o no con el alcance. Evaluar objetivamente si el proveedor cumpli con las expectativas contratadas. Evaluar no solo las variables contratadas como costo y alcance, sino tambin aspectos de cultura organizacional del proveedor. Con base a los resultados de la evaluacin, actualizar la lista de vendedores calificados si fuese necesario.

1.

2.

3.

4.

C-05

Cierre de adquisiciones

5.

Inspeccin

6.

7.

1.

2. C-06 Evaluacin final de proveedor 3.

Anlisis multicriterio

ZFC.014

8.27

109

Como puede verse, la propuesta descrita previamente lo que busca es plantear una serie de acciones y medidas a tomar dentro de la organizacin, para incrementar la eficiencia de la administracin de los proyectos dentro de Zona Franca Coyol. Se busc que fuesen iniciativas sencillas de realizar pero que generaran un impacto muy positivo en los proyectos. No se desea que las medidas lleguen a generar un proceso burocrtico grande dentro de los proyectos, por eso para cada caso en particular debe analizarse qu procedimiento aplican y cules deben ser modificados para adecuarse mejor a la realidad del proyecto. Adicionalmente en el anexo 8.28, se encuentra una gua de la metodologa planteada. En esta se estn indicando los documentos que deben solicitarse, las acciones que deben tomarse y los documentos que deben generarse en antes, durante y al cierre del proyecto. Con esta herramienta se busca proveer de una forma ms sencilla y prctica de revisar lo que debe hacerse en el da a da.

4.6. Validacin de Propuesta Metodolgica Con el fin de poder generar una comprobacin de la propuesta que se ha planteado en este PFG, se procedi a poner en prctica dentro de la organizacin de ZFC, esta metodologa. Si bien es cierto el instrumento que se propone abarca actividades para los procesos de ejecucin, seguimiento, control y cierre de los proyectos de la empresa, la validacin completa de la herramienta es un aspecto difcil de lograr debido a las propias caractersticas con que cuentan los proyectos que se desarrollan en esta zona franca. La mayora de los proyectos tienen un plazo tal que no permite que la herramienta pueda ser probada dentro de la duracin del desarrollo de este PFG. Es por ello que se procedi a realizar una validacin parcial de la metodologa,

110

aplicando la propuesta para el cierre de uno de los proyectos de infraestructura que se ejecut durante los meses previos a la realizacin de este trabajo de graduacin. El proyecto consista en el cambio de cable de toda la red de cobre del parque. Si bien es cierto este proyecto era de menor magnitud que los principales proyectos que maneja el parque, la aplicabilidad de la herramienta era la misma, adems de que por sus caractersticas, se trataba de un proyecto que contaba con un alto grado de especializacin. Al ingeniero encargado de la administracin del proyecto, se le entreg el resumen de la metodologa que se presenta en el anexo 8.28, as como la tabla con el resumen de procedimiento y herramientas para el cierre. A continuacin se presentarn las valoraciones aportadas por l a cada uno de los procesos recomendados.

Cuadro 4.5. Resultados de validacin de metodologa

Cdigo Proceso Observaciones En este caso no se gener el Project charter. Si bien es cierto no es un documento que se genere comnmente dentro de la organizacin, es importante que se haga, sobretodo en un proyecto como este donde el grado tcnico es muy alto. Inclusive para estos casos se puede crear el Project charter en conjunto con todo el equipo de proyecto que tiene un conocimiento tcnico ms amplio que el director de proyecto. Se pudo solicitar a la inspeccin la notificacin oficial de que el alcance del proyecto establecido fue cumplido. C-01 Cierre de proyecto Fue posible generar el acta de recepcin del proyecto. No se hizo un acta para cada entregable, pero s se hizo para el producto final completo del proyecto. En este caso es ms prctica una sola acta de entrega por el proyecto que hacer una por cada entregable debido a que era un proyecto pequeo. Entre ms grande sea el proyecto s se pueden realizar actas de entrega por cada entregable. Como en la mayora de los proyectos de la zona franca, la documentacin necesaria fue solicitada y se traspas en este caso al cliente final C-02 Cierre de documentacin Se actualiz el control de presupuestos al final del proyecto. Este es el nico documento que se manejaba que estuviera sujeto a

111

actualizacin. No haba registro de riesgos ni de lecciones aprendidas, sin embargo s lo considera necesario para todos los proyectos que se efecten dentro de la organizacin. En proyectos tan especializados como este estos dos documentos son de gran importancia ya que no son proyectos repetitivos por lo que las enseanzas que dejan son poco comunes. Se tuvo una reunin de cierre de proyecto pero con todo el equipo de trabajo, para cerrar cualquier detalle que estuviera pendiente. C-03 Reunin de cierre La reunin con el jefe de ingeniera no se efectu. Esta reunin puede ser difcil que se pueda realizar, pero s es recomendable generar al menos una vez al mes una reunin con todo el equipo de ingeniera de forma tal que las experiencias se puedan compartir entre los miembros del departamento. Se present el informe final con los datos de cierre del proyecto. Este tipo de informes ya son presentados dentro de la organizacin para todos los proyectos. En este caso no se realizaron adquisiciones importantes durante el proyecto. Se realiz una evaluacin de la empresa subcontratada para el proyecto. La herramienta de evaluacin es vlida y de gran aplicabilidad para tener un criterio objetivo del rendimiento que tuvo el subcontratista. Sin embargo, se considera que no es necesario actualizar o tener una lista de proveedores calificados ya que a nivel de personal la empresa no es muy grande, por lo que en caso de que se necesite algn proveedor se puede obtener fcilmente retroalimentacin sin necesidad de recurrir a una lista.

C-04

Informe final

C-05

Cierre de adquisiciones

C-06

Evaluacin final de proveedor

El ingeniero consultado considera que el cierre es precisamente uno de los aspectos que ms cuesta en los proyectos que se realizan en la zona franca. Segn indica en muchos casos es por muchos detalles que el cliente solicita lo que vuelve esta situacin complicada. Teniendo al menos un lineamiento bsico del cierre, no necesariamente vaya a acelerar el proceso de cierre de un proyecto, porque igualmente se depende de varios factores externos, pero al menos puede orientar mejor al ingeniero de las actividades que tiene que asegurarse por realizar. De forma general, el ingeniero que aport su evaluacin a la herramienta para el cierre de los proyectos considera que la propuesta metodolgica puede aportar

112

un orden a la hora de trabajar los proyectos en la zona franca, sin embargo puede haber procesos que sean difciles de poner en prctica en el da a da. Sin embargo, considera que idealmente se tiene que promover que la herramienta del PMBOK (Project Management Institute, 2008) se aplique en toda la extensin posible dentro de la organizacin, ya que ese es el norte que se le quiere dar a la forma de trabajo dentro de la empresa. Partiendo de esto la metodologa propuesta puede ser un primer paso que ayude a estandarizar muchas de las labores del departamento de ingeniera. En la medida que este tipo de acciones se vayan tomando, puede que algunas actividades requieran de ms tiempo y de un costo administrativo ms alto, pero considera que en contraposicin esto puede provocar proyectos ms exitosos y rentables. Segn argumenta la definicin de alcance es en algunos casos el principal problema porque algunas veces los proyectos se inician sin tener un alcance completamente definido, por lo que precisamente la definicin y la generacin de documentos como el Project charter pueden ayudar a que esto quede definido. Asimismo seala que aspectos como riesgos, lecciones aprendidas, recursos humanos y administracin de contratos son aspectos que tienen opcin de mejorar y para los que el aporte de esta herramienta puede ser valioso. Es importante tener en cuenta que lo que se present por medio de este PFG es una propuesta metodolgica que busc ajustarse a la realidad del tipo y calidad de trabajo que se realiza en el departamento de ingeniera de la zona franca. Por esta misma razn, como propuesta que es, est abierta a mejora y actualizacin por parte de los integrantes de la organizacin que vayan a usarla. No se pretende por ningn motivo imponer una forma de trabajo rgida a los trabajadores, sino establecer un mecanismo que sirva de gua para facilitar la

113

administracin de los proyectos y potenciar los resultados positivos que se pueden obtener con cada proyecto. La herramienta como tal debe estar sujeta a una constante evaluacin y actualizacin por parte del departamento de ingeniera. Tanto los procedimientos como las plantillas propuestas pueden cambiar en procura de ajustarse an mejor a la empresa.

114

5. CONCLUSIONES

1. Se concluye que la estructura organizacional que tiene ZFC, permite decir que se trata de una empresa orientada a proyectos. Sin embargo no se puede asegurar que se trata de una PMO que se encuentre establecida. El departamento de ingeniera cuenta con muchas caractersticas que se pueden asociar y comparar al de una PMO, sin embargo no se desenvuelve como tal.

2. Zona Franca Coyol es una empresa madura y que cuenta con una amplia experiencia en la administracin de proyectos de construccin, ya que su equipo de trabajo ha participado en el desarrollo de otras zonas francas en aos anteriores. Esa experiencia le permite finalizar proyectos de forma satisfactoria, sin embargo el trabajo no siempre se realiza de forma consistente y ordenada ocasionando que no siempre se logre terminar los proyectos de formas similares.

3. Es posible concluir que la forma en que se administra cada proyecto depende de cmo cada director de proyectos asignado asuma el trabajo. A pesar de que los dos ingenieros senior cuentan con experiencia suficiente para realizar un buen trabajo, cada uno aplica o no procesos de forma subjetiva, de acuerdo con lo que cada uno considere mejor. No existe una estandarizacin del trabajo como tal, lo que provoca que proyectos similares terminen con resultados completamente dismiles.

4. De la investigacin realizada se puede inferir que dentro de la organizacin se tiene un conocimiento amplio sobre lo que son los estndares que establece y propicia el PMI. El equipo de ingeniera ha recibido capacitacin en el tema de la administracin de proyectos. De ah que muchas de las

115

prcticas que son recomendadas en el PMBOK son de conocimiento general.

5. Durante el desarrollo de los proyectos, hay procesos del PMBOK que son aplicados por los directores de proyecto pero de manera informal o no de la forma ms adecuada. Un caso concreto de esta situacin son los riesgos, esto porque se sabe que estn y muchas veces se identifican, pero no siempre se preparan conscientemente para atacarlos.

6. Se concluye que en muchas ocasiones durante la administracin de un proyecto el conocimiento o la nocin bsica de una herramienta o procedimiento estn presentes, sin embargo no es desarrollado de las formas ms correctas, propiciando que no se obtengan los resultados que deben tenerse afectando el proyecto.

7. La metodologa que fue planteada en este documento, nace como complemento a la realidad expresada por los ingenieros de la organizacin, es por ello que est ajustada a la situacin actual que se desarrolla en la oficina de proyectos de ZFC.

8. La herramienta propuesta es un documento estndar, por lo que no est confeccionada para un proyecto en especfico.

9. La propuesta metodolgica est creada con el fin de que pueda ser aplicada en todos los proyectos que se desarrollen en la zona franca Sin embargo no puede utilizarse de la misma manera a todos los proyectos que sean desarrollados dentro de la zona franca. Existen distintos tipos de proyecto que son ejecutados as como cada uno va a responder a distintos tipos de necesidades de parte del cliente ocasionando que en cada caso el proyecto tenga que variar en la forma que debe ser administrado.

116

10. Se puede concluir que la propuesta metodolgica principalmente lo que busca es organizar la forma en que se trabaja y estandarizar ciertas actividades de forma tal que sean constantes en todos los proyectos sin importar el tipo, magnitud o el profesional que se encuentre a cargo de l.

11. La metodologa no es para sustituir completamente lo que se realiza actualmente en ZFC, por el contrario lo que busca es ser un complemento para lograr una normalizacin en la administracin que se lleva a cabo en los proyectos de construccin.

12. La propuesta metodolgica que se est planteando nicamente contempla los grupos de procesos de ejecucin, seguimiento, control y cierre. Lo que pretende es ser una gua para los profesionales de la organizacin para que se puedan asumir todos los proyectos de una forma ms ordenada y estandarizada, de forma tal que en todos los proyectos se tenga una base comn mnima de acciones a realizar para buscar garantizar el xito.

13. La metodologa propuesta parte de la necesidad de una serie de entradas iniciales. Algunas de ellas ya son creadas dentro de la organizacin y otras tienen que empezar a generarse en procura de un mejor ordenamiento de los proyectos.

14. Del documento se puede concluir que existen algunas entradas recomendados por el PMI que para el caso de esta herramienta se consideraron como no obligatorios.

15. El producto final de este PFG est basado en las recomendaciones tericas que se encuentran descritas en el PMBOK. Sin embargo, la propuesta resultante se plantea producto de una adecuacin de estas directrices a la realidad propia de la organizacin. Se busc en todo momento moldear las

117

buenas prcticas recomendadas por el PMI al tipo de proyectos que se generan en ZFC y no viceversa.

16. Esta herramienta propuesta busca estandarizar la informacin mnima que se reporta en los proyectos y con periodicidades similares. De esta forma se propicia que la informacin ms relevante siempre est actualizada y al alcance de los interesados.

17. Es posible concluir que si bien es cierto el Project Charter es quizs de los documentos ms importantes que debe tener todo proyecto, actualmente no se ha establecido como norma su confeccin. Sin embargo s se est empezando a hacer un esfuerzo por implementarse dentro de todos los proyectos de la zona franca.

18. Las tablas de resumen de las metodologas pretenden orientar a los profesionales que busquen aplicar la metodologa de forma tal que tengan a mano cul es el procedimiento que debe seguirse, de qu forma puede hacerse y si existe una plantilla que pueda utilizarse para realizar el trabajo indicado.

19. La herramienta como propuesta metodolgica es funcional y puede proveer un gran aporte a la organizacin, sin embargo debe tenerse presente que se tiene que pasar por un proceso de formacin de cultura para que puede tener una ptima eficiencia y resultados ms palpables.

118

6. RECOMENDACIONES

1. Se recomienda que antes de iniciar cada proyecto se revise que todas las actividades indicadas en la metodologa realmente apliquen para el proyecto en cuestin porque de lo contrario se pueden generar resultados adversos propiciando ms burocracia de la cuenta para proyectos que no lo ameritan.

2. La creacin de una plataforma virtual para el manejo de informacin es un aspecto recomendable ya que va facilitar no solo la distribucin sino la obtencin de informacin de los proyectos. Esto es un aspecto vital en el desarrollo de un proyecto ya que puede disminuir tiempos de espera y promover la solucin de problemas de forma ms expedita.

3. Es recomendable que se busque mediante un proyecto interno de la organizacin u otro PFG como este, que se desarrolle una propuesta metodolgica similar a esta pero para los grupos de procesos de inicio y planificacin. Este documento debe generar todas las salidas necesarias y mnimas que alimenten la propuesta que se est planteando, por lo que se debe realizar igualmente de acuerdo a la realidad de ZFC y en apego a lo que fue planteado en esta propuesta.

4. Se recomiendan que se identifiquen y se listen los factores ambientales de la empresa y los activos de los procesos de la organizacin. Esta informacin debe de ponerse al alcance del departamento de ingeniera y debe ser analizados por ellos para que se tomen en cuenta durante la planificacin y ejecucin de los proyectos.

5. Es importante que para cada proyecto sean creados los planes de gestin de: requisitos, alcance, cronograma, costos, calidad, comunicaciones,

119

riesgos y adquisiciones. Estos documentos van a preparar mejor al director de proyecto y su equipo de cara al desarrollo del proyecto.

6. Se recomienda que todas las recomendaciones que se dejaron planteadas, deben ser revisadas al menos una vez al ao para validar su utilidad o actualizar el procedimiento.

7. Es recomendable que la utilizacin de la herramienta se haga de parte de todos los profesionales del equipo de ingeniera de la organizacin, esto a su vez va contribuir a que se pueda generar retroalimentacin valiosa que pueda ser aplicada en actualizaciones posteriores.

8. Antes de empezar a utilizar la herramienta propuesta, se debe reunir al equipo de trabajo y explicar la razn de su uso, la importancia y los resultados que se esperan obtener al aplicarse. Esta tarea de

concientizacin y de conocimiento de la metodologa, ayudar a que se vuelva ms fcil su aplicacin. Es necesario que tambin se involucre a todas aquellas personas que se puedan ver involucradas en el proceso, para que tengan plena conciencia de los cambios que puedan darse.

9. Antes de iniciar cualquier proyecto, el director asignado debe revisar la metodologa actualizada y vigente en ese momento y con su juicio experto determinar qu aspectos s aplican y cules no, de manera tal que no se efecten actividades que carezcan de valor para el proyecto.

10. Las plantillas que se desarrollaron para su uso durante el proyecto, constituyen una recomendacin para facilitar la aplicacin de la metodologa que se plantea. El formato que tienen puede ser modificado para que sea ajustado a cualquier estndar que tenga la empresa, sin embargo esa es la informacin mnima que deben contener. Si el departamento de ingeniera considera importante agregar variables a completar, esto se puede realizar

120

bajo la aprobacin del Jefe de Ingeniera, actualizndose el documento y siendo de aplicacin por igual para todo el departamento.

11. Es recomendable mantener en constante capacitacin a los ingenieros de la organizacin en temas relacionados con la administracin de proyectos. Si bien es cierto esto es un hecho que en la actualidad se cuida, no se debe desistir de mantener a los profesionales actualizados en esta materia. Esto va permitir que desde lo interno del departamento pueda surgir nueva retroalimentacin de forma tal que se mejoren los procesos que se realizan y se actualice y ample igualmente la propuesta metodolgica que se est presentando.

12. Se recomienda que dentro de la organizacin se haga una escala de magnitud para poder calificar todos los proyectos que sean llevados a cabo. La escala puede utilizar los montos de los presupuestos aprobados, el plazo o alguna otra medida cuantitativa como mtrica para poder clasificar los proyectos y junto con esto establecer el nivel de importancia y urgencia que se tengan asociados.

13. Se debe establecer una directriz para indicar a partir de cual magnitud de proyecto se debe aplicar la metodologa para la administracin de proyectos vigente. Esto va evitar que proyectos pequeos tengan que pasar por el mismo proceso, pudiendo generar ms bien que el avance del proyecto pueda ser disminuido.

14. Se debe hacer una valoracin de la metodologa propuesta para los grupos de procesos de ejecucin, seguimiento y control. En este PFG no pudieron ser validados estos procesos, por lo que dentro de la organizacin se debe realizar una valoracin de la propuesta que se est haciendo y ver si algn cambio es necesario.

121

7. BIBLIOGRAFA

Cadence Management Corporation. (2009). Curso Maestro en el Enfoque Multidisciplianrio para la Planificacin e Implementacin de Proyectos. Direccin de Proyectos (pgs. 2-4). San Jose: Cadence Management Corporation.

Chamoun, Y. (2002). Administracin Profesional de Proyectos: La Gua. D.F., Mxico: McGraw-Hill Interamericana.

Fernndez, M. F. (2009). Curso Gestin de los Riesgos del Proyecto. MAP75, UCI, (pg. 18). San Jos, Costa Rica.

Gido, J., & Clements, J. P. (2007). Administarcin Exitosa de Proyectos 3a. edicin. D.F., Mxico: Cengage Learning Editores S.A,.

Google. (2010). Google Apps. Recuperado el 10 de Agosto de 2010, de http://www.google.com/apps/intl/es/business/index.html

Heldman, K. (2002). PMP Project Management Professional Study Guide. Alameda, California, USA.: Sybex Inc.

Microsoft Corporation. (2010). Microsoft Share Point 2010. Recuperado el 10 de Agosto de 2010, de http://sharepoint.microsoft.com

Microsoft. (2010). Office Online. Recuperado el 14 de Mayo de 2010, de http://office.microsoft.com/es-mx/project/HA011353423082.aspx

Nieva Lpez, A. (05 de Enero de 2009). Noticias.com. Recuperado el 14 de Mayo de 2010, de http://www.noticias.com/gestion-tecnologia-ingenieriaevolucion-infraestructuras-telecomunicaciones-tn2.2702

Ocampo Smano, J. E. (2005). Costos y Evaluacin de Proyectos. D.F., Mxico: Grupo Patria Cultural S.A.

122

Prince2. (2010). Prince2. Recuperado el 15 de Mayo de 2010, de http://www.prince2.com/

Project Management Institute. (2008). Project Management Body of Knowledge (PMBOK Guide). Newton Square, Pennsylvania, USA.: Project Management Institute.

Project Management Institute. (2010). Project Management Institute. Recuperado el 16 de Mayo de 2010, de http://www.pmi.org/AboutUs/Pages/FactSheet.aspx

Pueblo en lnea. (13 de Enero de 2010). Pueblo en lnea. Recuperado el 14 de Mayo de 2010, de http://spanish.peopledaily.com.cn/31617/6867555.html

Salas, C. X. (2010). Curso Implementacin, Control y Cierre. MAP75, UCI, (pg. 14). San Jos, Costa Rica.

Scribd. (2010). Scribd. Recuperado el 13 de Mayo de 2010, de http://www.scribd.com/doc/24166418/MANUAL-PRINCE-2-MetodologiaGestion-de-Proyectos

Worl Wide Quality Services. (2010). Worl Wide Quality Services. Recuperado el 16 de Mayo de 2010, de http://www.wwqs.net/noticias.php?id=11

Zona Franca Coyol. (2009). Zona Franca Coyol. Recuperado el 14 de Mayo de 2010, de http://www.coyolfz.com/

123

8. ANEXOS
8.1. Chrter del proyecto

124

125

8.2. Estructura Detallada de Trabajo del PFG Parte 1/3

126

Parte 2/3

127

Parte 3/3

128

8.3. Cronograma del proyecto Parte 1/2

Id 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 N om bre de tarea Duracin C om ienzo Fin Predeces oras 1

PROPUESTA METODOLGICA
INICIO PFG Propuesta PFG aprobada Inicio Propues ta PFG Prim era entrega D efinir propuestas de PFG Evaluar propues tas de PFG Seleccionar PFG Generar C harter de PFG Generar EDT de PFG Generar cronograma de PFG Entregar de documentos Segunda entrega R ealizar correcciones de 1era entrega Generar introduccin Generar Marco Terico Entregar de documentos Tercera entrega R ealizar correcciones 2nd entrega Generar Marco m etodolgico Generar es quem a de resultados Entregar de documentos Cuarta entrega R ealizar correcciones 3era entrega Generar R es umen ejecutivo Entregar de documentos Docum ento final R ealizar correcciones 4ta enterga Integrar de documento Entregar documento R evisar documento Aprobar documento Firm a de acta Asignacin Director de PFG R evisar de lis ta profesores dis ponibles Enviar s olicitudes a profes ores D es ignar D irector de PFG Cierre Propuesta PFG Metodologa actual de Ejecucin revisada Revisar as eguramiento de calidad actual Analizar resultados de revis in Propuesta metodolgica: Ejecucin Mejoras propues tas para ejecucin Integrar anlis is previos Entregar documento EJEC UC IN Metodologa actual de CyS revisada Revisar control de cronograma actual Revisar control de costos actual Revisar control de calidad actual Revisar CyS de ries gos actual Analizar resultados de revis iones

196 da s
0 das 42,75 das 0 das 7 das 1 da 2 das 0 das 1,5 das 1,5 das 1 da 0 das 7 das 2 das 3 das 4 das 0 das 7 das 2 das 5 das 2 das 0 das 4 das 2 das 4 das 0 das 8 das 1 da 1 da 2 das 4 das 0 das 0 das 40 das 10 das 20 das 10 das 0 das 20 das 10 das 10 das 11 das 8 das 3 das 0 das 29 das 5 das 5 das 5 das 5 das 15 das

lun 03/05/10
lun 03/05/10 lun 03/05/10 lun 03/05/10 lun 03/05/10 lun 03/05/10 mar 04/05/10 mi 05/05/1 jue 06/05/10 vie 07/05/10 dom 09/05/1 dom 09/05/1 lun 10/05/10 mi 12/05/1 lun 10/05/10 jue 13/05/10 dom 16/05/1 mar 18/05/10 jue 20/05/10 mar 18/05/10 dom 23/05/1 lun 24/05/10 mi 26/05/10 jue 27/05/10 mi 26/05/1 dom 30/05/1 mar 01/06/10 mar 01/06/10 mi 02/06/1 jue 03/06/10 s b 05/06/10 mar 08/06/10 vie 11/06/10 lun 03/05/10 lun 03/05/10 mi 12/05/1 dom 30/05/1 vie 11/06/10 lun 03/05/10 lun 03/05/10 mi 12/05/1 vie 21/05/10 vie 21/05/10 vie 28/05/10 dom 30/05/1 lun 31/05/10 lun 31/05/10 jue 03/06/10 dom 06/06/1 mar 08/06/10 dom 13/06/1

vie 29/10/10
lun 03/05/10 vie 11/06/10 lun 03/05/10 2 dom 09/05/10 lun 03/05/10 4 mi 05/05/1 6 mi 05/05/1 7 vie 07/05/108 s b 08/05/109 dom 09/05/1 10 dom 09/05/1 11 dom 16/05/10 vie 14/05/1012FC+3 das jue 13/05/10 12FC+1 da dom 16/05/1 15 dom 16/05/1 16;14 lun 24/05/10 s b 22/05/1017FC+4 das dom 23/05/1 17FC+2 das lun 24/05/10 20 lun 24/05/10 21;19 dom 30/05/10 s b 29/05/1022FC+3 das dom 30/05/1 22FC+2 das dom 30/05/1 25;24 mar 08/06/10 mar 01/06/10 26FC+2 das mi 02/06/1 28 vie 04/06/1029 mar 08/06/10 30 mar 08/06/10 31 vie 11/06/1032 mar 08/06/10 mi 12/05/1 4 dom 30/05/1 35 mar 08/06/10 36 vie 11/06/1033;37 vie 21/05/10 mi 12/05/1 vie 21/05/1040 dom 30/05/10 vie 28/05/1041 dom 30/05/1 43 dom 30/05/1 44 sb 26/06/10 vie 04/06/1045 lun 07/06/10 47FC-2 das jue 10/06/10 48FC-2 das dom 13/06/1 49FC-2 das s b 26/06/1050

129

Parte 2/2
52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 Propuesta metodolgica: Control y Seguim iento Mejoras propues tas para C yS Integrar anlis is previos Entregar documento CONTROL Y SEGUIMIEN Metodologa actual de Cierre revisada R evisar cierre de proyectos actual Analizar resultados de revis in Propuesta metodolgica: Cierre Mejoras propues tas para C ierre Integrar anlis is previos Entregar documento CIERR E Reuniones de seguimiento con Director de PFG Asignacin de lecctores R evisar lis ta de profesores dis ponibles Evaluar candidatos Pres entar candidatos a Director de PFG Propuesta validada Inicio Validacin PFG en ZFC Metodologa de Ejecucin validada R evisar propues ta m etodolgica Generar cambios a propuesta R evisar cambios propuestos Implem entar cam bios propues tos Entregar documento EJEC UC IN REVISA Metodologa de CyS validada R evisiar propues ta metodolgica Generar cambios a propuesta R evisar cambios propuestos Implem entar cam bios propues tos Entregar documento CONTROL Y SEGU I Metodologa de Cierre validada R evisar propues ta m etodolgica Generar cambios a propuesta R evisar cambios propuestos Implem entar cam bios propues tos Entregar documento CIERR E REVISADO C ierre Validacin PFG en ZFC Docum ento final PFG Integrar secciones de trabajo R evisar prelim inarm ente el documento Verificar formato Entregar PFG PFG cerrado Inicio C ierre PFG Asignar lectores R evisar documento (Director) R ealizar correcciones de D irector R evisar documento (Lectores ) R ealizar correcciones de Lectores Aprobacin final PFG Defensa virtual PFG C ierre Cierre PFG 13 das 10 das 3 das 0 das 10 das 5 das 5 das 13 das 10 das 3 das 0 das 110 das 7 das 3 das 4 das 0 das 102 das 0 das 37 das 5 das 5 das 7 das 20 das 0 das 43 das 10 das 5 das 8 das 20 das 0 das 37 das 5 das 5 das 7 das 20 das 0 das 0 das 17 das 9 das 5 das 3 das 0 das 56 das 0 das 10 das 10 das 5 das 15 das 5 das 8 das 0 das 0 das sb 26/06/10 s b 26/06/10 lun 05/07/10 jue 08/07/10 jue 08/07/10 jue 08/07/10 lun 12/07/10 sb 17/07/10 s b 17/07/10 lun 26/07/10 mi 28/07/1 mar 08/06/10 mi 01/09/10 mi 01/09/1 s b 04/09/10 mar 07/09/10 dom 30/05/10 dom 30/05/1 lun 31/05/10 lun 31/05/10 s b 05/06/10 mi 09/06/1 mar 15/06/10 s b 03/07/10 jue 08/07/10 jue 08/07/10 s b 17/07/10 mi 21/07/1 jue 29/07/10 lun 16/08/10 jue 29/07/10 jue 29/07/10 mar 03/08/10 dom 08/08/1 s b 14/08/10 mi 01/09/1 mi 01/09/1 mi 01/09/10 mi 01/09/1 jue 09/09/10 lun 13/09/10 vie 17/09/10 mar 07/09/10 mar 07/09/10 vie 17/09/10 vie 17/09/10 dom 26/09/1 vie 01/10/10 jue 14/10/10 mar 19/10/10 vie 29/10/10 vie 29/10/10 jue 08/07/10 lun 05/07/10 51 jue 08/07/10 53 jue 08/07/10 54 sb 17/07/10 lun 12/07/10 55 s b 17/07/1057 mi 28/07/10 dom 25/07/1 58 mi 28/07/1 60 mi 28/07/1 61 vie 17/09/1037 mar 07/09/10 s b 04/09/1090C C mar 07/09/10 65 mar 07/09/10 66 mi 01/09/10 dom 30/05/1 45 sb 03/07/10 vie 04/06/1069;45 mi 09/06/1 71 mar 15/06/10 72 s b 03/07/1073 s b 03/07/1074 lun 16/08/10 s b 17/07/1055 mi 21/07/1 77 mi 28/07/1 78 lun 16/08/10 79 lun 16/08/10 80 mi 01/09/10 mar 03/08/10 62 dom 08/08/1 83 s b 14/08/1084 mi 01/09/1 85 mi 01/09/1 86 mi 01/09/1 75;81;87 vie 17/09/10 jue 09/09/10 75;81;87 lun 13/09/10 90 vie 17/09/1091 vie 17/09/1092;63 vie 29/10/10 mar 07/09/10 67;88 dom 26/09/1 95;67;93 dom 26/09/1 93 vie 01/10/1097 jue 14/10/10 96;98 lun 18/10/10 99 mar 26/10/10 100 vie 29/10/10101FC+3 das vie 29/10/10102

130

8.4. Cuestionario Grupo de Procesos de Ejecucin Por favor responder las siguientes preguntas de acuerdo a lo que ha sido su experiencia en la administracin de proyectos de construccin en esta empresa. Este cuestionario no pretende evaluar su conocimiento o labor realizada, sino por el contrario conocer la realidad laboral, por lo que se agradece que se responda con sinceridad y a ttulo personal. El alcance de todas lasrespuestas debeestar supeditado al departamento deingenieradeZonaFrancaCoyol.
1. Busca prepararse de alguna forma antes de que comience con un nuevo 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.

proyecto?(SilarespuestaesNO,pasealapregunta#4). Quactividadesrealizaantesdeiniciarconlaejecucindeunproyecto? Qudocumentosrevisaantesdequeelproyectoinicie? Cundo inicia un proyecto siempre tiene claro el alcance del mismo? (Si la respuestaesNO,pasealapregunta#6). Cmorevisaelalcancedeunproyecto? Cundoiniciaunproyectosiempretieneclaroelcostoestimadodelmismo?(Sila respuestaesNO,pasealapregunta#8). Cmorevisaelcostodeunproyecto? Cundo inicia un proyecto siempre tiene claro el tiempo de ejecucin estimado delmismo?(SilarespuestaesNO,pasealapregunta#10). Cmorevisaestetiempoestimadodeunproyecto? Cundo inicia un proyecto siempre tiene claro los riesgos asociados del mismo? (SilarespuestaesNO,pasealapregunta#13). Cuentaconunalistaconlosriesgospriorizados? Conbaseaqucriteriopriorizalosriesgos? Cuando el proyecto inicia tiene claro cules van a ser los subcontratos o proveedoresquevaaadministrar? Llevauncontroldeloscambiossolicitadosyaprobadosenelproyecto? Actualizalosdocumentosdelproyectounavezqueloscambiossonaprobados? Cmoaseguralacalidadenelproyecto? Existen prcticas para mejorar la calidad de las actividades y de los procesos del proyecto? Se propicia el anlisis de problemas y restricciones que se dan en el da a da del proyecto? Cmosedesignaelequipoconelqueseenfrentarelproyecto? Tienealgunainjerenciaenlaseleccindelequipo?

131

21. Sepropicianactividadesquebusquenmejorarladinmicaylaconfianzaentrelos 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.

33. 34. 35.

miembrosdelequipo? Aliniciodelproyectosondefinidoslosrolesdecadamiembrodelequipo? Existenevaluacionesparadarleseguimientoalosmiembrosdelequipo? Sebuscafomentareltrabajoenequipo? En caso de que se genere conflictos entre miembros, cmo busca manejarlos? Qupasossigue? Cuando inicia el proyecto tiene claro cules son los interesados primarios y secundariosdelproyecto? Hayunacomunicacinconstanteconellos? Conoce cuales son los canales de comunicacin y las lneas de comunicacin con losinteresados? Mantiene con informacin actualizado a los interesados? (Si la respuesta es NO, pasealapregunta#31). Cmo mantiene informados a los interesados del proyecto? Qu herramientas utiliza? Conoceclaramenteculessonlasexpectativasdelosinteresadosdelproyecto? En caso de que las expectativas de los interesados varen, se le informa oportunamentedeestoscambios? Encasodenuevossubcontratos Cuenta con listas de empresas preseleccionadas en caso de que requiera subcontratarunnuevoserviciooproducto? Conbaseaqucriteriosevalalasofertas? Cuentaconalgnmtododeevaluacincuantitativoocualitativodelasofertas?

132

8.5. Cuestionario Grupo de Procesos de Seguimiento y Control Por favor responder las siguientes preguntas de acuerdo a lo que ha sido su experiencia en la administracin de proyectos de construccin en esta empresa. Este cuestionario no pretende evaluar su conocimiento o labor realizada, sino por el contrario conocer la realidad laboral, por lo que se agradece que se responda con sinceridad y a ttulo personal. El alcance de todas lasrespuestas debeestar supeditado al departamento deingenieradeZonaFrancaCoyol. 1. Quindicadoresledicenaustedqueunproyectovaporbuencamino? 2. Quindicadoresledicenaustedqueelproyectonovaporbuencamino? 3. Quherramientasutilizaparacomparareldesempeorealdelproyectocontrael desempeoplaneado? 4. Dequformamanejaloscambiosenelproyecto? 5. Maneja algn procedimiento para la solicitud y aprobacin o denegacin de cambiosenelproyecto? 6. Estn claros los roles de las distintas personas involucradas en el proceso de solicitudesdecambios? 7. Siuncambioesaprobado,actualizalosdocumentosdelproyecto? 8. Mantieneinformadosalosinteresadosdelproyectodeloscambiosquesucedan? 9. Estimaelimpactodeloscambiosaprobados? 10. Cuando el proyecto ha finalizado Cmo verifica que se est cumpliendo con el alcancedelproyecto? 11. Mantiene al da los cambios que existente entre el alcance actual del proyecto y elplanificadoinicialmente? 12. Cmocontrolaelcronogramadelproyecto? 13. Siuncambioesaprobado,revisaelimpactoenelcronogramadelproyecto? 14. Cmocontrolaloscostosdelproyecto? 15. Sellevaregistrodeloscostosrealesalafecha? 16. Sellevaregistrodeltrabajorealalafecha? 17. Siuncambioseaprueba,revisaelimpactoenloscostosdelproyecto? 18. Llevauncontroldecalidadenelproyecto? 19. Cmocontrolalacalidaddelproyecto? 20. Mantienereunionesperidicaspararevisarelestadodelproyecto? 21. Llevaregistrodelasleccionesaprendidasdelproyecto? 22. Ledaseguimientoalosriesgosidentificadosdelproyecto? 23. Tieneclaroculessonlosdisparadoresdelosriesgos?

133

Encasodequeserealicencomprasduranteelproyecto: 24. Ledaseguimientoalascomprasrealizadasenelproyecto? 25. Ledaseguimientoalserviciodelvendedor? 26. Tieneclaroculeselprocesoencasodequeelvendedorincumplaconalgo?

134

8.6. Cuestionario Grupo de Procesos de Cierre Por favor responder las siguientes preguntas de acuerdo a lo que ha sido su experiencia en la administracin de proyectos de construccin en esta empresa. Este cuestionario no pretende evaluar su conocimiento o labor realizada, sino por el contrario conocer la realidad laboral, por lo que se agradece que se responda con sinceridad y a ttulo personal. El alcance de todas lasrespuestas debeestar supeditado al departamento deingenieradeZonaFrancaCoyol. 1. Cmoverificaqueunproyectohafinalizado? 2. En caso de que un proyecto se de por finalizado, Qu acciones toma para cerrarlo? 3. Transfiere la documentacin del proyecto al departamento(s) correspondiente unavezqueestehayafinalizado? 4. Tiene claro cules son los documentos que requieren los otros departamentos queasumenelproductofinal? 5. Generaundocumentoconlasleccionesaprendidasdelproyecto? Encasodequeserealicencomprasduranteelproyecto: 6. Cierreoportunamentelosprocesosdecompras? 7. Generaundocumentofinalconlainformacindelprocesodelacompra? 8. Realizaunanlisisdelproveedorconelquesehizolacompra? 9. Documentalarecepcinoficialdelproductooserviciocomprado?

135

8.7. Resumen de focus group realizado en ZFC Con respecto a la administracin de proyectos, comentan conocer ampliamente del tema ya que la empresa ha invertido en la capacitacin de su personal. Zona Franca Coyol ha enviado a sus ingenieros a distintos seminarios de AP y ha propiciado que se obtenga la acreditacin de Project Manager Profesional aquellos que pueden optar por ella. Sin embargo no siempre es fcil aplicar toda la teora recibida. Al inicio de cada proyecto buscan la memoria descriptiva del shell, el presupuesto, la fecha de entrega, el scope manual (documentos de requerimientos preparado por el cliente y modificado por consultores) o un documento similar en caso de mejoras, estudios de suelos, entre otros. No se tiene acceso a la oferta que ZFC le da el cliente, consideran que esto ayudara para el conocimiento completo del proyecto. Con los documentos anteriores se da una idea macro del proyecto, no es tan definido, pero el detalle se va desarrollando durante la fase de diseo del proyecto, esto para el caso de las mejoras. El cronograma preliminar es macro, la fecha de entrega es con base a una negociacin que se da con el cliente, en la negociacin no estn presentes los ingenieros. El costo es un proceso similar, si es venta se trabaja con el orden de magnitud pero bastante preciso con base a proyectos anteriores, en el caso de los proyectos de mejoras. Para estos proyectos se hace un proceso de pre-construccin con empresas que participan voluntariamente. Para los proyectos de Shell si se genera un presupuesto ms final ya que se tiene una experiencia ms amplia. No hay listado de riesgos, hay algo latente en la cabeza pero no se escribe. No se hacen matrices.

136

La forma en que contractualmente se divide el proyecto est clara por lo que los subcontratos que se van a hacer se tiene claros y los presupuestos se estructuran con base a esos mismos subcontratos.

Los proveedores a utilizar para un posible subcontrato usualmente estn identificados pero no calificados. Se tienen los mismos proveedores. Los clientes a veces piden una precalificacin de proveedores.

El control de calidad se subcontrata a empresas dedicadas a esta actividad en proyectos constructivos. El aseguramiento se hace buscando la mejor empresa, que tengan un profesional responsable. El anlisis de los resultados del control de calidad lo hace la inspeccin. Este consultor debe tener un ingeniero residente en algunos proyectos.

S hay cierta injerencia sobre la seleccin del equipo, pero cuesta mucho poder seleccionar al equipo completo. Hay ms injerencia a alto nivel, sin embargo si se hacer observaciones sobre algn miembro del equipo que fue conformado.

No hay algo sistemtico para la integracin del equipo de proyecto. Son ms impulsos espordicos. A nivel de proyecto no se hace mucho, en niveles ms alto si se hace, pero esto se da especialmente para integrar al cliente con el equipo de proyecto

La introduccin al proyecto se hace tratando de integrar a las personas. A veces la integracin se da involuntariamente. Es muy pobre lo que hay, no se planea.

En caso de conflictos, se trata de explicar cmo tratar o lidiar con la otra persona con la que se tiene el problema, nunca se ha dado nada serio, son cosas ms llevaderas.

Al inicio siempre estn claros los interesados, pero a veces no estn claros cual es su rol ni tampoco si salen nuevos. Usualmente antes del proyecto ya se ha conversado con ellos y se sabe qu se espera. Sin embargo a veces hay sorpresas. Pero s se tiene muy claro cules son los key stakeholders.

137

Los canales de comunicacin estn claros del proyecto siempre estn claros, pero suele suceder que a algunos subcontratistas a veces se les enreda y se brincan pasos o niveles.

Qu les dicen que el proyecto va por buen camino? Las herramientas de control de presupuesto, en todas las reuniones se revisa el cronograma, fechas de entrega, muchas veces por pura experiencia se puede saber si el proyecto va bien.

Qu les dicen que no va bien? Atrasos de proveedores. Se confa mucho en el feeling de los profesionales. Se apoya mucho en los contratistas y se trata de identificar el verdadero compromiso de ellos.

Las lecciones aprendidas se hizo ya por primera vez al final de un proyecto reciente. No se llevan en el da a da. Entrega de proyecto a operaciones: manuales de equipos, planos as built, cdigos de materiales. Si se guarda una copia para el mantenimiento. No hay un anlisis escrito de los proveedores para las compras en proyectos ni tampoco hay tabla para evaluarlos. Para la revisin de las ofertas presentadas no hay una metodologa establecida. Si la compra es muy importante y compleja se renen con el cliente para ver cuales con las variables ms importantes y cul es el peso de cada variable.

138

8.8. Plantilla: Registro de Interesados de Proyecto

ZONAFRANCACOYOL REGISTRODEINTERESADOSDEPROYECTO
Proyecto: Fase: # 1 2 3 4 5 6 7 Nombre Interesado Organizacin Puesto Rolenproyecto

Documento: ZFC.001 Versin: 1.02010

Fecha: Informacindecontacto
Telfono: Email: Telfono: Email: Telfono: Email: Telfono: Email: Telfono: Email: Telfono: Email: Telfono: Email:

Clave(s/no)

139

8.9. Plantilla: Registro de Incidentes de Proyecto

ZONAFRANCACOYOL REGISTRODEINCIDENTESDEPROYECTO
Proyecto: Fase: # 1 2 3 4 5 6 7 8 9 10 11 12 Incidente Causaquelogener

Documento: ZFC.002 Versin: 1.02010

Fecha: Solucinaplicada

140

8.10.

Plantilla: Registro de Cambios de Proyecto

ZONAFRANCACOYOL

REGISTRODECAMBIOSDEPROYECTO
Proyecto: Fase: # 1 2 3 4 5 6 7 8 9 10 11 Cambiosolicitado Solicitante Impactos Econmico Plazo

Documento: ZFC.003 Versin: 1.02010

Fecha: Riesgosasociados

141

8.11.

Gua para elaboracin del Acta Constitutiva del Proyecto

A continuacin se presentar de forma general un esquema de cmo debe conformarse el Acta Constitutiva del Proyecto. El formato definitivo del documento deber ser definido por la organizacin
Documento: G.001

SECCIN 1: DECRIPCIN DEL PROYECTO 1.1. Enunciado del proyecto. 1.2. Descripcin del proyecto. 1.3. Metas y objetivos del proyecto. 1.4. Alcance del proyecto. 1.5. Factores claves de xito. 1.6. Supuestos del proyecto. 1.7. Restricciones del proyecto. 1.8. Descripcin de interesados.

SECCIN 2: PRESUPUESO Y CRONOGRAMA DEL PROYECTO 2.1. Presupuesto aprobado del proyecto. 2.2. Principales hitos del proyecto.

SECCIN 3: ORGANIZACIN DEL PROYECTO 3.1 Estructura del proyecto. 3.2 Facilidades y recursos del proyecto.

SECCIN 4: PUNTOS DE CONTACTO

SECCIN 5: GLOSARIO

SECCIN 6: REVISIN DE DOCUMENTOS

SECCIN 7: ANEXOS

142

8.12.

Gua para elaboracin la Agenda de Reunin

Documento: G.002

ZONAFRANCACOYOL NOMBREDELPROYECTO
AgendaReunindeCoordinacinInsertarFecha
Asuntosatratar:

1. 2. 3. 4. 5. 6.

143

8.13.

Gua para elaboracin la Minuta de Reunin

Documento: G.003

ZONAFRANCACOYOL NOMBREDELPROYECTO
MinutaReunindeCoordinacin#XX
InsertarFecha

Participantes:
Nombre Jose Araya Mario Mndez Sigla JA MM Empresa ZFC XXX Nombre Sigla Empresa

HoraInicio:9:00am Asuntostratadosenlareunin:
Asunto 1. 2. 3.

HoraFinal:11:00am

Responsable

Fechade Entrega

144

8.14.

Plantilla: Registro de Riesgos de Proyecto

ZONAFRANCACOYOL

REGISTRODERIESGOSDEPROYECTO
Proyecto: Fase: # 1 2 3 4 5 6 7 8 9 Descripcindelriesgo Disparador

Documento: ZFC.004 Versin: 1.02010

Fecha:

Planderespuesta

145

8.15.

Plantilla: Evaluacin de miembros del equipo

ZONAFRANCACOYOL EVALUACINDEMIEMBROSDELEQUIPO
Proyecto: Fase: Evaluador: Nombredel evaluado: Criteriodeevaluacin Relacionesinterpersonales Colaboracin Responsabilidad Trabajoenequipo Puntualidad Cumplimientoplandetrabajo Tiempoderespuestaadecuado Calidaddeltrabajo Habilidadparasolucionar problemas Calidaddeinformes presentados Empresa: Calificacin Excelente(10) Bueno(7.5) Regular(5) Malo(2.5) S No No. Evaluacin:
Documento: ZFC.005 Versin: 1.02010

Fecha:

CALIFICACINFINAL
Recomendaraaestaempresaparaquevuelvaasercontratada enZFC? Observaciones:

146

8.16.

Plantilla: Evaluacin de oferentes para licitacin

ZONAFRANCACOYOL EVALUACINDEOFERENTES
Proyecto: Fase: Evaluador: Empresa Oferente: Criterio
Precio 40% Plazo 25% Alcance 15% Currculum empresa 10% Trabajos previosen proyectos similaresen ZFC 10%
Menosque presupuesto Documento: ZFC.006 Versin: 1.02010

Responsable Oferente: ParmetrodeEvaluacin

Igualal presup. 05%sobre presup. 510%sobre presup.

Fecha: Licitacin: No. Evaluacin:

Puntaje
1015%sobre presup.

50
Menosque estimado

40
Igualque estimado

30
05%msque estimado

20
510%msque estimado

10
1015%msque estimado

30
Msque solicitado

25

20
Igualque solicitado

15
01aos experiencia

10
Menosque solicitado

20
10+aos experiencia

510aos experiencia

15
15aos experiencia

10

10
S

5
No

10 5

CALIFICACINFINAL
Observaciones:

147

8.17.

Plantilla: Registro de Lecciones Aprendidas de Proyecto

ZONAFRANCACOYOL REGISTRODELECCIONESAPRENDIDASDEPROYECTO
Proyecto: Fase: # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Leccinaprendida

Documento: ZFC.007 Versin: 1.02010

Fecha: Etapadeproyectoenquesedio

148

8.18.

Diagrama de flujo para solicitud y aprobacin de cambios

149

150

8.19.

Plantilla: Solicitud de aprobacin de cambios

151

8.20.

Ejemplo de punch list

152

8.21.

Plantilla: Revisin de Cronograma de Proyecto

ZONAFRANCACOYOL

Documento: ZFC.010

REVISINDECRONOGRAMADEPROYECTO
Fechadeiniciooficial: Fechadecierreoficial: Hitosdelproyecto 1. 2. 3. 4. Actividadesmsimportantes 1. 2. 3. 4. Actividadesderutacrtica 1. 2. 3. 4. Fechainicio

Versin: 1.02010

Fecha:

Fecha

Fechainicio

Fechacierre

153

8.22.

Gua para elaboracin de informes semanales para interesados

Documento: G.004

ZONAFRANCACOYOL NOMBREDELPROYECTO

1. Avance de Proyecto 1.1. Estatus de permisos. 1.2. Descripcin de avance. 1.3. Hitos del proyecto con su avance respectivo. 1.4. Fotografas del avance.

2. Cambios solicitados. 2.1. Log de cambios solicitados y su estatus

3. Riesgos 3.1. Registro de riesgos actualizado

4. Control de calidad 4.1. Descripcin de control de calidad efectuado. 4.2. Resultados de control de calidad

154

8.23.

Plantilla: Registro de informes de calidad.

ZONAFRANCACOYOL REGISTRODEINFORMESDECALIDAD
Proyecto: Fase: Descripcindeinforme Observaciones: Empresa responsable Periodicidad presentacin Fechainicio depruebas
Documento: ZFC.011 Versin: 1.02010

Fecha:

155

8.24. Gua para elaboracin de informes mensuales para control interno

Documento: G.005

ZONAFRANCACOYOL NOMBREDELPROYECTO

1. Avance de Proyecto 1.1. Estatus de permisos. 1.2. Descripcin de avance. 1.3. Hitos del proyecto con su avance respectivo. 1.4. Fotografas del avance.

2. Cambios solicitados. 2.1. Log de cambios solicitados y su estatus

3. Presupuesto 3.1. Registro de cambios en el presupuesto. 3.2. Tabla de control de presupuesto. 3.3. Proyecciones presupuestarias.

4. Riesgos 4.1. Registro de riesgos actualizado

5. Control de calidad 5.1. Descripcin de control de calidad efectuado. 5.2. Resultados de control de calidad

156

6. Lecciones aprendidas. 6.1. Actualizacin del registro de lecciones aprendidas.

7. Prximas actividades 7.1. Listado de actividades venideras. 7.2. Objetivos por cumplir en el siguiente periodo.

157

8.25.

Plantilla: Seguimiento y Control de Riesgos

ZONAFRANCACOYOL SEGUIMIENTOYCONTROLDERIESGOSDEPROYECTO

Documento: ZFC.012

Proyecto: Fase:

Fechade revisin

Versin: 1.02010

Fecha: Efectividadde plande respuesta

# 1 2 3 4 5 6 7 8 11

Riesgo

Disparador

Estatusdelriesgo

Planderespuesta

158

8.26.

Plantilla: Registro de Seguimiento a Proveedores de Proyecto

ZONAFRANCACOYOL

REGISTRODESEGUIMIENTOAPROVEEDORESDEPROYECTO
Proyecto: Fase: Descripcindeartculo comprado: Fechadeinforme Estatusactualdelacompra Estatusconrespectoalo planeado

Documento: ZFC.013 Versin: 1.02010

Fecha:

Observaciones

159

8.27.

Plantilla: Evaluacin final de contratista

ZONAFRANCACOYOL EVALUACINDECONTRATISTA
Proyecto: Fase: Evaluador: Empresa Contratada: Criterio
Plazode entrega 30% Calidad 25% Alcance completado 15% Relacincon contratista 10% Valor agregadoal proceso 10%
Menosque contratado Documento: ZFC.014 Versin: 1.02010

Responsable Contratista: ParmetrodeEvaluacin

Igualal contratado 05%+que contratado. 510%+que contratado.

Fecha: Producto oservicio: No. Evaluacin:

Puntaje
1015%+que contratado.

40

30

20

10

Cumpliconespecificacionesde calidad

Nocumplicon especificacionesdecalidad

25
Fuemsall delalcance contratado Cumpliconalcancecontratado

Nocumpliconalcancecontratado

15
Buena Regular Mala

25
Excelente

0
Deficiente 2 Cumpli deficientemente sulabor 0 Mala Deficiente 2

10

Aportnuevasideasysoluciones 10 Excelente Buena

Solamentecumpliconsu responsabilidad 5 Regular

Servicio postentrega 10%

10

CALIFICACINFINAL
Recomendaraaestaempresaparaquevuelvaasercontratadaen ZFC? Observaciones: S No

160

8.28.

Resumen de metodologa propuesta

161

8.29. Ejemplo de aplicacin de Valor Ganado en control de cronograma

A continuacin se presentar un ejemplo con los pasos que deben seguirse para poder aplicar la herramienta del valor ganado o earn value para el control de avance de los proyectos. Este instrumento se puede utilizar una vez que se cuente con un subcontrato adjudicado y se conozca el costo real que tendr determinada actividad. A continuacin se describir el procedimiento que debe realizarse. 1. Montar flujo de caja Una vez se tenga definido el monto y el plazo del contrato adjudicado, se debe establecer cul ser el flujo de caja del proyecto. Este flujo de caja muestra los desembolsos que debern realizarse a lo largo del proyecto para poder pagar los avances del oferente.
Cuadro 8.19.1: Flujo de caja proyecto Remodelacin de Oficinas.
Tarea
Demolicin Pisos Paredes Cielos EM AireAC Carpintera Cerrajera

Presupuesto total
$10.019,86 $22.055,24 $17.936,49 $22.041,39 $146.181,47 $14.366,11 $8.444,10 $1.941,95

Sem2
$10.019,86 $4.484,12 $17.541,78 $1.723,93

Sem4
$4.484,12 $11.694,52 $1.723,93 $1.688,82

Sem6
$4.484,12 $5.510,35 $17.541,78 $1.723,93 $3.377,64

Sem8
$6.616,57 $4.484,12 $5.510,35 $23.389,04 $1.723,93 $2.533,23

Sem10
$6.616,57 $5.510,35 $27.774,48 $1.723,93 $844,41

Sem12
$6.616,57 $5.510,35 $23.389,04 $2.298,58

Sem14
$2.205,52 $17.541,78 $1.723,93 $1.359,36

Sem16
$7.309,07 $1.723,93 $582,58

Total $10.019,86 $22.055,24 $17.936,49 $22.041,39 $146.181,47 $14.366,11 $8.444,10 $1.941,95 $242.986,61

Total

$242.986,61 $33.769,69 $19.591,39 $32.637,82

$44.257,24

$42.469,74

$37.814,53

$22.830,60

$9.615,59

Totalacumulado

$33.769,69 $53.361,08 $85.998,90 $130.256,15 $172.725,89 $210.540,43 $233.371,02 $242.986,61

Es muy importante que el flujo de caja se haga con base en el cronograma que presente el oferente para la realizacin de los trabajos contratados. Si no se hace tomando en cuenta esta consideracin la herramienta va perder toda validez.

162

El flujo de caja puede ser realizada por el equipo de proyecto de ZFC, o idealmente debe ser presentado por el proveedor. A continuacin se presenta como ejemplo el flujo de caja de un proyecto ficticio denominado: Remodelacin de oficinas. Este proyecto tiene una duracin de 16 semanas y un costo total de $242.986,61. Como puede verse en la tabla, los desembolsos se reflejan en las semanas 2, 4, 6, 8, 10, 12, 14 y 16. Esto es debido a que de acuerdo a lo establecido por ZFC, los pagos contra avances de obra se hacen de forma bisemanal. 2. Generar curva S de proyecto. Como puede verse en la tabla anterior, en la ltima fila se agreg el total acumulado de los pagos que se van realizando. Utilizando esta informacin es posible generar la curva S del proyecto, tal y como se muestra en el siguiente grfico

Presupuestoacumuladodeproyecto(CurvaS)
$300.000,00 $250.000,00 Flujodecajaacumulado $200.000,00 $150.000,00 PV $100.000,00 $50.000,00 $0,00 Sem2 Sem4 Sem6 Sem8 Sem10 Sem12 Sem14 Sem16 Fechasdepagos

Figura 8.19.1: Curva S proyecto Remodelacin de Oficinas.

163

Este grfico generado constituye el costo presupuestado programado del proyecto (PV) ya que refleja de qu forma han sido programados los desembolsos a lo largo del proyecto. 3. Anlisis en cada avance Una vez que ya se cuente con el flujo de caja y la curva S del proyecto listos, es posible realizar anlisis del avance del proyecto bisemanalmente, cada vez que al oferente se le deba de tramitar un pago por concepto de avance. Inicialmente se analizar el avance del proyecto haciendo un corte en la semana 6. En la siguiente tabla se muestra el avance que est presentando el proveedor en esa semana para que le sea cancelado el pago.
Cuadro 8.19.2: Desembolso real de pagos a semana 6.
Tarea
Demolicin Pisos Paredes Cielos E-M Aire AC Carpintera Cerrajera

Presupuesto total
$10.019,86 $22.055,24 $17.936,49 $22.041,39 $146.181,47 $14.366,11 $8.444,10 $1.941,95

Sem2
% 100% 0% 20% 0% 12% 12% 0% 0% Monto $10.019,86 $0,00 $3.587,30 $0,00 $17.541,78 $1.723,93 $0,00 $0,00 % 0% 0% 25% 0% 3% 20% 10% 0%

Sem4
Monto $0,00 $0,00 $4.484,12 $0,00 $4.385,44 $2.873,22 $844,41 $0,00 % 0% 0% 25% 20% 5% 12% 35% 0%

Sem6
Monto $0,00 $0,00 $4.484,12 $4.408,28 $7.309,07 $1.723,93 $2.955,43 $0,00

Total Totalacumulado

$242.986,61

$32.872,87 $32.872,87

$12.587,20 $45.460,06

$20.880,84 $66.340,91

Como puede verse en el cuadro anterior, al revisar el avance que se ha tenido hasta ese momento en el proyecto, puede notarse que el acumulado real a la semana 6 es de $66.340,91. Esto no coincide con el acumulado programado para esa misma semana, que se puede ver en el cuadro 8.19.1. En la figura 8.19.2, puede verse reflejado la variacin entre el costo presupuestado programado y el costo presupuestado del trabajo realmente ejecutado (EV).

164

Presupuestoacumuladodeproyecto(CurvaS)
$300.000,00 $250.000,00 Flujodecajaacumulado $200.000,00 $150.000,00 $100.000,00 $50.000,00 $0,00 Sem2 Sem4 Sem6 Sem8 Sem10 Sem12 Sem14 Sem16 Fechasdepagos PV

$85.998,90

EVsem6

$66.340,91

Figura 8.19.2: Curva valor ganado a semana 6.

De acuerdo a lo que se puede observar en el grfico anterior, y con las frmulas planteadas en la seccin 4.4.2.5, se tiene lo siguiente: PV = $85.998,90 EV = $66.340,91

SV = EV PV = $66.340,91 $85.998,90 SV = -$19.657,99

SPI = EV / PV = $66.340,91 / $85.998,90 SPI = 0,77

STC = Tiempo que falta de acuerdo a lo planeado / SPI STC = 10 / 0,77 STC = 12,98 semanas

SAC = Tiempo transcurrido hasta el momento + STC

165

SAC = 6 + 12,98 SAC = 18,98 semanas.

Con la informacin anterior, podra inferirse que al tener un SV (variacin en el cronograma) negativo, el proyecto se encuentra atrasado con respecto a lo planeado. Esto es debido a que se ha pagado menos de lo que se tena esperado pagar a la semana 6, lo que implica que el proyecto no ha avanzado de la forma que se quera. Por otro lado el SPI (ndice de rendimiento del cronograma) confirma lo anterior al ser menor que uno, por lo que el rendimiento que ha tenido el proyecto hasta ese momento, ha sido menor que el que se haba planeado. Para ver este ndice en trminos econmicos, se podra decir que se ha ganado para el proyecto $0,77 por cada dlar que se ha planeado hasta el corte realizado. De la misma forma las proyecciones sealan problemas de cara a la finalizacin del proyecto. Esto porque de acuerdo al avance que se lleva a la fecha, estaran haciendo falta 12,98 semanas para poder terminar el proyecto, esto proyecta una duracin total de 18,98 semanas. Lo cual es ms que las 16 semanas estimadas al inicio. Los resultados anteriores deben ser una seal de alerta para los miembros del equipo de proyecto, ya que se deben tomar las medidas necesarias para que se pueda recuperar el tiempo que se ha atrasado el proyecto. Seguidamente se har el mismo anlisis haciendo un corte en la semana 10. En la tabla que se muestra a continuacin se sealan el avance que se ha tenido hasta esa fecha.

166

Cuadro 8.19.3: Desembolso real de pagos a semana 10.

Tarea
Demolicin Pisos Paredes Cielos E-M Aire AC Carpintera Cerrajera

Presupuesto total
$10.019,86 $22.055,24 $17.936,49 $22.041,39 $146.181,47 $14.366,11 $8.444,10 $1.941,95

Sem2
% 100% 0% 20% 0% 12% 12% 0% 0% Monto $10.019,86 $0,00 $3.587,30 $0,00 $17.541,78 $1.723,93 $0,00 $0,00 % 0% 0% 25% 0% 3% 20% 10% 0%

Sem4
Monto $0,00 $0,00 $4.484,12 $0,00 $4.385,44 $2.873,22 $844,41 $0,00 % 0% 0% 25% 20% 5% 12% 35% 0%

Sem6
Monto $0,00 $0,00 $4.484,12 $4.408,28 $7.309,07 $1.723,93 $2.955,43 $0,00 % 0% 20% 20% 30% 12% 14% 30% 0%

Sem8
Monto $0,00 $4.411,05 $3.587,30 $6.612,42 $17.541,78 $2.011,26 $2.533,23 $0,00 % 0% 41% 10% 35% 43% 37% 20% 0%

Sem10
Monto $0,00 $9.042,65 $1.793,65 $7.714,49 $62.858,03 $5.315,46 $1.688,82 $0,00

Total

$242.986,61

Totalacumulado

$32.872,87 $32.872,87

$12.587,20

$20.880,84

$45.460,06

$66.340,91

$103.037,93
$36.697,03

$88.413,10 $191.451,03

Igualmente, con base en la informacin anterior, es posible generar una grfica en la que se compare el valor ganado y el costo presupuestado programado.

Presupuestoacumuladodeproyecto(CurvaS)
$300.000,00 $250.000,00 Flujodecajaacumulado $200.000,00 $150.000,00 $100.000,00 $50.000,00 $0,00 Sem2 Sem4 Sem6 Sem8 Sem10 Sem12 Sem14 Sem16 Fechasdepagos

$191.451,03
PV EVsem10

$172.725,89

Figura 8.19.3: Curva valor ganado a semana 10.

167

Para la semana 10 se tendra lo siguiente: PV = $172.725,89 EV = $191.451,03

SV = EV PV = $191.451,03 $172.725,89 SV = $18.725,14

SPI = EV / PV = $191.451,03 / $172.725,89 SPI = 1,11

STC = Tiempo que falta de acuerdo a lo planeado / SPI STC = 6 / 1,11 STC = 5,41 semanas

SAC = Tiempo transcurrido hasta el momento + STC

SAC = 10 + 5,41 SAC = 15,41 semanas.

Como puede verse en la figura 8.19.3 y con los datos anteriores, para la semana 10 las condiciones de avance en el proyecto han variado. El SV est dando un valor positivo, lo que implica que el proyecto se encuentra en trminos generales delante de acuerdo al cronograma. De la misma forma el SPI est dando un valor por encima de uno, lo que implica que se ha ganado para el proyecto $1,11 por cada dlar que se ha planeado hasta el corte realizado. Asimismo puede observar que con respecto al valor que se obtiene del SAC, el proyecto se proyecta su finalizacin en 15,41 semanas, terminando antes de lo que se haba planificado.

168

A partir de la informacin anterior es posible ver que el proyecto tiene un buen avance y que inclusive se encuentra delante de acuerdo al cronograma.