pfg final leana romero 11-12-09
TRANSCRIPT
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
PLAN DE PROYECTO PARA EL PROCESO DE CERTIFICACIÓN PCI DSS EN FISERV COSTA RICA
LEANA ROMERO ARCE
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACIÓN
DE PROYECTOS
San José, Costa Rica
Diciembre, 2009
ii
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como
Requisito parcial para optar al grado de Máster en Administración de Proyectos
__________________________ Miguel Vallejo Solís
PROFESOR TUTOR
_________________________ Ing. Marvin Coto Hernández, MAP
LECTOR No. 1
__________________________ Ing. Yorlen Solís Araya, MAP, PMP
LECTOR No. 2
________________________ Leana Romero Arce
SUSTENTANTE
iii
DEDICATORIA
A Dios por ser siempre lo primero en mi vida, porque sin Él en mi, nada
sería posible. A mis padres por haberme inculcado los valores que me han llevado
a través de mi vida a cumplir tantas metas y por apoyarme tanto en cada proyecto
que emprendo. A mis hermanos, porque al igual que mis padres, ellos son el
motivo por el cual inicio siempre cada proyecto y por ayudarme también en este
proceso. De ellos, es este triunfo personal.
iv
AGRADECIMIENTOS
Agradezco a Fiserv Costa Rica por el apoyo en este proceso de tesis. A mi
profesor tutor Miguel Vallejo, por su guía tan valiosa durante todo el proceso final
de esta maestría. A mis amigos más cercanos, porque sus palabras de aliento
siempre son fortaleza en cada momento de mi carrera y por prestarme su apoyo
incondicional cuando más lo he necesitado.
v
INDICE HOJA DE APROBACIÓN ii DEDICATORIA iii AGRADECIMIENTOS iv INDICE v INDICE DE FIGURAS viii INDICE DE CUADROS ix INDICE DE ABREVIATURAS x RESUMEN EJECUTIVO xi 1 INTRODUCCION........................................................................................................1
1.1 Antecedentes......................................................................................................1 1.2 Problemática.......................................................................................................1 1.3 Justificación del problema...................................................................................2 1.4 Objetivo general..................................................................................................3 1.5 Objetivos específicos ..........................................................................................3
2 MARCO TEORICO.....................................................................................................4 2.1 Marco referencial o institucional..........................................................................4 2.1.1 Antecedentes de la Institución (Fiserv, 2009)..............................................4 2.1.2 Misión y visión.............................................................................................5 2.1.3 Valores (Fiserv, 2009) .................................................................................6 2.1.4 Estructura organizativa................................................................................6 2.1.5 Productos que ofrece ..................................................................................7 2.2 Teoría de Administración de Proyectos...............................................................9 2.2.1 PRINCE2 ..................................................................................................11 2.2.2 XP.............................................................................................................12 2.2.3 P2M ..........................................................................................................15 2.2.4 V-Model.....................................................................................................18 2.2.5 Conclusiones sobre los Modelos de Administración de Proyectos ............20 2.2.6 Beneficios de la Administración de Proyectos para las organizaciones.....22 2.2.7 Metodología del PMI .................................................................................22 2.2.8 Proyecto....................................................................................................22 2.2.9 Administración de Proyectos según el PMI ...............................................24 2.2.10 Áreas del Conocimiento de la Administración de Proyectos......................25 2.2.11 Ciclo de vida de un proyecto .....................................................................26 2.2.12 Procesos en la Administración de Proyectos.............................................28 2.3 Certificación PCI DSS.......................................................................................32
3 MARCO METODOLOGICO......................................................................................34 3.1 Fuentes de información ....................................................................................34 3.1.1 Fuentes Primarias: ....................................................................................34 3.1.2 Fuentes Secundarias: ...............................................................................35 3.2 Técnicas de Investigación.................................................................................36 3.3 Método de Investigación ...................................................................................37 3.4 Herramientas y Entregables..............................................................................38
4 ALCANCE DEL PROYECTO....................................................................................39 4.1 Generalidades del Proyecto..............................................................................39
vi
4.2 Definición del Alcance.......................................................................................40 4.3 Beneficios Esperados .......................................................................................40 4.4 Entregables.......................................................................................................41 4.5 Exclusiones.......................................................................................................45 4.6 Restricciones ....................................................................................................45 4.7 Supuestos.........................................................................................................46 4.8 Estructura Detalla de Trabajo (EDT) .................................................................46
5 GESTIÓN DEL TIEMPO DEL PROYECTO ..............................................................48 5.1 Definición de las Actividades ............................................................................48 5.2 Estimación de Recursos de las Actividades......................................................50 5.3 Desarrollo del Cronograma del Proyecto ..........................................................50
6 PLAN DE RECURSOS HUMANOS..........................................................................52 6.1 Organigrama del Proyecto ................................................................................52 6.2 Roles y Responsabilidades del Proyecto ..........................................................53 6.3 Matriz de Asignación de Responsabilidades.....................................................57 6.4 Plan de Gestión del Personal............................................................................61 6.4.1 Reclutamiento de personal........................................................................61 6.4.2 Horarios ....................................................................................................61 6.4.3 Criterios de Liberación ..............................................................................62 6.4.4 Necesidades de Formación.......................................................................63 6.4.5 Reconocimiento y Recompensas ..............................................................64
7 PLAN DE GESTIÓN DE LAS COMUNICACIONES..................................................67 7.1 Análisis de Involucrados ...................................................................................67 7.2 Matriz de Responsabilidades de Comunicación de los Involucrados ................74 7.3 Proceso de Resolución de Disputas .................................................................75 7.4 Proceso de Escalamiento .................................................................................76 7.5 Distribución de la información ...........................................................................76 7.6 Informes del Proyecto .......................................................................................76 7.6.1 Informe Semanal.......................................................................................76 7.6.2 Informe Mensual .......................................................................................77 7.7 Reuniones ........................................................................................................77
8 PLAN DE GESTIÓN DE RIESGOS ..........................................................................79 8.1 Definición de Riesgo .........................................................................................79 8.2 Registro de Riesgos..........................................................................................80 8.3 Identificación de Riesgos ..................................................................................80 8.4 Clasificación de Riesgos ..................................................................................81 8.5 Causa del Riesgo .............................................................................................81 8.6 Análisis Cualitativo............................................................................................82 8.7 Categorización de los Riesgos..........................................................................84 8.8 Planificación de la Respuesta a Riesgos ..........................................................85 8.9 Estrategias de Respuesta .................................................................................86 8.10 Análisis Cuantitativo..........................................................................................86 8.11 Seguimiento y Control de los Riesgos...............................................................87 8.11.1 Reuniones de seguimiento........................................................................87 8.11.2 Informes de Estado ...................................................................................88 8.11.3 Control de Cambios ..................................................................................88 8.11.4 Actualización del Plan de Gestión .............................................................88 8.12 Registro de Riesgos del Proyecto .....................................................................88
vii
8.12.1 Identificación de Riesgos del Proyecto......................................................88 8.12.2 Análisis Cuantitativo..................................................................................91 8.12.3 Planificación de la Respuesta a los Riesgos del Proyecto.........................93
9 PLAN DE GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO................................97 9.1 Acta de Constitución del Proyecto ....................................................................97 9.2 Gestión de Cambios del Proyecto.....................................................................97 9.3 Procedimiento de Cierre Administrativo ............................................................99
10 CONCLUSIONES...............................................................................................101 11 RECOMENDACIONES.......................................................................................104 12 BIBLIOGRAFIA...................................................................................................106 13 ANEXOS ............................................................................................................107
Anexo 1: ACTA DEL PROYECTO..............................................................................107 Anexo 2: EDT DEL PFG.............................................................................................111 Anexo 3: CRONOGRAMA DEL PFG..........................................................................112 Anexo 4: CRONOGRAMA DEL PROYECTO PCI DSS FISERV, COSTA RICA.........113 Anexo 5: FORMATO INFORME SEMANAL ...............................................................114 Anexo 6: FORMATO INFORME MENSUAL ...............................................................115 Anexo 7: PLANTILLA PARA MINUTAS DE REUNIÓN...............................................116 Anexo 8: PLANTILLA PARA GESTIÓN DE CAMBIOS...............................................117 Anexo 9: PLANTILLA PARA LECCIONES APRENDIDAS..........................................118 Anexo 10: PLANTILLA PARA CONTROL DE HORAS ...............................................119 Anexo 11: PLANTILLA PARA CONTROL DE ASUNTOS...........................................120
viii
ÍNDICE DE FIGURAS
Figura No.1. Estructura organizativa de Fiserv Costa Rica……………………………………7
Figura No.2. Submodelos del Modelo-V..………………………………………………………19
Figura No.3. Secuencia de fases típicas en el ciclo de vida de un proyecto………………27
Figura No.4. El ciclo planificar-hacer-revisar-actuar…………………………………………..29
Figura No.5. Representación gráfica del proyecto.………………………….........................40
Figura No.6. Entregables y criterios de aceptación del proyecto………….……………......41
Figura No.7. Estructura detallada de trabajo del proyecto (EDT)……………………...……47
Figura No.8. Organigrama del proyecto………………………………………………………..53
Figura No.9. Estructura detallada de riesgos……………………………………………….…82
Figura No.10. Proceso de gestión de cambio…………………………………………...…….99
ix
ÍNDICE DE CUADROS
Cuadro No.1. Comparación entre la gestión de proyectos y la gestión de programas…...18
Cuadro No.2. Fuentes primarias y secundarias de los objetivos del proyecto…………….35
Cuadro No.3. Herramientas y entregables de los objetivos del proyecto……………….....38
Cuadro No.4. Entregables y sub-entregables del proyecto………………………………….42
Cuadro No.5. Roles y responsabilidades del proyecto……………………………………….53
Cuadro No.6. Matriz de asignación de responsabilidades…………………………………...58
Cuadro No.7. Criterios de liberación de los recursos del proyecto………………………….62
Cuadro No.8. Análisis de involucrados del proyecto………………………………………….68
Cuadro No.9. Matriz de comunicación del proyecto…………………………………………..74
Cuadro No.10. Criterios de probabilidad……………………………………………………….83
Cuadro No.11. Escala de impacto………………………………………………………………83
Cuadro No.12. Evaluación del impacto de un riesgo…………………………………………84
Cuadro No.13. Matriz PxI………………………………………………………………………...85
Cuadro No.14. Riesgos del proyecto………………………………………............................89
Cuadro No.15. Análisis cuantitativo…………………………………………………………….91
Cuadro No.16. Planificación de la respuesta a los riesgos………………………………….93
x
ÍNDICE DE ABREVIATURAS
CM: Configuration Management
EDT: Estructura Detallada de Trabajo
ENAA: Comité de Investigación y Desarrollo en Gestión de Proyectos
de la Asociación de Promoción de Ingeniería de Japón
IABG: Industrieanlagen-Betriebsgesellschaft mbH
OGC: Office of Government Commerce, 2009
PCI DSS: Payment Card Industry Data Security Standard
PFG: Proyecto Final de Graduación
PKBOK: Project Management Body of Knowledge
PM: Project Management
PMAJ: Project Management Association of Japan
PMI: Project Management Institute
PRINCE2: Projects in Controlled Enviroments
P2M: Project & Program Management for Enterprise Innovation
QA: Quality Assurance
RBS Risk Breakdown Structure
SD: System Development
TI: Tecnologías de Información
XP: eXtreme Programing
xi
RESUMEN EJECUTIVO
Fiserv, Inc. es una empresa dedicada al desarrollo de software para el área financiera, nacida de la fusión de dos compañías norteamericanas en 1984, Sunshine State Systems, Inc en Tampa, Florida y First Data Processing ubicada en Milwaukee, Wis. Para todas las oficinas de Fiserv en India, Costa Rica y Orlando Florida, Fiserv a establecido como política interna la obtención de la certificación PCI DSS para asegurar la información relacionada con tarjetas de crédito y débito, desde su perspectiva de proveedor de servicios de software en el área financiera. En el caso de las oficinas de Fiserv en Costa Rica la gestión de esta certificación es un agregado a la certificación ISO 27001 que actualmente está en proceso de implementación. La certificación PCI DSS es el conjunto de las Normas de Seguridad de la Información de la Industria de Medios de Pago (PCI DSS), creado por las compañías Visa y Mastercard. Esta es aplicada tanto a los bancos, como a comercios y proveedores de servicios relacionados con tarjetas de débito y crédito, para proteger a los dueños de tarjetas y su información confidencial. El objetivo principal de este trabajo, fue desarrollar un Plan de Proyecto para el proceso de Certificación de PCI DSS en Fiserv Costa Rica en su etapa de análisis. Dentro de los objetivos específicos se desarrollaron los siguientes: Desarrollar el acta de constitución del proyecto. Desarrollar el cronograma del proyecto para garantizar la conclusión del proyecto en el tiempo establecido. Desarrollar un Plan de Gestión del Personal. Desarrollar un plan de comunicaciones para determinar las necesidades de información. Desarrollar un Plan de Gestión de Riesgos para aumentar la probabilidad e impacto de los eventos positivos y disminuir la probabilidad e impacto de los eventos adversos para el proyecto. Dentro del marco metodológico usado para el desarrollo de la investigación se usaron fuentes de información primaria y secundaria. La fuente primaria que se utilizó para todos los objetivos aquí planteados fue el de entrevista, que se realizó a la Alta Gerencia, Departamento de Seguridad de la Información, Departamento de Recursos Humanos y Departamento de TI, según fue necesario para cada objetivo específico. Para las fuentes secundarias, se hizo uso de los sitios web tanto de Fiserv, Inc. como del PCI Security Standards Council y sitios oficiales relacionados con el tema de la certificación PCI DSS como los de VISA y Mastercard. De igual forma se utilizaron textos de Administración de Proyectos como fuentes secundarias para el desarrollo de cada objetivo específico. La técnica es indispensable en el proceso de la investigación científica, ya que integra la estructura por medio de la cual se organiza la investigación, por ello el tipo de investigación que se utilizó es la Investigación Mixta, que utiliza tanto la investigación documental, como la investigación de campo. La investigación mixta se empleará por la naturaleza de este proyecto, que involucra no solo la extracción de información de ciertos documentos, sino participación de distintas áreas de la
xii
organización (personal) que contienen información que debe ser extraída mediante la investigación de campo, y de esta forma complementar mejor la información disponible en otros medios. Finalmente dentro del marco metodológico se utilizó el método de investigación Inductivo-Deductivo donde se observan hechos particulares para obtener proposiciones generales, lo cuál indica la obtención de conclusiones o leyes universales que explican o relacionan los fenómenos estudiados. El resultado más importante del Proyecto Final de Graduación (PFG), es el plan de proyecto completo que se propone en este documento y el desarrollo de los objetivos específicos que dan como resultado lo siguiente: el desarrollo del alcance del proyecto que permitió identificar claramente los entregables y posteriormente con el desglose de actividades obtener el cronograma de trabajo. Además se realizó el calculo de los recursos que se requieren para llevar al cabo el proyecto y con ello se obtuvo la Matriz de Roles y Responsabilidades, parte del Plan de Recursos Humanos, para designar los diferentes recursos a estas actividades. Este análisis de recursos permitió el desarrollo del plan de comunicaciones, con el cual se identificaron los involucrados del proyecto. Con base en el desarrollo de lo anterior fue posible identificar y planificar los riesgos del proyecto dando como resultado el registro de riesgos. Aunado a esto se desarrolló la investigación previa al plan de proyecto que describe y compara distintas metodologías y que justifica el uso de la metodología del PMI. Con base en los resultados anteriores se concluye que la falta de una cultura organizacional enfocada a proyectos y la falta de conocimiento en el tema de administración de proyectos en Fiserv Costa Rica ha afectado los proyectos anteriores a este, ya que no han tenido una planeación definida o una metodología que haya permitido su éxito. A falta de documentación de proyectos anteriores, el juicio de expertos jugó un papel importante en el desarrollo de cada capítulo, pues a través de entrevistas fue posible extraer las lecciones aprendidas y con ello tomar en cuenta esta información para la planeación de todo el proyecto. Dentro de las recomendaciones se tiene que es importante que se supervisen detalladamente los supuestos establecidos en este proyecto ya que son clave para el éxito de la planeación sugerida. Además se recomienda se use este plan de proyecto como base para proyectos futuros así como hacer un recuento de las lecciones aprendidas resultantes de este proceso para que queden almacenadas en el sistema Sayri. Es importante además considerar las áreas del conocimiento de calidad y adquisiciones para ser incluidas en planteamientos futuros según sea necesario. La capacitación en materia de administración de proyectos debe ser continua así como enfocar esfuerzos en coordinar procesos de trabajo con la casa matriz de Fiserv para evitar desorganización confusión en el desarrollo de proyectos conjuntos.
1
1 INTRODUCCION
1.1 Antecedentes
Fiserv, Inc. es el proveedor líder en administración de la información y sistemas de
comercio electrónico para la industria de servicios financieros. La compañía se
fundó el 31 de Julio de 1984 cuando las empresas Sunshine State Systems, Inc en
Tampa, Florida y First Data Processing ubicada en Milwaukee, Wis., se unieron
para formar Fiserv, la primera compañía en Estados Unidos en proveer servicios
financieros, con oficinas centrales en Milwaukee.
Los procesadores de datos regionales se combinaron para dar servicio a
pequeños bancos y compañías de ahorro, creciendo organizadamente y a través
de 150 adquisiciones, con un negocio de $21 millones, con 350 empleados y el
número uno en el ranking de Fin Tech 100, lista de compañías proveedoras de
servicios financieros.
En el 2007, Fiserv hace su más grande adquisición al comprar la Corporación
CheckFree, líder mundial de comercio financiero electrónico y el líder en proveer
servicios bancarios en línea y pagos electrónicos.
En Costa Rica, Fiserv abre operaciones en el año 2004 y provee soporte a
aplicaciones bancarias y de pagos en línea, trabajando en conjunto con las sedes
de Fiserv en Europa, Estados Unidos e India.
1.2 Problemática
A raíz del crecimiento de Fiserv, Inc en todo el mundo y dado que su principal
actividad se centra en el desarrollo de software para entidades financieras, surge
la necesidad de adquirir una serie de estándares de seguridad que garanticen la
seguridad de la información que se utiliza para llevar al cabo esta actividad.
Muchos clientes de Fiserv son importantes bancos en todo el mundo y empresas
de servicios financieros, donde se maneja información de carácter confidencial. El
uso de datos para tarjetas de crédito y débito es parte de la información necesaria
2
para poder dar soporte a las diferentes aplicaciones informáticas de los clientes en
muchos de los proyectos que maneja Fiserv.
Hoy en día y dado el aumento en el uso de aplicaciones web, la industria de
desarrollo de software, ha creado grandes estándares de seguridad de la
información, que permiten aumentar la confianza de los clientes en proveedores
certificados. Como parte de las políticas internas de la compañía, las oficinas
centrales de Fiserv en Brookfield, Winsconsin, han determinado que las diferentes
oficinas en todo el mundo deben estar certificadas en ISO 27001 para seguridad
de la información en general y por ende obtener la certificación PCI DSS.
Actualmente la compañía está en su proceso final de certificación de ISO 27001 y
por ello surge la necesidad de comenzar la planeación para el proceso de
certificación de PCI DSS para el año 2010. Esta certificación, fue creada por
compañías como Visa y Mastercard, para evitar el uso indebido de datos de
tarjetas de débito y crédito en bancos, comercios y proveedores que dan soporte a
sistemas financieros. Esta certificación es un complemento del sistema ISO
27001.
1.3 Justificación del problema
El presente PFG, se realiza con el fin de emplear la metodología del Project
Management Institute (PMI) en un proceso de certificación en Fiserv, Costa Rica.
Esto debido a que la cultura de Administración de Proyectos es inexistente en la
organización, pero imprescindible, dada la cantidad de proyectos que actualmente
se están empezando a desarrollar. Tomando en cuenta además, experiencias
pasadas de proyectos que se han realizado sin una metodología determinada
dentro de la compañía y cuyo resultado no fue exitoso, se realiza la propuesta del
Plan de Proyecto para la Certificación PCI DSS que se rige bajo la metodología
del PMI. De esta forma se pretende lograr un planeamiento ordenado y que sirva
de ejemplo para la futura planeación y ejecución de proyectos en Fiserv, Costa
Rica.
3
1.4 Objetivo general
Desarrollar un Plan de Proyecto para el proceso de Certificación de PCI DSS en
Fiserv Costa Rica en su etapa de análisis, para cumplir con los estándares de
seguridad de información dispuestos por la casa matriz de la compañía.
1.5 Objetivos específicos
• Desarrollar el acta de constitución del proyecto para asegurarse que el
proyecto incluya todo el trabajo requerido y completar el proyecto
satisfactoriamente.
• Desarrollar el cronograma del proyecto para garantizar la conclusión del
proyecto en el tiempo establecido.
• Desarrollar un Plan de Gestión del Personal para identificar y documentar
los roles del proyecto así como para saber cuándo y cómo se cumplirán los
requisitos de recursos humanos.
• Desarrollar un plan de comunicaciones para determinar las necesidades de
información y garantizar la buena comunicación de los interesados.
• Desarrollar un Plan de Gestión de Riesgos para aumentar la probabilidad e
impacto de los eventos positivos y disminuir la probabilidad e impacto de los
eventos adversos para el proyecto.
4
2 MARCO TEORICO
2.1 Marco referencial o institucional
Fiserv, Inc. ha establecido como política interna que sus oficinas en todo el mundo
obtengan la certificación PCI DSS para asegurar la información relacionada con
tarjetas de crédito y débito, desde su perspectiva de proveedor de servicios de
software en el área financiera. En el caso de las oficinas de Fiserv en Costa Rica
la gestión de esta certificación es un agregado a la certificación ISO 27001 que
actualmente está en proceso de implementación. (Fiserv, 2009)
2.1.1 Antecedentes de la Institución (Fiserv, 2009)
Fiserv, Inc. Inicia por la combinación de dos proveedores regionales de servicios
de proceso de datos en Estados Unidos para pequeños bancos y compañías de
ahorro, Sunshine State Systems, Inc en Tampa, Florida y First Data Processing
ubicada en Milwaukee, Wis.
Fiserv fue la primera en lanzar el concepto de “National Data Procesing” y ahora
es una corporación internacional. En 1986 la compañía era un procesador de
datos de 70 millones de dólares, creciendo mediante la adquisición de Minnesota
On-Line, Inc en 1988. Para los siguientes cuatro años, Fiserv servía a las
instituciones Financieras más grandes en los Estados Unidos.
Como una organización de servicios que necesita crecer, la compañía hizo una
selección de soluciones y buscó compañías rentables cuyos gerentes estuvieran
dispuestos a conllevar un buen trabajo con el apoyo de los recursos
proporcionados por Fiserv.
En 1990 Fiserv expandió sus capacidades de fondos electrónicos a través de la
adquisición de California-based GTE EFT Services Money Network y GTE ATM
Networks.
Con cada paso hacia delante el equipo de Fiserv se concentró en generar
soluciones de interés para sus clientes. Hoy en día, como parte de las 500
5
compañías multimillonarias de la revista Fortune 500, se ofrece a los clientes una
gran gama de soluciones innovadoras construida sobre los cimientos de la
arquitectura orientada a servicios y el apoyo de la más alta calidad de servicio al
cliente.
En el 2007 Fiserv adquiere la compañía CheckFree, líder mundial de pagos
electrónicos.
En el 2007, Fiserv adquiere la compañía CheckFree, líder en pagos electrónicos.
Como una de las más grandes adquisiciones de Fiserv, CheckFree trajo nueva
tecnología incluyendo Corillian y Carreker que ponía a Fiserv aparte de su
competencia. Esta combinación aumentó el pensamiento innovador, anticipándose
a las necesidades de sus clientes y desarrollando tecnología de punta.
En el 2009 Fiserv lanza una sola estrategia de marca, un solo nombre y una sola
identidad de marca
En Costa Rica, Fiserv abre operaciones en el año 2004 y provee soporte a
aplicaciones bancarias y de pagos en línea, trabajando en conjunto con las sedes
de Fiserv en Europa, Estados Unidos e India.
2.1.2 Misión y visión
Visión:
Ser el líder global en soluciones de tecnología basada en transacciones (Fiserv,
2009)
Misión:
Proveer tecnología integrada y soluciones de servicio que permiten resultados
best-in-class para nuestros clientes. (Fiserv, 2009)
6
2.1.3 Valores (Fiserv, 2009)
Ganar la confianza de los clientes cada día: participar plenamente con los
clientes como un socio activo. Ganarse su lealtad y confianza a través de cada
interacción, como prueba de las relaciones que se mantienen con los clientes. Ser
un defensor de su éxito.
Crear con un propósito: ser la chispa que encienda la innovación. Definir e
implementar nuevas formas de mejorar sobre cada experiencia, si se trata de un
proceso, producto o servicio que toca a nuestros clientes, sus clientes o sus
colegas. Inspirar a otros para apoyar y mejorar sus esfuerzos.
Inspirar y lograr excelencia: participar activamente, y entregar la más alta
calidad en todo lo que se hace. Tomar la iniciativa, y centrarse sin descanso en la
ejecución. Mantenerse a sí mismo y a otros responsables de resultados
superiores.
Hacer lo correcto: Ser honesto y directo en todos sus negocios. Tener el valor de
compartir constructivamente su punto de vista. Respeto a los demás, y estar
abierto a todas las personas y sus perspectivas.
Cumplir con la promesa de ser un solo Fiserv: Colaborar con los colegas a
través de toda la organización, para hacerlo fácil para los clientes y asociados a la
experiencia de todo Fiserv. Reconocer las oportunidades y el impacto de sus
acciones en Fiserv como un conjunto. Hacer las posibilidades realidad.
2.1.4 Estructura organizativa
La estructura organizativa de Fiserv en Costa Rica se divide básicamente en dos
áreas, el área administrativa y el área de producción o desarrollo. Esta segunda
área es la que se encarga de atender los proyectos de Fiserv Global Services, una
sección de Fiserv que trabaja proyectos de desarrollo de software específicos
7
junto con las 3 oficinas de Fiserv Global ubicadas en la India. Ver Figura No. 1
sobre la estructura organizativa de Fiserv Costa Rica.
Figura No.1. Estructura organizativa de Fiserv Costa Rica
2.1.5 Productos que ofrece
Fiserv, Inc. ofrece la siguiente gama de productos en todo el mundo (Fiserv,
2009):
Pagos:
Innovación de Pagos que crean eficiencia e impulsan el crecimiento. Para
instituciones Financieras y empresas que están experimentando un cambio en la
eficiencia. Fiserv impulsa el cambio poniendo a disposición de estas instituciones
sistemas de pagos electrónicos y soluciones basadas en la imagen.
Servicios de Procesamiento:
Soluciones de procesamiento de datos correspondientes a pagos y transacciones
que impulsan la eficiencia en la industria financiera. Soluciones que surgen de un
incalculable número de conexiones visibles e invisibles para los clientes cada día y
que requieren de alta seguridad para evitar pérdida de datos o información.
Riesgo y Cumplimiento:
8
Algunas de las cosas que las organizaciones financieras hacen - como prestar
dinero y administrar las inversiones - son las mismas cosas que pueden hacer a
estas organizaciones estar en gran riesgo. Fiserv controla los sistemas y
tecnologías de más tipos de riesgo que cualquier otra organización. Las
soluciones de Riesgo y Cumplimiento de Fiserv, no sólo le dan una visión
estratégica del riesgo en todos los canales de su negocio, sino también las
herramientas necesarias para minimizar la exposición y evitar pérdidas
Cliente y Administración de Canales:
Como el mayor proveedor mundial de servicios de tecnología de la información de
la industria financiera, Fiserv expone las soluciones que hacen uso de las nuevas
tecnologías para llegar a los clientes donde viven, trabajan y se entretienen a
través de la banca en línea, banca móvil, banca telefónica, apertura de cuentas y
pagos a través de Internet.
Inteligencia de Negocios y Optimización:
Las instituciones financieras utilizan las soluciones de Fiserv para obtener una
visión más completa de su posición en el mercado, una mejor comprensión de sus
clientes y una clara visión estratégica para obtener una ventaja competitiva.
Plataformas Bancarias:
Con clientes en más de 66 países en todo el mundo, las plataformas bancarias de
Fiserv crean eficiencia usando la optimización de procesos estratégicos,
mejorando el rendimiento por toda la organización con el uso de herramientas
especializadas que hacen posible el servicio-orientado a la arquitectura.
Plataformas de Credit Union:
9
Las plataformas de Credit Union van más allá de hacer depósitos y préstamos,
abarcan herramientas de tecnología que sirven como base para el crecimiento de
cualquier compañía.
Soluciones de Pago:
Sistemas diseñados para pagos de facturas y otros pagos a través de Internet.
Soluciones Club
Software diseñado para realizar el manejo de clubes ya sea de salud o fitness.
Servicios de Inversión:
Los servicios de inversión de Fiserv, ayudan a navegar por complejos problemas
operacionales y así mejorar el rendimiento y rentabilidad. Reduce el riesgo,
aumenta ingresos y disminuye los costos, ampliando las posibilidades de
crecimiento.
2.2 Teoría de Administración de Proyectos
En el entorno del desarrollo de proyectos es poco común concebir proyectos
terminados a tiempo, dentro del presupuesto y con la calidad esperada; por lo
general se cumple uno o dos de estos requerimientos pero con mucho desgaste.
Actualmente para considerar exitoso un proyecto se necesita cumplir y superar las
expectativas de los clientes, lo cual implica concluir en el tiempo establecido,
dentro del presupuesto de acuerdo con los requerimientos de calidad estipulados y
desarrollando relaciones a largo plazo con los proveedores y demás integrantes
del equipo.
La administración empírica, intuitiva y tradicional no provee las bases necesarias
para cumplir con éxito esos objetivos y debemos recurrir a procedimientos,
técnicas y herramientas más efectivas que logren hacer predecibles los resultados
en nuestros proyectos.
10
La administración de proyectos es más que solo distribuir asignaciones de trabajo
a personas y esperar que de alguna manera logren un resultado esperado. De
hecho proyectos que podrían haber tenido éxito, con frecuencia fracasan, debido a
que estos métodos se dan por hecho.
Sin embargo, es a través de una adecuada metodología de proyectos que los
resultados del mismo se pueden planear con facilidad y hasta tener un mayor
grado de certeza en cada cosa que se planea, de manera que cualquier estrategia
que resulte de una correcta planeación tiene un mayor grado de éxito y menos
posibilidades de enfrentar riesgos inesperados que puedan llevar al proyecto al
fracaso.
En la actualidad se pueden encontrar diferentes metodologías de administración
de proyectos, con enfoques diferentes en cada una, que debe ser evaluada para
determinar cuál se ajusta a las diferentes organizaciones donde se dirigen
proyectos. Algunas de estas metodologías son:
• PMI PMBOK: (Project Managment Body Of Knowledge), este es la
metodología propuesta por la asociación Project Managment Institute (PMI),
es un estándar ampliamente difundido en EEUU. (PMI, 2008)
• PRINCE2: (Projects in Controlled Enviroments), es la metodología
propuesta por el Gobierno Ingles, y ampliamente difundida en Europa.
(OGC, 2009)
• XP: (eXtreme Programing), es la metodología mas difundida de la
asociación Agile, que agrupa varias metodologías de respuesta rápida y
altamente flexibles. (Wells, 2009)
• P2M: (Project & Program Management for Enterprise Innovation), es el
estándar de administración de proyectos Japonés. (PMAJ, 2007)
• V-Model: es el modelo alemán promovido por el Gobierno, y el ministerio
de defensa de ese país. (IABG, 2004)
11
A continuación una descripción de las bases que refuerzan a cada metodología.
2.2.1 PRINCE2
Cubre la forma de organizar, gestionar y controlar los proyectos. Su objetivo es
llevar el éxito de los productos correctos, a tiempo y dentro del presupuesto.
Ayudará a gestionar el riesgo, control de calidad y el cambio de manera efectiva,
así como aprovechar al máximo las situaciones difíciles y las oportunidades que
surgen dentro de un proyecto. PRINCE (cuyo significado por sus siglas en inglés
es, Projects in Controlled Environments o Proyectos en Ambientes Controlados)
fue desarrollado por el gobierno del Reino Unido en 1989 como el método
estándar para la gestión de proyectos de TI para el gobierno central. Desde
entonces, el método se ha mejorado para convertirse en un enfoque de mejores
prácticas en forma general, adecuados para la gestión de todo tipo de proyectos, y
tiene un historial probado fuera de TI y los sectores gubernamentales. (OGC,
2009)
Un proyecto de PRINCE2 tiene las siguientes características (principios):
• Continuidad a la justificación del negocio
• Aprender de la experiencia
• Funciones y responsabilidades definidas
• Gestionado por etapas
• Gestionado por excepciones
• Se centra en los productos y su calidad
• Se adapta al medio ambiente del producto en particular
Los enfoques para ofrecer estos principios se exponen en 7 temas:
• Caso de negocio
• Organización
• Calidad
12
• Planes
• Riesgos
• Cambios
• Progreso
Y fluyen a través de los siguientes procesos:
• Puesta en marcha del proyecto
• Dirigir un proyecto
• Iniciar un proyecto
• Controlar una etapa
• Gestionar los límites de la etapa
• Cerrar el proyecto
PRINCE2 no cubre todos los aspectos de la gestión de proyectos. Áreas como el
liderazgo y los conocimientos de gestión, la cobertura detallada de las
herramientas de gestión de proyectos y técnicas están bien cubiertos por los otros
métodos de eficacia demostrada y por lo tanto excluidos de PRINCE2. La gran
fortaleza de PRINCE2 es su capacidad de adaptarse al ambiente del proyecto, es
decir a la organización donde el proyecto se desarrollará. No da una respuesta
específica al “Como” pues no ejerce fuerza en el control del proyecto, si no que
está fuertemente guiado a los objetivos del negocio y es con base a este que el
proyecto se desarrolla.
2.2.2 XP
El primer proyecto de Extreme Programming (XP), se inició el 6 de marzo de 1996.
Extreme Programming es uno de varios procesos de la Asociación Agile. Ya se ha
demostrado ser muy exitoso en muchas empresas de todos los tamaños e
industrias en todo el mundo. Funciona para proyectos dedicados al desarrollo de
software. Este hace hincapié en la satisfacción del cliente y faculta a los
13
desarrolladores con confianza a responder a las cambiantes necesidades de los
clientes, incluso a finales del ciclo de vida.
XP se enfoca en el trabajo en equipo. Los administradores, clientes y
desarrolladores son socios iguales en un equipo de colaboración. Además con XP
se implementa un equipo simple, pero efectivo en un medio ambiente propicio
para llegar a ser altamente productivo. El equipo se auto-organiza en torno al
problema a resolver de la forma más eficiente posible. (Wells, 2009)
Las etapas del XP son las siguientes:
• Planeación
• Administración
• Diseño
• Codificación
• Pruebas
El XP se rige por reglas en cada una de las etapas indicadas y estas son las
bases de esta metodología:
Planeación:
• Las historias de usuarios (forma de documentar requisitos), son escritas por
el cliente, usando un lenguaje común y no técnico.
• Una reunión de planeación se lleva a cabo para fijar las reglas del proyecto
y negociar el cronograma de trabajo. Esta reunión da pie al cronograma de
trabajo.
• Se realizan pequeños entregables. El proyecto es divido en entregables
pequeños desarrollables en periodos cortos de tiempo.
• El proyecto es dividido en iteraciones y cada una lleva un entregable.
• La planificación de cada iteración inicia cada iteración.
Administración:
14
• Dar al equipo un ambiente de trabajo abierto.
• Establecer un buen ritmo de trabajo, tomando muy enserio el fin de cada
iteración y planeando cada iteración seriamente. Si una iteración no puede
ser terminada a tiempo, se debe hacer un replanteamiento de esos
objetivos para reubicar esfuerzos.
• Una reunión comienza cada día de trabajo.
• La velocidad del proyecto es medida.
• Mover gente alrededor del proyecto de manera que se nivele el
conocimiento en todo el equipo. De esta forma todos son capaces de
prestar apoyo en todas las áreas sin tener que depender de un solo
miembro del equipo.
• Arreglar el XP cuando sea necesario. Reorganizar y analizar las reglas del
XP nuevamente para hacer cambios.
Diseño:
• Simplicidad.
• Escoger una metáfora de cómo funcionará el sistema.
• Usar el modelo CRC cards para diseñar el sistema en equipo. Es un
modelo utilizado para el diseño de software.
• Utilizar soluciones “Spike”. Una solución Spike, es un programa que permite
explorar las diferentes soluciones a un problema.
• Ninguna funcionalidad es agregada antes de tiempo.
• Remover lo que no se usa dentro del código para mantener el diseño
siempre sencillo y manejable.
Codificación:
• El cliente está siempre disponible.
• El código debe ser siempre escrito siguiendo los estándares.
15
• Codificar el Unit Test primero. Unit Test se refiere a las pruebas hechas por
los desarrolladores a su propio código.
• Todo el código que va a producción es escrito entre dos recursos usando
una sola computadora.
• Todos los recursos pueden hacer cambios o correcciones para evitar
cuellos de botella.
Pruebas:
• Todo programador debe probar su propio código primero (Unit Testing).
• El código debe pasar las pruebas de Unit Testing antes de ser liberado.
• Cuando un error es encontrado se deben diseñar las pruebas apropiadas.
• Las pruebas de aceptación deben ser corridas constantemente y las
calificaciones deben ser publicadas.
El XP se concentra en el trabajo día a día. Las cualidades de liderazgo del Director
de Proyecto son esenciales para mantener un buen trabajo en equipo. Dado que
no hay mucho tiempo para planificación, la comunicación se vuelve un factor
importante para afrontar cambios diarios en requerimientos y funcionalidad de los
sistemas.
2.2.3 P2M
El término "P2M" es por sus siglas en inglés la abreviatura de Project & Program
Management for Enterprise Innovation, o de "Gestión de Proyecto y de Programas
para la Innovación Empresarial".
El P2M fue desarrollado por el Comité de Investigación y Desarrollo en Gestión de
Proyectos de la Asociación de Promoción de Ingeniería de Japón (ENAA), en
respuesta a una comisión del Ministerio de Economía, Comercio e Industria.
El objetivo del P2M es proporcionar directrices para la innovación empresarial a
través del programa y gestión de proyectos, y está destinado a servir como una
16
guía para ayudar al crecimiento de la empresa, la competencia y la supervivencia
en el negocio global de servicios públicos y medio ambiente, como complemento
de los repositorios de conocimiento y competencia de los estándares de otros
cuerpos de gestión de proyectos internacionales. El P2M está diseñado como una
guía para la gestión de proyectos en Japón, con el objetivo de crear conciencia
acerca de los "avances" y "las capacidades prácticas" que son requeridos por una
sociedad de conocimiento intensivo de la información. En consonancia con los
estándares mundiales, el P2M está diseñado para fomentar un cambio de
paradigma que va a generar nuevos valores y formas de pensar.
La interpretación que se le da al estándar común de gestión de proyectos es la
aplicación de un sistema de pensamiento, sabiduría, procedimientos y métodos
para dar valor a un tema específico, usando un equipo de proyecto de la
organización con un período de tiempo limitado. El P2M va más allá del alcance
de otros estándares oficiales de Administración de Proyectos, abarcando también
la gestión de programas. Esto es importante porque las aplicaciones
empresariales de gestión del proyecto van más allá de una base simple para los
proyectos de ingeniería independiente, ya que debe abarcar la complejidad y las
interrelaciones que requieren un enfoque de programa para la consolidación y
gestión de proyectos. (PMAJ, 2002).
Con el P2M, no solo se gestionan proyectos sino Portafolios de Proyectos que
deben estar relacionados entre sí, para lograr un objetivo común, previamente
identificado por la alta gerencia y que de finalizarse con éxito generará un valor a
toda la organización. De la estrategia corporativa de la empresa, sale un objetivo
que se desglosará en proyectos que juntos formen el portafolio de trabajo. Si los
proyectos dentro del programa no están relacionados, no pueden considerarse
parte del mismo y por ende parte de la metodología del P2M.
Dominio de la P2M
17
El enfoque del P2M es reconocer tres tipos de proyectos que consisten en 1) el
desarrollo de conceptos (modelo de esquema), 2) la aplicación (modelo de
sistema) y 3) funcionamiento (modelo de servicio) y para generar modelos de
negocio diversificados, creativos y sinérgicos. Estos modelos de negocio pueden
ser vistos como uno de los aportes de la gestión de programa en el que una
empresa adapta su sabiduría, los conocimientos acumulados y los datos para
responder a los cambios ambientales. Los modelos de negocio requieren un
nuevo concepto de integración de proyectos alineados con la gestión de
empresas, que abarca los principios básicos, la integración, la comunidad y la
estructura. Los lectores pueden utilizar el P2M para guiarse en la creación de
programas, la identificación de los conocimientos específicos de un proyecto o
proceso, y de forma sistemática, eficaz e integralmente el diseño de un enfoque de
gestión. (PMAJ, 2002).
Definición de Programa
En P2M, un programa se define como "una empresa en la cual un grupo de
proyectos están orgánicamente combinados para el logro de una misión global."
Varios proyectos que son independientes o débilmente relacionados entre sí no se
consideran como un programa. En un programa, el concepto y los requisitos
fundamentales de creación de valor para una empresa propuesto por un
empresario o del titular, está representado por una serie de proyectos agrupados
de manera significativa, que constituyen el programa. (PMAJ, 2002).
La diferencia entre la gestión de un proyecto y un programa se aprecia en el
Cuadro No.1.
18
Cuadro No.1. Comparación entre la gestión de proyectos y la gestión de programas
Administración de
Proyectos Administración de
Programas
Definición Valor de empresa creativa basada en una misión específica
Empresa de creación de valor basado en una misión integral
Actitud Básica Único, de naturaleza temporal e incertidumbre
Multiplicidad, escalabilidad, complejidad, incertidumbre
Vista Común
Enfoque de sistemas Ciclo de vida del proyecto Espacio mental de proyectos Involucrados del proyecto Uso de habilidades de gestión
Misión de Programa Valor de Programa Comunidad de Programa, Arquitectura del Programa Habilidades en Gestión de integración de programas
2.2.4 V-Model
El V-Model o Modelo-V regula todas las actividades y productos, así como los
estados de los productos y las interdependencias lógicas entre actividades y
productos durante el proceso de desarrollo de sistemas de TI del sistema y el
mantenimiento y la modificación de las Tecnologías de la Información.
El Modelo-V se estructura en cuatro submodelos:
1. Desarrollo del sistema (SD)
2. Aseguramiento de Calidad (QA)
3. Gestión de la Configuración (CM)
4. Gestión de Proyectos (PM)
El Modelo-V describe el proceso de desarrollo desde un punto de vista funcional.
No describe los modelos de organización especial, ya que se utilizarán en las
diferentes organizaciones / empresas. Por lo tanto, es necesario para un proyecto
concreto para determinar el personal a cargo o el órgano de las unidades
organizacionales para las tareas (“actividades") que figura en el modelo de V.
(IABG, 1997)
La Figura No. 2 muestra la estructura del Modelo –V según sus submodelos.
19
Configuration
Structure
Planning and
Controlling the Project
PM
SD
QA CM
Plan Data Actual Data SDE
SDE
QA
Result
Actual
Data
QA Requirement
Product
Product
Development
Specification of
QA Requirements
Product
Assessment
Administration of
Products/
Rights
Planning Product
Structure
Plan
Data SDE SDE
Plan
Data
Plan
Data
Actual
Data
Actual
Data
Product
Rights
Setting up Prerequisites
and Availability of Software
Development Environment (SDE)
Figura No.2. Submodelos del Modelo-V
Este es pues, un modelo en cascada donde una fase no inicia hasta que haya
terminado la anterior. Por la complejidad de sus submodelos es un modelo de
proyecto donde se ejerce un fuerte control en cada etapa del proyecto
aumentando la capacidad de predicción. Controla fuertemente la etapa de
requerimientos y diseño del sistema que es parte de las etapas iniciales y con ello
se reduce el riesgo de falta, cambio o poco entendimiento de los requerimientos
del sistema. Sin embargo, por ser cada una de sus etapas muy detalladas el
desarrollo del proyecto es menos flexible y por ende aumenta por mucho el tiempo
en que se desarrolla el proyecto. Implica además la participación de
departamentos de calidad y pruebas del sistema en etapas tempranas. Este
departamento forma parte importante en la planeación del proyecto. Cada
entregable que resulta de cada etapa de proyecto es revisado y analizado por el
departamento de calidad, disminuyendo así la probabilidad de grandes errores en
20
las etapas finales de proyecto, donde el costo de arreglar errores se incrementa.
En resumen es un modelo que ejerce fuerte presión y control en las primeras
etapas para así hacer una detección temprana de errores y de información y con
ello reducir costos hacia el final del proyecto.
2.2.5 Conclusiones sobre los Modelos de Administración de Proyectos
Según lo expuesto y analizado anteriormente se tiene las siguientes conclusiones
sobre los diferentes modelos:
• Los modelos XP y V-Model fueron creados exclusivamente para el área de
Desarrollo de Software. El XP es un modelo flexible cuyo objetivo es dividir
el proyecto en varias iteraciones para dividir el software en pequeños
entregables. Esto permite que los cambios constantes que se puedan
presentar puedan ser mejor manejados y controlados. Dado que es un
trabajo del día a día las habilidades de liderazgo son de suma importancia
para el Director del Proyecto, pues debe mostrar mucho liderazgo para
manejar eficientemente a los equipos de proyecto y poder terminar a tiempo
cada pequeña iteración que suele no durar más de 3 semanas. Por el
contrario el V-Model no es tan flexible como el XP. Refuerza mejor la
planeación del proyecto, aspecto que no se maneja bien en XP, pero no
divide el desarrollo del software en pequeños entregables, por el contrario
solo hay un entregable final. Ejerce mucho control en cada etapa y por su
estructura requiere de más tiempo para finalizarse, pues cada etapa
conlleva revisiones constantes y participación de un equipo de calidad. En
el V-Model las competencias de liderazgo no son tomadas en cuenta como
en otros modelos, por ejemplo el PMI.
• PRINCE2 como modelo de administración de proyectos aplicable en todas
las áreas, se centra en el control del tiempo, calidad y costos a través de
una buena gestión de cambios. Esto le permite aprovechar mejor las
21
oportunidades que se presentan durante el desarrollo del proyecto. No es
tan detallado como la metodología del PMI donde también se manejan el
tiempo, el costo y la calidad, ya que a diferencia de PRINCE2, el PMI
incluye herramientas y técnicas aplicadas a los diferentes procesos en sus
diferentes áreas. PRINCE2 tampoco presta atención al liderazgo y
conocimientos de gestión de proyectos, pues está basado en lo que un jefe
“debe hacer” y define los pasos a seguir para lograr un proyecto exitoso. La
metodología del PMI se basa, por el contrario, en lo que un jefe de
proyectos “debe saber”, enfocado en los estándares y buenas prácticas,
tomando en cuenta las habilidades de liderazgo. Otra característica
importante de PRINCE2 es su capacidad de adaptarse al ambiente del
proyecto, es decir, que toma muy en cuenta a la organización (objetivos del
negocio) donde el proyecto es desarrollado, de hecho este es un pilar
fundamental, desarrollar el proyecto adaptándose a la organización y
evitando diferencias que puedan perjudicar al proyecto. El PMI por su parte
está basado en el “know how” (conocimiento) que en su aplicación está
menos enfocado en las necesidades del negocio, aunque incluye como
entradas en cada uno de sus procesos a la organización, puede no
adaptarse a esta y por el contrario ofrecer un cambio positivo en ella, no
depende de la organización al 100% para llevarse al cabo. PRINCE2
además, no ofrece respuesta al “Como” pues no ejerce fuerza en el control
del proyecto como si lo hace el PMI. Por otra parte la estructura del
proyecto tiene mucho énfasis en PRINCE2, mientras que en el PMI no hay
estructura definida.
• P2M es una metodología no solo enfocada al proyecto en sí, sino en los
programas de proyectos. Extiende una serie de estándares que le permiten
a una organización crear portafolios de proyectos orientados a alcanzar
objetivos específicos para la mejora de la estrategia empresarial. Desde
esta perspectiva de programas es que luego se extienden estándares para
22
el manejo de cada uno de los proyectos contenidos en el programa, que
además deben estar muy relacionados entre sí para cumplir con los
objetivos estratégicos. Se apoya de otras metodologías de Administración
de Proyectos para el manejo de cada proyecto. Esta es la gran fortaleza de
P2M, que a diferencia de las demás metodologías se centran en el manejo
de programas y no tanto de proyectos específicos.
2.2.6 Beneficios de la Administración de Proyectos para las organizaciones
Dentro de los beneficios que tiene la Administración de Proyectos se encuentran
los siguientes:
• Tener un cliente satisfecho, tanto si se es el cliente del propio proyecto.
• El completar el alcance total de un proyecto con calidad, a tiempo y dentro
del presupuesto, proporciona una gran satisfacción.
• Tomar mejores decisiones de una forma planificada para la organización
• Realizar proyectos de inversión viables.
• Expandir y diversificar el negocio.
• Minimizar el costo de realización de un proyecto.
• Maximizar la eficiencia en el tiempo de realización de un proyecto.
2.2.7 Metodología del PMI
A continuación se describe la Administración de Proyectos desde la perspectiva
del PMI. Esta es la metodología elegida para la planeación del proyecto en
gestión.
2.2.8 Proyecto
Con base en la metodología del Project Management Institute (PMI) en su libro
PMBOK (PMI, 2004, p. 5), se entiende por proyecto como “un esfuerzo temporal
que se lleva a cabo para crear un producto, servicio o resultado único.”
23
Por temporal se entiende que cada proyecto tiene un comienzo definido y un final
definido. El final se alcanza cuando se han logrado los objetivos del proyecto o
dado el caso contrario cuando estos objetivos no pueden ser alcanzados pero se
llega a este entendimiento en algún punto del proyecto y por ende el proyecto es
cancelado. Esta característica de temporalidad no es aplicable al producto,
servicio o resultado creado por el proyecto. Temporal no necesariamente significa
corta duración; muchos proyectos pueden durar años.
Por producto, servicio o resultados únicos, se entiende que cada proyecto arroja
algo diferente, aún que se construyan varios edificios iguales, el proceso que lleva
a realizar cada uno es distinto, ya que tienen diferente dueño, diseño, ubicación,
diferentes contratistas en otros. Esta es una singularidad importante de los
proyectos. La presencia de elementos repetitivos no cambia la condición
fundamental de único del trabajo de un proyecto.
Los proyectos por ende pueden crear:
• Un producto o artículo producido, que es cuantificable y que puede ser un
elemento terminado o un componente.
• La capacidad de prestar un servicio como, por ejemplo, las funciones del
negocio que respaldan la producción o la distribución
• Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un
proyecto de investigación se obtienen conocimientos que pueden usarse
para determinar si existe o no una tendencia o si un nuevo proceso
beneficiará a la sociedad.
Finalmente la elaboración gradual es otra característica que acompaña a los
conceptos de temporal y único. “Elaboración gradual” significa desarrollar en
pasos e ir aumentando mediante incrementos.
24
La dirección o administración de proyectos es la aplicación de conocimientos,
habilidades, herramientas y técnicas a las actividades de un proyecto para
satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante
la aplicación e integración de los procesos de dirección de proyectos de inicio,
planificación, ejecución, seguimiento y control y cierre. Dentro de este contexto el
director de proyecto es la persona responsable de alcanzar los objetivos del
proyecto. (PMI, 2004)
La dirección de proyectos incluye:
• Identificar los requisitos
• Establecer unos objetivos claros y posibles de realizar
• Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos
• Adaptar las especificaciones, los planes y el enfoque a las diversas
inquietudes y expectativas de los diferentes interesados
2.2.9 Administración de Proyectos según el PMI
La dirección o administración de proyectos es la aplicación de conocimientos,
habilidades, herramientas y técnicas a las actividades de un proyecto para
satisfacer los requisitos del proyecto. La dirección de proyectos se logra mediante
la aplicación e integración de los procesos de dirección de proyectos de inicio,
planificación, ejecución, seguimiento y control y cierre. Dentro de este contexto el
director de proyecto es la persona responsable de alcanzar los objetivos del
proyecto. (PMI, 2004)
La dirección de proyectos incluye:
• Identificar los requisitos
• Establecer unos objetivos claros y posibles de realizar
• Equilibrar las demandas concurrentes de calidad, alcance, tiempo y costos
• Adaptar las especificaciones, los planes y el enfoque a las diversas
inquietudes y expectativas de los diferentes interesados
25
2.2.10 Áreas del Conocimiento de la Administración de Proyectos
Según el PMBOK (PMI, 2004), las áreas del conocimiento de la Administración de
Proyectos organizan los 44 procesos de dirección de proyectos de los Grupos de
Procesos en nueve áreas de conocimiento y son:
Gestión de la Integración del Proyecto: describe los procesos y actividades que
forman parte de los diversos elementos de la dirección de proyectos, que se
identifican, definen, combinan, unen y coordinan dentro de los Grupos de
Procesos de la Dirección de Proyectos.
Gestión del Alcance del Proyecto: describe los procesos necesarios para
asegurarse de que el proyecto incluya todo el trabajo requerido, y solo el trabajo
requerido, para completar el proyecto de forma satisfactoria.
Gestión del Tiempo del Proyecto: describe los procesos relativos a la
puntualidad en la conclusión del proyecto.
Gestión de los Costos del Proyecto: describe los procesos involucrados en la
planificación, estimación, presupuesto y control de costos de forma que el
proyecto se complete dentro del presupuesto aprobado.
Gestión de la Calidad del Proyecto: describe los procesos necesarios para
asegurarse de que el proyecto cumpla con los objetivos por los cuales ha sido
emprendido.
Gestión de los Recursos Humanos del Proyecto: describe los procesos que
organizan y dirigen el equipo del proyecto.
26
Gestión de las Comunicaciones del Proyecto: describe los procesos
relacionados con la generación, recogida, distribución, almacenamiento y destino
final de la información del proyecto en tiempo y forma.
Gestión de los Riesgos del Proyecto: describe los procesos relacionados con el
desarrollo de la gestión de riesgos de un proyecto.
Gestión de las Adquisiciones del Proyecto: describe los procesos para comprar
o adquirir productos, servicios o resultados, así como para contratar procesos de
dirección.
Para efectos de la presente tesina las áreas del conocimiento que se desarrollarán
son los siguientes: Gestión de la Integración, Gestión del Alcance, Gestión del
Tiempo, Gestión de los Recursos Humanos, Gestión de las Comunicaciones y
Gestión de los Riesgos del Proyecto.
2.2.11 Ciclo de vida de un proyecto
Para hacer más fácil la gestión de la administración de proyectos, los directores de
proyecto dividen el proyecto en fases. Estas pueden variar según las necesidades
de los proyectos. Existen organizaciones que han identificado un ciclo de vida
específico para ser usado en todos sus proyectos. Algunas de las características
del ciclo de vida incluyen que las fases conectan al inicio con el fin. Esto también
puede ayudar a un director de proyecto a tomar la decisión de si un posible
proyecto puede ser solo la fase inicial o como un proyecto separado o
independiente. Las fases de un proyecto no es lo mismo que los Grupos de
Procesos de Dirección de Proyectos tal como se puede apreciar en la Figura No.3.
27
Figura No.3. Secuencia de fases típicas en el ciclo de vida de un proyecto
Según el PMBOK (PMI, 2004), los ciclos de vida de un proyecto generalmente
definen:
• Qué trabajo técnico se debe realizar en cada fase (por ejemplo, ¿en qué
fase se debe realizar el trabajo del arquitecto?)
• Cuándo se deben generar los productos entregables en cada fase y cómo
se revisa, verifica y valida cada producto entregable
• Quién está involucrado en cada fase (por ejemplo, la ingeniería concurrente
requiere que los implementadores estén involucrados en las fases de
requisitos y de diseño)
• Cómo controlar y aprobar cada fase.
La mayoría de ciclos de vida comparten las siguientes características:
28
• Generalmente las fases son secuenciales, y pueden estar definidas por
alguna forma de transferencia de información técnica o transferencia de
componentes técnico al finalizar cada fase normalmente se suele dar una
revisión para comprobar que los productos entregables de cada fase estén
completos y cumplen con los requerimientos. Aunque en muchos casos las
fases son secuenciales, hay proyectos donde una fase puede comenzar
antes de que la anterior termine, cuando los riesgos considerados se
consideran aceptables.
• El ciclo suele caracterizarse por el bajo costo económico y de personal al
comienzo que se va incrementando al pasar a las fases intermedias y es
aquí donde alcanza su punto máximo para bajar nuevamente hacia la
conclusión del proyecto.
• El nivel de incertidumbre también juega un papel importante en las fases
iniciales y se va minimizando conforme el proyecto avanza hacia las fases
intermedias.
• Los cambios que puedan generar los interesados del proyecto es más alto
al inicio y se minimiza conforme avanza el proyecto. Sin embargo, aunque
la influencia de los interesados es mayor al inicio el costo de los cambios se
incrementa conforme avanza el proyecto.
2.2.12 Procesos en la Administración de Proyectos
Tal y como lo aplica el PMI, la dirección de procesos se logra mediante la
ejecución de procesos. El PMBOK (PMI, 2004) contempla 44 procesos distribuidos
en los 5 Grupos de Procesos: Grupo de Procesos de Iniciación, Planificación,
Ejecución, Seguimiento y Control y Cierre. Aunque los procesos de cada grupo
están bien definidos en la práctica se superponen e interactúan hasta de forma
repetitiva, muchos procesos son reiterados y revisados durante el proyecto. Estos
procesos en su forma de interactuar a lo largo de las fases del proyecto, tienen
una interacción similar al ciclo Planificar-Hacer-Revisar-Actuar, (según el concepto
29
de Shewart, modificado por el Dr. W. Edwards Deming). En donde el resultado de
una parte del ciclo se convierte en la entrada de otra. Este ciclo se puede observar
en la Figura No.4.
Actuar Planificar
HacerRevisar
Figura No.4. El ciclo planificar-hacer-revisar-actuar
Para efectos de este PFG, se desarrollarán los siguientes procesos que se
encuentran dentro del grupo de procesos de Planificación divididos en cada una
de las áreas de conocimiento, explicadas en la sección 2.2.4, y que se incluirán en
este trabajo. PMBOK (PMI, 2004):
Integración:
• Desarrollar el Acta de Constitución del Proyecto: es el documento que
autoriza formalmente un proyecto. El acta de constitución del proyecto confiere al
director del proyecto la autoridad para aplicar recursos de la organización a las
actividades del proyecto.
• Desarrollar el Enunciado del Alcance del Proyecto Preliminar: El
enunciado del alcance del proyecto es la definición del proyecto, los objetivos que
30
deben cumplirse. El proceso Desarrollar el Enunciado del Alcance del Proyecto
Preliminar aborda y documenta las características y los límites del proyecto, y sus
productos y servicios relacionados, así como los métodos de aceptación y el
control del alcance.
• Desarrollar el Plan de Gestión del Proyecto: El proceso Desarrollar el
Plan de Gestión del Proyecto incluye las acciones necesarias para definir, integrar
y coordinar todos los planes subsidiarios en un plan de gestión del proyecto. El
contenido del plan de gestión del proyecto variará de acuerdo con el área de
aplicación y la complejidad del proyecto.
Alcance:
• Planificación del Alcance: Es el proceso necesario para crear un plan de
gestión del alcance del proyecto que documente cómo se definirá, verificará y
controlará el alcance del proyecto, y cómo se creará y definirá la estructura de
desglose del trabajo.
• Definición del Alcance: Es el proceso necesario para desarrollar un
enunciado detallado del alcance del proyecto como base para futuras decisiones
del proyecto.
• Crear EDT: Es el proceso necesario para subdividir los principales
productos entregables del proyecto y el trabajo del proyecto en componentes más
pequeños y más fáciles de gestionar.
Tiempo:
• Definición de las Actividades: Es el proceso necesario para identificar las
actividades específicas que deben realizarse para producir los diversos productos
entregables del proyecto.
• Establecimiento de la Secuencia de las Actividades: Es el proceso
necesario para identificar y documentar las dependencias entre las actividades del
cronograma.
31
• Estimación de Recursos de las Actividades: Es el proceso necesario
para estimar los tipos y las cantidades de recursos necesarios para realizar cada
actividad del cronograma.
• Estimación de la Duración de las Actividades: Es el proceso necesario
para estimar la cantidad de períodos laborables que se requerirán para completar
cada actividad del cronograma.
• Desarrollo del Cronograma: Es el proceso necesario para analizar las
secuencias de las actividades, la duración de las actividades, los requisitos de los
recursos y las restricciones del cronograma para crear el cronograma del proyecto.
Recursos Humanos:
• Planificación de los Recursos Humanos: Es el proceso necesario para
identificar y documentar los roles dentro del proyecto, las responsabilidades y las
relaciones de comunicación, así como para crear el plan de gestión de personal.
Comunicaciones:
• Planificación de las Comunicaciones: Es el proceso necesario para
determinar las necesidades con respecto a la información y las comunicaciones de
los interesados en el proyecto.
Riesgos:
• Planificación de la Gestión de Riesgos: Es el proceso necesario para
decidir cómo abordar, planificar y ejecutar las actividades de gestión de riesgos
para un proyecto.
• Identificación de Riesgos: Es el proceso necesario para determinar qué
riesgos podrían afectar al proyecto y documentar sus características.
• Análisis Cualitativo de Riesgos: Es el proceso necesario para priorizar los
riesgos para realizar otros análisis o acciones posteriores, evaluando y
combinando la probabilidad de ocurrencia y el impacto.
32
• Análisis Cuantitativo de Riesgos: Es el proceso necesario para analizar
numéricamente el efecto de los riesgos identificados en los objetivos generales del
proyecto.
• Planificación de Respuesta a los Riesgos: Es el proceso necesario para
desarrollar opciones y acciones para mejorar las oportunidades y reducir las
amenazas a los objetivos del proyecto.
2.3 Certificación PCI DSS
La seguridad de la información de titulares de tarjetas se ha convertido en una
verdadera preocupación en todo el mundo, tanto para los bancos que emiten de
tarjetas de pago como para los comercios que las aceptan y por supuesto, para
los clientes que las utilizan.
En muchos países, se han producido casos en los cuales delincuentes acceden a
sistemas informáticos, roban la información de tarjetas y utilizan estos datos para
cometer fraudes. En la mayoría de los casos, estos sistemas informáticos han sido
operados por comercios que aceptan tarjetas de pago o por vendedores que
procesan pagos en su nombre. Como respuesta a este problema, Visa ha
desarrollado las Normas de Seguridad de la Información de la Industria de Medios
de Pago (PCI DSS) en colaboración con Mastercard. Se trata de un conjunto de
exigencias y procesos comunes a todo el sector respaldado por todos los
principales sistemas internacionales de tarjetas de pago.
El núcleo de la PCI DSS es un conjunto de principios y requisitos de
acompañamiento, en torno a la cual los elementos específicos de la DSS se
organizan, y se tienen entonces los siguientes requerimientos (PCI Security
Standards Council, 2009):
33
Construir y mantener una red segura
• Requisito 1: Instalar y mantener una configuración de cortafuegos para
proteger la tarjeta de datos
• Requisito 2: No utilizar sistemas de contraseñas y otros parámetros de
seguridad suministrados por el defecto por un proveedor
Proteger la tarjeta de datos
• Requisito 3: Proteger los datos titulares almacenados
• Requisito 4: Cifrar la transmisión de datos de tarjetas por, las redes públicas
o abiertas
Mantener un Programa de Manejo de Vulnerabilidad
• Requisito 5: Usar y actualizar periódicamente el software anti-virus
• Requisito 6: Desarrollar y mantener sistemas de seguridad y aplicaciones
Aplicar fuertes medidas de control de acceso
• Requisito 7: Restringir el acceso a los datos de usuarios de tarjetas
• Requisito 8: Asignar una identificación única a cada persona con acceso a
computadoras
• Requisito 9: Restringir el acceso físico a los datos de usuarios de tarjetas
Supervisar periódicamente los ensayos y Redes
• Requisito 10: Rastrear y monitorear todos los accesos a recursos de red y
datos de usuarios de tarjetas
• Requisito 11: probar periódicamente los sistemas de seguridad y procesos
Mantener una Política de Seguridad de la Información
Requisito 12: Mantener una política que aborde la seguridad de la información
34
3 MARCO METODOLOGICO
En el presente marco metodológico se explicarán las fuentes de información que
se utilizaron como base para la extracción de la información, así como las técnicas
de investigación y el método de investigación correspondientes, para lograr cada
uno de los objetivos planteados en este PFG.
3.1 Fuentes de información
La fuente de información es el lugar donde se encuentran los datos requeridos,
que posteriormente se pueden convertir en información útil para el investigador. A
su vez los datos son todos aquellos fundamentos o antecedentes que se requieren
para llegar al conocimiento exacto de una cosa. Estos datos, que se deben
recopilar de las fuentes, tendrán que ser suficientes para poder sustentar y
defender un trabajo (Eyssautier, 2002).
3.1.1 Fuentes Primarias:
Se refieren a aquellos portadores originales de la información que no han
retransmitido o grabado en cualquier medio o documento la información de interés.
Esta información de fuentes primarias la tiene la población misma. Para extraer
los datos de esta fuente se utiliza el método de encuesta, de entrevista,
experimental o por observación (Eyssautier, 2002).
La fuente primaria que se utilizó para todos los objetivos aquí planteados es el de
entrevista, que se realizó a la Alta Gerencia, Departamento de Seguridad de la
Información, Departamento de Recursos Humanos y Departamento de TI, según
fue necesario para cada objetivo específico. El detalle de las fuentes primarias se
puede apreciar en el Cuadro No.2.
35
3.1.2 Fuentes Secundarias:
Se refieren a todos aquellos portadores de datos e información que han sido
previamente retransmitidos o grabados en cualquier soporte, y que utilizan el
medio que sea; dicha información se encuentra a disposición de todo investigador
que la necesite (Eyssautier, 2002).
Para las fuentes secundarias, se hizo uso de los sitios web tanto de Fiserv, Inc.
como del PCI Security Standards Council y sitios oficiales relacionados con el
tema de la certificación PCI DSS como los de VISA y Mastercard. De igual forma
se utilizaron textos de Administración de Proyectos para el desarrollo de cada
objetivo específico. El detalle de las fuentes secundarias se puede apreciar en el
Cuadro No.2.
Cuadro No.2. Fuentes primarias y secundarias de los objetivos del proyecto Objetivo Fuentes de Información
Fuente Primaria Fuente Secundaria Desarrollar el acta de constitución del proyecto para asegurarse que el proyecto incluya todo el trabajo requerido y completar el proyecto satisfactoriamente.
Entrevista a la alta gerencia Guía del PMBOK (PMI, 2004).
Desarrollar el cronograma del proyecto para garantizar la conclusión del proyecto en el tiempo establecido.
Entrevista a la alta gerencia y Departamento de Seguridad de la Información
Sitio web del PCI Security Standards Council. Sitio web oficial de VISA Europe y Mastercard. Programa de Seguridad de la Información de VISA. Guía del PMBOK (PMI, 2004)
Desarrollar un Plan de Gestión del Personal para identificar y documentar los roles del proyecto así como para saber cuando y como se cumplirán los requisitos de recursos humanos.
Entrevista a la alta gerencia y Departamento de Recursos Humanos y Departamento de Seguridad de la Información
Libros: Guía del PMBOK (PMI, 2004). Administración Exitosa de Proyectos y Administración Profesional de Proyectos.
Desarrollar un plan de comunicaciones para determinar las necesidades de información y garantizar la buena comunicación de los interesados.
Entrevista a la alta gerencia y Departamento de Seguridad de la Información
Libros: Guía del PMBOK (PMI, 2004). Administración Exitosa de Proyectos y Administración Profesional de Proyectos.
Desarrollar un Plan de Gestión de Riesgos para aumentar la probabilidad e impacto de los eventos positivos y disminuir la probabilidad e impacto de los eventos adversos para el proyecto.
Entrevista a la alta gerencia y Departamento de Seguridad de la Información, así como al Departamento de TI
Libros: Guía del PMBOK (PMI, 2004). Administración Exitosa de Proyectos y Administración Profesional de Proyectos.
36
3.2 Técnicas de Investigación
La técnica es indispensable en el proceso de la investigación científica, ya que
integra la estructura por medio de la cual se organiza la investigación. La técnica
pretende los siguientes objetivos:
• Ordenar las etapas de la investigación.
• Aportar instrumentos para manejar la información.
• Llevar un control de los datos.
• Orientar la obtención de conocimientos.
En cuanto a las técnicas de investigación, se tienen tres formas generales:
investigación documental, investigación de campo e investigación mixta.
La investigación documental se apoya en la recopilación de antecedentes a
través de documentos gráficos formales e informales, cualquiera que estos sean,
donde el investigador fundamenta y complementa su investigación con lo aportado
por diferentes autores. (Muñoz, 1998).
La investigación de campo es la que se realiza directamente en el medio donde
se presenta el fenómeno de estudio. (Muñoz, 1998).
La investigación mixta corresponde a trabajos de investigación en cuyo método
de recopilación y tratamiento de datos se conjuntan la investigación documental
con la de campo, con el propósito de profundizar en el estudio del tema propuesto
para tratar de cubrir todos los posibles ángulos de exploración. Al aplicar ambos
métodos se pretende consolidar los resultados obtenidos. (Muñoz, 1998).
El tipo de investigación que se utilizó es la Investigación Mixta. Se empleó por la
naturaleza de este proyecto, que involucró no solo la extracción de información de
ciertos documentos, sino participación de distintas áreas de la organización
(personal) que contienen información que debió ser extraída mediante la
investigación de campo, y de esta forma complementar mejor la información
disponible en otros medios.
37
3.3 Método de Investigación
El método es la ruta o camino que se sigue para alcanzar cierto fin que se haya
propuesto de antemano, viene del término griego methodus, que significa el
camino hacia algo; y la metodología, el cuerpo de conocimiento que describe y
analiza los métodos, indicando sus limitaciones y recursos, clarificando sus
supuestos y consecuencias y considerando sus potenciales para los avances en la
investigación. Ambos se han particularizado, y son objeto de un tratamiento
especial de acuerdo con cada ciencia particular. (Eyssautier, 2002).
Para el desarrollo de los objetivos del proyecto se utilizó en todos el método
Inductivo-Deductivo.
Método Inductivo-Deductivo
Cuando se usa simultáneamente los métodos de inferencia inductiva y deductiva
para buscar la solución de un problema científico se dice que se está empleando
el método inductivo–deductivo, cuyas reglas básicas de operación son (Tejeda,
1999):
1. Observar cómo se asocian ciertos fenómenos, aparentemente ajenos entre
sí.
2. Por medio del razonamiento inductivo, intentar descubrir el denominador
común (ley o principios) que los asocia a todos.
3. Tomando como punto de partida este denominador común (por inducción),
generar un conjunto de hipótesis referidas a los fenómenos diferentes, de
los que se partió inicialmente.
4. Planteadas las hipótesis, deducir sus consecuencias con respecto a los
fenómenos considerados.
5. Hacer investigaciones (teóricas o experimentales) para observar si las
consecuencias de las hipótesis son verificadas por los hechos.
38
3.4 Herramientas y Entregables
A continuación en el Cuadro No.3, se presenta la lista de herramientas y
entregables utilizada para desarrollar cada objetivo del proyecto.
Cuadro No.3. Herramientas y entregables de los objetivos del proyecto
Objetivo Herramientas Entregables
Desarrollar el acta de constitución del proyecto para asegurarse que el proyecto incluya todo el trabajo requerido y completar el proyecto satisfactoriamente.
Metodología de dirección de Proyectos. Juicio de Expertos (en total 4 expertos)
Acta del proyecto completada y aprobada por la alta gerencia
Desarrollar el cronograma del proyecto para garantizar la conclusión del proyecto en el tiempo establecido.
Estructura de Desglose del Trabajo (EDT). Juicio de Expertos. Office Project.
Cronograma del proyecto desarrollado con tiempos establecidos
Desarrollar un Plan de Gestión del Personal para identificar y documentar los roles del proyecto así como para saber cuando y como se cumplirán los requisitos de recursos humanos.
EDT. Cronograma del Proyecto. Matriz de Asignación de Responsabilidades. Office Project.
Plan de Gestión de Personal completo
Desarrollar un plan de comunicaciones para determinar las necesidades de información y garantizar la buena comunicación de los interesados.
Matriz de Comunicaciones
Plan de Comunicaciones completo
Desarrollar un Plan de Gestión de Riesgos para aumentar la probabilidad e impacto de los eventos positivos y disminuir la probabilidad e impacto de los eventos adversos para el proyecto.
Matriz de Probabilidad e Impacto
Plan de Gestión de Riesgos Completo
39
4 ALCANCE DEL PROYECTO
4.1 Generalidades del Proyecto
Para el proceso de certificación de PCI DSS se han identificado básicamente dos
etapas. La primera etapa, donde se realiza el análisis de todos los requerimientos
(12 en total), para ubicar a la compañía en cuales requerimientos ya se
encuentran alineados al estándar del PCI DSS, como resultado del proceso de
certificación de ISO 27001 y cuales requerimientos no están alineados, para
generar planes de acción que le permitan a Fiserv completar de forma satisfactoria
con los 12 requerimientos.
La segunda etapa es la puesta en marcha de esos planes de acción y la ejecución
de auditorias internas para garantizar de forma definitiva, que la empresa está lista
para el proceso de auditoria externa por parte de la empresa BSI Global, que es la
empresa encargada de certificar a Fiserv Costa Rica en PCI DSS.
La Figura No. 5 muestra la representación gráfica del proyecto correspondiente a
la primera etapa del proceso de certificación PCI DSS en Fiserv Costa Rica.
40
Figura No.5. Representación gráfica del proyecto
4.2 Definición del Alcance
El presente proyecto contempla solo la primera etapa del proceso de certificación
del PCI DSS, es decir, la etapa de análisis, y contiene un cronograma de trabajo
con las actividades necesarias para este análisis, un plan de recursos humanos,
un plan de comunicaciones y un plan de riesgos, creados para finalizar con éxito
esta primera etapa del proceso de certificación PCI DSS en Fiserv Costa Rica.
4.3 Beneficios Esperados
Para Fiserv Costa Rica, obtener la certificación en PCI DSS significa alinearse a
los requisitos solicitados por parte de la casa matriz en Brookfield, Winsconsin y
con ello complementar el ya implantado ISO 27001 que es también para la
seguridad de la información, haciendo el negocio más seguro para el desarrollo de
los diferentes proyectos informáticos. Por otra parte, se convierte en una ventaja
competitiva que es atractiva para los potenciales clientes de Fiserv que se
encuentran dentro del sector financiero, donde la seguridad de información
41
confidencial es primordial, ya que se busca proteger a las entidades financieras y
bancarias así como también aquellos usuarios de los sistemas informáticos.
4.4 Entregables
La figura No.6 muestra los entregables del proyecto con sus respectivos criterios
de aceptación.
Figura No.6. Entregables y criterios de aceptación del proyecto
El Cuadro No.4, presenta el desglose de los entregables del proyecto en sub-
entregables y se adjuntan sus criterios de aceptación.
42
Cuadro No.4. Entregables y sub-entregables del proyecto
Criterios de Aceptación para el entregable 1: Documento de capacitaciones del proyecto
Entregable Descripción Criterios de Aceptación
Documento de capacitaciones del proyecto
Documento que contiene la planeación necesaria para impartir las capacitaciones a todos los involucrados en el proyecto.
Documento completo con todas las capacitaciones programadas
Documento revisado y aprobado por el departamento de Recursos Humanos
Sub-entregables Descripción Criterios de Aceptación
Plan de motivación para los empleados
Plan que contiene las actividades que se realizarán para mantener motivado al equipo del proyecto y a los empleados de Fiserv en general, con el fin de evitar retrasos por falta de cooperación o interés.
Plan firmado por el Departamento de Recursos Humanos
Plan aprobado y firmado por la Gerencia General de Fiserv
Criterios de Aceptación para el entregable 2: Documentos para el análisis de los 12 requerimientos
Entregable Descripción Criterios de Aceptación
Documentos para el análisis de los 12 requerimientos
Este es un grupo de plantillas que serán necesarias para realizar los entregables 3 y 4. Estos deben de ser entregados a los responsables para facilitar el GAP Analysis.
Todas las plantillas listas para ser usadas
Criterios de Aceptación para el entregable 3: Planes de acción para los requerimientos 1, 2, 5, 6, 7, 8, 9, 10, 11, 12
Entregable Descripción Criterios de Aceptación
Planes de acción para los requerimientos 1, 2, 5, 6, 7, 8, 9, 10, 11, 12
Una vez realizado el GAP Analysis de los requerimientos 1, 2, 5, 6, 7, 8, 9, 10, 11, 12, se obtendrá como resultado una lista de no conformidades o requerimientos que no están alineados según el estándar del PCI DSS en Fiserv. Para poder alinear estos faltantes, se debe realizar un plan de acción para cada uno que implemente el requerimiento faltante.
Plan de acción para cada faltante completo y firmado por el responsable
Planes de acción revisados y firmados por el Gerente de TI y el Oficial de Seguridad de la Información
43
Cuadro No.4. Entregables y sub-entregables del proyecto (continuación)
Sub-entregables Descripción Criterios de Aceptación
Lista de faltantes para los requerimientos 1, 2, 5, 6, 7, 8, 9, 10, 11, 12
Lista de requerimientos o aspectos que actualmente no están alineados con el estándar del PCI DSS en Fiserv Costa Rica
Lista de faltantes completa para cada requerimiento analizado
Criterios de Aceptación para el entregable 4: Planes de acción para los requerimientos 3 y 4
Entregable Descripción Criterios de Aceptación
Planes de acción para los requerimientos 3 y 4
Una vez realizado el GAP Analysis de los requerimientos 3 y 4 se obtendrá como resultado una lista de no conformidades o requerimientos que no están alineados según el estándar del PCI DSS en Fiserv. Para poder alinear estos faltantes, se debe realizar un plan de acción para cada uno que implemente el requerimiento faltante.
Plan de acción para cada faltante completo y firmado por el responsable
Planes de acción revisados y firmados por el Gerente de TI, Supervisores de cuenta y el Oficial de Seguridad de la Información
Sub-entregables Descripción Criterios de Aceptación
Lista de faltantes de los requerimientos 3 y 4
Lista de requerimientos o aspectos que actualmente no están alineados con el estándar del PCI DSS en Fiserv Costa Rica
Lista de faltantes completa para cada requerimiento analizado
Criterios de Aceptación para el entregable 5: Documento de Cierre Administrativo del Proyecto
Entregable Descripción Criterios de Aceptación
Documento de Cierre Administrativo del Proyecto
Con el objetivo de facilitar, tanto referencias posteriores a la información del proyecto como el desarrollo de futuros proyectos, se lleva a cabo el cierre administrativo, documentando los programas finales, índice de archivos, reporte de cambios, directorio de participantes y lecciones aprendidas, entre otros documentos
Actividades del cronograma completadas al 100%
44
Cuadro No.4. Entregables y sub-entregables del proyecto (continuación)
Documento de cierre del proyecto revisado y firmado por el Director del Proyecto y la Gerencia General
Sub-entregables Descripción Criterios de Aceptación
Entregables 1, 2, 3 y 4 Los entregables definidos anteriormente
Cada entregable con las aprobaciones y firmas definidas para cada uno de ellos.
Documento de lecciones aprendidas
Documento que contiene los contratiempos y situaciones especiales que se presentaron a lo largo del proyecto y la forma en que estos fueron resueltos para capitalizar las experiencias y el conocimiento adquirido y así apoyar la mejora continua y optimizar la planeación de proyectos futuros
Documento de lecciones aprendidas completo
Matriz de riesgos
La matriz de riesgos utilizada para el control de los riesgos identificados a lo largo del proyecto debe estar actualizada de manera que sirva de comparación y base para futuros proyectos
Matriz de riesgos actualizada al día del cierre del proyecto
Documento de control de cambios
Documento utilizado para llevar el control de los cambios que se pueden presentar a lo largo del desarrollo del proyecto
Documento de control de cambios con todos los cambios registrados durante el desarrollo del proyecto
EDT del proyecto Documento que contiene el EDT (Estructura Detalla de Trabajo)
EDT con todas las actividades identificadas en la fase de planeación del proyecto
Análisis de precedentes
Análisis que compara el desempeño de este proyecto una vez finalizadas todas las actividades del cronograma, con el desempeño de proyectos anteriores como referencia para proyectos futuros
Documento de análisis de precedentes completo y revisado por el equipo del proyecto
Evaluación del proyecto Evaluación que se hace del proyecto para obtener retroalimentación
Evaluación completa por parte del equipo del proyecto, el patrocinador y el cliente
Directorio de participantes
Documento que contiene quienes fueron los participantes del proyecto para referencia para proyectos futuros
Lista de integrantes y participantes del proyecto completa
Índice de archivos Lista de archivos generados del proyecto
Lista de archivos generados del proyecto completa
45
4.5 Exclusiones
Fuera del alcance de este proyecto se encuentran los siguientes aspectos:
• El alcance del proyecto contempla solo la fase de análisis de
requerimientos y el desarrollo de planes de acción para alinear los
requerimientos faltantes al estándar del PCI DSS, por lo tanto la segunda
fase de este proceso de certificación, que es la puesta en marcha de los
planes de acción y el proceso de auditoria de los mismos queda por fuera
del alcance de este proyecto.
• La gestión de costos del proyecto no se incluye en este plan de proyecto ya
que se utilizarán los procedimientos para gestión de costos que tiene Fiserv
Costa Rica.
4.6 Restricciones
A continuación se presentan las restricciones identificadas para este proyecto.
• Falta de cultura de Administración de Proyectos en la organización, ya que
actualmente ningún proyecto en la organización se ha realizado utilizando
esta metodología.
• La limitación de recursos que emplea la compañía actualmente debido a la
crisis económica en Estados Unidos, puede afectar los costos de
capacitación del personal y por ende afectar todo el proyecto.
• La falta de conocimiento de la metodología del PMI en el área
administrativa y en la empresa en general que evita que los proyectos
puedan organizarse y planearse siguiendo estos lineamientos.
• Desorganización en proyectos de certificación anteriores que ha llevado a
una desmotivación de las personas a trabajar en este tipo de proyectos.
• El equipo del proyecto estará conformado por empleados de Fiserv
contratados para llevar a cabo otras funciones y responsabilidades fuera de
este proyecto. Por lo tanto son recursos compartidos que utilizarán una
46
porción de su jornada laboral para desarrollar las actividades programadas
en este proyecto. Su utilización por lo tanto no es del 100%.
4.7 Supuestos
Dentro de los supuestos que se utilizarán como base para el desarrollo de este
proyecto se encuentran los siguientes:
• Se contará con el apoyo de información de las oficinas centrales de Fiserv
en Brookfield, Winsconsin, oficina que actualmente cuenta con la
certificación PCI DSS.
• Se contará con el apoyo de la empresa BSI Global contratada para realizar
las certificaciones de Fiserv en materia de seguridad de la información.
• El Director del Proyecto tendrá funciones 100% administrativas, que le
permitirán dirigir el proyecto sin necesidad de ocuparse de otras funciones
fuera del área de la administración de proyectos.
• Se contará con el apoyo de la Gerencia General para el uso de todos los
recursos que integran el proyecto (recursos compartidos), para que estos
puedan cumplir las actividades que les serán asignadas en el tiempo
establecido.
4.8 Estructura Detalla de Trabajo (EDT)
La estructura detallada del trabajo EDT, contempla básicamente 5 grandes
entregables como se puede apreciar en la Figura No.7. De estos 5 grandes
entregables se puede apreciar un desglose que llega hasta el nivel de paquetes de
trabajo que es el nivel de más detalle.
47
Figura No.7. Estructura detallada de trabajo del proyecto (EDT)
48
5 GESTIÓN DEL TIEMPO DEL PROYECTO
La Gestión del Tiempo del Proyecto incluye los procesos necesarios para lograr la
conclusión del proyecto a tiempo. Determina las actividades necesarias para
completar el proyecto de forma exitosa y estima los tiempos para cada una.
5.1 Definición de las Actividades
Para la definición de las actividades se tomó en cuenta solo la primera fase de
certificación cuyo producto final es un documento de planes de acción resultante
de cada faltante encontrado del Gap Analysis. Para ello se utilizó la técnica de
descomposición que implica subdividir los paquetes de trabajo en componentes
más pequeños tratando de llegar a un nivel alto de detalle. Igualmente se tomó en
cuenta el juicio de expertos sobre todo de aquellas personas que tuvieron
participación en el proyecto similar anterior (ISO 27001).
A continuación se presenta el desglose de las actividades identificadas para el
desarrollo de este proyecto:
Certificación PCI DSS: etapa de análisis
Etapa de iniciación del proyecto
1. Auto-entrenamiento del Administrador del Proyecto
2. Auto-evaluación de lo aprendido en PCI DSS del Administrador del proyecto
3. Revisión de resultados Auto-evaluación con Richard Icenberg
4. Desarrollo de plan de capacitaciones del proyecto
5. Desarrollo del plan de motivación de los empleados
6. Desarrollo de herramientas necesarias para análisis de requerimientos
Etapa de capacitaciones del proyecto
1. Capacitación PMI área administrativa y supervisores de cuenta
2. Capacitación a alta gerencia y área administrativa sobre PCI DSS
3. Crear el equipo de proyecto de PCI DSS y asignar responsabilidades
4. Capacitación al equipo de proyecto sobre PCI DSS
49
5. Capacitación Empleados de Fiserv sobre PCI DSS
Evaluación de requerimientos a nivel de compañía
Analizar la lista de requerimientos de PCI DSS contra el sistema de
seguridad ya implantado de ISO 27001 para detectar faltantes. Todos los
requerimientos excepto el 3 y 4
1. "Análisis de Requerimientos 1,2,5"
2. "Análisis de Requerimientos 6,7"
3. "Análisis de Requerimientos 8,11"
4. Análisis de Requerimiento 10
5. Revisión de Gaps de TI con Richard Icenberg
6. "Desarrollo de Planes de Acción para requerimientos 1,2,5,6,7,8,10,11"
7. Enviar planes de acción al Director del Proyecto
8. Análisis de Requerimientos 9 y 12
9. Desarrollo de planes de acción para requerimientos 9 y 12
10. Enviar planes de acción de requerimientos 9 y 12 al director de proyecto
Evaluación de requerimientos a nivel de cada proyecto en Fiserv
1. Crear mapas de circulación de información en cada proyecto para detectar
información sensible de tarjetas de débito y crédito
2. Clasificar los resultados para determinar cuáles procesos o sistemas están
bajo la responsabilidad de Fiserv
3. Analizar en cada proyecto los requerimientos 3 y 4 para detectar faltantes
4. Desarrollo de planes de acción de requerimientos 3 y 4 en cada proyecto
5. Envio de planes de acción de requerimientos 3 y 4 al Director del Proyecto
6. "Revisión de planes de acción de requerimientos 3, 4, 9 y 12 con Richard
Icenberg"
Preparación de Documentación Final
1. Etapa de correcciones
2. Unión de todos los documentos en un solo plan de PCI DSS
3. Cierre del Proyecto
50
5.2 Estimación de Recursos de las Actividades
A falta de datos documentados de proyectos anteriores la estimación de recursos
se realizó con base en el juicio de expertos de las personas que trabajan en las
áreas de aplicación donde el proyecto tendrá efecto y que también tuvieron
participación en el proyecto similar anterior (ISO 27001). Los recursos de este
proyecto anterior serán los mismos para el presente proyecto y pueden verse con
detalle en el capítulo 6 de Recursos Humanos.
5.3 Desarrollo del Cronograma del Proyecto
El desarrollo del cronograma del proyecto, un proceso iterativo, determina las
fechas de inicio y finalización planificadas para las actividades del proyecto. El
desarrollo del cronograma exige que se revisen y se corrijan las estimaciones de
duración y las estimaciones de los recursos para crear un cronograma del
proyecto aprobado que pueda servir como línea base con respecto a la cual poder
medir el avance. El desarrollo del cronograma continúa a lo largo del proyecto, a
medida que el trabajo avanza, el plan de gestión del proyecto cambia, y los
eventos de riesgo anticipados ocurren o desaparecen al tiempo que se identifican
nuevos riesgos. (PMI, 2004)
El cronograma del proyecto es parte de la sección de Anexos. Por lo tanto, el
cronograma completo se adjunta en el Anexo 4.
Como principales resultados de este proceso se tiene que:
• El proyecto tendrá una duración de 66 días hábiles, iniciando el 01 de
Febrero del 2010 y finalizando aproximadamente el 05 de Mayo del 2010.
• Los días sábado y domingo de cada semana no están contemplados como
parte de los días hábiles del proyecto.
• Se identificaron un total de 30 actividades repartidas en 5 grandes
entregables que son: la etapa de iniciación del proyecto, la etapa de
capacitaciones, la evaluación de requerimientos a nivel de compañía, la
51
evaluación de requerimientos a nivel de cada proyecto en Fiserv y la
preparación de la documentación final.
• En el proyecto no se contempla el trabajo en horas extra y para mitigar esta
posible situación cada actividad en el cronograma tiene un colchón de
tiempo en días suficiente, además del tiempo exacto calculado, que
permitirá mitigar el riesgo de pago de horas extra.
• El desglose de actividades permitió definir que la mayoría de actividades
serán responsabilidad del departamento de TI, lo que permitió identificar la
necesidad de contratar un recurso extra para este departamento mejorando
la distribución de actividades y así evitar recarga de trabajo.
52
6 PLAN DE RECURSOS HUMANOS
La Gestión de los Recursos Humanos del Proyecto incluye los procesos que
organizan y dirigen el equipo del proyecto. El equipo del proyecto está compuesto
por las personas a quienes se les han asignado roles y responsabilidades para
concluir el proyecto. Si bien es común hablar de asignación de roles y
responsabilidades, los miembros del equipo deberían participar en gran parte de la
planificación y toma de decisiones del proyecto. La participación temprana de los
miembros del equipo aporta experiencia durante el proceso de planificación y
fortalece el compromiso con el proyecto. El tipo y la cantidad de miembros del
equipo del proyecto a menudo pueden cambiar, a medida que avanza el proyecto.
Los miembros del equipo del proyecto pueden denominarse personal del proyecto.
(PMI, 2004)
6.1 Organigrama del Proyecto
El organigrama del proyecto contempla no solo al equipo que se encargará de
desarrollarlo sino a los involucrados que tienen participación directa en el mismo.
Se contará con la supervisión de las oficinas de Fiserv en Brookfield, Winsconsin,
así como del departamento de Recursos Humanos. Estos involucrados darán
apoyo directo al proyecto desde el inicio hasta el final.
53
Gerencia General
Administrador del
Proyecto
IT Manager
Supervisores de
Cuenta
Oficial de Seguridad de la
Información
Departamento de Recursos
Humanos
Equipos de cada
proyecto de desarrollo
Coordinador del equipo de PCI DSS en Fiserv Orlando Florida
Figura No.8. Organigrama del proyecto
6.2 Roles y Responsabilidades del Proyecto
En el Cuadro No.5 se establecen los roles y responsabilidades para cada uno de
los miembros del equipo. Con él, se busca evitar la confusión de roles que se ha
presentado en proyectos anteriores y que ha causado el retrabajo y aumento de
responsabilidades en ciertos miembros del equipo de proyecto.
Cuadro No.5. Roles y responsabilidades del proyecto
Responsable Rol en el Proyecto Responsabilidades Competencias
Leana Romero
Arce
Administrador del Proyecto
Crear el Acta de Constitución del Proyecto
-Conocimientos específicos en la Metodología del PMI para administración de proyectos
Crear el plan de proyecto -Conocimientos específicos en el tema PCI DSS
Crear el equipo de proyecto -Conocimientos generales sobre el desarrollo de proyectos de software
Capacitar al equipo de proyecto en materia de PCI DSS y Administración de Proyectos
-Poseer habilidades de líder para manejo eficiente de equipos de trabajo
54
Cuadro No.5. Roles y responsabilidades del proyecto (continuación)
Responsable Rol en el Proyecto
Responsabilidades Competencias
Leana Romero
Arce
Administrador del Proyecto
Capacitar al área administrativa de Fiserv en materia de PCI DSS y Administración de Proyectos
-Manejo del inglés escrito y oral de no menos del 90%
Monitorear las actividades diarias del proyecto
Manejar posibles conflictos que se puedan presentar en el proyecto
Controlar el cronograma de proyecto
Administrar la comunicación del proyecto
Presentar informes a los interesados del proyecto y Gerencia General
Crear un solo documento de plan de acción
Recolectar y revisar que la documentación desarrollada esté completa
Almacenar la documentación siguiendo los procesos de almacenamiento de Fiserv Costa Rica.
Realizar el cierre formal del proyecto
Aprueba el plan de proyecto -Conocimientos generales en la Metodología del PMI para administración de proyectos
Autoriza y aprueba el inicio del proyecto
-Manejo del inglés escrito y oral de no menos del 90%
Autoriza y aprueba el cierre del proyecto
-Poseer habilidades de líder para manejo eficiente de equipos de trabajo
Autoriza la contratación de recursos para el proyecto
-Conocimientos generales sobre el desarrollo de proyectos de software
Julio Cruz Gerencia General
Recibe informes semanales/mensuales del proyecto
-Conocimientos generales en el tema PCI DSS
55
Cuadro No.5. Roles y responsabilidades del proyecto (continuación)
Responsable Rol en el Proyecto
Responsabilidades Competencias
Revisar los requerimientos 1,2,5,6,7,8 y 10 del PCI DSS para encontrar faltantes o inconformidades con la norma
-Experiencia en instalación, manejo y seguridad de redes
Crear un plan de acción para cada inconformidad encontrada
-Conocimientos generales en la metodología de administración de proyectos del PMI
Crear la documentación necesaria para llevar al cabo cada requerimiento
-Conocimientos en monitoreo y pruebas de redes
Entregar reportes de avance al Administrador del Proyecto
-Manejo del inglés escrito y oral de no menos del 60%
Departamento de TI (Juan
Carlos Naranjo, Rodrigo
Miranda, Jose Calderón, Recurso
Extra)
Departamento de TI
Participar en las reuniones programadas del proyecto
-Conocimiento avanzado en Sistemas Operativos MS y sus productos. -Capacidades avanzadas para manejo de problemas técnicos (hardware-software)
Crear mapas de circulación de información en cada proyecto para detectar información sensible de tarjetas de débito y crédito
-Conocimientos generales en la metodología de administración de proyectos del PMI
Revisar los requerimientos 3 y 4 del PCI DSS para encontrar faltantes o inconformidades con la norma
-Conocimientos sobre proyectos de desarrollo de software
Realizar un plan de acción para cada inconformidad encontrada
-Poseer habilidades para desarrollo de documentación
Entregar reportes de avance al Administrador del Proyecto
-Conocimientos generales en el tema de PCI DSS
Participar en las reuniones programadas del proyecto
-Manejo del inglés escrito y oral de no menos del 90%
Waldier Arguedas
Laura Gamboa
Alexander Chaverri, Jonathan Loaiza,
Francisco Monge
Supervisores de Cuenta
Organizar a los diferentes equipos bajo su mando para cumplir con la documentación solicitada
-Habilidades de liderazgo para manejo de equipos
56
Cuadro No.5. Roles y responsabilidades del proyecto (continuación)
Responsable Rol en el Proyecto
Responsabilidades Competencias
Participar en las capacitaciones programadas sobre PCI DSS
-Conocimientos generales en la metodología de administración de proyectos del PMI
Dar soporte a sus respectivos Supervisores de Cuenta en la creación de mapas de información.
-Conocimientos generales en el tema de PCI DSS
Empleados de Fiserv
Equipo de Desarrollo
de cada Proyecto
Dar soporte a sus respectivos Supervisores de Cuenta en el análisis de requerimientos 3 y 4 del PCI DSS
-Conocimientos específicos en el desarrollo de software, testing y manejo de programas en general
Revisar los requerimientos 9 y 12 del PCI DSS para encontrar faltantes o inconformidades con la norma
-Conocimientos generales en la metodología de administración de proyectos del PMI
Verificar que cada plan de acción generado esté alineado con lo que establece ISO 27001
-Conocimientos específicos sobre PCI DSS
Desarrollo del Plan de Auditoria de PCI DSS
-Conocimiento en la certificación ISO 27001
Entregar reportes de avance al Administrador del Proyecto
-Poseer habilidades para desarrollo de documentación
Ricardo Bonilla
Oficial de Seguridad
de la Información
Participar en las reuniones programadas del proyecto
-Manejo del inglés escrito y oral de no menos del 90%
Proveer la capacitación a los empleados sobre PCI DSS
-Conocimientos generales en la metodología de administración de proyectos del PMI
Realizar el plan de motivación de los empleados
-Conocimientos generales en el tema de PCI DSS
Mónica Salazar,
Lorena Díaz
Departamento de
Recursos Humanos
Ejecutar el plan de motivación de los empleados
-Manejo del inglés escrito y oral de no menos del 90%
57
Cuadro No.5. Roles y responsabilidades del proyecto (continuación)
Responsable Rol en el Proyecto
Responsabilidades Competencias
Participar en la revisión de cada entregable del proyecto
Conocimientos específicos sobre PCI DSS
Proveer retroalimentación de cada fase del proyecto en forma semanal
-Conocimientos generales en la metodología de administración de proyectos del PMI Richard
Icenberg
Director de Sys
Sec, ISO en
oficinas centrales de Fiserv
Coordinar con su equipo de PCI DSS en Fiserv Orlando Florida, cualquier esfuerzo que se requiera de ellos durante el proceso de certificación de Fiserv Costa Rica
-Poseer habilidades de líder para manejo eficiente de equipos de trabajo
6.3 Matriz de Asignación de Responsabilidades
La matriz de asignación de responsabilidades tiene como objetivo complementar
el cuadro de Roles y Responsabilidades del proyecto. Con ayuda del Cuadro No.6
se puede ver de una forma más gráfica cuál es el papel que tiene cada miembro
del equipo de proyecto en cada una de las tareas del cronograma de trabajo. La
matriz de asignación de responsabilidades usa las siguientes siglas:
E=Ejecuta
P=Participa
C=Coordina
R=Revisa
A=Autoriza.
58
Cuadro No.6. Matriz de asignación de responsabilidades
Persona
Actividad L
ean
a R
om
ero
(D
irec
tor
del
Pro
yect
o)
Julio
Cru
z (G
eren
cia
Gen
eral
)
Juan
Car
los
Nar
anjo
Ro
dri
go
Mir
and
a
Jose
Cal
der
ón
Rec
urs
o A
dic
ion
al d
e T
I
Lau
ra G
amb
oa/
Wal
die
r A
rgu
edas
/ Ale
xan
der
C
hav
erri
/Jo
nat
han
L
oai
za/F
ran
cisc
o M
on
ge
Em
ple
ado
s d
e F
iser
v,
equ
ipo
s d
e d
esar
rollo
Ric
ard
o B
on
illa
Mó
nic
a S
alaz
ar/L
ore
na
Día
z
Ric
har
d Ic
enb
erg
Certificación PCI DSS: etapa de análisis
Etapa de iniciación del proyecto
Auto-entrenamiento del Administrador del Proyecto
C/E/P A
Auto-evaluación de lo aprendido en PCI DSS del Administrador del proyecto
E A
Revisión de resultados Auto-evaluación con Richard Icenberg
P E/R
Desarrollo de plan de capacitaciones del proyecto
C/E A R/A
Desarrollo del plan de motivación de los empleados
R/P A E
Desarrollo de herramientas necesarias para análisis de requerimientos
E A R
Etapa de capacitaciones del proyecto
Capacitación PMI área administrativa y supervisores de cuenta
E A/P C/R/P
Capacitación a alta gerencia y área administrativa sobre PCI DSS
E A/P C/R/P
Crear el equipo de proyecto de PCI DSS y asignar responsabilidades
C/E A
59
Cuadro No.6. Matriz de asignación de responsabilidades (continuación)
Persona
Actividad
Lea
na
Ro
mer
o (
Dir
ecto
r d
el P
roye
cto
) Ju
lio C
ruz
(Ger
enci
a G
ener
al)
Juan
Car
los
Nar
anjo
Ro
dri
go
Mir
and
a
Jose
Cal
der
ón
Rec
urs
o A
dic
ion
al d
e T
I
Lau
ra G
amb
oa/
Wal
die
r A
rgu
edas
/ Ale
xan
der
C
hav
erri
/Jo
nat
han
L
oai
za/F
ran
cisc
o M
on
ge
Em
ple
ado
s d
e F
iser
v,
equ
ipo
s d
e d
esar
rollo
Ric
ard
o B
on
illa
Mó
nic
a S
alaz
ar/L
ore
na
Día
z
Ric
har
d Ic
enb
erg
Capacitación al equipo de proyecto sobre PCI DSS
E A C/R
Capacitación Empleados de Fiserv sobre PCI DSS
E A C/R R
Evaluación de requerimientos a nivel de compañía
Analizar la lista de requerimientos de PCI DSS contra el sistema de seguridad ya implantado de ISO 27001 para detectar faltantes. Todos los requerimientos excepto el 3 y 4
Análisis de Requerimientos 1,2,5
C R E R
Análisis de Requerimientos 6,7 C R E R Análisis de Requerimientos 8,11
C E R
Análisis de Requerimiento 10 C R E R Revisión de Gaps de TI con Richard Icenberg
R C P P P E
Desarrollo de Planes de Acción para requerimientos 1,2,5,6,7,8,10,11
C C/E
E E E P
Enviar planes de acción al Director del Proyecto
C E
Análisis de Requerimientos 9 y 12
C E
Desarrollo de planes de acción para requerimientos 9 y 12
C E
Enviar planes de acción de requerimientos 9 y 12 al director de proyecto
C E
60
Cuadro No.6. Matriz de asignación de responsabilidades (continuación)
Persona
Actividad L
ean
a R
om
ero
(D
irec
tor
del
Pro
yect
o)
Julio
Cru
z (G
eren
cia
Gen
eral
)
Juan
Car
los
Nar
anjo
Ro
dri
go
Mir
and
a
Jose
Cal
der
ón
Rec
urs
o A
dic
ion
al d
e T
I
Lau
ra G
amb
oa/
Wal
die
r A
rgu
edas
/ Ale
xan
der
C
hav
erri
/Jo
nat
han
L
oai
za/F
ran
cisc
o M
on
ge
Em
ple
ado
s d
e F
iser
v,
equ
ipo
s d
e d
esar
rollo
Ric
ard
o B
on
illa
Mó
nic
a S
alaz
ar/L
ore
na
Día
z
Ric
har
d Ic
enb
erg
Evaluación de requerimientos a nivel de cada proyecto en Fiserv
Crear mapas de circulación de información en cada proyecto para detectar información sensible de tarjetas de débito y crédito
C E P R
Clasificar los resultados para determinar cuáles procesos o sistemas están bajo la responsabilidad de Fiserv
C/R P P E P R
Analizar en cada proyecto los requerimientos 3 y 4 para detectar faltantes
C E P R
Desarrollo de planes de acción de requerimientos 3 y 4 en cada proyecto
C E P R
Envio de planes de acción de requerimientos 3 y 4 al Director del Proyecto
C E
Revisión de planes de acción de requerimientos 3, 4, 9 y 12 con Richard Icenberg
C/P P P E
Preparación de Documentación Final
Etapa de correcciones C E E E E E E E R Unión de todos los documentos en un solo plan de PCI DSS
C/E A R
Cierre del Proyecto C/E P/A
61
6.4 Plan de Gestión del Personal
6.4.1 Reclutamiento de personal
Todos los recursos del proyecto son recursos internos de Fiserv Costa Rica y
Fiserv en Brookfield, Winsconsin, por ello no se requerirá de contratación de
personal externo en forma de Outsourcing. El departamento de Recursos
Humanos de la empresa estará apoyando al equipo del proyecto en su
constitución y ejecutando un plan de motivación durante todo el proyecto. Así
mismo, el departamento de Recursos Humanos dentro de sus funciones tiene a
cargo las distintas capacitaciones que sean necesarias en Fiserv, por lo tanto
estará asesorando al Director del Proyecto en la organización de las diferentes
capacitaciones contempladas en el cronograma de trabajo.
6.4.2 Horarios
• Dentro de la planificación de los recursos humanos, se ha identificado la
necesidad de contratar un recurso extra en el departamento de TI, cuyas
responsabilidades sean el monitoreo de redes exclusivamente y que de
esta forma sea responsable del análisis del requerimiento 10 del PCI DSS,
este recurso ya se había identificado en un proyecto anterior (Certificación
ISO 27001), pues a raíz de este proyecto se identificó el rol y por ende la
contratación de este recurso en la empresa de forma permanente, que
además de soporte al proceso de certificación PCI DSS. Este recurso debe
contratarse con un mínimo de un mes de anticipación al inicio del proyecto,
para adaptarlo al departamento de TI y así evitar retrasos por falta de
información. Los responsables de la contratación son el departamento de
Recursos Humanos en conjunto con el Gerente de TI.
• La cantidad de horas estimadas por día para cada recurso humano es de 8
horas hábiles. Esto debido a que los recursos humanos del proyecto no son
100% disponibles para el proyecto, estos por el contrario son recursos
compartidos. Por ende las 8 horas normales de trabajo de cada recurso
62
deben contemplar las tareas del cronograma de trabajo pero además las
tareas normales de cada miembro del equipo. El tiempo establecido para
cada recurso está calculado en días más que en horas y contempla una
holgura suficiente tomando en cuenta que cada recurso debe tomar solo un
porcentaje de su tiempo para completar las tareas programadas. Sin
embargo, no es posible establecer un porcentaje específico para cada
recurso pues este varía diariamente según la disponibilidad de cada
recurso.
6.4.3 Criterios de Liberación
Una vez el recurso finaliza sus tareas relacionadas con el proyecto, este debe
informar a su líder inmediato y este proporcionar un informe al Director de
Proyecto de las personas que van terminando sus tareas. El Cuadro No.7 muestra
los criterios de liberación de los recursos del proyecto.
Cuadro No.7. Criterios de liberación de los recursos del proyecto
Responsable Criterios de Liberación Cumplido/No Cumplido
Leana Romero Plantillas listas de trabajo Capacitaciones realizadas
Documento de planes de acción aprobado, revisado y firmado
Unión de todos los documentos en un solo plan de PCI DSS listo
Plan de proyecto actualizado a la fecha de cierre Documento de Lecciones Aprendidas finalizado Documento de cierre del proyecto finalizado y firmado Julio Cruz Documento de cierre del proyecto finalizado y firmado Juan Carlos Naranjo
Planes de acción listos para requerimientos 1,2,5,6,7,8,10,11
Documento de planes de acción revisado y firmado
Departamento de TI Planes de acción listos para requerimientos 1,2,5,6,7,8,10,11
Documento de planes de acción revisado
63
Cuadro No.7. Criterios de liberación de los recursos del proyecto (continuación)
Responsable Criterios de Liberación Cumplido/
No Cumplido
Supervisores de Cuenta Planes de acción listos para requerimientos 3,4 Documento de planes de acción revisado y firmado Equipos de Desarrollo Planes de acción listos para requerimientos 3,4 Ricardo Bonilla Planes de acción listos para requerimientos 9 y 12 Documento de planes de acción revisado y firmado Departamento de Recursos Humanos Plan de Capacitaciones aprobado y firmado
Todas las capacitaciones a los empleados de Fiserv finalizadas
Todos los premios del plan de reconocimiento y recompensas entregados a los ganadores
Richard Icenberg Documento de planes de acción aprobado, revisado y firmado
Aprobación del plan de PCI DSS, documento final del proyecto
6.4.4 Necesidades de Formación
Las siguientes son las capacitaciones que se reconocieron como indispensables
para llevar a buen término el proyecto:
• Capacitación sobre la metodología del PMI: esta se impartirá antes de
iniciar el análisis de los 12 requerimientos del PCI DSS a todo el equipo del
proyecto. Esto dado a que actualmente muy pocas personas en la
compañía saben como funciona esta metodología y este ha sido un factor
determinante para que el equipo pueda trabajar eficientemente con un
cronograma de trabajo y otras herramientas en proyectos anteriores. El
encargado de esta capacitación es el administrador del proyecto.
64
• Capacitación sobre el tema de PCI DSS: esta capacitación se le dará a
todos los empleados de Fiserv, iniciando con el área administrativa ya que
es importante que la gerencia general entienda el alcance de esta
certificación para que dé el apoyo necesario y siguiendo con el equipo del
proyecto quienes dependen de esta capacitación para desarrollar las
actividades establecidas en el cronograma. El encargado de las
capacitaciones al área administrativa y al equipo del proyecto es el mismo
Director del Proyecto quien ya para entonces contará con el conocimiento
suficiente. Estas capacitaciones se impartirán antes del análisis de los 12
requerimientos del PCI DSS.
Ambas capacitaciones estarán contempladas en el Plan de Capacitaciones que es
una actividad del proyecto y que debe ser revisado y aprobado por el
departamento de Recursos Humanos, como parte de los roles de este
departamento.
6.4.5 Reconocimiento y Recompensas
El programa de reconocimiento y recompensas que se usará durante el proyecto
es el programa de Reconocimiento y Recompensas oficial de Fiserv, que está
diseñado para reconocer logros individuales y de equipo. Por medio de estos
reconocimientos se les da a los empleados la oportunidad de ser compensados
por su buen trabajo. En este proyecto es vital el uso de este programa dado que
las tareas para algunos miembros del equipo se pueden considerar tareas
extraordinarias en donde la motivación juega un papel importante para el término
de las tareas a tiempo.
El programa contempla dos formas de reconocimiento:
• Reconocimiento por tarjetas o estrellas
• Programa de premios a campeones
65
A. Reconocimiento por tarjetas o estrellas
Estas tarjetas se darán a los empleados para reconocer:
• Los esfuerzos del empleado, por ejemplo, empleados que se quedan hasta
tarde para terminar un informe.
• Las mejoras, por ejemplo, el empleado que suele llegar tarde y después de
una sesión de apoyo empieza a llegar a tiempo.
• Un trabajo bien hecho, por ejemplo, una excelente presentación / informe.
Estrellas (puntos) del sistema: Cada tarjeta será válida para una estrella (1
punto). El empleado puede acumular estas tarjetas y canjearlos por diferentes
premios en cualquier momento. Las estrellas no caducan. Los premios serán de
cambio en el Departamento de Recursos Humanos.
B. Programa de premios a campeones
Categorías de Nominación
• Extraordinario Servicio al Cliente: Este premio se otorga al empleado que
proporciona a los clientes (internos o externos) las expectativas de un
servicio excepcional.
• Extraordinario Liderazgo: Este premio se otorga al empleado que ha
demostrado un liderazgo positivo y eficaz de un equipo o proyecto.
• Extraordinario Trabajo en Equipo: Este premio se otorga a los equipos
que ofrecen un rendimiento excepcional para el logro de una asignación
importante / proyecto / objetivo del departamento.
• Extraordinario Desenvolvimiento: Este premio se otorga al empleado que
su rendimiento supera las expectativas. El empleado es claramente un
factor clave para el éxito de la organización.
66
• Extraordinaria Contribución: Este premio se otorga a los empleados que
voluntariamente hacen una importante contribución a un proyecto / equipo /
departamento fuera de sus responsabilidades de trabajo.
Procedimiento para la nominación
• El reconocimiento se hará sobre una base mensual
• Las nominaciones serán recibidas a lo largo del mes
• Los ganadores serán anunciados la primera semana del mes siguiente
• El Supervisor rellena el formulario de nominación a los premios y lo somete
a la aprobación del Departamento de Recursos Humanos
• El departamento de Recursos Humanos examina las candidaturas y lo pasa
a la Gerencia General para su aprobación final
• Si la candidatura es aprobada, el departamento de Recursos Humanos
imprime un certificado de premio y le proporciona al Supervisor el
reconocimiento para el empleado
• El Supervisor da el premio y certificado al empleado
• Todos los ganadores de este mes se publicarán en el tablón de anuncios de
la compañía y por correo electrónico
Premios
• Certificados de reconocimiento
• Artículos promocionales
• Certificados de regalo para cenas o almuerzos
• Tiquetes de entrada al cine
• Pizza Party (premio para equipos)
67
7 PLAN DE GESTIÓN DE LAS COMUNICACIONES
La Gestión de las Comunicaciones del Proyecto es el Área de Conocimiento que
incluye los procesos necesarios para asegurar la generación, recogida,
distribución, almacenamiento, recuperación y destino final de la información del
proyecto en tiempo y forma. Los procesos de Gestión de las Comunicaciones del
Proyecto proporcionan los enlaces cruciales entre las personas y la información,
necesarios para unas comunicaciones exitosas. (PMI, 2004)
Planificación de las Comunicaciones
En muchos proyectos la planificación de las comunicaciones se realiza en las
primeras fases del proyecto, sin embargo, los resultados de este proceso se
revisan durante todo el proyecto. Esta planificación pretende determinar quienes
son los interesados del proyecto y cuales son sus necesidades de información,
para de esta forma darle una respuesta apropiada a estas necesidades.
7.1 Análisis de Involucrados
El siguiente análisis en el Cuadro No.8 provee información detallada sobre
quienes son los interesados del proyecto y el papel que juega cada uno en el éxito
del proyecto. Se describen también las actitudes percibidas como riesgos por
parte de cada involucrado y las acciones para mitigar esas actitudes o riesgos.
68
Cuadro No.8. Análisis de involucrados del proyecto
Involucrado
Su interés o requerimiento en el
proyecto
¿Qué necesita el proyecto de
ellos?
Actitudes percibidas o
riesgos Acciones
Julio Cruz
Es el Gerente General de la empresa, debe tomar decisiones de alto riesgo, así como entablar la comunicación con la casa matriz de Fiserv para cualquier requerimiento que pueda tener el proyecto. De igual forma debe de comunicar el estatus del proyecto cuando este le sea requerido por la casa matriz.
Se requiere su participación apoyando las iniciativas del personal de la empresa y su compromiso para mantener los supuestos establecidos en el alcance del proyecto.
El Gerente General podría tener poco interés o tiempo dedicado al proyecto lo que puede afectar la comunicación con la casa matriz para detectar cualquier requerimiento a tiempo.
Se le debe mantener informado a través de reportes semanales y mensuales sobre las actividades del proyecto, haciendo énfasis en aquellas situaciones donde se requiera de su participación activa.
Leana Romero
Como director del proyecto debe mantener un control estricto sobre la documentación creada para el proyecto, cuidando los tiempos y tratando de detectar los problemas que se puedan presentar día a día para que de esta forma establezca una comunicación eficiente.
Se requiere su control diario sobre los miembros del equipo de proyecto para conocer el estatus de sus tareas a tiempo. También se requiere que establezca la comunicación necesaria con los diferentes involucrados para minimizar el riesgo de descubrir posibles actividades en las etapas de cierre del proyecto.
El Director del proyecto por decisión de la alta gerencia podría no tener el rol al 100% de director de proyecto si se le asignan tareas fuera de este rol.
Mantener informada a la alta gerencia sobre el rol del director del proyecto en todo momento, haciendo énfasis en sus responsabilidades y la importancia de que su rol se mantenga.
69
Cuadro No.8. Análisis de involucrados del proyecto (continuación)
Involucrado
Su interés o requerimiento en el
proyecto
¿Qué necesita el proyecto de
ellos?
Actitudes percibidas o
riesgos Acciones
Juan Carlos
Naranjo
Como gerente del departamento de TI tiene la responsabilidad de velar porque las tareas asignadas a su equipo sean terminadas a tiempo. Esto debido a que este departamento tendrá a cargo la mayoría de tareas a desarrollar en el proyecto.
El proyecto requiere de su comunicación constante (diaria) con el director del proyecto para poder detectar posibles retrasos y buscar soluciones inmediatas. Es importante que el gerente de TI incluya en sus planeamientos internos al director del proyecto para que la toma de decisiones se realice en forma conjunta.
La falta de comunicación por falta de tiempo en el proyecto, podría evitar que no se puedan tomar medidas inmediatas que puedan mitigar riesgos.
Incluir a Juan Carlos Naranjo en la planeación del proyecto y en cualquier replanteamiento que se realice para que se tomen acciones conjuntas.
Departamento de
TI
Encargados de realizar la mayoría de tareas del proyecto, debido a la naturaleza del mismo.
Se requiere su compromiso para finalizar las tareas que se establezcan y que brinden comunicación eficiente con el gerente de TI, encargado de este departamento, para detectar posibles inconvenientes que puedan retrasar el proyecto.
El exceso de responsabilidades recargadas en este departamento y la falta de recursos podrían evitar que los integrantes de este departamento presenten un retraso en el desarrollo de sus tareas.
Se debe establecer reuniones constantes con este equipo de manera que cualquier inconveniente sea detectado a tiempo. La buena comunicación con el gerente de TI es fundamental para que las tareas sean terminadas a tiempo.
70
Cuadro No.8. Análisis de involucrados del proyecto (continuación)
Involucrado
Su interés o requerimient
o en el proyecto
¿Qué necesita el proyecto de ellos?
Actitudes percibidas o
riesgos Acciones
Supervisores de Cuenta
Encargados de desarrollar algunas tareas del proyecto con sus respectivos equipos de desarrollo.
Se requiere su compromiso para finalizar las tareas que se establezcan y que brinden comunicación constante con el director del proyecto para evitar retrasos.
Situaciones inesperadas para cada supervisor (visita de clientes u otros) podrían evitar que se completen las tareas a tiempo. La falta de motivación para participar de este tipo de proyectos podría dar paso a riesgos inesperados.
El desarrollo de reuniones semanales para evaluar la motivación y como medio de buena comunicación para detectar cualquier posible atraso en el desarrollo de las correspondientes tareas.
Equipos de desarrollo
Participan junto con sus respectivos Supervisores de Cuenta del desarrollo de los requerimientos 3 y 4.
Se requiere su aporte técnico en el desarrollo de estas tareas.
El uso de horas "cliente" podría ser un obstáculo para el desarrollo de estos requerimientos.
Su reporte de tiempo disponible a sus respectivos Supervisores de Cuenta para el buen manejo del tiempo.
Ricardo Bonilla
Como Oficial de Seguridad de la Información debe velar porque los planes de acción resultado del análisis de cada requerimiento estén acorde con la certificación ISO 27001.
Su participación en cada reunión de revisión es importante ya que de haber algún cambio a algún procedimiento de ISO 27001 que este sea controlado a través de este involucrado. Debe participar de la comunicación con la casa matriz y participar aportando ideas que permitan alinear la certificación PCI DSS a la certificación ISO 27001.
Su compromiso con ISO 27001 podría evitar que su participación en el proyecto se vea reducida y la comunicación con la casa matriz no sea llevada al cabo de manera eficiente.
La implementación de reuniones permitirá detectar a tiempo cualquier retraso o riesgo que aleje a este involucrado de su participación en el proyecto.
71
Cuadro No.8. Análisis de involucrados del proyecto (continuación)
Involucrado Su interés o
requerimiento en el proyecto
¿Qué necesita el proyecto de ellos?
Actitudes percibidas o
riesgos Acciones
Departamento de
Recursos Humanos
Encargados de dar soporte al director del proyecto en la parte de capacitaciones e implementando el programa de motivación a los participantes del proyecto.
Su comunicación constante con el director de proyecto para coordinar todas las actividades relacionadas con capacitaciones y plan de motivación de empleados en el tiempo establecido.
Poco envolvimiento en el proyecto puede provocar una debilidad en la comunicación.
Hacer participar a este departamento en las reuniones para asegurar la buena comunicación y su envolvimiento en los proyectos.
Richard Icenberg
Encargado de la certificación de PCI DSS en Fiserv oficinas centrales.
Su aporte a todo el proceso es indispensable. Se requiere de la revisión de cada entregable y su participación en reuniones semanales para obtener sus observaciones y corregir lo que sea necesario de forma semanal, evitando retrabajo hacia el final del proyecto.
La falta de comunicación por parte de la gerencia general con la casa matriz podría evitar que el nivel de participación de Richard sea limitado, así como cualquier evento inesperado en las oficinas centrales de Fiserv podrían limitar su participación.
La constante comunicación del avance del proyecto con la gerencia general para que esta dirija los esfuerzos y comunicación necesaria hacia la casa matriz de Fiserv, esto permite que Richard Icenberg pueda mantener la comunicación eficiente con el director del proyecto.
72
Cuadro No.8. Análisis de involucrados del proyecto (continuación)
Involucrado
Su interés o requerimiento en
el proyecto
¿Qué necesita el
proyecto de ellos?
Actitudes percibidas o
riesgos Acciones
Sanjiv Kumar
Es la contraparte del Gerente de TI de Costa Rica en India. Este será el punto de contacto del departamento de TI para la revisión de cualquier implementación en el departamento de TI así como de la revisión de la documentación generada por este departamento durante el proyecto.
Se requiere de su aporte técnico y su conocimiento en el tema de PCI DSS para que las posibles implementaciones en Costa Rica sean más rápidas tomando en cuenta el conocimiento que tiene India.
La participación de este involucrado debe ser limitada para evitar que una inclusión más amplia pueda chocar con las implementaciones que pueda hacer Richard Icenberg. La participación de las oficinas de Fiserv india debe ser de aporte más que de control.
Enviar la propuesta de proyecto a la casa matriz de Fiserv para explicar los roles que tomará cada oficina de Fiserv y obtener aprobación oficial, de manera que los roles y responsabilidades de cada oficina estén bien definidos y se evite aportes de muchas personas que pueden provocar confusión en el proceso y mucho retrabajo. Además incluir en la comunicación mensual del avance del proyecto a la casa matriz para mantener la información fluyendo de forma eficiente.
Gerencia General
de Fiserv India.
Oficinas de Fiserv ubicadas en la India.
Su observación y apoyo limitado y controlado en el proceso de certificación de Fiserv Costa Rica.
Normalmente esta oficina controla muchos de los procesos que se implementan en Fiserv Costa Rica. Sin embargo, en el proceso de certificación de PCI DSS la empresa encargada de la certificación es distinta de la que India usó para su certificación, por ello el mayor apoyo lo debe dar la casa matriz de Fiserv en Estados Unidos y limitar las funciones de India a ser observador del proceso.
La Gerencia General de Fiserv Costa Rica debe enviar a la Gerencia General de India un informe mensual con observaciones generales del avance del proceso y lo que se requiere de ellos si este es requerido o solicitado por la casa matriz.
73
Cuadro No.8. Análisis de involucrados del proyecto (continuación)
Involucrado Su interés o
requerimiento en el proyecto
¿Qué necesita el proyecto de
ellos?
Actitudes percibidas o
riesgos Acciones
Casa matriz de Fiserv
USA
Encargados de proveer el mayor apoyo técnico al proceso de certificación de PCI DSS. Proveen la aprobación del proyecto y la aprobación al presupuesto del mismo.
Se requiere una comunicación constante que les permita mantenerse al día con el avance del proyecto para detectar nuevas limitaciones o riesgos.
La falta de comunicación con la casa matriz podría aislar a la casa matriz y que sus aportes al proyectos no se den en el momento indicado y puedan por ende presentarse hacia al final del proyecto.
Reuniones e informes semanales del Director del Proyecto con Richard Icenberg y reuniones e informes mensuales de la Alta Gerencia de Fiserv Costa Rica con la Alta Gerencia de la casa matriz para comunicar los avances del proyecto.
Empleados de Fiserv
Costa Rica en general
Algunos de ellos darán soporte al desarrollo de los requerimientos 3 y 4 y otros deben ser entrenados en el tema para detectar cualquier información sensible que requiera de la implementación de procesos de PCI DSS
Se requiere su participación en las capacitaciones que se llevarán al cabo a toda la empresa.
Las limitaciones que se han llevado al cabo por parte de la empresa como resultado de ISO 27001 han afectado la motivación de los empleados que han visto reducidos algunos de sus beneficios. La implementación de otra certificación como PCI DSS en términos de la seguridad de la información podría afectar aún más la motivación si no se ofrece la información a tiempo y se mantiene una comunicación transparente, afectando al proyecto en general.
Las capacitaciones deben ofrecerse antes de la puesta en marcha del GAP Analysis de los requerimientos a todos los empleados. Los empleados deben recibir información constante sobre los objetivos de la certificación para evitar mal entendidos. La puesta en marcha del plan de motivación por parte de Recursos Humanos debe ir acorde con el envió de información.
74
7.2 Matriz de Responsabilidades de Comunicación de los Involucrados
Las responsabilidades referentes a la comunicación del proyecto se señalan en
la siguiente matriz de comunicación en el Cuadro No.9.
Simbología
@: Envía Mail
I: Genera Informe
R@: Recibe Mail
RI: Recibe Informe
AS: Actualiza Sistema
RS: Revisa Sistema
Cuadro No.9. Matriz de comunicación del proyecto
Matriz de Comunicación
Rep
ort
e S
eman
al
Rep
ort
e M
ensu
al
Min
uta
s d
e R
eun
ión
Órd
enes
de
Cam
bio
Pla
n d
e P
roye
cto
Say
ri
Nombre Rol en el Proyecto Sem Men Sem Otro Men Sem
Leana Romero Director del Proyecto
RI/R@/I/@ RI/R@/I/@ I/@ I/RI I AS/RS
Julio Cruz Gerente General
RI/I/R@ RI/R@ RI RS RS
Juan Carlos Naranjo Gerente de TI
I/@ RI/R@ I RS RS
Jose Calderón, Rodrigo Miranda
Departamento de TI
I/@ RI/R@ RS RS
Laura Gamboa, Alexander Chaverry, Waldier Arguedas, Jonathan Loaiza, Francisco Monge
Supervisores de Cuenta
I/@ RI/R@ I RS RS
Equipos de Desarrollo
Empleados de Fiserv
I/@ RS RS
Ricardo Bonilla Oficial de Seguridad de la Información
I/@ RI/R@ I RS RS
75
Cuadro No.9. Matriz de comunicación del proyecto (continuación)
Matriz de Comunicación
Rep
ort
e S
eman
al
Rep
ort
e M
ensu
al
Min
uta
s d
e R
eun
ión
Órd
enes
de
Cam
bio
Pla
n d
e P
roye
cto
Say
ri
Nombre Rol en el Proyecto Sem Men Sem Otro Men Sem
Mónica Salazar, Lorena Díaz
Departamento de RH
I/@ RI/R@ I RS RS
Richard Icenberg
Director de Sys Sec, ISO en oficinas centrales de Fiserv
RI/R@ RI/R@ I RS RS
Sanjiv Kumar Gerente de TI Fiserv India
Gerencia General Fiserv India
Gerencia General Fiserv India
RI/R@
Casa Matriz de Fiserv USA
Casa Matriz de Fiserv India
RI/R@
Otros empleados de Fiserv
Empleados de Fiserv
RS
7.3 Proceso de Resolución de Disputas
Ante cualquier situación que genere un desacuerdo entre los miembros de equipo,
o entre diferentes equipos de trabajo, se procederá a discutirlos directamente con
el director del proyecto, convocando a una reunión con el fin de buscar la mejor
solución ante el problema. Esto siempre y cuando estas situaciones o
desacuerdos sean generados dentro del mismo proyecto. Cualquier otro asunto
que esté por fuera del desarrollo del proyecto debe ser escalado a la Gerencia
General de Fiserv.
76
7.4 Proceso de Escalamiento
El proceso a seguir para escalar los problemas que se encuentran dentro del
proyecto, ya sean sobre temas técnicos u operativos, es tratarlos directamente con
el encargado del área. En este caso los miembros del departamento de TI deben
escalar sus situaciones al Gerente de TI. Los equipos de desarrollo deberán
escalar a sus respectivos Supervisores de Cuenta. En caso de que no se pueda
buscar una solución, o que sea una situación donde implique tomar una decisión
fuera del alcance de los encargados, se escalará directamente al director del
proyecto.
7.5 Distribución de la información
La información generada de reportes de avance se enviará al jefe directo según se
observa en el organigrama o en la matriz de comunicaciones. Además se
implementará una unidad en un servidor dedicado para almacenar dicha
información y toda la documentación referente al proyecto. Este sistema es el
sistema interno Sayri, en el cual se manejará la información del proyecto y el cuál
podrá ser accesado por el equipo de proyecto cuando sea requerido. En el se
asignarán las diferentes actividades a los diferentes responsables. Así como se
podrá almacenar la documentación resultante de cada entregable. Por ende toda
información oficial estará disponible en este sistema interno.
7.6 Informes del Proyecto
7.6.1 Informe Semanal
Cada uno de los involucrados debe generar informes semanalmente a su jefe
inmediato vía correo, según se presenta en la matriz de comunicaciones. Los jefes
de cada área deben generar un solo reporte semanal para presentar un informe
más completo al director del proyecto. Dicho informe básicamente informará el
detalle de avance de las tareas asignadas a cada uno de los miembros, de
manera que se pueda obtener una métrica de rendimiento según avance. Cada
77
jefe de área debe agregar además si también existen riesgos o aquellos aspectos
negativos que puedan generar retrasos al proyecto así como los aspectos
positivos más importantes a considerar. Una vez que todos los informes estén en
manos del director del proyecto, este acude a la actualización del plan de proyecto
de forma semanal que puede ser visualizado en el sistema Sayri. El formato del
informe semanal se puede ver en el Anexo 5.
7.6.2 Informe Mensual
De la misma forma para le entrega de informes semanales, cada uno de los
líderes de equipos presentará un informe mensual al Director de Proyecto, quien a
su vez emitirá un informe global que será enviado a la Gerencia General de Fiserv
Costa Rica. No obstante, y a diferencia de los reportes semanales, este informe irá
más enfocado a medir el rendimiento del proyecto y su impacto en cuanto a
tiempo y desempeño del mes en cuestión, con un resumen de tareas finalizadas y
las completadas, problemas encontrados y la forma como se resolvieron. Además
se incluirá en el informe, un pronóstico de avance para el mes siguiente. Este
informe a su vez será enviado a la Casa Matriz de Fiserv a través del señor Julio
Cruz (Gerente General de Fiserv Costa Rica) para actualizar a dicha oficina en el
avance del proyecto. Estos reportes también se almacenarán en el sistema Sayri
para que todos los involucrados lo puedan revisar. El formato del informe mensual
se puede ver en el Anexo 6.
7.7 Reuniones
Las reuniones son importantes para mantener la comunicación fluyendo de forma
más directa y para refrescar aquella información relevante del proyecto que
necesite ser reforzada de forma oral. Las siguientes son las reuniones que se
llevarán al cabo y el fin de cada una:
1. Reunión Semanal 1
Participantes: Director del Proyecto y Equipo de Proyecto
78
Objetivo: revisar los avances del proyecto durante la semana y discutir el informe
semanal enviado de forma previa a la reunión.
Día propuesto: Lunes de cada semana.
2. Reunión Semanal 2
Participantes: Director del Proyecto, Richard Icenberg
Objetivo: discutir los avances de cada semana (cronograma del proyecto), así
como la documentación generada al día de la reunión.
Día propuesto: Martes de cada semana.
3. Reunión Mensual 1
Participantes: Director del Proyecto, Gerencia General de Fiserv Costa Rica
Objetivo: discutir los avances de cada mes del proyecto haciendo énfasis en los
aspectos negativos y positivos del proyecto.
Día propuesto: Última semana de cada mes.
4. Reunión Quincenal 1
Participantes: Director del Proyecto, Gerente de TI, Sanjiv Kumar.
Objetivo: discutir los avances en las tareas que le corresponden al equipo de TI,
para revisar cualquier observación departe de India y tomar las consideraciones
necesarias para las siguientes actividades.
Día propuesto: Segunda y cuarta semana de cada mes.
79
8 PLAN DE GESTIÓN DE RIESGOS
Un plan de gestión del riesgo pretende aumentar la probabilidad e impacto de los
eventos positivos y disminuir la probabilidad e impacto de los eventos negativos
para evitar situaciones confusas que pongan en riesgo el éxito del proyecto.
Actualmente es una herramienta eficaz en el control y seguimiento de un proyecto
pues resulta ser una forma de disminuir el grado de incertidumbre que se puede
generar en un proyecto. El siguiente plan pretende definir el proceso para
planificar el riesgo, identificar el riesgo y dar respuesta a los riesgos identificados.
8.1 Definición de Riesgo
Un riesgo de un proyecto es un evento o condición inciertos que, si se produce,
tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, como
tiempo, coste, alcance o calidad (es decir, cuando el objetivo de tiempo de un
proyecto es cumplir con el cronograma acordado; cuando el objetivo de coste del
proyecto es cumplir con el coste acordado; etc.). Un riesgo puede tener una o más
causas y, si se produce, uno o más impactos. (PMI, 2004)
Objetivos de la Gestión de Riesgos
• Maximizar la probabilidad y el impacto resultados de los eventos positivos y
disminuir la probabilidad y el impacto de los eventos adversos para el
proyecto.
• La Gestión del Riesgo incluye técnicas estructuradas para bloquear las
“sorpresas” antes de que ocurran (proactivos)
• Lograr una administración profesional de proyectos
Beneficios de la Gestión de Riesgos
• Se evaden los problemas anticipadamente, por lo que disminuyen las
“sorpresas” en los proyectos.
80
• Los proyectos se hacen más simples (enfocados), terminan más rápidos y
se reducen los costes.
• Ayuda a cumplir los compromisos adquiridos con el cliente.
• Mejora la imagen y condiciones de negociación del Director del Proyecto.
• Nos permite una Dirección de Proyectos proactiva, aumentando las
posibilidades de éxito del proyecto.
8.2 Registro de Riesgos
El registro de riesgos es la herramienta que se propone para el proceso de crear el
Plan de Riesgos en los proyectos que se realicen en Fiserv Costa Rica. Se
desarrolla como una matriz que contiene en primera instancia las casillas
necesarias para la identificación de riesgos y se amplia posteriormente para
completarla con la respuesta a estos.
Para este proyecto específicamente el registro de riesgos contendrá las siguientes
columnas:
Iden
tifi
cad
or
Cau
sa
Rie
sgo
Imp
acto
Pro
bab
ilid
ad
Ran
go
Cat
ego
ría
Est
rate
gia
Acc
ión
Co
nti
ng
enci
a / P
lan
de
Res
pal
do
Tie
mp
os
Res
po
nsa
ble
Dis
par
ado
r
Per
iod
icid
ad
8.3 Identificación de Riesgos
Esta etapa determina la primera columna del registro de riesgos e incluye
identificar aquellos riesgos negativos y los riesgos positivos que pueda enfrentar el
proyecto, es decir, determinar aquellos riesgos que podrían implicar una
oportunidad para el proyecto y encontrar además la causa de los mismos. En este
proceso es importante incluir a los miembros del equipo en una lluvia de ideas, ya
que estos participaron en proyectos anteriores y pueden complementar la lista de
riesgos. Así a través de las lecciones aprendidas de proyectos anteriores se puede
identificar más riesgos.
81
8.4 Clasificación de Riesgos
Tomando en cuenta el tipo de trabajo que se desarrolla en Fiserv Costa Rica y que
se desenvuelve en el área del desarrollo de software, se presenta a continuación
una forma en que los riesgos fueron clasificados para este proyecto y que puede
servir de base para futuros proyectos. La nomenclatura será parte de la forma en
que posteriormente se identificará cada riesgo.
• RA- Riesgo de Administración de Proyectos: riesgos relacionados con la
administración del proyecto.
• RE- Riesgo Externo: riesgos que están por fuera de la organización que
pueden afectar el desarrollo del proyecto.
• RO- Riesgo Organizacional: riesgos relacionados con aspectos propios de
la organización.
• RT- Riesgo Técnico: riesgos relacionados con aspectos técnicos del o los
productos del proyecto.
8.5 Causa del Riesgo
El siguiente paso después de la identificación y clasificación de riesgos es
determinar su causa. Para efectos de esta propuesta, la causa del riesgo se puede
determinar con la ayuda de la RBS (Risk Breakdown Structure o Estructura
Detallada de Riesgo), un diagrama que ofrece la clasificación del punto anterior y
se descompone en niveles más pequeños dentro de cada categoría. La Figura
No.9 muestra la forma en que fueron clasificados los riesgos en este proyecto.
Esta estructura puede ser usada para cualquier proyecto futuro pues incluye las
áreas que funcionan dentro de Fiserv en general. Esta permitirá identificar en cuál
categoría cae cada riesgo y esta es la información que deberá ubicarse
posteriormente en la columna Causa, del registro de riesgos.
82
Figura No.9. Estructura detallada de riesgos
8.6 Análisis Cualitativo
Para efectos de evaluar el riesgo que enfrenta la compañía en el proyecto, se
realizó un análisis cualitativo. Este análisis se desarrolló evaluando el impacto y la
probabilidad, que son los 2 componentes primarios de un riesgo. Estos
porcentajes surgen al analizar la clasificación y la causa dadas a cada riesgo, para
luego clasificarlos en orden de prioridad, acorde a sus efectos potenciales en los
objetivos del proyecto.
El Cuadro No.10 y el Cuadro No.11.muestran los criterios de probabilidad e
impacto que se definieron para este proyecto.
83
Cuadro No.10. Criterios de probabilidad
Criterio Probabilidad
Muy Probable 0.9
Bastante Probable
0.7
Probable 0.5
Poco Probable 0.3
Muy Poco Probable
0.1
Cuadro No.11. Escala de impacto
Impacto Criterio Definición de Categoría
0.8 Muy Alto Un evento, que si ocurre, causaría fallas en el proyecto (inhabilita el alcance de los requerimientos mínimos aceptables)
0.4 Alto Un evento, que si ocurre, causaría incrementos severos en el costo y el tiempo. Requerimientos secundarios pueden no ser alcanzados.
0.2 Moderado Un evento, que si ocurre, causaría incrementos moderados en el costo y el tiempo, pero los requerimientos importantes pueden aún lograrse.
0.1 Bajo Un evento, que si ocurre, causaría incrementos bajos en el costo y el tiempo. Los requerimientos pueden ser alcanzados.
0.05 Muy Bajo Un evento, que si ocurre, no tendría efecto en el proyecto.
84
Para ubicar el impacto de cada riesgo en la escala utilizamos los siguientes
criterios del Cuadro No.12.
Cuadro No.12. Evaluación del impacto de un riesgo
Evaluación del impacto de un riesgo en los objetivos principales del proyecto (Escala ordinal o cardinal, escala no lineal)
Objetivo del Proyecto
Muy Bajo 0.05
Bajo 0.1 Moderado 0.2 Alto 0.4 Muy Alto
0.8
Calendario Insignificante variación del calendario
Variación del calendario < 5%
Desviación general del Proyecto 5 – 10 %
Desviación general del Proyecto 10 – 20 %
Desviación general del Proyecto >10 – 20 %
Alcance
Reducción del alcance apenas perceptible
Áreas menores del alcance son afectadas
Áreas mayores del alcance son afectadas
Reducción del alcance inaceptable para el cliente
El producto final del proyecto es inservible
Calidad
Degradación de la calidad apenas perceptible
Solo aplicaciones muy específicas son afectadas
La reducción de la calidad demanda la aprobación del cliente
Reducción de la calidad inaceptable para el cliente
El producto final del proyecto es inservible
8.7 Categorización de los Riesgos
Una vez que se establecieron los valores de la probabilidad e impacto para cada
uno de los riesgos, estos valores se multiplicaron, para obtener un solo valor
denominado Rango y este Rango se ubicó según la escala del Cuadro No.13 para
determinar que tan crítico es cada uno de los riesgos. Esto permitió establecer
posteriormente una respuesta acorde a cada uno.
85
Cuadro No.13. Matriz PxI
Marcador de riesgo para un riesgo específico (P x I)
Impacto Probabilidad
Muy Bajo 0.5
Bajo 0.1 Moderado 0.2 Alto 0.4 Muy Alto
0.8
0.9 0.05 0.09 0.18 0.36 0.72
0.7 0.04 0.07 0.14 0.28 0.56
0.5 0.03 0.05 0.10 0.20 0.40
0.3 0.02 0.03 0.06 0.12 0.24
0.1 0.01 0.01 0.02 0.04 0.08
Alto: 0.18 a 0.99. Inaceptable, requiere de una administración de alta prioridad.
Medio: 0.05 a 0.17. Puede ser requerida alguna medida contingente. Requiere
administración adicional.
Bajo: 0.01 a 0.04: Mínimo impacto.
8.8 Planificación de la Respuesta a Riesgos
Una vez identificados y priorizados cada uno de los riesgos se debió desarrollar
procedimientos y acciones para mejorar las oportunidades y minimizar las
amenazas a los objetivos del presente proyecto.
Estas respuestas pueden convertirse en actividades en el cronograma y acciones
en el plan de gestión del proyecto.
86
8.9 Estrategias de Respuesta
Una forma de dar respuesta a los riesgos es siguiendo las estrategias que se
muestran a continuación, utilizadas para dar respuesta a los riesgos del presente
proyecto:
• Eliminar: Eliminación del riesgo
• Transferir: Transferencia del riesgo (traslado de la responsabilidad a
terceras partes).
• Mitigar: Mitigación del riesgo.
• Aceptar: Aceptación del riesgo. Debe utilizarse para los riesgos de
categoría baja.
Una vez establecida la categorización de los riesgos, se propone desarrollar un
enfoque de mitigación del riesgo y de ser necesario, de contingencia para aquellos
con categoría Alta y Media. Deben describirse las acciones definidas (ya sean
mitigantes o contingentes) correspondiente a cada riesgo.
El conjunto de actividades y tareas definidas para la mitigación de los riesgos de
este proyecto, fueron incorporadas al Plan de Proyecto en la parte del
cronograma, como parte de las actividades normales del mismo.
El conjunto de actividades y tareas definidas para la atención de contingencias se
incorporaron al registro de riesgos, para aquellos casos en que se produzca el
evento y deba actuarse enfrentando el riesgo materializado.
8.10 Análisis Cuantitativo
Este plan de proyecto pretende cuantificar el tiempo que puede generar la acción
o el plan de contingencia para los riesgos no aceptados, por ello se desarrolló un
análisis cuantitativo además del análisis cualitativo, de manera que este tiempo
pueda ser tomado en cuenta en el cronograma de trabajo de ser necesario.
87
El Análisis Cuantitativo de Riesgos se realiza respecto a los riesgos priorizados en
el proceso Análisis Cualitativo de Riesgos por tener un posible impacto
significativo sobre las demandas concurrentes del proyecto. El proceso Análisis
Cuantitativo de Riesgos analiza el efecto de esos riesgos y les asigna una
calificación numérica. (PMI, 2004)
La técnica a utilizar para este cálculo es el juicio de expertos, pues a través de las
lecciones aprendidas y experiencias del equipo del proyecto en proyectos
similares se puede hacer un cálculo del tiempo para el Plan de Gestión de
Riesgos. Para ello, una vez categorizados los riesgos y establecidas las
contingencias y/o planes de acción se procede a evaluar esta información para
asignar un tiempo de respuesta en cada riesgo no aceptado. El registro de riesgos
debe mostrar una columna denominada Tiempo para ubicar este dato.
8.11 Seguimiento y Control de los Riesgos
A continuación se ofrece la estrategia que se propone para el seguimiento y
control de riesgos, que contempla reuniones de seguimiento, informes de estado,
control de cambios y la actualización constante al plan de proyecto.
8.11.1 Reuniones de seguimiento
• Las reuniones para evaluar riesgos son las reuniones semanales
especificadas en el capítulo 6 de Comunicaciones, estas reuniones tienen
como fin, revisar el estatus del proyecto con base en los reportes
semanales enviados por los jefes de área al Director del Proyecto.
• Cuando se identifiquen riesgos estos serán asignados a un responsable
que se encargará de ejecutar el plan de acción correspondiente.
• Además de las reuniones semanales, el Director del Proyecto debe reunirse
mensualmente con la Gerencia General de Fiserv para discutir el reporte
mensual, que al igual que los reportes semanales contempla una sección
de riesgos que debe ser discutida con el Gerente General para evaluar el
estado de cada riesgo y sus planes de acción. Con ello se busca el apoyo
88
de la alta gerencia en caso de que su aprobación a algún cambio sea
necesaria.
8.11.2 Informes de Estado
Los reportes semanales y mensuales que generará el proyecto contemplan una
sección que informará el estado de los riesgos del proyecto. Ver Anexos 5 y 6
sobre las plantillas de estos informes.
8.11.3 Control de Cambios
Los cambios que se generen con respecto al Plan de Gestión de Proyectos,
deberán documentarse y presentarse al Director del Proyecto y a la Gerencia
General de Fiserv Costa Rica para su correspondiente aprobación (para esto se
utiliza la plantilla de gestión de cambios en el Anexo 8).
8.11.4 Actualización del Plan de Gestión
Se reformulará el Plan de Gestión de Proyectos, cuando la respuesta a los
Riesgos presentados no sea lo suficientemente efectiva o cuando se hayan
detectado nuevos riesgos que deban analizarse bajo la metodología prevista en
este documento, incorporando o reprogramando actividades.
8.12 Registro de Riesgos del Proyecto
8.12.1 Identificación de Riesgos del Proyecto
El Cuadro No. 14 muestra los riesgos identificados del proyecto siguiendo la
metodología expuesta anteriormente.
89
Cuadro No.14. Riesgos del proyecto
Identificador Causa Riesgo Impacto Probabilidad Rango Categoría
RO01 Organizacional - Recursos
Si a falta de recursos dedicados 100% al proyecto, los recursos compartidos no dedican el tiempo requerido a cada una de las tareas por situaciones inesperadas se puede generar un gran retraso en el cronograma del proyecto.
0.8 0.9 0.72 Alto
RO02 Organizacional-Dependencias del Proyecto
Si no se obtiene el apoyo ofrecido por la Gerencia General de Fiserv Costa Rica para los supuestos del proyecto, se puede afectar el alcance del proyecto afectando toda la planeación propuesta.
0.8 0.9 0.72 Alto
RO03 Organizacional - Recursos
Si la falta de compromiso del encargado de PCI DSS en Fiserv USA evita su participación en etapas tempranas del proyecto se puede generar retrasos en el cronograma por retrabajo en las etapas finales del proyecto.
0.8 0.5 0.4 Alto
RA01 Administrativo - Planificación
Si las oficinas de Fiserv en India asumen un rol de control y no de observador del proyecto, se puede generar gran confusión en la planeación establecida para el proyecto afectando el alcance y causando un retraso en el cronograma del mismo, debido a la diferencia de lineamientos entre Fiserv USA y Fiserv India.
0.4 0.5 0.2 Alto
RT01 Técnico-Requerimientos
Si se aceptan controles de cambios que afecten el alcance porque los requerimientos no están bien definidos puede generar aumento de tiempo en el cronograma del proyecto.
0.2 0.7 0.14 Medio
90
Cuadro No.14. Riesgos del proyecto (continuación)
Identificador Causa Riesgo Impacto Probabilidad Rango Categoría
RO04 Organizacional-Capacitación
Si por falta de conocimiento en materia del administración de proyectos, el equipo del proyecto no sigue los lineamientos del PMI para completar el proyecto se puede generar un retraso por incumplimiento de tareas.
0.2 0.7 0.14 Medio
RA02 Administrativo - Planificación
Si la falta de motivación de los empleados de Fiserv Costa Rica no se maneja apropiadamente se puede generar un atraso en el proyecto por falta de motivación para completar tareas.
0.2 0.5 0.1 Medio
RA03 Administrativo - Comunicación
Si el compromiso de los empleados para trabajar en el proyecto se ve afectado porque no se realiza una buena comunicación sobre PCI DSS desde el inicio hasta el final del proyecto en todos los niveles de la compañía, se puede generar retrasos en el cronograma del proyecto.
0.2 0.5 0.1 Medio
RO05 Organizacional-Recursos
Si se mantiene la alta rotación del personal en la compañía se puede generar retrasos en el cronograma del proyecto.
0.1 0.5 0.05 Medio
RO06 Organizacional - Capacitación
Si no se adquiere el conocimiento suficiente por parte del Director del Proyecto en materia de PCI DSS, se puede generar un bajo rendimiento del equipo del proyecto para realizar las tareas designadas afectando los tiempos del proyecto.
0.1 0.3 0.03 Bajo
0.3 Alto
La medición de probabilidad e impacto para cada riesgo indica que el promedio
general del proyecto es de 0.3 que según la Matriz Pxl es un promedio de riesgo
alto.
91
8.12.2 Análisis Cuantitativo
El Cuadro No.15 muestra el análisis cuantitativo realizado a los riesgos
identificados enfocado al factor tiempo.
Cuadro No.15. Análisis cuantitativo Reservas
Identificador Riesgo Tiempos
RO01
Si a falta de recursos dedicados 100% al proyecto, los recursos compartidos no dedican el tiempo requerido a cada una de las tareas por situaciones inesperadas se puede generar un gran retraso en el cronograma del proyecto.
1 día por semana
RO02
Si no se obtiene el apoyo ofrecido por la Gerencia General de Fiserv Costa Rica para los supuestos del proyecto, se puede afectar el alcance del proyecto afectando toda la planeación propuesta.
10 días
RO03
Si la falta de compromiso del encargado de PCI DSS en Fiserv USA evita su participación en etapas tempranas del proyecto se puede generar retrasos en el cronograma por retrabajo en las etapas finales del proyecto.
1 día por semana
RA01
Si las oficinas de Fiserv en India asumen un rol de control y no de observador del proyecto, se puede generar gran confusión en la planeación establecida para el proyecto afectando el alcance y causando un retraso en el cronograma del mismo, debido a la diferencia de lineamientos entre Fiserv USA y Fiserv India.
5 días
92
Cuadro No.15. Análisis cuantitativo (continuación)
Reservas
Identificador Riesgo Tiempos
RT01
Si se aceptan controles de cambios que afecten el alcance porque los requerimientos no están bien definidos puede generar aumento de tiempo en el cronograma del proyecto.
2 días antes del inicio del proyecto
RO04
Si por falta de conocimiento en materia del administración de proyectos, el equipo del proyecto no sigue los lineamientos del PMI para completar el proyecto se puede generar un retraso por incumplimiento de tareas.
10 días
RA02
Si la falta de motivación de los empleados de Fiserv Costa Rica no se maneja apropiadamente se puede generar un atraso en el proyecto por falta de motivación para completar tareas.
2 días
RA03
Si el compromiso de los empleados para trabajar en el proyecto se ve afectado porque no se realiza una buena comunicación sobre PCI DSS desde el inicio hasta el final del proyecto en todos los niveles de la compañía, se puede generar retrasos en el cronograma del proyecto.
5 días
RO05
Si se mantiene la alta rotación del personal en la compañía se puede generar retrasos en el cronograma del proyecto.
2 días
RO06
Si no se adquiere el conocimiento suficiente por parte del Director del Proyecto en materia de PCI DSS, se puede generar un bajo rendimiento del equipo del proyecto para realizar las tareas designadas afectando los tiempos del proyecto.
2 días
93
8.12.3 Planificación de la Respuesta a los Riesgos del Proyecto
La planificación de la respuesta a los riesgos se puede ver en el Cuadro No.16,
donde se adjuntan las acciones a realizar en caso de que el riesgo ocurra y en
algunos casos un plan de contingencia. El disparador de cada riesgo debe ser
monitoreado diariamente pues esta será la señal de ocurrencia de los riesgos.
Cuadro No.16. Planificación de la respuesta a los riesgos
Reservas
Identifica dor
Estra tegia
Acción
Contingencia / Plan
de Respal
do
Tiempos
Responsable
Disparador Periodicidad
RO01 Mitigar
Monitorear a través de informes semanales a los miembros del proyecto para detectar cualquier señal de retraso en el desarrollo de sus actividades. Mantener una lista de posibles candidatos que puedan incluirse en el proyecto como recursos extras y de esta forma dar soporte a los miembros del equipo que tengan problemas para terminar tareas a tiempo.
1 día por semana
Supervisores de Cuenta y Gerente de TI
El porcentaje de tareas completadas en algunos miembros del equipo son más bajos que otros.
Diario
RO02 Mitigar
Incluir en toda la planeación a la Gerencia General de Fiserv Costa Rica para obtener aprobaciones y apoyo de la Gerencia. Mostrar informes mensuales a la Gerencia General para alertar sobre cualquier riesgo relacionado con los supuestos del proyecto y realizar planes de acción inmediatos para arreglar un eventual problema.
10 días
Director de proyecto
Los recursos solicitados a la Gerencia General relacionados con los supuestos y alguna otra petición son rechazados o retrasados.
Etapa de Inicio del Proyecto
94
Cuadro No.16. Planificación de la respuesta a los riesgos (continuación) Reservas
Identificador
Estrategia Acción
Contingencia / Plan
de Respaldo
Tiempos Responsable Disparador Periodi cidad
RO03 Mitigar
Coordinar reuniones semanales con Richard Icenberg para evitar que este se desligue del proyecto.
1 día por semana
Director de proyecto
La falta de respuesta de Richard Icenberg a llamadas y correos.
Semanal
RA01 Mitigar
Presentar los roles y responsabilidades propuestos a la casa matriz de Fiserv, a través del Gerente General en Costa Rica para obtener una aprobación oficial por parte de USA y así tomar acuerdos sobre la función que tendrá cada oficina antes de que se inicie el proyecto oficialmente.
5 días
Gerencia General de Fiserv Costa Rica
Se tiene demasiada participación por parte de las oficinas de Fiserv en India.
Semanal
RT01 Mitigar
Someter a revisión la documentación realizada a Richard Icenberg para obtener retroalimentación constante por parte de él y su equipo y evitar grandes cambios en etapas tardías de proyecto. Someter el cronograma de proyecto a revisión de Richard Icenberg antes de la etapa de ejecución del proyecto para incluir posibles nuevos requerimientos que no hayan sido considerados en la etapa de planeación.
2 días antes del inicio del proyecto
Ingeniero de implementación
Aumento en el número de cambios del proyecto en lapsos cortos de tiempo.
Semanal
95
Cuadro No.16. Planificación de la respuesta a los riesgos (continuación)
Reservas
Identificador
Estrategia Acción Contingencia / Plan de
Respaldo Tiempos
Responsable
Disparador Periodi cidad
RO04 Mitigar
Incluir en el plan de capacitación una capacitación sobre la metodología del PMI previa a la de PCI DSS, que le permita al equipo del proyecto conocer, entender y practicar la metodología del PMI correctamente.
Reforzar la metodología del PMI en las reuniones semanales con el equipo del proyecto.
10 días Director de proyecto
Actitud de los miembros del equipo del proyecto es negativa para seguir la metodología propuesta.
Diario
RA02 Mitigar
Crear un plan de motivación para los empleados que permita premiar al equipo del proyecto por su esfuerzo para que el proyecto sea desarrollado en forma exitosa.
2 días Director del proyecto
Se presentan comentarios de carácter negativo por parte del equipo de proyecto.
Diario
RA03 Mitigar
Medir a través de pruebas escritas o en línea si el conocimiento de los empleados después de las capacitaciones es correcto, para evitar mal entendidos que puedan generar información incorrecta y por ende desmotivación para trabajar en el proyecto.
Realizar actividades enfocadas a informar a los empleados sobre PCI DSS.
5 días Director del proyecto
Se presentan retrasos en las tareas de los responsables sin justificación alguna.
Diario
96
Reservas
Identificador
Estrategia Acción Contingencia / Plan de Respaldo
Tiempos
Responsable
Disparador Periodi cidad
RO05 Aceptar
Incluir en el plan de capacitación acciones para capacitar de forma rápida y eficiente al personal nuevo que pueda entrar en la compañía durante el desarrollo del proyecto para que su acoplamiento al proyecto sea rápido evitando retrasos. Tener una lista de posibles reemplazos en caso de que algún miembro del equipo renuncie durante el desarrollo del proyecto.
2 días
Ingeniero de
implementación
Cantidad de renuncias registradas por mes.
Semanal
RO06 Mitigar
Coordinar acciones con Richard Icenberg para obtener alguna capacitación a través de Webex durante la etapa de Auto-entrenamiento del Director del Proyecto.
2
días
Director de
proyecto
El auto examen que debe practicarse el Director del Proyecto arroja resultados de bajo nivel.
Fase de
Capacitaci
ón
97
9 PLAN DE GESTIÓN DE LA INTEGRACIÓN DEL PROYECTO
El Área de Conocimiento de Gestión de la Integración del Proyecto incluye los
procesos y actividades necesarios para identificar, definir, combinar, unificar y
coordinar los distintos procesos y actividades de dirección de proyectos dentro de
los Grupos de Procesos de Dirección de Proyectos. (PMI, 2004). Con base en el
desarrollo de los capítulos anteriores es necesario lograr la integración de los
procesos desarrollados.
9.1 Acta de Constitución del Proyecto
El Acta de Constitución del Proyecto o Charter es el documento que da el inicio
oficial al proyecto. Este contiene a nivel general los objetivos del proyecto, el
alcance y principales clientes (directos e indirectos). Este documento además
contendrá las fechas de inicio y fin del proyecto y la aprobación departe de la
Gerencia General de Fiserv y el Director del Proyecto ubicando sus respectivas
firmas al pie del acta.
9.2 Gestión de Cambios del Proyecto
El cambio es un elemento existente en todo el desarrollo del proyecto, su gestión
eficiente permite administrar este proceso generando el mínimo impacto para el
proyecto. La gestión de un cambio se realizará cuando se detecten nuevos
requerimientos no contemplados con anterioridad y que son importantes para el
éxito del proyecto. De igual forma será necesario un cambio cuando algún
elemento de la planeación propuesta, por alguna circunstancia especial, no sea
eficiente y sea necesario modificar alguna parte del plan de proyecto.
Dado que la gestión del cambio es un proceso crítico dentro del proyecto es
importante que el cambio quede registrado y documentado utilizando la plantilla
adecuada (ver Anexo 8. Plantilla de Gestión del Cambio) la cuál debe contar con
la aprobación del Director del Proyecto y el Gerente General de la empresa.
98
Con base en los recursos humanos del proyecto se adjunta la lista de las personas
que pueden solicitar un cambio utilizando la plantilla de cambios:
• El Gerente General de la empresa
• El Director del Proyecto
• Los Supervisores de Cuenta
• El Gerente de TI
Los demás miembros del equipo deben gestionar algún cambio con sus
respectivos jefes de área.
La Figura No.10 presenta el proceso para la gestión de un cambio en el proyecto.
99
Figura No.10. Proceso de gestión de cambio
9.3 Procedimiento de Cierre Administrativo
Finalmente cuando todas las actividades del cronograma estén completadas, los
entregables finalizados y los recursos liberados se procede al cierre administrativo
del proyecto.
El cierre administrativo implica recopilar la información histórica de toda la
documentación generada a lo largo del proyecto de manera que sirva como parte
de las lecciones aprendidas para futuros proyectos. La documentación generada
quedará guardada en el sistema interno Sayri, donde debe irse documentando
todo el desarrollo del proyecto. En este punto además debe hacerse uso de la
100
Plantilla para Lecciones Aprendidas en el Anexo 9 y también deben quedar
guardadas en el sistema interno Sayri.
Una reunión de cierre debe coordinarse para realizar un postmortem del proyecto
que permita analizar lo que se hizo bien y lo que se hizo mal junto con el equipo
del proyecto para con esta información dejar una base firme para futuros
proyectos.
101
10 CONCLUSIONES
Con base en la investigación realizada sobre la teoría de Administración de
Proyectos y tomando en consideración la cultura organizacional de Fiserv Costa
Rica se concluye lo siguiente:
• La metodología del PMI se adoptó como el procedimiento a seguir para
realizar el proyecto de PCI DSS en Fiserv Costa Rica por sus
características que se adaptan a la cultura organizacional de la empresa y
por haber un interés por parte de la Gerencia General de Fiserv Costa Rica
por utilizar dicha metodología y de esta forma sentar las bases para la
administración de futuros proyectos.
• Actualmente los proyectos realizados en el pasado en Fiserv Costa Rica no
han utilizado ninguna metodología como base que haya permitido el éxito
en alguno de ellos. Por el contrario los proyectos que anteceden a este
proyecto, han presentado retrasos importantes y no han podido sentar
alguna base firme que permita la correcta administración de proyectos
dentro de la compañía.
• A falta de documentación de proyectos anteriores, la planeación de este
proyecto tomó en cuenta el juicio de expertos, estos son personas que han
participado en proyectos anteriores y que cuentan con información valiosa
que pudo ser extraída utilizando el método de entrevistas.
• El elemento de la motivación en las personas que han participado en
proyectos anteriores fue un factor determinante dentro de la planeación, ya
que el equipo de proyecto es el mismo equipo del proyecto anterior ISO
27001. La falta de planeación y orden en ese proyecto ha dado paso a una
102
desmotivación generalizada para trabajar en este tipo de proyectos, por lo
cual es necesario cambiar la percepción negativa que se tiene, ya que el
proyecto de PCI DSS requiere un esfuerzo adicional a las labores
cotidianas de cada persona.
• La delimitación del alcance permitió determinar la responsabilidad de cada
oficina de Fiserv tanto en Estados Unidos como en la India y de esta forma
sentar los supuestos, limitaciones y exclusiones del proyecto, así como la
responsabilidad que tendrá cada oficina en el proyecto.
• La Gestión del Tiempo permitió establecer las actividades necesarias para
desarrollar los objetivos planteados para el proyecto y establecer una
secuencia lógica. Tomando como base el proyecto anterior de ISO 27001
se realizó el cálculo de los tiempos para cada actividad del cronograma.
• El plan de Gestión de los Recursos Humanos se determinó a partir de la
EDT desarrollada en el capítulo del Alcance, lo que permitió aclarar los
roles y responsabilidades de cada persona dentro del proyecto, factor que
no ha sido considerado en proyectos anteriores causando confusión en el
desarrollo del proyectos.
• El plan de comunicaciones determina en detalle a los involucrados, factor
que ha resultado crítico en proyectos pasados. Con esta información fue
posible establecer la matriz de comunicación del proyecto.
• El análisis de posibles riesgos dio paso a la identificación de los mismos,
utilizando el juicio de expertos y lecciones aprendidas de proyectos
pasados. Con ello se calculó el impacto y la probabilidad de los riesgos
identificados, dando como resultado un promedio de riesgo total del
103
proyecto de 0.3 que según la categorización de riesgos es un promedio de
riesgo alto. Algunas de las respuestas a los riesgos fueron incorporados al
cronograma de proyecto para mitigar el impacto de la mayoría de estos
riesgos. En otros casos se desarrolló un plan de contingencia como
respuesta a algunos riesgos en caso de que estos ocurran.
• Finalmente los procesos de integración descritos en este plan de proyecto
pretenden complementar los diferentes procesos a través de un acta de
constitución del proyecto, un proceso para la correcta gestión del cambio y
con un proceso formal de cierre de proyecto de tipo administrativo que
permita sentar las bases de proyectos futuros dentro de Fiserv Costa Rica.
104
11 RECOMENDACIONES
En este apartado se presentan las recomendaciones resultantes del proceso de
planeación de este plan de proyecto:
• Utilizar este plan de proyecto como base para la planificación de proyectos
futuros de esta índole, ya que dentro de la lista de proyectos futuros se
encuentran más proyectos enfocados a obtener certificaciones en materia
de seguridad para la empresa.
• Retomar las lecciones aprendidas resultantes de este proyecto y
almacenarlas en el sistema Sayri para la planeación de futuros proyectos.
Así mismo darle continuidad al sistema Sayri como medio oficial para la
administración de proyectos en Fiserv Costa Rica.
• Realizar el análisis necesario para incluir dentro de este plan las áreas de
conocimiento de calidad y adquisiciones según las características que
presenten cada uno de los proyectos.
• Controlar con mucho detalle y de forma diaria los supuestos establecidos
en el capítulo del Alcance, ya que a falta de alguno de estos supuestos la
planeación propuesta en este documento podría perder validez y aumentar
así el riesgo de fracaso del proyecto.
• Continuar con capacitaciones en materia de administración de proyectos,
específicamente en la metodología del PMI para gerentes y jefes de área,
ya que la comprensión y manejo adecuado de esta metodología permitirá la
fluidez en la planeación de futuros proyectos y reducirá el riesgo de fracaso
de proyectos por falta de formación.
105
• Coordinar con la casa matriz de Fiserv procesos de trabajo en conjunto en
materia de proyectos. Esto debido a que el trabajo en conjunto con otras
oficinas de Fiserv en proyectos anteriores ha sido un elemento de
desorganización y confusión. Por lo tanto para reducir el riesgo de
involucrados que aparecen sorpresivamente en etapas finales del proyecto
y evitar desorganización, es necesario que queden claros los procesos que
deben seguir cada una de las oficinas de Fiserv cuando sea necesario
apoyar a otra oficina en alguna actividad.
106
12 BIBLIOGRAFIA
Chamoun, Y. (2002). Administración Profesional de Proyectos. Una Guía Práctica para Programar el Éxito de sus Proyectos. México: McGraw Hill Interamericana.
Eyssautier, M. (2002). Metodología de la investigación. Desarrollo de la
inteligencia (4ª ed.). México: International Thomson Editores. Fiserv. (2009). Fiserv History and Products. Extraído el 10 de Agosto, 2009, de
http://fiserv.com/ Gido, J. & Clements, J. (2007). Administración exitosa de proyectos (3ª ed.).
México: Internacional Thompson Editores. IABG, (2004). V-Modell. Extraído el 6 de Octubre, 2009, de http://www.v-
modell.iabg.de/ Muñoz, C. (1998). ¿Cómo elaborar y asesorar una investigación de tesis? (1ª ed.).
México: Pearson Educación / Prentice Hall. Office of Government Commerce, OGC. (2009). Prince2. Extraído el 6 de Octubre,
2009, de http://www.ogc.gov.uk/methods_prince_2__overview.asp PCI Security Standards Council. (2009). PCI DSS Certification. Extraído el 14 de
Agosto, 2009, de https://www.pcisecuritystandards.org/ Project Management Association of Japan, PMAJ. (2007). Development of the
New Project Management Knowledge System (P2M). Extraído el 3 de
Octubre, 2009, de http://www.pmaj.or.jp/ENG/index.htm
Project Management Institute, Inc. (2004). Guía de los fundamentos de la
Dirección de Proyectos. PMBOK Guide (4ª ed.). Newtown Square, Pennsylvania, E.E.U.U.
Tejeda, R. (1999). El método inductivo-deductivo y Charles Darwin. [Versión
Electrónica]. Correo del Maestro. Extraído el 24 de Agosto, 2009, de http://www.correodelmaestro.com/anteriores/1999/febrero/3anteaula33.htm
Wells, D. (2009). XP, Extreme Programming. Extraído el 3 de Octubre, 2009, de
http://www.extremeprogramming.org/
107
13 ANEXOS
Anexo 1: ACTA DEL PROYECTO
ACTA DEL PROYECTO Fecha Nombre de Proyecto Viernes 31 de Julio, 2009
Plan de Proyecto para el Proceso de Certificación PCI DSS en Fiserv Costa Rica.
Áreas de conocimiento / procesos:
Área de aplicación (Sector / Actividad):
Integración Alcance Tiempo Recursos Humanos Comunicaciones Riesgos
Desarrollo de Software para el Sector Bancario.
Fecha de inicio del proyecto Fecha tentativa de finalización del proyecto 3 de Agosto, 2009
8 de Diciembre, 2009
Objetivos del proyecto (general y específicos) Objetivo General: Desarrollar un Plan de Proyecto para el proceso de Certificación de PCI DSS en Fiserv Costa Rica en su etapa de análisis, para cumplir con los estándares de seguridad de información dispuestos por la casa matriz de la compañía. Objetivos Específicos:
• Desarrollar el acta de constitución del proyecto para asegurarse que el proyecto incluya todo el trabajo requerido y completar el proyecto satisfactoriamente.
• Desarrollar el cronograma del proyecto para garantizar la conclusión del proyecto en el tiempo establecido.
• Desarrollar un Plan de Gestión del Personal para identificar y documentar los roles del proyecto así como para saber cuando y como se cumplirán los requisitos de recursos humanos.
• Desarrollar un plan de comunicaciones para determinar las necesidades de información y garantizar la buena comunicación de los interesados.
• Desarrollar un Plan de Gestión de Riesgos para aumentar la probabilidad e impacto de los eventos positivos y disminuir la probabilidad e impacto de los eventos adversos para el proyecto.
108
Anexo 1: ACTA DEL PROYECTO (continuación)
Justificación o propósito del proyecto (Aporte y resultados esperados) La certificación PCI DSS es un estándar de seguridad para compañías que trabajan con información de tarjetas de crédito y débito ya sean bancos, comercios u otros proveedores, creado por las compañías más importantes en tarjetas para compras, como los son Visa y Mastercard. Dicha certificación ayuda a facilitar la adopción de medidas de seguridad consistentes para el manejo de dichos datos. Debido a que Fiserv es una empresa proveedora de desarrollo de software para entidades bancarias, el uso de este tipo de información confidencial es requerido en casi todos los proyectos que maneja la compañía. Algunos de los clientes de Fiserv son otras divisiones, que desarrollan software para importantes bancos en los Estados Unidos y Europa. Otras operaciones de Fiserv Global desarrollan software para aplicaciones de compra en línea, donde se maneja información de tarjetas de débito y crédito. Como requisito primordial para trabajar en estos ambientes bancarios, la casa matriz de Fiserv en Orlando, ha decidido que todas sus oficinas deben obtener esta certificación para garantizar seguridad en todas sus operaciones y así sumarse al esfuerzo de muchas instituciones financieras que como clientes de Fiserv, tienen como requisito que sus proveedores estén certificados bajo el estándar del PCI DSS. Descripción del producto o servicio que generará el proyecto – Entregables finales del proyecto Producto: El Plan de Proyecto para la fase de planeación para la obtención de la certificación PCI DSS en Fiserv Costa Rica Descripción: El Plan de Proyecto para la obtención de la certificación PCI DSS en Fiserv, contendrá la información necesaria para asegurar el éxito del proyecto en la etapa de planeación de dicho proceso de certificación. El plan desarrollará el acta de constitución del proyecto, definirá las actividades necesarias para llevar el proyecto a su buen término y se les asignará el tiempo requerido. Además el plan contemplará la gestión de recursos humanos, las comunicaciones y los riesgos. Entregables Finales del Proyecto
1. Acta de Constitución del Proyecto 2. Documento de la Estructura Detallada de Trabajo (EDT) 3. Cronograma de Trabajo 4. Plan de Gestión del Personal 5. Plan de Gestión de las Comunicaciones 6. Plan de Gestión de Riesgos/Registro de Riesgos
109
Anexo 1: ACTA DEL PROYECTO (continuación)
Supuestos • Se contará con el apoyo de información de las oficinas centrales de Fiserv en Brookfield,
Winsconsin, oficina que actualmente cuenta con la certificación PCI DSS. • Se contará con el apoyo de la empresa BSI Global contratada para realizar las
certificaciones de Fiserv en materia de seguridad de la información. • Se contará con el apoyo de las oficinas de Fiserv India, durante todo el proceso de
planeamiento, proporcionando documentos e información utilizados en el proceso de certificación de PCI DSS en India, oficina que se encuentra actualmente certificada.
• El Director del Proyecto tendrá funciones 100% administrativas, que le permitirán dirigir el proyecto sin necesidad de ocuparse de otras funciones fuera del área de la administración de proyectos.
• Se contará con el apoyo de la Gerencia General para el uso de todos los recursos que integran el proyecto (recursos compartidos), para que estos puedan cumplir las actividades que les serán asignadas en el tiempo establecido.
Restricciones
• Falta de cultura de Administración de Proyectos en la organización, ya que actualmente ningún proyecto en la organización se ha realizado utilizando esta metodología.
• La limitación de recursos que emplea la compañía actualmente debido a la crisis económica en Estados Unidos, puede afectar los costos de capacitación del personal y por ende afectar todo el proyecto.
• La falta de conocimiento de la metodología del PMI en el área administrativa y en la empresa en general que evita que los proyectos puedan organizarse y planearse siguiendo estos lineamientos.
• Desorganización en proyectos de certificación anteriores que ha llevado a una desmotivación de las personas a trabajar en este tipo de proyectos.
• El equipo del proyecto estará conformado por empleados de Fiserv contratados para llevar a cabo otras funciones y responsabilidades fuera de este proyecto. Por lo tanto son recursos compartidos que utilizarán una porción de su jornada laboral para desarrollar las actividades programadas en este proyecto. Su utilización por lo tanto no es del 100%.
Información histórica relevante
• Documentación para la Certificación ISO 27001 que actualmente se está implementando en Fiserv Costa Rica.
• Documentación de PCI DSS proporcionada por Fiserv India.
110
Anexo 1: ACTA DEL PROYECTO (continuación)
Identificación de grupos de interés (Stakeholders) Cliente(s) directo(s):
• Gerencia General de Fiserv Costa Rica Cliente(s) indirecto(s):
• Fiserv oficinas centrales en Orlando, Florida • Fiserv oficinas en India
Aprobado por: Profesor Manuel Álvarez Elaborado por: Leana Romero Arce
Firma: Revisado por:
111
Anexo 2: EDT DEL PFG
112
Anexo 3: CRONOGRAMA DEL PFG
113
Anexo 4: CRONOGRAMA DEL PROYECTO PCI DSS FISERV, COSTA RICA
114
Anexo 5: FORMATO INFORME SEMANAL
Informe Semanal
Versión: 1 Fecha: 22/10/2009 Código: FSV-001
Proyecto:
Jefe de Área: Semana del: a:
Actividades Asignadas Actividades Terminadas
Actividades en Proceso % Responsable Observaciones
Marcar en rojo las actividades retrasadas
Riesgos Planes de Acción
Aspectos Positivos Identificados
115
Anexo 6: FORMATO INFORME MENSUAL
Informe Mensual
Versión: 1 Fecha: 22/10/2009 Código: FSV-002
Proyecto:
Director del Proyecto: Mes:
Total de Actividades Logros/Avance Desviaciones
Actividades Terminadas
Actividades en Proceso
% Terminado
Riesgos Planes de Acción Responsable
Prioridades (Qué debe hacerse la próxima semana) Áreas de Oportunidad
Aspectos Positivos Identificados
116
Anexo 7: PLANTILLA PARA MINUTAS DE REUNIÓN
Minuta de Reunión
Versión:1 Fecha: 22/10/2009 Código: FSV-003
1. Información del Proyecto Nombre del Proyecto: Código del Proyecto: Fecha: Objetivo de la Reunión: Hora de Inicio: Hora Finalización:
1. Información de la Reunión
Participantes de la Reunión Ausentes
Informe de Reunión N° Asunto Descripción de la Situación Acciones Responsable
117
Anexo 8: PLANTILLA PARA GESTIÓN DE CAMBIOS
Control de Cambios
Versión:1 Fecha: 22/10/2009 Código: FSV-004
1. Información del Proyecto Nombre del Proyecto: Código del Proyecto: Fecha: Control de Cambio No.:
2. Descripción del Cambio Solicitante:
Cambio Propuesto:
Actividad de la EDT:
Descripción del Cambio:
Justificación:
Acciones a Realizar:
Asignado a:
3. Impacto Alcance Tiempo Costo Calidad
118
Anexo 9: PLANTILLA PARA LECCIONES APRENDIDAS
Lecciones Aprendidas
Versión: 1 Fecha: 22/10/2009 Código: FSV-005
1. Información del Proyecto Nombre del Proyecto: Código del Proyecto:
2. Lecciones Aprendidas Lección No. Actividad del EDT:
Descripción del Problema:
Descripción de la Solución Aplicada:
Descripción de los Instrumentos Diseñados:
Lección No. Actividad del EDT:
Descripción del Problema:
Descripción de la Solución Aplicada:
Descripción de los Instrumentos Diseñados:
Lección No. Actividad del EDT:
Descripción del Problema:
Descripción de la Solución Aplicada:
Descripción de los Instrumentos Diseñados:
119
Anexo 10: PLANTILLA PARA CONTROL DE HORAS
Control del Horas del Proyecto
Proyecto: Proyecto #: Versión: 1
Director del Proyecto: Actualizado el: Código: FSV-006
Febrero
Name 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 17 18 19 20 21 22 23 24 25 26 27 28 Total
Total
120
Anexo 11: PLANTILLA PARA CONTROL DE ASUNTOS
Control de Asuntos del Proyecto
Proyecto: Proyecto #: Director del Proyecto: Actualizado el:
Versión: 1 Código: FSV-007
ID Descripción de la situación Impacto en el Proyecto Resolución/Plan de
Acción Responsable
Imp
ort
anci
a Fecha de
Ingreso
Fecha de
Revisión
Fecha de Resolución
1
¿Cuál es el problema?
¿Cómo el problema impactará el alcance,
tiempo y costo del proyecto?
¿Cómo se intentará resolver el problema?
¿Quién será el responsable de
la resolución/plan
de acción?
2 3 4 5 6 7 8 9
10 11 12 13 14 15